aboutsummaryrefslogtreecommitdiffstats
path: root/erts/example
diff options
context:
space:
mode:
authorIngela Anderton Andin <[email protected]>2014-07-31 15:21:52 +0200
committerIngela Anderton Andin <[email protected]>2014-08-08 14:29:53 +0200
commit2fe9ed0b1171aadc87e2bed6990a9857bee55345 (patch)
tree975500bde862bde2d2fb183a289bc8ed5d7da068 /erts/example
parent2525622c384b27581c4b4cb158fc951f15ac5ca3 (diff)
downloadotp-2fe9ed0b1171aadc87e2bed6990a9857bee55345.tar.gz
otp-2fe9ed0b1171aadc87e2bed6990a9857bee55345.tar.bz2
otp-2fe9ed0b1171aadc87e2bed6990a9857bee55345.zip
ssl: Correct handling of certificate_types in Certificate Requests
FROM TLS 1.2 RFC: The interaction of the certificate_types and supported_signature_algorithms fields is somewhat complicated. certificate_types has been present in TLS since SSLv3, but was somewhat underspecified. Much of its functionality is superseded by supported_signature_algorithms. The following rules apply: - Any certificates provided by the client MUST be signed using a hash/signature algorithm pair found in supported_signature_algorithms. - The end-entity certificate provided by the client MUST contain a key that is compatible with certificate_types. If the key is a signature key, it MUST be usable with some hash/signature algorithm pair in supported_signature_algorithms. - For historical reasons, the names of some client certificate types include the algorithm used to sign the certificate. For example, in earlier versions of TLS, rsa_fixed_dh meant a certificate signed with RSA and containing a static DH key. In TLS 1.2, this functionality has been obsoleted by the supported_signature_algorithms, and the certificate type no longer restricts the algorithm used to sign the certificate. For example, if the server sends dss_fixed_dh certificate type and {{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply with a certificate containing a static DH key, signed with RSA- SHA1.
Diffstat (limited to 'erts/example')
0 files changed, 0 insertions, 0 deletions