Changes

On April 5th3rd, 2015 (XXXcheck date), WoSign was contacted by Google , who were concerned about multiple Baseline Requirements violationsin 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:

* Their Incorrect or missing policy OIDs in all or most subscriber certificates;* CPS documented one set required use of policies that their certificates were issued under, but none of their certificates matched their CPS.obscure "Issuer Alternative Name" field which was not being used;* Their certificates included non-verified Inclusion of information unrelated to subscribers as part in the Subject of the Subject certificate (an advert) which was not validated subscriber information in the DN, and which contained a domain name, violating section 7.1.4.2 of the BRs.;* Their The CPS documentation of validity periods did not match what was inconsistent happening in practice;* CPS required compliance only with RFC 2459 instead of the validity period more restrictive RFC 5280. Google noted that many of their certificates in these issues should have been caught by a way that was BR non-compliantcompetent auditor. WoSign CPS is here, although it's not clear if this is pre-fix or post-fix auditors at the time were Ernst and Young (XXX clarifying with RyanHong Kong): https://www.wosign.com/policy/wosign-policy-1-2-10.pdf

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.

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 numbers are 20 N1 and 13 N2split may be different.

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.