Signing events

John Swinbank swinbank at transientskp.org
Mon Mar 5 07:17:00 PST 2012


Dear all,

On 5 Mar 2012, at 15:01, Rob Seaman wrote:

> As far as planning, what do the various projects need and when do they need it?

For me, at least, that's a key question.

My close colleagues in the 4 Pi Sky project are *currently* using a VOEvent stream to automatically cause AMI <http://www.mrao.cam.ac.uk/telescopes/ami/> to follow up on events from Swift. I don't know the details of the route those events are taking to reach 4 Pi Sky, but the last hop is from voevent.dc3.com, which allows publishing "without restriction" – it would be fairly trivial for some miscreant (or just somebody who makes a mistake while testing) to inject a forged Swift VOEvent into the stream, causing us to trigger incorrectly.

How likely is that? I don't know, but it doesn't sound implausible. Consequences? Currently, it would be an embarrassment, but we're hoping to implement a similar (albeit more elaborate) system with LOFAR over the course of this year, and if it happens then it would be a *major* headache.

So what do we need, and when do we need it? We need to be sure that the events we receive are genuinely being issued by the facilities they claim, and we need it in ~6 months. (Hey, I can dream, right?). From my first reading, it sounds as though Bob's system pretty much already covers this (modulo deployment issues – is anybody using it except dc3.com?).

In the longer term, I can imagine a whole panoply of different uses for signed events, and that's the problem: if we deploy Bob's system now, does that damage our future prospects? If we follow a more complex scheme, is it going to hit a complexity wall – or, at least, take so long to mature that it can't meet our needs this year?

Cheers,

John


More information about the voevent mailing list