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
