[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?)
>>> 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
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
* 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