On Monday, October 10, 2016 at 5:04:14 PM UTC-7, Kathleen Wilson wrote: > Based on the information that I have seen regarding WoSign, I believe that > WoSign intentionally bent the rules in order to continue issuing SHA-1 SSL > certs, when they knew full well that was no longer allowed. WoSign has lost > my confidence in their ability and intention to follow Mozilla's policies.
I suppose at core question here is whether it's believed StartCom is any different, and why that is. It seems uncontroversial that this is true for WoSign, but the proposal to distinguish StartCom, a wholly owned subsidiary that actively participated in this deception and misissuance, be treated distinctly. This is where I think many of my arguments center around - the moral hazard it invites for participating CAs in the program seems, to many people commenting, to outweigh the potential benefits of not taking commiserate action against all of WoSign's branded CAs. > I think what you are saying is that the CA needs to re-apply for inclusion > with new root certificates (not their old root certs). Correct? Yes > If yes, I am inclined towards that idea too. > I've heard that it would cause continuity issues, but I don't get that. Seems > to me that *if* the CA were to get their new root approved/included, that > they could resume issuing from their new root instead of their old root. CAs would and could address that continuinity by signing their new root with their old (distrusted) root, and only issuing certificates with the new root, while the old root fades into obsolecence. This offers continuity because the certs issued by new-root could be trusted by clients that only trust old-root, by cross-signing new-root with old-root, while still offering the assurances to the public that old-root can safely be distrusted. It does create the issue that, in the absence of trusted timestamps or whitelist, there's no way to maintain continuity for old-root's existing certificates, and that's a difficult decision, but in the goal of protecting users, we should take the conservative approach of "assume the worst" - precisely because so much of what goes on in the CA ecosystem is unobserved, even in a world with CT, due to the reliance on auditors whose fiduciary duty is to the CA, not to the public. > Why do we need a minimum of 1 year? > What purpose does that serve? > If they meet all our requirements earlier, why couldn't we discuss it earlier > than 1 year? In general, we've seen CAs hastily react to things, and in the process, introduce new vulnerabilities. We've also seen CAs fail to do the necessary due diligence to holistically understand the failure and to design safe-guards to mitigate the issue. By setting a time limit, it serves two purposes: 1) As a consistent and neutral deterrent for others to engage in such behaviour, due to the economic and business risk that failing to act in a trustworthy manner would entail 2) As an expression of what the community believes is a reasonable minimum for a successful remediation of the issues in a way that will be thorough and sufficient enough to reconsider trust _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
