return most specific error from path building failures

[cpu]

This branch adopts the "specificity ranking" strategy discussed in #79. In particular this allows us to surface CRL revocation errors like CertRevoked without them being turned into generic UnknownIssuer errors.

Resolves #79.

error: introduce ranking of errors by specificity.

This commit introduces a error.most_specific function that can compare two Error instances, returning the one that is "most specific". This is primarily useful for the context of path building where we may encounter several errors while trying to build a path to a trust anchor, and want to return the one that will be most useful to an end user for diagnosing the problem at hand. Without this feature we always yield Error::UnknownIssuer, even when the issuer is known and some more specific problem has been detected.

Since introducing more specific errors has changed the expected error result for several of the generated tests we temporarily #ignore them so that this commit can build clean without needing to bundle in a large diff regenerating test content. This will be undone in subsequent commits to restore test coverage.

The code in this diff was originally proposed in briansmith/webpki#188 by @stepancheg - All credit to them for the idea and the base implementation I've extended/adapted.

tests: update generator expected errors.

Now that we yield more specific errors for some path building error conditions the generated test suite tests need to be updated to stop expecting the generic UnknownIssuer error and instead expect the more specific error relevant to the test case.

This also fixes a few bugs in the generated tests:

• A couple of the CRL tests were using the wrong keys to sign the CRL. These mistakes were being masked by the unspecific errors returned previously.

• The intermediate CRL wrong key usage tests wouldn't work as written! Since the chain was EE->intermediate->trust anchor the intermediate CRL was always signed by a trust anchor and we don't track key usage for those. To fix this we now generate a chain like EE->intermediate A->intermediate B->trust anchor and can test that a CRL revoking intermediate A when signed by intermediate B without the right KU errors.

tests: regen server_cert and client_auth_rev tests.

Generated with:

cd tests
./generate.py --tls-server-certs --no-signatures --no-client-auth --client-auth-revocation

[codecov]

Codecov Report

Merging #89 (885722f) into main (9577180) will decrease coverage by 0.53%.
The diff coverage is 67.14%.

@@            Coverage Diff             @@
##             main      #89      +/-   ##
==========================================
- Coverage   95.93%   95.40%   -0.53%     
==========================================
  Files          15       15              
  Lines        3219     3262      +43     
==========================================
+ Hits         3088     3112      +24     
- Misses        131      150      +19     

Impacted Files	Coverage Δ
src/error.rs	42.22% <39.47%> (-14.93%)	⬇️
src/verify_cert.rs	95.08% <100.00%> (+1.77%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[ctz]

i think this is pretty good -- making up ordinals for each error and comparing those is a bit around-the-houses but i can't think of a less complex option. and i prefer the option of having a explicit most_specific_error function rather than implementing PartialOrd on Error.