Possible to retain negative serial number parsing in x509 certificates ?

[vEpiphyte]

I'm writing regarding the planned removal of negative serial number support from the cryptography package in v43.0.0.

Would it be possible to allow the parsing of negative serial numbers as an optional configuration to the hazmat layer, or as an option to the "load_der_x509_certificate / load_der_x509_certificates / load_der_x509_certificate" APIs? That would allow someone who is okay handling those negative serial numbers to opt-into supporting them; and those who want strict compliance with the RFCs to reject the certificates.

The reason that I bring this up is that there are still many real world examples of negative serial numbers being present in X509 certificates, despite deviation from RFCs. This is the unfortunate scenario where "RFC / Specification says one thing" and "Real stuff seen in the wild on the internet" differs enough to be non-ideal for parser authors. This is especially true when there have been multiple revisions of the standard :(

The example from https://github.com/pyca/cryptography/issues/6609 is just one item. There are people in the information security space who use cryptography for parsing and inspecting X509 certificates. Restricting the allowed space for ( otherwise usable ) X509 certificates can hamper security research and tracking of threat actors, since they cannot take advantage of new functionality offered by cryptography moving forward.

[Ousret]

I agree that this should not be removed. Working with the OSes truststores made me realize that X509 certificates w/ negative serial numbers are still wildly used. I had to silent the warning due to how often it appeared in my tests. I'm no X509 expert, but if there is no evidence of security risks or downsides to allowing that, I would vouch in favor of not removing its support (i) and (ii) possibly even removing the warning.

[alex]

Is there a particular OS or root that you've encountered with a negative serial number?

We originally added this fallback based on the Mozilla trust store containing a negative serial number, but that cert has since been removed.

[Ousret]

I have encountered it in NT systems. I have seen it in Windows Server <=2022 for example.

[reaperhulk]

If these are common root certs would it be possible to get some links to them from crt.sh? It's interesting (but perhaps understandable) that Windows has a significantly divergent trusted set from Mozilla, Apple, et al.

[alex]

https://crt.sh/?q=28903A635B5280FAE6774C0B6DA7D6BAA64AF2E8

On Wed, Feb 14, 2024 at 6:55 PM Paul Kehrer @.***> wrote:

If these are common root certs would it be possible to get some links to them from crt.sh? It's interesting (but perhaps understandable) that Windows has a significantly divergent trusted set from Mozilla, Apple, et al.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

-- All that is necessary for evil to succeed is for good people to do nothing.

[dpandya-cisco]

Hello - I am wondering if there are any updates on whether there will be an option to allow negative serial number parsing in x509 certificates in v43.0.0? We have encountered a situation where one of the certificates in our team's trust store has a negative value for a serial number.

Interestingly, when I print the certificate serial numbers, none of them show a negative value. It would be greatly helpful if the CryptographyDeprecationWarning for parsing negative serial numbers could be expanded to include information about which certificate triggered the warning to see if there is indeed one with a negative serial number or if this is a bug in the cryptography library.

[alex]

There's no updates beyond what is present in this thread.