Trevor Perrin <trevp(_at_)trevp(_dot_)net> writes:
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.
Except that Alice's subkey wouldn't have a self-signature by Bob's
primary key, so it shouldn't be accepted by Charlie as a valid subkey.
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.
Except Alice cannot falsify without the help of Bob. Why would
bob sign Alice's subkey as her own?
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..
Without a self-signature on the subkey, how would ie be accepted
as valid?
Trevor
-derek
--
Derek Atkins 617-623-3745
derek(_at_)ihtfp(_dot_)com www.ihtfp.com
Computer and Internet Security Consultant