The State of VOEvent

[Rob Seaman]

Hi Bob, et. al.,

> Section 1 of this document may be of interest:
>
> http://www.uddi.org/pubs/SchemaCentricCanonicalization.htm

Interesting indeed.  I'm concerned to realize that there is, in fact,  
no general XML canonicalization at all, but rather DTD or Schema based  
canonicalization.  The VO is a Schema shop, so we need to take this  
into account.  Given the age of the various documents, I'm also  
beginning to wonder if we've yet tapped into the state of the art here.

 From the description it sounds like most of the issues are related to  
fairly esoteric XML usage.  Perhaps folks could review both this  
document and the W3C signature doc and see what VOEvent specific  
issues might be lurking.  That is, I guess I'm not that concerned to  
hear that:

	"Canonical XML contains a (pragmatically minor) security hole having  
to do with how it processes certain esoteric node-sets."

We want:

1) to reliably authenticate VOEvent packets, and

2) to permit VOEvent usage that benefits from modern, evolving, XML  
tools.

...which is to say that I simply don't see how we can assume that we  
will sign a raw packet only.  Intervening links in the workflow may  
well reformat the XML, making the packet different than the one  
originally signed.  How then do we deal with this as simply and  
reliably as possible?

Another way to look at this is that the whole point is to increase the  
trustworthiness of our systems and of the data conveyed.  There is  
some trade-off between the reliability of signing and the complexity  
and efficiency of generating and evaluating signatures.  If a small  
fraction of packets are unsignable for esoteric reasons, that may be  
more acceptable than adopting a highly complex technology to render  
these few technically signable, but calling into question pragmatic  
VOEvent authentication for all packets.

And surely we will vet both signed and unsigned event streams for  
proper convenance through the VOEvent network as it evolves?  Any  
intervening relay that corrupts a packet should be corrected, not  
force all packets to be rewritten.

Anyway, we're doing something wrong if key management isn't our  
biggest issue :-)

Rob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20080611/e0c363fb/attachment-0001.html>