Re: Suggestion for the signing subkey problem


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello David,

We are opening a can of worms, and there
will be many more in the future as a result.

Please let me re-iterate:-

As I understand it, sub keys are only justified in the following
circumstances:-
1) When the public key algorithm does not support encryption (e.g. DSA).
2) In agreement with a school of thought, which recommends that
   it is good practice not to use the same key for signing and
   encryption.

Any other arguments beyond the above, are just eccentricities,
and will be better addressed by creating another key.

Therefore, for the sake of simplicity, please permit me to propose
that an OpenPGP key be a Master Key of an OpenPGP public key algorithm
suitable for signing, and ONE optional encryption sub key of an
OpenPGP public key algorithm suitable for encryption (and / or signing
if the owner so desires), PERIOD.

Should the above not be adopted, then, I would like to propose
that subkeys be treated just like any other key.
That is, they ought to be signed by their consumer(s).
After all, when you sign a check, you state the amount, among
other things, no one signs a blank check!
Also, when one signs a contract, one signs the pages
containing the terms of that contract, one does
not append to the later signed blank pages
(to use the analogy of signing OpenPGP v4 keys,
a Power or Attorney to append as many pages),
to be filled in by the other the other party, as,
when, and with whatever, he deems fit.

What you suggested below maybe an acceptable solution as far
as the key owner is concerned, but, what about the consumer?

- From what I could gather, subkeys are attractive, because
they inherit the trust/validity of the master key.
But, isn't that inheritance in breach of the OpenPGP
trust model?

my 2c,

Best regards

Imad R. Faiad

On Tue, 24 Jun 2003 22:57:03 -0400, you wrote:


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