Re: PoP & Signer's User ID subpacket?

[Trevor Perrin <trevp@xxxxxxxxx>]

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

Trevor