diff options
author | Ingela Anderton Andin <[email protected]> | 2014-07-31 15:21:52 +0200 |
---|---|---|
committer | Ingela Anderton Andin <[email protected]> | 2014-08-08 14:29:53 +0200 |
commit | 2fe9ed0b1171aadc87e2bed6990a9857bee55345 (patch) | |
tree | 975500bde862bde2d2fb183a289bc8ed5d7da068 /lib/public_key/asn1/OTP-PKIX.asn1 | |
parent | 2525622c384b27581c4b4cb158fc951f15ac5ca3 (diff) | |
download | otp-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 'lib/public_key/asn1/OTP-PKIX.asn1')
0 files changed, 0 insertions, 0 deletions