Signing events

[John Swinbank]

Hi Bob,

Broadly speaking, I had two reservations while reading this note, and I'd certainly be glad of your comments on them. I should add that I've not actually tried implementing this myself: I hope to do so at some point soon, and may then either decide that my concerns were misplaced, or (perhaps!) run into some more concrete implementation difficulties.

First: I think it's worth considering exactly what needs to be signed. Your note describes a system which signs the physical bits-on-the-wire, which seems to me to be rather limiting. A more flexible system would sign the "infoset" – the data encoded in the XML document – without being dependent on the particular physical representation.

To give a concrete example, I think a perfectly reasonable usage model would for a broker (or other event processor) to deserialize a VOEvent into some non-XML representation (a database, JSON, etc) on receipt, and to reserialize it as XML on demand. However, unless that reserialized XML was bit-for-bit identical with the original, the signature would be invalidated, even though the infoset is unchanged.

I don't claim expertise on the XML-DSig system – my main reservation about that was it's mind-boggling complexity! – but my understanding is that it invokes canonicalization in an attempt to work around such issues. Your note claims "no canonicalization issues" as a feature, but I wonder if it's actually just ignoring the problem!

(I should add, by the way, that from my limited understanding the canonicalization approach taken by XML-DSig doesn't adequately address all aspects of this problem.)

Secondly: I'm a little worried by the necessity of spawning separate processes to handling signing and verification for each event received. I note your section 5.2 in which you indicate that sub-second signing and validation can be achieved on modest hardware, but I can't help but imagine the overhead here must be substantial. Have you considered how well this scales up to the multi-million-event future being predicted by LSST and SKA? While I certainly appreciate the merits of a system which works and we can start using today, I'd like to also take account of long-term viability before I start deploying anything in the field.

Related to the above: your note is, of course, based on open standards. However, are there any widely available implementations of those standards beyond GPG? Of course, there's nothing wrong with GPG, but I think it's fairly clear that it will never be available as a shared library that can be directly linked into VOEvent handling code. Is there a (free, reliable) "libOpenPGP" that we could use instead? That would certainly go a long way towards addressing my concerns. (As I understand it, GPGME provides a high level API as a shared library, but still ultimately forks GPG behind the scenes. I'm happy to be corrected on this, though.)

Cheers,

John

On 3 Mar 2012, at 03:20, rdenny at dc3.com wrote:

> John --
> 
> I would be interested in your "area of concern" for the digital signature scheme described in the IVOA Note http://www.ivoa.net/Documents/latest/VOEventDigiSig.html. It is implemented in Dakota and has worked well so far. 
> 
>  -- Bob
> 
> 
> On Jan 25, 2012, at 1:36, John Swinbank <swinbank at transientskp.org> wrote:
> 
>> Hello,
>> 
>> Thanks Rob & Bob for your comments!
>> 
>> As LOFAR gets nearer to implementing automatic response to TOOs, we're starting to consider the real nuts & bolts of the situation. One of the obvious questions is how can we be certain that the events we're responding to are real alerts from the facilities we're interested in, and not malicious or accidental forgeries. I'm not sure how likely forged events are, but it seems to be a possibility we should at least consider, given the potential disruption & expense they could cause.
>> 
>> Both of the solutions mooted seem broadly technically viable (although I have a couple of areas of concern about both), but it's disappointing to see no widespread community support yet. I guess that's something we need to work on…
>> 
>> Cheers,
>> 
>> John
>> 
>> 
>> On 24 Jan 2012, at 23:46, Rob Seaman wrote:
>> 
>>> Hi John,
>>> 
>>> I believe both remain valid points of view.  What the WG had decided - at least for v2.0 - was not to include explicit hooks for the signatures in the schema itself, but this shouldn't strongly impact any of the options.  Few of the many and varied transient alert projects have had strong immediate signing requirements.  Do you have a specific project need here?
>>> 
>>> Rob
>>> --
>>> 
>>> On Jan 24, 2012, at 6:18 AM, John Swinbank wrote:
>>> 
>>>> Dear all,
>>>> 
>>>> Forgive me ignorance,
>> 
>> (And my typing!)
>> 
>>>> but I'm trying to get up to speed on previous discussions about signing VOEvents. I've seen Bob Denny's proposal at <http://www.ivoa.net/Documents/latest/VOEventDigiSig.html> and Steve Allen's publication (Astron. Nach., 329, 298-300, 2008). Both of those are a few years old now, though, and I'm wondering if either of them have gained community support/acceptance or if they state of the art has moved on to something different.
>>>> 
>>>> I've had quick browse through the mailing list archives, but can't seen anything very conclusive. Any thoughts or references on current best practice?
>>>> 
>>>> Thanks!
>>>> 
>>>> John
>>> 
>> 
>> 
>>