Subject: Re: PoP & Signer's User ID subpacket?

From: Len Sassaman <[email-masked]>
Date: Mon, 7 Jul 2003 15:34:56 -0700 (PDT)

On Mon, 16 Jun 2003, David Shaw wrote:

> This raises a 2440bis question: given all the recent deprecation of
> PGP 2.x stuff, is it worth requiring self-signatures on user IDs now?
> If I recall, the only reason that user ID self-signatures are not
> currently required was for 2.x compatibility.  Certainly every modern
> implementation (5.0+, any GnuPG) generates user ID self-signatures
> automatically when a user ID is created.

I think this is a marvelous idea.

---

From: David Shaw <[email-masked]>
Date: Sun, 13 Jul 2003 09:18:42 -0400

> I think this is a marvelous idea.

The only thing that really troubles me about the idea is that it
raises problems for the (legal, to my reading of 2440) encrypt-only v4
key.  A true encrypt-only key would have a problem issuing the
self-signature.  Of course, Hal's comments about encryption keys
issuing signatures apply here as well.

David

---

From: "Michael Young" <[email-masked]>
Date: Sun, 13 Jul 2003 23:37:24 -0400

"David Shaw" <[email-masked]> writes:
> key.

This doesn't trouble me... I strongly believe that we should
remove the loophole that allows encrypt-only top-level v4 keys,
for exactly this reason.  (I was astounded when David pointed out
the seemingly permissive language in another forum.)

Why is it important to be able to generate such a thing?  Is it such a
burden to have to generate a signing key?

[If you don't care about uid validity, which you mustn't if you're
using an encrypt-only top-level key now, then you could even attach a
bogus top-level key, which would take virtually no time to generate.]

---

From: David Shaw <[email-masked]>
Date: Mon, 14 Jul 2003 02:07:27 -0400

> the seemingly permissive language in another forum.)

Just so we're all clear, Michael and I had been discussing the
legality of a v4 encrypt-only primary WITHOUT any subkeys.  An
encrypt-only key WITH subkeys is clearly forbidden in 2440 both
implicitly (an encrypt-only primary key could not issue the
non-optional subkey binding signatures) and explicitly ("In a key that
has a main key and subkeys, the primary key MUST be a key capable of
certification.").

This is just a primary key that happens to be of an encrypt-only
algorithm (presumably #16, since there is no way to express an
encrypt-only primary key with algorithm #1 (you would need to use #2,
which is deprecated)).

David

---

From: David Shaw <[email-masked]>
Date: Mon, 14 Jul 2003 10:49:58 -0400

> encrypt-only primary key with algorithm #1 (you would need to use #2,

I should add, though, that I don't really understand the objection to
an encrypt-only primary.  OpenPGP is a collection of various tools
that can be combined in different ways for different uses.  Some
combinations are more useful than others, and some make no sense, but
I don't see why (in the absence of an actual problem) one particular
combination should be considered a "loophole" and removed.

Do I strongly care about encrypt-only primaries in particular?  Not
really.  I do care about clean design, though, and adding a special
additional "no encrypt-only primaries" rule on top of the current
clean primary/subkey design seems without clear benefit.

Can you explain what troubles you about encrypt-only primaries?

David

---

From: "Michael Young" <[email-masked]>
Date: Mon, 14 Jul 2003 13:39:04 -0400

> clean primary/subkey design seems without clear benefit.

I think that the rules are cleaner without encrypt-only standalone
keys: "Every key has a primary that can sign and any number of subkeys
(of any type)."  Just one rule, no special cases, nothing "on top".

I find it strange that you'd use the term "primary" for a top-level
encrypt-only key.  It can't have subkeys; there is no "secondary".

> Can you explain what troubles you about encrypt-only primaries?

Aside from being an unclean exception to a simple model :-?

I think there is value in requiring uids to be self-signed.  To allow
encrypt-only top-level keys, one has to make a special case.  Given
that they are only very limitedly useful, I'd rather not have the
special case.

I recognize that requiring self-signatures on uids restricts some
otherwise valid uses, and that it doesn't provide any additional
security given a strong trust model and a proper understanding of its
limitations.  I still think it's worthwhile.  [Note that the same is
true of the signing-subkey problem.  I acknowledge that the problem
was more serious there, and the uses of non-owned subkeys are more
limited.  (By the way, I like David's signature-in-a-subpacket
solution.)  The same is also true of the requirement that a key have
at least one uid.]

Hal observed that all *existing* encrypt-only algorithms really can
support signing anyway.  Who knows whether that will hold up over time?
If we're convinced that it will, I'd rather remove the encrypt-only
notion from the algorithm entirely (putting it in the key preferences
instead).

---

From: "Michael Young" <[email-masked]>
Date: Mon, 14 Jul 2003 12:46:11 -0400

---

From: David Shaw <[email-masked]>
Date: Mon, 14 Jul 2003 21:09:38 -0400

> encrypt-only key.  It can't have subkeys; there is no "secondary".

I call it primary because 2440 calls it primary.  It doesn't matter if
there are no subkeys on it.  That's just wording.  I think we all know
what I am talking about when I say encrypt-only primary: a version 4
public key (tag 6) that is of an encrypt-only algorithm.

> Aside from being an unclean exception to a simple model :-?

I don't see exceptions here.  The model is quite clearly and simply
stated in 2440.  Any key can be of any type.  There are no exceptions.
Does this mean that there are possible arrangements of packets that
make no sense?  Sure, so don't do that.

I see your suggestion as adding an exception: any key can be of any
type, except that the primary must be able to certify.

> that they are only very limitedly useful, I'd rather not have the

Keep in mind that this renders valid 2440 keys invalid under 2440bis.
I can't imagine why we'd do such a thing just to gain the ability to
require self-signed user IDs.  To be honest, I've never seen an
encrypt-only primary in nature.  I know of no program that generates
them.  I've never used one except to test.  But who am I to dictate -
in the absence of an actual security-related reason - to someone else
what type of key they may have?

Note that GnuPG doesn't have any special support for encrypt-only
primary keys, but because of the nice general design of v4 keys, where
any key (primary or subkey) can be of any type, encrypt-only primaries
work just fine.  I don't have a copy of PGP handy (I'm traveling), but
I suspect that they'll "just plain work" in PGP as well.  My point
here is that it would take additional code and additional complexity
to *prevent* encrypt-only primaries from working... so why mess around
with this, especially since there is no security-related reason for
it?

> security given a strong trust model and a proper understanding of
> its limitations.  I still think it's worthwhile.

Allow me to restate the original problem that spawned this thread: It
would be nice to require self-signatures on user IDs.  We cannot do
that since an encrypt-only primary is unable to issue such a
self-signature.

So, as a solution, rather than ripping into the key construction
rules, why not just put in a line saying "user IDs and user attributes
SHOULD have a self-signature", and call it a day?

This has a few nice details:

* It doesn't render perfectly valid 2440 encrypt-only primary keys
  invalid with the swipe of a pen.

* It doesn't render perfectly valid 2440 non-self-signed keys invalid
  with the swipe of a pen.

* It accomplishes the intent of pointing out that implementations
  should really be self-signing user IDs (which they are already
  doing anyway).

David

---

From: "Michael Young" <[email-masked]>
Date: Thu, 17 Jul 2003 17:50:49 -0400

> that since an encrypt-only primary is unable to issue such a

It seems that we all agree that it would be "nice" to *require*
self-signatures.

> SHOULD have a self-signature", and call it a day?

I think it's suitably "nice" to merit "ripping into" a key construction
rule that I have always thought was wrong.  Despite your attempts to
paint the current rule as cleaner, simpler, or more natural, I still
disagree -- I think the current rule is more convoluted.  It *is*
the current rule, though, and I understand that we'd be invalidating
some currently valid keys "with the swipe of a pen".  As you've noted,
no known software generates encrypt-only top-level keys (except perhaps
for testing).  Anyone with a usable signing key can generate a self-signature
to make any intended uids valid.  With those facts in mind, I'm quite
willing to take a swipe to correct a mistake.

Perhaps one of the original authors can offer some insight here.
Why was it important to allow encrypt-only "primary" keys?

---

From: Len Sassaman <[email-masked]>
Date: Thu, 17 Jul 2003 15:14:41 -0700 (PDT)

> the seemingly permissive language in another forum.)

Agreed.

---

From: Len Sassaman <[email-masked]>
Date: Thu, 17 Jul 2003 15:20:26 -0700 (PDT)

> require self-signed user IDs.  To be honest, I've never seen an

I am surprised that there have not been widespread attacks on OpenPGP keys
as a result of the permitted non-self-signed UIDs. I think this really
must be fixed. (And for users to add self-signatures to their existing
unsigned uids is trivial.)

> what type of key they may have?

That's what making an interoperable protocol is all about. (I'll also
argue that interoperability is a security-related reason in and of
itself.)

> with this, especially since there is no security-related reason for

Simplicity is a good reason, as is the robustness of the OpenPGP system.

---

From: David Shaw <[email-masked]>
Date: Thu, 17 Jul 2003 20:50:27 -0400

> disagree

"Despite your attempts to paint the current rule"?  Yikes.  We're all
working towards the same goal here.  Remember who suggested dealing
with this in 2440bis.  If I liked the no-required-self-sigs status
quo, I wouldn't have brought it up.

Although it might seem I'm arguing against required self-sigs, I'm
actually fairly torn.  One problem is that combining this change with
the encrypt-only key change implies a number of subtle and not so
subtle changes, and I'm not (yet) convinced that this is the right
thing to do.

I understand that you see the removal of encrypt-only keys as an
advantage (as you seem to be arguing against encrypt-only keys almost
more than you are arguing for a required self-signature), but I don't
see things that way.

Despite what I said earlier in this thread, requiring self-sigs does
not depend on removing encrypt-only keys.  Since there seems to be
widespread agreement for the former, and not for the latter, perhaps
it would be better to resolve the self-sigs question and then discuss
encrypt-only keys as a suppurate issue.  Discussing the two issues tied
together seems to be leading nowhere.

I propose "Self-signatures are REQUIRED for all user IDs and user
attribute IDs on any key that has a primary capable of certification".
This handles the self-sig issue without changing the key construction
rules at all.

If there is consensus on this, then a different discussion can be
opened on the matter of encrypt-only keys.

David

---

From: David Shaw <[email-masked]>
Date: Thu, 17 Jul 2003 20:57:24 -0400

> unsigned uids is trivial.)

No question.  I just object to tying the self-signature fix to
removing encrypt-only keys.  It's my own fault since I mentioned them
together, but I was wrong.  There is no need to tie the two together.

> Simplicity is a good reason, as is the robustness of the OpenPGP system.

I'm afraid I don't understand your response.  Simplicity is a good
reason to add complexity? (??)

David

---

From: Len Sassaman <[email-masked]>
Date: Fri, 18 Jul 2003 09:13:41 -0700 (PDT)

> reason to add complexity? (??)

I think that saying "all v4 primary keys are signature keys" actually
simplifies things. You may disagree.

---

From: David Shaw <[email-masked]>
Date: Fri, 18 Jul 2003 13:10:37 -0400

> simplifies things. You may disagree.

Ah, ok.  I didn't parse your response properly.

I'm of mixed feelings on the primary is a signing key issue.  There is
definite appeal to having all non-signature items in a key be bound
there by signatures.  As things stand now, subkeys are bound, but user
IDs/attributes might not be.  There is a nice annoyance attack in the
wait there.

I do wonder what this case would mean in regards to the discussion
though:

1) Generate a RSA sign+encrypt key.  Naturally the user ID on that key
   should have a self-signature.

2) Now change the key flags so that the primary is encrypt-only.

Is that an "encrypt-only" key?

David

---

From: "Imad R. Faiad" <[email-masked]>
Date: Sat, 19 Jul 2003 00:06:01 +0200

Hello David,

If it's an RSA key, then I guess that it is both,
unless the implementation honors the use flags,
and the OpenPGP's implied use of the public
key algorithm.

All of the public key algorithms support
signing, therefore, until a time when
there is a public key algorithm which
does not, one can say that all OpenPGP
keys can be signing keys.
One can generalize that and say, that
all OpenPGP key are encrypt enabled also,
with the exception of DSA keys.

While you control with what key/subkey
you sign with, you cannot control what
key will be used when encrypted messages
are sent to you.

I personally, will always prefer to
encrypt to a signing key, if at all
the public key algorithm supports
encryption.  If there are any subkeys,
I will chose the oldest, or a signing
subkey, just to have some "PHUN", regardless
of whether it is revoked or not.
And there is nothing that you can do
about it!  And I would recommend that
every OpenPGP user does the same.

Binding is not sufficient, all it implies is
that the one who had the secret part of the
primary key at the time chose to sign that
subkey.

A key or subkey should be self signed, this is
an indication that whoever purports to have
issued it had the secret part at the time.

A UID has to be signed by the primary key.

In short:-
1) A primary key with no self signature
   is meaningless.
2) A UID with no signature from the
   primary key is meaningless.
3) A subkey with no self signature and
   no binding signature from the primary
   key is meaningless also.

Hope the above helps,

Best regards

Imad R. Faiad

On Fri, 18 Jul 2003 13:10:37 -0400, you wrote:

>
>[F651E0D5]*** PGP SIGNATURE VERIFICATION ***
>[F651E0D5]*** Hash: SHA1
>[F651E0D5]*** Status: Good Signature from Invalid Key
>[F651E0D5]*** Alert: Please verify signer's key before trusting signature.
>[F651E0D5]*** Signer: David M. Shaw <[email-masked]>
>[F651E0D5]*** Note: Signing Key is a Sub-Key!
>[F651E0D5]*** Key ID: 0x49E1CBC9
>[F651E0D5]*** Fingerprint: FC2A 0E9B 5122 7D7B 5923  2CE6 E266 5C87 49E1
>CBC9 [F651E0D5]*** Signed: 7/18/2003 7:10:37 PM
>[F651E0D5]*** Verified: 7/18/2003 9:53:22 PM
>[F651E0D5]*** BEGIN PGP VERIFIED MESSAGE ***
>
>[F651E0D5]*** END PGP VERIFIED MESSAGE ***

---

From: David Shaw <[email-masked]>
Date: Fri, 18 Jul 2003 23:23:02 -0400

> every OpenPGP user does the same.

Not me.  I just pick a random person from the keyserver and encrypt to
them.  Now that's really phun.

David

---

From: Jon Callas <[email-masked]>
Date: Sun, 20 Jul 2003 03:05:14 -0700

> type, except that the primary must be able to certify.

2440 already says that a top-level key must be able to sign.

Getting, however to the issue in the subject line, I don't think 2440 should
require self-signed user ids.

Consider the following statements:

"Call me Ishmael."

"Call him Ishmael."

The first corresponds to a self-signed UID. The latter to an introducer
signature.

I think that PGP UIDs can be SDSI names. More than that, they should be.

I would like to be able to add a user id to someone's key because I want to,
and I sign it myself, and let it go at that.

Here's my real-world example. A person I work with, call this person "John
Doe," has a PGP key with the UID "[email-masked]" on it. However, this person
*always* sends mail from "[email-masked]" and I am constantly having to
cancel keyserver searches and then go manually select the right key. It
drive me up the blinking wall. I have asked said person to add in the proper
user name on a number of occasions, and am still waiting.

It would make me eternally happy if I can add the user name I want to that
key. It isn't self-signed, it's signed my *me*. Why should *my* software
accept UIDs as valid that are signed by me?

Now then, we get into a small bit of interesting protocol if I export that
key. But I don't see why that protocol has to be in 2440. Here are some
issues:

* What happens when I export that key? Should my software not export UIDs
that aren't self-signed? I don't care. Well, perhaps more to the point, I
consider that a bit of software design, not standards work.

* What happens if I import a key that has a UID that isn't self-signed?
Should it strip it? Should it strip it if it is signed by someone who is a
trusted introducer? Again, I consider that software design.

* What happens if a key is placed on a server? Should all non-self-signed
UIDs be stripped? I think that's a matter for the server owner, but "Yes" is
a fine answer.

If an implementation didn't export these "SDSI UIDs" I could live with it.
It might be nice to be able to import a SDSI UID that was signed by entities
I trust. But I could live without that.

But -- I consider all this to be software design issues, not standards
issues. The standard should allow gentlepersons to disagree on some facets
of design and use -- especially when the standard punts the whole issue of
trust.

    Jon

---

From: David Shaw <[email-masked]>
Date: Sun, 20 Jul 2003 08:34:17 -0400

> 2440 already says that a top-level key must be able to sign.

I'm not sure 2440 says that.  The relevant bit is in section 11.1,
which says "In a key that has a main key and subkeys, the primary key
MUST be a key capable of signing."

I took this, perhaps wrongly, at face value - that is, if a key had
subkeys, the primary had to be able to sign (for the binding
signatures, presumably).  The flip side of this is that if a key does
not have subkeys (and there is nothing wrong with a V4 key without
subkeys), the primary did not have to be able to sign.

Did I misinterpret the intent in 2440 there?  If "a key that has a
main key and subkeys" was intended to mean "V4 key", then I strongly
suggest changing it to say "V4 key" explicitly to avoid the confusion
that spawned a good bit of this thread.

David

---

From: Jon Callas <[email-masked]>
Date: Sun, 20 Jul 2003 14:22:42 -0700

> that spawned a good bit of this thread.

Uh, I thought that meant that the top-level key can't be an encrypt-only
key. So yes, I was quite sure that 2440 said what you wanted.

    Jon

---

From: "Michael Young" <[email-masked]>
Date: Fri, 25 Jul 2003 17:03:02 -0400

> 2440 already says that a top-level key must be able to sign.

That was my interpretation, but David read it another way and his
reading was not unreasonable.  I'd ask that we clarify the language.
Someone suggested saying "V4" rather than "that has a main key
and subkeys"; that works for me.

> and I sign it myself, and let it go at that.

Jon presents a very reasonable example.  If it's for his personal use,
then it can be encapsulated in user agents (not the protocol), much
the way trust is today.  (In fact, the value in signing such a local
alias is debatable.)  I sorely wish that user agents offered this
already.

If you feel that this is something that should be exportable, then
indeed, we need to allow non-selfsigned identities.  I considered this
use, and had decided that I could live without it (in the protocol) in
order to impose a strict self-signature rule.  But I'm willing to
relent.  As Jon points out, keyservers and user agents can (and
probably should) impose their own restrictions at storage/import time.