[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

        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.

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: