Alternate proposal for digital signatures

[Rob Seaman]

Steve says:

>> We're not doing international banking or espionage

These don't simply describe different levels of security needed, but  
entirely different use cases - for example, different cadences and  
budgets.  The point of cost requirements isn't just whether one  
community can afford more protection, but rather, what fraction of the  
total budget available should be assigned to one bit of functionality  
versus another.  For banking, security is a keystone requirement -  
banks employ vast security divisions.  For espionage, the "actors" may  
better rely on cheap steganography since obscuring the entire  
existence of traffic is more important than the content (which is  
often already in the possession of both parties).

In our case we have no need for a significant security budget - which  
is good, because we also have no likelihood of this.  Rather, what we  
have to budget for is the transport overhead of the trust model.  If  
the overhead of creating and repeatedly verifying the signature is too  
large, users won't use them.  Private circuits as envisioned for Pan- 
STARRS will be used for authentication, not just privacy.

Bob replies to Steve:

>> 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.

We need to explore the architecture of VOEvent authentication before  
focussing on the technology choice(s).  For instance, will we permit/ 
encourage more than one signature on a packet?

The roles of author and publisher are separate by design.  A VOEvent  
packet is truly a publication in both the computer science and  
academic sense.  The author is responsible for content - the publisher  
for the integrity of the packet.  The/a frequent use case would have a  
publisher supplying an authoring application to some class of authors  
- for instance, AAVSO as publisher encouraging amateur astronomers to  
download a desktop or browser app that is preconfigured to transport  
content from filling in a form to a known AAVSO-controlled VOEvent  
broker.

A transport signature may be attached between the client and the  
broker to protect the initial content - if the client runs in a web  
browser, browser level security would be an obvious choice.  This  
initial content will not typically reflect a VOEvent compliant packet,  
however, because it is the publisher who assigns an ID and guarantees  
conformance to the schema.

The first "official" signature is therefore only possible at the point  
of publication.  It seems to me that this first VOEvent-compliant  
signature would supersede any purely transport authentication used  
between author(s) and publisher.  Later brokers ("aggregators") might  
also attach signatures (assuming we allow this) - these later  
signatures might be to the same canonical text, or might be to  
additional or subset content.  I suspect we'll select an architecture  
that simplifies this potential source of headaches, but first we have  
to explore the range of reasons subsequent brokers might need to sign  
content.

Finally, of course, VOEvent includes its own citation mechanism that  
is designed such that the original content need not change in order  
for the observational thread (http://arxiv.org/pdf/0802.0262) to evolve.

>> 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.

Not partial messages (perhaps not even VOEvent-like in format), rather  
the members create content and the AAVSO publishes the first fully  
VOEvent-compliant packet with unique ID and persistent signature.

We are building a system to manage trust models.  We're not seeking to  
impose one such on everybody.  AAVSO trusts its members, likely in  
some multi-level fashion.  NOAO will have some different trust model,  
because its users are professionals, not amateurs - but more  
importantly, because we've spent 50 years polishing our community  
driven, competitively awarded time allocation procedures.  AAVSO has  
spent 97 years polishing a very different set of procedures.  VOEvent  
isn't going to swoop in at the end and change how these organizations  
do business.

NOAO's model is multi-level, too - not because of differing amounts of  
earned trust, but because we have different classes of proposals that  
are managed by different interlocking TACs.  A survey team like  
ESSENCE might self-publish in some fashion.  A target-of-opportunity  
proposal would be required to use VOEvent-aware tools preconfigured  
for receiving filtered transient alerts and for authoring the  
resulting follow-up packets.

>> 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.

I think we need to characterize the problem before we settle on a  
solution.  Prototypes can inform our understanding of the problem, but  
shouldn't constrain the ultimate solution space.

>> 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?

Right, although the transform can also excise original content.  We  
should be careful to understand how this all relates to the VOEvent  
citation architecture.  I tend to believe that under most use cases  
the original packet will remain intact and any changes will appear  
explicitly as citations.

The basic issue is as with the FITS checksum (an ASCII encoding of a  
1's complement checksum as used in TCP/IP packets).  Adding a checksum  
to a message changes the checksum of the message.  The 1's complement  
checksum is (re)computable, however, and a value is chosen to zero the  
checksum of the packet (or FITS file).  A message digest (a secure  
hash as used with a digital signature) is designed to be non- 
recomputable and thus can never be embedded in a message.

It is this same feature, however, that permits the message digest and  
the cryptographic key used to sign it to be maintained separately from  
the message while still providing authentication.  The signature can  
be stuffed into a mayonnaise jar under Funk and Wagnall's porch and  
the secure hash will later permit reattaching (in effect) the  
signature to the original message.

So the signature can be attached to the envelope (as with Bob's  
prototype) or be inserted within the body of the message using a  
surgically inert XPath transform (as with Steve) or could be added as  
a requirement to VOEvent repositories maintained by our broker/ 
publishers or could be promoted out of VOEvent entirely and be added  
(for instance) to the VO resource registries.

My own predilection is to select one of the simpler of these options.   
The choice depends again on VOEvent usage and the transport/query  
architecture.

> 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?

Commenting conventions (e.g., Encapsulated PostScript) are useful to  
introduce new features into static standards, particularly when  
extending functionality to new levels.  VOEvent has not (yet)  
(d)evolved into stasis, and authentication should reasonably be  
regarded as a core capability of the standard.  As was mentioned,  
larger VO standards may also come into play (but only if they actually  
work in practice :-)

I think the underlying architectural questions come down to whether  
the authentication is part of the content or of its transport, that  
is, part of the message or of an envelope.  I think this then pivots  
on whether this aspect of the design is more archival in nature or  
more of a reflection of the courier service analogy.  FedEx and UPS  
provide parcel tracking services.  Is authentication part of VOEvent  
tracking?  When user receives a packet, they can't establish trust in  
any standalone fashion - key exchange is needed to extend the trust  
from the publisher.  Will our architecture assume that key exchange  
happens in some unspecified (and asynchronous) way?  Or having  
received a packet is it up to the subscriber to conduct a tracking  
transaction to verify the packet (or rather, its secure hash)?

>> 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.

And the system engineering is in calibrating that instinct.

Rob