A recurring theme of m.d.s.policy is that a CA behaves in a way that falls short, sometimes far short of the reasonable expectations of relying parties and yet in the end Mozilla doesn't end up distrusting that CA because of the direct impact on relying parties, the indirect impact on subscribers, and then the indirect impact on Mozilla itself.
This suggests the need for some options short of distrust which can be deployed instead, but Mozilla does not seem to have any. If in fact it already does, this would be a great place to say what they are and discuss why they haven't been able to be used in recent cases. I have spent some time thinking about this, but I am only one person, and one with relatively little in-depth knowledge of the Mozilla project, so I think I will lay out the options I've thought about and invite feedback though particularly any alternative suggestions. 1. Implement "Require SCTs" for problematic CAs. Notify the CA they are obliged to CT log all certificates, inform subscribers etc. or their subscriber's certificates will suddenly be invalid in Firefox from some future date. This option would be a software change (to Firefox at least) making it able to reject certificates which chain to a particular root CA unless it is also presented with valid SCTs proving the certificate was CT logged. GOOD: Any certificates which aren't being logged are now much less useful to bad guys GOOD: Future bad certificates will more likely be seen in the CT logs and can be acted on directly by anyone. GOOD: Drives further uptake/ interest in CT logging which improves overall quality of the web PKI ? GOOD: Requires CA to actively contact subscribers, inform them of the issue, ensuring subscribers know of problematic behaviour by the CA. BAD: Requires non-trivial software development effort (unclear how much of this work is done in #944175, #1284256) BAD: Does not directly protect downstream users of NSS trust store. RISK: Hard to enforce notifications from CA to their subscriber. RISK: May create incentive for less security conscious subscribers to move to a CA that doesn't require SCTs, even though this increases risk for them and for their relying parties. 2. Create "at risk" category for problematic CAs which lasts some finite period of time (or a period to be set in each case). Notify the CA they are obliged to warn their subscribers of this status or leave the Mozilla programme immediately. Publicly announce "at risk" status and drive as PR. This option is purely a policy/ procedure change. Mozilla already reserves the right to distrust CAs. This would introduce a state in which the CA had been publicly warned that their behaviour fell short and must tell their subscribers that they are at risk of being distrusted. GOOD: Requires CA to actively contact subscribers, inform them of the issue, ensuring subscribers know of problematic behaviour by the CA. GOOD: Provides a clear stepping stone to distrust. GOOD: Might drive subscribers away from problematic CAs to ones with a better track record due to perceived risk of subsequent distrust. BAD: Doesn't directly DO anything to protect Mozilla's relying parties, purely a paperwork measure. RISK: Hard to enforce notifications from CA to their subscriber. 3. Split NSS trust store into two or more categories based on degree of trustworthiness. Maybe present a Firefox pref to pick "secure" vs "compatible" This option arguably punts on the problem, leaving it for end users or local administrators to decide whether the increased rate of trust failures is an acceptable or even desirable outcome from distrusting more CAs. GOOD: Might drive subscribers away from problematic CAs to ones with a better track record to increase their chance of acceptance GOOD: Gives relying parties something specific they can do short of making all their own trust decisions by hand. BAD: Reduces perceived value of basic inclusion in the Mozilla root programme. RISK: Press may cover this as Mozilla abandoning their role RISK: Might need software development to make this behaviour useful to ordinary end users Finally, I would like to mention, though I expect it to be shot down, a much more radical way forward. RP audits. Relying Party audits. Today audits are performed by a third party, selected and paid directly by the CA, largely for the benefit of the CA and secondarily for its subscribers. The auditors rarely find anything interesting (even when we know there was much to be found) and the result is of very little value to the people we care about in m.d.s.policy, the relying parties. I believe audits should be conducted on behalf of the relying parties, with auditors selected by them though still paid for ultimately by the CAs. The auditor's interim and final reports would go to relying parties, perhaps via trust stores like Mozilla or Google or perhaps via a new third party representing the relying parties (which today means basically the world population). The auditor's directions and goals would be set by the relying parties, for their benefit, rather than merely with the intention to produce an useless piece of paper and check the box. CAs would be under no obligation to subject themselves to RP audits, but of course if this were popularized it wouldn't make sense for a trust store to accept CAs that don't since they impose an incalculably greater risk on the relying parties. My model in thinking about this problem has been the Paris MOU. Historically by treaty the enforcement of most laws of the sea was left to flag states, sovereign entities which registered civilian vessels and permitted them to sail under that country's flag. Late last century Europe grew increasingly dissatisfied with the result: "flags of convenience" aka "open registers" in which a small country offered cheap registration to foreign operated vessels often with little or no actual enforcement. Dangerously under-maintained or poorly staffed vessels flagged by distant island nations threatened Europe's vital sea ports with pollution, fatal accidents and loss of cargo. So in Paris a Memorandum of Understanding was signed in which European port states agreed they'd all impose a new regime, vessels entering their ports could be inspected by officials working for the state the port was in, regardless of their flag. Vessels which failed inspection would be detained until they were improved, despite the cost to the port involved. Statistical models, rather than gut instinct, inform the decisions of which vessels are inspected and today this regime is so successful that has been replicated around the world. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
