You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZ3nUbS9_hQUJ5rUzb%3DyPYkA-3ienthPwqMGdP8Fo-86g%40mail.gmail.com.
I think the proposal may need accommodate the case where issued certificates have a CRLDP that contain a URI which points to a sharded CRL that may not be disclosed in CCADB. In other words, it is possible that the CA employs one sharding strategy for CCADB while using a different strategy for the CRLs that are referenced in the CRLDP of certificates it issues. The CA may be producing more CRLs than strictly necessary in this case, but I’m unaware of anything prohibiting such practice today and am hard-pressed to think of any issues that may arise with such an arrangement. I attempted to capture this consideration in my language proposal on Github .
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErdgaxi9TROWe5GdQ%3DFpMXpQcQcquL8xgGgrVfxCyOeydw%40mail.gmail.com.
I prefer explicitly stating that something is allowed, because we have seen previously that the lack of explicit allowance (or prohibition) in these requirements is the source of much disagreement. For this reason, I think explicitly enumerating what is allowed provides the most clarity (and less room for future disagreements).
That being said, I agree that your proposal is much more concise than the other proposals. If folks think my concern about explicitly enumerating allowances is unreasonable, then I think your language is fine.
A CRL whose scope does not include all unexpired certificates that are issued by the CA SHALL contain a critical Issuing Distribution Point extension. The distributionPoint field of the extension SHALL include a UniformResourceIdentifier whose value is derived from one of the two following sources:
1. The UniformResourceIdentifier as encoded in the distributionPoint field of an issued certificate's CRL Distribution Points extension (see RFC 5280 section 5.2.5); or
2. The URL as included in the "JSON Array of Partitioned CRLs" field in the CCADB entry corresponding to the certificate for the issuing CA.
Will that create any conflicting language or leave a gap that would allow CRL swapping? If not, then I don't mind if it's slightly redundant in some aspects.
I like this solution. It establishes the CCADB-specific requirement in the section dedicated to CCADB but also specifies the CRL profile with details that are not necessarily specific to CCADB.
I think this change is fine from a Mozilla Policy standpoint, as Mozilla only requires the disclosure of CRL URLs for TLS-capable CAs in CCADB. Apple, on the other hand, requires the disclosure of CRL URLs for all CAs regardless of technical capability (i.e., non-TLS CAs also have this disclosure requirement). Further guidance in the Apple root program policy on the encoding requirements for IDPs may be needed to cover the non-TLS CA case.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186105AA08E6F862CEA599592C59%40DM6PR14MB2186.namprd14.prod.outlook.com.
The CCADB update minutes for the February 2022 F2F  say:
“– Dimitris asked if full CRLs are required for technically constrained ICAs. Kathleen responded that the Root Program requirements are currently different; the new filter can be used in this case.
– Clint clarified that for the Apple Root Program, all ICAs will be required to make available full CRL information regardless of technical capability.”
Clint’s clarification aligns with the current wording of Apple Root Program policy. Your interpretation may very well be accurate, but I’m unable to find any minuted/written discussion that limits the scope of this requirement to encompass only id-kp-serverAuth or id-kp-emailProtection.
Effective October 1, 2022, CA providers must 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" on Root and Intermediate Certificate records, within 7 days of the corresponding CA issuing its first certificate. This requirement applies to each included CA Certificate and each CA Certificate chaining up to an included CA Certificate in the Apple Root Program.