trust your corporation for keyowner identification?
Peter Lebbing
peter at digitalbrains.com
Thu Oct 24 11:35:46 CEST 2013
On 24/10/13 01:15, Stan Tobias wrote:
> No, there's no paradox. Any liar will screw your parameters.
The paradox was very clear in my post where I still called it a dichotomy. There
was a paradox in my thoughts and conclusions, why do you suddenly state there is
no paradox?
And my original statement included: the moment I find out people sign keys
purely based on OpenPGP signatures they trust, they get an "I do NOT trust" in
my trust database. Obviously you also try to do this for liars, so this is no
different: when you find out someone's a liar, you give them negative trust in
your trust database.
> If you don't think it's enough to certify his key (at which point does it
> happen?)
The moment the verification is outside the Web Of Trust, it can start to be
enough. For an explanation I refer to my mail of 18 October, 11:37 CEST. You are
skewing my parameters "marginals needed", "completes needed" and "max cert
depth". If I trust the notary just like you do, I give that person full
ownertrust, and the keys they signed will become valid by that. I don't need nor
want your signature for that if it's just based on the fact you trust the notary.
> , then why do we believe WoT authenticates anything? Why do we accept, for
> example, a conversation by telephone to validate a key fingerprint?
Because these are verifications outside the Web of Trust.
> But then cases 2. (2a) and 3. differ basically by your cert being included in
> the set.
No, the difference is that in case 3., you (hopefully) actually did the
verification yourself for key K1, an you extend this verification you did
yourself to key K2. In the other cases, I can get validity for the keys in
question by assigning trust to the same signers that you trust. In case 3., you
are actually adding information to the Web of Trust, just like in the case where
the notary did not create OpenPGP signatures themselves.
> But then again if you wouldn't certify in case 3., then don't you believe
> your own certification? Or the safety of the communication? So what do we
> sign messages for in the first place?
That's correct, you could be so demanding that you say that you insist on seeing
the person face-to-face before you signed their key, because key K1 could have
been stolen and you don't want to make /new/ certifications based solely on a
signed message. It's a personal decision. You could have higher standards for
certifications than for other communication (for which you would trust the
signature).
And these higher standards aren't prohibitive, because certifications are rare.
You can spend a little effort on them that you don't want to spend for other
communication.
> 2a. Same as 1., but X's key (K1) is also signed by a few of your good
> friends, who have personally checked X's ownership of the key, and X sends
> you "I use K2" signed with K1. Would you certify K2?
I wouldn't sign K1 in this case (I'd assign ownertrust to my friends so the key
becomes valid), so if I would sign K2, I think that would be beyond a paradox
and just downright inconsequent. So no, I wouldn't sign K2. I never did any
verification of the identity of this person. They should ask my friends to sign
this key if they don't want to do a face-to-face.
> If for some reason you would sign in cases 2a and 3, but not in case 2, X
> could trick you: sends you "I use K2" signed by K1 (K1 certed by friends
> which you trust), and you sign K2. Then X sends you "I use K1" signed by K2
> (certed only by you yourself), and you sign K1 (case 3). K2 may be revoked
> now.
Sounds to me like you give a good point why you shouldn't sign in case 2a.
> I know. No keys were harmed in the making of my post. :-)
Hehehe :)
> Too long - sorry.
I don't think it was. Too short, and you might not make your point properly.
Cheers,
Peter.
--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
More information about the Gnupg-users
mailing list