Add opt-in support for ignoring URI name constraints

[jmcguire98]

As of release 0.103.12, which has the fix for GHSA-965h-392x-2mh5, a chain containing a URI name constraint is now rejected unconditionally, where previously the constraint was silently ignored.

This definitely makes sense as a default, but it's a breaking change for anyone whose CAs already carry URI name constraints. Webpki doesn't expose an API to assert URI names in the first place, so callers who care about URI name constraints may have been enforcing them themselves against the verified cert chain. For those callers the unconditional rejection short-circuits path validation before any other enforcement can run, and AFAICT there's no way to keep things working short of pinning a pre-0.103.12 version.

Is there any room for an opt-in (eg a flag on the verifier) that restores the old "ignore URI name constraints" behavior and leaves enforcement to the caller? Happy to submit a PR for this if there's interest.

[djc]

I'd be more interested in having actual strict working verification of URI name constraints. Would your organization be able to help fund work in that direction?

[jmcguire98]

At this point we're more interested in having the escape hatch available than in funding a full strict implementation of URI name constraint verification.

Given how limited support for URI name constraints currently is in the wild (the SPIFFE X.509-SVID standard says as much) it's hard for us to justify prioritizing a full implementation right now. Our interest is mostly in unblocking our customers who may want URI name constraints on their CAs for integration with other software in their ecosystem.

I'll freely admit this feeds into a bit of a chicken-and-egg problem where widespread support can never materialize if nobody's willing to sponsor or contribute it, but I don't think we have the appetite to be that party at the moment either.

If the opt-in escape is something you'd be willing to accept anyway, I'm happy to put up a PR.