Re: PoP & Signer's User ID subpacket?2003-06-16 18:50:52
At 04:22 PM 6/16/2003 -0700, Hal Finney wrote:
How bad is it to make someone else think that a key is yours, when it actually is not? I.e. you have no idea what the private part is. [...] This could mean that a message signed by someone else might appear to be signed by you. But that's not so significant, as you could have achieved the same effect just by copying the plaintext of the message to be signed and signing it with one of your own keys.
If you have access to the plaintext - but if Bob sends Charlie a signed and encrypted message, and Charlie receives what looks like a signed and encrypted message from Alice, that's a neat trick on Alice's part, since she'll have effectively signed something she never saw.
For example, Charlie says "I'll give twenty bucks to whoever answers my riddle". Alice doesn't know the answer, but makes Bob's signed and encrypted answer appear to come from her.
Something similar: what if Alice's signature subkey belongs to a primary key that also has an encryption subkey? Suppose the signature subkey is really Bob's key, but the encryption subkey is legitimately Alice's. Then if Charlie receives a message signed by Bob's signature key and containing corroborating info, so Charlie is convinced it really came from Bob, Charlie might leap to the false conclusion that Alice's encryption public key is also associated with Bob. I.e.:
Bob emails Charlie and says "Hi, I'm your old friend Bob. Where did you bury that treasure we stole?" Charlie replies "If you're really Bob, what's our codeword? And send it to me signed and encrypted, so I'll know which public key is yours." So Bob does. But Alice now slips Charlie a primary key that has Bob's public key as a signing subkey, and Alice's public key as an encryption subkey. Charlie decrypts and verifies the message, and is satisfied that the owner of this primary key knows the codeword, and is "Bob". So he encrypts the treasure map to Alice's public key.
In the "riddle" case, Charlie assumed a relation between the signing key and Alice's name which Alice could falsify. In the "treasure" case, Charlie assumed a relation between the signing subkey and encryption subkey which Alice could falsify.
Before, I suggested adding the "Signer's User ID" subpacket into message signatures. This would work in the "riddle" case, where Alice falsifies the name, but not in the "treasure" case, where Alice falsifies the relation between subkeys. Maybe a message signature produced by a subkey should also contain a subpacket that gives the primary key ID, so an attacker can't present his primary key and someone else's subkey to verify someone else's signature. Haven't really thought this through, though..