L46: C-core: New TLS Credentials API #422
Conversation
L46-core-tls-credential-API.md
Outdated
| // (in the one-side TLS scenario, the server is not required to provide root | ||
| // certs). We don't support default root certs on server side. | ||
| void watch_root_certs(); | ||
| // Sets the name of root certificates being watched, if |watch_root_certs| is |
There was a problem hiding this comment.
Pinging this so we don't lose it.
| ~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.
| // Sets the certificate verifier. The certificate verifier performs checks on | ||
| // the peer certificate chain after the chain has been (cryptographically) | ||
| // verified to chain up to a trusted root. | ||
| // If unset, this will default to the `HostNameCertificateVerifier` detailed |
There was a problem hiding this comment.
We should note that, if you call set_certificate_verifier(nullptr), this will overwrite the host name verifier and lead you to not doing any checks (aside from the cryptographic ones).
| // Sets the certificate verifier. The certificate verifier performs checks on | ||
| // the peer certificate chain after the chain has been (cryptographically) | ||
| // verified to chain up to a trusted root. | ||
| // If unset, this will default to the `HostNameCertificateVerifier` detailed |
There was a problem hiding this comment.
Should it only do this default on the client-side?
There was a problem hiding this comment.
That's a good question - I think it depends on other defaults, and if we are doing MTLS vs. TLS? I'll double check, but I don't believe this is called unless it is configured to do MTLS.
L46-core-tls-credential-API.md
Outdated
| Note that there is a naming mismatch here - there exist credentials beyond | ||
| certificates that this _could_ theoretically support. This provider is | ||
| responsible for sourcing key material and supplying it to the internal stack via | ||
| the `CertificateProvider`'s `SetKeyMaterials` API. Two reference |
There was a problem hiding this comment.
This sentence needs to be updated as the SetKeyMaterials API no longer exists.
There was a problem hiding this comment.
I believe I already fixed this in the most recent commit, PTAL
L46-core-tls-credential-API.md
Outdated
| // Does important internal setup steps. | ||
| void Start(); | ||
|
|
||
| // The case of a SPIFFE trust bundle still falls into RootCertificates, it's |
There was a problem hiding this comment.
This comment is coming from the review but, as written, it's a bit of a non sequitur. Can we add comments for each line in the enum, and this can be part of the RootCertificates comment?
L46-core-tls-credential-API.md
Outdated
| public: | ||
| virtual ~CertificateProviderInterface() = default; | ||
|
|
||
| // Must be called after the constructor. |
There was a problem hiding this comment.
The user does not call the constructor, so should we say e.g. "// Starts the provider. Must be called before the provider is used for any TLS handshakes."?
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?
L46-core-tls-credential-API.md
Outdated
| // If error status, failed synchronously. | ||
| // If OK status and true, succeeded synchronously. | ||
| // If OK status and false, verification is still in progress asynchronously. | ||
| virtual absl::StatusOr<bool> Verify(VerifiedPeerCertificateChainInfo* request, |
There was a problem hiding this comment.
micro-nit: I don't think the variable name should still be "request".
There was a problem hiding this comment.
Changed to verified_chain_info
L46-core-tls-credential-API.md
Outdated
| // verification request is pending. | ||
| // | ||
| // request: the verification information associated with this request | ||
| virtual void Cancel(VerifiedPeerCertificateChainInfo* request) = 0; |
There was a problem hiding this comment.
micro-nit: I don't think the variable name should still be "request".
There was a problem hiding this comment.
Changed to verified_chain_info
| */ | ||
| // This represents a potential decoupling of roots and identity chains, with | ||
| // further extension points for something like SPIFFE bundles | ||
| class CertificateProviderInterface { |
There was a problem hiding this comment.
Apologies if I'm a broken record with the "watch_root_certs" and "set_root_cert_name" APIs: can we move this functionality to the cert provider rather than having it on the options?
There was a problem hiding this comment.
I don't believe so - I believe the intention is that a provider could be serving many different sets of creds, thus they need to be separated by user-defined names.
Then the specific TlsCredentialsOptions struct used to create a specific TlsCredentials needs to know which creds from the provider they need, so the name has to be set there.
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.