Seven and a Half Non-risks of PKI: What You Shouldn't Be Told about

Public Key Infrastructure

By Ben Laurie.
Carl Ellison and Bruce Schneier wrote a critique of PKI, "Ten Risks of
PKI: What You're Not Being Told About Public Key Infrastructure",
which can be found here:
http://www.counterpane.com/pki-risks.html.
Whilst I agree with the conclusion ("Public-key infrastructure has
been oversold as the answer to many network security problems") I find
myself at odds with many of their arguments. So, I felt impelled to
write a response. And here it is.
It is also worth noting that, oversold or not, PKI is the only thing
we have right now that even remotely begins to solve some of the
problems we have.
Note that this will be almost meaningless unless read in conjunction
with the original article. "CE&BS" are, of course, Carl Ellison and
Bruce Schneier, and are quoted from their article. "BL" is yours
truly.
CE&BS: Before we start: "Do we even need a PKI for e-commerce?" Open any
article on PKI in the popular or technical press and you're likely to
find the statement that a PKI is desperately needed for e-commerce to
flourish. This statement is patently false. E-commerce is already
flourishing, and there is no such PKI. Web sites are happy to take
your order, whether or not you have a certificate.
BL: This is deliberately missing the point. Clients need no
certificate, but why would they? You don't need any kind of proof of
identity to buy things over the telephone or via mail order. However,
you'd be a fool to give money to someone you don't know in exchange
for a promise of goods. So, the shop is the one that needs (and,
indeed, has) a certificate. Proof that they are who they say they are.
CE&BS: Risk #1: "Who do we trust, and for what?"
BL: Again, we seem to be talking about client certificates here, which
are not relevant. A server certificate, which is relevant, says just
one thing: that the holder of the certificate owns the corresponding
domain name (i.e. the domain name named in the certificate does indeed
belong to the purchaser of that certificate).
Now, it can be argued that CAs don't check this relationship as
thoroughly as they might, but I know of no instance where it has turned
out to be false, and they do make some effort to ensure it is true.
It can also be said that they don't stand behind this assertion with
any great conviction, and that would seem to be true - but whatever
their legal liability may be, a CA that was shown to be negligent in
these matters will be out of business, fast.
You might ask "what use is the certificate, in that case?"
The answer is simple: if you get burnt, it tells you who burnt
you. You can then seek compensation. This can be rather hard if you
simply buy from Joe Average on the Internet.

There's also a technical issue: the security used in SSL/TLS is

dependent on one end or the other having a certificate for its
integrity. So the certificate provides a value simply by linking the
public key to the server name - it secures your shopping session.
CE&BS: Risk #2: "Who is using my key?"
BL: Client certificates again. They aren't the issue. Server
certificates _can_ be run in trusted environments, they _can_ have
good passwords. They _can_ be in tamperproof devices. And they often
are.
Of course, in every line of business, there will be those who don't
take the appropriate precautions. They will lose in the long run.
CE&BS: Risk #3: "How secure is the verifying computer?"
BL: At last, a risk I can agree with! However, it should be noted that
the verifying computer in the interesting case is the client's
computer. Cracking it to accept a forged certificate is going to be a
lot of effort for rather small gain in most cases.
CE&BS: Risk #4: "Which John Robinson is he?"
BL: When a certificate is used to verify a server DNS entry, there is
no possibility of confusion. Server names are globally unique, and
that's the end of it.
CE&BS: Risk #5: "Is the CA an authority?"
BL: The logic in this argument is flawed. The fact that X is not "an
authority" on Y does not mean that X cannot make a correct, verifiable
statement about Y. We do not care whether the statements made by a
certificate are "authoritative", we care whether they are true.
And to answer the final rhetorical question: " What harm is done if an
uncertified server were allowed to use encryption?", the answer is
that it would be susceptible to a Man in the Middle attack.
CE&BS: Risk #6: "Is the user part of the security design?"
BL: Once more, a point I have some sympathy with, but if you accept
that the purpose of a certificate is to bind a key with a DNS name
(and hence with the owner of that name), then the user does not need
to intervene. The browser checks the certificate matches, and our
needs have been fulfilled.
CE&BS: Risk #7: "Was it one CA or a CA plus a Registration Authority?"
BL: Again, I have to agree with this. RA+CA is a gaping security
problem. I think there may be a future for a related model, where
multiple CAs (or RAs, or somethings) collaborate to produce a single
certificate, but existing protocols and products do not support this
model.
CE&BS: Risk #8: "How did the CA identify the certificate holder?"
BL: Once more, switching back to uninteresting client certificates, it
is easy to knock holes in them. But this is not the point at

all. Server certificates _can_ be linked strongly with their owners,

and no magic is required - just company registrars and telephone
directories.
CE&BS: Risk #9: "How secure are the certificate practices?"
BL: This isn't really a risk at all, just FUD. Yes, CAs have to be
careful. So what's new?
CE&BS: Risk #10: "Why are we using the CA process, anyway?"
BL: Here's the crunch. Right now, We're using it because we need to be
sure we're doing business with who we think we are (where we are the
buyers, and "they" are vendors selling stuff on the Internet).
But, as CE&BS so rightly point out, SSO has to be the big opportunity
of PKI. But it can't be achieved with CAs as we know them today, and I
certainly find it most unlikely that it can be achieved at all with
identity certificates. Surely the appropriate role of PKI in this
brave new world is to bind _capabilities_ to keys. X.509 is not hugely
well suited to this but it can do it, and its what we've got. SPKI
might be better, but where is it? Sadly, it is still a twinkle in its
supporters' eyes.