Signing events

[John Swinbank]

Hi Bob,

On 6 Mar 2012, at 01:16, Bob Denny wrote:

> You said:
>> 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?
> Of course, as Norm points out (and as have others before him over 6 years) there are all of the old objections like "what if we rip apart the message and normalize it, and store it in a mapped database, or run it through a DOM, blah blah, and then later reconstruct it in a normalized form, and..." Feel free to chase your collective tails for another 6 years. 

This is exactly what worries me.

On the other hand, if we – you and I, for the sake of argument -- put aside those objections and press ahead with using your system now, but the rest of the community is scared off by the objections, we're also not actually achieving much.

> Meanwhile, if you are OK with the VOEvent message not being altered (which after all seems to be the whole idea to me), and if you are OK with using PROVEN/VETTED security tools (GPG/PGP) which are widely understood/accepted and which do not require expensive or untrusted (and difficult to manage) X.509 certs, and and and... No libraries. Just a command line executable. I'm waiting for the "scalability card" to be pulled next :-)) The DigiSig option of the Transport 1.1 spec provides publisher authentication and message integrity. The logic needed is trivial as shown by the simple perl scripts that are published in the Transport 1.1 IVOA Note. If you haven't looked at it, it might be nice to do so.

I think I already pulled the scalability card, actually… :-)

For what it's worth, my current intention is to experiment with my own implementation of your PGP-based system and see how well it works for me in practice (I realise you already report success with Dakota, but I am a great believer in learning-by-doing). I continue to be worried about the compromises it entails, though, and eagerly hope that an alternative will emerge which addresses them.

> And are we ever going to stop calling Transport "vTCP" or "vanilla" or ??? which is not indicative of the particular spec ("Handshake" or "IVOA Note", significant differences!) and elicits the type of question to which Alasdair just responded, and which comes from those who just don't want to learn the details about it?

I'm not well versed in the history here; sorry. I suspect I've used the term vTCP in the past, and apologise if it's not to your taste. If you can suggest an alternative – preferably one that (a) doesn't occupy many more characters, (b) is unambiguous (there are many IVOA notes!) and (c) doesn't imply canonicity (there are multiple VOEvent transport systems in use) – I for one will be happy to adopt that instead.

Cheers,

John