Maybe clarify even further that "publishing CRLs" can be via cert extension or other. For example in the case of "Hidden CRL" in which a leaf certificate lacks the CRL Distribution Points extension, but nonetheless the issuing CA does publish a CRL. (mozilla/crlite#43).
In CCADB there is an "Alternate CRL" field that can also be used for this.

In CCADB there is an "Alternate CRL" field that can also be used for this.

@WilsonKathleen I'm not convinced that "Alternate CRL" is intended to be used for the cases where "a leaf certificate lacks the CRL Distribution Points extension".

The CCADB help text for "Alternate CRL" says (emphasis mine) "Only fill this in if this certificate does not contain a CRL URL", where "this certificate" is the CA certificate identified in the CCADB record. This seems to imply that "Alternate CRL" is intended to identify the URL for CRLs issued by the issuer of the CA certificate (i.e., most likely a root CA), not CRLs issued by the CA identified in the CCADB record.

So either (1) that CCADB help text is misleading, in which case perhaps it should be changed to something like "Only fill this in if this CA does not include CRL URLs in the certificates it issues", or (2) there would need to be another field added to each CCADB record to hold the URL of a "hidden" CRL that covers (but is not included in) the certificates issued by the CA identified in the CCADB record.

The CCADB help text for "Alternate CRL" says (emphasis mine) "Only fill this in if this certificate does not contain a CRL URL", where "this certificate" is the CA certificate identified in the CCADB record. This seems to imply that "Alternate CRL" is intended to identify the URL for CRLs issued by the issuer of the CA certificate (i.e., most likely a root CA), not CRLs issued by the CA identified in the CCADB record.

Correct.

So either (1) that CCADB help text is misleading, in which case perhaps it should be changed to something like "Only fill this in if this CA does not include CRL URLs in the certificates it issues", or (2) there would need to be another field added to each CCADB record to hold the URL of a "hidden" CRL that covers (but is not included in) the certificates issued by the CA identified in the CCADB record.

(2) -- there would need to be another field added for "hidden" CRL

I apologize for my previous misleading comment.

For CRLite, do we want to try and address the issue of obtaining complete CRLs. I'm not sure what the right terminology is, but somehow Apple uses the complete CRL, even though CAs segment CRLs in end entity certificates to keep them short/fast. I suppose that raises a broader discussion and not right for anything to put now in version 2.7.1.

What if it were to say, "For end-entity certificates with a CRL Distribution Point (CDP) Extension, CRLs MUST be updated ..."?

@BenWilson-Mozilla I don't think that's what you want, but I'm also have trouble understanding the full scope of the "question" originally raised, as it seems disconnected from Kathleen's reply

If I understood your original issue, it appeared to be confusion between 7.1.2.3(b) of the Baseline Requirements (v.1.7.2), which has the crlDistributionPoint as optional, and whether Mozilla Policy is adding more restrictive requirements (e.g. requiring CRLs for all end-entity certificates) or restating Section 4.9.7 of the BRs.

If I understand your proposal, it's to clarify CRLs are optional.

However, your proposed language seems to overlook the issue Kathleen was raising, which is that Mozilla would like CAs to publish CRLs for all certificates, similar to Apple's expressed interest in requiring CAs make CRLs available for all certificates, even though the Baseline Requirements do not require this. The intent here is to allow CRLLite to process these (or, in Apple's case, Valid), without having to query the OCSP responses, which the BR mandates CAs make available.

So it seems the first question:

• Does Mozilla want to require CRLs be produced, in some form, for all certificates, in order to avoid having to check OCSP responses for CRLLite?

And if the answer is "Yes" (Or "SHOULD" but not "MUST"), then the next question is:

• Does Mozilla want to require CAs place this information in the crlDistributionPoint extension, or do they want to allow the CA to privately configure the URL via CCADB?

It seems like it's important to answer the first question, and it appears your proposed language is "No", which is why I'm having trouble squaring it with Kathleen's comment, or your later clarification

Thanks. This helps. The answer to the first question is yes. And then we need to resolve the second question.

Gotcha. It seems like this could be discussed in the CA/B Forum, since there's certainly interest (in Apple's case) of having CRLs for issuing CA certs. @clintwilson would probably be interested!

However, there's also value in tackling this in Mozilla Policy.

It seems that the requirement is something like:

For all CA certificates technically capable of (TLS?) issuance, the CA MUST provide a CRL whose scope is "all unexpired certificates issued by that CA revoked for any reason", referred to within RFC 5280, Section 5 as a "full and complete CRL." If the CA has ever issued an end-entity certificate, including certificates that have expired, then the CA MUST update and reissue this CRL at least every seven days, and the value of the nextUpdate field MUST NOT be more than ten days beyond the value of the thisUpdate field.

CAs SHOULD place the URL for the associated CRL within the crlDistributionPoints extension of issued certificates. CAs MAY omit the crlDistributionPoint extension, if permitted by the applicable requirements and policies, such as the Baseline Requirements. If the CA omits the crlDistributionPoint extension from any issued certificates, or if the crlDistributionPoint extension contains a URL other than the full and complete CRL (e.g. a complete CRL that is scoped by specific reason codes, or CRLs scoped on local information, such as batches of certificates), then the CA MUST ensure that the "Alternate CRL" field within CCADB contains the URL of the full and complete CRL subject to these requirements.

• The first paragraph is establishing that the CA MUST provide CRLs, and the CRLs MUST be "full and complete CRLs".
• The second paragraph establishes how the CA discloses this. They SHOULD disclose it within issued certificates, however, if they opt to use reasonCode segmentation (unlikely, rare) or more commonly, batch-segmented CRL (much more common, standard EJBCA feature), then they need to disclose the full and complete CRL within CCADB.

That said, I'm not sure how well EJBCA supports this case; I believe right now, it's an either/or configuration. That is, you either you hash-segmented/batch-segmented CRLs, or you use full and complete CRLs, but you can't produce both. I don't know the full implementation details of Valid or CRLLite to know how well it handles that case, so I suspect further discussion is needed, both with other vendors and with CAs.

Does CRLLite also support Technically Constrained subCAs (per Mozilla Policy) and BRs section 7.1.5? Could there be an exception for those CAs, so that end-entity certificates issued from TCSCAs don't need to contain both CRLDP and AIA OCSP Responder of the Issuing CA?

I would recommend that, as much as possible, exceptions for TCSCs be avoided. We have seen that end users/relying parties are harmed by such carveouts, as they continue to cause CAs confusion about the requirements, and continue to add complexity to the requirements.

Further, as we’ve seen countless TCSCs mis-issue certificates in a way that harms users, particularly with respect to malformed certificates not conforming to profile, the very idea of externally operated TCSCs is one that appears to have outlived its viability.

While there are still a few small number of TCSCs, we should not let them hold back clear, consistent, and useful requirements that benefit all users’ security.

Sure, but until that time comes and TCSCs are removed from policy (with no exceptions compared to unconstrained subCAs), shouldn't we try to minimize the size of certificates since OCSP must be supported for all leaf certificates?

Sure, but until that time comes and TCSCs are removed from policy (with no exceptions compared to unconstrained subCAs), shouldn't we try to minimize the size of certificates since OCSP must be supported for all leaf certificates?

TCSCs can still reduce the size of certificates through disclosure via CCADB of the CRL, as suggested in the proposal.

There should not be new exceptions for TCSCs is the point, and the proposed exclusion would be a new exclusion, which we know doesn't yield good results

Sleevi wrote:

It seems that the requirement is something like:
...
CAs SHOULD place the URL for the associated CRL within the crlDistributionPoints extension of issued certificates. CAs MAY omit the crlDistributionPoint extension, if permitted by the applicable requirements and policies, such as the Baseline Requirements. If the CA omits the crlDistributionPoint extension from any issued certificates, or if the crlDistributionPoint extension contains a URL other than the full and complete CRL (e.g. a complete CRL that is scoped by specific reason codes, or CRLs scoped on local information, such as batches of certificates), then the CA MUST ensure that the "Alternate CRL" field within CCADB contains the URL of the full and complete CRL subject to these requirements.

@sleevi Perhaps I'm unnecessarily nitpicking here, but I'd prefer to see "place the URL for the associated CRL within the crlDistributionPoints extension of issued certificates" and "the...field within CCADB contains the URL of the full and complete CRL" expressed as equally good options (for satisfying a "CAs MUST publish full and complete CRLs" requirement), rather than the first of those two options being expressed as the preferred option.

Sectigo omits crlDistributionPoints from issued DV certificates fairly extensively these days, and yet every one of our DV issuing CAs does publish a "hidden" CRL. We do this primarily because our CDN bill for serving CRLs was getting ridiculous, so we wanted to force clients (especially Windows CryptoAPI) to use OCSP instead.

I very much support the proposal of adding a new "Hidden CRL" field to CCADB. (Reminder: as discussed earlier in this Issue, "Alternate CRL" is used for something else). Once this field exists, I'll make sure that crt.sh uses it too.

@sleevi Perhaps I'm unnecessarily nitpicking here, but I'd prefer to see "place the URL for the associated CRL within the crlDistributionPoints extension of issued certificates" and "the...field within CCADB contains the URL of the full and complete CRL" expressed as equally good options (for satisfying a "CAs MUST publish full and complete CRLs" requirement), rather than the first of those two options being expressed as the preferred option.

Unfortunately, I don't think these are both equally good, in that one of them heavily depends on CAs correctly using CCADB. As you know from the many tools you've contributed to point out when CAs are not correctly using CCADB, there certainly is benefit in reducing area for confusion for CAs.

Given that CAs have expressed confusion around constructs like "If (condition), then (thing is permitted)", confusion around "00:00:00 UTC", and confusion around 397/398, it seems that the path that CAs are least likely to get wrong would be the preferable path.

I totally agree with you that there are situations where disclosure via CCADB is entirely appropriate. Unfortunately, I think the requirement has to target the lowest common denominator, and there's a very low floor in comprehension right now, unfortunately.

When we re-visit this, let's also consider how we want to handle short-lived certificates and if there are other mechanisms to gather certificate status information for CRLite.

Note: One of the reasons we did not add this requirement to v2.7.1 of the root store policy is because some CAs, like Let's Encrypt will have very large JSON arrays to indicate their full CRLs. So when we consider this update for the next version of the policy, add language to clarify that for very large JSON arrays, CAs should not store the array directly in the CCADB, but rather provide a URL to a file containing the JSON array on their website. This will probably require that an additional field be added to the CCADB (for the URL to the file of the JSON array).

In the CCADB, we will still have 'Full CRL Issued By This CA' and ‘JSON Array of Partitioned CRLs Issued By This CA’ with history tracking on.
However, we will need to figure out a way to handle the situation in which the ‘JSON Array of Partitioned CRLs Issued By This CA’ is very large and updated frequently by the CA, so we would not want to be adding lots of duplication of data via history tracking.

Actually, come to think of it... Now that we use OwnBackup for the CCADB backups, maybe we don't need the history tracking turned on in the CCADB -- we could run a report in OwnBackup to find previous values.
Anyways, this will need to be figured out when we add this requirement.

I think that most of the issues discussed here can be resolved by joining this issue with Issue #235, and maybe the original reason for opening this issue doesn't need addressing? In other words, we could close this issue and simply not make any amendment to that second sentence of MRSP 6, which says, "For end-entity certificates, CRLs MUST be updated and reissued at least every seven days, and the value of the nextUpdate field MUST NOT be more than ten days beyond the value of the thisUpdate field". Adding "if the CA publishes CRLs" might cause more confusion. Alternatively, we could rephrase that second sentence to more clearly state what we want (which I'll have to look into more).

I'm closing this as it is being addressed by resolution of Issue #235.