Thanks for your response. I think there is a confusion on the term - "server authorization check" (its another name is "secure naming check", but we decided to stick with the former). Note that it is one-side check and will be performed only at the client side to authorize the server (NOT the other way around) so, there is no need to have "TLS channel authorization check". In other words, it will play the same role as the current verify_peer_callback and will eventually supersede your PR.
On Thursday, September 6, 2018 at 10:46:25 PM UTC-7, [email protected] wrote: > > This all looks quite good to me. In particular the credential reloading > component would be really helpful for us; at the moment we've been tearing > down and reconstructing channels to handle credential reloading as needed. > This is definitely a lot better. A couple of comments to add: > > The credential reload APIs appear as though they would work just as well > on server or client side. On the other hand the "TLS server authorization > check" is an server-specific enhancement. At the risk of scope creep, would > it be worth generalizing this as a general mechanism to perform a "TLS > channel authorization check" in such a way that would supersede the PR I > was working on for the client-side verify_peer_callback > <https://github.com/grpc/grpc/pull/16395>? The mechanism seems analogous > so I'm just wondering if it's a two-birds-with-one-stone situation. > > Secondly: > >> Regarding grpc_tls_ctx_customize_config, the config is used when a caller >> wants to >> configure an underlying TLS context with customized primitives. For >> example, there could >> be a use case in which raw private keys are not directly accessible >> (e.g., hardware-backed) to a caller, >> but private key methods (e.g., “Sign” functions) are, in which case the >> config provides a means >> to customize an TLS context with an SSL_PRIVATE_KEY_METHOD object and >> associated signing algorithms. > > > I just want to throw in my support for this foresight. We've recently been > adding in support for hardware-backed private keys in other contexts > (mostly for REST based use-cases). We haven't hit a need to integrate this > with gRPC in languages other than Java and Go, but I see a desire for it in > our ecosystem coming down the pipeline in the not-too-distant future. > > On Wednesday, September 5, 2018 at 2:21:13 PM UTC-7, [email protected] > wrote: >> >> I just opened a gRFC that proposes to add a new TLS credential API with >> the purpose of supporting SPIFFE mutual TLS: >> https://github.com/grpc/proposal/pull/98. >> >> Please keep any discussion on this thread. >> > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/f4cd8d54-eadf-4917-9edd-25464a309283%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
