Provide an extensible and usable configuration API

[briansmith]

The current API for configuration has intentionally been narrow because when I started this project I intended to support only a narrow set of use cases, and also this project served as a rhetorical device in the advocacy for people to Do the Right Thing on the production end of X.509 stuff. Now this project is more open to supporting other use cases and in order to support those use cases we need some more configuration capability.

Most likely, we need an API that is more like other Rust APIs where users would construct a Verifier with some configuration, and then hold onto that Verifier across multiple verifications (e.g. one Verifier per Rustls ClientConfig/ServerConfig).

The construction of the Verifier should be where things like supported_sig_algs: &[&SignatureAlgorithm] and TlsServerTrustAnchors: &TlsServerTrustAnchors<'_> are configured.

For the cases where we want users to opt into supporting "bad" things for compatibility, we should have an Options structure that is an input to the construction of Verifier, where new options can be added without breaking changes to public API.

For the cases where we want users to be able to configure the type(s) of name(s) to be accepted, that should choice should happen during the construction of the Verifier or Options, where the default will continue to be `DNS Names only" or maybe "DNS Names and IP addresses only" or more generally "Name forms allowed in the Web PKI".

[briansmith]

Right now, we have separate APIs verify_is_valid_tls_server_cert and verify_is_valid_tls_client_cert. This is problematic especially if you look at the duplication in the implementation of Rustls's use of webpki, and also because it isn't extensible to new kinds of EKUs that people need to be able to use for new use cases. verify_is_valid_tls_server_cert and verify_is_valid_tls_client_cert should be replaced by a single function that is parameterized on which peer roles to accept.

It would be good for the Verifier be set up during its construction with an allowlist of peer roles to accept. However, I worry that this might encourage users to construct a single Verifier with multiple EKUs (e.g. TLS clientAuth and TLS serverAuth) and then use it across multiple use cases (e.g. verifying client certificates in a server, and verifying server certificates in a client). So, it is also probably important that the new function also continue to accept a role as a parameter; then the verification would use the intersection of the argument role(s) and the allowlist for which the Verifier was configured.

[briansmith]

We also seem to need a configuration API to allow per-root options, generalizing the per-root name constraints we already have. For example, #232 (comment) is an instance where we probably want to allow the flexibility for the application to configure publicly-trusted CAs to only issue certificates with valid serial numbers while allowing other (presumably enterprise MitM) CAs to issue certificates with malformed serial numbers.

[briansmith]

It would be good for the Verifier be set up during its construction with an allowlist of peer roles to accept. However, I worry that this might encourage users to construct a single Verifier with multiple EKUs (e.g. TLS clientAuth and TLS serverAuth) and then use it across multiple use cases (e.g. verifying client certificates in a server, and verifying server certificates in a client). So, it is also probably important that the new function also continue to accept a role as a parameter; then the verification would use the intersection of the argument role(s) and the allowlist for which the Verifier was configured.

The exact same considerations apply to how we deal with the different forms of names. In particular, an application might want to accept X.500 Directory Names for client certificates (to allow people to log in with a smart card) but accepting a Directory Name for a TLS server is overwhelmingly likely to be the wrong thing to do. So, again, we might want to have an allowlist of name forms to allow during the construction of the Verifier but we'd need some way to help users avoid reusing that Verifier in the wrong context.