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

[Jon Callas <jon@xxxxxxxxxx>]

>>> 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@xxxxxxx" on it. However, this person
*always* sends mail from "john.doe@xxxxxxx" 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