Remember certificate policies extensions but do nothing further

[kikuomax]

Deal with certificate policies extensions so that rustls-webpki won't fail when it faces a critical certificate policies extensions.

• fixes Support anyPolicy Certificate Policy #30

This PR makes rustls-webpki remember the values of the certificate policies extensions it faces but do nothing further. This change lets rustls-webpki accept certificates with invalid critical certificate policies extensions, though, this should be at least equivalent to OpenSSL's default behavior.

If one wants to verify the policy tree, can use verify_path option to do so. You can find an example in my fork.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (eed037b) 97.21% compared to head (0471312) 97.23%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #211      +/-   ##
==========================================
+ Coverage   97.21%   97.23%   +0.02%     
==========================================
  Files          19       19              
  Lines        4266     4268       +2     
==========================================
+ Hits         4147     4150       +3     
+ Misses        119      118       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[djc]

This looks okay to me.

If the test depends on the newly introduced behavior (not clear to me if it does?), I suggest that we switch the order of commits such that all commits can pass tests (since we rebase). (I suppose we could also just squash these commits.)

[ctz]

I don't think we should do this. The default openssl behaviour is incorrect and drives a bus through the intended meaning of extension criticality.

What do the BRs say about the cert policy extension?

Remove approval pending Joe's concerns

[kikuomax]

I don't think we should do this. The default openssl behaviour is incorrect and drives a bus through the intended meaning of extension criticality.

I understand your concern. Integrity should not be compromised for a very specific use case.
@djc @ctz Is there any chance to have this as an opt-in feature like accept-invalid-policies?

Anyway, please reject this PR if it is not relevant.

[kikuomax]

If the test depends on the newly introduced behavior (not clear to me if it does?), I suggest that we switch the order of commits such that all commits can pass tests (since we rebase). (I suppose we could also just squash these commits.)

@djc The order of commits reflected my test-driven approach. I will reorder them if this PR would be accepted.

[djc]

What exactly is the use case for this? Why would someone want to ignore these invalid extensions?

[cpu]

What do the BRs say about the cert policy extension?

All of the locations in the server cert baseline requirements that describe this extension list it as non-critical:

• 7.1.2.1.2 Root CA Extensions - NOT RECOMMENDED, not critical
• 7.1.2.2.3 Cross-Certified Subordinate CA Extensions - MUST presence, not critical
• 7.1.2.3.1 Technically Constrained Non-TLS Subordinate CA Extensions - MAY presence, not critical
• 7.1.2.4.1 Technically Constrained Precertificate Signing CA Extensions - MUST presence, not critical
• 7.1.2.5.1 Technically Constrained TLS Subordinate CA Extensions - MUST presence, not critical
• 7.1.2.7.6 Subscriber Certificate Extensions - MUST presence, not critical
• 7.1.2.8.2 OCSP Responder Extensions - MUST NOT presence, not critical

[kikuomax]

What exactly is the use case for this? Why would someone want to ignore these invalid extensions?

@djc My use case is not client-server communication but server-side verification of signatures signed by authenticator devices in the context of Web Authentication. I commented in Issue #30:

• Support anyPolicy Certificate Policy #30 (comment)

The certificate policies in the certificate chain I attached to the above comment are valid, but the end entity certificate contains a critical certificate policy extension:

            X509v3 Certificate Policies: critical
                Policy: 1.3.6.1.4.1.311.21.31
                  User Notice:
                    Explicit Text:

I did not mean to make it accept invalid extensions, however, I need more study to propose comprehensive validation.

[cpu]

I think we should close this PR for now. I agree with ctz's earlier assessment.

[kikuomax]

@cpu Sorry for a stale PR. I would like to come back to this issue later.