[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PoP & Signer's User ID subpacket?
David Shaw <dshaw@xxxxxxxxxxxxxxx> writes:
> On Mon, Jun 16, 2003 at 10:36:58PM -0400, Derek Atkins wrote:
> >
> > Trevor Perrin <trevp@xxxxxxxxx> 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@xxxxxxxxx www.ihtfp.com
Computer and Internet Security Consultant