I've been debating whether to ditch this or not, but I feel it needs to be said. So, as the Duke of Wellington may, or may not, have said, "publish, and be damned". Cheers, Ben. ..................................... 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. -- SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi