Subject: Re: Suggestion for the signing subkey problem

From: "Hal Finney" <[email-masked]>
Date: Wed, 25 Jun 2003 12:24:34 -0700

Derek Atkins writes:
> Hmm, can subkeys have subkeys?

Subkeys, unlike David's fleas, are not presently afflicted in this way.
However, if they ever suffered such a transformation, we could probably
link each top and child key in the same way we are proposing to link
our single level of parenthood.

As far as David's proposal, as I understand it, when a new subkey is
created, it signs the main key, along the lines we have been discussing.
However, rather than putting that signature on the main key, we instead
put it into a subpacket of the subkey binding signature issued by the
main key.  Since the subkey creation process has access to the private
parts of both keys, there is of course no difficulty in creating the
signatures in this order and putting them in these places.

The main advantage I see would be that we would not have a new signature
sitting on the main key, which some old software might choke on if it
were particularly particular.  Instead we have a new kind of subpacket in
the subkey binding signature, which hopefully most software will ignore
if it is non-critical.

David suggests that it could in fact be made critical, but I don't see
any advantage to doing that.  It would not stop the fraud from being
perpetrated on old software, since of course the fraudster would not be
in a position to create the new subpacket and certainly would not create
a bogus one and mark it critical, since that would defeat his purpose.

For a good subkey, all marking it critical would accomplish is to create
an artificial backwards incompatibility, so that this very valid subkey
was spuriously rejected by old software, which would not accomplish
anything useful that I can see.

This proposal does depend on old software ignoring non-critical subpackets,
in order for newly created subkeys to still be used by old software (at
least, old software that allowed the use of signing subkeys).

One concern I have is the rather generic "1F" signature type proposed
for the subkey-on-key signatures.  It would probably be better to
use a new signature type specific for this purpose.  We use "18"
for the topkey-on-subkey signature, so maybe we could use "19" for the
subkey-on-topkey.  That would reduce the possibility of an existing "1F"
signature somehow being put to a new and malicious use.  Introducing a
new signature type would increase the chance of an implementation choking
when it finds the signature on the top level key, which would be another
point in favor of David's suggestion to hide the new sig in a subpacket
of the topkey-on-subkey.

Hal Finney

David Shaw <[email-masked]> writes:
> Hi everyone,
> 
> I was thinking about the "stolen signing subkey" problem, and a
> slightly different solution popped up:
> 
> What if we create a new "signature in a signature" subpacket that is
> defined as a regular signature contained in a subpacket?  All signing
> subkeys MUST contain such a subpacket in their binding self-signature.
> The "subpacket signature" in this case is made by the signing subkey,
> and on the primary key, hashed as if for a 1F signature.  The end
> result is that the signing subkey has a binding self-signature issued
> by the primary key as we do now, and that binding self-signature has
> an embedded 1F signature on the primary key data issued by the signing
> subkey itself.
> 
> One of the nice benefits of using a subpacket here, rather than some
> other scheme is that we can set the critical bit of the subpacket if
> we want to "break" the signing subkey on older implementations, but at
> the same time, we don't have to.
> 
> I was considering suggesting a single-purpose subpacket that could
> only be used for making a back-signature from a signing subkey on the
> primary key data, but it started to look like reinventing the wheel.
> We have a good, working, signature format.  If we just stick it in a
> subpacket, we can leverage all that work.
> 
> Yes, it is a little odd to contemplate the idea that a subpacket can
> contain a signature that contains subpackets which contains a
> signature...  "Great fleas have little fleas upon their backs to bite
> 'em, And little fleas have lesser fleas, and so ad infinitum."
> 
> Is this overkill for the exact problem at hand?  Probably.  On the
> brighter side, is certainly a more general solution that could be
> useful elsewhere.  For example, it might replace the (as yet unused)
> signature target subpacket: since we can just stick the target
> signature in this proposed subpacket, we don't need the current target
> subpacket anymore.  It also enables interesting possibilities for the
> notary signature.
> 
> David

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 25 Jun 2003 13:34:03 -0700

>our single level of parenthood.

With a chain of N subkeys, this requires N back-signatures (so 2N total 
signatures).  You could do it with zero or one back-signatures.  Since PGP 
only has N=1, this may not be useful, but I'll point it out anyways:

An alternative to back-signatures was to include the primary key ID as a 
hashed subpacket in a signature produced by the subkey.  David didn't like 
this for subkeys because it would have to be repeated for every signature 
the subkey produced.  But if you have a chain of subkeys, for every subkey 
except the last, you *have* a signature that the subkey produced.

So if you added the primary key ID into subkey-on-subkey signatures, you'd 
only have to do something different for the last key, such as a 
back-signature, or adding the primary key ID into the signatures it produced.

On a separate point, I think subkeys having subkeys could be 
useful[1].  For example, Alice is going on vacation for a month, and 
doesn't want to bring her primary key.  However, she doesn't want to give 
her cellphone a month-long subkey, in case it gets stolen.  So she issues a 
month-long subkey to an online service that she trusts, and then every day 
uses her cellphone to authenticate to the service and get an 8-hour subkey 
under the service's subkey.

[1] http://www.imc.org/ietf-openpgp/mail-archive/msg05262.html

Trevor

---

From: David Shaw <[email-masked]>
Date: Thu, 26 Jun 2003 00:39:28 -0400

On Wed, Jun 25, 2003 at 12:24:34PM -0700, Hal Finney wrote:

> created, it signs the main key, along the lines we have been
> discussing.  However, rather than putting that signature on the main
> key, we instead put it into a subpacket of the subkey binding
> signature issued by the main key.  Since the subkey creation process
> has access to the private parts of both keys, there is of course no
> difficulty in creating the signatures in this order and putting them
> in these places.

Exactly.  Note, however, that there is no need for the subkey
generation process to have access to the private part of the primary
key.  Since this subkey-on-primary signature does not need to be part
of (i.e. hashed into) the subkey binding signature, and is just
located on the binding signature for convenience, there is no reason
why it can't be in the unhashed section of the binding signature.  The
subpacket should work equally well in either the hashed or unhashed
section.

> The main advantage I see would be that we would not have a new
> signature sitting on the main key, which some old software might
> choke on if it were particularly particular.  Instead we have a new
> kind of subpacket in the subkey binding signature, which hopefully
> most software will ignore if it is non-critical.

[..]

> This proposal does depend on old software ignoring non-critical
> subpackets, in order for newly created subkeys to still be used by
> old software (at least, old software that allowed the use of signing
> subkeys).

Yes.  I suppose it comes down to which is less likely to cause a
problem: a new signature subpacket, or a new signature class (as
suggested below).  I lean towards a signature subpacket for the
various reasons given in this thread thus far.  There is also a minor
advantage in key maintenance.  If a subkey is deleted, the
back-signature goes with it automatically, and the implementation
doesn't have to search for and delete back signatures elsewhere on the
key.

> point in favor of David's suggestion to hide the new sig in a subpacket

I think this is an excellent suggestion.

David