Support for getting ASN.1 value for parsed extensions

[felixfontein]

When parsing a certificate or CSR, it would be nice to be able to get the ASN.1 value for all extensions in a simple way without having to essentially re-create the certificate parsing code (i.e. iterating over the extensions by using obj._backend and obj._x509 and FFI).

This data is available when reading certificates or CSRs, it is currently only stored for UnrecognizedExtensions. So storing it, and adding a property (maybe called asn1_value), which is either None (if ASN.1 value is not available) or the ASN.1 value itself, should be no problem.

I'd like the use this as follows:

1. For code which dumps all extensions in a uniform way (i.e. as OID, critical flag, ASN.1 encoding tuples);
2. For code which deals with extensions currently not supported by cryptography, but potentially later.

Let me expand on 2): say I want to add a certain extension using cryptography right now. For that, I can add a UnrecognizedExtension with the correct content. But if I want to check whether this extension is already there with the correct content, I have to assume that it will come as a UnrecognizedExtension. If cryptography ever supports this extension type directly, my code for detecting whether the correct content is there will stop working.

Would adding this to cryptography be acceptable? (I can create a PR for this if wanted.)

[reaperhulk]

I'm interested in how you would implement this. I'm not opposed to this conceptually, but I think our willingness to accept a patch would be predicated on whether we can build a sane API for this.

[felixfontein]

I created a WIP for this (#5025). In it, every extension type gets a new property asn1value, which can be None or a bytes string. (I've not added this property to __eq__ and __ne__ since that would break a lot of things.)

[alex]

@reaperhulk and I discussed this a bit. One of the things that's on our roadmap for 2021 is to move our X.509 extension parsing away from using OpenSSL, and towards our own DER parser (see #5357). We think that's going to have profound implications for the API here, so we're not making any hard decisions until that happens.