On Friday, October 7, 2016 at 9:10:29 AM UTC-7, Gervase Markham wrote: > I should start by reiterating what you already know, but might be a > useful reminder for others - no agreement has been made between Mozilla > and Qihoo/StartCom/WoSign. We gave them advice on what we thought the > community might like to see, but they are responsible for their plan, > and the Module Owner will take the final decision on what action Mozilla > will take. I have my own opinions, which clearly will carry some weight, > but the decision is not mine. So the following is an explanation of how > I myself am viewing the situation.
Understood, and with that same disclaimer... > My view is that WoSign was not run in the way a CA should be run, in a > variety of ways. This was not generally true of StartCom, which was > reasonably well-run (although not perfect). One possible issue with this is that there hasn't been a similar question about StartCom's past practices. I think that, up until the discussion began, particularly around the backdating of certificates, it might have been said the same about WoSign - that is, the view that the issues were 'minor'. > Once WoSign bought StartCom > and StartCom started being influenced by WoSign technology and > management, things went downhill there too. But I feel that > re-separation of the two - at all levels, ownership, management and > technology - might allow StartCom to continue as a going concern. This > would imply StartCom has management Mozilla trusts, no ownership > connection through WoSign, and uses reliable technology not authored at > WoSign. Well, there can never be a perfect separation - though the WoSign report indicates that there wasn't a complete close of financial disbursements, there was a significant organizational and operational shift made under the terms of the contract that StartCom is, at present, significantly enmeshed with WoSign, and that process happened over a year. We know that the investors and principles have changed, and thus the priorities have changed. I think, in the case of many CAs, we might say that, prior to their misissuance, they were well-run CAs. But isn't that part of the problem? By taking into perspective a historical view, rather than an incident-based view, it naturally gravitates towards favoring incumbents (those who have been able to operate long enough to be considered 'mature' when a misissuance happens), and begins to introduce subjective-based weights into a process that is, ideally, largely objective. The implication here - that factors such as management and technology bear into decision making - suggest that future inclusion or maintenance requests need to consider this. I don't disagree that these could be valuable axis' in determining trust, but I think historically, Mozilla's Root Store has erred on the side of objectivity. For example, we see discussions about particular countries views' on wiretaps brought up from time to time, or particular companies' associated businesses providing wiretap/intercept capabilities, but on the whole, these associations are rejected as being influential in the decision to include or not - instead, it's based on (ideally) objective evaluations against audit criteria and technical standards. So now when we have a failure to abide by those criteria, why shouldn't we adhere to that same set of standards? Why introduce these subjective elements into the decision making? Clearly, there's a set of priorities at play here - what are the ultimate goals for Mozilla's Root Store? What are the things to prioritize? As a thought experiment, I'm trying to get to the heart of the reasoning of why a CA (and all affiliated entities) should or should not be distrusted when an incident occurs. An argument for distrust is that it strongly signals to the ecosystem that there is a serious risk in non-compliance. As such, the greater the fiduciary or business risk, the greater justification there is for investments into policies, practices, and technologies to minimize that risk. If you eliminate any risks, what incentives are there to align on proper behaviour, especially given the economic structures of CA trust, such that there is no long-term reputational brand damage for misissuance, nor is there any way to discover it (from people 'outside the know'). That is, to an end user, there's no distinction in trust between "Honest Achmed's Gently Used Certificates" and "Best CA in the world" - and as such, there's no incentives for site operators to consider one or the other. An argument against distrust is generally that of user impact. Distrust options, at present, vary in proportionality of user impact (generally with the size of the CA), and thus the larger the CA, the more difficult it can be seen to take action. But is that Mozilla's justification or set of priorities? It might be useful to understand what you (and other module contributors, to be particular, since we all may have different views) prioritize. To me, I value long-term ecosystem health, and the desire for objectivity, more than user impact. This may not be entirely fair, as we see in past incidents, but the fact that we keep having incidents I believe suggests that something more than the status quo is needed. > I would say the key differences with Symantec are that WoSign's > misdemeanours involved actual misissuance to third parties (e.g the > github certificates) and provable lying, e.g. about ownership and SHA-1 > backdating. I don't see either of those serious components in the > Symantec case. This is not to minimise what happened at Symantec, but I > do think the WoSign situation is more serious. But then, even before > this, I think it was already the case that you took a dimmer view of the > happenings at Symantec than I did (your view perhaps being based on more > complete information). This is a disconcerting viewpoint for me. It suggests that you view "We've sacked the people responsible" as an acceptable response, so long as we can't prove the CA is lying. While I agree that we should take into consideration that which we definitely know, and the facts surrounding the issue, I highlight this because, in the majority of cases, we don't know or won't be able to definitively prove the misissuance. In these scenarios, should our position be to 'fail open' (and continue to trust the CA, with some set of remediation plan) or 'fail closed' (and remove the CA until it can prove it's in compliance). The issue I have with 'fail open' is that you can see, throughout the engagement with CAs, significant leeway is given to them for slipping past compliance dates and practices, so much that it's become the rule, rather than the exception, that a CA will miss dates. I appreciate the need to be sensitive to business pressures, but I think it meaningfully impairs improvements in the WebPKI. While I realize this sounds closer to a 'zero tolerance' policy than even perhaps I'd be comfortable with, I think the risk - to global user safety and trust - is significant here. > As I said in my previous email, Qihoo's plans are enough, I think, count > as "data relevant to our current view" and I think we should at least > consider the two CAs separately, although that doesn't preclude reaching > the same conclusion for each. I'm uncomfortable with this, because it's a promise, with no timeline for delivery, and significant risk until it's met. This gets back to the question of priorities and goals for the root program. Would we accept a new CA that presented serious issues but promised to resolve them? I think history shows quite clearly that no - the community rejects such applications until the CA is able to resolve, and demonstrate they resolve them. The fact that this causes delays to the CA's application therefore incentivizes getting it correct. If the view is that once you're in, there's a higher bar to get out, then it sets a double standard as to how the program is maintained, and one that I fear may put users at risk. > As noted above, no agreement has been reached. However, as the person > who took a meeting with Qihoo's Head of Security, who will now chair > StartCom, I feel that he does understand the issues and I am willing to > give his chairmanship and Inigo Barreia's CEO-ship an opportunity to > demonstrate they can run a CA well. Inigo's track record at Izenpe is > good - I'm not aware of any incidents involving them. Does this suggest that Mozilla would be willing to meet with CA applicants' CSO/CEOs, to get a 'gut sense' about whether they're "serious", and then decide to overlook failures to abide by Mozilla's inclusion requirements? I ask this, because I think this highlights some of the disconcerting disconnect with "Oh, I know Jim, Jim's a good guy" sort of approaches. It may be that the answer is yes, which would be a consistent standard. However, if the question is "maybe", then it's useful to work through when it would and would not be an acceptable situation, otherwise the risk is that the standard of trust is varied, rather than consistent. > Indeed, this would be a bad situation - which is why, in my mind, a > different deal for StartCom would be predicated on them moving quickly > to a position where they share _nothing_ with WoSign, rather than > everything. How, if ever, will the community be assured of this? This is something that's quite intangible - which is the very problem. > I think that the plan we propose for WoSign is a clear statement that > the sort of behaviours seen there are unacceptable. I don't see them as > getting off lightly. No, but it suggests that if you play the game of organizational structuring, you can reduce risk of consequence. It suggests that, rather than integrate systems (such as Symantec has done with brands, or as Entrust is doing with AffirmTrust), you maintain them as "arms-distance" (legally speaking) entities, while the elements that the public cannot see are shared. Is that uncertainty worth introducing into the ecosystem? Is it something we already accept? I'm not sure, but I'm quite uncomfortable with the implications of the line of thinking. Then again, I assume CAs will do the worst thing possible, and every loophole possible. While perhaps not true of all CAs, in aggregate, the market incentives are so aligned that the worst behaviour reaps the most reward, and that's disturbing. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
