STS and lockCA

Dear public-webapps,

I would like to propose a small extension to the current draft 
specification for Strict Transport Security.
http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html

The Problem
-----------

At the moment, if one CA in a browser has a root compromise or other 
issuing problem, all websites are potentially at risk. Root certificates 
are trusted to issue end-entity certificates for any site. This means 
that a root compromise or other problem at RandomCA can affect people 
who aren't customers of RandomCA. As the number of CAs in each browser 
increases, the possibility of such a problem occurring increases.

A good recent example was the fact that one or two CAs were found to 
have faulty issuing software which happily issued certs for 
www.evil.com\0www.paypal.com, which were then trusted by browsers as 
being valid for www.paypal.com. If paypal.com had a way of telling 
browsers "valid certs for me only come from SuperSecureCA, not any other 
CA" then such a certificate would have failed in those browsers.

The Solution
------------

We would like to allow sites to partition the CA space so that 
compromises and problems in other parts of it don't affect them.

I therefore propose a simple extension to the STS standard; a single 
token to be appended to the end of the header:

lockCA

The effect of this token would be to get the browser to enforce, for 
that site, not only that HTTPS is required but that the CA may not 
change. The lock would be effective for as long as the forceHTTPS was in 
effect (i.e. same max-age).

There are a number of ways of defining "the CA" in the above sentence, 
and that would be subject to discussion. One simple way is the O field 
of the root, but there may be other, better ways. One might also want to 
store and lock to the EV-ness of the certificate.

A site may import resources from other domains. This opens up the 
possibility that an attacker can get a bogus cert for one of those 
instead. There are two workable ways of handling that. Either:

1) For full protection, the site just has to make sure that all the 
other sites also lock their CAs;

2) The lockCA system enforces a requirement that all dependent sites 
must also have CAs locked.

(Saying that all the sites must have the same CA produces undesirable 
network effects in the CA market.)

Clearly, this reduces flexibility for the site to change its certificate 
arrangements or vendor at short notice. If sites wanted to transition 
vendors, they would need to carefully manipulate their STS headers over 
time to create a window in which they could switch. Many sites may 
decide this trade-off in complexity is not worth it. But high-value 
sites such as Paypal or banks may decide differently.

I am interested in the group's feedback on this proposal.

Gerv

Received on Thursday, 1 October 2009 16:51:54 UTC