gep: standardizing behavior for invalid BackendTLSPolicy (#3909)

* gep: standardizing behavior for invalid BackendTLSPolicy

Signed-off-by: Norwin Schnyder <[email protected]>

* Apply PR feedback

Signed-off-by: Norwin Schnyder <[email protected]>

* Incorporate feedback from various discussions

Signed-off-by: Norwin Schnyder <[email protected]>

* Introduce ResolvedRefs status condition for BackendTLSPolicy

* Apply PR suggestions and feedback

Signed-off-by: Norwin Schnyder <[email protected]>

* Fix typos

Signed-off-by: Norwin Schnyder <[email protected]>

---------

Signed-off-by: Norwin Schnyder <[email protected]>

Author: snorwin

geps/gep-1897/index.md

@@ -214,6 +214,13 @@ configuration. CACertificateRefs is an implementation-specific slice of
 named object references, each containing a single cert. We originally proposed to follow the convention established by the
 [CertificateRefs field on Gateway](https://github.com/kubernetes-sigs/gateway-api/blob/18e79909f7310aafc625ba7c862dfcc67b385250/apis/v1beta1/gateway_types.go#L340)
 , but the CertificateRef requires both a tls.key and tls.crt and a certificate reference only requires the tls.crt.
+If any of the CACertificateRefs cannot be resolved (e.g., the referenced resource does not exist) or is misconfigured (e.g., ConfigMap does not contain a key named `ca.crt`), the `ResolvedRefs` status condition MUST be set to `False` with `Reason: InvalidCACertificateRef`. Connections using that CACertificateRef MUST fail, and the client MUST receive an HTTP 5xx error response.
+References to objects with an unsupported Group and Kind are not valid, and MUST be rejected by the implementation with the `ResolvedRefs` status condition set to `False` and `Reason: UnsupportedFeature`.
+Implementations MAY perform further validation of the certificate content (i.e., checking expiry or enforcing specific formats). If they do, they MUST ensure that the `ResolvedRefs` Condition is `False` and use an implementation-specific `Reason`, like `ExpiredCertificate` or similar.
+If `ResolvedRefs` Condition is `False` implementations SHOULD include a message specifying which references are invalid and explaining why.
+
+If all CertificateRefs cannot be resolved, the BackendTLSPolicy is considered invalid and the implementation MUST set the `Accepted` Condition to `False`, with a reason of `NoCACertificates` and a message explaining this.
+
 WellKnownCACertificates is an optional enum that allows users to specify whether to use the set of CA certificates trusted by the
 Gateway (WellKnownCACertificates specified as "System"), or to use the existing CACertificateRefs (WellKnownCACertificates
 specified as "").  The use and definition of system certificates is implementation-dependent, and the intent is that
@@ -222,8 +229,12 @@ references to Kubernetes objects that contain PEM-encoded TLS certificates, whic
 between the gateway and backend pod. References to a resource in a different namespace are invalid.
 If ClientCertificateRefs is unspecified, then WellKnownCACertificates must be set to "System" for a valid configuration.
 If WellKnownCACertificates is unspecified, then CACertificateRefs must be specified with at least one entry for a valid configuration.
-If WellKnownCACertificates is set to "System" and there are no system trusted certificates or the implementation doesn't define system
-trusted certificates, then the associated TLS connection must fail.
+If an implementation does not support the WellKnownCACertificates, or the provided value is unsupported,the BackendTLSPolicy is considered invalid, and the implementation MUST set the `Accepted` Condition to `False`, with a reason of `UnsupportedFeature` and a message explaining this.
+
+For an invalid BackendTLSPolicy, implementations MUST NOT fall back to unencrypted (plaintext) connections. 
+Instead, the corresponding TLS connection MUST fail, and the client MUST receive an HTTP 5xx error response.
+
+Implementations MUST NOT modify any status other than their own. Ownership of a status is determined by the `controllerName`, which identifies the responsible controller.
 
 The `Hostname` field is required and is to be used to configure the SNI the Gateway should use to connect to the backend.
 Implementations must validate that at least one name in the certificate served by the backend matches this field.