Delete key from keyserver
linux at codehelp.co.uk
Wed Oct 26 21:01:15 CEST 2005
On Wednesday 26 October 2005 6:26 pm, Alex Mauer wrote:
> Right, so why is it any better to have a key with:
> 0x99242560 David Shaw <dshaw at jabberwocky.com>
> than to have
> 0x99242560 David Shaw
> 0x99242560 dshaw at jabberwocky.com
> (two UIDs)
> You still have the same level of disambiguation.
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.
> Why would someone be
> unwilling to sign the one, but willing to sign the other?
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.
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.
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.
Without an email address and a name, a UID is rather useless.
> Yes, a key without any UID containing an email address is of
> questionable usefulness. Agreed.
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.
> 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.
A signature is a *public* testimony that you have verified this person.
You do not sign for your own benefit but to assist others. It is other
people's perceptions of the act of signing that are important.
Sign locally - you get the benefits and the rest of us do not get more
untrustworthy signatures on otherwise trusted keys.
> "In communication with them" is not good enough for the level of trust
> that these checks imply. Besides, the scenario I described already
> implies that they must be in communication.
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
One form of challenge is explained here:
A verification challenge would use a modified procedure that nevertheless
ensures that the person I met is the person with access to both the email
account and the private key.
> But it's really irrelevant to the original point, which is that in many
> cases, the real name doesn't matter; only the email address/key does.
The real name always matters. email-only verification is pointless - it
doesn't strengthen the web of trust.
> "If I know a person only by email, then that email *is* the person to
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.
> In that case, if the email is trusted, then the name on the UID is
Not true. By all means sign that locally, but do not lead others to believe
you have verified more than you have.
> I might be willing to trust that key ID 0x99242560 really
> is used by the holder of email dshaw at jabberwocky.com, but not that the
> person in question really is named David Shaw. ... and in most cases, I
> probably don't really care about the real name of the keyholder, only
> about the email address. So why should I have to sign both in order to
> declare this trust?
You don't if you sign locally.
You do if other people are going to be using that signature in their web of
You should advertise this policy and then people like me could set your trust
level to "Do NOT trust" so that none of your signatures ever count towards my
I cannot trust your signatures if you refuse to verify the *person*.
That's what it comes down to - your exportable signatures impact on MY web of
trust and if you are not going to complete the full verification, others
cannot trust your signatures.
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.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20051026/7d82814c/attachment-0001.pgp
More information about the Gnupg-users