Dirkjan Ochtman

> Perhaps it would be better to formulate `certificate_and_key_are_consistent()` (or whatever its name ends up being) to be infallible. Instead of returning a `Result`, maybe we could return an enum...

> > Is this actually what we're doing? > > Is that your preference? Without strong signal it seems better to follow the plan [outlined by Ctz](https://github.com/rustls/rustls/issues/1918#issuecomment-2093332074) unless there's consensus...

Option 1 sounds good, maybe we should file an issue with a label to remind ourselves to remove the default impl for the next semver-breaking release?

Right, so I think this probably is the right direction still: > I think the core question is the intended behavior for crypto providers that don't implement this. I think...

> @ctz @djc How do you feel about the above? I mostly agree, the one thing I'm in doubt about is whether the `KeyConsistency` type pulls its weight in this...

Why do you want to know this? What's the use case/motivation here? Just research?

> 1. Shower thought: we could perhaps return `Option

> We return None from our API in this case because we didn't do a full KX. I don't think we should change that Why not? Does the cipher suite...

> Because key exchange wasn't negotiated/performed. Do you have a non-bogo use-case in mind that would benefit from the information? This caveat is not documented -- probably want to fix...

Have you looked at tokio-rustls and the [unbuffered](https://docs.rs/rustls/latest/rustls/unbuffered/index.html) API?