Thanks for the question! Out of curiosity: why is it unattractive to include a CRL? Do you already include OCSP? Also, pardon my ignorance, but what is an EE certificate?

Sorry, EE stands for end-entity

If you issue millions of certificates from a single CA it's likely that you will aloso have many revoked certificates. This will quickly result in a CRL from serveral or even tens of megabytes. This is painfull for clients who actually download a CRL but also painfull for the CA as these get billed for a lot of bandwith.

Clients such as Microsoft automatically fallback to the CRL (when a CRL and OCSP are available) when they see about 40 certificates issued by the same CA.

See for example:
https://blog.cloudflare.com/the-hard-costs-of-heartbleed/

I don't see any reason why the CRL aggregator couldn't download a list of additional CRLs, or even scrape some websites for lists of additional CRLs -- but I do think we'd need to treat them as public knowledge -- e.g., place the lists into the CCADB for all root programs to use, and potentially be published from there.

Just further thoughts: Already all logs for CRLite are published, so CRL data is public. I wouldn't want to change that without cause, so I would argue that these CRLs would be revealed in the CRLite logs by design at present.

It's fine to have the CRL public, just not embedded in the certificate CDP.

Since lists are likely to be sharded, what CRLite would prefer is to be provided a CRL URL for an issuer from the CCADB which is either:

1. A monolithic CRL for that issuer, mime-type application/pkix-crl, containing revocations for that issuer, or
2. A JSON list of URLs, mime-type application/json, each list entry being a URL to a CRL for that issuer, which in aggregate cover all revocations for that issuer. e.g.:

[
  "https://cdn.example/crl-1.crl",
  "https://cdn.example/crl-2.crl",
]

In both cases, it would be preferred that the CRL(s) contain only unexpired revocations, that expired ones are pruned, but that is more for bandwidth efficiency, it does not have security impacts.

I like the simplicity of the JSON list but it does fall over, probably, when you are doing micro shards, for example, there is nothing stoping you from doing a CRL covering a single certificate. That said in the real world this would probably work.

In the case of CRLite, I can easily imagine setting a deadline on a per-issue basis that all revocation data needs to be acquired within X seconds of network activity or we just unenroll the issuer.

That is probably a good idea anyway and easy to do with Go contexts... opening a feature request.

Since lists are likely to be sharded, what CRLite would prefer is to be provided a CRL URL for an issuer from the CCADB which is either:

1. A monolithic CRL for that issuer, mime-type application/pkix-crl, containing revocations for that issuer, or

CCADB now has a "Full CRL Issued By This CA" field for each CA certificate. I've just used this facility to enter the URLs of (so far) 52 Full CRLs for intermediate CAs (for which Sectigo routinely omits the CRL Distribution Points extension in leaf certificates).

Is there a plan to use this field for CRLite?

The short answer is 'yes', though additional coordination on our side is still necessary.

Work on improving the auditing of CRLs is ongoing, and then I'd at least feel more comfortable with adding the ccadb's CRL data into the mix.