RFC 5280
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Pages: 151
Proposed Standard
→ Errata
Obsoletes: 3280 4325 4630
Updated by: 6818 8398 8399 9549
Proposed Standard
→ Errata
Obsoletes: 3280 4325 4630
Updated by: 6818 8398 8399 9549
Part 4 of 7 – Pages 71 to 95
6. Certification Path Validation
Certification path validation procedures for the Internet PKI are based on the algorithm supplied in [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 that are specified in the certificates that comprise the path and inputs that are specified by the relying party. 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 provide functionality 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. Valid paths begin with certificates issued by a trust anchor. The algorithm requires the public key of the CA, the CA's name, and any constraints upon the set of paths that may be validated using this key. The selection of a trust anchor is a matter of policy: it could be the top 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 trust anchor. In addition, different applications may rely on different trust anchors, or may accept paths that begin with any of a set of trust anchors. Section 6.2 describes methods for using the path validation algorithm in specific implementations. Section 6.3 describes the steps necessary to determine if a certificate is revoked when CRLs are the revocation mechanism used by the certificate issuer.6.1. Basic Path Validation
This text describes an algorithm for X.509 path processing. A conforming implementation MUST include an X.509 path processing procedure that is functionally equivalent to the external behavior of this algorithm. However, support for some of the certificate extensions processed in this algorithm are OPTIONAL for compliant implementations. Clients that do not support these extensions MAY omit the corresponding steps in the path validation algorithm. For example, clients are not required to support the policy mappings extension. Clients that do not support this extension MAY omit the path validation steps where policy mappings are processed. Note that clients MUST reject the certificate if it contains an unsupported critical extension. While the certificate and CRL profiles specified in Sections 4 and 5 of this document specify values for certificate and CRL fields and extensions that are considered to be appropriate for the Internet PKI, the algorithm presented in this section is not limited to accepting certificates and CRLs that conform to these profiles. Therefore, the algorithm only includes checks to verify that the certification path is valid according to X.509 and does not include checks to verify that the certificates and CRLs conform to this profile. While the algorithm could be extended to include checks for conformance to the profiles in Sections 4 and 5, this profile RECOMMENDS against including such checks. The algorithm presented in this section validates the certificate with respect to the current date and time. A conforming implementation MAY also support validation with respect to some point in the past. Note that mechanisms are not available for validating a certificate with respect to a time outside the certificate validity period.
The trust anchor is an input to the algorithm. There is no requirement that the same trust anchor be used to validate all certification paths. Different trust anchors MAY be used to validate different paths, as discussed further in Section 6.2. The primary goal of path validation is to verify the binding between a subject distinguished name or a subject alternative name and subject public key, as represented in the target certificate, based on the public key of the trust anchor. In most cases, the target certificate will be an end entity certificate, but the target certificate may be a CA certificate as long as the subject public key is to be used for a purpose other than verifying the signature on a public key certificate. Verifying the binding between the name and subject public key requires obtaining a sequence of certificates that support that binding. The procedure performed to obtain this sequence of certificates is outside the scope of this specification. To meet this goal, the path validation process verifies, among other things, that a prospective certification path (a sequence of n certificates) satisfies the following conditions: (a) for all x in {1, ..., n-1}, the subject of certificate x is the issuer of certificate x+1; (b) certificate 1 is issued by the trust anchor; (c) certificate n is the certificate to be validated (i.e., the target certificate); and (d) for all x in {1, ..., n}, the certificate was valid at the time in question. A certificate MUST NOT appear more than once in a prospective certification path. When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path. Information about trust anchors is provided as inputs to the certification path validation algorithm (Section 6.1.1). A particular certification path may not, however, be appropriate for all applications. Therefore, an application MAY augment this algorithm to further limit the set of valid paths. The path validation process also determines the set of certificate policies that are valid for this path, based on the certificate policies extension, policy mappings extension, policy constraints extension, and inhibit anyPolicy extension. To achieve this, the path
validation algorithm constructs a valid policy tree. If the set of certificate policies that are valid for this path is not empty, then the result will be a valid policy tree of depth n, otherwise the result will be a null valid policy tree. A certificate is self-issued if the same DN appears in the subject and issuer fields (the two DNs are the same if they match according to the rules specified in Section 7.1). In general, the issuer and subject of the certificates that make up a path are different for each certificate. However, a CA may issue a certificate to itself to support key rollover or changes in certificate policies. These self-issued certificates are not counted when evaluating path length or name constraints. This section presents the algorithm in four basic steps: (1) initialization, (2) basic certificate processing, (3) preparation for the next certificate, and (4) wrap-up. Steps (1) and (4) are performed exactly once. Step (2) is performed for all certificates in the path. Step (3) is performed for all certificates in the path except the final certificate. Figure 2 provides a high-level flowchart of this algorithm.
+-------+ | START | +-------+ | V +----------------+ | Initialization | +----------------+ | +<--------------------+ | | V | +----------------+ | | Process Cert | | +----------------+ | | | V | +================+ | | IF Last Cert | | | in Path | | +================+ | | | | THEN | | ELSE | V V | +----------------+ +----------------+ | | Wrap up | | Prepare for | | +----------------+ | Next Cert | | | +----------------+ | V | | +-------+ +--------------+ | STOP | +-------+ Figure 2. Certification Path Processing Flowchart6.1.1. Inputs
This algorithm assumes that the following nine inputs are provided to the path processing logic: (a) a prospective certification path of length n. (b) the current date/time.
(c) user-initial-policy-set: A set of certificate policy
identifiers naming the policies that are acceptable to the
certificate user. The user-initial-policy-set contains the
special value any-policy if the user is not concerned about
certificate policy.
(d) trust anchor information, describing a CA that serves as a
trust anchor for the certification path. The trust anchor
information includes:
(1) the trusted issuer name,
(2) the trusted public key algorithm,
(3) the trusted public key, and
(4) optionally, the trusted public key parameters associated
with the public key.
The trust anchor information may be provided to the path
processing procedure in the form of a self-signed certificate.
When the trust anchor information is provided in the form of a
certificate, the name in the subject field is used as the trusted
issuer name and the contents of the subjectPublicKeyInfo field is
used as the source of the trusted public key algorithm and the
trusted public key. The trust anchor information is trusted
because it was delivered to the path processing procedure by some
trustworthy out-of-band procedure. If the trusted public key
algorithm requires parameters, then the parameters are provided
along with the trusted public key.
(e) initial-policy-mapping-inhibit, which indicates if policy
mapping is allowed in the certification path.
(f) initial-explicit-policy, which indicates if the path must be
valid for at least one of the certificate policies in the
user-initial-policy-set.
(g) initial-any-policy-inhibit, which indicates whether the
anyPolicy OID should be processed if it is included in a
certificate.
(h) initial-permitted-subtrees, which indicates for each name
type (e.g., X.500 distinguished names, email addresses, or IP
addresses) a set of subtrees within which all subject names
in every certificate in the certification path MUST fall.
The initial-permitted-subtrees input includes a set for each
name type. For each name type, the set may consist of a
single subtree that includes all names of that name type or
one or more subtrees that each specifies a subset of the
names of that name type, or the set may be empty. If the set
for a name type is empty, then the certification path will be
considered invalid if any certificate in the certification
path includes a name of that name type.
(i) initial-excluded-subtrees, which indicates for each name type
(e.g., X.500 distinguished names, email addresses, or IP
addresses) a set of subtrees within which no subject name in
any certificate in the certification path may fall. The
initial-excluded-subtrees input includes a set for each name
type. For each name type, the set may be empty or may
consist of one or more subtrees that each specifies a subset
of the names of that name type. If the set for a name type
is empty, then no names of that name type are excluded.
Conforming implementations are not required to support the setting of
all of these inputs. For example, a conforming implementation may be
designed to validate all certification paths using a value of FALSE
for initial-any-policy-inhibit.
6.1.2. Initialization
This initialization phase establishes eleven state variables based
upon the nine inputs:
(a) valid_policy_tree: A tree of certificate policies with their
optional qualifiers; each of the leaves of the tree
represents a valid policy at this stage in the certification
path validation. If valid policies exist at this stage in
the certification path validation, the depth of the tree is
equal to the number of certificates in the chain that have
been processed. If valid policies do not exist at this stage
in the certification path validation, the tree is set to
NULL. Once the tree is set to NULL, policy processing
ceases.
Each node in the valid_policy_tree includes three data
objects: the valid policy, a set of associated policy
qualifiers, and a set of one or more expected policy values.
If the node is at depth x, the components of the node have
the following semantics:
(1) The valid_policy is a single policy OID representing a
valid policy for the path of length x.
(2) The qualifier_set is a set of policy qualifiers associated
with the valid policy in certificate x.
(3) The expected_policy_set contains one or more policy OIDs
that would satisfy this policy in the certificate x+1.
The initial value of the valid_policy_tree is a single node with
valid_policy anyPolicy, an empty qualifier_set, and an
expected_policy_set with the single value anyPolicy. This node is
considered to be at depth zero.
Figure 3 is a graphic representation of the initial state of the
valid_policy_tree. Additional figures will use this format to
describe changes in the valid_policy_tree during path processing.
+----------------+
| anyPolicy | <---- valid_policy
+----------------+
| {} | <---- qualifier_set
+----------------+
| {anyPolicy} | <---- expected_policy_set
+----------------+
Figure 3. Initial Value of the valid_policy_tree State Variable
(b) permitted_subtrees: a set of root names for each name type
(e.g., X.500 distinguished names, email addresses, or IP
addresses) defining a set of subtrees within which all
subject names in subsequent certificates in the certification
path MUST fall. This variable includes a set for each name
type, and the initial value is initial-permitted-subtrees.
(c) excluded_subtrees: a set of root names for each name type
(e.g., X.500 distinguished names, email addresses, or IP
addresses) defining a set of subtrees within which no subject
name in subsequent certificates in the certification path may
fall. This variable includes a set for each name type, and
the initial value is initial-excluded-subtrees.
(d) explicit_policy: an integer that indicates if a non-NULL
valid_policy_tree is required. The integer indicates the
number of non-self-issued certificates to be processed before
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 a non-NULL
valid_policy_tree, a later certificate cannot remove this
requirement. If initial-explicit-policy is set, then the
initial value is 0, otherwise the initial value is n+1.
(e) inhibit_anyPolicy: an integer that indicates whether the
anyPolicy policy identifier is considered a match. The
integer indicates the number of non-self-issued certificates
to be processed before the anyPolicy OID, if asserted in a
certificate other than an intermediate self-issued
certificate, is ignored. Once set, this variable may be
decreased, but may not be increased. That is, if a
certificate in the path inhibits processing of anyPolicy, a
later certificate cannot permit it. If initial-any-policy-
inhibit is set, then the initial value is 0, otherwise the
initial value is n+1.
(f) policy_mapping: an integer that indicates if policy mapping
is permitted. The integer indicates the number of non-self-
issued certificates to be processed before policy mapping is
inhibited. Once set, this variable may be decreased, but may
not be increased. That is, if a certificate in the path
specifies that policy mapping is not permitted, it cannot be
overridden by a later certificate. If initial-policy-
mapping-inhibit is set, then the initial value is 0,
otherwise the initial value is n+1.
(g) working_public_key_algorithm: the digital signature
algorithm used to verify the signature of a certificate. The
working_public_key_algorithm is initialized from the trusted
public key algorithm provided in the trust anchor
information.
(h) working_public_key: the public key used to verify the
signature of a certificate. The working_public_key is
initialized from the trusted public key provided in the trust
anchor information.
(i) working_public_key_parameters: parameters associated with
the current public key that may be required to verify a
signature (depending upon the algorithm). The
working_public_key_parameters variable is initialized from
the trusted public key parameters provided in the trust
anchor information.
(j) working_issuer_name: the issuer distinguished name expected
in the next certificate in the chain. The
working_issuer_name is initialized to the trusted issuer name
provided in the trust anchor information.
(k) max_path_length: this integer is initialized to n, is
decremented for each non-self-issued certificate in the path,
and may be reduced to the value in the path length constraint
field within the basic constraints extension of a CA
certificate.
Upon completion of the initialization steps, perform the basic
certificate processing steps specified in 6.1.3.
6.1.3. Basic Certificate Processing
The basic path processing actions to be performed for certificate i
(for all i in [1..n]) are listed below.
(a) Verify the basic certificate information. The certificate
MUST satisfy each of the following:
(1) The signature on the certificate can be verified using
working_public_key_algorithm, the working_public_key, and
the working_public_key_parameters.
(2) The certificate validity period includes the current time.
(3) At the current time, the certificate is not revoked. This
may be determined by obtaining the appropriate CRL
(Section 6.3), by status information, or by out-of-band
mechanisms.
(4) The certificate issuer name is the working_issuer_name.
(b) If certificate i is self-issued and it is not the final
certificate in the path, skip this step for certificate i.
Otherwise, verify that the subject name is within one of the
permitted_subtrees for X.500 distinguished names, and verify
that each of the alternative names in the subjectAltName
extension (critical or non-critical) is within one of the
permitted_subtrees for that name type.
(c) If certificate i is self-issued and it is not the final
certificate in the path, skip this step for certificate i.
Otherwise, verify that the subject name is not within any of
the excluded_subtrees for X.500 distinguished names, and
verify that each of the alternative names in the
subjectAltName extension (critical or non-critical) is not
within any of the excluded_subtrees for that name type.
(d) If the certificate policies extension is present in the
certificate and the valid_policy_tree is not NULL, process
the policy information by performing the following steps in
order:
(1) For each policy P not equal to anyPolicy in the
certificate policies extension, let P-OID denote the OID
for policy P and P-Q denote the qualifier set for policy
P. Perform the following steps in order:
(i) For each node of depth i-1 in the valid_policy_tree
where P-OID is in the expected_policy_set, create a
child node as follows: set the valid_policy to P-OID,
set the qualifier_set to P-Q, and set the
expected_policy_set to
{P-OID}.
For example, consider a valid_policy_tree with a node
of depth i-1 where the expected_policy_set is {Gold,
White}. Assume the certificate policies Gold and
Silver appear in the certificate policies extension of
certificate i. The Gold policy is matched, but the
Silver policy is not. This rule will generate a child
node of depth i for the Gold policy. The result is
shown as Figure 4.
+-----------------+
| Red |
+-----------------+
| {} |
+-----------------+ node of depth i-1
| {Gold, White} |
+-----------------+
|
|
|
V
+-----------------+
| Gold |
+-----------------+
| {} |
+-----------------+ node of depth i
| {Gold} |
+-----------------+
Figure 4. Processing an Exact Match
(ii) If there was no match in step (i) and the
valid_policy_tree includes a node of depth i-1 with
the valid_policy anyPolicy, generate a child node with
the following values: set the valid_policy to P-OID,
set the qualifier_set to P-Q, and set the
expected_policy_set to {P-OID}.
For example, consider a valid_policy_tree with a node
of depth i-1 where the valid_policy is anyPolicy.
Assume the certificate policies Gold and Silver appear
in the certificate policies extension of certificate
i. The Gold policy does not have a qualifier, but the
Silver policy has the qualifier Q-Silver. If Gold and
Silver were not matched in (i) above, this rule will
generate two child nodes of depth i, one for each
policy. The result is shown as Figure 5.
+-----------------+
| anyPolicy |
+-----------------+
| {} |
+-----------------+ node of depth i-1
| {anyPolicy} |
+-----------------+
/ \
/ \
/ \
/ \
+-----------------+ +-----------------+
| Gold | | Silver |
+-----------------+ +-----------------+
| {} | | {Q-Silver} |
+-----------------+ nodes of +-----------------+
| {Gold} | depth i | {Silver} |
+-----------------+ +-----------------+
Figure 5. Processing Unmatched Policies when a
Leaf Node Specifies anyPolicy
(2) If the certificate policies extension includes the policy
anyPolicy with the qualifier set AP-Q and either (a)
inhibit_anyPolicy is greater than 0 or (b) i<n and the
certificate is self-issued, then:
For each node in the valid_policy_tree of depth i-1, for
each value in the expected_policy_set (including
anyPolicy) that does not appear in a child node, create a
child node with the following values: set the valid_policy
to the value from the expected_policy_set in the parent
node, set the qualifier_set to AP-Q, and set the
expected_policy_set to the value in the valid_policy from
this node.
For example, consider a valid_policy_tree with a node of
depth i-1 where the expected_policy_set is {Gold, Silver}.
Assume anyPolicy appears in the certificate policies
extension of certificate i with no policy qualifiers, but
Gold and Silver do not appear. This rule will generate
two child nodes of depth i, one for each policy. The
result is shown below as Figure 6.
+-----------------+
| Red |
+-----------------+
| {} |
+-----------------+ node of depth i-1
| {Gold, Silver} |
+-----------------+
/ \
/ \
/ \
/ \
+-----------------+ +-----------------+
| Gold | | Silver |
+-----------------+ +-----------------+
| {} | | {} |
+-----------------+ nodes of +-----------------+
| {Gold} | depth i | {Silver} |
+-----------------+ +-----------------+
Figure 6. Processing Unmatched Policies When the
Certificate Policies Extension Specifies anyPolicy
(3) If there is a node in the valid_policy_tree of depth i-1
or less without any child nodes, delete that node. Repeat
this step until there are no nodes of depth i-1 or less
without children.
For example, consider the valid_policy_tree shown in
Figure 7 below. The two nodes at depth i-1 that are
marked with an 'X' have no children, and they are deleted.
Applying this rule to the resulting tree will cause the
node at depth i-2 that is marked with a 'Y' to be deleted.
In the resulting tree, there are no nodes of depth i-1 or
less without children, and this step is complete.
(e) If the certificate policies extension is not present, set the
valid_policy_tree to NULL.
(f) Verify that either explicit_policy is greater than 0 or the
valid_policy_tree is not equal to NULL;
If any of steps (a), (b), (c), or (f) fails, the procedure
terminates, returning a failure indication and an appropriate reason.
If i is not equal to n, continue by performing the preparatory steps
listed in Section 6.1.4. If i is equal to n, perform the wrap-up
steps listed in Section 6.1.5.
+-----------+
| | node of depth i-3
+-----------+
/ | \
/ | \
/ | \
+-----------+ +-----------+ +-----------+
| | | | | Y | nodes of
+-----------+ +-----------+ +-----------+ depth i-2
/ \ | |
/ \ | |
/ \ | |
+-----------+ +-----------+ +-----------+ +-----------+ nodes of
| | | X | | | | X | depth
+-----------+ +-----------+ +-----------+ +-----------+ i-1
| / | \
| / | \
| / | \
+-----------+ +-----------+ +-----------+ +-----------+ nodes of
| | | | | | | | depth
+-----------+ +-----------+ +-----------+ +-----------+ i
Figure 7. Pruning the valid_policy_tree
6.1.4. Preparation for Certificate i+1
To prepare for processing of certificate i+1, perform the
following steps for certificate i:
(a) If a policy mappings extension is present, verify that the
special value anyPolicy does not appear as an
issuerDomainPolicy or a subjectDomainPolicy.
(b) If a policy mappings extension is present, then for each
issuerDomainPolicy ID-P in the policy mappings extension:
(1) If the policy_mapping variable is greater than 0, for each
node in the valid_policy_tree of depth i where ID-P is the
valid_policy, set expected_policy_set to the set of
subjectDomainPolicy values that are specified as
equivalent to ID-P by the policy mappings extension.
If no node of depth i in the valid_policy_tree has a
valid_policy of ID-P but there is a node of depth i with a
valid_policy of anyPolicy, then generate a child node of
the node of depth i-1 that has a valid_policy of anyPolicy
as follows:
(i) set the valid_policy to ID-P;
(ii) set the qualifier_set to the qualifier set of the
policy anyPolicy in the certificate policies
extension of certificate i; and
(iii) set the expected_policy_set to the set of
subjectDomainPolicy values that are specified as
equivalent to ID-P by the policy mappings extension.
(2) If the policy_mapping variable is equal to 0:
(i) delete each node of depth i in the valid_policy_tree
where ID-P is the valid_policy.
(ii) If there is a node in the valid_policy_tree of depth
i-1 or less without any child nodes, delete that
node. Repeat this step until there are no nodes of
depth i-1 or less without children.
(c) Assign the certificate subject name to working_issuer_name.
(d) Assign the certificate subjectPublicKey to
working_public_key.
(e) If the subjectPublicKeyInfo field of the certificate contains
an algorithm field with non-null parameters, assign the
parameters to the working_public_key_parameters variable.
If the subjectPublicKeyInfo field of the certificate contains
an algorithm field with null parameters or parameters are
omitted, compare the certificate subjectPublicKey algorithm
to the working_public_key_algorithm. If the certificate
subjectPublicKey algorithm and the
working_public_key_algorithm are different, set the
working_public_key_parameters to null.
(f) Assign the certificate subjectPublicKey algorithm to the
working_public_key_algorithm variable.
(g) If a name constraints extension is included in the
certificate, modify the permitted_subtrees and
excluded_subtrees state variables as follows:
(1) If permittedSubtrees is present in the certificate, set
the permitted_subtrees state variable to the intersection
of its previous value and the value indicated in the
extension field. If permittedSubtrees does not include a
particular name type, the permitted_subtrees state
variable is unchanged for that name type. For example,
the intersection of example.com and foo.example.com is
foo.example.com. And the intersection of example.com and
example.net is the empty set.
(2) 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. If excludedSubtrees does not include a particular
name type, the excluded_subtrees state variable is
unchanged for that name type. For example, the union of
the name spaces example.com and foo.example.com is
example.com. And the union of example.com and example.net
is both name spaces.
(h) If certificate i is not self-issued:
(1) If explicit_policy is not 0, decrement explicit_policy by
1.
(2) If policy_mapping is not 0, decrement policy_mapping by 1.
(3) If inhibit_anyPolicy is not 0, decrement inhibit_anyPolicy
by 1.
(i) 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 is less than
explicit_policy, set explicit_policy to the value of
requireExplicitPolicy.
(2) If inhibitPolicyMapping is present and is less than
policy_mapping, set policy_mapping to the value of
inhibitPolicyMapping.
(j) If the inhibitAnyPolicy extension is included in the
certificate and is less than inhibit_anyPolicy, set
inhibit_anyPolicy to the value of inhibitAnyPolicy.
(k) If certificate i is a version 3 certificate, verify that the
basicConstraints extension is present and that cA is set to
TRUE. (If certificate i is a version 1 or version 2
certificate, then the application MUST either verify that
certificate i is a CA certificate through out-of-band means
or reject the certificate. Conforming implementations may
choose to reject all version 1 and version 2 intermediate
certificates.)
(l) If the certificate was not self-issued, verify that
max_path_length is greater than zero and decrement
max_path_length by 1.
(m) If pathLenConstraint is present in the certificate and is
less than max_path_length, set max_path_length to the value
of pathLenConstraint.
(n) If a key usage extension is present, verify that the
keyCertSign bit is set.
(o) Recognize and process any other critical extension present in
the certificate. Process any other recognized non-critical
extension present in the certificate that is relevant to path
processing.
If check (a), (k), (l), (n), or (o) fails, the procedure terminates,
returning a failure indication and an appropriate reason.
If (a), (k), (l), (n), and (o) have completed successfully, increment
i and perform the basic certificate processing specified in Section
6.1.3.
6.1.5. Wrap-Up Procedure
To complete the processing of the target certificate, perform the
following steps for certificate n:
(a) If explicit_policy is not 0, decrement explicit_policy by 1.
(b) If a policy constraints extension is included in the
certificate and requireExplicitPolicy is present and has a
value of 0, set the explicit_policy state variable to 0.
(c) Assign the certificate subjectPublicKey to
working_public_key.
(d) If the subjectPublicKeyInfo field of the certificate contains
an algorithm field with non-null parameters, assign the
parameters to the working_public_key_parameters variable.
If the subjectPublicKeyInfo field of the certificate contains
an algorithm field with null parameters or parameters are
omitted, compare the certificate subjectPublicKey algorithm
to the working_public_key_algorithm. If the certificate
subjectPublicKey algorithm and the
working_public_key_algorithm are different, set the
working_public_key_parameters to null.
(e) Assign the certificate subjectPublicKey algorithm to the
working_public_key_algorithm variable.
(f) Recognize and process any other critical extension present in
the certificate n. Process any other recognized non-critical
extension present in certificate n that is relevant to path
processing.
(g) Calculate the intersection of the valid_policy_tree and the
user-initial-policy-set, as follows:
(i) If the valid_policy_tree is NULL, the intersection is
NULL.
(ii) If the valid_policy_tree is not NULL and the user-
initial-policy-set is any-policy, the intersection is
the entire valid_policy_tree.
(iii) If the valid_policy_tree is not NULL and the user-
initial-policy-set is not any-policy, calculate the
intersection of the valid_policy_tree and the user-
initial-policy-set as follows:
1. Determine the set of policy nodes whose parent nodes
have a valid_policy of anyPolicy. This is the
valid_policy_node_set.
2. If the valid_policy of any node in the
valid_policy_node_set is not in the user-initial-
policy-set and is not anyPolicy, delete this node and
all its children.
3. If the valid_policy_tree includes a node of depth n
with the valid_policy anyPolicy and the user-initial-
policy-set is not any-policy, perform the following
steps:
a. Set P-Q to the qualifier_set in the node of depth n
with valid_policy anyPolicy.
b. For each P-OID in the user-initial-policy-set that is
not the valid_policy of a node in the
valid_policy_node_set, create a child node whose
parent is the node of depth n-1 with the valid_policy
anyPolicy. Set the values in the child node as
follows: set the valid_policy to P-OID, set the
qualifier_set to P-Q, and set the expected_policy_set
to {P-OID}.
c. Delete the node of depth n with the valid_policy
anyPolicy.
4. If there is a node in the valid_policy_tree of depth
n-1 or less without any child nodes, delete that node.
Repeat this step until there are no nodes of depth n-1
or less without children.
If either (1) the value of explicit_policy variable is greater than
zero or (2) the valid_policy_tree is not NULL, then path processing
has succeeded.
6.1.6. Outputs
If path processing succeeds, the procedure terminates, returning a
success indication together with final value of the
valid_policy_tree, the working_public_key, the
working_public_key_algorithm, and the working_public_key_parameters.
6.2. Using the Path Validation Algorithm
The path validation algorithm describes the process of validating a
single certification path. While each certification path begins with
a specific trust anchor, there is no requirement that all
certification paths validated by a particular system share a single
trust anchor. The selection of one or more trusted CAs is a local
decision. A system may provide any one of its trusted CAs as the
trust anchor for a particular path. The inputs to the path
validation algorithm may be different for each path. The inputs used
to process a path may reflect application-specific requirements or
limitations in the trust accorded a particular trust anchor. For
example, a trusted CA may only be trusted for a particular certificate policy. This restriction can be expressed through the inputs to the path validation procedure. An implementation MAY augment the algorithm presented in Section 6.1 to further limit the set of valid certification paths that begin with a particular trust anchor. For example, an implementation MAY modify the algorithm to apply a path length constraint to a specific trust anchor during the initialization phase, or the application MAY require the presence of a particular alternative name form in the target certificate, or the application MAY impose requirements on application-specific extensions. Thus, the path validation algorithm presented in Section 6.1 defines the minimum conditions for a path to be considered valid. Where a CA distributes self-signed certificates to specify trust anchor information, certificate extensions can be used to specify recommended inputs to path validation. For example, a policy constraints extension could be included in the self-signed certificate to indicate that paths beginning with this trust anchor should be trusted only for the specified policies. Similarly, a name constraints extension could be included to indicate that paths beginning with this trust anchor should be trusted only for the specified name spaces. The path validation algorithm presented in Section 6.1 does not assume that trust anchor information is provided in self-signed certificates and does not specify processing rules for additional information included in such certificates. Implementations that use self-signed certificates to specify trust anchor information are free to process or ignore such information.6.3. CRL Validation
This section describes the steps necessary to determine if a certificate is revoked when CRLs are the revocation mechanism used by the certificate issuer. Conforming implementations that support CRLs are not required to implement this algorithm, but they MUST be functionally equivalent to the external behavior resulting from this procedure when processing CRLs that are issued in conformance with this profile. Any algorithm may be used by a particular implementation so long as it derives the correct result. This algorithm assumes that all of the needed CRLs are available in a local cache. Further, if the next update time of a CRL has passed, the algorithm assumes a mechanism to fetch a current CRL and place it in the local CRL cache.
This algorithm defines a set of inputs, a set of state variables, and processing steps that are performed for each certificate in the path. The algorithm output is the revocation status of the certificate.6.3.1. Revocation Inputs
To support revocation processing, the algorithm requires two inputs: (a) certificate: The algorithm requires the certificate serial number and issuer name to determine whether a certificate is on a particular CRL. The basicConstraints extension is used to determine whether the supplied certificate is associated with a CA or an end entity. If present, the algorithm uses the cRLDistributionPoints and freshestCRL extensions to determine revocation status. (b) use-deltas: This boolean input determines whether delta CRLs are applied to CRLs.6.3.2. Initialization and Revocation State Variables
To support CRL processing, the algorithm requires the following state variables: (a) reasons_mask: This variable contains the set of revocation reasons supported by the CRLs and delta CRLs processed so far. The legal members of the set are the possible revocation reason values minus unspecified: keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, privilegeWithdrawn, and aACompromise. The special value all-reasons is used to denote the set of all legal members. This variable is initialized to the empty set. (b) cert_status: This variable contains the status of the certificate. This variable may be assigned one of the following values: unspecified, keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise, the special value UNREVOKED, or the special value UNDETERMINED. This variable is initialized to the special value UNREVOKED. (c) interim_reasons_mask: This contains the set of revocation reasons supported by the CRL or delta CRL currently being processed.
Note: In some environments, it is not necessary to check all reason codes. For example, some environments are only concerned with cACompromise and keyCompromise for CA certificates. This algorithm checks all reason codes. Additional processing and state variables may be necessary to limit the checking to a subset of the reason codes.6.3.3. CRL Processing
This algorithm begins by assuming that the certificate is not revoked. The algorithm checks one or more CRLs until either the certificate status is determined to be revoked or sufficient CRLs have been checked to cover all reason codes. For each distribution point (DP) in the certificate's CRL distribution points extension, for each corresponding CRL in the local CRL cache, while ((reasons_mask is not all-reasons) and (cert_status is UNREVOKED)) perform the following: (a) Update the local CRL cache by obtaining a complete CRL, a delta CRL, or both, as required: (1) If the current time is after the value of the CRL next update field, then do one of the following: (i) If use-deltas is set and either the certificate or the CRL contains the freshest CRL extension, obtain a delta CRL with a next update value that is after the current time and can be used to update the locally cached CRL as specified in Section 5.2.4. (ii) Update the local CRL cache with a current complete CRL, verify that the current time is before the next update value in the new CRL, and continue processing with the new CRL. If use-deltas is set and either the certificate or the CRL contains the freshest CRL extension, then obtain the current delta CRL that can be used to update the new locally cached complete CRL as specified in Section 5.2.4. (2) If the current time is before the value of the next update field, use-deltas is set, and either the certificate or the CRL contains the freshest CRL extension, then obtain the current delta CRL that can be used to update the locally cached complete CRL as specified in Section 5.2.4.
(b) Verify the issuer and scope of the complete CRL as follows:
(1) If the DP includes cRLIssuer, then verify that the issuer
field in the complete CRL matches cRLIssuer in the DP and
that the complete CRL contains an issuing distribution
point extension with the indirectCRL boolean asserted.
Otherwise, verify that the CRL issuer matches the
certificate issuer.
(2) If the complete CRL includes an issuing distribution point
(IDP) CRL extension, check the following:
(i) If the distribution point name is present in the IDP
CRL extension and the distribution field is present in
the DP, then verify that one of the names in the IDP
matches one of the names in the DP. If the
distribution point name is present in the IDP CRL
extension and the distribution field is omitted from
the DP, then verify that one of the names in the IDP
matches one of the names in the cRLIssuer field of the
DP.
(ii) If the onlyContainsUserCerts boolean is asserted in
the IDP CRL extension, verify that the certificate
does not include the basic constraints extension with
the cA boolean asserted.
(iii) If the onlyContainsCACerts boolean is asserted in the
IDP CRL extension, verify that the certificate
includes the basic constraints extension with the cA
boolean asserted.
(iv) Verify that the onlyContainsAttributeCerts boolean is
not asserted.
(c) If use-deltas is set, verify the issuer and scope of the
delta CRL as follows:
(1) Verify that the delta CRL issuer matches the complete CRL
issuer.
(2) If the complete CRL includes an issuing distribution point
(IDP) CRL extension, verify that the delta CRL contains a
matching IDP CRL extension. If the complete CRL omits an
IDP CRL extension, verify that the delta CRL also omits an
IDP CRL extension.
(3) Verify that the delta CRL authority key identifier
extension matches the complete CRL authority key
identifier extension.
(d) Compute the interim_reasons_mask for this CRL as follows:
(1) If the issuing distribution point (IDP) CRL extension is
present and includes onlySomeReasons and the DP includes
reasons, then set interim_reasons_mask to the intersection
of reasons in the DP and onlySomeReasons in the IDP CRL
extension.
(2) If the IDP CRL extension includes onlySomeReasons but the
DP omits reasons, then set interim_reasons_mask to the
value of onlySomeReasons in the IDP CRL extension.
(3) If the IDP CRL extension is not present or omits
onlySomeReasons but the DP includes reasons, then set
interim_reasons_mask to the value of DP reasons.
(4) If the IDP CRL extension is not present or omits
onlySomeReasons and the DP omits reasons, then set
interim_reasons_mask to the special value all-reasons.
(e) Verify that interim_reasons_mask includes one or more reasons
that are not included in the reasons_mask.
(f) Obtain and validate the certification path for the issuer of
the complete CRL. The trust anchor for the certification
path MUST be the same as the trust anchor used to validate
the target certificate. If a key usage extension is present
in the CRL issuer's certificate, verify that the cRLSign bit
is set.
(g) Validate the signature on the complete CRL using the public
key validated in step (f).
(h) If use-deltas is set, then validate the signature on the
delta CRL using the public key validated in step (f).
(i) If use-deltas is set, then search for the certificate on the
delta CRL. If an entry is found that matches the certificate
issuer and serial number as described in Section 5.3.3, then
set the cert_status variable to the indicated reason as
follows:
(1) If the reason code CRL entry extension is present, set the
cert_status variable to the value of the reason code CRL
entry extension.
(2) If the reason code CRL entry extension is not present, set
the cert_status variable to the value unspecified.
(j) If (cert_status is UNREVOKED), then search for the
certificate on the complete CRL. If an entry is found that
matches the certificate issuer and serial number as described
in Section 5.3.3, then set the cert_status variable to the
indicated reason as described in step (i).
(k) If (cert_status is removeFromCRL), then set cert_status to
UNREVOKED.
(l) Set the reasons_mask state variable to the union of its
previous value and the value of the interim_reasons_mask
state variable.
If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)),
then the revocation status has been determined, so return
cert_status.
If the revocation status has not been determined, repeat the process
above with any available CRLs not specified in a distribution point
but issued by the certificate issuer. For the processing of such a
CRL, assume a DP with both the reasons and the cRLIssuer fields
omitted and a distribution point name of the certificate issuer.
That is, the sequence of names in fullName is generated from the
certificate issuer field as well as the certificate issuerAltName
extension. After processing such CRLs, if the revocation status has
still not been determined, then return the cert_status UNDETERMINED.
(page 95 continued on part 5)