back signatures

David Shaw dshaw at jabberwocky.com
Thu Nov 10 21:24:34 CET 2005


On Thu, Nov 10, 2005 at 09:00:56PM +0100, Christoph Anton Mitterer wrote:
> David Shaw wrote:
> 
> >>And what is the "theory" behind them,... e.g. how do they improve 
> >>security?
> >>   
> >>
> >Current signing subkeys have a weakness in that they can be moved from
> >one key to another without the key owner's approval.
> >
> >This means that if I sign a message with a signing subkey, someone
> >else can lift the (public) signing subkey off of my key, attach it to
> >theirs, and issue a new binding signature for it.  This person can
> >then claim to be the person who signed the message.
> > 
> >
> Ah,... I see,.. but is this problem only limited to signing subkeys? It 
> should be, right? Because the primary is protected by the selfsigned 
> user id? Or is there another reason? (just want to check if I'm slowly 
> understand how all these things work :-D )

Not exactly.  The problem is limited to signing subkeys because
identity is attached to the primary key.  When you make a signature
with your primary key, you're saying "key XXXX made this signature,
and key XXXX is owned by Joe Smith".  When you make a signature with a
signing subkey, you're saying "key XXXX made this signature, and key
XXXX is owned by key YYYY and key YYYY is owned by Joe Smith".

The problem is that only key YYYY (the primary) asserts ownership of
key XXXX (the signing subkey), which means that ZZZZ (someone elses
primary) can come along and also assert ownership of XXXX.  The fix
("back signatures") is to have XXXX assert posession by YYYY.  This
foils ZZZZ since she cannot issue a signature from XXXX.

> btw: You remember my C-only thread (I'll answer you lastest posts 
> soon),... I played around a bit and read some parts of rfc2440.
> Ok when I split a key using gpgsplit I get about the following:
> pubkey
> uid
> selfsig on uid (Sig type - Positive certification of a User ID and 
> Public Key packet(0x13))
> subkey
> selfsig on subkey (Sig type - Subkey Binding Signature(0x18))
> 
> Ok,.. the 0x18 signature ist the one that binds the sub to the primary.
> =>so nobody can add his own subkey to my primary because he wouldn't be 
> able to make a subkey binding sig, correct?

Right.

> =>but he is able do take my subkey and remove my 0x18 and add his one 
> (that is where your back sig come into the game, correct?)

Right.

> Is it correct that the primary has not directly a single self sig 
> packet, but rather 0x13s are used therefor? If so,.. what is 0x1F 
> (signature direct on key) used for? I thought this is used for primary 
> selfsigs.

No, 0x13 (or 0x10, 0x11, 0x12) are used to sign a user ID and primary
key together.  Historically, people call this "signing a key", but
it's really signing a user ID + key.

0x1F signatures are truly signing a key alone.

> >Note that this person doesn't have the secret key or the passphrase -
> >they can't issue NEW signatures.  They can only claim to be the signer
> >for existing signatures.  They also can't stop the original signer
> >from claiming ownership.  If it comes down to two people, both
> >claiming they issued a particular signature, just ask them both to
> >sign a challenge (a different challenge for each).  The impostor won't
> >be able to.
> >
> >Anyway, back signatures avoid all that by adding a signature from the
> >signing subkey on the primary key.  This proves that the owner of the
> >signing subkey is not an impostor, since the impostor could not issue
> >such a signature.
> > 
> >
> Ah,.. ok,.. than backsignatures are VERY IMPORTANT, aren't they? And 
> everybody should add them to existing keys....

Yes, indeed.

> Will gnupg and other clients autmatically indicate if an signing subkey 
> has no backsig?

GnuPG does, as of 1.4.3.  I expect other clients will do as well.

David



More information about the Gnupg-users mailing list