Occasionally, I come across certificates in the wild that cryptography is unable to load due to errors in their encoding, but that are accepted by other implementations, notably OpenSSL.
See, e.g., here (ECDSA signatures with an invalid NULL parameter), or various older certificates/intermediates within CCADB.
I think it is, in general, good behavior to reject invalid inputs. In many of these cases (e.g., the invalid ECDSA signatures mentioned), I'd even argue it's a bug that OpenSSL accepts them. However, I wonder if you'd consider having an optional feature that is able to parse such certificates.
My use case is that I'm developing a tool to analyze public keys for known vulnerabililties (badkeys). I think a broader case could be made that for certificate analysis tools it is desirable behavior being able to, e.g., extract a public key or other info from a malformed cert.
Given that I'd also consider this a risky feature, I'd suggest having a very clear name. I could imagine something like this:
load_pem_x509_certificate(data, risky_allow_broken_x509=True)
If you consider this to be a bad idea, I'd also understand that. But I wanted to bring it up to know whether that's something you'd consider.
Occasionally, I come across certificates in the wild that
cryptographyis unable to load due to errors in their encoding, but that are accepted by other implementations, notably OpenSSL.See, e.g., here (ECDSA signatures with an invalid
NULLparameter), or various older certificates/intermediates within CCADB.I think it is, in general, good behavior to reject invalid inputs. In many of these cases (e.g., the invalid ECDSA signatures mentioned), I'd even argue it's a bug that OpenSSL accepts them. However, I wonder if you'd consider having an optional feature that is able to parse such certificates.
My use case is that I'm developing a tool to analyze public keys for known vulnerabililties (badkeys). I think a broader case could be made that for certificate analysis tools it is desirable behavior being able to, e.g., extract a public key or other info from a malformed cert.
Given that I'd also consider this a risky feature, I'd suggest having a very clear name. I could imagine something like this:
If you consider this to be a bad idea, I'd also understand that. But I wanted to bring it up to know whether that's something you'd consider.