ietf-openpgp
[Top] [All Lists]

Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?)

2003-07-20 03:05:11

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

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.

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 "jdoe(_at_)pgp(_dot_)com" on it. However, this 
person
*always* sends mail from "john(_dot_)doe(_at_)pgp(_dot_)com" 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


<Prev in Thread] Current Thread [Next in Thread>