Cryptographic authentication of VOEvents

[John Swinbank]

Hey Rob,

I agree quite strongly with all of the below.

I'm hoping that when LOFAR starts broadcasting signed events, we can do so in such a way that best satisfies the needs of you, Norman, Alasdair, Roy, Bob, and the rest of the community.

Similarly, when LOFAR starts receiving signed events, I'm hoping to minimize the amount of effort I have to invest in interoperating will a multitude of different systems.

Hence, I'm keenly interested in the suggestions of the community as to how to best serve all their needs, and, when we roll out our system, we'll do our best to satisfy as many requirements as possible. 

Ultimately, though, we will not be waiting for a consensus from this mailing list before deploying (although if one were to emerge, it would make my job easier!); as you suggest, it will be up to the marketplace to determine if we get it right.

Cheers,

John

On 12 Sep 2012, at 17:31, Rob Seaman <seaman at noao.edu> wrote:

> Precisely.  It's market driven.  Those wanting to trust your events will implement a validator that does whatever you do.  Those wanting you to trust (and follow-up) their events will feed you whatever you specify as necessary to get your attention.
> 
> This is a great and useful discussion, but it is outside the standard and corresponds to one or more notes (or references to external documents).
> 
> The major surveys and the gatekeepers to robotic and human-mediated follow-up telescopes (and potentially computational assets of other sorts) comprise a "here's what I've got" and "here's what I need" matrix.  Currently (and likely for some time into the future) both axes are unauthenticated and this discussion is moot for those assets.  Trust is then at the discretion of the consumer; let the buyer beware.
> 
> It sounds like several important stakeholders are interested in authentication.  They (you) may reach consensus or you may go your own ways.  We likely all prefer the former, but some projects may well make alternate choices if the advantage appears large enough.  It's then a question of whether supporting a couple of different flavors (likely by linking against library routines) is a heinous requirement to be rejected out of hand.
> 
> Commercial vendors in related fields do this all the time.  A wifi connection is a negotiation between many different protocols.  Cell phones and land lines interoperate.  Even paper mail uses zip codes and zip+4 interchangeably.
> 
> Choice of signing paradigm is not an ethical quandary :-)
> 
> Rob
> --
> 
> On Sep 12, 2012, at 8:07 AM, John Swinbank wrote:
> 
>> On 12 Sep 2012, at 16:54, Rob Seaman <seaman at noao.edu> wrote:
>> 
>>> Nothing stops a particular project from signing a canonical version of an XML packet.  Nothing forbids signing a specific sequence of bytes.  As long as we don't specify that signatures must be embedded in the packets we can have our cake and eat it too.
>> 
>> Until, presumably, we want to interoperate with each other.
>> 
>> To be personal (or egocentric?) for a moment, when LOFAR starts publishing VOEvents ("real soon now", etc), we want to cryptographically sign them. (And, conversely, we won't trigger on a VOEvent if we aren't confident of its authenticity.)
>> 
>> When we sign those events, we want to do so in a way that's of the greatest possible value to the community. If there's a clearly articulated reason why signing an opaque bitstream is of less value to the community, we won't do that. Similarly, if added complexity due to normalization, or philosophical differences about what "ought" to be signed, makes it harder for others to accept our events, we won't do that.
>> 
>> But we will do something, and, once we start doing it, it'll be hard for us to change to another system. And we'll do it now (well, soon), not in a(nother) decade.
>> 
>> Cheers,
>> 
>> John
>