Re: [Debconf-discuss] GPG keysigning?
On Tue, Jun 23 2009, Giacomo A. Catenazzi wrote:
> Manoj Srivastava wrote:
>> On Tue, Jun 23 2009, Giacomo A. Catenazzi wrote:
>
>>> I think you miss an important item: people with the same name. In my
>>> small town, I know a lot of people with same name (first and surname).
>>> In linux community we have three different Alax Cox.
>>
>> Right. But you never sign just a name; you sign an gpg user id,
>> which is associated with an email, or a picture, and you check the
>> person owns the email, right? Right?
>>
>>
>> Me, I usually don't sign a key unless I can ensure that the
>> owner of the email address knows a shared secret we shared at the
>> keysigning. Admittedly, this is a minor attack vector: if Eve knows
>> Alice's secret key and passphrase, has control of one of the email
>> addresses, and Alice does not, then Eve will not get the new signature,
>> since she does not know the secret I shared with Alice. This is
>> probably not a vector worth thinking about, I might just start using
>> caff instead.
>>
>>
>>> PGP identity uses normally a email like identity (name and email
>>> address), so your point A reduce the set of possible person that can
>>> misuses identity check, but ... on security terminology this is called
>>> false security which is normally worse than no-security (people will
>>> trust wrong thing).
>>
>> I fail to see this. When we sign keys, the accepted minimal
>> convention is to use caff, which ensures the signature is propagated
>> only if the person whose identity you verified (by whatever criteria you
>> select) owns the id; or whose real life face matches their picture
>> ID.
>
> But from the thread it was given too much emphasis on identity (like
> name and surname), which is IMO dangerous. A name cannot identify
> uniquely a person (or her keys).
This is probably because one does not need s signaure to attach
the gpg user id (email, etc) to the key; you can just send an secret in
an encrypted message and ask for a reply to ascertain that the key
owner retains control of the email ID.
The critical piece of additional information that the signature
is supposed to represent is that the name attached to the key was
connected to the owner of the key (or, at least, someone who controls
the secret key and the email id) by some identity criteria (what they
have, what they are, or what they know). And thus the emphasis on the
ascertaining the identity in this thread.
>> So no, I do not think I missed this item; I just assumed that
>> everyone used a minimal email check before handing out signatures.
>
> Ok, I "misunderstood" your mail: I was thinking you put to much
> weight only on official document (passport etc.).
> I totally agree with you, we need to verify the email addresses
> (along the identity).
Which ought to be the default convention for eysigning -- and we
have tools like caff to make this easier. However, please note that
this need not really be tied down to the signature; as long as you
trust the signature to link the real name to the key, you can verify
the email address control yourself at any later point in time.
Really, we should add things to the signature, about the details
of the identity verification process; like the documents used to verify
the id (though things like passport numbers, validity periods, etc
should not be bandied around for (i hope obvious) privacy reasons).
As Russ mentioned, he can't smite errant folks if he does not
know what country they belonged to, and which identity certifying
authority to go to to get the current location to deliver the
smite. And out web of trust does not carry that information around.
>>> Web of trust is evil! I think debian should reframe the problem and
>>> use GPG only for limited scopes (upload and sign), identified by key
>>> ID. Debian could build an intern web of trust (checking mail and
>>> identity, with own extra rules).
>>
>> My goodness. These are extra rules now?
>>
>> This is dismaying, and engenders misgivings about the value of
>> your signatures.
> Ok. I went to the extreme (we should not trust on names), which is also
> wrong.
We don't trust "names". We ensure that there is some
/reproducible/ test of identity that the key owner can pass that
links the meat-space them to the key (often, a travel document issuing
authority is used as an proxy to perform these checks), and also that
the email id belongs to the key owner (though the latter check may be
done independently, by anyone who needs to be sure of that, without
relying on the signature).
> I meant: the way to break the web of trust are too easy, some are
> malicious/educative like Martin's one, some real errors and
> misunderstanding of GPG. Each error diminishes the value of
> web-of-trust.
> So we need a Debian procedure for a strong web-of-trust which it
> is easy and reduce errors and misconceptions at minimum. Actual
> debconf keysigning parties have problems, OTOH we need signatures.
> We need to set one (or two bars). I don't think that only personal
> assessment on signature is good.
Frankly, recording the details of the verification performed is
a first step to improving the ability to assess the strength of the
link in the web of trust. A simple key sig is not enough, there could
be a formal process to add to the WoT, say by sending a
signed(encrypted?) email to wot@debian.org which has a formal
structure that specifies:
A) Name of signee
B) GPG id(s) of signee
C) Key fingerprint of signee
D) Method used to verify identity
E) Free form additional details
Of course, this should only be done if the owner of the key has
demonstrated they own the email address by decrypting the key and
adding it to the keyservers.
This way, we have some way of looking over what was done to ID
the person, and come to our own conclusion about the strength of the
link.
I have a very different opinion about Alice saying: I have met
Mallory several times over the last few years, and every time He
said his name was Mallory. I did not check his documents, since
he has repeatedly and consistently said his name was Mallory every
time. He could not possibly be lying more than one time, you know?
But I also understand that this is never going to happen; most
people in Debian dismiss such levels of WoT documentation as paronia,
not transparency. But it is hard t judge the links in the WoT unless
we have something like this, and I do not think Smiting or sending the
black helicopters out is very feasible unless we get a stronger link to
the real life human than we do currently. And if Smiting is not the
point, why do we need key signatures?
Why do you need to know who I am? Is it not sufficient that,
say, make or kernel-package have been uploaded by key 0xC7261095 since
circa 1997?
Since key 0xC7261095 has been doing the uploading, you can
attach whatever measures of competence, or trust, the work uploaded by
key 0xC7261095 to that key, and have some reasonable expectation of
future packages uploaded by 0xC7261095. Why does it matter what the
real life name of the owner of key 0xC7261095 is? How does it affect
Debian, and the Debian users?
A lot of your mail seems to be a knee jerk reaction (We MUST
have a strong web of trust; we must check email ID's, etc). Why do we
need that, if not to
A) Smite people
B) Allow them to change keys without losing the trust the old key had
built in their competence and judgement.
> [Note: debian trusts keys in a different way compared to GPG (e.g.
> disconnected keys)]
>
> OTOH in the general web-of-trust, every person has own rules
> (some IMO too weak some IMO too strong) and every person assesses
> trustiness of other people, which cannot be enough to trust
> new NM.
The strong links are not a worry. The weak links are. Me, I say
the people interested enough in strong rules should be left alone, if
not encouraged, and the weaker links is what diminishes the web of
trust model.
manoj
--
It's the good girls who keep the diaries, the bad girls never have the
time. Tallulah Bankhead
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: