Signing events

[Rob Seaman]

Hola,

As Norman's comment implies:

> Indeed.  Signing the bits on the wire means that it's possible to check the signatures when they _enter_ the system, but unless those bits are stored verbatim, there's no possibility of re-verifying the signature, by the same client later, or by someone else if the VOEvent packet is passed on.  That is, a signature which lives inside a comment won't realistically survive passage through an XML database, or a SAX stream, or a DOM.

these engineering choices come down to how the signatures will be used.  One strong advantage of the Dakota model is that it already exists.  Personally, I'm strongly resisting a detour into a discussion of hash functions in general :-)

John identified three different concepts of where a digital signature for VOEvent might be used: on the wire, in the system (as XML is transmuted back-and-forth from database schemata), in the packets themselves.  Complications like canonicalization have been noted.  And there was an explicit decision to omit any discussion of signatures from VOEvent v2.0, given competing priorities.

More fundamental yet is how the signed or unsigned VOEvent packets themselves will be used.  It is clear that the IVOA Technical Coordination Group (to the extent they've given it any thought whatsoever) view VOEvent as a purely ephemeral representation distinct from the IVOA's more permanent and weighty data models.  However, this is not how transient alerts are viewed by the community.  GCN, MPC, CBAT, ATel notices are all cited in the literature.  One can presume VOEvent realizations of these will be as well (and indeed have already been).  One does not cite something intrinsically impermanent.

There is a special kind of permanence to a record of an ephemeral event, a special responsibility to get it right the first time.  Ultimately some way of managing trust (by signature or otherwise) will be applied to some realization of the VOEvent packets themselves.  For a comparable situation note that FITS was envisioned as purely an interchange format, but has been forced by the requirements of the community into a permanent archival role.

And an even more basic engineering question is whether we should be looking for a single signing technology at all.  A trust model for the transport can be implemented in addition to one for the servers.  These will often be the responsibilities of different stakeholders.  And whether in VOEvent v3.0 or a separate IVOA Note or in some other fashion, some sort of trust model may be eventually (so to speak) implemented for the packets themselves.  (Or perhaps this is implicit in the literature.  Nobody signs ApJ articles.)

As far as planning, what do the various projects need and when do they need it?

Rob