Goal
Add optional support for RFC 9345 – TLS Delegated Credentials on top of Portal's existing Keyless TLS architecture.
Today, the tunnel terminates tenant TLS but calls the relay's /v1/sign during full TLS handshakes.
With RFC 9345, the relay can periodically delegate TLS authentication to a short-lived key generated by the tunnel:
Relay
└─ long-term certificate key
↓ signs periodically
Delegated Credential
↓
Tunnel
└─ short-lived private key
↓
local TLS handshakes
This removes /v1/sign from the handshake hot path for compatible clients while keeping the long-term certificate private key on the relay.
Compatibility
Use Delegated Credentials when the client advertises RFC 9345 support. Otherwise, fall back to the existing Keyless TLS path.
RFC 9345 client → Delegated Credential → local signing
Other clients → Keyless TLS → /v1/sign
Current constraints
- The relay certificate must contain the RFC 9345
DelegationUsage extension.
- Ordinary wildcard certificates without this extension cannot be used for delegation.
- CA support for
DelegationUsage is currently limited.
- Browser support is currently limited, so Keyless TLS must remain as a compatibility fallback.
- Prefer a native Go implementation rather than introducing BoringSSL/CGO into the production binary.
Direction
Keep the existing relay-owned wildcard certificate and long-term private key.
Add a credential-level operation such as:
The tunnel generates an ephemeral key, receives a short-lived Delegated Credential from the relay, and renews it before expiration.
RFC 9345 should initially be experimental and capability-gated, with the existing Keyless TLS path used as fallback.
Goal
Add optional support for RFC 9345 – TLS Delegated Credentials on top of Portal's existing Keyless TLS architecture.
Today, the tunnel terminates tenant TLS but calls the relay's
/v1/signduring full TLS handshakes.With RFC 9345, the relay can periodically delegate TLS authentication to a short-lived key generated by the tunnel:
This removes
/v1/signfrom the handshake hot path for compatible clients while keeping the long-term certificate private key on the relay.Compatibility
Use Delegated Credentials when the client advertises RFC 9345 support. Otherwise, fall back to the existing Keyless TLS path.
Current constraints
DelegationUsageextension.DelegationUsageis currently limited.Direction
Keep the existing relay-owned wildcard certificate and long-term private key.
Add a credential-level operation such as:
The tunnel generates an ephemeral key, receives a short-lived Delegated Credential from the relay, and renews it before expiration.
RFC 9345 should initially be experimental and capability-gated, with the existing Keyless TLS path used as fallback.