RFC 2459
Internet X.509 Public Key Infrastructure Certificate and CRL Profile
4.2 Standard Certificate Extensions The extensions defined for X.509 v3 certificates provide methods for associating additional attributes with users or public keys and for managing the certification hierarchy. The X.509 v3 certificate format also allows communities to define private extensions to carry information unique to those communities. Each extension in a certificate may be designated as critical or non-critical. A certificate using system MUST reject the certificate if it encounters a critical extension it does not recognize; however, a non-critical extension may be ignored if it is not recognized. The following sections present recommended extensions used within Internet certificates and standard locations for information. Communities may elect to use additional extensions; however, caution should be exercised in adopting any critical extensions in certificates which might prevent use in a general context. Each extension includes an OID and an ASN.1 structure. When an extension appears in a certificate, the OID appears as the field extnID and the corresponding ASN.1 encoded structure is the value of the octet string extnValue. Only one instance of a particular extension may appear in a particular certificate. For example, a certificate may contain only one authority key identifier extension (see sec. 4.2.1.1). An extension includes the boolean critical, with a default value of FALSE. The text for each extension specifies the acceptable values for the critical field.
Conforming CAs MUST support key identifiers (see sec. 4.2.1.1 and 4.2.1.2), basic constraints (see sec. 4.2.1.10), key usage (see sec. 4.2.1.3), and certificate policies (see sec. 4.2.1.5) extensions. If the CA issues certificates with an empty sequence for the subject field, the CA MUST support the subject alternative name extension (see sec. 4.2.1.7). Support for the remaining extensions is OPTIONAL. Conforming CAs may support extensions that are not identified within this specification; certificate issuers are cautioned that marking such extensions as critical may inhibit interoperability. At a minimum, applications conforming to this profile MUST recognize the extensions which must or may be critical in this specification. These extensions are: key usage (see sec. 4.2.1.3), certificate policies (see sec. 4.2.1.5), the subject alternative name (see sec. 4.2.1.7), basic constraints (see sec. 4.2.1.10), name constraints (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), and extended key usage (see sec. 4.2.1.13). In addition, this profile RECOMMENDS application support for the authority and subject key identifier (see sec. 4.2.1.1 and 4.2.1.2) extensions. 4.2.1 Standard Extensions This section identifies standard certificate extensions defined in [X.509] for use in the Internet PKI. Each extension is associated with an OID defined in [X.509]. These OIDs are members of the id-ce arc, which is defined by the following: id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} 4.2.1.1 Authority Key Identifier The authority key identifier extension provides a means of identifying the public key corresponding to the private key used to sign a certificate. This extension is used where an issuer has multiple signing keys (either due to multiple concurrent key pairs or due to changeover). The identification may be based on either the key identifier (the subject key identifier in the issuer's certificate) or on the issuer name and serial number. The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate chain building. There is one exception; where a CA distributes its public key in the form of a "self-signed" certificate, the authority key identifier may be omitted. In this case, the subject and authority key identifiers would be identical.
The value of the keyIdentifier field SHOULD be derived from the
public key used to verify the certificate's signature or a method
that generates unique values. Two common methods for generating key
identifiers from the public key are described in (sec. 4.2.1.2). One
common method for generating unique values isdescribed in (sec.
4.2.1.2). Where a key identifier has not been previously
established, this specification recommends use of one of these
methods for generating keyIdentifiers.
This profile recommends support for the key identifier method by all
certificate users.
This extension MUST NOT be marked critical.
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
authorityCertIssuer [1] GeneralNames OPTIONAL,
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
KeyIdentifier ::= OCTET STRING
4.2.1.2 Subject Key Identifier
The subject key identifier extension provides a means of identifying
certificates that contain a particular public key.
To facilitate chain building, this extension MUST appear in all con-
forming CA certificates, that is, all certificates including the
basic constraints extension (see sec. 4.2.1.10) where the value of cA
is TRUE. The value of the subject key identifier MUST be the value
placed in the key identifier field of the Authority Key Identifier
extension (see sec. 4.2.1.1) of certificates issued by the subject of
this certificate.
For CA certificates, subject key identifiers SHOULD be derived from
the public key or a method that generates unique values. Two common
methods for generating key identifiers from the public key are:
(1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
value of the BIT STRING subjectPublicKey (excluding the tag,
length, and number of unused bits).
(2) The keyIdentifier is composed of a four bit type field with
the value 0100 followed by the least significant 60 bits of the
SHA-1 hash of the value of the BIT STRING subjectPublicKey.
One common method for generating unique values is a monotomically
increasing sequence of integers.
For end entity certificates, the subject key identifier extension
provides a means for identifying certificates containing the
particular public key used in an application. Where an end entity has
obtained multiple certificates, especially from multiple CAs, the
subject key identifier provides a means to quickly identify the set
of certificates containing a particular public key. To assist
applications in identificiation the appropriate end entity
certificate, this extension SHOULD be included in all end entity
certificates.
For end entity certificates, subject key identifiers SHOULD be
derived from the public key. Two common methods for generating key
identifiers from the public key are identifed above.
Where a key identifier has not been previously established, this
specification recommends use of one of these methods for generating
keyIdentifiers.
This extension MUST NOT be marked critical.
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
SubjectKeyIdentifier ::= KeyIdentifier
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 for signing, 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. When used, this extension
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 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.
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.
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 shall asserted.
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 shall asserted.
The keyCertSign bit is asserted when the subject public key is
used for verifying a signature on certificates. This bit may only
be asserted in CA certificates.
The cRLSign bit is asserted when the subject public key is used
for verifying a signature on revocation information (e.g., a CRL).
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 section 7.3. 4.2.1.4 Private Key Usage Period This profile recommends against the use of this extension. CAs conforming to this profile MUST NOT generate certificates with critical private key usage period extensions. The private key usage period extension allows the certificate issuer to specify a different validity period for the private key than the certificate. This extension is intended for use with digital signature keys. This extension consists of two optional components, notBefore and notAfter. The private key associated with the certificate should not be used to sign objects before or after the times specified by the two components, respectively. CAs conforming to this profile MUST NOT generate certificates with private key usage period extensions unless at least one of the two components is present. Where used, notBefore and notAfter are represented as GeneralizedTime and MUST be specified and interpreted as defined in section 4.1.2.5.2. id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } PrivateKeyUsagePeriod ::= SEQUENCE { notBefore [0] GeneralizedTime OPTIONAL, notAfter [1] GeneralizedTime OPTIONAL } 4.2.1.5 Certificate Policies The certificate policies extension contains a sequence of one or more policy information terms, each of which consists of an object identifier (OID) and optional qualifiers. These policy information terms indicate the policy under which the certificate has been issued and the purposes for which the certificate may be used. Optional qualifiers, which may be present, are not expected to change the definition of the policy. Applications with specific policy requirements are expected to have a list of those policies which they will accept and to compare the policy OIDs in the certificate to that list. If this extension is critical, the path validation software MUST be able to interpret this extension (including the optional qualifier), or MUST reject the certificate.
To promote interoperability, this profile RECOMMENDS that policy
information terms consist of only an OID. Where an OID alone is
insufficient, this profile strongly recommends that use of qualifiers
be limited to those identified in this section.
This specification defines two policy qualifier types for use by
certificate policy writers and certificate issuers. The qualifier
types are the CPS Pointer and User Notice qualifiers.
The CPS Pointer qualifier contains a pointer to a Certification
Practice Statement (CPS) published by the CA. The pointer is in the
form of a URI.
User notice is intended for display to a relying party when a
certificate is used. The application software SHOULD display all
user notices in all certificates of the certification path used,
except that if a notice is duplicated only one copy need be
displayed. To prevent such duplication, this qualifier SHOULD only
be present in end-entity certificates and CA certificates issued to
other organizations.
The user notice has two optional fields: the noticeRef field and the
explicitText field.
The noticeRef field, if used, names an organization and
identifies, by number, a particular textual statement prepared by
that organization. For example, it might identify the
organization "CertsRUs" and notice number 1. In a typical
implementation, the application software will have a notice file
containing the current set of notices for CertsRUs; the
application will extract the notice text from the file and display
it. Messages may be multilingual, allowing the software to select
the particular language message for its own environment.
An explicitText field includes the textual statement directly in
the certificate. The explicitText field is a string with a
maximum size of 200 characters.
If both the noticeRef and explicitText options are included in the
one qualifier and if the application software can locate the notice
text indicated by the noticeRef option then that text should be
displayed; otherwise, the explicitText string should be displayed.
id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
PolicyInformation ::= SEQUENCE {
policyIdentifier CertPolicyId,
policyQualifiers SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL }
CertPolicyId ::= OBJECT IDENTIFIER
PolicyQualifierInfo ::= SEQUENCE {
policyQualifierId PolicyQualifierId,
qualifier ANY DEFINED BY policyQualifierId }
-- policyQualifierIds for Internet policy qualifiers
id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
PolicyQualifierId ::=
OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
Qualifier ::= CHOICE {
cPSuri CPSuri,
userNotice UserNotice }
CPSuri ::= IA5String
UserNotice ::= SEQUENCE {
noticeRef NoticeReference OPTIONAL,
explicitText DisplayText OPTIONAL}
NoticeReference ::= SEQUENCE {
organization DisplayText,
noticeNumbers SEQUENCE OF INTEGER }
DisplayText ::= CHOICE {
visibleString VisibleString (SIZE (1..200)),
bmpString BMPString (SIZE (1..200)),
utf8String UTF8String (SIZE (1..200)) }
4.2.1.6 Policy Mappings
This extension is used in CA certificates. It lists one or more
pairs of OIDs; each pair includes an issuerDomainPolicy and a
subjectDomainPolicy. The pairing indicates the issuing CA considers
its issuerDomainPolicy equivalent to the subject CA's
subjectDomainPolicy.
The issuing CA's users may accept an issuerDomainPolicy for certain
applications. The policy mapping tells the issuing CA's users which
policies associated with the subject CA are comparable to the policy
they accept.
This extension may be supported by CAs and/or applications, and it
MUST be non-critical.
id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }
PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
issuerDomainPolicy CertPolicyId,
subjectDomainPolicy CertPolicyId }
4.2.1.7 Subject Alternative Name
The subject alternative names extension allows additional identities
to be bound to the subject of the certificate. Defined options
include an Internet electronic mail address, a DNS name, an IP
address, and a uniform resource identifier (URI). Other options
exist, including completely local definitions. Multiple name forms,
and multiple instances of each name form, may be included. Whenever
such identities are to be bound into a certificate, the subject
alternative name (or issuer alternative name) extension MUST be used.
Because the subject alternative name is considered to be
definitiviely bound to the public key, all parts of the subject
alternative name MUST be verified by the CA.
Further, if the only subject identity included in the certificate is
an alternative name form (e.g., an electronic mail address), then the
subject distinguished name MUST be empty (an empty sequence), and the
subjectAltName extension MUST be present. If the subject field
contains an empty sequence, the subjectAltName extension MUST be
marked critical.
When the subjectAltName extension contains an Internet mail address,
the address MUST be included as an rfc822Name. The format of an
rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An
addr-spec has the form "local-part@domain". Note that an addr-spec
has no phrase (such as a common name) before it, has no comment (text
surrounded in parentheses) after it, and is not surrounded by "<" and
">". Note that while upper and lower case letters are allowed in an
RFC 822 addr-spec, no significance is attached to the case.
When the subjectAltName extension contains a iPAddress, the address
MUST be stored in the octet string in "network byte order," as
specified in RFC 791 [RFC 791]. The least significant bit (LSB) of
each octet is the LSB of the corresponding byte in the network address. For IP Version 4, as specified in RFC 791, the octet string MUST contain exactly four octets. For IP Version 6, as specified in RFC 1883, the octet string MUST contain exactly sixteen octets [RFC 1883]. When the subjectAltName extension contains a domain name service label, the domain name MUST be stored in the dNSName (an IA5String). The name MUST be in the "preferred name syntax," as specified by RFC 1034 [RFC 1034]. Note that while upper and lower case letters are allowed in domain names, no signifigance is attached to the case. In addition, while the string " " is a legal domain name, subjectAltName extensions with a dNSName " " are not permitted. Finally, the use of the DNS representation for Internet mail addresses (wpolk.nist.gov instead of wpolk@nist.gov) is not permitted; such identities are to be encoded as rfc822Name. When the subjectAltName extension contains a URI, the name MUST be stored in the uniformResourceIdentifier (an IA5String). The name MUST be a non-relative URL, and MUST follow the URL syntax and encoding rules specified in [RFC 1738]. The name must include both a scheme (e.g., "http" or "ftp") and a scheme-specific-part. The scheme- specific-part must include a fully qualified domain name or IP address as the host. As specified in [RFC 1738], the scheme name is not case-sensitive (e.g., "http" is equivalent to "HTTP"). The host part is also not case-sensitive, but other components of the scheme-specific-part may be case-sensitive. When comparing URIs, conforming implementations MUST compare the scheme and host without regard to case, but assume the remainder of the scheme-specific-part is case sensitive. Subject alternative names may be constrained in the same manner as subject distinguished names using the name constraints extension as described in section 4.2.1.11. If the subjectAltName extension is present, the sequence MUST contain at least one entry. Unlike the subject field, conforming CAs MUST NOT issue certificates with subjectAltNames containing empty GeneralName fields. For example, an rfc822Name is represented as an IA5String. While an empty string is a valid IA5String, such an rfc822Name is not permitted by this profile. The behavior of clients that encounter such a certificate when processing a certificication path is not defined by this profile.
Finally, the semantics of subject alternative names that include
wildcard characters (e.g., as a placeholder for a set of names) are
not addressed by this specification. Applications with specific
requirements may use such names but shall define the semantics.
id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
SubjectAltName ::= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralName ::= CHOICE {
otherName [0] OtherName,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER}
OtherName ::= SEQUENCE {
type-id OBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id }
EDIPartyName ::= SEQUENCE {
nameAssigner [0] DirectoryString OPTIONAL,
partyName [1] DirectoryString }
4.2.1.8 Issuer Alternative Names
As with 4.2.1.7, this extension is used to associate Internet style
identities with the certificate issuer. Issuer alternative names MUST
be encoded as in 4.2.1.7.
Where present, this extension SHOULD NOT be marked critical.
id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }
IssuerAltName ::= GeneralNames
4.2.1.9 Subject Directory Attributes
The subject directory attributes extension is not recommended as an
essential part of this profile, but it may be used in local
environments. This extension MUST be non-critical.
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }
SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
4.2.1.10 Basic Constraints
The basic constraints extension identifies whether the subject of the
certificate is a CA and how deep a certification path may exist
through that CA.
The pathLenConstraint field is meaningful only if cA is set to TRUE.
In this case, it gives the maximum number of CA certificates that may
follow this certificate in a certification path. A value of zero
indicates that only an end-entity certificate may follow in the path.
Where it appears, the pathLenConstraint field MUST be greater than or
equal to zero. Where pathLenConstraint does not appear, there is no
limit to the allowed length of the certification path.
This extension MUST appear as a critical extension in all CA
certificates. This extension SHOULD NOT appear in end entity
certificates.
id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }
BasicConstraints ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
4.2.1.11 Name Constraints
The name constraints extension, which MUST be used only in a CA
certificate, indicates a name space within which all subject names in
subsequent certificates in a certification path shall be located.
Restrictions may apply to the subject distinguished name or subject
alternative names. Restrictions apply only when the specified name
form is present. If no name of the type is in the certificate, the
certificate is acceptable.
Restrictions are defined in terms of permitted or excluded name
subtrees. Any name matching a restriction in the excludedSubtrees
field is invalid regardless of information appearing in the
permittedSubtrees. This extension MUST be critical.
Within this profile, the minimum and maximum fields are not used with
any name forms, thus minimum is always zero, and maximum is always
absent.
For URIs, the constraint applies to the host part of the name. The constraint may specify a host or a domain. Examples would be "foo.bar.com"; and ".xyz.com". When the the constraint begins with a period, it may be expanded with one or more subdomains. That is, the constraint ".xyz.com" is satisfied by both abc.xyz.com and abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied by "xyz.com". When the constraint does not begin with a period, it specifies a host. A name constraint for Internat mail addresses may specify a particular mailbox, all addresses at a particular host, or all mailboxes in a domain. To indicate a particular mailbox, the constraint is the complete mail address. For example, "root@xyz.com" indicates the root mailbox on the host "xyz.com". To indicate all Internet mail addresses on a particular host, the constraint is specified as the host name. For example, the constraint "xyz.com" is satisfied by any mail address at the host "xyz.com". To specify any address within a domain, the constraint is specified with a leading period (as with URIs). For example, ".xyz.com" indicates all the Internet mail addresses in the domain "xyz.com", but Internet mail addresses on the host "xyz.com". DNS name restrictions are expressed as foo.bar.com. Any subdomain satisfies the name constraint. For example, www.foo.bar.com would satisfy the constraint but bigfoo.bar.com would not. Legacy implementations exist where an RFC 822 name is embedded in the subject distinguished name in an attribute of type EmailAddress (see sec. 4.1.2.6). When rfc822 names are constrained, but the certificate does not include a subject alternative name, the rfc822 name constraint MUST be applied to the attribute of type EmailAddress in the subject distinguished name. The ASN.1 syntax for EmailAddress and the corresponding OID are supplied in Appendix A and B. Restrictions of the form directoryName MUST be applied to the subject field in the certificate and to the subjectAltName extensions of type directoryName. Restrictions of the form x400Address MUST be applied to subjectAltName extensions of type x400Address. When applying restrictions of the form directoryName, an implementation MUST compare DN attributes. At a minimum, implementations MUST perform the DN comparison rules specified in Section 4.1.2.4. CAs issuing certificates with a restriction of the form directoryName SHOULD NOT rely on implementation of the full ISO DN name comparison algorithm. This implies name restrictions shall be stated identically to the encoding used in the subject field or subjectAltName extension.
The syntax of iPAddress MUST be as described in section 4.2.1.7 with the following additions specifically for Name Constraints. For IPv4 addresses, the ipAddress field of generalName MUST contain eight (8) octets, encoded in the style of RFC 1519 (CIDR) to represent an address range.[RFC 1519] For IPv6 addresses, the ipAddress field MUST contain 32 octets similarly encoded. For example, a name constraint for "class C" subnet 10.9.8.0 shall be represented as the octets 0A 09 08 00 FF FF FF 00, representing the CIDR notation 10.9.8.0/255.255.255.0. The syntax and semantics for name constraints for otherName, ediPartyName, and registeredID are not defined by this specification. id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } NameConstraints ::= SEQUENCE { permittedSubtrees [0] GeneralSubtrees OPTIONAL, excludedSubtrees [1] GeneralSubtrees OPTIONAL } GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree GeneralSubtree ::= SEQUENCE { base GeneralName, minimum [0] BaseDistance DEFAULT 0, maximum [1] BaseDistance OPTIONAL } BaseDistance ::= INTEGER (0..MAX) 4.2.1.12 Policy Constraints The policy constraints extension can be used in certificates issued to CAs. The policy constraints extension constrains path validation in two ways. It can be used to prohibit policy mapping or require that each certificate in a path contain an acceptable policy identifier. If the inhibitPolicyMapping field is present, the value indicates the number of additional certificates that may appear in the path before policy mapping is no longer permitted. For example, a value of one indicates that policy mapping may be processed in certificates issued by the subject of this certificate, but not in additional certificates in the path. If the requireExplicitPolicy field is present, subsequent certificates shall include an acceptable policy identifier. The value of requireExplicitPolicy indicates the number of additional certificates that may appear in the path before an explicit policy is required. An acceptable policy identifier is the identifier of a
policy required by the user of the certification path or the
identifier of a policy which has been declared equivalent through
policy mapping.
Conforming CAs MUST NOT issue certificates where policy constraints
is a null sequence. That is, at least one of the inhibitPolicyMapping
field or the requireExplicitPolicy field MUST be present. The
behavior of clients that encounter a null policy constraints field is
not addressed in this profile.
This extension may be critical or non-critical.
id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX)
4.2.1.13 Extended key usage field
This field indicates one or more purposes for which the certified
public key may be used, in addition to or in place of the basic
purposes indicated in the key usage extension field. This field is
defined as follows:
id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37}
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER
Key purposes may be defined by any organization with a need. Object
identifiers used to identify key purposes shall be assigned in
accordance with IANA or ITU-T Rec. X.660 | ISO/IEC/ITU 9834-1.
This extension may, at the option of the certificate issuer, be
either critical or non-critical.
If the extension is flagged critical, then the certificate MUST be
used only for one of the purposes indicated.
If the extension is flagged non-critical, then it indicates the
intended purpose or purposes of the key, and may be used in finding
the correct key/certificate of an entity that has multiple
keys/certificates. It is an advisory field and does not imply that
usage of the key is restricted by the certification authority to the
purpose indicated. Certificate using applications may nevertheless
require that a particular purpose be indicated in order for the
certificate to be acceptable to that application.
If a certificate contains both a critical key usage field and a
critical extended key usage field, then both fields MUST be processed
independently and the certificate MUST only be used for a purpose
consistent with both fields. If there is no purpose consistent with
both fields, then the certificate MUST NOT be used for any purpose.
The following key usage purposes are defined by this profile:
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
id-kp-serverAuth OBJECT IDENTIFIER ::= {id-kp 1}
-- TLS Web server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement
--
id-kp-clientAuth OBJECT IDENTIFIER ::= {id-kp 2}
-- TLS Web client authentication
-- Key usage bits that may be consistent: digitalSignature and/or
-- keyAgreement
--
id-kp-codeSigning OBJECT IDENTIFIER ::= {id-kp 3}
-- Signing of downloadable executable code
-- Key usage bits that may be consistent: digitalSignature
--
id-kp-emailProtection OBJECT IDENTIFIER ::= {id-kp 4}
-- E-mail protection
-- Key usage bits that may be consistent: digitalSignature,
-- nonRepudiation, and/or (keyEncipherment
-- or keyAgreement)
--
id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
-- Binding the hash of an object to a time from an agreed-upon time
-- source. Key usage bits that may be consistent: digitalSignature,
-- nonRepudiation
4.2.1.14 CRL Distribution Points
The CRL distribution points extension identifies how CRL information
is obtained. The extension SHOULD be non-critical, but this profile
recommends support for this extension by CAs and applications.
Further discussion of CRL management is contained in section 5.
If the cRLDistributionPoints extension contains a
DistributionPointName of type URI, the following semantics MUST be
assumed: the URI is a pointer to the current CRL for the associated
reasons and will be issued by the associated cRLIssuer. The expected
values for the URI are those defined in 4.2.1.7. Processing rules for
other values are not defined by this specification. If the
distributionPoint omits reasons, the CRL MUST include revocations for
all reasons. If the distributionPoint omits cRLIssuer, the CRL MUST
be issued by the CA that issued the certificate.
id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 }
cRLDistributionPoints ::= {
CRLDistPointsSyntax }
CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
DistributionPoint ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL,
reasons [1] ReasonFlags OPTIONAL,
cRLIssuer [2] GeneralNames OPTIONAL }
DistributionPointName ::= CHOICE {
fullName [0] GeneralNames,
nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
ReasonFlags ::= BIT STRING {
unused (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6) }
4.2.2 Private Internet Extensions
This section defines one new extension for use in the Internet Public
Key Infrastructure. This extension may be used to direct
applications to identify an on-line validation service supporting the
issuing CA. As the information may be available in multiple forms,
each extension is a sequence of IA5String values, each of which
represents a URI. The URI implicitly specifies the location and
format of the information and the method for obtaining the
information.
An object identifier is defined for the private extension. The
object identifier associated with the private extension is defined
under the arc id-pe within the id-pkix name space. Any future
extensions defined for the Internet PKI will also be defined under
the arc id-pe.
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
4.2.2.1 Authority Information Access
The authority information access extension indicates how to access CA
information and services for the issuer of the certificate in which
the extension appears. Information and services may include on-line
validation services and CA policy data. (The location of CRLs is not
specified in this extension; that information is provided by the
cRLDistributionPoints extension.) This extension may be included in
subject or CA certificates, and it MUST be non-critical.
id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
AuthorityInfoAccessSyntax ::=
SEQUENCE SIZE (1..MAX) OF AccessDescription
AccessDescription ::= SEQUENCE {
accessMethod OBJECT IDENTIFIER,
accessLocation GeneralName }
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
Each entry in the sequence AuthorityInfoAccessSyntax describes the
format and location of additional information about the CA who issued
the certificate in which this extension appears. The type and format
of the information is specified by the accessMethod field; the
accessLocation field specifies the location of the information. The
retrieval mechanism may be implied by the accessMethod or specified
by accessLocation.
This profile defines one OID for accessMethod. The id-ad-caIssuers
OID is used when the additional information lists CAs that have
issued certificates superior to the CA that issued the certificate
containing this extension. The referenced CA Issuers description is intended to aid certificate users in the selection of a certification path that terminates at a point trusted by the certificate user. When id-ad-caIssuers appears as accessInfoType, the accessLocation field describes the referenced description server and the access protocol to obtain the referenced description. The accessLocation field is defined as a GeneralName, which can take several forms. Where the information is available via http, ftp, or ldap, accessLocation MUST be a uniformResourceIdentifier. Where the information is available via the directory access protocol (dap), accessLocation MUST be a directoryName. When the information is available via electronic mail, accessLocation MUST be an rfc822Name. The semantics of other name forms of accessLocation (when accessMethod is id-ad-caIssuers) are not defined by this specification. Additional access descriptors may be defined in other PKIX specifications. 5 CRL and CRL Extensions Profile As described above, one goal of this X.509 v2 CRL profile is to foster the creation of an interoperable and reusable Internet PKI. To achieve this goal, guidelines for the use of extensions are specified, and some assumptions are made about the nature of information included in the CRL. CRLs may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and an even broader spectrum of operational and assurance requirements. This profile establishes a common baseline for generic applications requiring broad interoperability. The profile defines a baseline set of information that can be expected in every CRL. Also, the profile defines common locations within the CRL for frequently used attributes as well as common representations for these attributes. This profile does not define any private Internet CRL extensions or CRL entry extensions. Environments with additional or special purpose requirements may build on this profile or may replace it. Conforming CAs are not required to issue CRLs if other revocation or certificate status mechanisms are provided. Conforming CAs that issue CRLs MUST issue version 2 CRLs, and CAs MUST include the date by which the next CRL will be issued in the nextUpdate field (see
sec. 5.1.2.5), the CRL number extension (see sec. 5.2.3) and the authority key identifier extension (see sec. 5.2.1). Conforming applications are required to process version 1 and 2 CRLs. 5.1 CRL Fields The X.509 v2 CRL syntax is as follows. For signature calculation, the data that is to be signed is ASN.1 DER encoded. ASN.1 DER encoding is a tag, length, value encoding system for each element. CertificateList ::= SEQUENCE { tbsCertList TBSCertList, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } TBSCertList ::= SEQUENCE { version Version OPTIONAL, -- if present, shall be v2 signature AlgorithmIdentifier, issuer Name, thisUpdate Time, nextUpdate Time OPTIONAL, revokedCertificates SEQUENCE OF SEQUENCE { userCertificate CertificateSerialNumber, revocationDate Time, crlEntryExtensions Extensions OPTIONAL -- if present, shall be v2 } OPTIONAL, crlExtensions [0] EXPLICIT Extensions OPTIONAL -- if present, shall be v2 } -- Version, Time, CertificateSerialNumber, and Extensions -- are all defined in the ASN.1 in section 4.1 -- AlgorithmIdentifier is defined in section 4.1.1.2 The following items describe the use of the X.509 v2 CRL in the Internet PKI. 5.1.1 CertificateList Fields The CertificateList is a SEQUENCE of three required fields. The fields are described in detail in the following subsections.
5.1.1.1 tbsCertList The first field in the sequence is the tbsCertList. This field is itself a sequence containing the name of the issuer, issue date, issue date of the next list, the list of revoked certificates, and optional CRL extensions. Further, each entry on the revoked certificate list is defined by a sequence of user certificate serial number, revocation date, and optional CRL entry extensions. 5.1.1.2 signatureAlgorithm The signatureAlgorithm field contains the algorithm identifier for the algorithm used by the CA to sign the CertificateList. The field is of type AlgorithmIdentifier, which is defined in section 4.1.1.2. Section 7.2 lists the supported algorithms for this specification. Conforming CAs MUST use the algorithm identifiers presented in section 7.2 when signing with a supported signature algorithm. This field MUST contain the same algorithm identifier as the signature field in the sequence tbsCertList (see sec. 5.1.2.2). 5.1.1.3 signatureValue The signatureValue field contains a digital signature computed upon the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList is used as the input to the signature function. This signature value is then ASN.1 encoded as a BIT STRING and included in the CRL's signatureValue field. The details of this process are specified for each of the supported algorithms in section 7.2. 5.1.2 Certificate List "To Be Signed" The certificate list to be signed, or TBSCertList, is a SEQUENCE of required and optional fields. The required fields identify the CRL issuer, the algorithm used to sign the CRL, the date and time the CRL was issued, and the date and time by which the CA will issue the next CRL. Optional fields include lists of revoked certificates and CRL extensions. The revoked certificate list is optional to support the case where a CA has not revoked any unexpired certificates that it has issued. The profile requires conforming CAs to use the CRL extension cRLNumber in all CRLs issued.
5.1.2.1 Version This optional field describes the version of the encoded CRL. When extensions are used, as required by this profile, this field MUST be present and MUST specify version 2 (the integer value is 1). 5.1.2.2 Signature This field contains the algorithm identifier for the algorithm used to sign the CRL. Section 7.2 lists OIDs for the most popular signature algorithms used in the Internet PKI. This field MUST contain the same algorithm identifier as the signatureAlgorithm field in the sequence CertificateList (see section 5.1.1.2). 5.1.2.3 Issuer Name The issuer name identifies the entity who has signed and issued the CRL. The issuer identity is carried in the issuer name field. Alternative name forms may also appear in the issuerAltName extension (see sec. 5.2.2). The issuer name field MUST contain an X.500 distinguished name (DN). The issuer name field is defined as the X.501 type Name, and MUST follow the encoding rules for the issuer name field in the certificate (see sec. 4.1.2.4). 5.1.2.4 This Update This field indicates the issue date of this CRL. ThisUpdate may be encoded as UTCTime or GeneralizedTime. CAs conforming to this profile that issue CRLs MUST encode thisUpdate as UTCTime for dates through the year 2049. CAs conforming to this profile that issue CRLs MUST encode thisUpdate as GeneralizedTime for dates in the year 2050 or later. Where encoded as UTCTime, thisUpdate MUST be specified and interpreted as defined in section 4.1.2.5.1. Where encoded as GeneralizedTime, thisUpdate MUST be specified and interpreted as defined in section 4.1.2.5.2. 5.1.2.5 Next Update This field indicates the date by which the next CRL will be issued. The next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date. CAs SHOULD issue CRLs with a nextUpdate time equal to or later than all previous CRLs. nextUpdate may be encoded as UTCTime or GeneralizedTime.
This profile requires inclusion of nextUpdate in all CRLs issued by conforming CAs. Note that the ASN.1 syntax of TBSCertList describes this field as OPTIONAL, which is consistent with the ASN.1 structure defined in [X.509]. The behavior of clients processing CRLs which omit nextUpdate is not specified by this profile. CAs conforming to this profile that issue CRLs MUST encode nextUpdate as UTCTime for dates through the year 2049. CAs conforming to this profile that issue CRLs MUST encode nextUpdate as GeneralizedTime for dates in the year 2050 or later. Where encoded as UTCTime, nextUpdate MUST be specified and interpreted as defined in section 4.1.2.5.1. Where encoded as GeneralizedTime, nextUpdate MUST be specified and interpreted as defined in section 4.1.2.5.2. 5.1.2.6 Revoked Certificates Revoked certificates are listed. The revoked certificates are named by their serial numbers. Certificates revoked by the CA are uniquely identified by the certificate serial number. The date on which the revocation occurred is specified. The time for revocationDate MUST be expressed as described in section 5.1.2.4. Additional information may be supplied in CRL entry extensions; CRL entry extensions are discussed in section 5.3. 5.1.2.7 Extensions This field may only appear if the version is 2 (see sec. 5.1.2.1). If present, this field is a SEQUENCE of one or more CRL extensions. CRL extensions are discussed in section 5.2. 5.2 CRL Extensions The extensions defined by ANSI X9 and ISO/IEC/ITU for X.509 v2 CRLs [X.509] [X9.55] provide methods for associating additional attributes with CRLs. The X.509 v2 CRL format also allows communities to define private extensions to carry information unique to those communities. Each extension in a CRL may be designated as critical or non- critical. A CRL validation MUST fail if it encounters a critical extension which it does not know how to process. However, an unrecognized non-critical extension may be ignored. The following subsections present those extensions used within Internet CRLs. Communities may elect to include extensions in CRLs which are not defined in this specification. However, caution should be exercised in adopting any critical extensions in CRLs which might be used in a general context.
Conforming CAs that issue CRLs are required to include the authority key identifier (see sec. 5.2.1) and the CRL number (see sec. 5.2.3) extensions in all CRLs issued. 5.2.1 Authority Key Identifier The authority key identifier extension provides a means of identifying the public key corresponding to the private key used to sign a CRL. The identification can be based on either the key identifier (the subject key identifier in the CRL signer's certificate) or on the issuer name and serial number. This extension is especially useful where an issuer has more than one signing key, either due to multiple concurrent key pairs or due to changeover. Conforming CAs MUST use the key identifier method, and MUST include this extension in all CRLs issued. The syntax for this CRL extension is defined in section 4.2.1.1. 5.2.2 Issuer Alternative Name The issuer alternative names extension allows additional identities to be associated with the issuer of the CRL. Defined options include an rfc822 name (electronic mail address), a DNS name, an IP address, and a URI. Multiple instances of a name and multiple name forms may be included. Whenever such identities are used, the issuer alternative name extension MUST be used. The issuerAltName extension SHOULD NOT be marked critical. The OID and syntax for this CRL extension are defined in section 4.2.1.8. 5.2.3 CRL Number The CRL number is a non-critical CRL extension which conveys a monotonically increasing sequence number for each CRL issued by a CA. This extension allows users to easily determine when a particular CRL supersedes another CRL. CAs conforming to this profile MUST include this extension in all CRLs. id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } cRLNumber ::= INTEGER (0..MAX)
5.2.4 Delta CRL Indicator The delta CRL indicator is a critical CRL extension that identifies a delta-CRL. The use of delta-CRLs can significantly improve processing time for applications which store revocation information in a format other than the CRL structure. This allows changes to be added to the local database while ignoring unchanged information that is already in the local database. When a delta-CRL is issued, the CAs MUST also issue a complete CRL. The value of BaseCRLNumber identifies the CRL number of the base CRL that was used as the starting point in the generation of this delta- CRL. The delta-CRL contains the changes between the base CRL and the current CRL issued along with the delta-CRL. It is the decision of a CA as to whether to provide delta-CRLs. Again, a delta-CRL MUST NOT be issued without a corresponding complete CRL. The value of CRLNumber for both the delta-CRL and the corresponding complete CRL MUST be identical. A CRL user constructing a locally held CRL from delta-CRLs MUST consider the constructed CRL incomplete and unusable if the CRLNumber of the received delta-CRL is more than one greater than the CRLnumber of the delta-CRL last processed. id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } deltaCRLIndicator ::= BaseCRLNumber BaseCRLNumber ::= CRLNumber 5.2.5 Issuing Distribution Point The issuing distribution point is a critical CRL extension that identifies the CRL distribution point for a particular CRL, and it indicates whether the CRL covers revocation for end entity certificates only, CA certificates only, or a limitied set of reason codes. Although the extension is critical, conforming implementations are not required to support this extension. The CRL is signed using the CA's private key. CRL Distribution Points do not have their own key pairs. If the CRL is stored in the X.500 Directory, it is stored in the Directory entry corresponding to the CRL distribution point, which may be different than the Directory entry of the CA.
The reason codes associated with a distribution point shall be specified in onlySomeReasons. If onlySomeReasons does not appear, the distribution point shall contain revocations for all reason codes. CAs may use CRL distribution points to partition the CRL on the basis of compromise and routine revocation. In this case, the revocations with reason code keyCompromise (1) and cACompromise (2) appear in one distribution point, and the revocations with other reason codes appear in another distribution point. Where the issuingDistributionPoint extension contains a URL, the following semantics MUST be assumed: the object is a pointer to the most current CRL issued by this CA. The URI schemes ftp, http, mailto [RFC1738] and ldap [RFC1778] are defined for this purpose. The URI MUST be an absolute, not relative, pathname and MUST specify the host. id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } issuingDistributionPoint ::= SEQUENCE { distributionPoint [0] DistributionPointName OPTIONAL, onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, onlySomeReasons [3] ReasonFlags OPTIONAL, indirectCRL [4] BOOLEAN DEFAULT FALSE } 5.3 CRL Entry Extensions The CRL entry extensions already defined by ANSI X9 and ISO/IEC/ITU for X.509 v2 CRLs provide methods for associating additional attributes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format also allows communities to define private CRL entry extensions to carry information unique to those communities. Each extension in a CRL entry may be designated as critical or non-critical. A CRL validation MUST fail if it encounters a critical CRL entry extension which it does not know how to process. However, an unrecognized non-critical CRL entry extension may be ignored. The following subsections present recommended extensions used within Internet CRL entries and standard locations for information. Communities may elect to use additional CRL entry extensions; however, caution should be exercised in adopting any critical extensions in CRL entries which might be used in a general context. All CRL entry extensions used in this specification are non-critical. Support for these extensions is optional for conforming CAs and applications. However, CAs that issue CRLs SHOULD include reason codes (see sec. 5.3.1) and invalidity dates (see sec. 5.3.3) whenever this information is available.
5.3.1 Reason Code The reasonCode is a non-critical CRL entry extension that identifies the reason for the certificate revocation. CAs are strongly encouraged to include meaningful reason codes in CRL entries; however, the reason code CRL entry extension SHOULD be absent instead of using the unspecified (0) reasonCode value. id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } -- reasonCode ::= { CRLReason } CRLReason ::= ENUMERATED { unspecified (0), keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6), removeFromCRL (8) } 5.3.2 Hold Instruction Code The hold instruction code is a non-critical CRL entry extension that provides a registered instruction identifier which indicates the action to be taken after encountering a certificate that has been placed on hold. id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } holdInstructionCode ::= OBJECT IDENTIFIER The following instruction codes have been defined. Conforming applications that process this extension MUST recognize the following instruction codes. holdInstruction OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57(10040) 2 } id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} id-holdinstruction-callissuer OBJECT IDENTIFIER ::= {holdInstruction 2} id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} Conforming applications which encounter an id-holdinstruction- callissuer MUST call the certificate issuer or reject the certificate. Conforming applications which encounter an id-
holdinstruction-reject MUST reject the certificate. The hold instruction id-holdinstruction-none is semantically equivalent to the absence of a holdInstructionCode, and its use is strongly deprecated for the Internet PKI. 5.3.3 Invalidity Date The invalidity date is a non-critical CRL entry extension that provides the date on which it is known or suspected that the private key was compromised or that the certificate otherwise became invalid. This date may be earlier than the revocation date in the CRL entry, which is the date at which the CA processed the revocation. When a revocation is first posted by a CA in a CRL, the invalidity date may precede the date of issue of earlier CRLs, but the revocation date SHOULD NOT precede the date of issue of earlier CRLs. Whenever this information is available, CAs are strongly encouraged to share it with CRL users. The GeneralizedTime values included in this field MUST be expressed in Greenwich Mean Time (Zulu), and MUST be specified and interpreted as defined in section 4.1.2.5.2. id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } invalidityDate ::= GeneralizedTime 5.3.4 Certificate Issuer This CRL entry extension identifies the certificate issuer associated with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL indicator set in its issuing distribution point extension. If this extension is not present on the first entry in an indirect CRL, the certificate issuer defaults to the CRL issuer. On subsequent entries in an indirect CRL, if this extension is not present, the certificate issuer for the entry is the same as that for the preceding entry. This field is defined as follows: id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } certificateIssuer ::= GeneralNames If used by conforming CAs that issue CRLs, this extension is always critical. If an implementation ignored this extension it could not correctly attribute CRL entries to certificates. This specification RECOMMENDS that implementations recognize this extension.
(next page on part 3)
