rfc9829.original.xml | rfc9829.xml | |||
---|---|---|---|---|
<?xml version='1.0' encoding='UTF-8'?> | <?xml version='1.0' encoding='UTF-8'?> | |||
<!-- draft submitted in xml v3 --> | ||||
<!DOCTYPE rfc [ | <!DOCTYPE rfc [ | |||
<!ENTITY nbsp " "> | <!ENTITY nbsp " "> | |||
<!ENTITY zwsp "​"> | <!ENTITY zwsp "​"> | |||
<!ENTITY nbhy "‑"> | <!ENTITY nbhy "‑"> | |||
<!ENTITY wj "⁠"> | <!ENTITY wj "⁠"> | |||
]> | ]> | |||
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie | |||
category="std" | tf-sidrops-rpki-crl-numbers-05" number="9829" ipr="trust200902" xml:lang="en" so | |||
docName="draft-ietf-sidrops-rpki-crl-numbers-05" | rtRefs="true" submissionType="IETF" consensus="true" updates="6487" obsoletes="" | |||
ipr="trust200902" | symRefs="true" tocInclude="true" version="3"> | |||
xml:lang="en" | ||||
sortRefs="true" | ||||
submissionType="IETF" | ||||
consensus="true" | ||||
updates="6487" | ||||
obsoletes="" | ||||
symRefs="true" | ||||
tocInclude="true" | ||||
version="3"> | ||||
<front> | <front> | |||
<title abbrev="RPKI CRL Number handling"> | <title abbrev="RPKI CRL Number Handling">Handling of Resource Public Key Inf | |||
Handling of Resource Public Key Infrastructure (RPKI) Certificate Revocati | rastructure (RPKI) Certificate Revocation List (CRL) Number Extensions</title> | |||
on List (CRL) Number Extensions | <seriesInfo name="RFC" value="9829"/> | |||
</title> | ||||
<author fullname="Job Snijders" initials="J." surname="Snijders"> | <author fullname="Job Snijders" initials="J." surname="Snijders"> | |||
<organization /> | ||||
<address> | <address> | |||
<postal> | <postal> | |||
<postalLine>Amsterdam</postalLine> | <postalLine>Amsterdam</postalLine> | |||
<postalLine>The Netherlands</postalLine> | <postalLine>The Netherlands</postalLine> | |||
</postal> | </postal> | |||
<email>job@sobornost.net</email> | <email>job@sobornost.net</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Ben Maddison" initials="B." surname="Maddison"> | <author fullname="Ben Maddison" initials="B." surname="Maddison"> | |||
<organization>Workonline</organization> | <organization>Workonline</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street/> | ||||
<city>Cape Town</city> | <city>Cape Town</city> | |||
<country>South Africa</country> | <country>South Africa</country> | |||
</postal> | </postal> | |||
<email>benm@workonline.africa</email> | <email>benm@workonline.africa</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Theo Buehler" initials="T." surname="Buehler"> | <author fullname="Theo Buehler" initials="T." surname="Buehler"> | |||
<organization>OpenBSD</organization> | <organization>OpenBSD</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<country>CH</country> | <country>Switzerland</country> | |||
</postal> | </postal> | |||
<email>tb@openbsd.org</email> | <email>tb@openbsd.org</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<date/> | <date month="July" year="2025"/> | |||
<area>Operations and Management Area (OPS)</area> | <area>OPS</area> | |||
<workgroup>SIDROPS</workgroup> | <workgroup>sidrops</workgroup> | |||
<keyword>RPKI</keyword> | <keyword>RPKI</keyword> | |||
<keyword>Routing Security</keyword> | <keyword>Routing Security</keyword> | |||
<keyword>BGP</keyword> | <keyword>BGP</keyword> | |||
<keyword>X.509</keyword> | <keyword>X.509</keyword> | |||
<keyword>CRL</keyword> | <keyword>CRL</keyword> | |||
<abstract> | <abstract> | |||
<t> | <t> | |||
This document revises how the Resource Public Key Infrastructure (RPKI) handles Certificate Revocation List (CRL) Number extensions. | This document revises how the Resource Public Key Infrastructure (RPKI) handles Certificate Revocation List (CRL) Number extensions. | |||
skipping to change at line 92 ¶ | skipping to change at line 74 ¶ | |||
<middle> | <middle> | |||
<section anchor="intro"> | <section anchor="intro"> | |||
<name>Introduction</name> | <name>Introduction</name> | |||
<t> | <t> | |||
<xref target="RFC5280" section="5.2.3" /> describes the value of the Cer tificate Revocation List (CRL) Number extension as a monotonically increasing se quence number, which "allows users to easily determine when a particular CRL sup ersedes another CRL". | <xref target="RFC5280" section="5.2.3" /> describes the value of the Cer tificate Revocation List (CRL) Number extension as a monotonically increasing se quence number, which "allows users to easily determine when a particular CRL sup ersedes another CRL". | |||
In other words, in Public Key Infrastructures (PKIs) in which it is poss ible for Relying Parties (RPs) to encounter multiple usable CRLs, the CRL Number extension is a means for an RP to determine which CRLs to rely upon. | In other words, in Public Key Infrastructures (PKIs) in which it is poss ible for Relying Parties (RPs) to encounter multiple usable CRLs, the CRL Number extension is a means for an RP to determine which CRLs to rely upon. | |||
</t> | </t> | |||
<t> | <t> | |||
In the Resource Public Key Infrastructure (RPKI), a well-formed Manifest FileList contains exactly one entry for its associated CRL, together with a col lision-resistant message digest of that CRL's contents (see <xref target="RFC648 1" section="2.2"/> and <xref target="RFC9286" section="2"/>). | In the Resource Public Key Infrastructure (RPKI), a well-formed Manifest fileList contains exactly one entry for its associated CRL, together with a col lision-resistant message digest of that CRL's contents (see <xref target="RFC648 1" section="2.2"/> and <xref target="RFC9286" section="2"/>). | |||
Additionally, the target of the CRL Distribution Points extension in an RPKI Resource Certificate is the same CRL object listed on the issuing Certifica tion Authorities (CAs) current manifest (see <xref target="RFC6487" section="4.8 .6"/>). | Additionally, the target of the CRL Distribution Points extension in an RPKI Resource Certificate is the same CRL object listed on the issuing Certifica tion Authorities (CAs) current manifest (see <xref target="RFC6487" section="4.8 .6"/>). | |||
Together, these properties guarantee that RPKI RPs will always be able t o unambiguously identify exactly one current CRL for each RPKI CA. | Together, these properties guarantee that RPKI RPs will always be able t o unambiguously identify exactly one current CRL for each RPKI CA. | |||
Thus, in the RPKI, the ordering functionality provided by CRL Numbers is fully subsumed by monotonically increasing Manifest Numbers (<xref target="RFC9 286" section="4.2.1"/>), thereby obviating the need for RPKI RPs to process CRL Number extensions at all. | Thus, in the RPKI, the ordering functionality provided by CRL Numbers is fully subsumed by monotonically increasing Manifest Numbers (<xref target="RFC9 286" section="4.2.1"/>), thereby obviating the need for RPKI RPs to process CRL Number extensions at all. | |||
</t> | </t> | |||
<t> | <t> | |||
Therefore, although the CRL Number extension is mandatory in RPKI CRLs f or compliance with the X.509 v2 CRL Profile (<xref target="RFC5280" section="5"/ >), any use of this extension by RPKI RPs merely adds complexity and fragility t o RPKI Resource Certificate path validation. | Therefore, although the CRL Number extension is mandatory in RPKI CRLs f or compliance with the X.509 v2 CRL Profile (<xref target="RFC5280" section="5"/ >), any use of this extension by RPKI RPs merely adds complexity and fragility t o RPKI Resource Certificate path validation. | |||
This document mandates that RPKI RPs ignore the CRL Number extension. | This document mandates that RPKI RPs ignore the CRL Number extension. | |||
</t> | </t> | |||
<t> | <t> | |||
This document updates <xref target="RFC6487"/>. | This document updates <xref target="RFC6487"/>. | |||
Refer to <xref target="Updates"/> for more details. | Refer to <xref target="Updates"/> for more details. | |||
</t> | </t> | |||
<section anchor="reqs-lang"> | <section anchor="reqs-lang"> | |||
<name>Requirements Language</name> | <name>Requirements Language</name> | |||
<t> | <t> | |||
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 | The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", | |||
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14> | "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14> | |||
SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bc | ", | |||
p14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14> | "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", | |||
" in this document are to be interpreted as described in BCP 14 <xref targe | "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | |||
t="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all c | "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to | |||
apitals, as shown here.</t> | be | |||
interpreted as described in BCP 14 <xref target="RFC2119"/> <xref | ||||
target="RFC8174"/> when, and only when, they appear in all capitals, as | ||||
shown here. | ||||
</t> | ||||
</section> | </section> | |||
<section anchor="Related"> | <section anchor="Related"> | |||
<name>Related Work</name> | <name>Related Work</name> | |||
<t> | <t> | |||
It is assumed that the reader is familiar with the terms and concepts de | The reader is assumed to be familiar with the terms and concepts describ | |||
scribed in | ed in "Internet X.509 Public Key Infrastructure Certificate | |||
"<xref target="RFC5280" format="title"/>" <xref target="RFC5280" format= | and Certificate Revocation List (CRL) Profile" | |||
"default"/>, | <xref target="RFC5280" />, "A Profile | |||
"<xref target="RFC6481" format="title"/>" <xref target="RFC6481" format= | for Resource Certificate Repository Structure" <xref target="RFC6481" format= | |||
"default"/>, and | "default"/>, and "Manifests for the Resource Public Key Infrastructure (RPKI)" < | |||
"<xref target="RFC9286" format="title"/>" <xref target="RFC9286" format= | xref target="RFC9286" format="default"/>. | |||
"default"/>. | ||||
</t> | </t> | |||
</section> | </section> | |||
<section anchor="Changes"> | <section anchor="Changes"> | |||
<name>Changes from RFC 6487</name> | <name>Changes from RFC 6487</name> | |||
<t> | <t> | |||
This section summarizes the significant changes between <xref target=" RFC6487"/> and this document. | This section summarizes the significant changes between <xref target=" RFC6487"/> and this document. | |||
</t> | </t> | |||
<!-- [rfced] We have added an informative reference to erratum 3206. Please let | ||||
us know if you have any concerns. | ||||
Original: | ||||
* Integration of RFC 6487 Errata 3205. | ||||
Current: | ||||
* Integration of Errata 3205 [Err3205]. | ||||
--> | ||||
<ul> | <ul> | |||
<li>Revision of CRL Number handling.</li> | <li>Revision of CRL Number handling.</li> | |||
<li>Adjustment of step 5 of the Resource Certification Path Validation .</li> | <li>Adjustment of step 5 of the Resource Certification Path Validation .</li> | |||
<li>Integration of RFC 6487 Errata 3205.</li> | <li>Integration of Errata 3205 <xref target="Err3205"/>.</li> | |||
</ul> | </ul> | |||
</section> | </section> | |||
</section> | </section> | |||
<section> | <section> | |||
<name>Summary</name> | <name>Summary</name> | |||
<t> | <t> | |||
This document clarifies that, in the RPKI, there is exactly one CRL appr opriate and relevant for determining the revocation status of a given resource c ertificate. | This document clarifies that, in the RPKI, there is exactly one CRL that is appropriate and relevant for determining the revocation status of a given re source certificate. | |||
It is the unique CRL object that is simultaneously: | It is the unique CRL object that is simultaneously: | |||
</t> | </t> | |||
<ul> | <ul> | |||
<li>the target of the certificate's CRL Distribution Points extension, a nd</li> | <li>the target of the certificate's CRL Distribution Points extension, a nd</li> | |||
<li>listed in the issuing CA's current Manifest FileList and has matchin | ||||
g hash (see <xref target="RFC9286" section="4.2.1"/>).</li> | <!-- [rfced] RFC 9286 defines "fileList" rather than "FileList". We have update | |||
d the document accordingly. Please let us know any corrections. | ||||
Original: | ||||
In the Resource Public Key Infrastructure (RPKI), a well-formed | ||||
Manifest FileList contains exactly one entry for its associated CRL, ... | ||||
Original: | ||||
* listed in the issuing CA's current Manifest FileList and has | ||||
matching hash (see Section 4.2.1 of [RFC9286]). | ||||
Original: | ||||
By way of the hash in the manifest's FileList this | ||||
provides a cryptographic guarantee on the Certification Authority's ... | ||||
In addition, note that the following terminology appears to be used | ||||
inconsistently throughout the document. Please review these occurrences | ||||
and let us know if/how they may be made consistent. | ||||
Manifest FileList vs manifest's FileList (note that we will lowercase FileList a | ||||
s noted above.) | ||||
Manifest vs manifest (6487 and 9286 seem to use "manifest" except where it's par | ||||
t of a specific name.) | ||||
--> | ||||
<li>listed in the issuing CA's current Manifest fileList and has a match | ||||
ing hash (see <xref target="RFC9286" section="4.2.1"/>).</li> | ||||
</ul> | </ul> | |||
<!-- [rfced] We are not sure what "without recourse" means here. Does it mean " | ||||
without access to"? Please clarify. | ||||
Original: | ||||
In particular, a resource certificate cannot be validated without | ||||
recourse to the current Manifest of the certificate's issuer. | ||||
--> | ||||
<t> | <t> | |||
In particular, a resource certificate cannot be validated without recour se to the current Manifest of the certificate's issuer. | In particular, a resource certificate cannot be validated without recour se to the current Manifest of the certificate's issuer. | |||
</t> | </t> | |||
</section> | </section> | |||
<section anchor="Updates"> | <section anchor="Updates"> | |||
<name>Updates to RFC 6487</name> | <name>Updates to RFC 6487</name> | |||
<section> | <section> | |||
<name>Updates to Section 5</name> | <name>Updates to Section 5</name> | |||
skipping to change at line 174 ¶ | skipping to change at line 204 ¶ | |||
<t>OLD</t> | <t>OLD</t> | |||
<blockquote> | <blockquote> | |||
<t> | <t> | |||
Where two or more CRLs are issued by the same CA, the CRL with the highest value of the "CRL Number" field supersedes all other CRLs issued by thi s CA. | Where two or more CRLs are issued by the same CA, the CRL with the highest value of the "CRL Number" field supersedes all other CRLs issued by thi s CA. | |||
</t> | </t> | |||
</blockquote> | </blockquote> | |||
<t>NEW</t> | <t>NEW</t> | |||
<blockquote> | <blockquote> | |||
<t> | <t> | |||
Per <xref target="RFC5280" section="5.2.3"/>, CAs issue new CRLs u sing a monotonically increasing sequence number in the "CRL Number" extension. | Per <xref target="RFC5280" section="5.2.3"/>, CAs issue new CRLs u sing a monotonically increasing sequence number in the "CRL Number" extension. | |||
It is RECOMMENDED that the "CRL Number" matches the "manifestNumbe r" of the manifest that will include this CRL (see <xref target="RFC9286" sectio n="4.2.1" />). | It is <bcp14>RECOMMENDED</bcp14> that the "CRL Number" match the " manifestNumber" of the manifest that will include this CRL (see <xref target="RF C9286" section="4.2.1" />). | |||
</t> | </t> | |||
</blockquote> | </blockquote> | |||
</li> | </li> | |||
<li> | <li> | |||
<t>Second change:</t> | <t>Second change:</t> | |||
<t>OLD</t> | <t>OLD</t> | |||
<blockquote> | <blockquote> | |||
<t> | <t> | |||
An RPKI CA MUST include the two extensions, Authority Key Identifi | An RPKI CA <bcp14>MUST</bcp14> include the two extensions, Authori | |||
er and CRL Number, in every CRL that it issues. | ty Key Identifier and CRL Number, in every CRL that it issues. | |||
RPs MUST be prepared to process CRLs with these extensions. | RPs <bcp14>MUST</bcp14> be prepared to process CRLs with these ext | |||
ensions. | ||||
No other CRL extensions are allowed. | No other CRL extensions are allowed. | |||
</t> | </t> | |||
</blockquote> | </blockquote> | |||
<t>NEW</t> | <t>NEW</t> | |||
<blockquote> | <blockquote> | |||
<t> | <t> | |||
An RPKI CA MUST include exactly two extensions in every CRL that i t issues: an Authority Key Identifier (AKI) and a CRL Number. | An RPKI CA <bcp14>MUST</bcp14> include exactly two extensions in e very CRL that it issues: an Authority Key Identifier (AKI) and a CRL Number. | |||
No other CRL extensions are allowed. | No other CRL extensions are allowed. | |||
</t> | </t> | |||
<ul> | <ul> | |||
<li>RPs MUST process the AKI extension.</li> | <li>RPs <bcp14>MUST</bcp14> process the AKI extension.</li> | |||
<li>RPs MUST ignore the CRL Number extension except for checking t | <!-- [rfced] We have updated the text to use superscript (see <https://authors.i | |||
hat it is marked as non-critical and contains a non-negative integer less than o | etf.org/rfcxml-vocabulary#sup> for more information). Please let us know if thi | |||
r equal to 2^159-1.</li> | s is incorrect or not desired. | |||
Original: | ||||
2^159-1 | ||||
The HTML and PDF will display 159-1 as an exponent. | ||||
The text will display as follows: | ||||
2^(159-1) | ||||
--> | ||||
<li>RPs <bcp14>MUST</bcp14> ignore the CRL Number extension except | ||||
for checking that it is marked as non-critical and contains a non-negative inte | ||||
ger less than or equal to 2<sup>159-1</sup>.</li> | ||||
</ul> | </ul> | |||
</blockquote> | </blockquote> | |||
</li> | </li> | |||
</ul> | </ul> | |||
</section> | </section> | |||
<section> | <section> | |||
<name>Update to Section 7.2</name> | <name>Update to Section 7.2</name> | |||
<t> | <t> | |||
This section updates <xref target="RFC6487" section="7.2"/> as follows: | This section updates <xref target="RFC6487" section="7.2"/> as follows: | |||
skipping to change at line 229 ¶ | skipping to change at line 270 ¶ | |||
A revoked certificate is identified by the certificate's serial number b eing listed on the issuer's current CRL, as identified by the issuer's current M anifest and the CRLDP of the certificate. | A revoked certificate is identified by the certificate's serial number b eing listed on the issuer's current CRL, as identified by the issuer's current M anifest and the CRLDP of the certificate. | |||
The CRL is itself valid and the public key used to verify the signature on the CRL is the same public key used to verify the certificate itself.</li> | The CRL is itself valid and the public key used to verify the signature on the CRL is the same public key used to verify the certificate itself.</li> | |||
</ol> | </ol> | |||
</blockquote> | </blockquote> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="operational"> | <section anchor="operational"> | |||
<name>Operational Considerations</name> | <name>Operational Considerations</name> | |||
<!-- [rfced] For clarity, may we update the text as follows? | ||||
Original: | ||||
This document has no additional operational considerations compared | ||||
to Section 9 of [RFC6487]. | ||||
Perhaps: | ||||
This document has no additional operational considerations beyond those | ||||
described in Section 9 of [RFC6487]. | ||||
--> | ||||
<t> | <t> | |||
This document has no additional operational considerations compared to <xr ef target="RFC6487" section="9"/>. | This document has no additional operational considerations compared to <xr ef target="RFC6487" section="9"/>. | |||
</t> | </t> | |||
</section> | </section> | |||
<section anchor="security"> | <section anchor="security"> | |||
<name>Security Considerations</name> | <name>Security Considerations</name> | |||
<t> | <t> | |||
The Security Considerations of <xref target="RFC3779"/>, <xref target="R FC5280"/>, and <xref target="RFC6487"/> apply to Resource Certificates and CRLs. | The Security Considerations of <xref target="RFC3779"/>, <xref target="R FC5280"/>, and <xref target="RFC6487"/> apply to Resource Certificates and CRLs. | |||
</t> | </t> | |||
<t> | <t> | |||
This document explicates that, in the RPKI, the CRL listed on the certif icate issuer's current Manifest is the one relevant and appropriate for determin ing the revocation status of a resource certificate. | This document explicates that, in the RPKI, the CRL listed on the certif icate issuer's current Manifest is the one relevant and appropriate for determin ing the revocation status of a resource certificate. | |||
By way of the hash in the manifest's FileList this provides a cryptograp | <!-- [rfced] This sentence uses "this" twice in the second sentence and they see | |||
hic guarantee on the Certification Authority's intent that this is the most rece | mingly refer to different things. What does each instance of "this" refer to? | |||
nt CRL and removes possible replay vectors. | Please review. | |||
Note that the first sentence is provided for context. | ||||
Original: | ||||
This document explicates that, in the RPKI, the CRL listed on the | ||||
certificate issuer's current Manifest is the one relevant and | ||||
appropriate for determining the revocation status of a resource | ||||
certificate. By way of the hash in the manifest's FileList this | ||||
provides a cryptographic guarantee on the Certification Authority's | ||||
intent that this is the most recent CRL and removes possible replay | ||||
vectors. | ||||
--> | ||||
By way of the hash in the manifest's fileList this provides a cryptograp | ||||
hic guarantee on the Certification Authority's intent that this is the most rece | ||||
nt CRL and removes possible replay vectors. | ||||
</t> | </t> | |||
</section> | </section> | |||
<section anchor="iana"> | <section anchor="iana"> | |||
<name>IANA Considerations</name> | <name>IANA Considerations</name> | |||
<t> | <t> | |||
This document has no IANA actions. | This document has no IANA actions. | |||
</t> | </t> | |||
</section> | </section> | |||
</middle> | </middle> | |||
<back> | <back> | |||
<references> | <references> | |||
<name>References</name> | <name>References</name> | |||
<references> | <references> | |||
<name>Normative References</name> | <name>Normative References</name> | |||
skipping to change at line 274 ¶ | skipping to change at line 340 ¶ | |||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 174.xml"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 174.xml"/> | |||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 286.xml"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 286.xml"/> | |||
</references> | </references> | |||
<references> | <references> | |||
<name>Informative References</name> | <name>Informative References</name> | |||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3 779.xml"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3 779.xml"/> | |||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 280.xml"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 280.xml"/> | |||
<reference anchor="Err3205" target="https://www.rfc-editor.org/errata/eid3205 " quoteTitle="false"> | ||||
<reference anchor="rpki-client" target="https://www.rpki-client.org/"> | <front> | |||
<front> | <title>RFC Errata, Erratum ID 3205</title> | |||
<title>rpki-client</title> | ||||
<author fullname="Claudio Jeker"/> | ||||
<author fullname="Job Snijders"/> | ||||
<author fullname="Kristaps Dzonsons"/> | ||||
<author fullname="Theo Buehler"/> | ||||
<date month="June" year="2024" /> | ||||
</front> | ||||
</reference> | ||||
<reference anchor="FORT" target="https://fortproject.net/en/validator"> | <author initials="" surname="" fullname=""> | |||
<front> | <organization /> | |||
<title>FORT validator</title> | </author> | |||
<author fullname="Alberto Leiva"/> | ||||
<date/> | ||||
</front> | ||||
</reference> | ||||
<reference anchor="routinator" target="https://github.com/NLnetLabs/rout | </front> | |||
inator"> | <seriesInfo name="RFC" value="6487" /> | |||
<front> | </reference> | |||
<title>Routinator</title> | ||||
<author fullname="NLnetLabs"/> | ||||
<date/> | ||||
</front> | ||||
</reference> | ||||
</references> | </references> | |||
</references> | </references> | |||
<section title="Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATIO | ||||
N"> | ||||
<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, an | ||||
d 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 presente | ||||
d here that was supplied by IETF contributors. | ||||
This is not intended as, and must not be construed to be, a catalog of a | ||||
vailable 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, whi | ||||
ch 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 the | ||||
y see fit". | ||||
</t> | ||||
<ul> | ||||
<li> | ||||
OpenBSD <xref target="rpki-client"/> | ||||
</li> | ||||
<li> | ||||
<xref target="FORT"/> | ||||
</li> | ||||
<li> | ||||
<xref target="routinator"/> | ||||
</li> | ||||
</ul> | ||||
</section> | ||||
<section anchor="acknowledgements" numbered="false"> | <section anchor="acknowledgements" numbered="false"> | |||
<name>Acknowledgements</name> | <name>Acknowledgements</name> | |||
<t> | <t> | |||
The authors wish to thank <contact fullname="Tom Harrison"/> whose observa tions prompted this document, <contact fullname="Alberto Leiva"/>, <contact full name="Tim Bruijnzeels"/>, <contact fullname="Mohamed Boucadair"/>, <contact full name="Geoff Huston"/>, and the IESG for their valuable comments and feedback. | The authors wish to thank <contact fullname="Tom Harrison"/> whose observa tions prompted this document, <contact fullname="Alberto Leiva"/>, <contact full name="Tim Bruijnzeels"/>, <contact fullname="Mohamed Boucadair"/>, <contact full name="Geoff Huston"/>, and the IESG for their valuable comments and feedback. | |||
</t> | </t> | |||
</section> | </section> | |||
<!-- [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. Updates of this nature typically | ||||
result in more precise language, which is helpful for readers. | ||||
Note that our script did not flag any words in particular, but this should | ||||
still be reviewed as a best practice. | ||||
--> | ||||
</back> | </back> | |||
</rfc> | </rfc> | |||
End of changes. 29 change blocks. | ||||
124 lines changed or deleted | 151 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |