Hey Kathleen, hey list, I really don't get why Mozilla is pushing so hard on the Chinese and at the same time let others get away. For example the Comodo case from today. Isn't that a much worse incident than what has happened here. People were able to issue certs for other people domains. When I read the WoSign answer to the current case (https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf) I personally felt, that they completely understood the seriousness of the situation. I doubt we'll see a professional answer like this in the current Comodo case. But then - of cause - Comodos headquarter is in the United States and not in China.
I feel like Mozilla is misusing its market power in a beginning trade war and this is not a good thing for the Mozilla Foundation. We all trust Mozilla to fight for a free web and not to choose sides in a trade war. Best, Nikolai Am Donnerstag, 13. Oktober 2016 18:50:02 UTC+2 schrieb Kathleen Wilson: > All, > > 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 [1][2]. 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[3]. > > 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 > SHA-1 Fingerprint > 16:32:47:8D:89:F9:21:3A:92:00:85:63:F5:A4:A7:D3:12:40:8A:D6 > SHA-256 Fingerprint > D6:F0:34:BD:94:AA:23:3F:02:97:EC:A4:24:5B:28:39:73:E4:47:AA:59:0F:31:0C:77:F4:8F:DF:83:11:22:54 > > 2) Subject: CN=Certification Authority of WoSign, OU=null, O=WoSign CA > Limited, C=CN > Certificate Serial Number: 5e68d61171946350560068f33ec9c591 > SHA-1 Fingerprint > B9:42:94:BF:91:EA:8F:B6:4B:E6:10:97:C7:FB:00:13:59:B6:76:CB > SHA-256 Fingerprint > 4B:22:D5:A6:AE:C9:9F:3C:DB:79:AA:5E:C0:68:38:47:9C:D5:EC:BA:71:64:F7:F2:2D:C1:D6:5F:63:D8:57:08 > > 3) Subject: CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA > Limited, C=CN > Certificate Serial Number: 6b25da8a889d7cbc0f05b3b17a614544 > SHA-1 Fingerprint > FB:ED:DC:90:65:B7:27:20:37:BC:55:0C:9C:56:DE:BB:F2:78:94:E1 > SHA-256 Fingerprint > D4:87:A5:6F:83:B0:74:82:E8:5E:96:33:94:C1:EC:C2:C9:E5:1D:09:03:EE:94:6B:02:C3:01:58:1E:D9:9E:16 > > 4) Subject: CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN > Certificate Serial Number: 684a5870806bf08f02faf6dee8b09090 > SHA-1 Fingerprint > D2:7A:D2:BE:ED:94:C0:A1:3C:C7:25:21:EA:5D:71:BE:81:19:F3:2B > SHA-256 Fingerprint > 8B:45:DA:1C:06:F7:91:EB:0C:AB:F2:6B:E5:88:F5:FB:23:16:5C:2E:61:4B:F8:85:56:2D:0D:CE:50:B2:9B:02 > > 5) Subject: CN=StartCom Certification Authority, OU=Secure Digital > Certificate Signing, O=StartCom Ltd., C=IL > Certificate Serial Number: 01 > SHA-1 Fingerprint > 3E:2B:F7:F2:03:1B:96:F3:8C:E6:C4:D8:A8:5D:3E:2D:58:47:6A:0F > SHA-256 Fingerprint > C7:66:A9:BE:F2:D4:07:1C:86:3A:31:AA:49:20:E8:13:B2:D1:98:60:8C:B7:B7:CF:E2:11:43:B8:36:DF:09:EA > > 6) Subject: CN=StartCom Certification Authority, OU=Secure Digital > Certificate Signing, O=StartCom Ltd., C=IL > Certificate Serial Number: 2d > SHA-1 Fingerprint > A3:F1:33:3F:E2:42:BF:CF:C5:D1:4E:8F:39:42:98:40:68:10:D1:A0 > SHA-256 Fingerprint > E1:78:90:EE:09:A3:FB:F4:F4:8B:9C:41:4A:17:D6:37:B7:A5:06:47:E9:BC:75:23:22:72:7F:CC:17:42:A9:11 > > 7) Subject: CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., > C=IL > Certificate Serial Number: 3b > SHA-1 Fingerprint > 31:F1:FD:68:22:63:20:EE:C6:3B:3F:9D:EA:4A:3E:53:7C:7C:39:17 > SHA-256 Fingerprint > C7:BA:65:67:DE:93:A7:98:AE:1F:AA:79:1E:71:2D:37:8F:AE:1F:93:C4:39:7F:EA:44:1B:B7:CB:E6:FD:59:95 > > 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 [4]. > -- 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[5] 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[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. > > 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. > > Notes: > * 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. > > Thanks, > Kathleen > > [1] > https://blog.mozilla.org/security/2015/04/02/distrusting-new-cnnic-certificates/ > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1177209 > [3] > https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/edit# > [4] https://wiki.mozilla.org/RapidRelease/Calendar > [5] > http://www.webtrust.org/licensed-webtrust-practitioners-international/item64419.aspx > [6] https://wiki.mozilla.org/CA:BaselineRequirements _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
