This email begins discussion of a potential change to section 6 of the Mozilla Root Store Policy <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation>.
The method by which a person may provide a CA with proof of private key compromise has been an issue discussed on the mdsp list <https://groups.google.com/g/mozilla.dev.security.policy/c/DeztURyCHPo/m/1IZnDsMuAQAJ> this past year. According to section 4.9.1.1 of the CA/Browser Forum's Baseline Requirements <https://cabforum.org/baseline-requirements-documents/>, key compromise is one reason for certificate revocation within a 24-hour period, and section 4.9.3 of the Baseline Requirements requires that CAs provide "clear instructions for reporting suspected Private Key Compromise ..." and that they "publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS." However, in many of the CPSes reviewed by Mozilla, the only information appearing is a contact person's street address, email address, and sometimes a telephone number. Seldom is this information provided in the context of revocation for key compromise, and in many situations, email is an inadequate method of communicating key compromises, especially at scale. Some CAs have portals (e.g. DigiCert <https://problemreport.digicert.com/key-compromise/report> and Sectigo <https://secure.sectigo.com/products/RevocationPortal>) in addition to an email address to submit revocation requests. There is also an open-source ACME server which is designed for the sole purpose of receiving revocations: https://github.com/tobermorytech/acmevoke. Github Issue #205 <https://github.com/mozilla/pkipolicy/issues/205> notes that the best place for disclosure of such revocation methods would be in section 4.9.12 of a CA's CPS. Section 4.9.12 of the RFC 3647 outline <https://tools.ietf.org/html/rfc3647#section-6> is titled "Special requirements re key compromise". Not only will this requirement make it easier for the Mozilla community to report key compromises, but it will also help streamline key-compromise-based revocations, thereby reducing the number of Bugzilla incidents filed for delayed revocation. Draft language in https://github.com/BenWilson-Mozilla/pkipolicy/commit/719b834689949e869a0bd94f7bacb8dde0ccc9e4 proposes to add a last sentence to section 6 of the MRSP reading "Section 4.9.12 of a CA's CP/CPS MUST clearly specify the methods that parties may use to demonstrate private key compromise." We recognize that there is some overlap with the BR 4.9.3 requirement that certain instructions be provided in section 1.5.2 of the CPS, but we believe that the overlap can be worked through during this discussion and, if not, a related discussion within the CA/Browser Forum. We look forward to your comments and suggestions on this issue. Sincerely yours, Ben Wilson Mozilla Root Store Program _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
