Signing events

[Roy Williams]

Yes I too have been thinking quite a bit about security -- as John 
points out, we don't want just anyone publishing spam! Here are the models:

(a) signing the bits of the event.
(b) signing the "information content" of the event.
(c) verifying the identity of the publisher.
(d) verifying the IP address of the publisher.

As John notes, the problem with (a) is its brittle nature. For example, 
the iPhone app for CRTS events has its own Skyalert server at lsst.org; 
when it receives an event from skyalert.org, it grabs all the images 
(URL at caltech.edu) and copies them, then changes the links in the 
event to lsst.org. Now the bits are different, but the infoset is the 
same. Similarly, the 10^8 LSST events will have links back to a deep and 
massive and slow archive, but the most popular 10^2 LSST events will 
actually be hosted elsewhere with links to a smaller faster cache.

Skyalert takes approach (c), trying to verify the identity of the 
publisher. And I recall there is something like (d) with GCN (?) where 
the IP address is used as an implicit identity for providers. Certainly 
LIGO used mechanism (d) for trigger release during the last science run. 
The advantage of this approach is that the identity can be established 
at the beginning of a session, and 10^8 events exchanged wihtout the 
overhead of verification for each one. It also allows information to be 
sent in other formats (eg a tar file of 10^8 events), or the JSON 
serialization of VOEvent.

There are other functions of a mature event network that we might 
consider when deciding on a security mechanism. An event repository and 
the queries on that might need security (private events and/or big 
queries). In this case signing events does not help, rather we need an 
identity for the person making the query.

What would be really nice would be a way to have "sideband information" 
in vTCP, a way to send something in addition to the VOEvent. The 
sideband could contain authentication, observing instructions, a URL for 
the event -- all the information that, for one reason or another, is not 
in the VOEvent itself. This would make vTCP much more flexible and useful.

Roy

---
Caltech LIGO
roy at caltech.edu
626 395 3670