Implement PolicyMappings X.509 extension

[ralphje]

This implements the PolicyMappings X.509 extension as defined in RFC 5280, section 4.2.1.5.

It complements the other already-implemented extensions CertificatePolicies, PolicyConstraints and InhibitAnyPolicy.

[alex]

Can you share a bit more about what the actual concrete use cases this has in real-world PKIs? I personally have not encountered it in actual use before.

Now that we have public ASN.1 DER APIs, for X.509 extensions which are less popular, we'd like to push folks to implementing them externally with those APIs.

[ralphje]

I'm trying to implement the full PKITS set and encountered this omission.

This somewhat implies that this is something required by the US government for full compliance with their PKI programmes.

While I don't have a concrete use case, it's an extension listed in RFC5280, and not one of the more esoteric listed in the X.509 specification, and it does complement the already implemented policy extensions.

It's actually part of the validation algorithm in RFC5280, and is listed in section 4.2 as one of the extensions that should be implemented.

What do you mean by public DER APIs? The ASN.1 parser is still listed as non stable

[alex]

The ASN.1 API you linked is what I meant -- while we haven't declared them stable yet, that's the long term goal. (Before they existed, the only meaningful way to support an X.509 extension was for it to be built in, but now they can be implemented externally.)

Absent a concrete use case, I don't think there's much reason for us to add this. The entire certificate policies machinery is strongly disfavored in modern PKIs like the WebPKI.

[ralphje]

Thank you for your time in reviewing this PR. In all honesty, I'm disappointed you see it this way. I do see your point, but I would expect that full RFC support in this library should also be a long-term goal, regardless of how little-used it is.

Someone, somewhere, may need this in the future. To me, this felt just like a small omission in the extensive support you've already built for X.509; an oversight that could easily be resolved.

But I understand and appreciate that you must draw the line somewhere. Scope creep and future maintenance burden is also important to keep in check.

[ralphje]

Adding to myself here, and although I feel that RFC-completeness and NIST PKITS compliance are compelling cases, I did do some further research into this extension, and found that it is common practice in some bridge and cross certification schemes.

The US Government uses the Federal Bridge CA, featuring cross-certificates with policy mappings, to interoperate with various federal agencies, such as the Treasury.

A similar use case can be found in the CertiPath Federated Trust cross-CA. I have also found references to SAFE-BioPharma, but couldn't locate any trustworthy source for that one.

Reading through those specifications, I also realised that the Policy Constraints extension explicitly states that implementations that support inhibitPolicyMapping must also support the Policy Mapings extension, and if it doesn't, must reject this extension if that field is present and the extension is marked as critical. And that is something that these cross-CAs are actually doing (e.g. CertiPath X.509 Certificate Policy, section 7.1.7).

I'm not sure whether you find these are compelling cases. If cryptography wants to focus on WebPKI exclusively: I haven't found any evidence that this extension is actually used there, most likely due to the inherent hierarchical nature and lack of distinct sovereign trust domains. And like you said, certificate polices are complex (even RFC 9618 addresses that explicitly), further reducing their use to those found in my research.

[alex]

The X.509 RFCs are too gargantuan for RFC-completeness to be a real goal. As an alumni of the US Government, the federal PKI is one of the worst things in existence, and I'm loathe to do anything for it.

We have support for certificate policies in our x.509 verification APIs, therefore the only thing adding PolicyMapping does ATM is encode/decode them -- which can be done externally at this point. If there are ways we can make external X.509 extensions easier, that's something we can consider, but otherwise unless @reaperhulk disagrees, I think this is wontfix.

[ralphje]

Thank you for your consideration (again). If you feel that strongly about it, closing this PR without merging is likely the best way forward.

Adding to your comment, it would be awesome if there was a way to add support for custom extensions in the long run, e.g. such that something like get_extension_for_class would work on custom extension subclasses.

On a related note, I've tried implementing the extension manually using those ASN.1 APIs, but found that an extension containing a sequence of sequences could not be decoded with the current ASN.1 support. The main reason for that is that asn1.decode_der does not appear to support native types, so that an PolicyMappings UnrecognizedExtension.values DER bytes, that I typed as list[PolicyMapping] (PolicyMapping being a sequence), seems currently not accepted (i.e. asn1.decode_der(list[PolicyMapping], ...) fails).

I'm not confident that I've tested and researched this well enough to open a feature request/issue for this, in the hopes of this getting merged, but wanted to put this additional complication in the context of this PR.

[alex]

If asn1.decoder_der(list[ASN1Type], ...) doesn't work, that seems like a bug we should fix.

[alex]

(Please file a seperate bug for that and also bugs for any other improvements, thanks!)