Subject: Suggestion for the signing subkey problem

From: David Shaw <[email-masked]>
Date: Tue, 24 Jun 2003 22:57:03 -0400

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: Derek Atkins <[email-masked]>
Date: 25 Jun 2003 14:29:37 -0400

Hmm, can subkeys have subkeys?

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: "Imad R. Faiad" <[email-masked]>
Date: Thu, 26 Jun 2003 16:56:43 +0200

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

---

From: David Shaw <[email-masked]>
Date: Fri, 27 Jun 2003 10:03:58 -0400

> and will be better addressed by creating another key.

One person's eccentricity is another person's operational requirement.
OpenPGP should be flexible enough to accomodate both.

> if the owner so desires), PERIOD.

I guess I don't really see how this helps.  Remember that both
multiple subkeys and signing subkeys are from 2440.  These are not new
inventions in 2440bis, and are already widely supported in the field.
All versions of PGP (5+) and GnuPG support multiple subkeys.  All
versions of GnuPG and PGP 8 support signing subkeys.

What is under discussion here is a simple fix for a design weakness in
signing subkeys.  Forcing all v4 keys to have one and only one subkey
would effectively declare every current OpenPGP implementation
noncompliant, and even then not solve the problem at hand with
sign+encrypt subkeys.

David

---

From: "Imad R. Faiad" <[email-masked]>
Date: Sat, 28 Jun 2003 01:45:46 +0200

Hello David,

On Fri, 27 Jun 2003 10:03:58 -0400, you wrote:

>
>[818D9699]*** PGP SIGNATURE VERIFICATION ***
>[818D9699]*** Hash: SHA1
>[818D9699]*** Status: Good Signature from Invalid Key
>[818D9699]*** Alert: NEVER TRUST A V4 KEY.
>[818D9699]*** Signer: David M. Shaw <[email-masked]>
>[818D9699]*** Note: Signing Key is a Sub-Key!
>[818D9699]*** Key ID: 0xE2665C8749E1CBC9
>[818D9699]*** Fingerprint: FC2A 0E9B 5122 7D7B 5923  2CE6 E266 5C87 49E1
>CBC9 [818D9699]*** Signed: 6/27/2003 4:03:58 PM
>[818D9699]*** Verified: 6/27/2003 11:58:15 PM
>[818D9699]*** BEGIN PGP VERIFIED MESSAGE ***
>
Exactly, it's an operational requirement, therefore, please by all
means exclude such requirements from a standard, which as I understand
it, defines OpenPGP packet formats.  Operational requirement, depends
on one's taste.  And needless to say, tastes differ, so please do not
burden that standard with one's groups view of what these operational
requirement should be...  I am sure, with some thoughts, you or anyone
for that matter can come up with something, to meet those requirements,
with just the humblest of OpenPGP keys.  If on the other hand
you feel that these operational requirement are the best thing
since sliced bread, than by all means, spawn another RFC
to standardize them.

I do not share your view that OpenPGP should be flexible when that
flexibility leads to complexity. OpenPGP should be as simple as possible,
without compromising security that is, it should be easily implemented,
unambiguous, and understood by it's users.

A lot of users have a hard time as it is, understanding the concepts
of Public Key Encryption. We are creating barriers for users,
and implementors.  As I understand it, OpenPGP is supposed to be
a standard whose end users are supposed to be the masses.
I cannot see how the masses can be served with the operational
requirements of paranoids, I mean those of us who feel impelled
to have off and on line boxes, super duper master keys to be
used in a super duper secure environments, with lesser sub keys which
expire on the hour...  Hey what are you guys protecting? Nukes?
If that is the case, maybe you guys need something more that
Pretty Good Privacy...
>versions of GnuPG and PGP 8 support signing subkeys.
The reason that I have proposed the above, is because I am very concerned
about v4 keys in general, and in particular sub keys.  Also, I do
believe in the principle that less is better, especially so
for crypto software.
>noncompliant, and even then not solve the problem at hand with
The problem is a lot more than that.  V4 keys are flowed to begin
with.  Please re-read what I stated in my previous message,
in particular the sections which you sniped.
I think, that this is an problem which should be addressed.
>David
No offense,
and with all respect,

Best Regards

Imad R. Faiad
>[818D9699]*** END PGP VERIFIED MESSAGE ***

---

From: Ian Brown <[email-masked]>
Date: Sat, 28 Jun 2003 00:30:08 +0100

I am amazed that this thread is still running several weeks after you
started it, with virtually every response refuting your arguments...

>Exactly, it's an operational requirement, therefore, please 
>by all means exclude such requirements from a standard,

You seem unable to understand the difference between enabling
functionality through a standard and mandating it. RFC 2440 has allowed
subkeys for several years now. You need to make the case to remove this
functionality better than you have done so far.
  
> If on the other hand you feel that these operational 
> requirement are the best thing since sliced bread, than by 
> all means, spawn another RFC to standardize them.

RFC 2440 was published five years ago. I look forward to your draft
removing multiple subkey capability from it.

---

From: "Imad R. Faiad" <[email-masked]>
Date: Sun, 29 Jun 2003 19:14:36 +0200

Hello Ian,

>started it, with virtually every response refuting your arguments...
And what amazes me, is that you have yet to grasp what we are
talking about!  Please re-read the thread, some issues have
been addressed.  I sincerely hope that you re-read each and
every message in that thread, because, you are taylor made
for the kind of attacks which can be inflicted to your
OpenPGP keys.
>functionality better than you have done so far.
No problems, I mean what can I say???
>removing multiple subkey capability from it. 
I am no paper pusher, and do not have the funding or time/ability
to publish RFC's

And no offence,

Best Regards

Imad R. Faiad

---

From: Ian Brown <[email-masked]>
Date: Sun, 29 Jun 2003 23:01:26 +0100

> for the kind of attacks which can be inflicted to your OpenPGP keys.

I've read all the messages. Your request that subkey capability be
essentially removed has been rejected by all of them.

> I am no paper pusher, and do not have the funding or 
> time/ability to publish RFC's

So I guess this thread is at an end then, with the capability remaining.