http://www.ietf.org/rfc/rfc2459.txt
The goal of the Internet Public Key Infrastructure (PKI) is to meet
the needs of deterministic, automated identification, authentication,
access control, and authorization functions. Support for these
services determines the attributes contained in the certificate as
well as the ancillary control information in the certificate such as
policy data and certification path constraints.
The components in this model are:
end entity: user of PKI certificates and/or end user system that
is the subject of a certificate;
CA: certification authority;
RA: registration authority, i.e., an optional system to
which a CA delegates certain management functions;
repository: a system or collection of distributed systems that
store certificates and CRLs and serves as a means of
distributing these certificates and CRLs to end
entities.
3.3 Revocation
When a certificate is issued, it is expected to be in use for its
entire validity period. However, various circumstances may cause a
certificate to become invalid prior to the expiration of the validity
period. Such circumstances include change of name, change of
association between subject and CA (e.g., an employee terminates
employment with an organization), and compromise or suspected
compromise of the corresponding private key. Under such
circumstances, the CA needs to revoke the certificate.
X.509 defines one method of certificate revocation. This method
involves each CA periodically issuing a signed data structure called
a certificate revocation list (CRL). A CRL is a time stamped list
identifying revoked certificates which is signed by a CA and made
freely available in a public repository. Each revoked certificate is
identified in a CRL by its certificate serial number. When a
certificate-using system uses a certificate (e.g., for verifying a
remote user's digital signature), that system not only checks the
certificate signature and validity but also acquires a suitably-
recent CRL and checks that the certificate serial number is not on
that CRL. The meaning of "suitably-recent" may vary with local
policy, but it usually means the most recently-issued CRL. A CA
issues a new CRL on a regular periodic basis (e.g., hourly, daily, or
weekly). An entry is added to the CRL as part of the next update
following notification of revocation. An entry may be removed from
the CRL after appearing on one regularly scheduled CRL issued beyond
the revoked certificate's validity period.
An advantage of this revocation method is that CRLs may be
distributed by exactly the same means as certificates themselves,
namely, via untrusted communications and server systems.
One limitation of the CRL revocation method, using untrusted
communications and servers, is that the time granularity of
revocation is limited to the CRL issue period. For example, if a
revocation is reported now, that revocation will not be reliably
notified to certificate-using systems until the next periodic CRL is
issued -- this may be up to one hour, one day, or one week depending
on the frequency that the CA issues CRLs.
As with the X.509 v3 certificate format, in order to facilitate
interoperable implementations from multiple vendors, the X.509 v2 CRL
format needs to be profiled for Internet use. It is one goal of this
document to specify that profile. However, this profile does not
require CAs to issue CRLs. Message formats and protocols supporting
on-line revocation notification may be defined in other PKIX
specifications. On-line methods of revocation notification may be
applicable in some environments as an alternative to the X.509 CRL.
On-line revocation checking may significantly reduce the latency
between a revocation report and the distribution of the information
to relying parties. Once the CA accepts the report as authentic and
valid, any query to the on-line service will correctly reflect the
certificate validation impacts of the revocation. However, these
methods impose new security requirements; the certificate validator
shall trust the on-line validation service while the repository does
not need to be trusted.
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) }
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.
4.1.2.5.1 UTCTime
The universal time type, UTCTime, is a standard ASN.1 type intended
for international applications where local time alone is not
adequate. UTCTime specifies the year through the two low order
digits and time is specified to the precision of one minute or one
second. UTCTime includes either Z (for Zulu, or Greenwich Mean Time)
or a time differential.
For the purposes of this profile, UTCTime values MUST be expressed
Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are
YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming
systems MUST interpret the year field (YY) as follows:
Where YY is greater than or equal to 50, the year shall be
interpreted as 19YY; and
Where YY is less than 50, the year shall be interpreted as 20YY.
4.1.2.5.2 GeneralizedTime
The generalized time type, GeneralizedTime, is a standard ASN.1 type
for variable precision representation of time. Optionally, the
GeneralizedTime field can include a representation of the time
differential between local and Greenwich Mean Time.
For the purposes of this profile, GeneralizedTime values MUST be
expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e.,
times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
GeneralizedTime values MUST NOT include fractional seconds.
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.
6 Certification Path Validation
Certification path validation procedures for the Internet PKI are
based on section 12.4.3 of [X.509]. Certification path processing
verifies the binding between the subject distinguished name and/or
subject alternative name and subject public key. The binding is
limited by constraints which are specified in the certificates which
comprise the path. The basic constraints and policy constraints
extensions allow the certification path processing logic to automate
the decision making process.
This section describes an algorithm for validating certification
paths. Conforming implementations of this specification are not
required to implement this algorithm, but MUST be functionally
equivalent to the external behavior resulting from this procedure.
Any algorithm may be used by a particular implementation so long as
it derives the correct result.
In section 6.1, the text describes basic path validation. This text
assumes that all valid paths begin with certificates issued by a
single "most-trusted CA". The algorithm requires the public key of
the CA, the CA's name, the validity period of the public key, and any
constraints upon the set of paths which may be validated using this
key.
The "most-trusted CA" is a matter of policy: it could be a root CA in
a hierarchical PKI; the CA that issued the verifier's own
certificate(s); or any other CA in a network PKI. The path
validation procedure is the same regardless of the choice of "most-
trusted CA."
section 6.2 describes extensions to the basic path validation
algorithm. Two specific cases are discussed: the case where paths may
begin with one of several trusted CAs; and where compatibility with
the PEM architecture is required.
6.1 Basic Path Validation
The text assumes that the trusted public key (and related
information) is contained in a "self-signed" certificate. This
simplifies the description of the path processing procedure. Note
that the signature on the self-signed certificate does not provide
any security services. The trusted public key (and related
information) may be obtained in other formats; the information is
trusted because of other procedures used to obtain and protect it.
The goal of path validation is to verify the binding between a
subject distinguished name or subject alternative name and subject
public key, as represented in the "end entity" certificate, based on
the public key of the "most-trusted CA". This requires obtaining a
sequence of certificates that support that binding. The procedures
performed to obtain this sequence is outside the scope of this
section.
The following text also assumes that certificates do not use subject
or unique identifier fields or private critical extensions, as
recommended within this profile. However, if these components appear
in certificates, they MUST be processed. Finally, policy qualifiers
are also neglected for the sake of clarity.
A certification path is a sequence of n certificates where:
* for all x in {1,(n-1)}, the subject of certificate x is the
issuer of certificate x+1.
* certificate x=1 is the the self-signed certificate, and
* certificate x=n is the end entity certificate.
This section assumes the following inputs are provided to the path
processing logic:
(a) a certification path of length n;
(b) a set of initial policy identifiers (each comprising a
sequence of policy element identifiers), which identifies one or
more certificate policies, any one of which would be acceptable
for the purposes of certification path processing, or the special
value "any-policy";
(c) the current date/time (if not available internally to the
certification path processing module); and
(d) the time, T, for which the validity of the path should be
determined. (This may be the current date/time, or some point in
the past.)
From the inputs, the procedure intializes five state variables:
(a) acceptable policy set: A set of certificate policy
identifiers comprising the policy or policies recognized by the
public key user together with policies deemed equivalent through
policy mapping. The initial value of the acceptable policy set is
the special value "any-policy".
(b) constrained subtrees: A set of root names defining a set of
subtrees within which all subject names in subsequent certificates
in the certification path shall fall. The initial value is
"unbounded".
(c) excluded subtrees: A set of root names defining a set of
subtrees within which no subject name in subsequent certificates
in the certification path may fall. The initial value is "empty".
(d) explicit policy: an integer which indicates if an explicit
policy identifier is required. The integer indicates the first
certificate in the path where this requirement is imposed. Once
set, this variable may be decreased, but may not be increased.
(That is, if a certificate in the path requires explicit policy
identifiers, a later certificate can not remove this requirement.)
The initial value is n+1.
(e) policy mapping: an integer which indicates if policy mapping
is permitted. The integer indicates the last certificate on which
policy mapping may be applied. Once set, this variable may be
decreased, but may not be increased. (That is, if a certificate in
the path specifies policy mapping is not permitted, it can not be
overriden by a later certificate.) The initial value is n+1.
The actions performed by the path processing software for each
certificate i=1 through n are described below. The self-signed
certificate is certificate i=1, the end entity certificate is i=n.
The processing is performed sequentially, so that processing
certificate i affects the state variables for processing certificate
(i+1). Note that actions (h) through (m) are not applied to the end
entity certificate (certificate n).
The path processing actions to be performed are:
(a) Verify the basic certificate information, including:
(1) the certificate was signed using the subject public key
from certificate i-1 (in the special case i=1, this step may be
omitted; if not, use the subject public key from the same
certificate),
(2) the certificate validity period includes time T,
(3) the certificate had not been revoked at time T and is not
currently on hold status that commenced before time T, (this
may be determined by obtaining the appropriate CRL or status
information, or by out-of-band mechanisms), and
(4) the subject and issuer names chain correctly (that is, the
issuer of this certificate was the subject of the previous
certificate.)
(b) Verify that the subject name and subjectAltName extension
(critical or noncritical) is consistent with the constrained
subtrees state variables.
(c) Verify that the subject name and subjectAltName extension
(critical or noncritical) is consistent with the excluded subtrees
state variables.
(d) Verify that policy information is consistent with the initial
policy set:
(1) if the explicit policy state variable is less than or equal
to i, a policy identifier in the certificate shall be in the
initial policy set; and
(2) if the policy mapping variable is less than or equal to i,
the policy identifier may not be mapped.
(e) Verify that policy information is consistent with the
acceptable policy set:
(1) if the certificate policies extension is marked critical,
the intersection of the policies extension and the acceptable
policy set shall be non-null;
(2) the acceptable policy set is assigned the resulting
intersection as its new value.
(g) Verify that the intersection of the acceptable policy set and
the initial policy set is non-null.
(h) Recognize and process any other critical extension present in
the certificate.
(i) Verify that the certificate is a CA certificate (as specified
in a basicConstraints extension or as verified out-of-band).
(j) If permittedSubtrees is present in the certificate, set the
constrained subtrees state variable to the intersection of its
previous value and the value indicated in the extension field.
(k) If excludedSubtrees is present in the certificate, set the
excluded subtrees state variable to the union of its previous
value and the value indicated in the extension field.
(l) If a policy constraints extension is included in the
certificate, modify the explicit policy and policy mapping state
variables as follows:
(1) If requireExplicitPolicy is present and has value r, the
explicit policy state variable is set to the minimum of its
current value and the sum of r and i (the current certificate
in the sequence).
(2) If inhibitPolicyMapping is present and has value q, the
policy mapping state variable is set to the minimum of its
current value and the sum of q and i (the current certificate
in the sequence).
(m) If a key usage extension is marked critical, ensure the
keyCertSign bit is set.
If any one of the above checks fail, the procedure terminates,
returning a failure indication and an appropriate reason. If none of
the above checks fail on the end-entity certificate, the procedure
terminates, returning a success indication together with the set of
all policy qualifier values encountered in the set of certificates.
6.2 Extending Path Validation
The path validation algorithm presented in 6.1 is based on several
simplifying assumptions (e.g., a single trusted CA that starts all
valid paths). This algorithm may be extended for cases where the
assumptions do not hold.
This procedure may be extended for multiple trusted CAs by providing
a set of self-signed certificates to the validation module. In this
case, a valid path could begin with any one of the self-signed
certificates. Limitations in the trust paths for any particular key
may be incorporated into the self-signed certificate's extensions. In
this way, the self-signed certificates permit the path validation
module to automatically incorporate local security policy and
requirements.
It is also possible to specify an extended version of the above
certification path processing procedure which results in default
behavior identical to the rules of PEM [RFC 1422]. In this extended
version, additional inputs to the procedure are a list of one or more
Policy Certification Authorities (PCAs) names and an indicator of the
position in the certification path where the PCA is expected. At the
nominated PCA position, the CA name is compared against this list.
If a recognized PCA name is found, then a constraint of
SubordinateToCA is implicitly assumed for the remainder of the
certification path and processing continues. If no valid PCA name is
found, and if the certification path cannot be validated on the basis
of identified policies, then the certification path is considered
invalid.
D.1 Certificate
This section contains an annotated hex dump of a 699 byte version 3
certificate. The certificate contains the following information:
(a) the serial number is 17 (11 hex);
(b) the certificate is signed with DSA and the SHA-1 hash algorithm;
(c) the issuer's distinguished name is OU=nist; O=gov; C=US
(d) and the subject's distinguished name is OU=nist; O=gov; C=US
(e) the certificate was issued on June 30, 1997 and will expire on
December 31, 1997;
(f) the certificate contains a 1024 bit DSA public key with
parameters;
(g) the certificate contains a subject key identifier extension; and
(h) the certificate is a CA certificate (as indicated through the
basic constraints extension.)
0000 30 82 02 b7 695: SEQUENCE
0004 30 82 02 77 631: . SEQUENCE tbscertificate
0008 a0 03 3: . . [0]
0010 02 01 1: . . . INTEGER 2
: 02
0013 02 01 1: . . INTEGER 17
: 11
0016 30 09 9: . . SEQUENCE
0018 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha
: 2a 86 48 ce 38 04 03
0027 30 2a 42: . . SEQUENCE
0029 31 0b 11: . . . SET
0031 30 09 9: . . . . SEQUENCE
0033 06 03 3: . . . . . OID 2.5.4.6: C
: 55 04 06
0038 13 02 2: . . . . . PrintableString 'US'
: 55 53
0042 31 0c 12: . . . SET
0044 30 0a 10: . . . . SEQUENCE
0046 06 03 3: . . . . . OID 2.5.4.10: O
: 55 04 0a
0051 13 03 3: . . . . . PrintableString 'gov'
: 67 6f 76
0056 31 0d 13: . . . SET
0058 30 0b 11: . . . . SEQUENCE
0060 06 03 3: . . . . . OID 2.5.4.11: OU
: 55 04 0b
0065 13 04 4: . . . . . PrintableString 'nist'
: 6e 69 73 74
0071 30 1e 30: . . SEQUENCE
0073 17 0d 13: . . . UTCTime '970630000000Z'
: 39 37 30 36 33 30 30 30 30 30 30 30 5a
0088 17 0d 13: . . . UTCTime '971231000000Z'
: 39 37 31 32 33 31 30 30 30 30 30 30 5a
0103 30 2a 42: . . SEQUENCE
0105 31 0b 11: . . . SET
0107 30 09 9: . . . . SEQUENCE
0109 06 03 3: . . . . . OID 2.5.4.6: C
: 55 04 06
0114 13 02 2: . . . . . PrintableString 'US'
: 55 53
0118 31 0c 12: . . . SET
0120 30 0a 10: . . . . SEQUENCE
0122 06 03 3: . . . . . OID 2.5.4.10: O
: 55 04 0a
0127 13 03 3: . . . . . PrintableString 'gov'
: 67 6f 76
0132 31 0d 13: . . . SET
0134 30 0b 11: . . . . SEQUENCE
0136 06 03 3: . . . . . OID 2.5.4.11: OU
: 55 04 0b
0141 13 04 4: . . . . . PrintableString 'nist'
: 6e 69 73 74
0147 30 82 01 b4 436: . . SEQUENCE
0151 30 82 01 29 297: . . . SEQUENCE
0155 06 07 7: . . . . OID 1.2.840.10040.4.1: dsa
: 2a 86 48 ce 38 04 01
0164 30 82 01 1c 284: . . . . SEQUENCE
0168 02 81 80 128: . . . . . INTEGER
: d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 63 55 d3
: 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 62 b4 d2
: 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 83 3d 03
: 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a f7 e2 a6
: 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5a f7 0a
: 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 31 23 be
: 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 9c eb 4d
: f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 7d 57 8d
0299 02 14 20: . . . . . INTEGER
: a7 83 9b f3 bd 2c 20 07 fc 4c e7 e8 9f f3 39 83
: 51 0d dc dd
0321 02 81 80 128: . . . . . INTEGER
: 0e 3b 46 31 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca
: 90 88 57 64 9f 01 21 e0 15 05 94 24 82 e2 10 90
: d9 e1 4e 10 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5
: a1 7d b5 07 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb
: ac fa 4e 76 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d
: a6 97 59 c5 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42
: 87 62 3f f1 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90
: cf 67 db de 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d
0452 03 81 84 132: . . . BIT STRING (0 unused bits)
: 02 81 80 aa 98 ea 13 94 a2 db f1 5b 7f 98 2f 78
: e7 d8 e3 b9 71 86 f6 80 2f 40 39 c3 da 3b 4b 13
: 46 26 ee 0d 56 c5 a3 3a 39 b7 7d 33 c2 6b 5c 77
: 92 f2 55 65 90 39 cd 1a 3c 86 e1 32 eb 25 bc 91
: c4 ff 80 4f 36 61 bd cc e2 61 04 e0 7e 60 13 ca
: c0 9c dd e0 ea 41 de 33 c1 f1 44 a9 bc 71 de cf
: 59 d4 6e da 44 99 3c 21 64 e4 78 54 9d d0 7b ba
: 4e f5 18 4d 5e 39 30 bf e0 d1 f6 f4 83 25 4f 14
: aa 71 e1
0587 a3 32 50: . . [3]
0589 30 30 48: . . . SEQUENCE
0591 30 0f 9: . . . . SEQUENCE
0593 06 03 3: . . . . . OID 2.5.29.19: basicConstraints
: 55 1d 13
0598 01 01 1: . . . . . TRUE
: ff
0601 04 05 5: . . . . . OCTET STRING
: 30 03 01 01 ff
0608 30 1d 29: . SEQUENCE
0610 06 03 3: . . . . . OID 2.5.29.14: subjectKeyIdentifier
: 55 1d 0e
0615 04 16 22: . . . . . OCTET STRING
: 04 14 e7 26 c5 54 cd 5b a3 6f 35 68 95 aa d5 ff
D.4 Certificate Revocation List
This section contains an annotated hex dump of a version 2 CRL with
one extension (cRLNumber). The CRL was issued by OU=nist;O=gov;C=us
on July 7, 1996; the next scheduled issuance was August 7, 1996. The
CRL includes one revoked certificates: serial number 18 (12 hex).
The CRL itself is number 18, and it was signed with DSA and SHA-1.
0000 30 81 ba 186: SEQUENCE
0003 30 7c 124: . SEQUENCE
0005 02 01 1: . . INTEGER 1
: 01
0008 30 09 9: . . SEQUENCE
0010 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha
: 2a 86 48 ce 38 04 03
0019 30 2a 42: . . SEQUENCE
0021 31 0b 11: . . . SET
0023 30 09 9: . . . . SEQUENCE
0025 06 03 3: . . . . . OID 2.5.4.6: C
: 55 04 06
0030 13 02 2: . . . . . PrintableString 'US'
: 55 53
0034 31 0c 12: . . . SET
0036 30 0a 10: . . . . SEQUENCE
0038 06 03 3: . . . . . OID 2.5.4.10: O
: 55 04 0a
0043 13 03 3: . . . . . PrintableString 'gov'
: 67 6f 76
0048 31 0d 13: . . . SET
0050 30 0b 11: . . . . SEQUENCE
0052 06 03 3: . . . . . OID 2.5.4.11: OU
: 55 04 0b
Housley, et. al. Standards Track [Page 126]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
0057 13 04 4: . . . . . PrintableString 'nist'
: 6e 69 73 74
0063 17 0d 13: . . UTCTime '970801000000Z'
: 39 37 30 38 30 31 30 30 30 30 30 30 5a
0078 17 0d 13: . . UTCTime '970808000000Z'
: 39 37 30 38 30 38 30 30 30 30 30 30 5a
0093 30 22 34: . . SEQUENCE
0095 30 20 32: . . . SEQUENCE
0097 02 01 1: . . . . INTEGER 18
: 12
0100 17 0d 13: . . . . UTCTime '970731000000Z'
: 39 37 30 37 33 31 30 30 30 30 30 30 5a
0115 30 0c 12: . . . . SEQUENCE
0117 30 0a 10: . . . . . SEQUENCE
0119 06 03 3: . . . . . . OID 2.5.29.21: reasonCode
: 55 1d 15
0124 04 03 3: . . . . . . OCTET STRING
: 0a 01 01
0129 30 09 9: . SEQUENCE
0131 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha
: 2a 86 48 ce 38 04 03
0140 03 2f 47: . BIT STRING (0 unused bits)
: 30 2c 02 14 9e d8 6b c1 7d c2 c4 02 f5 17 84 f9
: 9f 46 7a ca cf b7 05 8a 02 14 9e 43 39 85 dc ea
: 14 13 72 93 54 5d 44 44 e5 05 fe 73 9a b2