We had a fairly extensive discussion of back-signatures a few months
back on this list. It seemed (at least to me) that we more or less
came to an understanding as to a way to address the problem. I'm
planning on writing up the solution more formally, but before I do so,
I'd like a sanity check whether the problem and solution as I
understand it agrees with the problem and solution as everyone else
understands it.
The problem: it is possible for an attacker to take a signing subkey
from a victim's key and attach this signing subkey to the attacker's
own key. The attacker does this by issuing a new binding signature on
the subkey from his own primary key. The end result is that a
signature issued by this signing subkey may be claimed to be from
either the attacker or the victim.
Proposed solution: have the signing subkey issue a signature on the
primary key. This prevents the attacker stealing the victim's subkey
since the attacker could not issue this signature. Any signing subkey
without such a "back-signature" should be assumed to be suspect.
The details:
1) Define a new type of signature subpacket that consists of a
regular signature contained in a subpacket.
2) Define a new signature class (Hal suggested 0x19), that is defined
as a subkey signature on a primary key. The hashing rules here are
the same as a 0x1F signature - we hash the primary key, and issue a
signature from the subkey over this hash.
3) At (sub)key generation time (or later, for existing keys) create
this 0x19 signature and store it as a subpacket on the subkey
binding signature. It does not matter whether it is a hashed
subpacket or not.
Some advantages:
1) Old signatures issued before this back-signature protection became
available are automatically protected once the back-signature is
added to a given key.
2) Storing the back-signature on the subkey binding signatures
simplifies key maintenance. If a subkey is deleted, the
back-signature does with it automatically, and the implementation
doesn't have to search for and delete back-signatures elsewhere on
the key.
3) Existing signing subkeys can easily have a back-signature added.
It is not necessary to create new subkeys.
4) By storing the data as a signature subpacket (which are generally
ignored if not recognized), we minimize the chance of compatibility
problems with older implementations.
Comments?
David