Practical usage of CRL(Certificate Revocation List)

Question

Does the CA need to mandatorily publish the new CRL file even though there are no new certificates that have been compromised since the last CRL published?

If CA needs to publish the CRL's periodically, how do I identity whether there are new records added to the revocation list or not?

If there are no new records added to the CRL, do I need to update my existing CRL file with the new one?

Is timestamping the CRL file a mandate or an optional feature?

Do All CA certificates need to use EKU(Extended Key Usage) set to CRLSign for the purposes of issuing the CRL's in the future?

Also, If the CRL validity is a week and published every Sunday, what would be implications on security if a certificate is compromised on Tuesday. As an end device, the next CRL will be only looked at after Sunday and so I would have accepted the connection from the compromised party for the last 5 days.

Answer 1

Does the CA need to mandatorily publish the new CRL file even though there are no new certificates that have been compromised since the last CRL published?

yes. CRL has fixed validity period determined by ThisUpdate and NextUpdate fields. After NextUpdate timestamp, CRL is considered expired and client application will return RevocationOffline chain validation status.

If CA needs to publish the CRL's periodically, how do I identity whether there are new records added to the revocation list or not?

by periodically checking for new CRLs and examining them.

Is timestamping the CRL file a mandate or an optional feature?

in practice -- mandatory requirement.

Do All CA certificates need to use EKU(Extended Key Usage) set to CRLSign for the purposes of issuing the CRL's in the future?

yes.

Also, If the CRL validity is a week and published every Sunday, what would be implications on security if a certificate is compromised on Tuesday

then this will be detected by clients no later than upcoming Sunday.

As an end device, the next CRL will be only looked at after Sunday and so I would have accepted the connection from the compromised party for the last 5 days.

it highly depends on client implementation. Most clients will cache once downloaded CRL for the CRL validity duration and won't download it again until it expires. Some clients, such as Microsoft CryptAPI client implements E-tag and Max-age HTTP headers that allow HTTP CDP endpoint polling without having to download CRL if it wasn't changed on HTTP server. Once new CRL is published to HTTP endpoint, E-tag will change and CryptoAPI client will forcibly re-download CRL, so detection of newly revoked certificates occurs faster. It is

Another option is to use Delta CRLs that include only revoked certificates since last Base CRL was published. Delta CRLs are meant to be smaller in size and can be published frequently, say every day.

Depending on use case, clients may utilize OCSP stapling (when we talk about online TLS connections), when TLS server obtains OCSP response for its own certificate and staple in response during handshake. But this vary between certificate usage scenarios (hence certificates are not only TLS, there are miriads of other usages).

Answer 2

Adding a few more details to Crypt32's responses.

If CA needs to publish the CRL's periodically, how do I identity whether there are new records added to the revocation list or not?

This is going to be dependent on the certificate authority. There is usually a process for someone to request a certificate to be revoked. This should translate to the CA marking the certificate as revoked in its database and publishing a CRL at some defined interval. For reference see https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-cersod/c2144dad-a72b-4829-b9de-b5944b697d9e.

If there are no new records added to the CRL, do I need to update my existing CRL file with the new one?

Yes, because the old CRL will be expired or near expiry.

Is timestamping the CRL file a mandate or an optional feature?

I'm assuming that by this you mean setting the ThisUpdate and NextUpdate fields, then yes, it is required in practice. Reference https://www.rfc-editor.org/rfc/rfc5280#section-5.1.2.4.

Also, If the CRL validity is a week and published every Sunday, what would be implications on security if a certificate is compromised on Tuesday. As an end device, the next CRL will be only looked at after Sunday and so I would have accepted the connection from the compromised party for the last 5 days.

That is correct: If the only thing the client relies on is the CRL, then it will be vulnerable to accepting a revoked certificate until the next CRL is available. Usually, new CRLs are published prior to the expiration of the old one, and some clients will download the newer CRL (as Crypt32 mentioned).

Note, however, that this is a risk decision made by the implementers of the PKI. That is, they decide that it is an acceptable risk for systems to be vulnerable to accepting revoked certificates for this period of time. If a client does not agree, they may either opt to subscribe to a different revocation mechanism (e.g., delta CRLs or OCSP) or implement other controls to mitigate the risk to an acceptable level.