You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(See definitions in [GEP Status][/contributing/gep#status].)
7
7
@@ -11,10 +11,11 @@ This GEP proposes a way to validate the TLS certificate presented by the downstr
11
11
(Gateway Listener in this case) during a [TLS Handshake Protocol][].
12
12
13
13
## Goals
14
-
- Define an API field to specify the CA Certificate within the Gateway Listener configuration that can be used as a trust anchor to validate the certificates presented by the client. This use case has been been highlighted in the [Gateway API TLS Use Cases][] document under point 7.
14
+
15
+
* Define an API field to specify the CA Certificate within the Gateway Listener configuration that can be used as a trust anchor to validate the certificates presented by the client. This use case has been highlighted in the [TLS Configuration GEP][] under segment 1 and in the [Gateway API TLS Use Cases][] document under point 7.
15
16
16
17
## Non-Goals
17
-
- Define other fields that can be used to verify the client certificate such as the Certificate Hash.
18
+
* Define other fields that can be used to verify the client certificate such as the Certificate Hash.
18
19
19
20
## Existing support in Implementations
20
21
@@ -30,37 +31,36 @@ This table highlights the support. Please feel free to add any missing implement
* Introduce a `Client` field of type `TLSClientContext` within [GatewayTLSConfig][] to hold TLS configuration specific to the client.
37
-
* Introduce a `Validation` field of type `TLSValidationContext` within the `Client` field that can be used to validate the peer with which the TLS connection is being made.
38
-
to the Gateway.
39
-
* Introduce a `caCertificateRefs` field within `ValidationContext` that can be used to specify a list of CA Certificates that
40
-
can be used as a trust anchor to validate the certificates presented by the client.
41
-
* This new field is mutually exclusive with the [BackendTLSPolicy][] configuation which is used to validate the TLS certificate presented by the peer on the connection between the Gateway and the backend, and this GEP is adding support for validating the TLS certificate presented by the peer on the connection between the Gateway and the downstream client.
42
-
* Introduce an optional `subjectAltNames` field within `ClientValidationContext` that can be used to specify one or more alternate names to verify the subject identity in the certificate presented by the client. The maximum number of alternate names that can be specified is implementation defined.
38
+
* Introduce a `FrontendValidation` field of type `FrontEndTLSValidationContext` within [GatewayTLSConfig][] that can be used to validate the peer(frontend) with which the TLS connection is being made.
39
+
* Introduce a `caCertificateRefs` field within `FrontEndTLSValidationContext` that can be used to specify a list of CA Certificates that can be used as a trust anchor to validate the certificates presented by the client.
40
+
* This new field is mutually exclusive with the [BackendTLSPolicy][] configuation which is used to validate the TLS certificate presented by the peer on the connection between the Gateway and the backend, and this GEP is adding support for validating the TLS certificate presented by the peer on the connection between the Gateway and the frontend (downstream client).
43
41
44
42
#### GO
45
43
46
44
```go
47
-
// TLSClientContext holds configuration specific to the client initiating the TLS connection.
48
-
typeTLSClientContextstruct {
49
-
// Validation holds configuration around validating the client initiating the TLS connection.
This section highlights use cases that may be covered in a future iteration of this GEP
125
116
126
117
* Using system CA certificates as the trust anchor to validate the certificates presented by the client.
127
-
* Supporting a permissive TLS mode where untrusted clients are allowed in, useful for debugging and migrating to strict TLS.
118
+
* Supporting a mode where validating client certficates is optional, useful for debugging and migrating to strict TLS.
119
+
* Supporting an optional `subjectAltNames` field within `ClientValidationContext` that can be used to specify one or more alternate names to verify the subject identity in the certificate presented by the client. This field falls under authorization and will be revisited when authorization is tackled as a whole in the project.
120
+
* Specifying the verification depth in the client certificates chain
0 commit comments