David Shaw <dshaw(_at_)jabberwocky(_dot_)com> writes:
On Mon, Jun 16, 2003 at 10:36:58PM -0400, Derek Atkins wrote:
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.
I think Trevor was referring to Alice generating a brand new primary
signing key and encryption subkey, and then using the new primary to
self-sign Bob's signing subkey (or transform Bob's primary into a
subkey and self-sign that). Alice then is in posession of a key that
will correctly verify Bob's signatures, but someone encrypting to the
key will encrypt to Alice.
Alice can't issue signatures as Bob, but can attempt to claim existing
Bob signatures as her own.
Well, the obvious fix for this attack is to require all signing keys
to be authoritative. If we're going to allow signature subkeys (as
opposed to just encryption subkeys), then the self-signature on that
subkey should be a two-factor signature, requiring BOTH secret keys.
It was unclear from the proposed attack that this was using signature
sub-keys. I personally believe that signature subkeys are a bad idea,
but if the working group seems to feel otherwise I think we should put
some strong language about the pitfalls.
David
-derek
--
Derek Atkins 617-623-3745
derek(_at_)ihtfp(_dot_)com www.ihtfp.com
Computer and Internet Security Consultant