Alternate proposal for digital signatures

[Rob Seaman]

Bob Denny wrote:

> I see it as a publication by the author, using electronic printing  
> presses that are designed and operated by printers (the computer  
> techs) -- the manuscript is turned into printed pages (a form change  
> only) -- the author's data is turned into a VOEvent packet (a form  
> change only). I see the two as analogous.


I wasn't speaking metaphorically.  The roles of author and publisher  
are distinct, even if a particular author self-publishes in some  
fashion.  For instance, a particular document may have several  
authors.  These authors may collaborate in a number of distinct ways,  
in parallel or sequentially.  Authoring may involve iterative passes  
with editors (human or implicit in some authoring tool).

In contrast, to "publish" is an atomic operation by a single agent.  A  
publication adheres to a specific schema, whatever the author(s)'  
content.  It is tagged with an ID chosen from a namespace controlled  
by the publisher, not the author.  And it is some canonical form of  
the published realization of the content that is signed.

> I still have a hard time with the publisher altering the content

The publisher ensures compliance with curation standards.  The author,  
as with a paper publication, agrees to adhere to these standards as a  
requirement of publication.  The publisher doesn't alter the content -  
the payload - of the packet, but rather controls aspects of its  
presentation.

> The tool could (should!) produce a signed packet, thus the author  
> would know that those computer guys can't possible alter his/her data.

I don't think the key security concern here is the interaction between  
the astronomer and an observatory's software engineers :-)  Rather all  
these members of the astronomical community join in common purpose in  
a dangerous world.  Some external threats are intentional, many  
unintentional.  Authentication protects against both.

What we're really trying to clarify are the interfaces and protocols  
involved in modeling (e.g., via activity and sequence diagrams)  
typical authenticated VOEvent publication transactions.

An author initiates a transaction.  Content is assembled from one or  
many sources.  A single or multipart negotiation occurs between the  
author/client and publisher/broker.  As with paper journals, there may  
be third party agents - referees.  The author retains, implicitly or  
explicitly, final approval - but just as with a journal, the only  
recourse is to withdraw the submission.

> The ultimate result would be the author's data would end up in a  
> VOEvent packet, signed by the author.  The publisher's tools should  
> make this possible to a degree of assurance acceptable to the author.


Part of the assurance the author is seeking is adherence to a coherent  
publication strategy, including a publisher centered trust model.   
Subscribers trust the AAVSO, not necessarily the individual authors.   
They trust peer review as performed by MPC and CBAT.  They trust GCN  
to enforce robust, broad and persistent standards - and they will  
continue to trust VO-GCN since we will build even better such  
mechanisms into VOEvent.  This is the value added that lets the author  
focus on content while the publisher focuses on reliability of form.

> the most adaptable key-trust architecture is PGP's, thus it is the  
> most likely to fit whatever trust model(s) end up being required.

Anybody else want to assay an opinion here?  Are these two options the  
only candidates?  Is either fatally flawed?  Are there unique and  
valuable features of one choice, missing from the other?

> your message is probably sort of a watershed event.

Don't say that!  It's like throwing gasoline on a fire...

Rob
--



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20080319/ba78cee8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Biot376PhotoE.jpg
Type: image/jpeg
Size: 26018 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20080319/ba78cee8/attachment-0001.jpg>