On 13 April 2014 13:36, Florian Weimer <f...@deneb.enyo.de> wrote: > > The second reason is the following: What you are proposing is a value > judgement. But these have no place in the browser PKI. For example, > a properly contained sub-CA which issues interception certificates for > internal company use arguably increases security for the covered users > because content passing in and out can be reviewed independently from > the end points. Furthermore, many people will agree that interception > certificates for targeting terrorists and other criminals would result > in a net benefit as well. I think it is extremely difficult to draw > the line between "good" CA policy violations and "bad" ones, so it's > better not to start. >
I agree with everything you say above: the PKIX should be a way of reliably mapping between domain names and keys, and nothing more. Value judgements and policy belong at different layers of the stack that PKI (ideally, in layers with more user control and less exposure to 50-150 jurisdictions). Unfortunately, the people who set up the PKIX didn't understand this, and put a lot of foolish policy-like language into the hybrid CPS-Baseline Requirements-industrial complex. Now to make matters worse, there are *some* cases where we really expect CAs to be doing extra legwork and revoking proactively. Basically, that's any situation where we should expect centralisation of expertise to be socially productive. Looking for and revoking certs that *without the domain's knowledge* had a weak key (RNG bugs, for instance) in it is an appropriate thing for CAs to refuse to issue/revoke on. Heartbleed could turn into such a scenario, where we really think that some large and identifiable set of certs now have untrustworthy keys, but the evidence isn't there yet. > Requesting certificates with the intent of leaking the private key is > against the rules, so just don't do it. It is debatable whether the > rules makes sense (especially the CA-initiated revocations on key > compromise, as mandated by Mozilla's rules, seem problematic to me), > but then the rules need changing. > The cloudlfarechallenge.com case is totally different to a case where a domain was unknowingly using a weak key. Here we have a scenario where the purpose of the domain is to *test* whether the name <-> key mapping is secure. Nobody is going to that site for any other purpose. Of course cloudflare could rekey the site now that the contest has been won, but actually that would be slightly inconvenient to its users, since they can't check claims of key compromise on Twitter as easily if the key on the site changes. And probably they want to leave it running a vulnerable OpenSSL, so we can learn how much the blackhats and intelligence agencies could have done with this bug. Another distantly related example would be a site that knowingly selects an RSA key with more than two factors, as an informed performance/security tradeoff. I think that forcing CAs to revoke in such cases is foolishly importing judgement calls into the PKIX layer, just as much as going after the "terrorists and other criminals'" certs would be. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
