On Mon, Apr 16, 2018 at 2:56 AM, Tobias Gondrom <tobias.gond...@gondrom.org> wrote:
> Are there any RFCs that speak (beyond the general verification of the > certificate in mutual TLS authentication) to the need to also verify the CN > inside the client certificate against an additional whitelist _*before*_ > establishing a TLS connection. > I'm not sure what you mean by "before establishing a TLS connection", as certificates are generally exchanged during the TLS handshake, so doing anything "before establishing a TLS connection" would require the server somehow know the client's certificate a priori. There are several systems that will abort the handshake unless they receive an acceptable client certificate, however. I don't know of any RFCs for this per se, or anything that uses the Subject CN (I think almost everything has completely moved away from using the CN). However, as an example, SPIFFE is a largely Kubernetes-focused identity system which encodes a "SPIFFE ID" in the client cert's subjectAltName and uses that to determine whether clients are authorized to continue a TLS connection: https://github.com/spiffe/spiffe/blob/master/standards/X509-SVID.md -- Tony Arcieri
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
