CRL version 3
RFC 5280 states that a CRL can only be version 1 or 2. https://datatracker.ietf.org/doc/html/rfc5280#section-5.1.2.1
Asn1crypto have a version 3 as well. https://github.com/wbond/asn1crypto/blob/master/asn1crypto/crl.py#L43
Openssl also indicate something wrong when using v3. openssl crl -text -noout -in crl.crl
Certificate Revocation List (CRL):
Version unknown (2)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = SE, ST = Stockholm, L = Stockholm, O = SUNET, OU = SUNET Infrastructure, CN = ca-test.sunet.se, emailAddress = [email protected]
...
When using v2 all seems ok. openssl crl -text -noout -in crl.crl
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = SE, ST = Stockholm, L = Stockholm, O = SUNET, OU = SUNET Infrastructure, CN = ca-test.sunet.se, emailAddress = [email protected]
...
Hmm, I also can't find a reference to v3 CRLs in the copy of Rec. ITU-T X.509 (10/2016) | ISO/IEC 9594-8:2017 sitting on my machine, and the requirement that the version be set to v2 on CRLs is present even in X.509 (of which RFC 5280 is a profile).
Having said that, syntactically, the v3 value is valid: in the X.509 ASN.1 module (Annex A of the cited document), the version field in both TBSCertificate and CertificateListContent refer to the same type definition for Version, which includes v1, v2 and v3. For Certificates, using v3 makes sense. For CertificateLists, not so much, hence why there's an additional rule restricting the permissible values to v2.
So, personally, I'd chalk this up to a quirk in the way the X.509 spec is structured rather than a bug in asn1crypto, to be honest.
EDIT: ...but I wouldn't necessarily object to removing the v3 option from CRLVersion in the API either.
I agree, it's not broken.
Although there is no such thing as a v3 at this time, it is not the least bit harmful to accept the value in a library like this. Will might prefer to change it for aesthetics to be matchy matchy with the standard, or might prefer to leave it as is. Either way is the same / makes no difference as far as I'm concerned. If a person is using a lower level library that allows you to fiddle with these values when encoding CRLs it is incumbent on them to know what they are doing. If one doesn't know what they are doing to this level then they should probably be using higher level functionality that insulates them from these details.
On Sat, Sep 17, 2022 at 9:15 AM Matthias Valvekens @.***> wrote:
Hmm, I also can't find a reference to v3 CRLs in the copy of Rec. ITU-T X.509 (10/2016) | ISO/IEC 9594-8:2017 sitting on my machine, and the requirement that the version be set to v2 on CRLs is present even in X.509 (of which RFC 5280 is a profile).
Having said that, syntactically, the v3 value is valid: in the X.509 ASN.1 module (Annex A of the cited document), the version field in both TBSCertificate and CertificateListContent refer to the same type definition for Version, which includes v1, v2 and v3. For Certificates, using v3 makes sense. For CertificateLists, not so much, hence why there's an additional rule restricting the permissible values to v2.
So, personally, I'd chalk this up to a quirk in the way the X.509 spec is structured rather than a bug in asn1crypto, to be honest.
— Reply to this email directly, view it on GitHub https://github.com/wbond/asn1crypto/issues/236#issuecomment-1250069724, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEIC54ZFKZ42RSG4U625ULDV6W77TANCNFSM6AAAAAAQO76XDQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Most likely it was a copy-paste of the definition of Version from x509.py. Originally things were tightly coupled, and then at some point I segmented them to reduce coupling and improve handling of the edge cases. I believe this was during my initial development of the library, before I started tracking all code changes as commits in git.
@wbond Would you support a pull request to remove version 3?
@vinas003 Yes
Seems the tests failed because of https://github.com/wbond/crlbuilder
So I made a pull request for that repo as well. Hope I changed v3 -> v2 in all places.