Signing events

[Norman Gray]

Greetings, all.

Permit me to chip in here.

On 2012 Mar 5, at 10:31, John Swinbank wrote:

> First: I think it's worth considering exactly what needs to be signed. Your note describes a system which signs the physical bits-on-the-wire, which seems to me to be rather limiting. A more flexible system would sign the "infoset" – the data encoded in the XML document – without being dependent on the particular physical representation.

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.

Of course, in each case it would be possible to _make_ it work, by very carefully preserving comments, and whitespace, and by being precise about subsequent serialisation, but in each case it's going against the grain, so will be fragile.

> I don't claim expertise on the XML-DSig system – my main reservation about that was it's mind-boggling complexity! – but my understanding is that it invokes canonicalization in an attempt to work around such issues. Your note claims "no canonicalization issues" as a feature, but I wonder if it's actually just ignoring the problem!
> 
> (I should add, by the way, that from my limited understanding the canonicalization approach taken by XML-DSig doesn't adequately address all aspects of this problem.)

I don't claim expertise on the XML-DSig work, but my understanding, from the last time I studied this, was that the hard bit was the canonicalisation step <http://www.w3.org/TR/xml-c14n>.

However, the canonicalisation process is complicated because it is trying to address the general problem, with most of the complication involved with whitespace processing.  Similarly, the complications of the XML-DSig signing process are concerned with including the signature element in a general XML document.

What that means is that in a particular domain -- for example the domain of VOEvent packets -- most of the complications disappear.  If I recall correctly, the VOEvent packet has little or no mixed content, does not use XML namespaces, appears to require that the document is in UTF-8 (and the document will probably be in ASCII most of the time), and will not typically have a DTD (so there will be no non-standard entities).  That leaves little or no canonicalisation left to do.

An alternative would be to skip the standard canonicalisation and define a canonicalisation within the VOEvent spec (it might for example omit all whitespace in certain elements).  Defining a canonicalisation of the abstract form of a VOEvent packet, and defining a signature element which sits at the end of the packet, would allow the generation and validation of signatures to happen in stream processing.

> Related to the above: your note is, of course, based on open standards. However, are there any widely available implementations of those standards beyond GPG? Of course, there's nothing wrong with GPG, but I think it's fairly clear that it will never be available as a shared library that can be directly linked into VOEvent handling code. Is there a (free, reliable) "libOpenPGP" that we could use instead? That would certainly go a long way towards addressing my concerns. (As I understand it, GPGME provides a high level API as a shared library, but still ultimately forks GPG behind the scenes. I'm happy to be corrected on this, though.)

I believe there's some effort to make a library version of GPG, but it seems that the gnupg maintainers don't approve <http://www.gnupg.org/faq/GnuPG-FAQ.html#cant-we-have-a-gpg-library>

X.509 signatures are a reasonable alternative.  X.509 has a very bad reputation for horrendous usability (I bear the scars), but it _is_ good in parts, and my own experience has been that the hideousness is to some extent confined to the UIs, and to searching for keys, and that despite these problems the available APIs (for example the JDK interface) aren't too bad.  I'm not necessarily pushing X.509, but I think it's important not to discount it for the wrong reasons.

All the best,

Norman


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