Loading certificate with invalid Name Constraints fails silently

[sffjunkie]

Python Version: 3.10.4 Cryptography: 37.0.4

Loading a certificate that has a bad Naming Constraints does not raise an error. However when accessing the extensions property a ValueError is raised (this means information on other valid extensions cannot be retrieved.)

Depending on whether the project philosophy to only work with valid certificates, either the certificate should be rejected as a whole when loading, or there should be some method to only error when accessing invalid extensions.

For example the following certificate from the openssl project shows this effect https://github.com/openssl/openssl/blob/master/test/certs/bad-othername-namec-inter.pem

See the following gist to illustrate https://gist.github.com/sffjunkie/75a9586655e9031edddb3d306efc16a1

Change #6983 from issue #6982 touched this code.

[alex]

This is a somewhat intentional feature of our X.509: We validate the overall structure of a certificate on parse, but only validate extension on access. This is basically a result of the fact that RFC 5280 makes extensions be an OCTET STRING containing DER -- therefore they're not decoded when decoding the cert as a whole.

The nature of our extensions API is that trying to access any extension decodes all of them. At one point many years ago I looked into changing this, but it didn't end of going anywhere. At this point I'm more ambivalent about fixing the API to allow reading a single extension, but would probably consider a patch that does so.

[alex]

@reaperhulk and I spent some time discussing this this evening. The conclusion we came to is that while the exact boundaries of when we raise exceptions in X.509 processing may not be optimal, we don't think the level of effort involved in changing it would be worth the costs in API disruption.

We considered this from both perspectives:

1. What would it take to eagerly enforce extension correctness on parse? The most natural (and efficient) way to do it would help us catch ASN.1 syntactic errors, but would not cover semantic errors easily -- and indeed, the example you have is a semantic error.
2. What would it take to support extracting some extensions in the face of others that were malformed? As I said, we looked into this previously, and there's just not a clean way to do it with our current APIs. To rectify this, I believe we'd need new APIs, and the cost of migrating to them isn't worth it for this.

[sffjunkie]

Thanks for the detailed responses and I understand your position. I will update my code to take this into account.