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.
Live near Brisbane, Australia. Software developer currently focused on iOS and Android. Avid Google Local Guide
Red Circle Blog 