Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
CA/WoSign Issues: Difference between revisions
Jump to navigation
Jump to search
Misc updates
(Update N and P) |
(Misc updates) |
||
| Line 68: | Line 68: | ||
''(a.k.a. "Incident -1")'' | ''(a.k.a. "Incident -1")'' | ||
On April | On April 3rd, 2015, WoSign was contacted by Google, who were concerned about Baseline Requirements violations in recently-issued certificates from WoSign. Instead of specifying the violations directly, Google asked WoSign to check their certificates against their CPS. The following list of problems is a combination of those found by WoSign themselves and those pointed out later by Google: | ||
* | * Incorrect or missing policy OIDs in all or most subscriber certificates; | ||
* | * CPS required use of obscure "Issuer Alternative Name" field which was not being used; | ||
* | * Inclusion of information in the Subject of the certificate (an advert) which was not validated subscriber information, and which contained a domain name, violating section 7.1.4.2 of the BRs; | ||
* The CPS documentation of validity periods did not match what was happening in practice; | |||
WoSign | * CPS required compliance only with RFC 2459 instead of the more restrictive RFC 5280. | ||
Google noted that many of these issues should have been caught by a competent auditor. WoSign's auditors at the time were Ernst and Young (Hong Kong). | |||
===WoSign Response=== | ===WoSign Response=== | ||
This incident was included in Google's report to Mozilla but not listed in the original public discussion. It has come up in the ensuing discussion in m.d.s.policy but no formal response has been made. | WoSign resolved this promptly at the time by a mix of changes to practice and changes to [https://www.wosign.com/policy/wosign-policy-1-2-11.pdf their CPS] (new versions 1.2.10 and 1.2.11). | ||
This incident was included in Google's report to Mozilla in August 2016 but not listed in the original public discussion. It has come up in the ensuing discussion in m.d.s.policy but no additional formal response has been made. It is possible that WoSign's upcoming report will cover this. | |||
===Further Comments=== | |||
WoSign acted quickly to resolve the issues, but this incident perhaps demonstrates that their CPS was not a definition of their practice, but more a document to be updated post-hoc to match changes made to their operations. | |||
Mozilla [https://wiki.mozilla.org/CA:BaselineRequirements#Audit_Mistakes documentation related to auditor errors] states that: | |||
<blockquote><i> | |||
When egregious mistakes were overlooked by the auditor, or there are a significant number of oversights, or the auditor did not notice BR compliance problems with the root or intermediate certificates, then the CA must resolve the issues and be re-audited. For the re-audit the CA can either get re-audited by a different auditor, or have the current auditor provide an immediate plan for correction and compliance, and then present a mid-term partial audit following that plan. In either case, the auditor must provide documentation about steps they are taking to avoid making the same mistakes in future audits. If the auditor fails to assure Mozilla that they have corrected the deficiencies in their auditing process, then their standing as a trusted auditor for the Mozilla root program may be jeopardized. | |||
</i></blockquote> | |||
As Mozilla was not aware of this incident at the time, we were unable to make a judgement on whether these issues rose to an appropriate level of severity to require this response. | |||
==Incident L: Any Port (Jan - Apr 2015)== | ==Incident L: Any Port (Jan - Apr 2015)== | ||
| Line 134: | Line 150: | ||
[https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/gksYkOTLCwAJ List of crt.sh links to certificates involved] - total 33. | [https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/gksYkOTLCwAJ List of crt.sh links to certificates involved] - total 33. | ||
2016-09-04: [https://www.wosign.com/report/wosign_incidents_report_09042016.pdf Official incident report]. The report explains the two bugs, N1 and N2. WoSign classifies the misissuances as 21 N1 and 12 N2. However, they have misclassified one - line 2 of Figure 14 - so the actual | 2016-09-04: [https://www.wosign.com/report/wosign_incidents_report_09042016.pdf Official incident report]. The report explains the two bugs, N1 and N2. WoSign classifies the misissuances as 21 N1 and 12 N2. However, they have misclassified at least one - line 2 of Figure 14 - so the actual split may be different. | ||
====Bug N1==== | ====Bug N1==== | ||
| Line 204: | Line 220: | ||
===WoSign Response=== | ===WoSign Response=== | ||
WoSign have not yet been formally approached about this, and no response has been given yet in the thread where it was noted in m.d.s.policy. | WoSign have not yet been formally approached about this, and no response has been given yet in the thread where it was noted in m.d.s.policy. It is possible that WoSign's upcoming report will cover this. | ||
==Incident V: StartEncrypt (July 2016)== | ==Incident V: StartEncrypt (July 2016)== | ||