Implementing custom extensions for certificates (and CRLs for that matter) on top of the ASN.1 parsing mechanism is being preferred over implementing native support for them in cryptography's souce code (see #15379 for a related discussion and the initial suggestion for this issue).
Currently, writing and using custom extensions is tedious, as the extension can only be retrieved by using get_extension_for_oid, then the attribute UnrecognizedExtension.value must be inspected, then ran through asn1.decode_der and then the parsed value can be acted upon. This is less type-safe and more tedious than for built-in extensions, where get_extension_for_class works automatically and in a type-safe way.
It would be very helpful if cryptography was able to provide some pluggable way of using custom extension classes. A nice way to start could probably be something like extending get_extension_for_class to accept custom Extension subclasses. Perhaps something like:
class PolicyMappings(CustomExtension):
oid = ExtensionOID.POLICY_MAPPINGS
_value: list[PolicyMapping] # the parsed ASN.1 value
__len__, __iter__, __getitem__ = _make_sequence_methods("_value")
cert.extensions.get_extension_for_class(PolicyMappings)
Perhaps it would also be possible to inject custom Extension subclasses into the iterations of the Extensions object, so that get_extension_by_oid and iter() also work in the same way with custom extensions, instead of having to route through UnrecognizedExtension.
Implementing custom extensions for certificates (and CRLs for that matter) on top of the ASN.1 parsing mechanism is being preferred over implementing native support for them in cryptography's souce code (see #15379 for a related discussion and the initial suggestion for this issue).
Currently, writing and using custom extensions is tedious, as the extension can only be retrieved by using
get_extension_for_oid, then the attributeUnrecognizedExtension.valuemust be inspected, then ran throughasn1.decode_derand then the parsed value can be acted upon. This is less type-safe and more tedious than for built-in extensions, whereget_extension_for_classworks automatically and in a type-safe way.It would be very helpful if cryptography was able to provide some pluggable way of using custom extension classes. A nice way to start could probably be something like extending
get_extension_for_classto accept customExtensionsubclasses. Perhaps something like:Perhaps it would also be possible to inject custom
Extensionsubclasses into the iterations of theExtensionsobject, so thatget_extension_by_oidanditer()also work in the same way with custom extensions, instead of having to route throughUnrecognizedExtension.