On 5/11/2020 10:33 μ.μ., Ben Wilson via dev-security-policy wrote:
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
I believe this information should be the "minimum" accepted methods of
proving that a Private Key is compromised. We should allow CAs to accept
other methods without the need to first update their CP/CPS. Do people
think that the currently proposed language would forbid a CA from
accepting methods that are not explicitly documented in the CP/CPS?
I also think that "parties" is a bit ambiguous, so I would suggest
modifying that to follow the language of the BRs section 4.9.2
"Subscribers, Relying Parties, Application Software Suppliers, and other
third parties". Here is my proposed change:
"Section 4.9.12 of a CA's CP/CPS MUST clearly specify the methods (at a
minimum) that Subscribers, Relying Parties, Application Software
Suppliers, and other third parties may use to demonstrate private key
compromise."
Thank you,
Dimitris.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
