-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide an extensible and usable configuration API #249
Comments
Right now, we have separate APIs It would be good for the |
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. |
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 |
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 thatVerifier
across multiple verifications (e.g. oneVerifier
per RustlsClientConfig
/ServerConfig
).The construction of the
Verifier
should be where things likesupported_sig_algs: &[&SignatureAlgorithm]
andTlsServerTrustAnchors: &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 ofVerifier
, 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
orOptions
, 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".The text was updated successfully, but these errors were encountered: