Policy 2.8.1: MRSP Issue #251: Full CRL Publication Requirements

222 views
Skip to first unread message

Ben Wilson

unread,
Nov 11, 2022, 2:22:50 PM11/11/22
to dev-secur...@mozilla.org
The current subject line for GitHub Mozilla PKI Policy Issue #251 is "Edit MRSP 4.1 to clarify full CRL publication issues in the CCADB". 

Currently, section 4.1 of MRSP 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



Corey Bonnell

unread,
Dec 8, 2022, 8:27:37 PM12/8/22
to dev-secur...@mozilla.org, bwi...@mozilla.com
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

Reply all
Reply to author
Forward
0 new messages