602f4669ab
See the IETF thread here: https://www.ietf.org/mail-archive/web/tls/current/msg27292.html In particular, although the original publication of RFC 5246 had a syntax error in the field (the minimum length was unspecified), there is an errata from 2012 to fix it to be non-empty. https://www.rfc-editor.org/errata/eid2864 Currently, when empty, we implicitly interpret it as SHA1/*, matching the server behavior in missing extension in ClientHellos. However that text does not support doing it for CertificateRequests, and there is not much reason to. That default (which is in itself confusing and caused problems such as older OpenSSL only signing SHA-1 given SNI) was because, at the time, there were concerns over making any ClientHello extensions mandatory. This isn't applicable for CertificateRequest, which can freely advertise their true preferences. Change-Id: I113494d8f66769fde1362795fb08ff2f471ef31d Reviewed-on: https://boringssl-review.googlesource.com/c/33524 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> |
||
---|---|---|
.. | ||
curve25519 | ||
ed25519 | ||
poly1305 | ||
alert.go | ||
cert.pem | ||
chacha20_poly1305_test.go | ||
chacha20_poly1305.go | ||
channel_id_key.pem | ||
cipher_suites.go | ||
common.go | ||
conn.go | ||
deterministic.go | ||
dtls.go | ||
ecdsa_p224_cert.pem | ||
ecdsa_p224_key.pem | ||
ecdsa_p256_cert.pem | ||
ecdsa_p256_key.pem | ||
ecdsa_p384_cert.pem | ||
ecdsa_p384_key.pem | ||
ecdsa_p521_cert.pem | ||
ecdsa_p521_key.pem | ||
ed25519_cert.pem | ||
ed25519_key.pem | ||
fuzzer_mode.json | ||
handshake_client.go | ||
handshake_messages.go | ||
handshake_server.go | ||
hkdf_test.go | ||
hkdf.go | ||
key_agreement.go | ||
key.pem | ||
packet_adapter.go | ||
prf.go | ||
recordingconn.go | ||
rsa_1024_cert.pem | ||
rsa_1024_key.pem | ||
rsa_chain_cert.pem | ||
rsa_chain_key.pem | ||
runner_test.go | ||
runner.go | ||
shim_ticket.go | ||
sign.go | ||
ticket.go | ||
tls.go |