the subject is a CA (e.g., the basic constraints extension, as
discussed in 4.2.1.10, is present and the value of cA is TRUE,) then
the subject field MUST be populated with a non-empty distinguished
name matching the contents of the issuer field (see sec. 4.1.2.4) in
all certificates issued by the subject CA. If subject naming
information is present only in the subjectAltName extension (e.g., a
key bound only to an email address or URI), then the subject name
MUST be an empty sequence and the subjectAltName extension MUST be
critical.
Where it is non-empty, the subject field MUST contain an X.500
distinguished name (DN). The DN MUST be unique for each subject
entity certified by the one CA as defined by the issuer name field. A
CA may issue more than one certificate with the same DN to the same
subject entity.
The subject name field is defined as the X.501 type Name.
Implementation requirements for this field are those defined for the
issuer field (see sec. 4.1.2.4). When encoding attribute values of
type DirectoryString, the encoding rules for the issuer field MUST be
implemented. Implementations of this specification MUST be prepared
to receive subject names containing the attribute types required for
the issuer field. Implementations of this specification SHOULD be
prepared to receive subject names containing the recommended
attribute types for the issuer field. The syntax and associated
object identifiers (OIDs) for these attribute types are provided in
the ASN.1 modules in Appendices A and B. Implementations of this
specification MAY use these comparison rules to process unfamiliar
attribute types (i.e., for name chaining). This allows
implementations to process certificates with unfamiliar attributes in
the subject name.
In addition, legacy implementations exist where an RFC822 name is
embedded in the subject distinguished name as an EmailAddress
attribute. The attribute value for EmailAddress is of type IA5String
to permit inclusion of the character '@', which is not part of the
PrintableString character set. EmailAddress attribute values are not
case sensitive (e.g., "fanfeedback@redsox.com" is the same as
"FANFEEDBACK@REDSOX.COM").
Conforming implementations generating new certificates with
electronic mail addresses MUST use the rfc822Name in the subject
alternative name field (see sec. 4.2.1.7) to describe such
identities. Simultaneous inclusion of the EmailAddress attribute in
the subject distinguished name to support legacy implementations is
deprecated but permitted.
4.1.2.7 Subject Public Key Info
This field is used to carry the public key and identify the algorithm
with which the key is used. The algorithm is identified using the
AlgorithmIdentifier structure specified in section 4.1.1.2. The
object identifiers for the supported algorithms and the methods for
encoding the public key materials (public key and parameters) are
specified in section 7.3.
4.1.2.8 Unique Identifiers
These fields may only appear if the version is 2 or 3 (see sec.
4.1.2.1). The subject and issuer unique identifiers are present in
the certificate to handle the possibility of reuse of subject and/or
issuer names over time. This profile recommends that names not be
reused for different entities and that Internet certificates not make
use of unique identifiers. CAs conforming to this profile SHOULD NOT
generate certificates with unique identifiers. Applications
conforming to this profile SHOULD be capable of parsing unique
identifiers and making comparisons.
4.1.2.9 Extensions
This field may only appear if the version is 3 (see sec. 4.1.2.1).
If present, this field is a SEQUENCE of one or more certificate
extensions. The format and content of certificate extensions in the
Internet PKI is defined in section 4.2.
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 RFC822 [RFC822]. 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
RFC822 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 RFC791 [RFC791]. 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 RFC791, the octet string
MUST contain exactly four octets. For IP Version 6, as specified in
RFC1883, 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 [RFC1034]. 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 [RFC1738]. 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 [RFC1738], 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 RFC822 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 RFC1519 (CIDR) to represent an
address range.[RFC1519] 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.