diff options
author | Ingela Anderton Andin <[email protected]> | 2018-05-04 17:42:28 +0200 |
---|---|---|
committer | Ingela Anderton Andin <[email protected]> | 2018-07-10 16:21:38 +0200 |
commit | 636ff07209b9f3c48dbfa75b7ca4ede02b11caab (patch) | |
tree | 9210c6630ae89cd177b34749dec37590977c6997 /lib/ssl/test/ssl_npn_hello_SUITE.erl | |
parent | dd8d31fdeb3237deddfe2c5cccebf13fb97d7719 (diff) | |
download | otp-636ff07209b9f3c48dbfa75b7ca4ede02b11caab.tar.gz otp-636ff07209b9f3c48dbfa75b7ca4ede02b11caab.tar.bz2 otp-636ff07209b9f3c48dbfa75b7ca4ede02b11caab.zip |
ssl: Correct key_usage check
The Key Usage extension is described in section 4.2.1.3 of X.509, with the following possible flags:
KeyUsage ::= BIT STRING {
digitalSignature (0),
nonRepudiation (1), -- recent editions of X.509 have
-- renamed this bit to contentCommitment
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
keyCertSign (5),
cRLSign (6),
encipherOnly (7),
decipherOnly (8) }
In SSL/TLS, when the server certificate contains a RSA key, then:
either a DHE or ECDHE cipher suite is used, in which case the RSA key
is used for a signature (see section 7.4.3 of RFC 5246: the "Server
Key Exchange" message); this exercises the digitalSignature key usage;
or "plain RSA" is used, with a random value (the 48-byte pre-master
secret) being encrypted by the client with the server's public key
(see section 7.4.7.1 of RFC 5246); this is right in the definition of
the keyEncipherment key usage flag.
dataEncipherment does not apply, because what is encrypted is not
directly meaningful data, but a value which is mostly generated
randomly and used to derive symmetric keys. keyAgreement does not
apply either, because that one is for key agreement algorithms which
are not a case of asymmetric encryption (e.g. Diffie-Hellman). The
keyAgreement usage flag would appear in a certificate which contains a
DH key, not a RSA key. nonRepudiation is not used, because whatever is
signed as part of a SSL/TLS key exchange cannot be used as proof for a
third party (there is nothing in a SSL/TLS tunnel that the client
could record and then use to convince a judge when tring to sue the
server itself; the data which is exchanged within the tunnel is not
signed by the server).
When a ECDSA key is used then "keyAgreement" flag is needed for beeing
ECDH "capable" (as opposed to ephemeral ECDHE)
Diffstat (limited to 'lib/ssl/test/ssl_npn_hello_SUITE.erl')
0 files changed, 0 insertions, 0 deletions