proposal: Add extensionCertificateAuthorities to the clientHelloMsg structure

[SailKog]

Proposal Details

The definition of extensionCertificateAuthorities exists in the tls/common.go file. // TLS extension numbers const ( ... extensionCertificateAuthorities uint16 = 47 ... )

However, this field can be carried only in the CertificateRequest message. According to RFC 8446, the CertificateRequest can be carried in the ClientHello message.

Can crypto\tls add support for this field in ClientHello?

[ianlancetaylor]

I'm not clear on what the actual proposal is here. Can you show the API change that you would like to see? Thanks.

[SailKog]

1. Add new member in Config struct

type Config struct {
...
extensionCertificateAuthorities []string
...
}

2. Add extensionCertificateAuthorities to clientHelloMsg (client case)
3. Applications can then create extensions with simply

config := testConfig.Clone()
	config.extensionCertificateAuthorities= []string{"CA1", "CA2"}

to meet RFC 8446 4.2.4. Certificate Authorities

[seankhliao]

is that a private field?

[SailKog]

This is not a private field. It is defined in RFC8446 of the TLS protocol.

[ianlancetaylor]

Do you mean that we should add ExtensionCertificateAuthorities? Adding the unexported field extensionCertificateAuthorities would not require a proposal.

[FiloSottile]

We support a subset of all possible TLS extensions to limit complexity. certificate_authorities in Client Hello is rarely used and has size issues when supporting more than a handful of CAs.

[SailKog]

Well, we've chosen to use openssl directly to solve this problem. I can accept Crypto's consideration of complexity.

[whiteblad-k]

config := testConfig.Clone() config.extensionCertificateAuthorities= []string{"CA1", "CA2"}

[whiteblad-k]

config := testConfig.Clone() config.extensionCertificateAuthorities= []string{"CA1", "CA2"}