August 08, 2007

Microsoft asserts itself as an uber-CA

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:

  • uber-CAs probably have some liability, but will likely deny it
  • users are supposed to read the CPS, then rely. But don't or won't, and do.
  • CAs claim to the users as if they have the liability, but write the CPS as if they have none.
  • developers read from the PKI practices book, and write code according to uber-policy...
  • (We can add many other issues which lead PKI into harm, but we are well past the average issue saturation point already.)

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
Comments

another way of looking at it ... is that in some cases, the browser vendors have charged CAs quite a bit of money to get their (self-signed) certificate included in the browser.

These aren't x.509 identity digital certificates in the traditional sense ... these tend to be self-signed digital certificates ... which turn out to be a convenient packaging technique for public keys that are to be included in a trusted repository (of public keys) ... aka rather than these digital certificates being a trust mechanism ... these kinds of digital certificates are purely public key packaging mechanism ... and the act of including the public key in the (browser's) trusted repository of public keys is the trust mechanism.

Now the certification authorities (CA), who have typically paid money to have their public key included in the browser's repository of trusted public keys, ... can turn around and charge their clients money for digitally signed (trust) digital certificates (verifiable by one of the public keys included in a browser's repository of trusted public keys).

So the ability to remove a (certification authorities) public key from a browser's repository of trusted public keys ... might also be interpreted as impacting a whole economic ecosystem (since the CA's clients stop receiving benefit from having the certificates, they paid for, being accepting ... which in turn impacts the economic operation of the CA that had paid money to have their public key included in the browser's trusted public key repository).

Having the browser vendor automatically reload public keys into the browser's repository of public keys ... might be construed as the browser vendor actually maintaining the master copy of trusted public keys (which they probably have charged quite a bit of money to include a public key) ... and any specific browser's copy is purely a "local" cache. While it might superficially appear that a browser's local copy of trusted public keys is purely autonomous ... protocols implemented by the browser software could actually manage cache consistency with the vendor's master copy. In theory, not only could a cache consistency algorithm reload trusted public keys that have been deleted from the local cache ... but might also load new public keys that had never been in a local cache. Such an hypothetical cache consistency implementation could also do away with any certificate revocation kludge for certification authority public keys (we've made past claims that our repeated criticism of certificate revocation operation led to the OCSP effort).

In any case, the whole public key reload effort might possibly be a browser vendor, certification authority, CA-client economic ecosystem ... having little or nothing to do directly with PKI relying parties.

This is orthogonal to the traditional trusted 3rd party certification authority having no real business foundation ... aka the relying party typically doesn't have any sort of contractual relationship or other mechanism on which to base liability and/or recourse with regard to anything done by the certification authority.

This is somewhat highlighted by the federal PKI operation where the GSA (as agent for federal gov. relying parties) has contracts with the various approved certification authorities (creating a basis for legal reliance between the relying parties and the certifying operations). These "contracts" bridge the legal and contractual gap with regard to reliance that occurs in many of the deployed PKI operations

misc. past posts mentioning the contractual work around in the federal PKI to the typical trusted 3rd party kludge:
http://www.garlic.com/~lynn/aadsm12.htm#29 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm16.htm#16 Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
http://www.garlic.com/~lynn/aadsm17.htm#9 Setting X.509 Policy Data in IE, IIS, Outlook
http://www.garlic.com/~lynn/aadsm18.htm#7 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm22.htm#19 "doing the CA statement shuffle" and other dances
http://www.garlic.com/~lynn/aadsm23.htm#14 Shifting the Burden - legal tactics from the contracts world
http://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minimum liability, the CA trap, the market in browser governance
http://www.garlic.com/~lynn/2003l.html#45 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates
http://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005i.html#21 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
http://www.garlic.com/~lynn/2007l.html#2 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#6 John W. Backus, 82, Fortran developer, dies

Posted by: Lynn Wheeler at August 7, 2007 09:36 PM

Mozilla doesn't charge CAs for inclusion in Firefox.

- A

Posted by: Asa Dotzler at August 8, 2007 02:39 AM

Neither does Microsoft; at least directly. What they do is demand annual audits from CAs whose root certificate include in IE. However, I agree that this practice of reinstalling deleted certificates was most probably decided _in part_ on the basis of avoiding economic conflicts.

Posted by: Patroklos Argyroudis at August 8, 2007 04:26 AM

Is this more evidence of CA-like behaviour?

Posted by: Microsoft revokes a code signing certificate.... at August 9, 2007 08:33 AM
Post a comment









Remember personal info?






Hit preview to see your comment as it would be displayed.