On Aug 31, 11:34 am, Gervase Markham <g...@mozilla.org> wrote: > On 30/08/11 17:46, Boris Zbarsky wrote: > > > I was looking at our CA root list, and a lot of them seem like > > "specialist" CAs that would only issue certs for a limited range of > > hostnames. Could we formalize this, and have CAs indicate any such > > restrictions as part of their application, then enforce it on our end? > > There is a way to encode this in certificates, called basicConstraints, > although I suspect very few CAs do that. (Why limit your market?) I > guess NSS could have a feature to impose them on a CA from outside. > > > That would limit the extent to which a compromise of one of these > > "specialist" CAs could be exploited (e.g. we'd notice that a Dutch CA is > > being used to sign the Mossad's website and cry foul, without > > pre-pinning the CA for the presumably rarely visited Mossad site). > > Just because they are a Dutch CA doesn't mean they are necessarily only > working with Dutch sites. Verisign/Symantec is an American CA. > > We don't want to put ourselves in a position of entrenching incumbents.
Absolutely agreed > > In addition, even a CA focussed only on Dutch _companies_ would want to > issue certs for .com, because I'm sure a lot of Dutch companies have > ..com sites. Given that the aim would be to prevent them issuing bogus > certs for mozilla.org, paypal.com, twitter.com etc., I'm not sure many > of them Well I'm keen that the aim includes myonlinebankingaddress.co.uk as well. And there are plenty of roots in Firefox which I expect don't ordinarily issue .co.uk certs. In trying to think of non-entrenching approaches to improve the current system, 2 things come to mind. 1. Require CAs to publish every month the list of publicsuffix.org entries which they have currently valid end entity certificates issued against. That would allow browsers to add a not-before constraint on not-in-use suffixes for each CA. For specialist CAs, they'd likely notice an unusual suffix as part of the publication process or, if they'd not been aware of the issuance, the cert would become useless after just a few weeks. However, I suspect CAs would balk at this as someone (even if it's just a browser extension) is likely to turn it around and block certs with given suffixes until they've been published. There's also an increased cost to browser vendors, though with automation, I'd hope it wouldn't be too high. 2. Require end entity certs to be issued by an intermediary cert with basic constraints matching exactly the suffixes of the domain(s) used in the end-entity certs. This would impose a cost on CAs to maintain these intermediaries, which would hopefully minimise their creation. This would (particularly for smaller CAs) make it less likely that an intruder can issue a cert for an arbitrary suffix, and might subsequently allow for more targeted blacklisting. David _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
