rfc9981xml2.original.xml   rfc9981.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!DOCTYPE rfc [
.2119.xml"> <!ENTITY nbsp "&#160;">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY zwsp "&#8203;">
.8174.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC6480 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY wj "&#8288;">
.6480.xml">
<!ENTITY RFC6481 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6481.xml">
<!ENTITY RFC6487 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6487.xml">
<!ENTITY RFC6488 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6488.xml">
<!ENTITY RFC6489 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6489.xml">
<!ENTITY RFC7942 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7942.xml">
<!ENTITY RFC8182 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8182.xml">
<!ENTITY RFC8630 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8630.xml">
<!ENTITY RFC8488 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8488.xml">
<!ENTITY RFC9286 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.9286.xml">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<?rfc strict="yes" ?> tf-sidrops-manifest-numbers-09" number="9981" ipr="trust200902" updates="9286" c
<?rfc toc="yes"?> onsensus="true" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="tru
<?rfc tocdepth="3"?> e" tocDepth="3" symRefs="true" sortRefs="true" version="3">
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std"
docName="draft-ietf-sidrops-manifest-numbers-09"
ipr="trust200902" updates="9286" consensus="true">
<front> <front>
<title abbrev="RPKI Manifest Number Handling">Resource Public Key Infrastruc ture (RPKI) Manifest Number Handling</title> <title abbrev="RPKI Manifest Number Handling">Resource Public Key Infrastruc ture (RPKI) Manifest Number Handling</title>
<seriesInfo name="RFC" value="9981"/>
<author initials="T." surname="Harrison" fullname="Tom Harrison"> <author initials="T." surname="Harrison" fullname="Tom Harrison">
<organization abbrev="APNIC">Asia Pacific Network Information Centre</or <organization abbrev="APNIC">Asia Pacific Network Information Centre</orga
ganization> nization>
<address> <address>
<postal> <postal>
<street>6 Cordelia St</street> <street>6 Cordelia St</street>
<city>South Brisbane</city> <city>South Brisbane</city>
<code>4101</code> <code>4101</code>
<country>Australia</country> <country>Australia</country>
<region>QLD</region> <region>QLD</region>
</postal> </postal>
<email>tomh@apnic.net</email> <email>tomh@apnic.net</email>
</address> </address>
</author> </author>
<author fullname="George G. Michaelson" initials="G." surname="Michaelson"> <author fullname="George G. Michaelson" initials="G." surname="Michaelson">
<organization abbrev="APNIC">Asia-Pacific Network Information Centre</org <organization abbrev="APNIC">Asia-Pacific Network Information Centre</orga
anization> nization>
<address>
<address> <postal>
<postal> <street>6 Cordelia St</street>
<street>6 Cordelia St</street> <city>South Brisbane</city>
<city>South Brisbane</city> <region>QLD</region>
<region>QLD</region> <code>4101</code>
<code>4101</code> <country>Australia</country>
<country>Australia</country> </postal>
</postal> <email>ggm@apnic.net</email>
<email>ggm@apnic.net</email> </address>
</address>
</author>
<author fullname="Job Snijders" initials="J." surname="Snijders">
<organization></organization>
<address>
<postal>
<street/>
<city>Amsterdam</city>
<region/>
<country>Netherlands</country>
</postal>
<email>job@sobornost.net</email>
</address>
</author> </author>
<author fullname="Job Snijders" initials="J." surname="Snijders">
<organization abbrev="BSD">BSD Software Development</organization>
<address>
<postal>
<postalLine>Amsterdam</postalLine>
<postalLine>The Netherlands</postalLine>
</postal>
<email>job@bsd.nl</email>
<uri>https://www.bsd.nl</uri>
</address>
</author>
<date month="May" year="2026"/>
<area>OPS</area>
<workgroup>sidrops</workgroup>
<date/>
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>template</keyword>
<abstract> <abstract>
<t> <t>
The Resource Public Key Infrastructure (RPKI) makes use of The Resource Public Key Infrastructure (RPKI) makes use of
signed objects called manifests, each of which includes a signed objects called "manifests", each of which includes a
"manifest number". This document updates RFC9286 by "manifest number". This document updates RFC 9286 by
specifying issuer and RP behaviour when a manifest number specifying issuer and Relying Party (RP) behaviour when a manifest n
umber
reaches the largest possible value, a situation not reaches the largest possible value, a situation not
considered in RFC9286. considered in RFC 9286.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t> <name>Introduction</name>
<t>
The Resource Public Key Infrastructure (RPKI) <xref The Resource Public Key Infrastructure (RPKI) <xref target="RFC6480"
target="RFC6480" /> makes use of signed objects <xref format="default"/> makes use of signed objects <xref target="RFC6488" format="d
target="RFC6488" /> called manifests <xref efault"/> called "manifests" <xref target="RFC9286" format="default"/>. A manif
target="RFC9286" />. A manifest lists each file that an est lists each file that an
issuer intends to include within an RPKI repository issuer intends to include within an RPKI repository
<xref target="RFC6481" />, and can be used to detect <xref target="RFC6481" format="default"/>. Manifests can also be use d to detect
certain forms of attack against a repository. Manifests certain forms of attack against a repository. Manifests
include a "manifest number" (manifestNumber), which an include a "manifest number" (manifestNumber), which an
issuer must increment by one whenever it issues a new issuer must increment by one whenever it issues a new
manifest, and Relying Parties (RPs) are required to verify manifest, and Relying Parties (RPs) are required to verify
that a newly-retrieved manifest for a given Certification that a newly retrieved manifest for a given Certification
Authority (CA) has a higher manifestNumber than the Authority (CA) has a higher manifestNumber than the
previously-validated manifest (<xref previously validated manifest (<xref target="RFC9286" sectionFormat=
target="RFC9286" sectionFormat="of" section="4.2.1" />). "of" section="4.2.1" format="default"/>).
</t>
<t> </t>
<t>
However, the manifestNumber field is 20 octets in length However, the manifestNumber field is 20 octets in length
(i.e., bounded), and no behaviour is specified for (i.e., bounded), and no behaviour is specified for
when a manifestNumber reaches the largest possible value when a manifestNumber reaches the largest possible value
(2<sup>159</sup>-1). When that value is reached, some RP (2<sup>159</sup>-1). When that value is reached, some RP
implementations will accept a new manifest for the CA only implementations will accept a new manifest for the CA only
once the current manifest has expired, while others will once the current manifest has expired, while others will
not accept a new manifest at all. not accept a new manifest at all.
</t> </t>
<t>
<t>
While it is practically impossible for an issuer to reach While it is practically impossible for an issuer to reach
the largest possible value under normal operating the largest possible value under normal operating
conditions (it would require that the issuer issue one conditions (it would require that the issuer issue one
manifest per second for 23,171,956,451,847,141,650,870 manifest per second for 23,171,956,451,847,141,650,870
quintillion years), there is still a chance that it could quintillion years), there is still a chance that it could
be reached due to bugs in the issuance or publication be reached due to bugs in the issuance or publication
systems or incorrect/inadvertent use of those systems. systems or incorrect/inadvertent use of those systems.
For example: For example:
<ul> </t>
<ul>
<li>Incrementing by large values when issuing <li>Incrementing by large values when issuing
manifests, such that the time to reach that largest manifests, such that the time to reach that largest
value is reduced.</li> value is reduced.</li>
<li>Reissuing new manifests in an infinite delay-free
<li>Reissuing new manifests in an infinite delay-free
loop, such that the manifestNumber increases by a loop, such that the manifestNumber increases by a
large value in a comparatively short period of large value in a comparatively short period of
time.</li> time.</li>
<li>Inadvertently setting the manifestNumber to the
<li>Inadvertently setting the manifestNumber to the
largest possible value, such that the issuer will largest possible value, such that the issuer will
no longer be able to publish usable manifests for that no longer be able to publish usable manifests for that
repository.</li> repository.</li>
</ul>
</ul> <t>
These scenarios might also arise in combination and be more These scenarios might also arise in combination and be more
severe as a result. For example, a CA might increase the severe as a result. For example, a CA might increase the
manifestNumber by a large value on reissuance, and also manifestNumber by a large value on reissuance and also
reissue the manifest more frequently than is necessary. reissue the manifest more frequently than is necessary.
</t> </t>
<t>
<t>
For a subordinate CA, the risk of repository invalidation For a subordinate CA, the risk of repository invalidation
due to such a problem can be addressed by the issuer due to such a problem can be addressed by the issuer
using the key rollover process <xref target="RFC6489" /> using the key rollover process <xref target="RFC6489" format="defaul t"/>
to get a new CA certificate. RPs will treat this new certificate to get a new CA certificate. RPs will treat this new certificate
as though it represents a distinct CA, and the manifestNumber as though it represents a distinct CA; the manifestNumber
can be reset at that point. can be reset at that point.
</t> </t>
<t>
<t>
However, this option is not available for RPKI Trust However, this option is not available for RPKI Trust
Anchors (TAs). If a TA publishes a manifest with the Anchors (TAs). If a TA publishes a manifest with the
largest-possible manifestNumber value, then it is largest-possible manifestNumber value, then it is
difficult to rely on the TA after that point, since difficult to rely on the TA after that point, since
(as described previously) some RPs will not accept a new manifest (as described previously) some RPs will not accept a new manifest
until the current one has expired, while others will until the current one has expired, while others will
reject all new manifests indefinitely. Particularly in reject all new manifests indefinitely. Particularly in
the case of TAs, the manifest validity period may be quite the case of TAs, the manifest validity period may be quite
long, too. Issuing a new TA and distributing the long, too. Issuing a new TA and distributing the
associated Trust Anchor Locator (TAL) <xref target="RFC8630"/> associated Trust Anchor Locator (TAL) <xref target="RFC8630" format= "default"/>
to clients would involve a large amount of work for TA operators to clients would involve a large amount of work for TA operators
and RPs. Additionally, depending on the RP implementation being use d, and RPs. Additionally, depending on the RP implementation being use d,
there would be a limited degree of RPKI protection by way of that TA for there would be a limited degree of RPKI protection by way of that TA for
the time between the issuance of the problematic manifest the time between the issuance of the problematic manifest
and the installation of the new TAL. and the installation of the new TAL.
</t> </t>
<t>
<t>
In order to avoid these problems, this document updates <xref target ="RFC9286"/> In order to avoid these problems, this document updates <xref target ="RFC9286" format="default"/>
by defining how issuers and RPs can handle this scenario in order by defining how issuers and RPs can handle this scenario in order
to facilitate ongoing use of an affected repository. to facilitate ongoing use of an affected repository.
</t>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<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> </t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to 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> </section>
<section anchor="manifest-number-handling" numbered="true" toc="default">
<name>Manifest Number Handling</name>
<t>
<section anchor="manifest-number-handling" title="Manifest Number Handling"> For a given CA, an RP <bcp14>MUST NOT</bcp14> reject a new manifest
<t>
For a given CA, an RP MUST NOT reject a new manifest
issued by that CA on the basis of it not having a higher issued by that CA on the basis of it not having a higher
manifestNumber than a previously-validated manifest if the manifestNumber than a previously validated manifest if the
new manifest has a different filename from that of the new manifest has a different filename from that of the
previously-validated manifest. In other words, an RP has to previously validated manifest. In other words, an RP has to
reset its stored manifestNumber for a given CA if the CA reset its stored manifestNumber for a given CA if the CA
changes the filename of its manifest. This is an update changes the filename of its manifest. This is an update
to the requirements set out in <xref target="RFC9286" to the requirements set out in <xref target="RFC9286" sectionFormat=
sectionFormat="of" section="4.2.1" />. "of" section="4.2.1" format="default"/>.
</t>
<t> </t>
<t>
With this behaviour, it is possible for a CA to be With this behaviour, it is possible for a CA to be
configured such that any time it issues a new manifest, it configured such that, any time it issues a new manifest, it
uses a new filename for that manifest. If a CA were uses a new filename for that manifest. If a CA were
configured in this way, the manifestNumber validation set configured in this way, the manifestNumber validation set
out in <xref target="RFC9286" sectionFormat="of" out in <xref target="RFC9286" sectionFormat="of" section="4.2.1" for
section="4.2.1" /> would have no purpose. To avoid this mat="default"/> would have no purpose. To avoid this
outcome, CAs SHOULD NOT use new filenames for manifests outcome, CAs <bcp14>SHOULD NOT</bcp14> use new filenames for manifes
ts
except in situations where such a change is necessary to except in situations where such a change is necessary to
address the invalidity problem described in this document. address the invalidity problem described in this document.
Similarly, an RP MUST alert its operators when a Similarly, an RP <bcp14>MUST</bcp14> alert its operators when a
manifest filename changes for a given CA. manifest filename changes for a given CA.
</t> </t>
<t anchor="replay">
<t anchor="replay">
<xref target="RFC9286"/> requires that RPs perform two <xref target="RFC9286" format="default"/> requires that RPs perform
replay-related checks on newly-retrieved manifests: two
firstly, that the purported new manifest has a greater replay-related checks on newly retrieved manifests:</t>
manifestNumber than the cached manifest, and secondly, <ol>
that the purported new manifest has a more recent <li>Check that the purported new manifest has a greater
thisUpdate than the cached manifest. An RP that manifestNumber than the cached manifest, and</li>
<li>Check that the purported new manifest has a more recent
thisUpdate than the cached manifest.</li>
</ol>
<t>An RP that
implements the behaviour in this section will momentarily implements the behaviour in this section will momentarily
omit the manifestNumber check following a manifest omit the manifestNumber check following a manifest
filename change. So long as the RP still performs the filename change. So long as the RP still performs the
second check described above, it will be protected against second check described above, it will be protected against
replay attacks. replay attacks.
</t> </t>
</section> </section>
<section anchor="manifest-filenames" numbered="true" toc="default">
<name>Manifest Filenames</name>
<t>
<section anchor="manifest-filenames" title="Manifest Filenames"> A CA specifies its manifest URI by way of a Subject Information Acce
ss (SIA) entry
<t> with an accessMethod of id-ad-rpkiManifest (<xref target="RFC6487" s
ection="4.8.8.1" format="default"/>). For the purposes of this document,
A CA specifies its manifest URI by way of an SIA entry
with an accessMethod of id-ad-rpkiManifest (<xref
target="RFC6487" section="4.8.8.1" />). For the purposes of this do
cument,
the manifest filename is the final segment of the path of the manifest filename is the final segment of the path of
the accessLocation URI from that SIA entry. the accessLocation URI from that SIA entry.
</t> </t>
<t>
<t>
<xref target="RFC6487" sectionFormat="of" <xref target="RFC6487" sectionFormat="of" section="4.8.8.1" format="
section="4.8.8.1" /> states that a CA may include in its default"/> states that a CA may include in its
certificate multiple id-ad-rpkiManifest SIA entries. For certificate multiple id-ad-rpkiManifest SIA entries. For
comparisons, an RP may use the filename from any one of comparisons, an RP may use the filename from any one of
the id-ad-rpkiManifest SIA entries in the the id-ad-rpkiManifest SIA entries in the
previously-validated CA certificate. If that filename previously validated CA certificate. If that filename
does not appear in any of the id-ad-rpkiManifest SIA does not appear in any of the id-ad-rpkiManifest SIA
entries in the CA certificate that is currently being entries in the CA certificate that is currently being
validated, then the manifest filename has changed for the validated, then the manifest filename has changed for the
purposes of this document. purposes of this document.
</t> </t>
<t>
<t>
The corollary of the behaviour defined in the previous The corollary of the behaviour defined in the previous
paragraph is that a CA that includes multiple paragraph is that a CA that includes multiple
id-ad-rpkiManifest SIA entries in its certificate and id-ad-rpkiManifest SIA entries in its certificate and
wants to rely on the behaviour defined in this document wants to rely on the behaviour defined in this document
MUST ensure that none of the manifest filenames in the <bcp14>MUST</bcp14> ensure that none of the manifest filenames in th
previous CA certificate appear in the newly-issued CA e
previous CA certificate appear in the newly issued CA
certificate. If one of the manifest filenames from the certificate. If one of the manifest filenames from the
previous CA certificate appears in the newly-issued CA previous CA certificate appears in the newly issued CA
certificate, then an RP that is using that manifest certificate, then an RP that is using that manifest
filename for comparisons will determine that the manifest filename for comparisons will determine that the manifest
filename for the CA has not changed, and will therefore filename for the CA has not changed and will therefore
not reset its stored manifestNumber for the CA. not reset its stored manifestNumber for the CA.
</t> </t>
</section> </section>
<section anchor="manifest-sia-check" numbered="true" toc="default">
<name>Manifest SIA Verification</name>
<t>
<section anchor="manifest-sia-check" title="Manifest SIA Verification"> To avoid certain forms of replay attack, RPs <bcp14>MUST</bcp14> ver
ify
<t>
To avoid certain forms of replay attack, RPs MUST verify
that the URI in the accessLocation in one of the that the URI in the accessLocation in one of the
id-ad-signedObject accessMethod instances in the id-ad-signedObject accessMethod instances in the
manifest's Subject Information Access (SIA) extension manifest's SIA extension
exactly matches the URI presented in the RPKI Repository exactly matches the URI presented in the RPKI Repository
Delta Protocol (RRDP) <xref target="RFC8182" /> "publish" Delta Protocol (RRDP) <xref target="RFC8182" format="default"/> "pub lish"
element or the path presented by remote rsync servers. If element or the path presented by remote rsync servers. If
this verification check is unsuccessful, then the fetch this verification check is unsuccessful, then the fetch
has failed, and the RP MUST proceed per <xref has failed, and the RP <bcp14>MUST</bcp14> proceed per <xref target=
target="RFC9286" sectionFormat="of" section="6.6" />. "RFC9286" sectionFormat="of" section="6.6" format="default"/>.
</t>
</t>
</section> </section>
<section anchor="rfc8488" numbered="true" toc="default">
<name>Comparison with RFC 8488</name>
<t>
<section anchor="rfc8488" title="RFC8488 Comparison"> <xref target="RFC8488" sectionFormat="of" section="3.2.1" format="de
fault"/> describes a manifest-selection approach
<t> for RPs that involves collecting all unexpired valid
manifests for a CA and then selecting from that
<xref target="RFC8488" sectionFormat="of"
section="3.2.1"/> describes a manifest selection approach
for RPs that involves collecting all unexpired, valid
manifests for a CA, and then selecting from that
collection the manifest that has the highest collection the manifest that has the highest
manifestNumber. The approach set out in this document is manifestNumber. The approach set out in this document is
different from that approach. different from that approach.
</t> </t>
</section> </section>
<section anchor="general-repository-handling" numbered="true" toc="default">
<name>General Repository Handling</name>
<t>
<section anchor="general-repository-handling" title="General Repository Hand <xref target="manifest-number-handling" format="default"/> contains
ling"> a
specific update to <xref target="RFC9286" format="default"/> for the
<t>
<xref target="manifest-number-handling" /> contains a
specific update to <xref target="RFC9286" /> for the
handling of manifest numbers, in order to address one handling of manifest numbers, in order to address one
potential permanent invalidity scenario. RPs that potential permanent invalidity scenario. RPs that
encounter other permanent invalidity scenarios should also encounter other permanent invalidity scenarios should also
consider how those can be addressed such that the scenario consider how those can be addressed such that the scenario
does not require the relevant CA or TA to perform a key does not require the relevant CA or TA to perform a key
rollover operation. For example, in the event that an RP rollover operation. For example, in the event that an RP
recognises that a permanent invalidity scenario has recognises that a permanent invalidity scenario has
occurred, the RP could alert the operator and provide an occurred, the RP could alert the operator and provide an
option to the operator to stop relying on cached data for option to the operator to stop relying on cached data for
the affected repository, so that the CA can rectify the the affected repository so that the CA can rectify the
problem. problem.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Operational Considerations"> <name>Operational Considerations</name>
<t>
<t>
CA software may opt to support the manifest number reset CA software may opt to support the manifest number reset
functionality in various ways. For example, it could functionality in various ways. For example, it could
change the manifest filename when the manifestNumber change the manifest filename when the manifestNumber
reaches a certain threshold, or it could alert the reaches a certain threshold, or it could alert the
operator in this scenario and request confirmation that operator in this scenario and request confirmation that
the filename should be changed. the filename should be changed.
</t> </t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>
<t>
The RPKI primarily exists to support and improve security The RPKI primarily exists to support and improve security
of the global Internet routing system. Reliability of the global Internet routing system. Reliability
improvements to the RPKI itself, such as outlined in this improvements to the RPKI itself, such as outlined in this
document, strengthen its dependability (see <xref document, strengthen its dependability (see <xref target="RFC6480" s
target="RFC6480" section="8" />). ection="8" format="default"/>).
</t>
<t> </t>
<t>
See <xref target="replay" /> regarding the effect of See <xref target="replay" format="default"/> regarding the effect of
skipping the manifestNumber check with respect to replay skipping the manifestNumber check with respect to replay
attacks. To protect against replay attacks in the absence attacks. To protect against replay attacks in the absence
of this check, RPs should ensure that they are verifying of this check, RPs should ensure that they are verifying
the thisUpdate value per the requirements of <xref the thisUpdate value per the requirements of <xref target="RFC9286"
target="RFC9286"/>. format="default"/>.
</t>
<t> </t>
<t>
<xref target="manifest-sia-check" /> describes an <xref target="manifest-sia-check" format="default"/> describes an
additional protection against certain forms of replay additional protection against certain forms of replay
attack. attack.
</t>
<t>
Although this document updates <xref target="RFC9286"/>,
the security considerations from <xref target="RFC9286"/>
remain relevant.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This document has no actions for IANA.
</t>
</section>
<section removeInRFC="true">
<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, an
d is based on a proposal described in <xref target="RFC7942" />.
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>
<t> <t>
According to <xref target="RFC7942" />, "this will allow reviewers and w
orking groups to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation and feedba
ck 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>
<section anchor="impl-rpki-client" title="rpki-client"> Although this document updates <xref target="RFC9286" format="defaul
<t><list style="none" spacing="compact"> t"/>,
<t>Responsible Organization: OpenBSD<vspace blankLines='1' /></t> the security considerations from <xref target="RFC9286" format="defa
<t>Location: https://www.rpki-client.org<vspace blankLines='1' /></t> ult"/>
<t>Description: This implementation supports the behaviour described i remain relevant.
n this document.<vspace blankLines='1' /></t>
<t>Level of Maturity: This is a production implementation.<vspace blan
kLines='1' /></t>
<t>Coverage: This implementation includes all of the features describe
d in this specification.<vspace blankLines='1' /></t>
<t>Contact Information: Job Snijders, job@sobornost.net</t>
</list></t>
</section>
<section anchor="impl-routinator" title="Routinator">
<t><list style="none" spacing="compact">
<t>Responsible Organization: NLNetLabs<vspace blankLines='1' /></t>
<t>Location: https://github.com/NLnetLabs/routinator<vspace blankLines
='1' /></t>
<t>Description: This implementation supports the behaviour described i
n this document.<vspace blankLines='1' /></t>
<t>Level of Maturity: This is a production implementation.<vspace blan
kLines='1' /></t>
<t>Coverage: This implementation supports the manifest number handling
changes described in this specification.<vspace blankLines='1' /></t>
<t>Contact Information: NLNetLabs, labs@nlnetlabs.nl</t>
</list></t>
</section>
</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="Acknowledgements" title="Acknowledgements"> <t>
<t> This document has no IANA actions. </t>
The authors would like to thank <contact fullname="Theo
Buehler"/>, <contact fullname="Ben Maddison" />, <contact
fullname="Rob Austein" />, <contact fullname="Tim
Bruijnzeels" />, <contact fullname="Russ Housley" />,
<contact fullname="Mohamed Boucadair"/>, <contact
fullname="Luigi Iannone" />, <contact fullname="Daniele
Ceccarelli" />, <contact fullname="Darren Dukes" />,
<contact fullname="Ines Robles" />, <contact
fullname="Barry Leiba" />, <contact fullname="Éric Vyncke"
/>, <contact fullname="Gorry Fairhurst" />, <contact
fullname="Andy Newton" />, <contact fullname="Roman
Danyliw" />, <contact fullname="Mike Bishop" />, and
<contact fullname="Deb Cooley" /> for
their review and feedback on this document.
</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
&RFC2119; <name>References</name>
&RFC6487; <references>
&RFC6488; <name>Normative References</name>
&RFC8174; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
&RFC8182; 119.xml"/>
&RFC9286; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
</references> 487.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<references title="Informative References"> 488.xml"/>
&RFC6480; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
&RFC6481; 174.xml"/>
&RFC6489; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
&RFC7942; 182.xml"/>
&RFC8630; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
&RFC8488; 286.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
480.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
481.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
489.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
630.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
488.xml"/>
</references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t> The authors would like to thank <contact fullname="Theo Buehler"/>,
<contact fullname="Ben Maddison"/>, <contact fullname="Rob Austein"/>,
<contact fullname="Tim Bruijnzeels"/>, <contact fullname="Russ
Housley"/>, <contact fullname="Mohamed Boucadair"/>, <contact
fullname="Luigi Iannone"/>, <contact fullname="Daniele Ceccarelli"/>,
<contact fullname="Darren Dukes"/>, <contact fullname="Maria Ines Robles"/
>,
<contact fullname="Barry Leiba"/>, <contact fullname="Éric Vyncke"/>,
<contact fullname="Gorry Fairhurst"/>, <contact fullname="Andy
Newton"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Mike
Bishop"/>, and <contact fullname="Deb Cooley"/> for their review and
feedback on this document.
</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 87 change blocks. 
345 lines changed or deleted 250 lines changed or added

This html diff was produced by rfcdiff 1.48.