## 9.1 Certificate extensions

### 9.1.1 Authority key identifier

This non-critical extension identifies the public key used to verify the
signature on a certificate. It enables distinct keys used by the same CA
to be differentiated. This extension may hold an explicit key identifier
or an explicit certificate identifier. This extension is useful when a
CA uses more than one key (e.g., when the CA key is re-keyed). The use
of this extension may provide improved efficiency when attempting to
locate a specific certificate.

CAs shall be capable of generating this extension in all CA and end
entity certificates. When the extension is populated, CAs shall:

1\. include the **keyIdentifier** octet string and

2\. omit the **authorityCertIssuer** and **authorityCertSerialNumber**
fields.

The **keyIdentifier** component is used exclusively because all public
keys are assigned a unique identifier (see Section 9.1.2, Subject Key
Identifier), and the use of the explicit key identifier will always
uniquely identify a public key certificate.

There are no requirements for implementations to process this extension,
though it is recommended that relying parties be capable of recognising
the **authorityKeyIdentifier** field as the identifier of the
certification authority's key used to sign the certificate.

### 9.1.2 Subject key identifier

This non-critical extension identifies the public key being certified.
It enables distinct keys used by the same subject to be differentiated.
This extension may hold an explicit key identifier, and is useful when a
subject uses more than one key. Similar to the Authority Key Identifier
extension, this extension may provide improved efficiency when
attempting to locate a certificate.

CAs shall be capable of generating this extension in all CA and end
entity certificates.

There are no requirements for implementations to process this extension,
though it is recommended that relying parties be capable of recognising
the **subjectKeyIdentifier** field as the identifier of the public key
being certified.

### 9.1.3 Key usage

This extension indicates the purposes for which the certified public key
is used. It shall be implemented as a critical extension. The
**KeyUsage** field includes the following types:

a\) **digitalSignature**: asserted when the subject public key is used
with a digital signature mechanism to support security services other
than non-repudiation (bit 1), certificate signing (bit 5), or revocation
information signing (bit 6). Digital signature mechanisms are often used
for entity authentication and data origin authentication with integrity;

b\) **nonRepudiation**: for verifying a digital signature applied to an
object to support the delivery of the non-repudiation service (excluding
certificate or CRL signing as in f) or g) below) If present, the
**nonRepudiation** bit shall be ignored;

c\) **keyEncipherment**: for enciphering keys or other security
information, e.g. for key transport;

CAs shall set the **keyEncipherment** bit when the public key is used
for enciphering keys or other security information.

d\) **dataEncipherment**: for enciphering user data, but not keys or
other security information as in c) above;

CAs shall set the **dataEncipherment** bit when the public key is used
for enciphering user data, but not keys or other security information.

e\) **keyAgreement**: for use as a public key agreement key;

CAs shall set the **keyAgreement** bit when the public key is used as a
key agreement key.

f\) **keyCertSign**: for verifying a CA's signature on certificates;

CAs shall set the **keyCertSign** bit when the public key may be used to
sign certificates. This bit shall only be set in CA certificates.

g\) **cRLSign**: for verifying a CA's signature on CRLs.

CAs shall set the **cRLSign** bit when the public key may be used to
sign CRLs.

h\) The **encipherOnly** and **decipherOnly** key usages are intended to
provide support for key agreement schemes where separate shared secret
keys are used in each direction of communication. In such a scheme, a
user has more than one set of key pairs and bits 7 (**encipherOnly**)
and 8 (**decipherOnly**) are used to distinguish between the two types.
The originator of a message would use the recipient\'s public key
certificate with bits 4 (**keyAgreement**) and 7 (**encipherOnly**) to
create a key encryption key. The recipient would use the originator\'s
certificate with bits 4 (**keyAgreement**) and 8 (**decipherOnly**) to
create the key encryption key. Typically the originator would pass his
own certificate with bits 4 and 8 along with the message. Financial
systems are not required to implement a key management scheme where the
symmetric keys used in each direction of communication are derived from
separate public key pairs.

CAs shall include this extension in all CA and end entity certificates,
and indicate that the extension is critical by setting the criticality
flag to "true".

CAs shall set the key usage bits according to the valid key usage
combinations as illustrated in Table 8 and described in the following.

When the public key is used to validate the authenticity and integrity
of signed data (exclusive of certificates and CRLs), then
**digitalSignature** shall be set to \'1\'.

For financial systems, non-repudiation can only be conveyed through
business agreements. Therefore, the **nonRepudiation** bit is not
meaningful and shall be set to \'0\'.

When the public key is used for confidentiality protection using
reversible asymmetric algorithms, then only the **keyEncipherment** bit
shall be set to \'1\'. This is illustrated as Combination 2 in Table 8.
The public key shall not be used for any other purposes (no other bits
may be set to \'1\').

When the public key is used for confidentiality protection of data, then
only the **dataEncipherment** bit shall be set to \'1\'. This is
illustrated as Combination 3 in Table 8. The public key shall not be
used for any other purposes (no other bits may be set to \'1\').

Table 8 Valid combinations of key usage bits

+-------------------------+----+----+-----+-----+---------------------+
|                         | *  |    |     |     |                     |
|                         | *V |    |     |     |                     |
|                         | al |    |     |     |                     |
|                         | id |    |     |     |                     |
|                         | K  |    |     |     |                     |
|                         | ey |    |     |     |                     |
|                         | U  |    |     |     |                     |
|                         | sa |    |     |     |                     |
|                         | ge |    |     |     |                     |
|                         | Co |    |     |     |                     |
|                         | mb |    |     |     |                     |
|                         | in |    |     |     |                     |
|                         | at |    |     |     |                     |
|                         | io |    |     |     |                     |
|                         | ns |    |     |     |                     |
|                         | ** |    |     |     |                     |
+=========================+====+====+=====+=====+=====================+
|                         | *  |    |     |     | CA Certificates     |
|                         | *E |    |     |     |                     |
|                         | nd |    |     |     |                     |
|                         | En |    |     |     |                     |
|                         | ti |    |     |     |                     |
|                         | ty |    |     |     |                     |
|                         | Ce |    |     |     |                     |
|                         | rt |    |     |     |                     |
|                         | if |    |     |     |                     |
|                         | ic |    |     |     |                     |
|                         | at |    |     |     |                     |
|                         | es |    |     |     |                     |
|                         | ** |    |     |     |                     |
+-------------------------+----+----+-----+-----+---------------------+
| Key Usages              | 1  | 2  | 3   | 4   | 5                   |
+-------------------------+----+----+-----+-----+---------------------+
| Digital Signature       | •  | x  | x   | x   | A                   |
+-------------------------+----+----+-----+-----+---------------------+
| Key Encipherment        | x  | •  | x   | x   | x                   |
+-------------------------+----+----+-----+-----+---------------------+
| Non Repudiation         | \# | \# | \#  | \#  | \#                  |
+-------------------------+----+----+-----+-----+---------------------+
| Data Encipherment       | x  | x  | •   | x   | x                   |
+-------------------------+----+----+-----+-----+---------------------+
| Key Agreement           | x  | x  | x   | •   | x                   |
+-------------------------+----+----+-----+-----+---------------------+
| Key CertSign            | x  | x  | x   | x   | A                   |
+-------------------------+----+----+-----+-----+---------------------+
| CRL Sign                | x  | x  | x   | x   | A                   |
+-------------------------+----+----+-----+-----+---------------------+
| Encipher Only           | x  | x  | x   | x   | x                   |
+-------------------------+----+----+-----+-----+---------------------+
| Decipher Only           | x  | x  | x   | x   | x                   |
+-------------------------+----+----+-----+-----+---------------------+
| • bit is set to \'1\'   |    |    |     |     |                     |
|                         |    |    |     |     |                     |
| A [A]{.underline}ny     |    |    |     |     |                     |
| combination of these    |    |    |     |     |                     |
| key usages is valid.    |    |    |     |     |                     |
|                         |    |    |     |     |                     |
| x not allowed           |    |    |     |     |                     |
|                         |    |    |     |     |                     |
| \# bit shall be set to  |    |    |     |     |                     |
| \'0\'; ignore in        |    |    |     |     |                     |
| processing              |    |    |     |     |                     |
+-------------------------+----+----+-----+-----+---------------------+

When the public key is used for confidentiality protection using
irreversible asymmetric algorithms, then only the **keyAgreement** bit
shall be set to \'1\'. This is illustrated in Combination 4 in Table 8.
The public key shall not be used for any other purposes (no other bits
may be set to \'1\').

When the public key is used for validating the authenticity and
integrity of signed data, certificates, and CRLs, then the
**digitalSignature**, **keyCertSign**, and **cRLSign** bits shall be set
to \'1\', respectively. No other bits shall be set to \'1\'. This is
illustrated in Combination 5 in Table 8. A subset of this combination is
also valid. The decision to combine these functions in a single public
key shall be based on business risk. This combination shall only appear
in CA certificates.

When the public key is used to provide confidentiality using a key
agreement mechanism, e.g., KEA, Diffie-Hellman, or a variant thereof,
the **keyAgreement** bit is set to \"1\"; if the key is to be used to
form a pairwise key to decrypt data, then the certificate processing
entity shall ensure that the **encipherOnly** bit is set to "0"; if the
key is to be used to form a pairwise key to encrypt data, then the
certificate processing entity shall ensure that the **decipherOnly** bit
is set to "0";

Relying parties shall interpret the **keyUsage** bits as described in
this Standard and reject any combination of key usages that is not a
valid combination as identified in Table 8 and described above.