Alternate proposal for digital signatures

[Bob Denny]

Steve A:
> Those are enough.  We're not doing international banking or espionage

OK thanks. That eases one concern.

Me:
> And does RFC 4880[1] specify a system that is worthy of becoming part of a 
> VOEvent standard?
Steve:
> Yes, if we don't choose an XML-native solution.

Excellent.

Me:
> And beyond any signature scheme, PGP/GPG or not. This is a tough one... But
> do we really *need* to couple [the VOEvent message and signature info]
> together?
Steve:
> It depends on the usage analysis that we really have not done.

I'll offer my thoughts as of now ... strong use-cases could change my views
(absent other solutions).

> Are VOEvent packets always atomic?  Do they never get modified from the point
> that they initially leave the first creator?

I'd be uneasy knowing that my messages could be modified in transit. The message
is a statement by me, maybe signed by me, and then what? Someone adds or deletes
'stuff' after I send it? This seems wrong. To me a major reason for me signing
my messages is to _prevent_ changes in transit.

> Do we expect AAVSO members to generate partial versions which are then 
> further padded out by the AAVSO machinery before it submits them to the
> VOEvent pipelines?

Why would they generate partial messages? For lack of the right tool? In that
case, it seems to me that the point of solution is there and not in making the
VOEvent system more complex.

> Do we expect that a relaying or archiving system will want to insert any sort
> of additional unique identifiers or "I saw this" elements?

I can see a relay or archiver adding info, but in the XML comments between
<?xml...> and the beginning of the sigheader. Trace/archive info (e.g.) could be
useful, but it is completely outside the semantic domain of the VOEvent message
itself, so insert it outside the VOEvent root node as comments. Although an XML
document can have only one root node, a separate "hidden" XML (e.g.) trace-info
document could appear in comments, and later extracted by a knowing receiver.
I'd lean toward simple text lines though. Same for archiver metadata.

> If there is any modification of the VOEvent itself then the XML scheme
> allows for the signatures to remain valid because an agent can rewrite
> the Transform Algorithm (in my scheme currently just an XPath which
> excludes all Signature elements) without invalidating the Signature
> of the material which existed at the point of the Signature.

I think I understand, but I am not very familiar with XML Signature, so this may
be off base. If changes are made, they cannot not be made to the 'material that
existed at the point of the Signature' or the signature as guarantee of
integrity would be useless. So we're talking about _additions_ to the VOEvent -
am I right? And the additional signatures cover both the original material, its
signature, and the additions, sealing them as a unit?

If I have this right, then the additional material could be added externally to
the VOEvent as above, and re-signed with an outer signature, all in comments. Is
this easier or more difficult than dealing with XML Signature?

> The alternative is to do all of this archival manipulation externally
> to the VOEvent, and that may mean setting up standards and
> implementing systems which are not necessarily describable by XML.

Yes, that's what I was getting at (except it wouldn't _need_ to be describable
by XML). And yes, it would require additional standards (as would my original
proposal). But my instinct says that's better than requiring n number of
programmers to implement something that, in detail, may be more complex. It's
analogous to the old saw "more programmer work = less user work" only in this
case it's "more standards work = less programmer work". And if this is to be
widely deployed, there'll be a lot more programmers than standards authors.

> It's an engineering tradeoff that's hard to make prior to some
> "interop"erational experimenting.

Absolutely! Working models, preferably doing production things, produce info
that can greatly help tip the scales. I'm a big believer in having a working
production implementation of something before it goes to standard.
Design-and-decree is a road littered with failures.

  -- Bob