CRL feature discussion

[JeyJeyGao]

As mentioned in #125, we need to implement the CRL check to complete the certificate revocation support. I have investigated CRL based on RFC 5280 and would like to start a discussion about this feature.

Here are the topics that I think we need to discuss:

CRL Validation:

As mentioned in RFC 5280, Section 5.1.1.3 signatureValue:

Applications that perform CRL checking MUST support certification path validation when certificates and CRLs are digitally signed with the same CA private key.

In this case, we can use the original certificate issuer's certificate to validate the CRL's signature.

These applications SHOULD support certification path validation when certificates and CRLs are digitally signed with different CA private keys.

For this case, where the original certificate issuer's certificate differs from the CRL issuer's certificate, we don't have enough information to validate the CRL. In this situation, we need to decide whether we should perform the validation because it mentions that it is SHOULD rather than MUST. If we need to implement the validation, we need the user to provide the issuer certificate for the CRL.

Large CRL Size

We need to support an offline cache for CRL considering the pros and cons of CRL:

CRL:

• Pros:
  • Simplicity: the CRL role is straightforward and easy to understand.
  • Complete revocation list: provides a comprehensive list of all revoked certificates from a CA, ensuring thorough checks.
• Cons:
  • Potential large CRL content. For example, the Digicert CRL file is about 353 KB.
  • Update frequency: CRLs are updated at regular intervals, not in real-time, which can lead to a gap between a certificate’s revocation and its appearance on the list.

As mentioned above, a 353 KB CRL file is too large for frequent verification processes, so we need a library-level caching mechanism to solve the issue. However, this could be an optimization work item for the CRL feature.

I appreciate your thoughts and ideas. Thank you very much!

[Two-Hearts]

My suggestion is in our 1st iteration, we only support cases that cert and CRL share the same issuer (i.e., digitally signed with the same CA private key). In a future release, we could consider add the support for the other case (including new trust store type design).

For cache, since a cert chain could have many CRLs, one download failure would waster other successful downloads, the network overhead can be huge. I agree with @JeyJeyGao that we should implement a cache. One option could be introducing a new folder under notation/config dir to save the CRL files. The cache key would be CDP URL, the cache value is just the downloaded .crl file path. One thing needs particular attention though, the cache refresh MUST be checked, if the current machine time is later than the CRL's next update/next publish time, the cache record MUST be refreshed.

[JeyJeyGao]

I think so. We can support cases where the certificate and CRL share the same issuer for the first version.

Thank you for your suggestion about the cache. Do you think it is a required feature for the first version, or could it be an improvement? @Two-Hearts

[Two-Hearts]

@JeyJeyGao I guess your last question is really determined on our timeline, which can be better answered by @yizha1 and @FeynmanZhou. In terms of unblocking users who only have CRLs in their certs, I would say we could save the cache in the 2nd iteration.