The State of VOEvent

[Rob Seaman]

Hi Steve,

> On Fri 2008-06-06T14:23:22 -0700, Rob Seaman hath writ:
>> A) Authentication.  The sense of the WG in Trieste was that digital
>> signatures not be embedded within VOEvent packets themselves.  Two
>> distinct technologies have been proposed.  Each has already been
>> prototyped.  Now we need a coherent pilot project to carry one or  
>> both
>> of these forward in a VOEventNet-wide fashion.  There is no reason to
>> create a signature if nobody will later check it - this implies
>> support of one sort or another within our browsers.  Let's find a
>> middle road between racing forward willy-nilly on the one hand - and
>> doing nothing at all on the other.

I meant "broker", not "browser", of course.  I should hasten to add  
that no site should be required to perform authentication if they  
don't need it.  That said, I think we're going to all find that we  
need it except perhaps over communication channels completely within  
our firewalls.

> I wasn't at Trieste, but if I'm not mistaken the two technologies are
>
> 1) Detached Signatures within the scope of XML
>   a la the W3C Signature standard
>
> <VOEventSigWrapper>
> <VOEvent>[as per existing specs]</VOEvent>
> <Signature>[w3c sig content]</Signature>
> </VOEventSigWrapper>
>
> This is what was implemented at NVOSS 2005.
> It has the content in some sort of signed wrapper
> which implies that parties wishing to use it want to
> define the schema of the <VOEventSigWrapper> and that
> parties who don't care can just strip out the
> <VOEvent>s from inside the wrapper.
>
> 2) PGP signatures
>
> As described and implemented earlier this year by Bob Denny.

Yes and yes.  And perhaps some other technology will reveal itself.

The resolution at Trieste was that a VOEvent signature (or derived  
construct such as a certificate) must reside outside of the VOEvent  
packet itself.  If anybody wants an official vote on this point, speak  
up.  (It is likely that a signature could be wholly embedded within a  
<Description> anyway - but the standard is never going to describe  
such shenanigans.)

>> In addition, I'd also like to evaluate a lightweight checksum  
>> scheme for use within a packet, similar to the FITS Checksum  
>> convention.
>
> I remain unsure how this, or the PGP method, can work in XML because
>
> <Outer><Inner>content</Inner></Outer>
>
> is equivalent to
>
> <Outer>
> <Inner>content</Inner>
> </Outer>
>
> That is the point of the canonicalization algorithm used in W3C
> Signature -- that the content must first be rendered into canonical
> form, and then the checksum/hash algorithm is applied.

Indeed, and canonicalization formed the bulk of the discussion after  
Matthew's very nice presentation on both mechanisms.  We reached no  
conclusions, but the strong sense of the (relatively small) group in  
the room was that some canonical form was necessary whichever signing  
technology is used.

This may be a different question for the checksum, whose goal is more  
specific to the transport layer.  A reminder that the FITS Checksum is  
an ASCII-encoded variation of the 1's complement TCP/IP checksum.  A  
1's complement checksum can be embedded in a packet because it is  
computable and can be used to force each packet's checksum to zero  
(well, negative zero).  It protects an explicit stream of bytes, not a  
hierarchy of XML objects.

> Can all parties agree never to use any XML tools that reformat the
> elements in ways that are content idempotent but bitwise different?

Nope.  In a first-things-first way of looking at the problem, I think  
you have won this initial round even though you weren't in  
attendance :-)

> Are there tools that make that sort of guarantee?

As you already demonstrated, the W3C signature.  Is there some reason,  
however, that PGP can't be used to sign a canonical XML packet?  What  
are the strengths and weaknesses of that notion?

VOEvent remains transport neutral.  That being the case, there is  
nothing to keep a particular project from using any such transport  
level signing technology they want.  Our goal is to discover  
interoperability requirements, however.  One of these appears to be  
that our packets be canonicalizable.  (Is that a word?)  It seems  
likely that another requirement is that there be a single IVOA-wide  
signing scheme - certainly for VOEvent packets crossing project  
boundaries.  We'll be lucky enough to get folks to code to a single  
signing technology, let alone two such.

A solution responsive to these requirements might have a project using  
one signing technology internally, and have a boundary broker that  
translates (an interesting notion in its own right) incoming and  
outgoing signatures.  Revealing the requirements early will permit  
keeping such baroque solutions to a minimum.

VOEvent is an expression of content, not an expression of bytes.  This  
seems like a broader statement applicable to all XML within the VO.

Rob