ietf-openpgp
[Top] [All Lists]

Re: Back-signatures, part II

2003-10-29 13:13:08

On Tue, Oct 28, 2003 at 10:59:31PM -0800, Trevor Perrin wrote:

 - A naive user re-uses the same subkey under 2 different primary
keys.  Signatures performed by the subkey can't be confined to
being under one or the other primary key.  This problem can be
easily avoided: just don't re-use keys, but that caveat would be
unnecessary if signatures committed to their enclosing context.

I don't see this as a problem, actually.  So what if a user uses the
same subkey under two different primaries?  The user controls the
subkey, and so can issue valid back-signatures (or fingerprint
subpackets).  The owner of a subkey can do what they like with it.

The problem arises when the user signs a document with the subkey, and 
wants this signature to be under one of his particular primaries.  Say he 
has Work and Personal primary keys.  He signs something and wants to 
indicate that it's under his Work primary key.

A user can "legally" use the same subkey under two different
primaries.  I think this is more of a feature request than an attack.

The include-the-primary-fingerprint fix for the original attack has a
side effect that gives the information you want here, but I still
don't think this is an attack on the system.

I.e.: a user who receives a signed message through some secure channel (say 
someone hands them a message on a floppy disk), might then retrieve a key 
through an *un*secure channel, and attempt to validate the key by verifying 
the message with it.

You can say: the user screwed up, we can't help him.  But if the signature 
covered the public key that produced it, then the user's naive assumption 
would be correct, and his behavior would be safe.

The issuer key ID subpacket makes an attack hard, though, because the 
attacker would have to try ~ 2^64 trial keys that verify the signature, 
before discovering one that *also* has the right issuer key ID.  But if the 
signature covered the public key with a full hash, an attack would be even 
harder.

Note that most implementations do not store the issuer key ID in the
hashed portion of the signature.  The issuer ID is thus not part of
the signature.

David