Hi Ben, I believe the proposed language would allow a CA to issue a certificate but not disclose any revocation information source for that certificate for up to 7 days after issuance. This would mean that in the event of a key compromise of the certified key soon after issuance, user agents and other consumers of CCADB revocation disclosures would not recognize any revocation of the certificate for up to a week, exposing Relying Parties to risk.
This is similar to the concern that Wendy raised on the servercert-wg mailing list regarding a CA creating a new CRL shard and issuing certificates within that CRL's scope but not immediately disclosing the URL of the new CRL shard [1]. To mitigate against any risk caused by CCADB information lagging the actual state of CA revocation information, policy should be amended such that: 1. The location(s) of CRL(s) for dormant CAs MUST be disclosed prior to issuing any certificates (i.e., making the CA "active" again), and 2. The location(s) of new CRL shard(s) MUST be disclosed prior to populating any revoked certificate information on that CRL. Happy to draft some concrete policy language if there's agreement that this change would be beneficial. Thanks, Corey [1] https://lists.cabforum.org/pipermail/servercert-wg/2022-October/003359.html On Friday, November 11, 2022 at 2:22:50 PM UTC-5 [email protected] wrote: > The current subject line for GitHub Mozilla PKI Policy Issue #251 > <https://github.com/mozilla/pkipolicy/issues/251> is "Edit MRSP 4.1 to > clarify full CRL publication issues in the CCADB". > > Currently, section 4.1 of MRSP > <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#41-additional-requirements> > > states: > > Effective October 1, 2022, CA operators with intermediate CA certificates > that are capable of issuing TLS certificates chaining up to root > certificates in Mozilla's root store SHALL populate the CCADB fields under > "Pertaining to Certificates Issued by This CA" with either the CRL > Distribution Point for the "Full CRL Issued By This CA" or a "JSON Array of > Partitioned CRLs" > > Requests have been made to clarify this policy for at least two situations > where the CA is not actively issuing certificates: (1) the CA has not yet > issued certificates, and (2) the CA issued certificates in the past, but is > no longer issuing certificates, e.g. a "dormant" CA (provided that all > previously issued certificates have since expired). > > The language proposed thus far would address the first scenario by adding > "within > 7 days of such intermediate CA issuing its first certificate". Language > should be developed that addresses the second scenario. > > One suggestion might be to change the phrase directly above to read > something like: > > "unless no certificates have been issued by the intermediate CA or all > previously issued certificates under that intermediate CA have expired, in > which case, the CA operator shall populate the CCADB fields within 7 days > of such intermediate CA issuing a certificate." > > Thoughts? Discussion? > > Thanks, > Ben > > > > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/9ec8dda2-c36b-4996-9548-2c2e793d3ca7n%40mozilla.org.
