proposal: crypto/tls: add support for delegated credentials

[aaslamin]

This proposal is to add support to the crypto/tls package for the new cryptographic protocol, delegated credentials, which will be an extension to TLS. It's currently in the process of being adopted as a standard by the IETF.

Some benefits:

Key protection: rather than deploying the actual private key associated with the certificate that was issued to you by the CA to each server that fronts TLS, one can instead create and issue a delegated credential. This credential can have a much shorter life span than that of the original certificate and one does not need to contact the CA to have it provisioned each time. The client can still verify the chain of trust as the delegated credential is still signed by the certificate obtained by the CA.

Experimentation for new PK algorithms: in addition to the security benefits it provides to protecting keys, it enables for servers to experiment rolling out support for new authentication mechanisms which are tied to the certificate being served. Essentially, the server can try out a new authentication type without altering the certificate the was issued to them by the CA.

Concerns:

• I am not sure about Go's policy for adding support of draft RFC's to the standard library, although this one seems promising in that it will land? Thoughts?

---

Cc: @FiloSottile

[FiloSottile]

Not an RFC yet, and we never implement drafts. Also, we usually wait until there is wide ecosystem support before implementing things.

Then there are the two fundamental questions: what does a good API for it look like, and are Go deployments going to benefit from this enough to justify the complexity.

[aaslamin]

Sounds good @FiloSottile!

Would love to work on this when the time comes 🙃

[hslatman]

The RFC is complete now: https://datatracker.ietf.org/doc/rfc9345/

At Cloudflare support for this was added to their fork of Go in https://github.com/cloudflare/go/pull/28.