rfc9618.original.xml   rfc9618.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.5 (Ruby 3.2.2 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
) --> -ietf-lamps-x509-policy-graph-05" number="9618" category="std" consensus="true"
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft submissionType="IETF" obsoletes="" updates="5280" tocInclude="true" sortRefs="tr
-ietf-lamps-x509-policy-graph-05" category="std" consensus="true" submissionType ue" symRefs="true" xml:lang="en" version="3">
="IETF" updates="5280" tocInclude="true" sortRefs="true" symRefs="true" version=
"3">
<!-- xml2rfc v2v3 conversion 3.19.1 -->
<front> <front>
<title abbrev="Updates to X.509 Policy Validation">Updates to X.509 Policy V alidation</title> <title abbrev="Updates to X.509 Policy Validation">Updates to X.509 Policy V alidation</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-x509-policy-graph- 05"/> <seriesInfo name="RFC" value="9618"/>
<author initials="D." surname="Benjamin" fullname="David Benjamin"> <author initials="D." surname="Benjamin" fullname="David Benjamin">
<organization>Google LLC</organization> <organization>Google LLC</organization>
<address> <address>
<email>davidben@google.com</email> <email>davidben@google.com</email>
</address> </address>
</author> </author>
<date year="2024" month="February" day="01"/>
<area>Security</area>
<workgroup>Limited Additional Mechanisms for PKIX and SMIME</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 57?>
<t>This document updates RFC 5280 to replace the algorithm for X.509 policy <date year="2024" month="July"/>
validation with an equivalent, more efficient algorithm. The original algorithm
built a structure which scaled exponentially in the worst case, leaving <area>sec</area>
implementations vulnerable to denial-of-service attacks.</t> <workgroup>lamps</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->
<abstract><t>This document updates RFC 5280 to replace the algorithm for
X.509 policy validation with an equivalent, more efficient algorithm. The
original algorithm built a structure that scaled exponentially in the
worst case, leaving implementations vulnerable to denial-of-service
attacks.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<t>Discussion of this document takes place on the
Limited Additional Mechanisms for PKIX and SMIME Working Group mailing list
(spasm@ietf.org),
which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/
spasm/"/>.</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/davidben/x509-policy-graph"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 64?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t><xref target="RFC5280"/> defines a suite of extensions for determining <t><xref target="RFC5280"/> defines a suite of extensions for
the "policies" which determining the policies that apply to a certification path. A policy
apply to a certification path. A policy is described by an object identifier is described by an object identifier (OID) and a set of optional
(OID), and a set of optional qualifiers.</t> qualifiers.</t>
<t>Policy validation in <xref target="RFC5280"/> is complex. As an overvie <!-- [rfced] How does "collecting the corresponding qualifiers" connect with
w, the certificate the rest of the sentence?
policies extension (<xref section="4.2.1.4" sectionFormat="of" target="RFC5280"/
>) describes the policies, Original:
with optional qualifiers, under which an individual certificate was issued. Subject to these mappings and other extensions, the certification
The policy mappings extension (<xref section="4.2.1.5" sectionFormat="of" target path's overall policy set is the intersection of policies asserted by
="RFC5280"/>) allows a each certificate in the path, collecting the corresponding
CA certificate to map its policy OIDs to other policy OIDs in certificates qualifiers.
that it issues. Subject to these mappings and other extensions, the certificatio
n Perhaps:
path's overall policy set is the intersection of policies asserted by each Subject to these mappings and other extensions, the certification
certificate in the path, collecting the corresponding qualifiers.</t> path's overall policy set is the intersection of policies asserted by
<t>The procedure in <xref section="6.1" sectionFormat="of" target="RFC5280 each certificate in the path and their corresponding
"/> determines this set in the course qualifiers.
of certification path validation. It does so by building a policy tree,
containing policies asserted by each certificate and mappings between Or:
them. This tree can grow exponentially in the depth of the certification path, Subject to these mappings and other extensions, the certification
which means an attacker, with a small input, can cause a path validator to path's overall policy set is the intersection of policies asserted by
consume excessive memory and computational resources. This cost asymmetry each certificate in the path and the collection of corresponding
can lead to a denial-of-service vulnerability in X.509-based applications, such qualifiers.
as <xref target="CVE-2023-0464"/> and <xref target="CVE-2023-23524"/>.</t> -->
<t><xref target="dos"/> describes this vulnerability. <xref target="policy
-graph"/> describes the primary <t>Policy validation in <xref target="RFC5280"/> is complex. As an
mitigation for this vulnerability, a replacement for the policy tree structure. overview, the certificate policies extension (<xref section="4.2.1.4"
<xref target="updates"/> provides updates to <xref target="RFC5280"/> which impl sectionFormat="of" target="RFC5280"/>) describes the policies, with
ement this change. optional qualifiers, under which an individual certificate was issued.
Finally, <xref target="other-mitigations"/> discusses alternative mitigation str The policy mappings extension (<xref section="4.2.1.5"
ategies for sectionFormat="of" target="RFC5280"/>) allows a CA certificate to map
X.509 applications.</t> its policy OIDs to other policy OIDs in certificates that it
issues. Subject to these mappings and other extensions, the
certification path's overall policy set is the intersection of policies
asserted by each certificate in the path, collecting the corresponding
qualifiers.</t>
<t>The procedure in <xref section="6.1" sectionFormat="of"
target="RFC5280"/> determines this set in the course of certification
path validation. It does so by building a policy tree containing
policies asserted by each certificate and the mappings between
them. This tree can grow exponentially in the depth of the certification
path, which means an attacker, with a small input, can cause a path
validator to consume excessive memory and computational resources. This
cost asymmetry can lead to a denial-of-service vulnerability in
X.509-based applications, such as <xref target="CVE-2023-0464"/> and
<xref target="CVE-2023-23524"/>.</t>
<t><xref target="dos"/> describes this vulnerability. <xref
target="policy-graph"/> describes the primary mitigation for this
vulnerability, a replacement for the policy tree structure. <xref
target="updates"/> provides updates to <xref target="RFC5280"/> that
implement this change. Finally, <xref target="other-mitigations"/>
discusses alternative mitigation strategies for X.509 applications.</t>
<section anchor="summary-of-changes-from-rfc-5280"> <section anchor="summary-of-changes-from-rfc-5280">
<name>Summary of Changes from RFC 5280</name> <name>Summary of Changes from RFC 5280</name>
<t>The algorithm for processing certificate policies and policy mappings <t>The algorithm for processing certificate policies and policy
is mappings is replaced with one that builds an equivalent but much more
replaced with one which builds an equivalent, but much more efficient structure. efficient structure. This new algorithm does not change the validity
This new algorithm does not change the validity status of any certification status of any certification path or which certificate policies are
path, nor which certificate policies are valid for it.</t> valid for it.</t>
</section> </section>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH <t>
OULD", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> < ",
xref target="RFC8174"/> "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
when, and only when, they appear in all capitals, as shown here.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
<section anchor="dos"> <section anchor="dos">
<name>Denial of Service Vulnerability</name> <name>Denial-of-Service Vulnerability</name>
<t>This section discusses how the path validation algorithm defined in <t>This section discusses how the path validation algorithm defined in
<xref section="6.1.2" sectionFormat="of" target="RFC5280"/> can lead to a denial -of-service vulnerability in <xref section="6.1.2" sectionFormat="of" target="RFC5280"/> can lead to a denial -of-service vulnerability in
X.509-based applications.</t> X.509-based applications.</t>
<section anchor="policy-trees"> <section anchor="policy-trees">
<name>Policy Trees</name> <name>Policy Trees</name>
<t><xref section="6.1.2" sectionFormat="of" target="RFC5280"/> construct <t><xref section="6.1.2" sectionFormat="of" target="RFC5280"/>
s the <tt>valid_policy_tree</tt>, a tree of constructs the <tt>valid_policy_tree</tt>, a tree of certificate
certificate policies, during certification path validation. policies, during certification path validation. The nodes at any
The nodes at any given depth in the tree correspond to given depth in the tree correspond to policies asserted by a
policies asserted by a certificate in the certification path. A node's certificate in the certification path.
parent policy is the policy in the issuer certificate which was mapped to this
policy, and a node's children are the policies it was mapped to in the subject <!-- [rfced] Will readers understand what "it" refers to here?
certificate.</t>
Original:
A node's parent policy
is the policy in the issuer certificate which was mapped to this
policy, and a node's children are the policies it was mapped to in
the subject certificate.
Perhaps:
A node's parent policy
is the policy in the issuer certificate that was mapped to this
policy, and a node's children are the policies the node
was mapped to in the subject certificate.
-->
A node's parent policy is the
policy in the issuer certificate that was mapped to this policy, and a
node's children are the policies it was mapped to in the subject
certificate.</t>
<!-- [rfced] Would it be helpful to add "from" in this sentence? Or is the
current clear?
Original:
It contains mappings OID1 to OID3, and OID1 to OID4.
Perhaps:
It contains mappings from OID1 to OID3 and from OID1 to OID4.
-->
<t>For example, suppose a certification path contains:</t> <t>For example, suppose a certification path contains:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>An intermediate certificate that asserts the following policy OID
<t>An intermediate certificate which asserts policy OIDs OID1, OID2, s: OID1, OID2,
and OID5. and OID5. It contains mappings OID1 to OID3 and OID1 to OID4.</li>
It contains mappings OID1 to OID3, and OID1 to OID4.</t> <li>An end-entity certificate that asserts the following policy OIDs:
</li> OID2, OID3,
<li> and OID6.</li>
<t>An end-entity certificate which asserts policy OIDs OID2, OID3, a
nd OID6.</t>
</li>
</ul> </ul>
<t>This would result in the tree shown in <xref target="basic-tree"/>. N <t>This would result in the tree shown below.
ote that OID5 and OID6 Note that OID5 and OID6 are not included or
are not included or mapped across the whole path, so they do not appear in the mapped across the whole path, so they do not appear in the final
final structure.</t> structure.</t>
<figure anchor="basic-tree">
<name>An Example X.509 Policy Tree</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="336" width="424" viewBox="0 0 424 336" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="336" width="424" viewBox="0 0 424 336" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 152,160 L 152,224" fill="none" stroke="black"/> <path d="M 152,160 L 152,224" fill="none" stroke="black"/>
<path d="M 152,288 L 152,320" fill="none" stroke="black"/> <path d="M 152,288 L 152,320" fill="none" stroke="black"/>
<path d="M 200,232 L 200,280" fill="none" stroke="black"/> <path d="M 200,232 L 200,280" fill="none" stroke="black"/>
<path d="M 232,32 L 232,96" fill="none" stroke="black"/> <path d="M 232,32 L 232,96" fill="none" stroke="black"/>
<path d="M 256,160 L 256,224" fill="none" stroke="black"/> <path d="M 256,160 L 256,224" fill="none" stroke="black"/>
<path d="M 256,288 L 256,320" fill="none" stroke="black"/> <path d="M 256,288 L 256,320" fill="none" stroke="black"/>
<path d="M 312,160 L 312,224" fill="none" stroke="black"/> <path d="M 312,160 L 312,224" fill="none" stroke="black"/>
<path d="M 312,288 L 312,320" fill="none" stroke="black"/> <path d="M 312,288 L 312,320" fill="none" stroke="black"/>
skipping to change at line 190 skipping to change at line 247
|{OID3, OID4}| | {OID2} | |{OID3, OID4}| | {OID2} |
+------------+ +------------+ +------------+ +------------+
| | | |
| | | |
v v v v
+------------+ +------------+ +------------+ +------------+
End-entity: | OID3 | | OID2 | End-entity: | OID3 | | OID2 |
(OID6 discarded) +------------+ +------------+ (OID6 discarded) +------------+ +------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure>
<t>The complete algorithm for building this structure is described in st <t>The complete algorithm for building this structure is described in
eps (d), steps (d), (e), and (f) in <xref section="6.1.3" sectionFormat="of"
(e), and (f) of <xref section="6.1.3" sectionFormat="of" target="RFC5280"/>, ste target="RFC5280"/>; steps (h), (i), and (j) in <xref section="6.1.4"
ps (h), (i), (j) of <xref section="6.1.4" sectionFormat="of" target="RFC5280"/>, sectionFormat="of" target="RFC5280"/>; and steps (a), (b), and (g) in
and steps (a), (b), and (g) of <xref section="6.1.5" sectionFormat="of" target= <xref section="6.1.5" sectionFormat="of" target="RFC5280"/>.</t>
"RFC5280"/>.</t>
</section> </section>
<section anchor="exponential-growth"> <section anchor="exponential-growth">
<name>Exponential Growth</name> <name>Exponential Growth</name>
<t>The <tt>valid_policy_tree</tt> grows exponentially in the worst case. <t>The <tt>valid_policy_tree</tt> grows exponentially in the worst
In case. In step (d.1) in <xref section="6.1.3" sectionFormat="of"
step (d.1) of <xref section="6.1.3" sectionFormat="of" target="RFC5280"/>, a sin target="RFC5280"/>, a single policy P can produce multiple child nodes
gle policy P can produce if multiple issuer policies map to P. This can cause the tree size to
multiple child nodes if multiple issuer policies map to P. This can cause the increase in size multiplicatively at each level.</t>
tree size to increase in size multiplicatively at each level.</t> <t>In particular, consider a certificate chain where every
<t>In particular, consider a certificate chain where every intermediate intermediate certificate asserts policies OID1 and OID2 and then
certificate contains the full Cartesian product of mappings:</t>
asserts policies OID1 and OID2, and then contains the full Cartesian product of
mappings:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>OID1 maps to OID1</t> <t>OID1 maps to OID1</t>
</li> </li>
<li> <li>
<t>OID1 maps to OID2</t> <t>OID1 maps to OID2</t>
</li> </li>
<li> <li>
<t>OID2 maps to OID1</t> <t>OID2 maps to OID1</t>
</li> </li>
skipping to change at line 383 skipping to change at line 444
v v v v v v v v v v v v v v v v
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| OID1 | | OID2 | | OID1 | | OID2 | | OID1 | | OID2 | | OID1 | | OID2 | | OID1 | | OID2 | | OID1 | | OID2 | | OID1 | | OID2 | | OID1 | | OID2 |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="attack-vector"> <section anchor="attack-vector">
<name>Attack Vector</name> <name>Attack Vector</name>
<t>An attacker can use the exponential growth to mount a denial-of-servi <!-- [rfced] May we update "preventing it" as follows for clarity? The pronoun
ce attack against "it" is used once before in the sentence to refer to something else.
an X.509-based application. The attacker sends certificate chain as in <xref tar
get="exponential-growth"/> and Original:
triggers the target application's certificate validation process. For example, The target application will
the target application may be a TLS <xref target="RFC8446"/> server that perform consume far more resources processing the input than the attacker
s client consumed to send it, preventing it from servicing other clients.
certificate validation. The target
application will consume far more resources processing the input than the Perhaps:
attacker consumed to send it, preventing it from servicing other clients.</t> The target application will
consume far more resources processing the input than the attacker
consumed to send it, which prevents the target application from
servicing other clients.
-->
<t>An attacker can use the exponential growth to mount a
denial-of-service attack against an X.509-based application. The
attacker sends a certificate chain as described in <xref
target="exponential-growth"/> and triggers the target application's
certificate validation process. For example, the target application
may be a TLS server <xref target="RFC8446"/> that performs client
certificate validation. The target application will consume far more
resources processing the input than the attacker consumed to send it,
preventing it from servicing other clients.</t>
</section> </section>
</section> </section>
<section anchor="avoiding-exponential-growth"> <section anchor="avoiding-exponential-growth">
<name>Avoiding Exponential Growth</name> <name>Avoiding Exponential Growth</name>
<t>This document mitigates the denial-of-service vulnerability described i <t>This document mitigates the denial-of-service vulnerability
n <xref target="dos"/> described in <xref target="dos"/> by replacing the policy tree with a
by replacing the policy tree with a policy graph structure, described in this policy graph structure, which is described in this section. The policy gra
section. The policy graph grows linearly instead of exponentially. This removes ph grows
the asymmetric cost in policy validation.</t> linearly instead of exponentially. This removes the asymmetric cost in
<t>X.509 implementations SHOULD perform policy validation by building a po policy validation.</t>
licy <t>X.509 implementations <bcp14>SHOULD</bcp14> perform policy validation
graph, following the procedure described in <xref target="updates"/>. This repla by building a policy graph, following the procedure described in <xref
cement target="updates"/>. This replacement procedure computes the same
procedure computes the same policies as in <xref target="RFC5280"/>, however one policies as in <xref target="RFC5280"/>, but one of the outputs is in a
of the different form. See <xref target="outputs"/> for details. <xref
outputs is in a different form. See <xref target="outputs"/> for details. target="other-mitigations"/> describes alternative mitigations for
<xref target="other-mitigations"/> describes alternative mitigations for impleme implementations that depend on the original, exponential-sized
ntations that output.</t>
depend on the original, exponential-sized output.</t>
<section anchor="policy-graph"> <section anchor="policy-graph">
<name>Policy Graphs</name> <name>Policy Graphs</name>
<t>The tree structure from <xref target="RFC5280"/> is an unnecessarily <!-- [rfced] FYI - We updated "Where [RFC5280] adds multiple duplicate nodes"
inefficient in this sentence as follows. Please let us know any concerns.
representation of a certification path's policy mappings. A single certificate
policy may correspond to multiple nodes, but each node is identical, with identi Original:
cal Where [RFC5280] adds multiple duplicate nodes, a policy graph adds a single
children. This redundancy is the source of the exponential growth described in node with multiple parents.
<xref target="exponential-growth"/>.</t>
<t>A policy graph is a directed acyclic graph of policy nodes. Updated:
Where <xref target="RFC5280"/> adds multiple duplicate nodes, a policy graph add The policy tree in [RFC5280] adds multiple duplicate nodes, but a policy
s a single node with multiple parents. graph adds a single node with multiple parents.
See <xref target="updates"/> for the procedure for building this structure. -->
<xref target="exponential-tree-as-graph"/> shows the updated representation of t
he example in <xref target="exponential-tree"/>.</t> <t>The tree structure in <xref target="RFC5280"/> is an
unnecessarily inefficient representation of a certification path's
policy mappings. A single certificate policy may correspond to
multiple nodes, but each node is identical, with identical
children. This redundancy is the source of the exponential growth
described in <xref target="exponential-growth"/>.</t>
<t>A policy graph is a directed acyclic graph of policy nodes. The
policy tree in <xref target="RFC5280"/> adds multiple duplicate nodes,
but a policy graph adds a single node with multiple parents. See
<xref target="updates"/> for the procedure for building this
structure. <xref target="exponential-tree-as-graph"/> shows the
updated representation of the example in <xref
target="exponential-tree"/>.</t>
<figure anchor="exponential-tree-as-graph"> <figure anchor="exponential-tree-as-graph">
<name>A More Efficient Representation of an X.509 Policy Tree</name> <name>A More Efficient Representation of an X.509 Policy Tree</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="576" width="248" viewBox="0 0 248 576" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version= "1.1" height="576" width="248" viewBox="0 0 248 576" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 8,160 L 8,224" fill="none" stroke="black"/> <path d="M 8,160 L 8,224" fill="none" stroke="black"/>
<path d="M 8,336 L 8,400" fill="none" stroke="black"/> <path d="M 8,336 L 8,400" fill="none" stroke="black"/>
<path d="M 8,512 L 8,544" fill="none" stroke="black"/> <path d="M 8,512 L 8,544" fill="none" stroke="black"/>
<path d="M 48,232 L 48,328" fill="none" stroke="black"/> <path d="M 48,232 L 48,328" fill="none" stroke="black"/>
<path d="M 48,408 L 48,504" fill="none" stroke="black"/> <path d="M 48,408 L 48,504" fill="none" stroke="black"/>
<path d="M 80,32 L 80,96" fill="none" stroke="black"/> <path d="M 80,32 L 80,96" fill="none" stroke="black"/>
skipping to change at line 529 skipping to change at line 626
| \/ | | \/ |
| /\ | | /\ |
| / \ | | / \ |
v v v v v v v v
+------------+ +------------+ +------------+ +------------+
| OID1 | | OID2 | | OID1 | | OID2 |
+------------+ +------------+ +------------+ +------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>This graph's size is bounded linearly by the total number of certific <t>This graph's size is bounded linearly by the total number of
ate certificate policies (<xref section="4.2.1.4" sectionFormat="of"
policies (<xref section="4.2.1.4" sectionFormat="of" target="RFC5280"/>) and pol target="RFC5280"/>) and policy mappings (<xref section="4.2.1.5"
icy mappings (<xref section="4.2.1.5" sectionFormat="of" target="RFC5280"/>). Th sectionFormat="of" target="RFC5280"/>). The policy tree in <xref
e policy tree from <xref target="RFC5280"/> is the tree of all paths from the ro target="RFC5280"/> is the tree of all paths from the root to a leaf in
ot to a leaf in the policy graph, the policy graph, so no information is lost in the graph
so no information is lost in the graph representation.</t> representation.</t>
</section> </section>
<section anchor="outputs"> <section anchor="outputs">
<name>Verification Outputs</name> <name>Verification Outputs</name>
<t><xref section="6.1.6" sectionFormat="of" target="RFC5280"/> describes <!-- [rfced] How may we update "Section 12.2 of [X.509] instead only outputs"
the entire <tt>valid_policy_tree</tt> structure as to avoid personification of the section? That is, instead of "Section
an output of the verification process. Section 12.2 of <xref target="X.509"/> in 12.2 ... outputs", perhaps the sentence can be updated to note that Section 12.2
stead only describes the outputs (or something similar)?
outputs the authorities-constrained policies, the user-constrained policies,
and their associated qualifiers.</t> Original:
<t>As the <tt>valid_policy_tree</tt> is the exponential structure, compu Section 12.2 of
ting it [X.509] instead only outputs the authorities-constrained policies,
reintroduces the denial-of-service vulnerability. X.509 implementations the user-constrained policies, and their associated qualifiers.
SHOULD NOT output the entire <tt>valid_policy_tree</tt> structure and instead SH
OULD Perhaps:
limit output to just the set of authorities-constrained and/or user-constrained However, Section 12.2 of
policies, as described in <xref target="X.509"/>. <xref target="update-outputs"/ [X.509] only describes the following as outputs: the authorities-constrained
> and policies,
<xref target="other-mitigations"/> discuss other mitigations for applications wh the user-constrained policies, and their associated qualifiers.
ere this -->
option is not available.</t>
<t>X.509 implementations MAY omit policy qualifiers from the output to s <t><xref section="6.1.6" sectionFormat="of" target="RFC5280"/>
implify describes the entire <tt>valid_policy_tree</tt> structure as an output
processing. Note <xref section="4.2.1.4" sectionFormat="of" target="RFC5280"/> a of the verification process. Section 12.2 of <xref target="X.509"/>
lready recommends that instead only outputs the authorities-constrained policies, the
certification authorities omit policy qualifiers from policy information terms.< user-constrained policies, and their associated qualifiers.</t>
/t> <t>As the <tt>valid_policy_tree</tt> is the exponential structure,
computing it reintroduces the denial-of-service vulnerability. X.509
implementations <bcp14>SHOULD NOT</bcp14> output the entire
<tt>valid_policy_tree</tt> structure; instead, they
<bcp14>SHOULD</bcp14> limit output to just the set of
authorities-constrained and/or user-constrained policies, as described
in <xref target="X.509"/>. Sections <xref target="update-outputs"
format="counter"/> and <xref target="other-mitigations"
format="counter"/> discuss other mitigations for applications where
this option is not available.</t>
<t>X.509 implementations <bcp14>MAY</bcp14> omit policy qualifiers
from the output to simplify processing. Note that <xref section="4.2.1.4
"
sectionFormat="of" target="RFC5280"/> already recommends that
certification authorities omit policy qualifiers from policy
information terms.</t>
</section> </section>
</section> </section>
<section anchor="updates"> <section anchor="updates">
<name>Updates to RFC 5280</name> <name>Updates to RFC 5280</name>
<t>This section provides updates to <xref target="RFC5280"/>. This impleme nts the changes <t>This section provides updates to <xref target="RFC5280"/>. These update s implement the changes
described in <xref target="avoiding-exponential-growth"/>.</t> described in <xref target="avoiding-exponential-growth"/>.</t>
<section anchor="updates-to-section-61"> <section anchor="updates-to-section-61">
<name>Updates to Section 6.1</name> <name>Updates to Section 6.1</name>
<t>This update replaces a paragraph of <xref section="6.1" sectionFormat ="of" target="RFC5280"/> as follows:</t> <t><xref section="6.1" sectionFormat="of" target="RFC5280"/> is updated as follows:</t>
<t>OLD:</t> <t>OLD:</t>
<ul empty="true">
<li> <blockquote><t>A particular certification path may not, however, be
<t>A particular certification path may not, however, be appropriate appropriate for all applications. Therefore, an application
for <bcp14>MAY</bcp14> augment this algorithm to further limit the set of
all applications. Therefore, an application MAY augment this valid paths. The path validation process also determines the set of
algorithm to further limit the set of valid paths. The path certificate policies that are valid for this path, based on the
validation process also determines the set of certificate policies certificate policies extension, policy mappings extension, policy
that are valid for this path, based on the certificate policies constraints extension, and inhibit anyPolicy extension. To achieve
extension, policy mappings extension, policy constraints extension, this, the path validation algorithm constructs a valid policy tree.
and inhibit anyPolicy extension. To achieve this, the path If the set of certificate policies that are valid for this path is not
validation algorithm constructs a valid policy tree. If the set of empty, then the result will be a valid policy tree of depth n,
certificate policies that are valid for this path is not empty, then otherwise the result will be a null valid policy
the result will be a valid policy tree of depth n, otherwise the tree.</t></blockquote>
result will be a null valid policy tree.</t>
</li>
</ul>
<t>NEW:</t> <t>NEW:</t>
<ul empty="true">
<li> <blockquote><t>A particular certification path may not, however, be
<t>A particular certification path may not, however, be appropriate appropriate for all applications. Therefore, an application
for <bcp14>MAY</bcp14> augment this algorithm to further limit the set of
all applications. Therefore, an application MAY augment this valid paths. The path validation process also determines the set of
algorithm to further limit the set of valid paths. The path certificate policies that are valid for this path, based on the
validation process also determines the set of certificate policies certificate policies extension, policy mappings extension, policy
that are valid for this path, based on the certificate policies constraints extension, and inhibit anyPolicy extension. To achieve
extension, policy mappings extension, policy constraints extension, this, the path validation algorithm constructs a valid policy set,
and inhibit anyPolicy extension. To achieve this, the path which may be empty if no certificate policies are valid for this
validation algorithm constructs a valid policy set, which may be empty if path.</t></blockquote>
no certificate policies are valid for this path.</t>
</li>
</ul>
</section> </section>
<!-- [rfced] In the RFC Series, we use the <blockquote> element for OLD and
NEW text in documents that update another. We noticed a bug in the txt
output when we added <blockquote> to Sections 5.2-5.5, and we opened the
following issue:
https://github.com/ietf-tools/xml2rfc/issues/1148
We will publish this document once this issue has been resolved.
-->
<!-- [rfced] FYI - The replacement text in Sections 5.2 and 5.3 in this
document contains figures. The numbering of the figures in the
replacement text doesn’t match up with the numbering of the corresponding
figures in RFC 5280. Unfortunately, xml2rfc does not allow us to adjust
figure numbers. To align the figure numbers, we removed the figure number
from the original Figure 1. We feel this is the best option, but please
let us know any concerns.
-->
<section anchor="updates-to-section-612"> <section anchor="updates-to-section-612">
<name>Updates to Section 6.1.2</name> <name>Updates to Section 6.1.2</name>
<t>This update replaces entry (a) of <xref section="6.1.2" sectionFormat <t>The following replaces entry (a) in <xref section="6.1.2"
="of" target="RFC5280"/> with the following text:</t> sectionFormat="of" target="RFC5280"/>:
</t>
<blockquote>
<ol spacing="normal" type="(%c)"><li> <ol spacing="normal" type="(%c)"><li>
<t><tt>valid_policy_graph</tt>: A directed acyclic graph of certifi <t><tt>valid_policy_graph</tt>: A directed acyclic graph of
cate certificate policies with their optional qualifiers; each of the
policies with their optional qualifiers; each of the leaves leaves of the graph represents a valid policy at this stage in the
of the graph represents a valid policy at this stage in the certification path validation. If valid policies exist at this
certification path validation. If valid policies exist at stage in the certification path validation, the depth of the graph
this stage in the certification path validation, the depth of is equal to the number of certificates in the chain that have been
the graph is equal to the number of certificates in the chain processed. If valid policies do not exist at this stage in the
that have been processed. If valid policies do not exist at certification path validation, the graph is set to NULL. Once the
this stage in the certification path validation, the graph is graph is set to NULL, policy processing ceases. Implementations
set to NULL. Once the graph is set to NULL, policy processing <bcp14>MAY</bcp14> omit qualifiers if not returned in the output.
ceases. Implementations MAY omit qualifiers if not returned </t>
in the output. </t> <t>Each node in the <tt>valid_policy_graph</tt> includes three
<t> data objects: the valid policy, a set of associated policy
Each node in the <tt>valid_policy_graph</tt> includes three data objects: qualifiers, and a set of one or more expected policy values. </t>
the valid policy, a set of associated policy qualifiers, and a set of
one or more expected policy values. </t> <t>Nodes in the graph can be divided into depths, numbered
<t> starting from zero. A node at depth x can have zero or more
Nodes in the graph can be divided into depths, numbered starting from zero. children at depth x+1 and, with the exception of depth zero, one
A node at depth x can have zero or more children at depth x+1 and, with the or more parents at depth x-1. No other edges between nodes may
exception of depth zero, one or more parents at depth x-1. No other edges exist. </t>
between nodes may exist. </t> <t>If the node is at depth x, the components of the node have the
<t> following semantics: </t>
If the node is at depth x, the components of the node have
the following semantics: </t>
<ol spacing="normal" type="(%d)"><li> <ol spacing="normal" type="(%d)"><li>
<t>The <tt>valid_policy</tt> is a single policy OID representing <t>The <tt>valid_policy</tt> is a single policy OID
a valid policy for the path of length x.</t> representing a valid policy for the path of length x.</t>
</li> </li>
<li> <li>
<t>The <tt>qualifier_set</tt> is a set of policy qualifiers asso <t>The <tt>qualifier_set</tt> is a set of policy qualifiers
ciated with the valid policy in certificate x. associated with the valid policy in certificate x. It is only
It is only necessary to maintain this field if policy qualifiers are returned to necessary to maintain this field if policy qualifiers are
the application. returned to the application. See Section 6.1.5, step (g).</t>
See Section 6.1.5, step (g).</t>
</li> </li>
<li> <li>
<t>The <tt>expected_policy_set</tt> contains one or more policy <t>The <tt>expected_policy_set</tt> contains one or more
OIDs that would satisfy this policy in the certificate x+1.</t> policy OIDs that would satisfy this policy in the certificate
x+1.</t>
</li> </li>
</ol> </ol>
<t>
The initial value of the <tt>valid_policy_graph</tt> is a single node with <t>The initial value of the <tt>valid_policy_graph</tt> is a
<tt>valid_policy</tt> anyPolicy, an empty <tt>qualifier_set</tt>, and an single node with <tt>valid_policy</tt> anyPolicy, an empty
<tt>expected_policy_set</tt> with the single value anyPolicy. This node is <tt>qualifier_set</tt>, and an <tt>expected_policy_set</tt> with
considered to be at depth zero. </t> the single value anyPolicy. This node is considered to be at
<t> depth zero. </t>
The graph additionally satisfies the following invariants: </t> <t>The graph additionally satisfies the following invariants: </t>
<!-- [rfced] Please review "policy OID P-OID" and "OID P-OID" in the sentences
below. Are these redundant? Let us know if any updates are needed or if
the current is correct.
Original:
* For any depth x and policy OID P-OID, there is at most one
node at depth x whose valid_policy is P-OID.
....
For each policy OID P-OID (including anyPolicy) which
appears in the expected_policy_set of some node in the
valid_policy_graph for depth i-1,
....
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.
....
(ii) If anyPolicy appears in
authority_constrained_policy_set with qualifiers AP-
Q, for each OID P-OID in user-initial-policy-set
which does not appear in user_constrained_policy_set,
add P-OID with qualifiers AP-Q to
user_constrained_policy_set.
Perhaps:
* For any depth x and P-OID (OID for policy P), there is at most one
node at depth x whose valid_policy is P-OID.
...
For each P-OID (including anyPolicy) that
appears in the expected_policy_set of some node in the
valid_policy_graph for depth i-1,
....
This is equivalent to running step (1) above, as if the
certificate policies extension contained a policy with
P-OID and qualifier set AP-Q.
....
(ii) If anyPolicy appears in
authority_constrained_policy_set with qualifiers AP-
Q, for each 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.
-->
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>For any depth x and policy OID P-OID, there is at most one no <t>For any depth x and policy OID P-OID, there is at most one
de at depth x whose <tt>valid_policy</tt> is P-OID.</t> node at depth x whose <tt>valid_policy</tt> is P-OID.</t>
</li> </li>
<li> <li>
<t>The <tt>expected_policy_set</tt> of a node whose <tt>valid_po <t>The <tt>expected_policy_set</tt> of a node whose
licy</tt> is anyPolicy is always {anyPolicy}.</t> <tt>valid_policy</tt> is anyPolicy is always {anyPolicy}.</t>
</li> </li>
<li> <li>
<t>A node at depth x whose <tt>valid_policy</tt> is anyPolicy, e <t>A node at depth x whose <tt>valid_policy</tt> is anyPolicy,
xcept for the one at except for the one at depth zero, always has exactly one
depth zero, always has exactly one parent: a node at depth x-1 whose parent: a node at depth x-1 whose <tt>valid_policy</tt> is
<tt>valid_policy</tt> is also anyPolicy.</t> also anyPolicy.</t>
</li> </li>
<li> <li>
<t>Each node at depth greater than 0 has either one or more pare <t>Each node at depth greater than 0 has either one or more
nt nodes whose <tt>valid_policy</tt> is not anyPolicy, parent nodes whose <tt>valid_policy</tt> is not anyPolicy or
or a single parent node whose <tt>valid_policy</tt> is anyPolicy. a single parent node whose <tt>valid_policy</tt> is anyPolicy.
That is, a node cannot simultaneously be a child of both anyPolicy and some non- That is, a node cannot simultaneously be a child of both
anyPolicy OID.</t> anyPolicy and some non-anyPolicy OID.</t>
</li> </li>
</ul> </ul>
<t> <t><xref target="graph-initial"/> is a graphic representation of
<xref target="graph-initial"/> is a graphic representation of the initial state the initial state of the <tt>valid_policy_graph</tt>. Additional
of the figures will use this format to describe changes in the
<tt>valid_policy_graph</tt>. Additional figures will use this format to <tt>valid_policy_graph</tt> during path processing. </t>
describe changes in the <tt>valid_policy_graph</tt> during path processing. </t
>
<figure anchor="graph-initial"> <figure anchor="graph-initial">
<name>Initial value of the valid_policy_graph State Variable</name > <name>Initial Value of the valid_policy_graph State Variable</name >
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" vers ion="1.1" height="160" width="376" viewBox="0 0 376 160" class="diagram" text-an chor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" vers ion="1.1" height="160" width="376" viewBox="0 0 376 160" class="diagram" text-an chor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 8,32 L 8,128" fill="none" stroke="black"/> <path d="M 8,32 L 8,128" fill="none" stroke="black"/>
<path d="M 144,32 L 144,128" fill="none" stroke="black"/> <path d="M 144,32 L 144,128" fill="none" stroke="black"/>
<path d="M 8,32 L 144,32" fill="none" stroke="black"/> <path d="M 8,32 L 144,32" fill="none" stroke="black"/>
<path d="M 176,48 L 208,48" fill="none" stroke="black"/> <path d="M 176,48 L 208,48" fill="none" stroke="black"/>
<path d="M 8,64 L 144,64" fill="none" stroke="black"/> <path d="M 8,64 L 144,64" fill="none" stroke="black"/>
<path d="M 176,80 L 208,80" fill="none" stroke="black"/> <path d="M 176,80 L 208,80" fill="none" stroke="black"/>
<path d="M 8,96 L 144,96" fill="none" stroke="black"/> <path d="M 8,96 L 144,96" fill="none" stroke="black"/>
<path d="M 176,112 L 208,112" fill="none" stroke="black"/> <path d="M 176,112 L 208,112" fill="none" stroke="black"/>
skipping to change at line 696 skipping to change at line 890
+----------------+ +----------------+
| {} | <---- qualifier_set | {} | <---- qualifier_set
+----------------+ +----------------+
| {anyPolicy} | <---- expected_policy_set | {anyPolicy} | <---- expected_policy_set
+----------------+ +----------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</li> </li>
</ol> </ol>
</blockquote>
</section> </section>
<section anchor="updates-to-section-613"> <section anchor="updates-to-section-613">
<name>Updates to Section 6.1.3</name> <name>Updates to Section 6.1.3</name>
<t>This update replaces steps (d), (e), and (f) of <xref section="6.1.3" <t>The following replaces steps (d), (e), and (f) in <xref
sectionFormat="of" target="RFC5280"/> with the following text:</t> section="6.1.3" sectionFormat="of" target="RFC5280"/>:
</t>
<blockquote>
<ol spacing="normal" type="(%c)" start="4"><li> <ol spacing="normal" type="(%c)" start="4"><li>
<t>If the certificate policies extension is present in the <t>If the certificate policies extension is present in the
certificate and the <tt>valid_policy_graph</tt> is not NULL, process certificate and the <tt>valid_policy_graph</tt> is not NULL,
the policy information by performing the following steps in process the policy information by performing the following steps
order: </t> in order: </t>
<ol spacing="normal" type="(%d)"><li> <ol spacing="normal" type="(%d)"><li>
<t>For each policy P not equal to anyPolicy in the certificate p <t>For each policy P not equal to anyPolicy in the certificate
olicies extension, policies extension, let P-OID denote the OID for policy P and
let P-OID denote the OID for policy P and P-Q denote the qualifier set for polic P-Q denote the qualifier set for policy P. Perform the
y P. following steps in order: </t>
Perform the following steps in order: </t>
<ol spacing="normal" type="(%i)"><li> <ol spacing="normal" type="(%i)"><li>
<t>Let <tt>parent_nodes</tt> be the nodes at depth i-1 in th <t>Let <tt>parent_nodes</tt> be the nodes at depth i-1 in
e <tt>valid_policy_graph</tt> where P-OID is in the <tt>expected_policy_set</tt> the <tt>valid_policy_graph</tt> where P-OID is in the
. <tt>expected_policy_set</tt>. If <tt>parent_nodes</tt> is
If <tt>parent_nodes</tt> is not empty, create a child node as follows: not empty, create a child node as follows: set the
set the <tt>valid_policy</tt> to P-OID, set the <tt>qualifier_set</tt> to P-Q, s <tt>valid_policy</tt> to P-OID, set the
et the <tt>expected_policy_set</tt> to {P-OID}, and set the parent nodes to <tt> <tt>qualifier_set</tt> to P-Q, set the
parent_nodes</tt>. </t> <tt>expected_policy_set</tt> to {P-OID}, and set the
<t> parent nodes to <tt>parent_nodes</tt>. </t>
For example, consider a <tt>valid_policy_graph</tt> with a node of depth i-1 whe <t>For example, consider a <tt>valid_policy_graph</tt>
re the <tt>expected_policy_set</tt> is {Gold, White}, with a node of depth i-1 where the
and a second node where the <tt>expected_policy_set</tt> is {Gold, Yellow}. <tt>expected_policy_set</tt> is {Gold, White} and a
Assume the certificate policies Gold and Silver appear in the certificate polici second node where the <tt>expected_policy_set</tt> is
es extension of certificate i. {Gold, Yellow}. Assume the certificate policies Gold and
The Gold policy is matched, but the Silver policy is not. Silver appear in the certificate policies extension of
This rule will generate a child node of depth i for the Gold policy. certificate i. The Gold policy is matched, but the Silver
The result is shown as <xref target="exact-match"/>. </t> policy is not. This rule will generate a child node of
depth i for the Gold policy. The result is shown as <xref
target="exact-match"/>. </t>
<figure anchor="exact-match"> <figure anchor="exact-match">
<name>Processing an Exact Match</name> <name>Processing an Exact Match</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/s vg" version="1.1" height="336" width="456" viewBox="0 0 456 336" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="r ound"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/s vg" version="1.1" height="336" width="456" viewBox="0 0 456 336" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="r ound">
<path d="M 8,32 L 8,128" fill="none" stroke="black"/ > <path d="M 8,32 L 8,128" fill="none" stroke="black"/ >
<path d="M 112,208 L 112,304" fill="none" stroke="bl ack"/> <path d="M 112,208 L 112,304" fill="none" stroke="bl ack"/>
<path d="M 152,32 L 152,128" fill="none" stroke="bla ck"/> <path d="M 152,32 L 152,128" fill="none" stroke="bla ck"/>
<path d="M 208,32 L 208,128" fill="none" stroke="bla ck"/> <path d="M 208,32 L 208,128" fill="none" stroke="bla ck"/>
<path d="M 256,208 L 256,304" fill="none" stroke="bl ack"/> <path d="M 256,208 L 256,304" fill="none" stroke="bl ack"/>
<path d="M 352,32 L 352,128" fill="none" stroke="bla ck"/> <path d="M 352,32 L 352,128" fill="none" stroke="bla ck"/>
skipping to change at line 766 skipping to change at line 973
<text x="312" y="116">Yellow}</text> <text x="312" y="116">Yellow}</text>
<text x="180" y="228">Gold</text> <text x="180" y="228">Gold</text>
<text x="180" y="260">{}</text> <text x="180" y="260">{}</text>
<text x="304" y="260">depth</text> <text x="304" y="260">depth</text>
<text x="336" y="260">i</text> <text x="336" y="260">i</text>
<text x="180" y="292">{Gold}</text> <text x="180" y="292">{Gold}</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art"><![CDATA[
+-----------------+ +-----------------+ +-----------------+ +-----------------+
| Red | | Blue | | Red | | Blue |
+-----------------+ +-----------------+ +-----------------+ +-----------------+
| {} | | {} | depth i-1 | {} | | {} | depth i-1
+-----------------+ +-----------------+ +-----------------+ +-----------------+
| {Gold, White} | | {Gold, Yellow} | | {Gold, White} | | {Gold, Yellow} |
+-----------------+ +-----------------+ +-----------------+ +-----------------+
\ / \ /
\ / \ /
\ / \ /
v v v v
+-----------------+ +-----------------+
| Gold | | Gold |
+-----------------+ +-----------------+
| {} | depth i | {} | depth i
+-----------------+ +-----------------+
| {Gold} | | {Gold} |
+-----------------+ +-----------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</li> </li>
<li> <li>
<t>If there was no match in step (i) and the <tt>valid_polic <t>If there was no match in step (i) and the
y_graph</tt> includes a node of depth i-1 with the <tt>valid_policy</tt> anyPoli <tt>valid_policy_graph</tt> includes a node of depth i-1
cy, with the <tt>valid_policy</tt> anyPolicy, generate a child
generate a child node with the following values: node with the following values: set the
set the <tt>valid_policy</tt> to P-OID, set the <tt>qualifier_set</tt> to P-Q, s <tt>valid_policy</tt> to P-OID, set the
et the <tt>expected_policy_set</tt> to {P-OID}, <tt>qualifier_set</tt> to P-Q, set the
and set the parent node to the anyPolicy node at depth i-1. </t> <tt>expected_policy_set</tt> to {P-OID}, and set the
<t> parent node to the anyPolicy node at depth i-1. </t>
For example, consider a <tt>valid_policy_graph</tt> with a node <t>For example, consider a <tt>valid_policy_graph</tt>
of depth i-1 where the <tt>valid_policy</tt> is anyPolicy. with a node of depth i-1 where the <tt>valid_policy</tt>
Assume the certificate policies Gold and Silver appear is anyPolicy. Assume the certificate policies Gold and
in the certificate policies extension of certificate Silver appear in the certificate policies extension of
i. The Gold policy does not have a qualifier, but the certificate i. The Gold policy does not have a qualifier,
Silver policy has the qualifier Q-Silver. If Gold and but the Silver policy has the qualifier Q-Silver. If Gold
Silver were not matched in (i) above, this rule will and Silver were not matched in (i) above, this rule will
generate two child nodes of depth i, one for each generate two child nodes of depth i, one for each policy.
policy. The result is shown as <xref target="unmatched-anypolicy"/>. < The result is shown as <xref
/t> target="unmatched-anypolicy"/>. </t>
<figure anchor="unmatched-anypolicy"> <figure anchor="unmatched-anypolicy">
<name>Processing Unmatched Policies when a Leaf Node Speci fies anyPolicy</name> <name>Processing Unmatched Policies When a Leaf Node Speci fies anyPolicy</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/s vg" version="1.1" height="336" width="472" viewBox="0 0 472 336" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="r ound"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/s vg" version="1.1" height="336" width="472" viewBox="0 0 472 336" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="r ound">
<path d="M 8,208 L 8,304" fill="none" stroke="black" /> <path d="M 8,208 L 8,304" fill="none" stroke="black" />
<path d="M 120,32 L 120,128" fill="none" stroke="bla ck"/> <path d="M 120,32 L 120,128" fill="none" stroke="bla ck"/>
<path d="M 152,208 L 152,304" fill="none" stroke="bl ack"/> <path d="M 152,208 L 152,304" fill="none" stroke="bl ack"/>
<path d="M 240,208 L 240,304" fill="none" stroke="bl ack"/> <path d="M 240,208 L 240,304" fill="none" stroke="bl ack"/>
<path d="M 264,32 L 264,128" fill="none" stroke="bla ck"/> <path d="M 264,32 L 264,128" fill="none" stroke="bla ck"/>
<path d="M 384,208 L 384,304" fill="none" stroke="bl ack"/> <path d="M 384,208 L 384,304" fill="none" stroke="bl ack"/>
<path d="M 120,32 L 264,32" fill="none" stroke="blac k"/> <path d="M 120,32 L 264,32" fill="none" stroke="blac k"/>
<path d="M 120,64 L 264,64" fill="none" stroke="blac k"/> <path d="M 120,64 L 264,64" fill="none" stroke="blac k"/>
skipping to change at line 847 skipping to change at line 1058
<text x="76" y="260">{}</text> <text x="76" y="260">{}</text>
<text x="308" y="260">{Q-Silver}</text> <text x="308" y="260">{Q-Silver}</text>
<text x="432" y="260">depth</text> <text x="432" y="260">depth</text>
<text x="464" y="260">i</text> <text x="464" y="260">i</text>
<text x="76" y="292">{Gold}</text> <text x="76" y="292">{Gold}</text>
<text x="308" y="292">{Silver}</text> <text x="308" y="292">{Silver}</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art"><![CDATA[
+-----------------+ +-----------------+
| anyPolicy | | anyPolicy |
+-----------------+ +-----------------+
| {} | | {} |
+-----------------+ depth i-1 +-----------------+ depth i-1
| {anyPolicy} | | {anyPolicy} |
+-----------------+ +-----------------+
/ \ / \
/ \ / \
/ \ / \
v v v v
+-----------------+ +-----------------+ +-----------------+ +-----------------+
| Gold | | Silver | | Gold | | Silver |
+-----------------+ +-----------------+ +-----------------+ +-----------------+
| {} | | {Q-Silver} | depth i | {} | | {Q-Silver} | depth i
+-----------------+ +-----------------+ +-----------------+ +-----------------+
| {Gold} | | {Silver} | | {Gold} | | {Silver} |
+-----------------+ +-----------------+ +-----------------+ +-----------------+
]]></artwork> ]]></artwork>
-----------------+ +-----------------+
</artset> </artset>
</figure> </figure>
</li> </li>
</ol> </ol>
</li> </li>
<li> <li>
<t>If the certificate policies extension includes the policy any <t>If the certificate policies extension includes the policy
Policy with the qualifier set AP-Q and either (a) anyPolicy with the qualifier set AP-Q and either (a)
<tt>inhibit_anyPolicy</tt> is greater than 0 or (b) i&lt;n and the certificate i <tt>inhibit_anyPolicy</tt> is greater than 0 or (b) i&lt;n and
s self-issued, then: </t> the certificate is self-issued, then: </t>
<t> <t>For each policy OID P-OID (including anyPolicy) that
For each policy OID P-OID (including anyPolicy) which appears in the <tt>expecte appears in the <tt>expected_policy_set</tt> of some node in
d_policy_set</tt> of some node in the <tt>valid_policy_graph</tt> for depth i-1, the <tt>valid_policy_graph</tt> for depth i-1, if P-OID does
if P-OID does not appear as the <tt>valid_policy</tt> of some node at depth i, c not appear as the <tt>valid_policy</tt> of some node at depth
reate a single child node with the following values: i, create a single child node with the following values: set
set the <tt>valid_policy</tt> to P-OID, set the <tt>qualifier_set</tt> to AP-Q, the <tt>valid_policy</tt> to P-OID, set the
set the <tt>expected_policy_set</tt> to {P-OID}, <tt>qualifier_set</tt> to AP-Q, set the
and set the parents to the nodes at depth i-1 where P-OID appears in <tt>expecte <tt>expected_policy_set</tt> to {P-OID}, and set the parents
d_policy_set</tt>. </t> to the nodes at depth i-1 where P-OID appears in
<t> <tt>expected_policy_set</tt>. </t>
This is equivalent to running step (1) above, as if the certificate policies ext <t>This is equivalent to running step (1) above as if the
ension contained a policy with OID P-OID and qualifier set AP-Q. </t> certificate policies extension contained a policy with OID
<t> P-OID and qualifier set AP-Q. </t>
For example, consider a <tt>valid_policy_graph</tt> with a node of depth i-1 whe <t>For example, consider a <tt>valid_policy_graph</tt> with a
re the <tt>expected_policy_set</tt> is {Gold, Silver}, node of depth i-1 where the <tt>expected_policy_set</tt> is
and a second node of depth i-1 where the <tt>expected_policy_set</tt> is {Gold}. {Gold, Silver} and a second node of depth i-1 where the
Assume anyPolicy appears in the certificate policies extension of certificate i <tt>expected_policy_set</tt> is {Gold}. Assume anyPolicy
with policy qualifiers AP-Q, but Gold and Silver do not appear. appears in the certificate policies extension of certificate i
This rule will generate two child nodes of depth i, one for each policy. with policy qualifiers AP-Q, but Gold and Silver do not
The result is shown below as <xref target="anypolicy-in-extension"/>. </t> appear. This rule will generate two child nodes of depth i,
one for each policy. The result is shown below as <xref
target="anypolicy-in-extension"/>. </t>
<figure anchor="anypolicy-in-extension"> <figure anchor="anypolicy-in-extension">
<name>Processing Unmatched Policies When the Certificate Polic ies Extension Specifies anyPolicy</name> <name>Processing Unmatched Policies When the Certificate Polic ies Extension Specifies anyPolicy</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="368" width="432" viewBox="0 0 432 368" class="diagram" tex t-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round "> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="368" width="432" viewBox="0 0 432 368" class="diagram" tex t-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round ">
<path d="M 8,32 L 8,128" fill="none" stroke="black"/> <path d="M 8,32 L 8,128" fill="none" stroke="black"/>
<path d="M 8,240 L 8,336" fill="none" stroke="black"/> <path d="M 8,240 L 8,336" fill="none" stroke="black"/>
<path d="M 72,136 L 72,232" fill="none" stroke="black"/> <path d="M 72,136 L 72,232" fill="none" stroke="black"/>
<path d="M 152,32 L 152,128" fill="none" stroke="black"/ > <path d="M 152,32 L 152,128" fill="none" stroke="black"/ >
<path d="M 152,240 L 152,336" fill="none" stroke="black" /> <path d="M 152,240 L 152,336" fill="none" stroke="black" />
<path d="M 184,32 L 184,128" fill="none" stroke="black"/ > <path d="M 184,32 L 184,128" fill="none" stroke="black"/ >
skipping to change at line 1082 skipping to change at line 1304
v v v v v v
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| | | | | | depth i | | | | | | depth i
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</li> </li>
</ol> </ol>
</li> </li>
<!-- [rfced] The introductory text in Section 5.3 of this document notes that
the text in the section replaces "steps (d), (e), and (f) of Section 6.1.3
of [RFC5280]".
In Section 6.1.3 of RFC 5280, the following sentences appear after step (f)
and before Figure 7:
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.
These sentences (and Figure 7) do not appear to be part of step (f) in RFC
5280. Will it be clear to readers whether or not these sentences are replaced
in this document?
For example, should the introductory text in this document be updated to
something like the following? Or should these sentences appear in this
document? Please review and let us know your thoughts.
Current:
The following replaces steps (d), (e), and (f) in Section 6.1.3 of
[RFC5280]:
Perhaps:
The following replaces the text in Section 6.1.3 of [RFC5280] from
step (d) to the end of the section:
-->
<li> <li>
<t>If the certificate policies extension is not present, set the <tt >valid_policy_graph</tt> to NULL.</t> <t>If the certificate policies extension is not present, set the <tt >valid_policy_graph</tt> to NULL.</t>
</li> </li>
<li> <li>
<t>Verify that either <tt>explicit_policy</tt> is greater than 0 or
the <tt>valid_policy_graph</tt> is not equal to NULL;</t> <t>Verify that either <tt>explicit_policy</tt> is greater than 0 or
the <tt>valid_policy_graph</tt> is not equal to NULL.</t>
</li> </li>
</ol> </ol>
</blockquote>
</section> </section>
<section anchor="updates-to-section-614"> <section anchor="updates-to-section-614">
<name>Updates to Section 6.1.4</name> <name>Updates to Section 6.1.4</name>
<t>This update replaces step (b) of <xref section="6.1.4" sectionFormat= <t>The following replaces step (b) in <xref section="6.1.4" sectionForma
"of" target="RFC5280"/> with the following text:</t> t="of" target="RFC5280"/>:</t>
<ol spacing="normal" type="(%c)" start="2"><li> <blockquote>
<!-- [rfced] Should "issuerDomainPolicy ID-P" be updated to
"issuerDomainPolicy (ID-P)" (with parentheses), or is the current okay?
Note that RFC 5280 includes this sentence with no parentheses.
Original:
(b) If a policy mappings extension is present, then for each
issuerDomainPolicy ID-P in the policy mappings extension:
Perhaps:
(b) If a policy mappings extension is present, then for each
issuerDomainPolicy (ID-P) in the policy mappings extension:
-->
<ol spacing="normal" type="(%c)" start="2"><li>
<t>If a policy mappings extension is present, then for each issuerDo mainPolicy ID-P in the policy mappings extension: </t> <t>If a policy mappings extension is present, then for each issuerDo mainPolicy ID-P in the policy mappings extension: </t>
<ol spacing="normal" type="(%d)"><li> <ol spacing="normal" type="(%d)"><li>
<t>If the policy_mapping variable is greater than 0 and there is a <t>If the policy_mapping variable is greater than 0 and there is a
node in the <tt>valid_policy_graph</tt> of depth i where ID-P is the node in the <tt>valid_policy_graph</tt> of depth i where ID-P is the
valid_policy, set <tt>expected_policy_set</tt> to the set of valid_policy, set <tt>expected_policy_set</tt> to the set of
subjectDomainPolicy values that are specified as subjectDomainPolicy values that are specified as
equivalent to ID-P by the policy mappings extension.</t> equivalent to ID-P by the policy mappings extension.</t>
</li> </li>
<li> <li>
<t>If the policy_mapping variable is greater than 0, <t>If the policy_mapping variable is greater than 0 and
no node of depth i in the <tt>valid_policy_graph</tt> has a no node of depth i in the <tt>valid_policy_graph</tt> has a
<tt>valid_policy</tt> of ID-P, but there is a node of depth i with a <tt>valid_policy</tt> of ID-P but there is a node of depth i with a
<tt>valid_policy</tt> of anyPolicy, then generate a child node of <tt>valid_policy</tt> of anyPolicy, then generate a child node of
the node of depth i-1 that has a <tt>valid_policy</tt> of anyPolicy the node of depth i-1 that has a <tt>valid_policy</tt> of anyPolicy
as follows: </t> as follows: </t>
<ol spacing="normal" type="(%i)"><li> <ol spacing="normal" type="(%i)"><li>
<t>set the <tt>valid_policy</tt> to ID-P;</t> <t>set the <tt>valid_policy</tt> to ID-P;</t>
</li> </li>
<li> <li>
<t>set the <tt>qualifier_set</tt> to the qualifier set of th e <t>set the <tt>qualifier_set</tt> to the qualifier set of th e
policy anyPolicy in the certificate policies policy anyPolicy in the certificate policies
extension of certificate i; and</t> extension of certificate i; and</t>
skipping to change at line 1140 skipping to change at line 1410
<t>If there is a node in the <tt>valid_policy_graph</tt> of depth <t>If there is a node in the <tt>valid_policy_graph</tt> of depth
i-1 or less without any child nodes, delete that i-1 or less without any child nodes, delete that
node. Repeat this step until there are no nodes of node. Repeat this step until there are no nodes of
depth i-1 or less without children.</t> depth i-1 or less without children.</t>
</li> </li>
</ol> </ol>
</li> </li>
</ol> </ol>
</li> </li>
</ol> </ol>
</blockquote>
</section> </section>
<section anchor="updates-to-section-615"> <section anchor="updates-to-section-615">
<name>Updates to Section 6.1.5</name> <name>Updates to Section 6.1.5</name>
<t>This update replaces step (g) of <xref section="6.1.5" sectionFormat= <t>The following replaces step (g) in <xref section="6.1.5" sectionForma
"of" target="RFC5280"/> with the following text:</t> t="of" target="RFC5280"/>:</t>
<blockquote>
<ol spacing="normal" type="(%c)" start="7"><li> <ol spacing="normal" type="(%c)" start="7"><li>
<t>Calculate the <tt>user_constrained_policy_set</tt> as follows. <t>Calculate the <tt>user_constrained_policy_set</tt> as follows.
The <tt>user_constrained_policy_set</tt> is a set of policy OIDs, along with ass ociated policy qualifiers. </t> The <tt>user_constrained_policy_set</tt> is a set of policy OIDs, along with ass ociated policy qualifiers. </t>
<ol spacing="normal" type="(%d)"><li> <ol spacing="normal" type="(%d)"><li>
<t>If the <tt>valid_policy_graph</tt> is NULL, set <tt>valid_pol icy_node_set</tt> to the empty set.</t> <t>If the <tt>valid_policy_graph</tt> is NULL, set <tt>valid_pol icy_node_set</tt> to the empty set.</t>
</li> </li>
<li> <li>
<t>If the <tt>valid_policy_graph</tt> is not NULL, set <tt>valid _policy_node_set</tt> to the set of policy nodes <t>If the <tt>valid_policy_graph</tt> is not NULL, set <tt>valid _policy_node_set</tt> to the set of policy nodes
whose <tt>valid_policy</tt> is not anyPolicy and whose <tt>valid_policy</tt> is not anyPolicy and
whose parent list is a single node with <tt>valid_policy</tt> of anyPolicy.</t> whose parent list is a single node with <tt>valid_policy</tt> of anyPolicy.</t>
</li> </li>
<li> <li>
<t>If the <tt>valid_policy_graph</tt> is not NULL and contains a node of depth n with the <tt>valid_policy</tt> anyPolicy, add it to <tt>valid_p olicy_node_set</tt>.</t> <t>If the <tt>valid_policy_graph</tt> is not NULL and contains a node of depth n with the <tt>valid_policy</tt> anyPolicy, add it to <tt>valid_p olicy_node_set</tt>.</t>
</li> </li>
<li> <li>
<t>Compute <tt>authority_constrained_policy_set</tt>, a set of p olicy OIDs and associated qualifiers as follows. For each node in <tt>valid_poli cy_node_set</tt>: </t> <t>Compute <tt>authority_constrained_policy_set</tt>, a set of p olicy OIDs and associated qualifiers as follows. For each node in <tt>valid_poli cy_node_set</tt>: </t>
<ol spacing="normal" type="(%i)"><li> <ol spacing="normal" type="(%i)"><li>
<t>Add the node's <tt>valid_policy</tt> to <tt>authority_con strained_policy_set</tt>.</t> <t>Add the node's <tt>valid_policy</tt> to <tt>authority_con strained_policy_set</tt>.</t>
</li> </li>
<li> <li>
<t>Collect all qualifiers in the node, its ancestors, and de scendants and associate them with <tt>valid_policy</tt>. Applications that do no t use policy qualifiers MAY skip this step to simplify processing.</t> <t>Collect all qualifiers in the node, its ancestors, and de scendants and associate them with <tt>valid_policy</tt>. Applications that do no t use policy qualifiers <bcp14>MAY</bcp14> skip this step to simplify processing .</t>
</li> </li>
</ol> </ol>
</li> </li>
<li> <li>
<t>Set <tt>user_constrained_policy_set</tt> to <tt>authority_con strained_policy_set</tt>.</t> <t>Set <tt>user_constrained_policy_set</tt> to <tt>authority_con strained_policy_set</tt>.</t>
</li> </li>
<li> <li>
<t>If the user-initial-policy-set is not anyPolicy: </t> <t>If the user-initial-policy-set is not anyPolicy: </t>
<ol spacing="normal" type="(%i)"><li> <ol spacing="normal" type="(%i)"><li>
<t>Remove any elements of <tt>user_constrained_policy_set</t t> which do not appear in user-initial-policy-set.</t> <t>Remove any elements of <tt>user_constrained_policy_set</t t> that do not appear in user-initial-policy-set.</t>
</li> </li>
<li> <li>
<t>If anyPolicy appears in <tt>authority_constrained_policy_ set</tt> with qualifiers AP-Q, for each OID P-OID in user-initial-policy-set whi ch does not appear in <tt>user_constrained_policy_set</tt>, add P-OID with quali fiers AP-Q to <tt>user_constrained_policy_set</tt>.</t> <t>If anyPolicy appears in <tt>authority_constrained_policy_ set</tt> with qualifiers AP-Q, for each OID P-OID in user-initial-policy-set tha t does not appear in <tt>user_constrained_policy_set</tt>, add P-OID with qualif iers AP-Q to <tt>user_constrained_policy_set</tt>.</t>
</li> </li>
</ol> </ol>
</li> </li>
</ol> </ol>
</li> </li>
</ol> </ol>
<t>Additionally, this update replaces the final paragraph as follows:</t </blockquote>
> <t>In addition, the final paragraph in <xref section="6.1.5"
sectionFormat="of" target="RFC5280"/> is updated as follows:</t>
<t>OLD:</t> <t>OLD:</t>
<ul empty="true"> <blockquote><t>If either (1) the value of <tt>explicit_policy</tt>
<li> variable is greater than zero or (2) the <tt>valid_policy_tree</tt> is
<t>If either (1) the value of <tt>explicit_policy</tt> variable is g not NULL, then path processing has succeeded.</t></blockquote>
reater than
zero or (2) the <tt>valid_policy_tree</tt> is not NULL, then path processing
has succeeded.</t>
</li>
</ul>
<t>NEW:</t> <t>NEW:</t>
<ul empty="true"> <blockquote><t>If either (1) the value of <tt>explicit_policy</tt> is
<li> greater than zero, or (2) the <tt>user_constrained_policy_set</tt> is
<t>If either (1) the value of <tt>explicit_policy</tt> is greater th not empty, then path processing has succeeded.</t></blockquote>
an
zero or (2) the <tt>user_constrained_policy_set</tt> is not empty, then path pro
cessing
has succeeded.</t>
</li>
</ul>
</section> </section>
<section anchor="update-outputs"> <section anchor="update-outputs">
<name>Updates to Section 6.1.6</name> <name>Updates to Section 6.1.6</name>
<t>This update replaces <xref section="6.1.6" sectionFormat="of" target= <t>The following replaces <xref section="6.1.6" sectionFormat="of" targe
"RFC5280"/> with the following text:</t> t="RFC5280"/>:</t>
<ul empty="true">
<li> <blockquote>
<t>If path processing succeeds, the procedure terminates, returning <t>If path processing succeeds, the procedure terminates, returning
a a success indication together with the final value of the
success indication together with final value of the <tt>user_constrained_policy_ <tt>user_constrained_policy_set</tt>, the
set</tt>, <tt>working_public_key</tt>, the
the <tt>working_public_key</tt>, the <tt>working_public_key_algorithm</tt>, and <tt>working_public_key_algorithm</tt>, and the
the <tt>working_public_key_parameters</tt>.</t>
<tt>working_public_key_parameters</tt>.</t> <t>Note that the original procedure described in <xref
<t>Note the original procedure described in <xref target="RFC5280"/> target="RFC5280"/> included a <tt>valid_policy_tree</tt> structure
included a as part of the output. This structure grows exponentially in the
<tt>valid_policy_tree</tt> structure as part of the output. This structure grows size of the input, so computing it risks denial-of-service
exponentially in the size of the input, so computing it risks vulnerabilities in X.509-based applications, such as <xref
denial-of-service vulnerabilities in X.509-based applications, such as target="CVE-2023-0464"/> and <xref
<xref target="CVE-2023-0464"/> and <xref target="CVE-2023-23524"/>. Accordingly, target="CVE-2023-23524"/>. Accordingly, this output is
this output is deprecated. Computing this structure is <bcp14>NOT
deprecated. Computing this structure is NOT RECOMMENDED.</t> RECOMMENDED</bcp14>.</t>
<t>An implementation which requires <tt>valid_policy_tree</tt> for c <!-- [rfced] Should "denial-of-service" here be updated to "denial-of-service
ompatibility with attacks", or is the current okay?
legacy systems may compute it from <tt>valid_policy_graph</tt> by recursively
duplicating every multi-parent node. This may be done on-demand when the Original:
calling application first requests this output. However, this computation may However, this computation may consume
consume exponential time and memory, so such implementations SHOULD mitigate exponential time and memory, so such implementations SHOULD
denial-of-service in other ways, such as limiting the depth or size of the mitigate denial-of-service in other ways, such as limiting the
tree.</t> depth or size of the tree.
</li>
</ul> Perhaps:
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.
-->
<t>An implementation that requires <tt>valid_policy_tree</tt> for
compatibility with legacy systems may compute it from
<tt>valid_policy_graph</tt> 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
<bcp14>SHOULD</bcp14> mitigate denial-of-service in other ways, such
as by limiting the depth or size of the tree.</t>
</blockquote>
</section> </section>
</section> </section>
<section anchor="other-mitigations"> <section anchor="other-mitigations">
<name>Other Mitigations</name> <name>Other Mitigations</name>
<t>X.509 implementations that are unable switch to the policy graph struct <t>X.509 implementations that are unable to switch to the policy graph str
ure ucture
SHOULD mitigate the denial-of-service attack in other ways. This section <bcp14>SHOULD</bcp14> mitigate the denial-of-service attack in other ways. This
section
describes alternate mitigation and partial mitigation strategies.</t> describes alternate mitigation and partial mitigation strategies.</t>
<section anchor="verify-signatures-first"> <section anchor="verify-signatures-first">
<name>Verify Signatures First</name> <name>Verify Signatures First</name>
<t>X.509 validators SHOULD verify signatures in certification paths befo re or in <t>X.509 validators <bcp14>SHOULD</bcp14> verify signatures in certifica tion paths before or in
conjunction with policy verification. This limits the attack to entities in conjunction with policy verification. This limits the attack to entities in
control of CA certificates. For some applications, this may be sufficient to control of CA certificates. For some applications, this may be sufficient to
mitigate the attack. However, other applications may still be impacted. For mitigate the attack. However, other applications may still be impacted, for
example:</t> example:</t>
<ul spacing="normal"> <!-- [rfced] Will the text starting with "but where..." be clear to readers?
Original:
* Any application that evaluates an otherwise trusted PKI, but where
untrusted entities have technically-constrained intermediate
certificates where policy mapping and path length are
unconstrained.
Perhaps:
* Any application that evaluates an otherwise trusted PKI that includes
untrusted entities with technically constrained intermediate
certificates where policy mapping and path length are
unconstrained.
-->
<ul spacing="normal">
<li> <li>
<t>Any application that evaluates an untrusted PKI, such as a hostin <t>Any application that evaluates an untrusted PKI, such as a
g provider hosting provider that evaluates a customer-supplied PKI</t>
that evaluates a customer-supplied PKI</t>
</li> </li>
<li> <li>
<t>Any application that evaluates an otherwise trusted PKI, but wher <t>Any application that evaluates an otherwise trusted PKI, but
e untrusted where untrusted entities have technically constrained intermediate
entities have technically-constrained intermediate certificates where policy certificates where policy mapping and path length are
mapping and path length are unconstrained.</t> unconstrained.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="limit-certificate-depth"> <section anchor="limit-certificate-depth">
<name>Limit Certificate Depth</name> <name>Limit Certificate Depth</name>
<t>The policy tree grows exponentially in the depth of a certification p <t>The policy tree grows exponentially in the depth of a certification
ath, so path, so limiting the depth and certificate size can mitigate the
limiting the depth and certificate size can mitigate the attack.</t> attack.</t>
<t>However, this option may not be viable for all applications. Too low
of a limit <!-- [rfced] Does the "^" here denote superscript? If so, would you you like
may reject existing paths which the application wishes to accept. Too high of a to make use of <sup> for superscript in this document? In the html and
limit may still admit a DoS attack for the application. By modifying the example pdf outputs, it appears as superscript; in the text output, it will
in <xref target="exponential-growth"/> to increase the number of policies assert appear the same.
ed in each
certificate, an attacker could still achieve O(N^(depth/2)) scaling.</t> Original:
By modifying the example in Section 3.2
to increase the number of policies asserted in each certificate, an
attacker could still achieve O(N^(depth/2)) scaling.
-->
<t>However, this option may not be viable for all applications. Too
low of a limit may reject existing paths that the application wishes
to accept. Too high of a limit may still admit a denial-of-service attac
k for the
application. By modifying the example in <xref
target="exponential-growth"/> to increase the number of policies
asserted in each certificate, an attacker could still achieve
O(N^(depth/2)) scaling.</t>
</section> </section>
<section anchor="limit-policy-tree-size"> <section anchor="limit-policy-tree-size">
<name>Limit Policy Tree Size</name> <name>Limit Policy Tree Size</name>
<t>The attack can be mitigated by limiting the number of nodes in the po <t>The attack can be mitigated by limiting the number of nodes in the
licy tree, policy tree and rejecting the certification path if this limit is
and rejecting the certification path if this limit is reached. This limit should reached. This limit should be set high enough to still admit existing
be set high enough to still admit existing valid certification paths for the valid certification paths for the application but low enough to no
application, but low enough to no longer admit a DoS attack.</t> longer admit a denial-of-service attack.</t>
</section> </section>
<section anchor="inhibit-policy-mapping"> <section anchor="inhibit-policy-mapping">
<name>Inhibit Policy Mapping</name> <name>Inhibit Policy Mapping</name>
<t>If policy mapping is disabled via the initial-policy-mapping-inhibit setting <t>If policy mapping is disabled via the initial-policy-mapping-inhibit setting
(see <xref section="6.1.1" sectionFormat="of" target="RFC5280"/>), the attack is mitigated. This also (see <xref section="6.1.1" sectionFormat="of" target="RFC5280"/>), the attack is mitigated. This also
significantly simplifies the X.509 implementation, which reduces the risk of significantly simplifies the X.509 implementation, which reduces the risk of
other security bugs. However, this will break compatibility with any existing other security bugs. However, this will break compatibility with any existing
certification paths which rely on policy mapping.</t> certification paths that rely on policy mapping.</t>
<t>To facilitate this mitigation, certificate authorities SHOULD NOT iss <t>To facilitate this mitigation, certificate authorities <bcp14>SHOULD
ue NOT</bcp14> issue
certificates with the policy mappings extension (<xref section="4.2.1.5" section Format="of" target="RFC5280"/>). Applications maintaining policies for accepted trust anchors are certificates with the policy mappings extension (<xref section="4.2.1.5" section Format="of" target="RFC5280"/>). Applications maintaining policies for accepted trust anchors are
RECOMMENDED to forbid this extension in participating certificate authorities.</ t> <bcp14>RECOMMENDED</bcp14> to forbid this extension in participating certificate authorities.</t>
</section> </section>
<section anchor="disable-policy-checking"> <section anchor="disable-policy-checking">
<name>Disable Policy Checking</name> <name>Disable Policy Checking</name>
<t>An X.509 validator can mitigate this attack by disabling policy valid ation <t>An X.509 validator can mitigate this attack by disabling policy valid ation
entirely. This may be viable for applications which do not require policy entirely. This may be viable for applications that do not require policy
validation. In this case, critical policy-related extensions, notably the policy validation. In this case, critical policy-related extensions, notably the policy
constraints (<xref section="4.2.1.11" sectionFormat="of" target="RFC5280"/>), MU constraints extension (<xref section="4.2.1.11" sectionFormat="of" target="RFC52
ST be treated as unrecognized 80"/>), <bcp14>MUST</bcp14> be treated as unrecognized
extensions as in <xref section="4.2" sectionFormat="of" target="RFC5280"/> and b extensions as described in <xref section="4.2" sectionFormat="of" target="RFC528
e rejected.</t> 0"/> and be rejected.</t>
</section> </section>
</section> </section>
<section removeInRFC="true" anchor="implementation-status">
<name>Implementation Status</name>
<t>This section records the status of known implementations of the
protocol defined by this specification at the time of posting of
this Internet-Draft, and is based on a proposal described in
RFC 7942. The description of implementations in this section is
intended to assist the IETF in its decision processes in
progressing drafts to RFCs. Please note that the listing of any
individual implementation here does not imply endorsement by the
IETF. Furthermore, no effort has been spent to verify the
information presented here that was supplied by IETF contributors.
This is not intended as, and must not be construed to be, a
catalog of available implementations or their features. Readers
are advised to note that other implementations may exist.</t>
<t>According to RFC 7942, "this will allow reviewers and working
groups to assign due consideration to documents that have the
benefit of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented
protocols more mature. It is up to the individual working groups
to use this information as they see fit".</t>
<t>The following projects adopted the concept outlined in this document:</
t>
<ul spacing="normal">
<li>
<t><xref target="BoringSSL"/></t>
</li>
<li>
<t><xref target="LibreSSL"/></t>
</li>
</ul>
</section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t><xref target="dos"/> discusses how <xref target="RFC5280"/>'s policy tr <t><xref target="dos"/> discusses how the policy
ee algorithm can lead to tree algorithm in <xref target="RFC5280"/> can lead to denial-of-service v
denial-of-service vulnerabilities in X.509-based applications, such as ulnerabilities in
<xref target="CVE-2023-0464"/> and <xref target="CVE-2023-23524"/>.</t> X.509-based applications, such as <xref target="CVE-2023-0464"/> and
<t><xref target="updates"/> replaces this algorithm to avoid this issue. A <xref target="CVE-2023-23524"/>.</t>
s discussed in <t><xref target="updates"/> replaces this algorithm to avoid this
<xref target="policy-graph"/>, the new structure scales linearly with the input. issue. As discussed in <xref target="policy-graph"/>, the new structure
This means scales linearly with the input. This means input limits in X.509
input limits in X.509 validators will more naturally bound processing time, validators will more naturally bound processing time, thus avoiding
thus avoiding these vulnerabilities.</t> these vulnerabilities.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC5280">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
<title>Internet X.509 Public Key Infrastructure Certificate and Cert 80.xml"/>
ificate Revocation List (CRL) Profile</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<author fullname="D. Cooper" initials="D." surname="Cooper"/> 19.xml"/>
<author fullname="S. Santesson" initials="S." surname="Santesson"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<author fullname="S. Farrell" initials="S." surname="Farrell"/> 74.xml"/>
<author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<author fullname="W. Polk" initials="W." surname="Polk"/>
<date month="May" year="2008"/>
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certif
icate revocation list (CRL) for use in the Internet. An overview of this approac
h and model is provided as an introduction. The X.509 v3 certificate format is d
escribed in detail, with additional information regarding the format and semanti
cs of Internet name forms. Standard certificate extensions are described and two
Internet-specific extensions are defined. A set of required certificate extensi
ons is specified. The X.509 v2 CRL format is described in detail along with stan
dard and Internet-specific extensions. An algorithm for X.509 certification path
validation is described. An ASN.1 module and examples are provided in the appen
dices. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5280"/>
<seriesInfo name="DOI" value="10.17487/RFC5280"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="X.509">
<!-- [rfced] FYI - For reference [X.509], we added the following URL. Please
let us know if there are any objections.
Original:
[X.509] International Telecommunications Union, "Information
technology - Open Systems Interconnection - The Directory:
Public-key and attribute certificate frameworks",
ITU-T Recommendation X.509, October 2019.
Current:
[X.509] ITU-T, "Information technology - Open Systems
Interconnection - The Directory: Public-key and attribute
certificate frameworks", ITU-T Recommendation X.509,
October 2019, <https://www.itu.int/rec/T-REC-X.509>.
-->
<reference anchor="X.509" target="https://www.itu.int/rec/T-REC-X.509">
<front> <front>
<title>Information technology - Open Systems Interconnection - The D irectory: Public-key and attribute certificate frameworks</title> <title>Information technology - Open Systems Interconnection - The D irectory: Public-key and attribute certificate frameworks</title>
<author> <author>
<organization>International Telecommunications Union</organization > <organization>ITU-T</organization>
</author> </author>
<date year="2019" month="October"/> <date year="2019" month="October"/>
</front> </front>
<seriesInfo name="ITU-T" value="Recommendation X.509"/> <seriesInfo name="ITU-T Recommendation" value="X.509"/>
</reference> </reference>
<reference anchor="CVE-2023-0464" target="https://www.cve.org/CVERecord? id=CVE-2023-0464"> <reference anchor="CVE-2023-0464" target="https://www.cve.org/CVERecord? id=CVE-2023-0464">
<front> <front>
<title>Excessive Resource Usage Verifying X.509 Policy Constraints</ title> <title>Excessive Resource Usage Verifying X.509 Policy Constraints</ title>
<author> <author>
<organization/> <organization>CVE</organization>
</author> </author>
<date year="2023" month="March"/> <date year="2023" month="March"/>
</front> </front>
<refcontent>CVE-2023-0464</refcontent>
</reference> </reference>
<reference anchor="CVE-2023-23524" target="https://www.cve.org/CVERecord ?id=CVE-2023-23524"> <reference anchor="CVE-2023-23524" target="https://www.cve.org/CVERecord ?id=CVE-2023-23524">
<front> <front>
<title>Processing a maliciously crafted certificate may lead to a de nial-of-service</title> <title>Processing a maliciously crafted certificate may lead to a de nial-of-service</title>
<author> <author>
<organization/> <organization>CVE</organization>
</author> </author>
<date year="2023" month="February"/> <date year="2023" month="February"/>
</front> </front>
<refcontent>CVE-2023-23524</refcontent>
</reference> </reference>
<reference anchor="BoringSSL" target="https://boringssl.googlesource.com
/boringssl"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 446.xml"/>
<title>BoringSSL</title>
<author>
<organization/>
</author>
<date year="2024" month="January"/>
</front>
</reference>
<reference anchor="LibreSSL" target="https://www.libressl.org/">
<front>
<title>LibreSSL</title>
<author>
<organization/>
</author>
<date year="2024" month="January"/>
</front>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
</references> </references>
</references> </references>
<?line 802?>
<section numbered="false" anchor="acknowledgements"> <section numbered="false" anchor="acknowledgements">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>The author thanks Bob Beck, Adam Langley, Matt Mueller, and Ryan Sleevi <t>The author thanks <contact fullname="Bob Beck"/>, <contact
for fullname="Adam Langley"/>, <contact fullname="Matt Mueller"/>, and
many valuable discussions that led to discovering this issue, understanding it, <contact fullname="Ryan Sleevi"/> for many valuable discussions that led
and developing the mitigation. The author also thanks Martin Thomson and Job to discovering this issue, understanding it, and developing the
Snijders for feedback on this document.</t> mitigation. The author also thanks <contact fullname="Martin Thomson"/>,
<contact fullname="Job Snijders"/>, and <contact fullname="John
Scudder"/> for their review and feedback on this document.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+1dW3cbR3J+n1/RoU6OpBiAREryxtzYCS3Ku0yoy4qUd33i
RBpgGuBYwAx2LqSxFPe3p259m+kBSYlJTnIWDxIx6OlLdXXVV9XV1ePxOGny
Zqn31bt1lja6Vk2p/jR59vgb9aZc5rON+jFd5vBLXhZJOp1W+vxGRbNyVqQr
qDar0nkzznUzHy/T1boe/wovjNf0wnhRpeuz8eNnyQzqW5TVZl/VTZbU7XSV
1zXUc7pZQx1HL05/SJKWW91Xz/b+8XGS5OtqXzVVWzd7jx9/83gvSSud7qud
Ez1rq7zZ7CQf9eairDJ4v2h0VehmfIidSeDhx0VVtmsofZyv8kZn6iDLcux4
ulQv9ewsLfJ6Vat5Wak3/3b0J5UWmTp5efTyxU6S1A18e58uywK6ttF1ss73
1b835Wyk6rJqKj2v4a/NCv/4jyRJ2+asrPYTNU4UfPICRrBzOFHf6+KXdJUX
O/SYibVzmJ7nWeenslpAd/5CdIUivyvLxVKr4+Pn/LNepfkS6IxvTnXxLwv6
fTIrV0CjAkawgjfPNXSAJ2uf3pJJ/46+KKCQFCwL1cD4i3JZLjZqrF6vdaFO
NnWjV7UtC9SclUWhZ1R+rE7PtDrMK/hOU/imncLsjoH8SDd5K22aKp+2jVYz
XTX5PMcpV/MKxo3zwZVbWikZuJm7VObmVC81jGzVFvg+PKvVuwL5Dcsje+yr
19CLqa7U3uPdb+hxratc10gKU/HR6bvx6b56S1XpglmWqZNAkec/vhjvPd57
Mn789OunAble/DrTwJfnGt6ty7aaafWuThda/QhtzDd5sQgXxHPoYFOledHw
+Jq0WuhmX501zbref/To4uJiMjvXExjpI2gVO1Rl/5xn3wZd8Ab3Mq1mZwp/
CTq69+TZXtjTN1VJXYUepWoF63KWl2293KgZLgFgeH8WVulGLXWa4YJOVaaL
PF2Oy/kYKHeez/Rndp065fX9Bz2t2rTa2O5/X1bQv5OT46Dn9mm02Sn9WtfL
CfM5zwJyu/vJa/Nf08I0+RSbPM5BgnVbNA8Hx7nEAtgmDnaw9vF4rNIpzves
SZLTs7xWIAVbYLBGiexSb394TuILKV3p9TIFDmpg9aRLkH55c7YikcM8xDIy
ObdCVV1ACVhSSv+5zeExVDxSq7LSSs9hJnNsyFY0oVUJfy9yXDj2eTJt8yWU
A0FbtbOmhbcvznJgqnoGNWZK/7oGwVY0wALALXlB3YMVWjdqltZ6hIxyDnRO
8tV6qXFwsg7P22Whq3QKsgkG12MiFADp7GM9YUKt8ixb6iS5hwu8KrOWZEmS
XF7+HdAISXR1BZXM8wKoBp1tQUqrcg7da3RRU4NIqUyDdABJiXyOHd0hosFy
3+FRJel6DcMgvnYcj7Rcp83ZRB0IlRVOlq5nIKKABlMUXKqc/gISTeUZUmOe
6yp58Pro8OGIlAF0STfYoXItounPLUwUFsMhyvr35g4oeXnphgbtAc8CBX+F
TtTU3DkSSl+MaCDe8kzMmNzg1YPLyxMRv08ne5PdyVPsiyPdQzuamqozVYwS
4qFIp0eqLTIQm8wMKXY4y0GlQIFAVlykNXS+bnU2SU5NzRsQIes1rr5tfXzW
7SOwWHkBg0+eHwRtwHRBfSpvalM9EJ7gRgmDqYKHQFfv1TppzlKYs4b7WE/U
ScvTCC/Du7V2PcVp5PocU3WJjzyJnHK/pvmBDpvGcfpzJm6OKqqWocIQ7Xyl
NTB/wwylU+BGf5CytLD2EfDCcokVCBuDLAWBAwsxwycBZxHNUbhnuHSJqwyV
v57shhS2y4O4AHpLnS6kiRb6nED5/rrw+HaijhoQY1BBXeIwUHpkrFWEEAB4
9CgBPNCkvA4Hhx/MMVLfTsVUNxdaFzB5mgQXEhaqBYlTKEBqF3GplOk18vK8
P2dM1YR5eaXTglYYSyBdjUSQqnqFE5oX6xYEKbY1S1vgkDQgAkiZpsTx1SDK
oSMGAaw0iF5COLSS28ZglEqUUi0jmZUgO1MAhCvdVJsE29mibK0czZcAYnGo
pA3GUxC+IHZAnBnkAyCzRQlXAwsEeAEmHnvlPSVVfHU1QfmalTVxhhMPeR02
OoFXfYDeKY78l69A7yUAnfMFExyFcb8mkJVGzZEa5FLaZx2nhybQOdGT0CLw
OEgfaLB1xkagHHhyrRbi1hG5L6CmH1DpLaH9y0ta4mPXVRp9Xs9a4E5gi6XA
S5xRNxzU4mCRIBdDnxNWyD7xgZT37oFwWSEhkAefU8tQvCpXVs3zcg2V+9oh
M389uFUDU9cVqnmdCBkz5l1YDEIAWpB1FxUA0FarFpk/hAcesYk3C33hdY/W
eVE2QkaaKloFyIlg9jRtjUNNi01ERI7gTaM+4gOrpDYiQ94gCREhn+O6Lgse
+SGqfLLEaiYeWhFoxdVq5+W7k9OdEf+vXr2mv9+++MO7o7cvDvHvk98fHB/b
P0yJk9+/fncMvyfyl3vz+euXL1+8OuSX4anqPHp58NMOa/ud129Oj16/Ojje
YdkD82GhHQ4LeHMqemBdaRR5qY8n4J3vn79Ru0+Fg/d2d78BLuQv/7j7G1ia
IKt0wY2VBYg4/goTsEG202mFlaC0mqXrvEmXsPqhifqsvCgU8LcmYh6SMMEp
OhFh8mMgTC7v4eIXbGoUllsLUJlVST508RiEABkOKAnUzmSvo3huK+SSISHH
60zg1CnIizq5rmmyuYDLWVZ9oIG85xX1HiXOB5RKJHrKeRLj1JEC3Rquz5hm
JPYsSpRRADlwUSxAihSilkRHsRqz6hxVSVQ/piqCDeKIFZu8X8Oaq5D9HH71
BKu8TxioCuEbrU8EcShcdMa4CPiZ3zTgltsAOQDCBZphJvdwJCKssBJpsma4
5dMVpvCHEkFWirIatdZ6XZKajdBXcES9nyT/oA4KXlMrneVpx3MgOJVIGMJE
+Gd3hP/u8Wjgr2cTsNoAyJjanWTFwth9+P+JLW6ePJ1IL3SRjVFKNZub92Fv
FFb69UQW3kXZLjNECe2yCdiEVzNBOlgI+WyMT0Frq1clgmIEtjgWWyF6vEhc
58Vs2WYwD0BmmZF0VpU188TFWbk0OLMuWaZkJb3oRAs8TeZkKXoqIvnrX/+q
0rQ+X4jjJP75auw+X/kl35YlWNLe5xMuE1nMnz6vzt7n06Wt8+qu6lSP3J8/
by35yP+yteh552ukrN/B8VexZ/jSkbck9pGm8CGmVfLFPdujL2S3PiNBn1bA
Jg9v2lLn8+mSGRpXxpXXEj7eu6KWPndM0c+n2LM7Kn0ee/YF3X9hJYQ3JU+8
fkWm5OvbTgksx+RyX91z0oFdWN/ugIx6wfI1dECixty5YiTF/oami0etRccW
ovUK5R0EUzd6XasH2cNR8kCLF+TB/CFq31AhPwkV8si8eQYvPcjxn1/Ct5Kv
+w4Mrl/eTPGlqWlzEWkTXQuJe5tRwwtnNKrfgRUJ6uXynmdJjhf0UMgTAQpk
e9bXucTARC4S7CkQZ7J7E4KA5QkEX1p1/Ybw0prcYDpZgV7IcSZJ+wrCyOfK
Phe1bnUx+kpAYb0x9qY1ZFGos2bJ/6JZSc8qDV2m+cRnUiep4HMNowMdQ6b6
UsNXIOMR6mXQeLN2mVYjAlc5uolCvAL2AtR4gUBUwYvVZlBvJ4G2xN6T6BKV
Jhob+l04XY3UnrcAfZ9DR3SdW1Kh/y0xmpwAA9UFT2pR4LuRZ3v8bC9Sbi8s
lxwIMQjRjZyiZg2elS06O4WUkxDk5OSVAHIQcrooBwkifiiw5+Igg5tltECr
1HUATA4yM9b5rOE1ennps7fAh5uo8UDQ3E44O43Oz/8b2vA0/J23EWpw+xlW
5fHyW96IqRr5JXglpgC6ny2aM4YDup+OErrL1i8d7L4aaj0oc5ete5Pyc/zl
TqEk/nzL60Eh//Vwegcmu1MoiY349k+S2KyHc+w/GSpzh73pccHtn9xdb9wy
cAx5qyeJP3VuCm/1JPnKdPHL/kg+8RR+Up945uSP2z65s/4YMNrVODeBpOzE
7OMzhKoA3A7IUa9+pIACUMPOdU/gRqCNj8sUQznaOSpb9MoN7kCqdIGwoknS
Qdc6753aNmvQzHUE76R1X+cKpCQPPGCvfLHQFUMY3lj2m7kfVup53MRHPFE+
pkjitdDuPUIBdXp8Ar35Z/QpPn36NfQBB64r9hysdYUhHtDkEj3BSbxlHjk3
kviNXOToe5RNkHlasWPZbnX4Xm3eElu36JJP2bPgpo9rII8RklXlzQje1eQD
hnfzhh3oPGX4hHfouNPkDVQH52VOBksU36fy63gA6Pu78uLwl12N67yUgTUk
+yjJdCMbHGbk/taGbDPJI9pLcQbWKKyQnHDik+VZCF5jS2SZFzqtyAgBgyPN
eEfcs07EBKj0qjynzVBtd57yGe9EQVvr7u400JXXaHdTX1zmwjz9F6Nbggl1
eQTWJe7vWsLYTcsOIe2ej+283TBK3Eu8xyZTVacrf2NB1qFvYp2VF2iIELDm
HcKkbBuoATdTyJcOxvd8rivZllpN1AnM2OWllILVI/EFab6scWsquo9kt8Xi
+0gcpNAlKq7HBGC7JuBPAzJxGiN/OsdoV0AR6lHgCP8dErgGbg+26diODTfV
eDkFG2c57Ra1GL8FKzatcuInu0eEO02wrk13acMn4qm9X3d3qdA3LXZtL3ph
Q1Iq8IM7e5YsXN6zInMLv9MsUeTFDKlCK8l+T4xf2nJM1hZZWjg/uARnyd5w
RFH4PJjERThQ/CBchEg5YBsMdCMX6wbE0kx+M/v+Gx7OJPkjmX8B5dMM9Igd
dtayeLUE6EgKKm1dBUQUIoOtgHcAoCnmXLd3ardZ7erZ4uiZJH2rcZzWdusX
vdJMVG4AXdddBmEis7K/vRm6zS+7zWO89b0tXuFt7w3C/K7hF/7Yhf1i2XVB
asyE6aLzmI12o3o6uDpmbd2kHtcpsYZ43J/6v+LPQpTYr+pnQ7Hor49+3vLr
I2uJ+b+ee//x33+js/p/SOch08KKJWtjqJcIQ1/Y+Ia3fd1VDHnEQQhSZaDJ
yBcK36clBsFlDmcBvCHUXTagOop2hYHFQciUF50Xj8nzw90ikR39ILkkeCmA
gqTaRaEH+tx6JnHAGKMGClpCUch7WJYN78QvdTq3kWeeshklNe4IqtyLA4d6
lwIYsTgTPpT9DEoo+Nlgg9eCsi7vGSTV3bD/OiBLJ7QIZ7uKO+MdpklrNN64
fqN+zv1OWPvJtLu7x3ECl5fEDEg1g6CL5cZCQ8LLFIMOEE7X45mJ39aZFx1A
uhBshPjPiXiw8wp3hstZTjoziOE7GAxNMJPpIxbPYmAQzIYS4LRcQmdvZsBM
VBTjJy4sxpD05hOBFpwQkqtJlnigwlZUql/amiuUeNkh8kJVjwCkdOmaOLJ3
Q2rsXE4s+Bk79I7299bgL7Esu2DdDz6RHQ0yzThkFueHNs7PwSzAWOdBy+nl
wU+qRFLIMnMM4Nalo1KNr+fzTeLsaNn23y5UYLVXQHw0QuUsg5gXIWD3iL61
UzZ8xD8NUq3Y7vZO/dgw9st7BnV2oori4Xtug46BuyUaMzCHndVJZ5q3mfSy
1ef1zRM10ifugrEra4rvrFIL23sBtB51azFicXvp9fEh/PsdqK8Db08sFsSC
tg5wibVCR+SfWQNN1hXt/2BMIVaEsjqIdlIo7isNv+sRhax6LhjkqLRd2GBH
qcHs5cLQ521FPM1r0Ft0HHZHWoGboL+pgr7XCeqsyzB02FYUC5eiasjHFEb4
kZnBYSfsYSu7UU2dOmwY9mg4qtz+NHNHa7xfmSYklc7yad541oMthBQAXQg2
JMwN9XJkw966JHHk9cLKUkNPp5WhzqO5RyiqJxoFuY1QRrro1RpjZ3EbVIhr
dgDZD0fevl4fcH449gyoRMLtIpdNYKykV0GBe6r9kSTJqxd//Buj/43Re4wO
pBlJzJv4nIlRVc7sDvDxBnG/lljbBPdkb0B0A0tUGwwI6UdZ7IWim1wlFDrg
vJBAGWBssCyazRqshwd/P3sIpsDupINySDN82Ef2H3b2+CYADN6O1rQL8C9y
yua37OESzIpHqTSdDJQHHYzdm4G0Mc4bPHQoYXuBpIke4UDZ5NXDR4lyPJXQ
JMTSnSq31zcKDl8kIp+sh0zjaOW4Tdxkqm0zuI2SmEV1BsQAptJ2feos2nWJ
XfziEZgeYwW46qHLr94dH0Obrws5lmcH5f1uF6aDajwFsPRR6BwNAUEPbOVz
GkKlAUUjyFXK9Ns6e+HRC+cMLSIGA7OpCf5E6YVKAEaYytG1et9Mjs9EI3d2
zbNPeoAwPOZGPIqudNn4ASTG68LtCOBpK+r2Kw5Y8q1G3LUDcUEHygjV0QlB
YCBohllEY7AX6hpYpwRF/6KrEqN2JeAZWZ9Z7leqjZgFy9guuVhlW/IrCiwa
2TWZkOyd6bVxDnA5rGYUDE88q15V413E4+a8WLbgZSvnliRGC4UicSXTQQCB
8Wa7uuSQGdhyhGZrs/qpJA7MTJsTXbVepej7RhwKP3oiLEMRBo922VMQsMgH
9liHwWavjw6dhOFtm0DGWOdxyoerlrpYYK95UHvSjGWU98Agph3mqr5t4fGZ
FctBm+EhPmyLPVBHdMaODkSY3YoNnw7MKTiMFz40ssxwTUVapk1KXmVGJvkb
vdIOOtCDcEIOWsRYQx72Exm24XuzBmnwNlItYCH/4CKKN47ZqqHder4RNRhE
6wcU+GqXGz6lzdScHAG0yAyzxGVBbMMAq+mwhQULhL1Yi3emVNY/ief4sO1U
SoPcPVs14S8CtMT/JCMlepDnYuotal7tZsB2/0NSMsD0M91yAWluYeTFeQpQ
s2hkZfwDbZnjYQwjLTyvG7L+mzH8O5LgPF6WK/Ry4dx1Bc3FGZ5T6C8pqmMi
7Q3zBe2c8TQMVORAG35ZXqSb2g92M030ReC1FY5E0NnljONjZakCsSetnqWI
CdJZA7TGoiwB980AfEHIjXNNkR4gpnZMICNwqszWtKg0cHrFQQKPuQM5ide+
JBYBOzRq8sjYkXPPkAus5HOVXE85kQmndI6YduXoPVA62Eyd4/ZbWmjOpkCG
FMfpwmxPSzqfb+aUIpjLFfJVMXaPLe9cXnL+E1nfsjXL3A9QM77NZoQBHsez
W9vdmRB5AEvQy2syzxdtRQgVjDGOocnJ57VCWFkmxBjseDGemK3AQw5JkZ7w
3FY0tN5WXy8w0+6CfFKdGFJ88E9YRPmt3qwi/FxeeQ+4okC03aimMOTU1RRZ
6Nvrw70M1tj3gtk2WxhHMeHeJ7c6ofn+EYXddKklUGrAenoyYD25EH51gxD+
29tSDOG+3XnKVtVR92S29u0PkyYA9SDzedSg0SYifFDj4bIUYM5caOBTxJs5
3ZhYFhOW4mEsog4bJGUFamob1qLALBRqNoSfbBJj+3iCfdgX4JvzzEJLQFCk
XNCXz4e+NGktOjhsWkKCvBn/wS9jGZxAmF/aQJw3EsITH7M/4HDMuYyZh30M
tX9gcfqeZPIHFIEGvHogNwc9sU14sGedx5o7ORPTo2YEDKk7rYcesxnpFCuS
WeF4PlxbEdlzfbiMpygYH9gCHaBLJf7g/R7V/OjsporMORYpHWgzKBQOZpK4
DgaHCbxTF3FicpwZDddaNTlpai0HN+P9BOpd/q5cgon0x7O80Vcj1wFj/c0w
Wkc0500r+0kjva+8iTuoKXBwcCXge5xkK19i2FZwMPE6CdJx1+VeuwjOqG53
TBYkwexMZxxvhLVLk64EMFRQBUYYtUvNinOhcUety2SO6hZwec12OmSOfprz
25TBgcDXmDp3deVzwkDUTP+kQ+zMWKjXrHajz1uA4cET88P3qIn4yV23aXVz
t83wB8vBd9h+wOh++yHT3t2Y/U/sWMGj4eKR8ttK94pvLRw5jDD0udUYDUmJ
8eXJXdcd55M7boUY4uoLRyC4T3pNwSx2gRvs5ydpo2j5WaNeYgGEd/zmnoFR
FadeKkoWYOZEJp6ovAYhGf9gVEEYZDfoIHCDiEu+CDZkZ+D/irYN9VdE7Von
kAVooVUKRLkLNexqGNLH1xqg+Pk8tene/xz96b096StQmyKGHLCpA55Wn7r3
Q8WKBn4IVf8w5hLs5Tdj6b1/oSXNgWhuHBVx/bQ8p+ORvn6OsCuevvSP0roZ
YafvXKC8e3XtHFgD2rotpDNo13PxG2nt8HM74cTSKTSV77p2FUjYW9auBhV3
v6WOfX2H41Bbg3i3Fb1VrofrSvcPAnYU7SCwGPgxCqh8Xdv9UZYPP/lvaLsP
5syfl2ZlX5knUUV9F70IdHXnx0uvE3dHgZ5ij8iCiIJ/Z0pxICptFeMx9xRs
6nROm2bqBJRbPuckYLI6BAns3dib4nYDrQPEiQyrrEN/wQF6E1CNiAP2QfpQ
hvhBwgve2zpIV3V8tyBAH0wfqvyfCgtFAoMM90+X8zGnjeS4Futq6DpSrI8e
ZDyNhdGRtP7Q5NwhRbfdb4CCXtyv12yh8kkfkVwGQ+Rz44oxKk+M0jQSvdlp
zMEJzydhzsbcAjt9CXA6+Czk1IdNtd3L73t4fC+ONyUDbhxpgiP/ai9fHWXD
bYvCeKTUg12r3tNacilcx/myC4exGoaXiL6OoXBsfcafBJz4P+hyEenkUz50
uHxWvdbrItjR244I18wtnSo84v4OK7MZYr8uGA1yTE38yY94U24K0joelRhA
m2pYSwzTrEAe58XYjs1DajGYFlcN2/VR3Key3aHyJe2EqvfmTpTPbDPkWL9N
T/9+6di6Y+y4NWIY0dP4ftlrivplryvqlb22qCsbK9rN/2X+vxOOCLCe1y+H
D++G8y5xuXtwy3CBexxHe5/dYojh1F3znQNziOTi4uJmYO6PCOZQrj73pKb9
9YWtbADjYS+eeL6e3PprtgGXQEOAhFxiVCsK6rLljJSeSMXz5pT+i6JR8JER
om81SGgbWQjqty2afCkd4RyDPakcac8eyt2uUAf2N73kh2vAAkDlqysW5b6s
RzURwSE2KHeVVh9NlBFA0/t/us+OiqK03bMppjb0BhMls1oT88XbQ7KkqAT+
uBRM3GHOiGDybPV7tce9oh0Hr1Pq/k/3Jfql0/RREWtn9NnzYAZqZtWmnKeU
nJb/b5EZ6map+j7Zvj35wlofeXUPGtvmZKTaWqyboWVI7H617VtEEfPfsW8/
yTfLD1/Yot/uz8E3+9tAaXvE85rSIY2Gdwk+n15/kr9j9DK/XQdbbkcv8/k/
zUrm23a9epP2Qn0ngtYpuNZepNGX0KSlkps7IthmltCOUdyUNXrMhF4nCehA
vkuHpac4JNDkwRYa32Hed0JcFyViwzOwsd9ui6B5uiWChnwdvZCZp18WMrNn
Q2as9Rq5UsPFyrAXxZlFnBPysMTIWLH3jg7HbzpnfftVbotxkYkWUsq76lxC
kCJTIIpV4Isw2i1AjBi53PHa20zwX2NWGvRnNO4MFr8rGakD0rCXxcGGWkAZ
5m2X10LvBHVJDoMP0nLScdXdmHAjS6peNME2wuGOiqFy3xuFXbabMgGi9AlO
mGSwDi+clNhtKPhBKrBB7AE+kcMdddeVErZgvCD+iUsrqeLBSMPeMRz7b70t
1C1usr431MVU8qfnRd3iQHFvDXtSfku7XFLyyeR6F12PpT+fq7+Esa15oj6E
nP0hYG0rZB9fP4PWImG+obSpQOfRTVdAT150eGES20a/nWnlbYfe0sZyb5Kx
dTs7y718I4NrWJM926rJhnIpf4Em+w1rsufpEo+Nyux+wHP9771z/QGPu0VP
ttDptS9EjpvgQQuMZi+hfyzVthxukvjr/WGlNwQjONCUNFBQAuctWLB8qAKe
dLXC9WGsN6g9HDsxjXDMjWLkvX12Li8REks8Uhc9RLJNdPfEwzUjlDuT5NBM
VykVNwhKwbMhmCsQQyjjhOI+PQU+5Lxx6oPJgbAZ4qpRlKfYLx9L5OGzrdvG
MoJloF+eTIyLxIMss/Lwfh3RbdcPxJd6z/liMTqA7R9ALHyhiyfdChAKTWnO
/eFBALwYkw7B+QTA11YxjpiQ68RmziAlJDsA6CLpbxzgucj6Y7725KGXCKN3
ouApJnNprpELtyDPM8uulHJEovLNxbRyu1uwaK6dureUdZF0gjZpLYCZtneZ
9zN793EMdKqj0KKbO9dTgOevt4ljjQm3ZTbcE9vxcHMU2982Xl66XHmsFzSF
2yrA9DnewTCJ/+lqN9JXdJ2JS/URTeYBRDSb3rsPjeXLBzH6RucQgod6zFHU
B3sPIzLQ5vZxQp7wdOfsDNSDOLluZzOtM/QM2lwMt+rnDbp3nXrtpKG4QU+H
IcjXNk3M2OWEioKSrYmihoEIkafTQ9M3k/PApkLkbA/Yz5EcDaUIA6iE3qhr
uvlSDo435UIT1alx5qjwGOZWZodKqRDecAytvF/TzcjvP+rNh9HQL+9tKoYP
1lUN9cRKIm+vMH0Fnh34Dgq9MudB7L2vg1lXvfxh5vYgpMF1ibcoIYgZvBxW
501dV4py1UJd0XszKNWaPctGNy/WZZDYSlV5/RHf357PKufjadtvR0TL57ub
34+oDmZ4jTFiHyNZJEdTzh1aVxqNuMzgivi9KZ275Hhu8DKrIDWASNAKDTI8
lxcjPYpkpA28IFmI6UTvd2AILFJMycE3c0t2VUY6JodyFIZRvuJZW9V03QeO
SbKQ4kj46g7KLzr2YmZlgiXnR0bHM4txhkfSMw5iYhadwTzTWvJyucxzvCYF
xwjwovZJOlG/N0lj+OpGd4kmNoX12Ts3XTK0Jl/J3aF0/SYxD030QOZik+I5
yk547olXd7pxDMNZZYwjVPJcVD7j4rLmVDn31Guq4KWXRezyXj/r2FCWMGur
twUplhqmd3ZmUL6Apk7i6KQzNOnmQLbzYIxmqcq9O/30xcElmHRyGnMyAN2j
d2N66f826iRfQAV0wvQHnHQzZHuNqp2Tc36hdi8E5/9Nwg68FhbzAyHx8wJv
YP2lLWbuImyhjp/4T8ZHEyjZ/JgKQFC6WoWFBt1WW5V0U2J49bAgeYrkCqVJ
4y2BurUJJ5syCeaB2/N4m4kfZJXDWupG8jABR6QzkijQcCLbpXL73SZYSuwQ
R+0j18ag/6Bqa7RK3vzbkePfVIFNRwwsWdgwIrz7tprBmzDMaoz38S1zruRm
7XrJpfz20dfIHhnbMWjY0p02Yhs9Oyswh/NyE6T/G74eh2tcGyeh8aYyczZn
Jj8FLyKvSmbOY8oQ5e/JH5JXx7+7mpJnbbnqyd4zHMuDjRIoiUgMsnG9Zkl8
YOaSGLskSSgLJdmgpNdCNjln4EkZCnu5tE7LUmHME3WR+pLgq5Wmm68pJYk5
qV2L1qHGg/z+9Rkjt3SGeQO40rN8wQOXtI6Oc9MMv6fqsDwxa8wcfAsuUvge
9EmZwXI31BEOT4ZvTvDvqSIj1eYQsttM9uZMqKV7sfbIv+oZr7nGrBvcZ8mE
9frBq/98QLP0aO/hQ7r4ns1Myy9iVNFVFScwcXKPL49TktmYeaTrOwMGcB0u
/FQ4HrdxklCeH3vndz9jEQU+GnmmKNF5ilEnvpjDwAkYYjJlpxDNmC7KdkFa
xJ8syweceiUmcGUK/ZsfeFkjd7laC2S3YoFyrccGTMYjyUomhHzJizZJjuYd
LzNdM5fXyNwZMrngwsDalKJjk+oMxonjSB7UWndMhjB/48ORrwNQfps5Ewpi
sooE9RARosDkF+KAMJlGYmp7ZJGby72KmBXdtizua4RYiNamLebFDxc3Z+CD
qfwYgXbsPZCZSmJzZNqmRB0dauIVo6WapzOskGWMGzX1PDhY72UF9ZLA0lZi
EspgY3oNb032ExkjOfxExgehDsz7F8aTdCPxgxliUIOgX+qs5EQ+iQepKQlg
WU1zCXDxA+AlZ2G+ZlA7MGLm00NmPcOnz8/07CMx6oFJG+1uge8Ib8odQ4wF
659Z2A7GvyIj4Uy69m4OwRC+QA9Tznr+ILENjPbzc7odSfIjvIEQg8xzuhlB
So6hPRJNli6YaKtsoEl/qyfxcwv2JnC3t5jo4u0ppZpO5ZLrtsDMs7CA/gLK
3rVm7+TwquykVi3oAjuWgaytO6nTKOVFWyeX+3ydSV5U89m3O8AXLoG3STeL
nagyyeBoLyr/WFBMWQdzC4YHbNSUMwCB5lLrqWRlkm0zkzqXN+fI7iAVxDIU
eJsK02WshW7Gh1U6b9hgx0TiJg9kihgMXkqX4ZUTmEH3N9883ZNDZvybzUvW
7bLJdGWGC9YoAibKVY4qu65zybJ89OL0ByyO+DeDcdRevkvGvvBlUYmPJMNO
m4y+mLzuzZLUbmEvHMY6l7kZM0qnBN0jgCpxl69j0BJSsx5B/HGDtxrC+qVC
ss+YYB+hrR84ieeKUoCCStFzWAy8U0xZAGEeeI/y3ASEIGpwuTwkEgJIIKHx
Kd9JbfEsNEfkILSfgxorcefHHD/gi5OFiKn4vVcocwRySSJMk6wKCiTAE+my
ZEqYDNB9/iIdmldqrtm8oa2/FGB4TTc2p9l5XnOtjs6sN7pV+RnlrGvCJGBG
9hmpHadTUnSLwVI4z/UF7U+gec5eowTQVctXWyKzLAqw+7WNyTS+LnszUq1c
RkYk+1QXsEjI72POacxo68BlA6W7pnDZa7Q4Cr58hYwGoFGCW9tV7jgFuzbX
OpuScWbbWqUZYz5LCMwALgu15oxQKyLqxCSHa9fGWvb4UkateNQJFLD5jnwO
4pM82Hf0Fjc7E8Z5zr8ITVMiRZizkpXSGVGNMmuVbbMU24WrNtQj6+3y8vsS
8yOdnBxfXfGD4xy0vny/hx5SxgjP/Vmg6+3paimTpxwtJ5hW/yIZd/cOmS5e
7lZQUUtMxg5m6R15z27sO8OOuytoPE884SwveS+l85bJQKgByKC2g5X7eESN
yR00DOMKfeG52RC1a+9GLAtRyKlodK1OCxSV6METp0DeU+yyeoi5yCFBth9d
BRFcawbsi3ewgWoxCcmxvbpHV1ZlB68OejMb3j52xsf5qWQ6Y1MuScbjscJV
QTedzVCDLTHdJK1KUIUmW+a3O3MAr/ZuZwY25O3/WKvvy6n6HpDMSB1k6Uod
p7iXuxlhboFGvWz1colgFOfx7QY45mSpYdFSruYVwk+zas2kOE/VksUWPi9R
KhvvJ83jSOHlGRWo3yJjTy6bORleJVyujZ3j0Khcs8ddp7xx0v+XlAgUfi1X
tQiLfy2nyUmR/5JRrvqyctKj7Ky+SfJfveq5UdWSAAA=
<!-- [rfced] The SVG figures in this document have width or height specified,
which will make the artwork not scale. Please consider whether scaling
should be enabled. Scaling will allow the figures to be resized when
viewed on a mobile device; however, there may be aesthetic trade-offs
(e.g., a given image may appear too large on a desktop screen, or
different figures may scale differently based on their relative sizes).
Please review Figures 1-8 in the HTML and PDF outputs, and let us know how
to proceed.
-->
<!-- [rfced] The following terms appear both with and without <tt> in the xml
file. Should all instances (aside from those in figures) be marked with <tt>?
policy_mapping
valid_policy_graph
valid_policy
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
--> -->
</rfc> </rfc>
 End of changes. 94 change blocks. 
853 lines changed or deleted 788 lines changed or added

This html diff was produced by rfcdiff 1.48.