Cryptographic authentication of VOEvents

[Rob Seaman]

On Sep 12, 2012, at 7:25 AM, John Swinbank wrote:

> On 12 Sep 2012, at 00:43, Norman Gray <norman at astro.gla.ac.uk> wrote:
> 
>> I'm a bit of a tourist in this WG, so others will have to add detailed use-cases.  However the fact that you effectively have to abandon the signature as soon as a document enters an XML parser, seems an obvious massive downside.  You have to abandon the signature because it's axiomatic in any XML processing system that the serialisation -- the collection of angle brackets -- doesn't matter, so if it's the serialisation and not the content that you've signed, then you're going right against the grain.  Good engineering goes with the grain.
> 
> Broadly speaking I agree, but I'm pretty sure that others won't, and I can't articulate a good, practical use case which this would enable. I would love for another member of this WG to step up and demonstrate how this will enable science which would otherwise be impossible.

We're commissioning gonzo instruments at this end so everybody's distracted.  However, I don't believe the basic positions have changed since last we discussed this.  As early as the Trieste interop it was clear that there was little interest from any stakeholder in tightly coupling the signatures to the standard.  That being the case, one could imagine different implementations of signatures for different projects.

If loosely (and very imprecisely) one characterizes the two positions as engineers versus researchers, I would personally like to see VOEvent continue to walk the fence between the two.  Deployed systems must rely on - well - reliable technology.  But realizing future visionary goals (and few areas of observational astronomy are more visionary than the time domain) requires developing new visionary technology.

Nothing stops a particular project from signing a canonical version of an XML packet.  Nothing forbids signing a specific sequence of bytes.  As long as we don't specify that signatures must be embedded in the packets we can have our cake and eat it too.

Signing the serialization is naturally most similar to authenticating the transport layer.  Signing the content, to authenticating an archival copy.  Perhaps a particular broker or repository will flip the usage for their own purposes, but when passing a packet and signature on to another site we'll need some agreement on what should be passed.

Perhaps just include the flavors of signatures as another field in the registry?  And obviously if a broker receives a signature it can't handle it will either discard it or forward it on.  Whether it then contingently discards the now unauthenticated packet is a policy question for that particular stakeholder and its customers.

And not to put too fine a point on it, isn't this precisely a market economy?

Rob