Add CRL support to X.509 verification

[vEpiphyte]

Hello!

I've been working on updating some code to utilize cryptography in favor of PyOpenSSL due to the API deprecation in the older project.

The only code that I can not currently remove is related to the use of X509Store and X509StoreContext. That is utilized for doing certificate validation. For example:

    def verifyACertificate(self, cert: c_x509.Certificate):
    	'''
    	Check if a Certificate is trusted by a set of CAs and is not revoked.
    	'''
        crls = self.getCaCrls()  # type: List[c_x509.CertificateRevocationList]
        cacerts = self.getCaCerts()  # type: List[c_x509.Certificate]

        store = crypto.X509Store()  # This is pyopenssl...
        [store.add_cert(crypto.X509.from_cryptography(cacert)) for cacert in cacerts]

        if crls:
            # Setting flags is important. Other uses use things such as PARTIAL_CHAIN flags.
            store.set_flags(crypto.X509StoreFlags.CRL_CHECK | crypto.X509StoreFlags.CRL_CHECK_ALL)
            [store.add_crl(crypto.CRL.from_cryptography(crl)) for crl in crls]

        ctx = crypto.X509StoreContext(store, crypto.X509.from_cryptography(cert))
        try:
            ctx.verify_certificate()  # raises X509StoreContextError if unable to verify
        except crypto.X509StoreContextError as e:
            mesg = _unpackContextError(e)  # helper function to unpack the X509StoreContextError, not important here.  
            raise Exception(mesg)
        return cert

I believe my use case aligns with #10276 ( doing code signing and/or user cert verification ). Current docs for the verification APIS ( https://cryptography.io/en/42.0.2/x509/verification/ ) don't seem to support setting CRLs or flag setting.

Is this type of use case in scope for work in #10345 ?

[alex]

cc: @woodruffw

Looks like there's two pieces you need here:

1. Doing verification without checking for a particular SAN, which is what @woodruffw has in his PR
2. Checking CLRs.

Both of these are tracked in #10034

Figuring out CLRs is going to require some API design work on our part. It looks like your implementation relies on having pre-fetched the CRLs, and not loading them on-demand.

[vEpiphyte]

@alex Correct - I am assuming that CRLs are present ahead of time ( and very much not assuming that it is the job of cryptography to retrieve them ).

If these pieces are being correctly tracked in #10034 we can close this issue out to avoid duplication.

[alex]

#10345 adds verification without a subject.

CRL is the remaining piece here. We still need to figure out what we want to do in terms of API design there.

[alex]

@reaperhulk and I discussed some and here's what we came up for in terms of an API:

• We add a new RevocationChecker ABC, which has an is_revoked() method
• We add a new revocation_checker API on PolicyBuilder to provide a RevocationChecker for use in that verification
• The core verification engine calls is_revoked in the right places
• We introduce a CRLRevocationChecker that takes a list of CertificateRevocationList objects and implements the RevocationChecker interface using them

Then in terms of the CRLRevocationChecker:

• It needs to verify the signature on the CRL with the issuer's public key
• TODO: decide whether to fail open or closed if a CRL's next_update is in the past
• It needs to check the CRL's extensions and make sure there are not any critical extensions that we don't check.
• Then it needs to check if the certificate is found in the CRL
• And then it needs to make sure there are no unknown critical extensions in the CRL entry

And for all of this we need to write a bunch of new x509-limbo tests :-)

For folks who were interested in this feature, does this sound like a design that works for your use case?

@woodruffw do you have an opinion on adding CRL tests to x509-limbo?

[vEpiphyte]

That design sounds solid from a user perspective. With the schism between pyopenssl removing the CRL constructs, and older versions of pyopenssl having a cryptography version constraint which prevents installing v44.0.1, this is an important item to nail down IMO.

[alex]

Started working on a list of test cases (well, I asked an LLM to do my homework for me):

Basic Functionality Tests

• Valid certificate not on any CRL
• Revoked certificate present on CRL
• Certificate with matching serial number but different issuer on CRL

CRL Structure Tests

• CRL with invalid signature
• CRL signed by incorrect private key
• Empty CRL (no revoked certificates)
• Very large CRL (performance test)
• CRL with unknown critical extension
• CRL with unknown non-critical extension
• CRL with duplicate revoked entry serial numbers

CRL Entry Tests

• CRL entry with unknown critical extension
• CRL entry with unknown non-critical extension

Temporal Tests

• CRL with thisUpdate in the future
• CRL with nextUpdate in the past
  • I think we want to just reject this on creating the verifier
• Certificate revoked with revocationDate in the future
• Certificate revoked with revocationDate before certificate's notBefore date
• CRL validity period not overlapping with certificate validity period

Chain Validation Tests

• Revoked end-entity certificate
• Revoked intermediate CA certificate
• CRL issuer certificate itself revoked in another CRL
• Multiple valid paths with different revocation status
• CRL issued by a certificate that doesn't have the CRL sign key usage

Extension Tests

• CRL with Authority Key Identifier extension
• CRL with Issuing Distribution Point extension
• CRL with CRL Number extension
• CRL with Delta CRL Indicator extension
• CRL with Invalidity Date extension
• Certificate with CRL Distribution Points extension
• CRL with duplicate extensions

[woodruffw]

Neat -- I realized I forgot to respond before, but I'm a big +1 on adding CRL tests to x509-limbo! They'd definitely make sense under a new crl:: namespace, similar to what we do for rfc5280:: and webpki::.