136
edits
Changes
→Revocation: tweaks
8. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate; …<br>
10. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or<br>
11. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise, methods have been developed that can easily calculate it based on the Public Key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence that the specific method used to generate the Private Key was flawed."
</blockquote>
* The decision and rationale for delaying revocation will be disclosed to Mozilla in the form of a preliminary incident report immediately; preferably before the BR mandated revocation deadline. The rationale must include an explanation for why the situation is exceptional. Responses similar to “we deem this misissuance not to be a security risk” are not acceptable. This rationale should be provided on a per-Subscriber basis.
* Any decision to not comply with the timeline specified in the Baseline Requirements must also be accompanied by a clear timeline for when the problematic certificates will be revoked and supported by the rationale to delay revocation.
* The issue will need to be listed as a finding in your CA’s next BR audit report or attestation statement.
* Your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable.
* That you will perform an analysis to determine the factors that prevented timely revocation of the certificates, and include a set of remediation actions in the final incident report that aim to prevent future revocation delays.
