In the PKI ("public key infrastructure") world, there is a written practice that the user, sometimes known as the relying party, should read the CPS ("certificate practice statement") and other documents before being qualified to rely on a certificate. This would qualify as industry practice and is sensible, at least on the face of it, in that the CA ("certificate authority") can not divine what you are going to use the cert for. Ergo, the logic goes, as relying party, you have to do some of the work yourself.
However, in the "PKI-lite" that is in place in x.509 browser and email world, this model has been simplified. Obviously, all of us who've come into contact with user software and the average user know that the notion of a user reading a CPS is so ludicrous that it's hardly worth discussing. Of course, we need another answer.
There are many suggestions, but the one that is in effect is that the browser, or more precisely, the software vendor, is the one who reads the CPS, on behalf of the users. One way to look at this is that this makes the browser the relying party by proxy, as, in making its assessment, it reads the CPS, measures it against own needs, and relies on audits and other issues. (By way of disclosure, I audit a CA.)
Unfortunately, it cannot be the relying party because it simply isn't a party to any transaction. The user remains the relying party, but isn't encouraged to do any of the relying and reading stuff that was mentioned above. That is, the user is encouraged to rely on the certificate, the vendor, the CA and the counter-party, all on an article of blind faith in these people and processes she has never heard of.
This dilemma is better structured as multi-tiered authorities: The CA is the authority on the certificates and their "owners." The software vendor is the authority on the CAs, by means of their CPSs, audits, etc.
Such a re-drawing of the map has fairly dramatic consequences for the PKI. The widespread perception is that the CA is highly liable -- because that's the "trust" product that they sell -- and the browser is not. In principle, and in contract law, it might be the other way around, as the browser has an agreement with the user, and the CA has not. Where the perception might find comfort is in the doctrine of duty of care but that will generally limit the CA's liability to gross negligence. Either way, the last word on this complicated arrangement might need real lawyers and eventually real courts.
It has always been somewhat controversial to suggest that the browser is in control, and therefore may need to consider risks, liabilities and obligations. But now, Paul Hoffman has published a rather serious piece of evidence that Microsoft, for its part, has taken on the R/L/O more seriously than thought:
If a user running Windows XP SP2 in its default configuration removes a root certificate that is one that Microsoft trusts, Windows will re-install that root certificate and again start to trust certificates that come from that root without alerting the user. This re-installation and renewed trust happens as soon as the user visits a SSL-based web site using Internet Explorer or any other web browser that uses the Cryptographic Application Programming Interface (CAPI) built-in to Windows; it will also happen when the user receives secure email using Outlook, Microsoft Mail, or another mail program that uses CAPI, as long as that mail is signed by a certificate that is based on that root certificate.
In effect, the user is not permitted by the software to make choices of reliance. To complete the picture, Paul was careful to mention the variations (Thunderbird and Firefox are not effected, there is an SP2 feature to disable all updates of roots, Vista has the same problem but no override...).
This supports the claim, as I suggested above, that the effective state of play -- best practices if you'll pardon the unfortunate term -- is that the software vendor is the uber-CA.
If we accept this conclusion, then we could conceivably get on and improve security within these limitations, that the user does little or nothing, and the software manufacturer decides everything they possibly can. OK, what's wrong with that? From an architectural position, nothing, especially if it is built-in up-front. Indeed this is one of the core design decisions of the best-of-security-breed applications (x9.59, Skype, SSH, Ricardo, etc. Feel free to suggest any others to the list, it's short and it's lonely.)
The problem lies in that software control is not stated up-front, and it is indeed denied by large swathes of securityland. I'd not be surprised if Microsoft themselves denied it (and maybe their lawyers would be right, given the rather traumatic link between phishing and mitm-proof-certificates...). The PKI state-of-denial leaves us in a little bit of a mess:
To extract from this mess probably takes some brave steps. I think I applaud Microsoft's practice, in that at least this makes that little part clearer.
They are in control, they are (I suggest) a party with risks, liabilities and obligations, so they should get on and make the product as secure as possible, as their primary goal. This includes throwing out bits of PKI best practices that we know to be worst practices.
They are not the only ones. Mozilla Foundation in recent years has completed a ground-breaking project to define their own CA processes, and this evidences great care and attention, especially in the ascension of the CA to their root list. What does this show other than they are a party of much power, exercising their duty of care?
Like Microsoft, they (only) care about their users, so they should (only) consider their users, in their security choices.
Will the CAs follow suit and create a simpler, more aligned product? Possibly not, unless pushed. As a personal remark, the criteria I use in auditing are indeed pushing dramatically in the direction of better care of risks, liabilities and obligations. The work to go there is not easy nor trivial, so it is no wonder that no CA wants to go there (and that may be an answer to those asking why it is taking so long).
Even if every CA stood forth and laid out a clear risks, liabilities and obligations statement before their relying parties, more would still need to be done. Until the uber-CAs also get on board publically with the liability shift and clearly work with the ramifications of it, we're still likely locked in the old PKI-lite paper regime or shell game that nobody ever used nor believed in.
For this reason, Microsoft is to be encouraged to make decisions that help the user. We may not like this decision, or every decision, but they are the party that should make them. Old models be damned, as the users surely are in today's insecurity, thanks in part to those very same models.Posted by iang at August 8, 2007 07:14 AM | TrackBack