Thanks again to all of you who have put in so much time and effort to determine what happened with WoSign and StartCom and discuss what to do about it.
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. I also believe that the deception continued even after Mozilla directly asked WoSign about this. WoSign has lost my confidence in their ability and intention to follow Mozilla's policies. Therefore, I think we should respond similarly to WoSign as we did to CNNIC . Unfortunately, the number of certificates and the timescales involved are such that we prefer not to create a list of the domains for which previously-issued certs that chain up to the Affected Roots may continue to be trusted, so our approach will be a little different, as Gerv previously described.
Within this message, the term “Affected Roots” applies to the following 7 root certificates.
1) Subject: CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN
Certificate Serial Number: 50706bcdd813fc1b4e3b3372d211488d
2) Subject: CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN
Certificate Serial Number: 5e68d61171946350560068f33ec9c591
3) Subject: CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, C=CN
Certificate Serial Number: 6b25da8a889d7cbc0f05b3b17a614544
4) Subject: CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
Certificate Serial Number: 684a5870806bf08f02faf6dee8b09090
5) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
Certificate Serial Number: 01
6) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
Certificate Serial Number: 2d
7) Subject: CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., C=IL
Certificate Serial Number: 3b
I intend to move forward as follows, unless further information or input causes me to rethink this plan. Therefore, I will continue to appreciate your input, and this discussion is still open.
Mozilla will perform the following 4 actions. I have filed Bugzilla Bug #1309707 to track the engineering work for this. Please keep discussion here in mozilla.dev.security.policy, and not in the bug.
1) Distrust certificates chaining up to Affected Roots with a notBefore date after October 21, 2016. If additional back-dating is discovered (by any means) to circumvent this control, then Mozilla will immediately and permanently revoke trust in the Affected Roots.
-- This change will go into the Firefox 51 release train .
-- The code will use the subject key id (hash of public key) to identify the Affected Roots, so that the control will also apply to cross-certs of the Affected Roots.
2) Add the previously identified backdated SHA-1 certs chaining up to the Affected Roots to OneCRL.
3) No longer accept audits carried out by Ernst & Young Hong Kong.
4) Remove the Affected Roots from NSS after the SSL certificates issued before October 1, 2016, have expired or have been replaced.
WoSign may apply for inclusion of new (replacement) root certificates following Mozilla's normal root inclusion/change process (minus waiting in the queue for the discussion), after they have completed all of the following action items, and no earlier than June 1, 2017. If StartCom is able to provide proof enough to convince the Mozilla community in the mozilla.dev.security.policy forum that WoSign has no control (people or code) over StartCom, then StartCom may re-apply for inclusion earlier, as soon as the following action items are completed.
1. Provide a list of changes that the CA plans to implement to ensure that there are no future violations of Mozilla Policy and the Baseline Requirements.
2. Implement the changes, and update their CP/CPS to fully document their improved processes. The CP/CPS must explicitly state that it is prohibited to backdate the notBefore of certificates by more than one day.
3. Provide a public-facing attestation from a Licensed WebTrust Practitioner other than EY Hong Kong that the changes have been made. This audit may be part of an annual WebTrust CA audit.
4. Provide auditor attestation that a full performance audit has been performed confirming compliance with the CA/Browser Forum's Baseline Requirements. This audit may be part of an annual WebTrust BR audit. It must include a full security audit of the CA’s issuing infrastructure.
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.
* The new (replacement) root certificates may be cross-signed by the Affected Roots. However, the Affected Roots may *not* be cross-signed by the new (replacement) root certificates, because that would bring the concerns about the Affected Roots into the scope of the new roots.
* Mozilla's root inclusion/change process includes checking that certificates in the CA hierarchy comply with the CA/Browser Forum's Baseline Requirements.
Please let me know if I’ve missed anything.