31

I'm only really concerned with RSA keys, so the exchange methods are RSA (generate a key, encrypt it, and send it over) and [EC]DHE_RSA (generate an ephemeral [EC]DH key, sign it, and use it for key agreement).

The actual operation in RSA is "Key Encipherment", and in [EC]DHE_RSA it's digital signature, but they're both forms of key agreement. So, which of "Key Encipherment", "Digital Signature", and "Key Agreement" are needed in the key usage extension for each method? I haven't been able to find this specified anywhere and it probably varies by implementation, so the answer might be a table per-implementation.

makerofthings7
  • 50,090
  • 54
  • 250
  • 536
Ben Jencks
  • 411
  • 1
  • 4
  • 3

1 Answers1

37

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).

To sum up: digitalSignature for (EC)DHE cipher suites, keyEncipherment for plain RSA cipher suites. However, some implementations will also accept keyAgreement in lieu of keyEncipherment, or nonRepudiation even if digitalSignature is not set; and some will just totally ignore the Key Usage extension (even if marked critical). For maximum interoperability, specify all four flags in the Key Usage extension.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • This is a very detailed answer, and seems plausible, but it doesn't really tell me anything I didn't know already. The question was about ambiguity in the standard, and you just cite those very same ambiguous portions of the standard. Do you have any references to documentation or code that this interpretation is correct? – Ben Jencks Dec 01 '12 at 21:36
  • 7
    Since I have written several SSL/TLS implementations and X.509 validation engines, which are deployed in the field, I can claim to be my own reference: at least my code works as I explain. – Thomas Pornin Dec 01 '12 at 21:58
  • 24
    I guess you could say you're a self signed authority (⌐■_■) – Rhythmic Fistman Jan 02 '14 at 01:18
  • 2
    With Openssl tls v1.2 if you don't use keyAgreement in KeyUsage field you are not allowed to establish ECDH but only ECDHE. I think the OP would to know things like that. – boos Oct 15 '14 at 16:17
  • Just to expand, when a ECDSA key is used then "keyAgreement" flag is needed for beeing ECDH "capable" (as opposed to ephemeral ECDHE) – eckes May 23 '17 at 14:19
  • What if the certificate contains an ECDSA key? – Melab Sep 10 '18 at 00:06
  • A word of warning, the following recommendation on always including the `keyAgreement` KU bit enables the KCI-based MitM attack (https://kcitls.org) when ECDSA certificates are used: _For maximum interoperability, specify all four flags in the Key Usage extension_. – Jaime Hablutzel Sep 05 '21 at 01:06