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.