• An intermediate certificate that asserts the following policy OIDs: OID1, OID2, and OID5. It contains mappings from OID1 to OID3 and from OID1 to OID4.
• An end-entity certificate that asserts the following policy OIDs: OID2, OID3, and OID6.

• OID1 maps to OID1
• OID1 maps to OID2
• OID2 maps to OID1
• OID2 maps to OID2

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 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 set, which may be empty if no certificate policies are valid for this path.

1. valid_policy_graph: A directed acyclic graph of certificate policies with their optional qualifiers; each of the leaves of the graph 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 graph 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 graph is set to NULL. Once the graph is set to NULL, policy processing ceases. Implementations MAY omit qualifiers if not returned in the output. Each node in the valid_policy_graph includes three data objects: the valid policy, a set of associated policy qualifiers, and a set of one or more expected policy values. Nodes in the graph can be divided into depths, numbered starting from zero. A node at depth x can have zero or more children at depth x+1 and, with the exception of depth zero, one or more parents at depth x-1. No other edges between nodes may exist. 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. It is only necessary to maintain this field if policy qualifiers are returned to the application. See Section 6.1.5, step (g).
   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_graph 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. The graph additionally satisfies the following invariants:
   • For any depth x and policy OID P-OID, there is at most one node at depth x whose valid_policy is P-OID.
   • The expected_policy_set of a node whose valid_policy is anyPolicy is always {anyPolicy}.
   • A node at depth x whose valid_policy is anyPolicy, except for the one at depth zero, always has exactly one parent: a node at depth x-1 whose valid_policy is also anyPolicy.
   • Each node at depth greater than 0 has either one or more parent nodes whose valid_policy is not anyPolicy or a single parent node whose valid_policy is anyPolicy. That is, a node cannot simultaneously be a child of both anyPolicy and some non-anyPolicy OID.
   is a graphic representation of the initial state of the valid_policy_graph. Additional figures will use this format to describe changes in the valid_policy_graph during path processing.

   Initial Value of the valid_policy_graph State Variable +----------------+ | anyPolicy | <---- valid_policy +----------------+ | {} | <---- qualifier_set +----------------+ | {anyPolicy} | <---- expected_policy_set +----------------+

4. If the certificate policies extension is present in the certificate and the valid_policy_graph 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:
      1. Let parent_nodes be the nodes at depth i-1 in the valid_policy_graph where P-OID is in the expected_policy_set. If parent_nodes is not empty, create a child node as follows: set the valid_policy to P-OID, set the qualifier_set to P-Q, set the expected_policy_set to {P-OID}, and set the parent nodes to parent_nodes. For example, consider a valid_policy_graph with a node of depth i-1 where the expected_policy_set is {Gold, White} and a second node where the expected_policy_set is {Gold, Yellow}. 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 .

         Processing an Exact Match +-----------------+ +-----------------+ | Red | | Blue | +-----------------+ +-----------------+ | {} | | {} | depth i-1 +-----------------+ +-----------------+ | {Gold, White} | | {Gold, Yellow} | +-----------------+ +-----------------+ \ / \ / \ / v v +-----------------+ | Gold | +-----------------+ | {} | depth i +-----------------+ | {Gold} | +-----------------+

      2. If there was no match in step (i) and the valid_policy_graph 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, set the expected_policy_set to {P-OID}, and set the parent node to the anyPolicy node at depth i-1. For example, consider a valid_policy_graph 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 .

         Processing Unmatched Policies When a Leaf Node Specifies anyPolicy +-----------------+ | anyPolicy | +-----------------+ | {} | +-----------------+ depth i-1 | {anyPolicy} | +-----------------+ / \ / \ / \ v v +-----------------+ +-----------------+ | Gold | | Silver | +-----------------+ +-----------------+ | {} | | {Q-Silver} | depth i +-----------------+ +-----------------+ | {Gold} | | {Silver} | +-----------------+ +-----------------+

   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 policy OID P-OID (including anyPolicy) that appears in the expected_policy_set of some node in the valid_policy_graph for depth i-1, if P-OID does not appear as the valid_policy of some node at depth i, create a single child node with the following values: set the valid_policy to P-OID, set the qualifier_set to AP-Q, set the expected_policy_set to {P-OID}, and set the parents to the nodes at depth i-1 where P-OID appears in expected_policy_set. This is equivalent to running step (1) above as if the certificate policies extension contained a policy with OID P-OID and qualifier set AP-Q. For example, consider a valid_policy_graph with a node of depth i-1 where the expected_policy_set is {Gold, Silver} and a second node of depth i-1 where the expected_policy_set is {Gold}. Assume anyPolicy appears in the certificate policies extension of certificate i with policy qualifiers AP-Q, 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 .

      Processing Unmatched Policies When the Certificate Policies Extension Specifies anyPolicy +-----------------+ +-----------------+ | Red | | Blue | +-----------------+ +-----------------+ | {} | | {} | depth i-1 +-----------------+ +-----------------+ | {Gold, Silver} | | {Gold} | +-----------------+ +-----------------+ | \ | | \ | | \ | | \ | | \ | v v v +-----------------+ +-----------------+ | Silver | | Gold | +-----------------+ +-----------------+ | {AP-Q} | | {AP-Q} | depth i +-----------------+ +-----------------+ | {Silver} | | {Gold} | +-----------------+ +-----------------+

   3. If there is a node in the valid_policy_graph 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_graph shown in 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 graph will cause the nodes at depth i-2 that is marked with a 'Y' to be deleted. In the resulting graph, there are no nodes of depth i-1 or less without children, and this step is complete.

      Pruning the valid_policy_graph +-----------+ | | depth i-3 +-----------+ / | \ / | \ v v v +-----------+ +-----------+ +-----------+ | | | | | Y | depth i-2 +-----------+ +-----------+ +-----------+ | \ | | | \ | | v v v v +-----------+ +-----------+ +-----------+ | X | | | | X | depth i-1 +-----------+ +-----------+ +-----------+ / | \ / | \ v v v +-----------+ +-----------+ +-----------+ | | | | | | depth i +-----------+ +-----------+ +-----------+

5. If the certificate policies extension is not present, set the valid_policy_graph to NULL.
6. Verify that either explicit_policy is greater than 0 or the valid_policy_graph is not equal to NULL.

2. 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 and there is a node in the valid_policy_graph 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.
   2. If the policy_mapping variable is greater than 0 and no node of depth i in the valid_policy_graph 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:
      1. set the valid_policy to ID-P;
      2. set the qualifier_set to the qualifier set of the policy anyPolicy in the certificate policies extension of certificate i; and
      3. set the expected_policy_set to the set of subjectDomainPolicy values that are specified as equivalent to ID-P by the policy mappings extension.
   3. If the policy_mapping variable is equal to 0:
      1. delete the node, if any, of depth i in the valid_policy_graph where ID-P is the valid_policy.
      2. If there is a node in the valid_policy_graph 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.

7. Calculate the user_constrained_policy_set as follows. The user_constrained_policy_set is a set of policy OIDs, along with associated policy qualifiers.
   1. If the valid_policy_graph is NULL, set valid_policy_node_set to the empty set.
   2. If the valid_policy_graph is not NULL, set valid_policy_node_set to the set of policy nodes whose valid_policy is not anyPolicy and whose parent list is a single node with valid_policy of anyPolicy.
   3. If the valid_policy_graph is not NULL and contains a node of depth n with the valid_policy anyPolicy, add it to valid_policy_node_set.
   4. Compute authority_constrained_policy_set, a set of policy OIDs and associated qualifiers as follows. For each node in valid_policy_node_set:
      1. Add the node's valid_policy to authority_constrained_policy_set.
      2. Collect all qualifiers in the node, its ancestors, and descendants and associate them with valid_policy. Applications that do not use policy qualifiers MAY skip this step to simplify processing.
   5. Set user_constrained_policy_set to authority_constrained_policy_set.
   6. If the user-initial-policy-set is not anyPolicy:
      1. Remove any elements of user_constrained_policy_set that do not appear in user-initial-policy-set.
      2. If anyPolicy appears in authority_constrained_policy_set with qualifiers AP-Q, for each OID P-OID in user-initial-policy-set that does not appear in user_constrained_policy_set, add P-OID with qualifiers AP-Q to user_constrained_policy_set.

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.

If either (1) the value of explicit_policy is greater than zero, or (2) the user_constrained_policy_set is not empty, then path processing has succeeded.

If path processing succeeds, the procedure terminates, returning a success indication together with the final value of the user_constrained_policy_set, the working_public_key, the working_public_key_algorithm, and the working_public_key_parameters. Note that the original procedure described in included a valid_policy_tree structure as part of the output. This structure grows exponentially in the size of the input, so computing it risks denial-of-service vulnerabilities in X.509-based applications, such as and . Accordingly, this output is deprecated. Computing this structure is NOT RECOMMENDED. An implementation that requires valid_policy_tree for compatibility with legacy systems may compute it from valid_policy_graph by recursively duplicating every multi-parent node. This may be done on-demand when the calling application first requests this output. However, this computation may consume exponential time and memory, so such implementations SHOULD mitigate denial-of-service attacks in other ways, such as by limiting the depth or size of the tree.

• Any application that evaluates an untrusted PKI, such as a hosting provider that evaluates a customer-supplied PKI
• Any application that evaluates an otherwise trusted PKI that includes untrusted entities with technically constrained intermediate certificates. If the intermediates do not constrain policy mapping or path length, those entities may be able to perform this attack.