Trevor Perrin wrote:
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.
This illustrates a problem with signature subkeys. When a top-level key
is used to sign a message, it is also used to sign the encryption subkeys.
So your message is signed by the same key that said "use one of these
subkeys to encrypt to me". You have assurance in that case that you
are encrypting the reply to a key endorsed by the person who signed the
original message.
But with signature subkeys, there is no such guarantee. The subkey is
just dangling. It isn't making any statements about the other encryption
subkeys or the top-level master key. That is why this fraud works in
that case.
I seem to recall that many years ago we discussed this problem, or
something similar. We talked about requiring signature subkeys to
sign the top level key. That way the two keys, master key and subkey,
would each sign the other. They would in effect endorse each other as
belonging to the same key holder.
Doing this would eliminate your fraud, as there would be no signature
from Bob's "stolen" key on Alice's master key where she planted it.
This would indicate that the subkey did not belong there, hence that
the encryption subkeys didn't go with it.
Hal Finney