PKI deserves to die

[ciphergoth]

In response http://www2.cio.com/research/security/edit/a05232002.html

From: Carl Ellison <cme@acm.org>
Subject: Re: PKI: Only Mostly Dead

Scott,

as far as I'm concerned PKI is not only dying, it deserves to die
much more quickly. That's because when it works, it still doesn't
work.

See the two papers to which I contributed at last month's PKI
Research Workshop http://www.cs.dartmouth.edu/~pki02/

Look especially at what we call the John Wilson problem. In a
nutshell, if you bind a name to a key, even if you do that always
accurately and even if your certificates interoperate with my
software, you have done nothing for me if there are more than about
1000 certified people in the world. That's because there are too
many John Wilsons. I can't tell them apart by name, when you lump
them all together into one big pool (the pool of all people the CA
certifies -- e.g., a big one like VeriSign -- or a little one like
Intel Corporation with only 70,000 and 8 John Wilsons). If I can't
tell them apart (and people can't -- for which we have definite
proof), then I am forced to make a guess as to which one is the right
one -- if the right one is represented at all -- and when I'm handed
a certificate saying that this S/MIME message or HTTPS page came from
John Wilson, I'm not given the list of all John Wilsons, so I don't
even get to compare them to see which one looks like the closest
match.

PKI deserves to die not because of vendor greed, although there is
plenty of that, but because the original idea was wrong. When you
bind a person's name to a public key you have not identified the key
in a way that is useful to me. That's because if I know the name of
the keyholder, I still don't know who the keyholder is.

- Carl

P.S. I strongly recommend your reading those papers in the preprints
available at the PKI Workshop web site.

+------------------------------------------------------------------+
|Carl M. Ellison         cme@acm.org     http://world.std.com/~cme |
|    PGP: 08FF BA05 599B 49D2  23C6 6FFD 36BA D342                 |
+--Officer, officer, arrest that man. He's whistling a dirty song.-+

Comments

[ciphergoth.livejournal.com]

PKI will be useful when I can explicitly bind to public keys the information someone who plans to use them might need to know in order to trust them. That's not a UID, e-mail address or FQDN. See my response to wechsler.

[giolla.livejournal.com]

Odd, 'cos when I use PKI those are the 3 things I generally want to know:
If I'm connecting to a server I want to know that it is the right server, so the certicate needs to show me that.
If I want to send/recieve encrypted mail I want to know that it's from/to a specific e-mail address /* The identity behind that I'll either not care about or have verified by other means */

And within a company/network to identify what a given person is allowed to do I need either a UID or an e-mail address from which I'll extract the UID.

What information would you have bound to a key that would be more useful?

All 3 of these attributes, possibly along with an LDAP DN that I could look up else where, solve the uniqueness problem in an easy to understand way.

[(Anonymous)]

The information I would bind to a key that is more useful than a domain name or e-mail address or common name is the name I use to identify the entity -- the keyholder's SDSI name. That is an identifier that means something to me. The others are all subject to the John Wilson problem.

Of course, the SDSI name can also be confused. This is because of the way we are built to use names, but I don't have time to go into that in detail here. Needless to say, this whole topic needs a lot of work.

Using pictures instead of names, as was suggested in another thread, might be better, but I do know of people who look so much alike that even that is subject to confusion.

- Carl