Joe Birr-Pixton

It's a correct observation that we don't currently look at the keyUsage extension. But if that were to change I don't think it would appear in the public API, instead:...

Have you considered https://github.com/pyca/cryptography/tree/main/src/rust/cryptography-x509-verification ? As far as I understand, that has a more general goal than this one.

Yes, this needs openssl to be installed and available on the system you're building on. That'll make using it on Windows quite challenging.

I was thinking originally we could call the new consistency API `CertifiedKey::keys_match` in several places that accept `CertifiedKey`s and are already fallible. There are only a few such places, but...

> Let me try and summarize some things I think we have agreement on (_of course this is an invitation to please chime in if I'm misrepresenting anything_). Thanks for...

> I don't feel strongly. @ctz do you want to be a tie breaker? Maybe I can get there by enumerating the things I don't think work, lol: - `keys_match(&self)...

> Is there a meaningful/not contrived way to add test coverage for the `Display` of this new error variant? Add a line into this test: https://github.com/rustls/rustls/blob/3bb255cd58cda65f3e8a998f71df03429f03941c/rustls/src/error.rs#L724

> Because key exchange wasn't negotiated/performed. Do you have a non-bogo use-case in mind that would benefit from the information? I guess one point would be simplifying implementation of openssl...

I think It's exceedingly unlikely we'll do this. `decrypt` (and `encrypt`) are computation-bound and relatively small computations at that, and not IO-bound. What is your use case?

> It like cloudflare keyless I think this is already covered in #850 ("asynchronous handshake authentication signature" cases)