Can someone explain the "Section 4.2.1.3. Key Usage" extension in RFC 5280 as it relates to TLS 1.2 RFC 5246

Question

There are references in TLS 1.2 RFC 5246 about use of certificates (server and client). I am unclear about the "key usage" extension of a certificate as it relates to TLS 1.2 and that too for data encryption only. I am not not concerned about using TLS by CAs themselves. Here are the various key usage types:

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

Clearly dataEncipherment has no role to play in TLS 1.2. Can someone provide the key extensions that do play a role in TLS 1.2 and a sentence or two explaining the specific usage of the certificate for that key extension?

There is mention of the some of these extensions in the TLS 1.2 RFC (For example in section 7.4.2). But its too brief for my knowledge level in this area.

Answer 1

Great question! I don't know if there's definitive source for this, so I'm going to make educated guesses based on the RFCs.

TL;DR: the following keyUsage bits are supported in TLS 1.2 for end-entity certs:

   digitalSignature        (0),
   keyEncipherment         (2),
   keyAgreement            (4),

Now let's go through the keyUsages one at a time:

digitalSignature

 KeyUsage ::= BIT STRING {
   digitalSignature        (0),

This one is obvious, this is the normal RSA or ECC certificate auth.

nonRepudiation

   nonRepudiation          (1), -- recent editions of X.509 have
                        -- renamed this bit to contentCommitment

This is typically used for legally-binding signatures, such as eIDAS. I can't imagine you'd put this on a TLS cert.

keyEncipherment

   keyEncipherment         (2),

This will correspond to TLS cipher suites with RSA key transport, like TLS_RSA_WITH_AES_256_GCM_SHA384.

From RFC 5246 (TLS1.2) Section-7.4.2 Server Certificate:

RSA                RSA public key; the certificate MUST allow the
RSA_PSK            key to be used for encryption (the
                     keyEncipherment bit MUST be set if the key
                     usage extension is present).
                     Note: RSA_PSK is defined in [TLSPSK].

dataEncipherment

   dataEncipherment        (3),

I don't think there's a use for this in TLS.

keyAgreement

   keyAgreement            (4),

This is used when you have a Diffie-Hellman key in a certificate. This is definitely less common than it used to be, and people prefer the ephemeral versions -- DHE and ECDHE -- but TLS 1.2 does support it with cipher suites like TLS_DH_RSA_WITH_AES_256_GCM_SHA384.

From RFC 5246 (TLS1.2) Section-7.4.2 Server Certificate:

DH_DSS             Diffie-Hellman public key; the keyAgreement bit
DH_RSA             MUST be set if the key usage extension is present.

keyCertSign & cRLSign

   keyCertSign             (5),

From RFC 5280 (X.509) section 4.2.1.3. Key Usage:

The keyCertSign bit is asserted when the subject public key is
  used for verifying signatures on public key certificates.  If the
  keyCertSign bit is asserted, then the cA bit in the basic
  constraints extension (Section 4.2.1.9) MUST also be asserted.

You don't (or at least, really really shouldn't) use a CA cert directly for TLS, so I wouldn't expect to see this key usage on a TLS cert.

Similarly:

   cRLSign                 (6),

From RFC 5280 (X.509) section 4.2.1.3. Key Usage:

The cRLSign bit is asserted when the subject public key is used
  for verifying signatures on certificate revocation lists (e.g.,
  CRLs, delta CRLs, or ARLs).

So you shouldn't see that key usage on a TLS cert.

encipherOnly & decipherOnly

   encipherOnly            (7),
   decipherOnly            (8) }

From RFC 5280 (X.509) section 4.2.1.3. Key Usage:

The meaning of the encipherOnly bit is undefined in the absence of
  the keyAgreement bit.  When the encipherOnly bit is asserted and
  the keyAgreement bit is also set, the subject public key may be
  used only for enciphering data while performing key agreement.

 The meaning of the decipherOnly bit is undefined in the absence of
  the keyAgreement bit.  When the decipherOnly bit is asserted and
  the keyAgreement bit is also set, the subject public key may be
  used only for deciphering data while performing key agreement.

These terms do not appear in RFC 5246, so I don't imagine a TLS server / client would know what to do with them, even if they were present