L46: C-core: New TLS Credentials API #422
Conversation
| ~TlsCustomVerificationCheckRequest() {} | ||
|
|
||
| absl::string_view target_name() const; | ||
| absl::string_view peer_cert() const; |
There was a problem hiding this comment.
I think that comment is another signal that this API is not useful for anyone since they cannot really predict what the return value should be. I think we should probably deprecate + delete this API and replace it with APIs that return predictable and explicit values.
L46-core-tls-credential-API.md
Outdated
| // identity certificates(single side TLS). | ||
| class TlsChannelCredentialsOptions final : public TlsCredentialsOptions { | ||
| public: | ||
| // Sets the decision of whether to do a crypto check on the server certs. |
There was a problem hiding this comment.
Despite the other comment, I think we need to clean up this comment so that it is more precise. :)
| ~TlsCustomVerificationCheckRequest() {} | ||
|
|
||
| absl::string_view target_name() const; | ||
| absl::string_view peer_cert() const; |
There was a problem hiding this comment.
How do we get a verified chain on resumed handshakes?
| ~TlsCustomVerificationCheckRequest() {} | ||
|
|
||
| absl::string_view target_name() const; | ||
| absl::string_view peer_cert() const; |
There was a problem hiding this comment.
Ya that's what I was hinting at. Resumed handshakes skip the cryptographic verification, but I'm not sure if they skip the post-handshake verification. If that's correct, we need to explain that some of these fields may not be available on resumed handshakes.
This PR is subsuming the previous PR of the same title (#205), and attempting to bring the content to the current state with the goal of formally merging this and moving these API from experimental to stable.
This is still under active work and is not ready for final review.