Cryptographic authentication of VOEvents

[John Swinbank]

Hi Norman,

On 10 Sep 2012, at 02:19, Norman Gray <norman at astro.gla.ac.uk> wrote:
> 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.

This now lives at <http://comet.readthedocs.org/en/latest/appendix/VOEvent-OpenPGP.html>; apologies for the changing URL. Anybody who doesn't fancy wading through my text to find it might want to skip directly at Gutmann's document at <http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt>.

> 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'm a little on the fence about this. On general principle, I agree; however, I've seen few really convincing examples of what those hassles might be. I note the examples in your document ("if you want to do anything with the XML… [or] round-trip [it] into a system which doesn't know about your signature"), and find them somewhat persuasive but not compelling.

I'd be genuinely interested in a real-world application where regarding the VOEvent as an opaque bitstream to be signed causes serious problems.

[…]

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

As a relative XML neophyte, I find this really interesting. I do have a dumb question, though: the answer is probably obvious to those better schooled in the ways of XML than I.

We're told that the complexity of the XML infoset is what makes it hard to canonicalize. However, you suggest that this ESIS model overcomes these problems, presenting a bytestream which can be easily normalized. This sounds great, but: if the ESIS model provides an adequate representation of the document for signing, why hasn't it been adopted for XML-DSig?

If, on the other hand, ESIS provides a good representation of a "simple" document like a VOEvent but isn't applicable in the more general case, can we be confident that it will provide an adequate representation of all future VOEvents? Versions 3, 4, … N, etc.

[…]

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

For me, implementation issues would be key.

In particular, I'm worried about barrier-to-entry. Signing a bucket o' bytes has the advantage of simplicity; XML-DSig has the advantage of the W3C behind it, and consequent (presumed, at least) legitimacy and library support. This has neither: we're effectively saying to implementers that they will have to build their own canonicalization system. That might be straightforward to those who already know what they're doing (and I certainly take note of your Java implementation), but it's enough to make me blanche.

[…]

> I hope this is interesting!

Definitely.

Cheers,

John