Alternate proposal for digital signatures

[Bob Denny]

Steve:
> Alternatively, admit that the notion of message integrity is irrelevant, 
> uninteresting, or unmotivating, perhaps as a result of specifying the use of 
> already-secure communications channels.

That still leaves authenticity, "This is MY data..." and drops the "... and it
hasn't been altered."

Rob (typ.):
> 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).

I see that entire process as "authoring" with the resulting "data" being the
work-product of an "author". The "author" could be a collection of parties
collaborating, and the name of the author could contain many peoples' names,
editors' names, organization names, etc. In the end, there is an "author"
(collective or individual is immaterial), and "data" to be published.

Also, to clarify, by "data" I mean the semantic content not the form. That's
what I was getting at by using the analogy of book publishing... a change of
form but not semantic content. Yes, iterations are part of producing the final
content, but in my analogy "publishing" is the act of "broadcasting" the final
authored content in one or more forms without changing the semantic meaning.

> 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.

Yes. So it seems we're saying the same things.

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

OK, I understand.

> 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.

And once that approval has been given, the result is what I'm calling "data".
The form(s) of the data (raw XML, XML+XSLT=[HTML|???], printed paper...) as
produced by publication are the other part.

> 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.

In the above, the AAVSO does -two- things: quality assurance of content and
reliability of distribution form. I see quality assurance as part of the
"authoring" process, and "distribution" as what I have been calling
"publication". I suppose differences in terminology are inevitable, given the
different environments we operate in :-) See the attached drawing.

But more importantly, is VO really going to take responsibility for the quality
of the data in a VOEvent packet? Will we have real-time peer-review of (e.g.) a
CV outburst alert? Somehow this seems very difficult to implement at a minimum,
and may be impossible without compromising the time-sensitive (transient) nature
of event "publications". At some point we need to consider the SOURCE of the
packet as trustworthy enough to use the packet as input to our observatory.

I can see us (VO) enforcing standards of -form- on event packets, but I don't
know how we could take on enforcement of quality of -content-. It's possible
that applying the notion of a "publisher centered trust model" isn't appropriate
here, or maybe we aren't the "publisher" in the traditional sense.

In the end, upon receiving a VOEvent packet a decision must be made: "Is this
trustworthy (and interesting) enough to warrant interrupting my operations and
take data in response?"

Specific examples:

1. Packet from GCN, signed by GCN, AuthorIVORN is GCN: I trust it, and act upon
it (if I'm interested).

2. Packet from Steve Brady (amateur CV investigator), signed by Steve Brady,
Author IVORN Steve Brady: I don't trust it and discard it.

3. Packet from AAVSO, signed by AAVSO, Author IVORN Steve Brady: I trust it
because (presumably) it has been reviewed and accepted by AAVSO.

Should we be using the term "source" instead of "author"? In the above, we could
say that the sources are GCN, Steve Brady, and AAVSO, respectively.

If so, it seems that we should expect that a signature would be applied by the
source. Then, unless we intend do do additional quality assurance (more review),
there would be no need for us to add additional signatures because they would be
meaningless (in terms of authenticity/trust). We could chose any scheme
(including "none" as Steve pointed out) to assure that the packets get from the
source to the destination unaltered.

So the big question is "Is VO going to be part of the -content- quality
assurance process for event packets?"

Right now, we don't even take responsibility for the -structure- of the packet.
Today's packets are sometimes not conformant. I'll post a separate note here
with my findings in that regard.

  -- Bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VOPub.png
Type: image/png
Size: 32842 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20080319/c91eb57d/attachment-0001.png>