Monthly Archives: September 2010

Public keys that reside inside certificates are only meant to be used for certain things.  This is indicated by the Key Usage and Extended Key Usage extensions.

The first stop is documentation from OpenSSL.

Key usage supported names:

• digitalSignature
• nonRepudiation
• keyEncipherment
• dataEncipherment
• keyAgreement
• keyCertSign
• cRLSign
• encipherOnly
• decipherOnly

Extended Key Usage names:

Value                  Meaning
 -----                  -------
 serverAuth             SSL/TLS Web Server Authentication.
 clientAuth             SSL/TLS Web Client Authentication.
 codeSigning            Code signing.
 emailProtection        E-mail Protection (S/MIME).
 timeStamping           Trusted Timestamping
 msCodeInd              Microsoft Individual Code Signing (authenticode)
 msCodeCom              Microsoft Commercial Code Signing (authenticode)
 msCTLSign              Microsoft Trust List Signing
 msSGC                  Microsoft Server Gated Crypto
 msEFS                  Microsoft Encrypted File System
 nsSGC                  Netscape Server Gated Crypto

Now, moving on to a more detailed source from IETF (RFC 3280):

4.2.1.3  Key Usage

   The key usage extension defines the purpose (e.g., encipherment,
   signature, certificate signing) of the key contained in the
   certificate.  The usage restriction might be employed when a key that
   could be used for more than one operation is to be restricted.  For
   example, when an RSA key should be used only to verify signatures on
   objects other than public key certificates and CRLs, the
   digitalSignature and/or nonRepudiation bits would be asserted.
   Likewise, when an RSA key should be used only for key management, the
   keyEncipherment bit would be asserted.

   This extension MUST appear in certificates that contain public keys
   that are used to validate digital signatures on other public key
   certificates or CRLs.  When this extension appears, it SHOULD be
   marked critical.

      id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }

      KeyUsage ::= BIT STRING {
           digitalSignature        (0),
           nonRepudiation          (1),
           keyEncipherment         (2),
           dataEncipherment        (3),
           keyAgreement            (4),
           keyCertSign             (5),
           cRLSign                 (6),
           encipherOnly            (7),
           decipherOnly            (8) }

   Bits in the KeyUsage type are used as follows:

      The digitalSignature bit is asserted when the subject public key
      is used with a digital signature mechanism to support security
      services other than certificate signing (bit 5), or CRL signing
      (bit 6).  Digital signature mechanisms are often used for entity
      authentication and data origin authentication with integrity.

      The nonRepudiation bit is asserted when the subject public key is
      used to verify digital signatures used to provide a non-
      repudiation service which protects against the signing entity
      falsely denying some action, excluding certificate or CRL signing.
      In the case of later conflict, a reliable third party may
      determine the authenticity of the signed data.

      Further distinctions between the digitalSignature and
      nonRepudiation bits may be provided in specific certificate
      policies.

      The keyEncipherment bit is asserted when the subject public key is
      used for key transport.  For example, when an RSA key is to be
      used for key management, then this bit is set.

      The dataEncipherment bit is asserted when the subject public key
      is used for enciphering user data, other than cryptographic keys.

      The keyAgreement bit is asserted when the subject public key is
      used for key agreement.  For example, when a Diffie-Hellman key is
      to be used for key management, then this bit is set.

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

      The cRLSign bit is asserted when the subject public key is used
      for verifying a signature on certificate revocation list (e.g., a
      CRL, delta CRL, or an ARL).  This bit MUST be asserted in
      certificates that are used to verify signatures on CRLs.

      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.

   This profile does not restrict the combinations of bits that may be
   set in an instantiation of the keyUsage extension.  However,
   appropriate values for keyUsage extensions for particular algorithms
   are specified in [PKIXALGS].

But wait, the trail goes deeper into “PKIXALGS” which is also known as RFC3279.

If the keyUsage extension is present in an end entity certificate
   which conveys an RSA public key, any combination of the following
   values MAY be present:

      digitalSignature;
      nonRepudiation;
      keyEncipherment; and
      dataEncipherment.

   If the keyUsage extension is present in a CA or CRL issuer
   certificate which conveys an RSA public key, any combination of the
   following values MAY be present:

      digitalSignature;
      nonRepudiation;
      keyEncipherment;
      dataEncipherment;
      keyCertSign; and
      cRLSign.

   However, this specification RECOMMENDS that if keyCertSign or cRLSign
   is present, both keyEncipherment and dataEncipherment SHOULD NOT be
   present.

What does all this mean? There are specific rules about how the usage field controls how the public key is applied. Think of it as a gate to certain activities. A CA certificate has access to more functions than a non-CA (normal) certificate.

Having the usage right to sign another certificate is reserved for CAs. Based on previous posts, this means that you could have a certificate that would never have to right to sign other certificates.

I must admit that it is still a bit confusing how all these combinations fit together. Examples over time will help to clear this up. At least now the different types are clearly identified.