Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question

1 Answer 1

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.

share|improve this answer
    
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 1 '12 at 21:36
    
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 1 '12 at 21:58
    
I guess you could say you're a self signed authority (⌐■_■) –  Rhythmic Fistman Jan 2 at 1:18

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.