Make `TrustAnchor::try_from_cert_der` less of an attractive nuisance about webpki

[briansmith]

One absolutely MUST NOT treat an end-entity certificate as a TrustAnchor, because a TrustAnchor is trusted for issuing other certificates; i.e. a TrustAnchor is a "root CA" and so it would be trusted to issue certificates for other websites. The way to implement "certificate error overrides" and TOFU and similar is NOT to do anything with TrustAnchor.

To further clarify, constructing a TrustAnchor from a self-signed certificate for the purpose of "accepting self-signed certificates" is absolutely NOT a safe way to implement such things.

[briansmith]

Any time you are thinking of using "self-signed certificate" or "end-entity certificate" and TrustAnchor together, you are almost surely on the verge of something that is very dangerous. webpki (and similar things, AFAICT) does not provide any facilities for helping with self-signed certificates or certificate error overrides.

[briansmith]

"Trust anchor" is defined in RFC 5280, in https://datatracker.ietf.org/doc/html/rfc5280#section-6.1.1 and other parts.

[est31]

Any time you are thinking of using "self-signed certificate" or "end-entity certificate" and TrustAnchor together, you are almost surely on the verge of something that is very dangerous. webpki (and similar things, AFAICT) does not provide any facilities for helping with self-signed certificates or certificate error overrides.

What would be your recommendation for webpki users who want to use TOFU approaches for their app or similar?

Maybe if the Certificate is found as user-added exception, they should skip doing the verify_is_valid_tls_server_cert check and only do verify_is_valid_for_dns_name and verify_signature? Is there a security benefit for such users in not doing verify_is_valid_tls_server_cert?