Manoj Srivastava wrote:
(...)
> Now really, we want to tie the key to a person -- even if they
> resleeve (a. la. Altered Carbon, [0]). Thankfully, releeving is not
> (yet) possible, so we don't have to deal with that. All we have to do
> is to tie a key to a real live person, and do it in a fashion that is
> reproducible and testable.
>
> Traditionally, you establish identity for a person by one or
> more of:
> A) Something they (and only they) have. This is previously issued
> tokens of some kind (passports, id cards, secure tokens,
> etc). There are three things needed to make this even the least bit
> reliable:
> 1) You need to trust the process of deploying the thing they have;
> someone must establish in some manner who the person is, before
> the token is given out
> 2) The token should not be easily duplicated, stolen, and
> reused. This requires some care on the part of the token holder
> 3) You can actually verify that the token is genuine and decipher
> who the token was issued to without being spoofed.
> B) Something that the person is. Biometrics, etc. Again, the caveats
> apply about spoofing, and trusting you know what it is that the
> person is supposed to be (is it really Mr X's retina scan I am
> trying to match?)
> C) Something they know. Shared secrets, passwords, knowledge of
> events past you and the person knows, and no one else could.
>
> Madduck seems to put a whole lot of unjustified confidence in C)
> above. You might think you know the person pretending to be Mr X, but
> really, most of us at debconf have done little to verify C to any
> degree of reliability. If all you can say is that person owns that
> email address, why are you even bothering to have a signing party? You
> don't need it to ascertain that a key owner controls an email address
> by some other persons signature; just send a encrypted message to that
> email address and ask for a reply. Done.
>
> So, A. Now, most countries where people are allowed to come to
> my country from have to demonstrate a process by which they issue
> travel documents to their citizens, and I have established for myself
> that if it meets the State departments needs, then !.1 is satisfied
> for me.
>
> A.2 is somewhat harder, but being careless about your travel
> documents has real world consequences, and most countries whose
> citizens can travel to mine have made travel docs hard to
> duplicate. Not impossible, but hard.
>
> A.3 seems to be the part which receives most criticism; I can
> surely be spoofed by a well forged travel document. But it does raise
> the bar for someone who needs my signature, and I think it meets my
> threshold of return on effort to sign the key, and put a modicum of
> trust in the assertion that we have nailed that key to a real human
> being.
>
> So while signing keys is not about governments, as Russ said, it
> is about establishing identity, and government issued identity
> documents are better proxies for establishing that than I can be
> bothered to do myself.
>
> And, on my day job, people will fall over laughing about basing
> identity on what someone says often enough over a period of time with
> no further checks. And yes, my tummy still hurts.
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.
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).
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).
Mails, extern signatures and other gpg things (and identities) should be left
outside debian, with people own interpretations and trustiness.
IMHo combining the two will be a security mess.
ciao
cate
_______________________________________________
Debconf-discuss mailing list
[email protected]
http://lists.debconf.org/mailman/listinfo/debconf-discuss
