Signature semantics (was Re: Anyone know what became of the Gaim-E Project?)

[David Shaw]

On Mon, Nov 03, 2008 at 05:23:32PM +0100, David Pic?n ?lvarez wrote:
> As far as I'm concerned signature semantics are indeed a bit problematic, 
> not the least reason being that it isn't really the user who signs, but a 
> piece of software, ideally by the agency of the user, but in actuality 
> this is in itself hard to verify. I think an idea is that digital 
> signatures should rather be regarded as seals, like in the ancient days 
> when documents were authenticated that way. The reason I think this is a 
> better metaphor is it follows more closely the reality of digital 
> signing: it authentifies that the document passed through the hands of 
> the seal-holder, but was not necessarily authored by them; it gives a 
> clear feel of what happens when you lose your privkey (same as when you 
> lose a seal, anyone can seal with it); and it detaches the idea of 
> signing (which often implies active consent) from sealing (which is more 
> like a mechanical act), which is good because a digital seal can end up 
> there by accident (for instance if someone does not compromise your keys 
> but compromises your mail client, they might be able to get you to send 
> something with your seal).

OpenPGP (properly) does not get very involved in the meaning of a
signature.  Regular signatures, in fact, are defined in RFC-4880 as
"This means the signer owns it, created it, or certifies that it has
not been modified." which is fairly wide open to whatever meaning
anyone wants to apply to it (that's a feature, not a bug).

> Where I have a difference is in the I love you example. Clearly you could 
> send the unsealed data (plaintext, whatever) to someone else and end up 
> in trouble, but the reasonable thing to do would be to send the document 
> sealed by the original sender, as you received it, same as when you 
> forward an e-mail the headers are on top indicating it does not come from 
> you, so the example is, I think, a bit contrived and inapplicable.

The problem with a seal or a signature that it doesn't say anything
about the intended recipient of the message.  It's very easy for
someone to forward the message elsewhere as a man-in-the-middle.  An
example using OpenPGP in particular: Alice sends Baker the signed "I
love you" message.  Baker then forwards it to his rival Charlie.
Charlie sees a signed message from Alice, without any indication that
he is not the real recipient, and proceeds to make a fool of himself.

Encryption doesn't help this situation as (in most cryptosystems), the
encryption is a wrapper around the signature.  So Alice creates this:

  "I love you"

and signs it:

  Alice_sign( "I love you" )

now encrypts it to Baker:

  Encrypt_Baker( Alice_sign( "I love you" ) )

Baker gets it, and decrypts it:

  Alice_sign( "I love you" )

Then encrypts it again to Charlie:

  Encrypt_Charlie( Alice_sign( "I love you" ) )

One lesson that can be learned from this is that the signed portion of
a message should contain sufficient context so that the message cannot
be repurposed in this fashion.  Also, Alice should know better than to
trust Baker.  The cad.

David