Cryptographic authentication of VOEvents

[Norman Gray]

John and all, greetings.

On 2012 Aug 9, at 06:48, John Swinbank wrote:

> I have written up my thoughts in some detail here
> 
>  https://github.com/jdswinbank/Comet/blob/master/docs/VOEvent-OpenPGP.rst
> 
> and I would appreciate your comments on them.

That's an interesting document (though it was producing a 404 last time I looked); thanks also for the pointer to Peter Gutmann's remarks.

I can't help feeling, however, that the suggested practice of simply signing the serialised XML document, as a binary blob, is a little ... unambitious, and will lead to hassles later.  I think it's possible to do better, cheaply, and I describe how below.

Gutmann's main point, I think, is that there is a fundamental disconnect between the flexibility of XML and the requirement that signing mechanisms can really only sign a binary blob.  That leads to the conclusion that signing the serialised XML (that is, the stuff from the wire or on disk, with the angle-brackets and quotes and everything) is the _only_ thing to do.  That's a huge overreaction, I believe.

The underlying problem, of course, is that a given XML document is one of a large-ish class of XML serialisations which are 'equivalent' in meaning: it would be useful to be able to change att='value' to att="value" and have the signature remain valid.  The XML Canonicalisation and signature work is (a) an algorithm to turn a random XML document into a canonical representation, and (b) specify how to include a signature in that, both with all-web generality, and including various (barely relevant) bits of lexical information in the canonicalisation.

That's a hard task, because it's monumentally fiddly, and because it faces exactly the sort of streaming problems that Gutmann describes.

BUT: VOEvent doesn't have to solve the general problem.  It only has to solve the limited problem of signing VOEvent files, with PGP.

Given that, it's suddenly _easy_ to define a normalisation of a VOEvent, and _easy_ to define how to include a signature within that.

That 'easy' is easy to say (and I and others have I think said it in the past), but it turns out to be pretty easy to demonstrate, too.

See: http://www.astro.gla.ac.uk/users/norman/ivoa/voevent-signing/

This is a definition of a simple normalisation algorithm for XML documents (including VOEvent), and a Java library which implements both this normalisation and the mechanism for signing events.  This signature mechanism is resistant to syntactically substantial but semantically irrelevant changes to the XML (for example it doesn't care about quotes, or various whitespace transformations).  Therefore the signatures should remain valid after a document has been through an XSLT identity transformation (for example) or into and out of an XML database.

Implementation note: I've done this in Java because I'm already familiar with the relevant support there.  The normalisation process is inspired by the information made available by the (Java) SAX interface.  However 'SAX' information isn't unique to Java, and the process is not specific to Java, but could be implemented in any other language.  If I recall correctly, Xalan is in C and has a similar SAX-like interface already (I can't check that right now, but almost any language's streaming interface to XML would have something very like SAX).

I haven't tuned this implementation, or tested it for performance, but if there's interest in it I'd be very happy to do so.

> I'll add a similar disclaimer as to my last mail – I don't for a moment believe that this proposal represents the be-all and end-all of VOEvent authentication schemes. However, while blue-skies discussion is always fun, I'm hoping to arrive at a "good enough" solution that we can start deploying in the real world within months rather than years and with relatively modest investment of developer time.

I think this is an admirable goal; +1 from me.

However I do believe that treating XML as a binary blob is asking for trouble down the line -- I claim that this isn't 'good enough'.  The fact that I can demonstrate an implementation here illustrates that a more flexible signing mechanism isn't just blue-skies discussion.

I hope this is interesting!  (if anyone else here is going to be at Astroinformatics 2012 in Redmond next week, we can talk about this more).

All the best,

Norman


-- 
Norman Gray  :  http://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK