change x509 validation to allow parsing of some "bad" certs

[reaperhulk]

We now validate on these fields when adding the objects to the CertificateBuilder.

This PR does not attempt to migrate all validation logic. Each extension has logic that may be specific to Python or enforcement of an RFC restriction. Before migrating more logic I'd like to see examples of certificates that encode things in that specific invalid way.

Fixes #3857 and #3856

[alex]

Please put the vector in a separate PR.

You also seem to not be handling these validations in CSR, CRL, and whatever-the-hell-else builders.

[reaperhulk]

This is ready for review again. Still outstanding: whether we want to switch to adding _validate() to every extension class rather than the (new) getattr approach.

[jcrowgey]

I have a dataset of about 20 certificates (and still growing) which break the validation steps in this library. All were harvested in the wild. If there's some way to publish these examples for you conveniently, I'd love to contribute. Currently, I just monkey patch the init methods on lots of the Extension and Name classes to remove the validation checks.

[2rs2ts]

Is this PR abandoned?

[jcrowgey]

@2rs2ts what timing. I just released (a few hours ago) the library I use which does the monkeypatching to allow loading of certs which don't always follow best practices.

https://github.com/jcrowgey/x5092json

[2rs2ts]

@jcrowgey nice... I am not sure your library solves my problem, but it is indeed cool! 😄

[reaperhulk]

This has been pushed 5 times now and is no less problematic now than it was 3 years ago. I think to get "bad" cert parsing we're going to need to have someone commit to the large amount of work necessary for a hazmat x509 parsing API. When that gets implemented we can have this.

In the meantime the monkeypatching model is probably the best path to bypass this type of validation if needed.