All, Here’s a summary of your input, and my thoughts.
~~ What about NSS? We discussed this in the NSS team call last week, and the general decision was that the rules we put in place regarding these Affected Roots for Mozilla will also be put in place inside NSS. That doesn’t help all consumers of the NSS root store, just the ones who use NSS validation. I’m not sure what we can do about other consumers of the NSS root store, other than publish what we are doing and hope those folks read the news and update their version of their root store as they see appropriate for their use. ~~ Several comments about Mozilla’s Action #4. > 4) Remove the Affected Roots from NSS after the SSL certificates > issued before October 1, 2016, have expired or have been replaced. I will change the date to October 21, 2016 to be consistent with the date previously listed. When I wrote that we would remove the Affected roots after the certs had expired or been replaced, I was incorrectly only thinking about the 1-year SSL certs. My intent was to find a reasonable date in the future when current clients have had enough notice and time to transition to other root certificates. Based on the data from Kurt, it looks like a year might be too little time. Two years seems like a lot of time. ~~ Regarding actions for the CA… Several suggestions that Mozilla require or strongly urge the CA owners of the Affected Roots to reach out to their subscribers asap to let them know about these changes, and give those clients time to transition. > subscribers > deserve some warning even of the risk that invalidation would > happen in future, not to mention that they will not be able to > receive renewals from these CAs, at least for some time. > WoSign and StartCom are still actively selling certs which cost > one hundreds or more dollars. I think Mozilla should mandate > that WoSign/StartCom inform their users of such incidents or > at least the imminent distrust by Mozilla I would hope that the CA would figure out how to communicate this to their customers in order to help their customers have minimum disruption. The CA could create new root certs, and put information on their website to make it easier for users to manually import their new root certs, and also put information on their website for their current customers who will need to get new intermediate certs, and instruct their customers about downloading the new root certs. That’s basically what CAs whose root certs aren’t included in NSS (and aren’t cross-signed by an included root) have to do anyways. I’m not sure what I could reasonably require (and enforce) of the CA in regards to communicating with their customers. I recall that my security blog about CNNIC got censored in China, so I'm not sure what Mozilla can do about informing the CA's customers of this pending change/impact. ~~ >> 4. Provide auditor attestation that a full performance audit has been >> performed confirming compliance with the CA/Browser Forum's Baseline >> Requirements[6]. This audit may be part of an annual WebTrust BR >> audit. It must include a full security audit of the CA’s issuing >> infrastructure. > > I would recommend that Mozilla retain the option to approve the > security auditor, and that it be an external company. I will add the sentence: “The auditor must be an external company, and approved by Mozilla.” ~~ > 5. 100% embedded CT for all issued certificates, with embedded SCTs > from at least one Google and one non-Google log not controlled by the > CA. As suggested, I will add: ”The CA SHOULD NOT fulfill the non-Google log requirement by using logs that they run themselves. For as long as they do so, they will need to demonstrate ongoing evidence of efforts to get other logs to take their volume, and why those efforts have not been successful." > I should add that if StartCom/WoSign have a CT log codebase capable of > taking the volume necessary, they could always open source it, and then > pay a 3rd party to run an instance of it, with an arms-length contract. > That sort of solution may well be acceptable, depending on contract details. I don't think that changes the sentence that is being added. ~~ > Please can Mozilla ensure that both EY Hong Kong and the overarching parent > organisation in the United Kingdom (in Southwark) are informed of this ban > and get a copy of Mozilla's findings if they haven't already ? I think Gerv is doing that. It will also impact CNNIC. https://bugzilla.mozilla.org/show_bug.cgi?id=1177209#c13 So, does CNNIC's audit get grandfathered in? Or does CNNIC have to get audited by a different auditor before they can re-apply for full inclusion? ~~ I think we need to add an action item regarding making sure that all of the code and systems used by the CA are well-designed and updated, and fully meet the CA/Browser Forum’s Baseline Requirements. What would be a reasonable requirement to state for each of the CAs? Are there tests that we could require the CA to run/pass that would satisfy our concerns about quality of the code and systems? Thanks, Kathleen _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
