Potentially anomalous path-building results

[woodruffw]

Hi there! I'm opening this to help root-cause a handful of anomalous path-building results observed with certvalidator, which we found with x509-limbo.

As a disclaimer: many of these are likely to be non-issues from certvalidator's perspective, so please don't interpret this issue as a demand or expectation for everything on the linked results page to be fixed. X.509 validators have a huge range of behaviors in practice and many of the failures are either due to "pedantic" readings of RFC 5280 or explicitly unsupported features (e.g. Name Constraints, in certvalidator's case).

There are, however, some results for which certvalidator is an outlier or otherwise should probably consider some changes. A non-exhaustive sampling:

• rfc5280::aki::critical-aki: all other implementations (except Go, which is fixing their behavior) under test reject critical AKIs; certvalidator accepts it;
• pathological::nc-dos-1 and pathological::nc-dos-3: implementations typically establish a NC comparison budget to prevent quadratic blowup, but certvalidator appears to churn through them instead (taking over 30 seconds on my machine). I haven't fully root-caused this one, but was surprised since certvalidator otherwise appears to reject any critical NC extensions);
• webpki::san::wildcard-embedded-leftmost-san: implementations should reject SAN patterns with non-leftmost wildcards (e.g. ba*.example.com), per both RFC 6125 and CABF;
• cve::cve-2024-0567: this is a test for a chain-building failure in an older version of GnuTLS, which certvalidator also fails to construct a chain for here. The error here is pretty strange, since certvalidator appears to handle SANs in other contexts.

There are others as well, but these ones stood out as initial candidates for fixes.

Please let me know if there's any other information I can provide, or if I can help in any way! I'm not super familiar with certvalidator's internals, but I may be able to help resolve some of these with some guidance on the codebase 🙂

[woodruffw]

And for context, here's a similar issue we filed with another X.509 validator (Go's crypto/x509): golang/go#65085.