Delete key from keyserver

[Alex Mauer]

Neil Williams wrote:

> No, because you've separated the two - there has to be a reason to do this and 
> therefore you are implying that there is a difference between the two UID's.

There is.  It is nearly impossible to verify with complete certainty 
that the person you meet is in fact able to access the email 
account/key.  It is completely impossible to verify that they are the 
only person with access to the mailbox or key.

If you sign both UIDs, it is equivalent to signing one traditional UID.

> I wouldn't sign the email only one because an email address can be accessible 
> to more than one person. If I'm encrypting to this key, I want to know to 
> WHOM I am writing.

But you don't know that any more with two UIDs than with one.  The name 
being part of the UID does not say anything at all about the email.

> I wouldn't sign the name-only one either - I cannot contact the person with 
> that name because I have no idea if the email address is solely for the 
> person named in the other UID.

But you have no idea if the email address part of the single UID is 
solely for the person named in the name part of the single UID.  Same 
problem.

On this basis, you should not sign any UID at all, since you can't send 
a mail to the email address and be sure of contacting the person with 
the real name listed, and you can't meet a real person and be sure that 
it is the same person who receives mail at the address.

> A UID should reflect how I know a person. I've got several UID's and if you 
> know me as webmaster, you sign that one, if you know me from the LUG you sign 
> that one, if you know me professionally, you sign that one.

Exactly.  So if you had separate UIDs, someone knowing you as webmaster 
would sign both that email address UID and the real name UID, from the 
LUG would sign that one and the real name, etc.  Someone (like me) 
knowing you only by email address could sign only the relevant email 
UID, and be making no statement about your real name.

> But when signing a key, I'm signing a specific UID. It is bad practice to sign 
> all UID's belonging to any one key. "Sign only the ones you can verify"  is 
> my advice at keysigning events. If there's no email I cannot verify that UID. 
> If there's no name, I cannot verify that UID.

...how do you make the connection between the email part of the UID and 
the real name part of the UID?  I assert that you cannot.

>>But if they can only prove one part of the data to their satisfaction,
>>why should they not sign only that part?

> IMHO, they should not sign at all.

I agree, for cases where a UID contains both a real name and an email, 
and both parts cannot be verified.

> The challenge token is sufficient because it is used to show that the person 
> you met and verified personally also has access to the private key at the 
> address indicated.

No it doesn't.  Nothing prevents the person you met from giving the 
challenge token to someone else who does have access to the private key 
at the address indicated.

> So sign it locally. By signing it with an exportable signature, you are trying 
> to indicate to ME that you have verified the identity of that person, not 
> just the email account.

If it is a UID containing only an email address, I am not trying to 
indicate that I have verified the identity of that person.  I am only 
indicating that I have verified the email account.

If it contains both an email address and a real name, then by signing it 
I am trying to indicate that I have verified both.

>>In that case, if the email is trusted, then the name on the UID is 
>>irrelevant.
> 
> Not true. By all means sign that locally, but do not lead others to believe 
> you have verified more than you have.

Given.  I am speaking of relevance to me, not relevance to others.  If I 
trust the association between the email address and the key, and I only 
interact with that person by email, then the name on the UID is of no 
importance to me.  That is not to say that I am willing to sign it, only 
that I am willing to trust its veracity for my purposes.

> why should I have to sign both in order to
>>declare this trust?
> 
> You don't if you sign locally.

Actually, I would, even with an lsign.  My local signature would 
indicate "Dave Shaw, email address dshaw at jabberwocky.com, uses key ID 
0x99242560".  If the UIDs were separate, then I could sign (or lsign) 
the one part that I had verified.

> You should advertise this policy 

http://web.hawkesnest.net/~hawke/gpgsigningpolicy.html

> I would recommend you only sign keys locally until you are willing to accept 
> how other people would be affected by your incomplete verification policy.

Please, take care to note that it is not my policy to sign a key without 
verifying all parts of it. (except for the few keys that I will sign 
with a level 1 sig, as described in my key signing policy.  It is simple 
enough to configure gpg to ignore level 1 signatures if you feel that 
they weaken the web of trust.) I wrote a comment on the usefulness of 
UIDs which only contain one piece of data; this does not reflect on my 
key signing policy in any way.

I also wrote in largely hypothetical terms, "If I *wanted* to advertise 
my trust in the email portion of a traditional UID, I *would* have to 
sign the whole thing".  That is not the same as "When I want to 
advertise my complete trust in the email portion of a traditional UID I 
just go ahead and sign it with no verification whatsoever." In point of 
fact I *do* use a challenge method as you described for email, I *do* 
indicate the level of verification I have done, and I *do not* claim to 
have verified all information in a UID if I haven't.

> BTW. Knowing this in advance, I would not sign your key even if I could verify 
> your physical identity, fingerprint and email address. It would send the 
> wrong signal to those who already know me.

...k, go ahead.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : /pipermail/attachments/20051026/10c67a03/signature.pgp