Expose all x509 verification policy options

[ralphje]

Although the library does a pretty good job of validating X.509 certificates following the WebPKI spec, it currently does not expose everything to allow implementing policies from other specifications or implementations.

In my case, I try to verify (legacy) code signing certificates with low RSA moduli, but minimum_rsa_modulus is not exposed to the PolicyBuilder API.

It could make sense to wrap this in some sort of algorithm policy, but perhaps that is making it more complicated than really needed. It should at least be possible to disable this check, or specify a different minimum modulus.

Additionally, it appears not possible to modify the extended_key_usage it checks for in EE certificates. Perhaps this could be worked around by defining an ExtensionPolicy, but that will require some additional (duplicate) code.

There may be more policy related settings that are unmodifiably defaulted to WebPKI standards. I believe all of these should be modifiable (or entirely disableable) by a custom policy.

permitted_public_key_algorithms and permitted_signature_algorithms were already identified and tracked in #13391

[woodruffw]

Hi @ralphje, could you say a bit more about your use case?

I think in principle this could be made part of the public PolicyBuilder API, but I think we'd be wary of doing it if it's the entry point for larger non-CABF PKI validation requests -- the X.509 validator's internals (and externals) intentionally use CABF (Web PKI) as a baseline to make it harder to introduce misuse-prone knobs.

[alex]

I'm pretty skeptical about the merits of letting users change minimum_rsa_modulus. At some level all you're allowing is users to make the entire process pointless by allowing sufficiently weak keys.

EKUs we should do though (I'm really surprised we haven't)

[ralphje]

I'm building the library https://github.com/ralphje/signify, in which I try to verify Windows signed binaries. This library has use cases in malware forensics, and I'm mostly aiming to have verification parity with Microsoft's own sigcheck.exe.

One of the properties of signed binaries is that they can contain countersignatures, cryptographically verifying when a binary was signed. This means that a binary with a signature countersigned in 2006 could still be valid today in Windows 11, despite modern security practices no longer considering them very strong. (The countersignature itself will have another cryptographic signature, that could be coonsidered more secure by today's standards, which would put trust in that reported signing date itself.)

In my library, I want to provide users with the option to decide whether they still want to verify these successfully, noting that it is indeed insecure, but still verified successfully in Windows. This is an important distinction to make; when software is verified by default in Windows, it has more potential of executing successfully (since it would still be considered trusted by SmartScreen). This could e.g. help deciding priorities regarding malicious software.

Exposing these verification policies, such as the RSA modulus, also allows for more strict checks than currently enforced by CABF. I could perhaps also see use cases where some applications are requiring signatures with very high RSA moduli, higher than required by CABF. Or use cases where the CABF enforces certain policies after certain dates, requiring flexibility from the library to handle both cases.

I do not suggest we disable this type of defaults altogether, as it makes sense to have these secure defaults for many other use cases. However, my use case shows that there should be some way of disabling such policies for other use cases. Sadly, not everything in the wild is always adhering to the latest CABF requirements. Perhaps a policy HazardousInsecureModifiableFootgunPolicyBuilder could be used to indicate to the user that this is actually quite hazardous to mess with, although how the ExtensionPolicy handles this also seems like good API design: secure by default, but still possible to modify to an implementor's requirements.

Limiting the possibilities of the cryptography library itself in this regard is, in my opinion, mostly artificially limiting the potential of this awesome library, which would be a real shame.