rfc9981.original   rfc9981.txt 
Internet Engineering Task Force T. Harrison Internet Engineering Task Force (IETF) T. Harrison
Internet-Draft G. Michaelson Request for Comments: 9981 G. Michaelson
Updates: 9286 (if approved) APNIC Updates: 9286 APNIC
Intended status: Standards Track J. Snijders Category: Standards Track J. Snijders
Expires: 25 July 2026 21 January 2026 ISSN: 2070-1721 BSD
May 2026
Resource Public Key Infrastructure (RPKI) Manifest Number Handling Resource Public Key Infrastructure (RPKI) Manifest Number Handling
draft-ietf-sidrops-manifest-numbers-09
Abstract Abstract
The Resource Public Key Infrastructure (RPKI) makes use of signed The Resource Public Key Infrastructure (RPKI) makes use of signed
objects called manifests, each of which includes a "manifest number". objects called "manifests", each of which includes a "manifest
This document updates RFC9286 by specifying issuer and RP behaviour number". This document updates RFC 9286 by specifying issuer and
when a manifest number reaches the largest possible value, a Relying Party (RP) behaviour when a manifest number reaches the
situation not considered in RFC9286. largest possible value, a situation not considered in RFC 9286.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 25 July 2026. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9981.
Copyright Notice Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
2. Manifest Number Handling . . . . . . . . . . . . . . . . . . 4 2. Manifest Number Handling
3. Manifest Filenames . . . . . . . . . . . . . . . . . . . . . 4 3. Manifest Filenames
4. Manifest SIA Verification . . . . . . . . . . . . . . . . . . 5 4. Manifest SIA Verification
5. RFC8488 Comparison . . . . . . . . . . . . . . . . . . . . . 5 5. Comparison with RFC 8488
6. General Repository Handling . . . . . . . . . . . . . . . . . 5 6. General Repository Handling
7. Operational Considerations . . . . . . . . . . . . . . . . . 5 7. Operational Considerations
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations
10. Implementation status . . . . . . . . . . . . . . . . . . . . 6 10. References
10.1. rpki-client . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References
10.2. Routinator . . . . . . . . . . . . . . . . . . . . . . . 7 10.2. Informative References
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 Acknowledgements
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses
12.1. Normative References . . . . . . . . . . . . . . . . . . 7
12.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The Resource Public Key Infrastructure (RPKI) [RFC6480] makes use of The Resource Public Key Infrastructure (RPKI) [RFC6480] makes use of
signed objects [RFC6488] called manifests [RFC9286]. A manifest signed objects [RFC6488] called "manifests" [RFC9286]. A manifest
lists each file that an issuer intends to include within an RPKI lists each file that an issuer intends to include within an RPKI
repository [RFC6481], and can be used to detect certain forms of repository [RFC6481]. Manifests can also be used to detect certain
attack against a repository. Manifests include a "manifest number" forms of attack against a repository. Manifests include a "manifest
(manifestNumber), which an issuer must increment by one whenever it number" (manifestNumber), which an issuer must increment by one
issues a new manifest, and Relying Parties (RPs) are required to whenever it issues a new manifest, and Relying Parties (RPs) are
verify that a newly-retrieved manifest for a given Certification required to verify that a newly retrieved manifest for a given
Authority (CA) has a higher manifestNumber than the previously- Certification Authority (CA) has a higher manifestNumber than the
validated manifest (Section 4.2.1 of [RFC9286]). previously validated manifest (Section 4.2.1 of [RFC9286]).
However, the manifestNumber field is 20 octets in length (i.e., However, the manifestNumber field is 20 octets in length (i.e.,
bounded), and no behaviour is specified for when a manifestNumber bounded), and no behaviour is specified for when a manifestNumber
reaches the largest possible value (2^159-1). When that value is reaches the largest possible value (2^159-1). When that value is
reached, some RP implementations will accept a new manifest for the reached, some RP implementations will accept a new manifest for the
CA only once the current manifest has expired, while others will not CA only once the current manifest has expired, while others will not
accept a new manifest at all. accept a new manifest at all.
While it is practically impossible for an issuer to reach the largest While it is practically impossible for an issuer to reach the largest
possible value under normal operating conditions (it would require possible value under normal operating conditions (it would require
skipping to change at page 3, line 18 skipping to change at line 107
* Reissuing new manifests in an infinite delay-free loop, such that * Reissuing new manifests in an infinite delay-free loop, such that
the manifestNumber increases by a large value in a comparatively the manifestNumber increases by a large value in a comparatively
short period of time. short period of time.
* Inadvertently setting the manifestNumber to the largest possible * Inadvertently setting the manifestNumber to the largest possible
value, such that the issuer will no longer be able to publish value, such that the issuer will no longer be able to publish
usable manifests for that repository. usable manifests for that repository.
These scenarios might also arise in combination and be more severe as These scenarios might also arise in combination and be more severe as
a result. For example, a CA might increase the manifestNumber by a a result. For example, a CA might increase the manifestNumber by a
large value on reissuance, and also reissue the manifest more large value on reissuance and also reissue the manifest more
frequently than is necessary. frequently than is necessary.
For a subordinate CA, the risk of repository invalidation due to such For a subordinate CA, the risk of repository invalidation due to such
a problem can be addressed by the issuer using the key rollover a problem can be addressed by the issuer using the key rollover
process [RFC6489] to get a new CA certificate. RPs will treat this process [RFC6489] to get a new CA certificate. RPs will treat this
new certificate as though it represents a distinct CA, and the new certificate as though it represents a distinct CA; the
manifestNumber can be reset at that point. manifestNumber can be reset at that point.
However, this option is not available for RPKI Trust Anchors (TAs). However, this option is not available for RPKI Trust Anchors (TAs).
If a TA publishes a manifest with the largest-possible manifestNumber If a TA publishes a manifest with the largest-possible manifestNumber
value, then it is difficult to rely on the TA after that point, since value, then it is 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 reject all new until the current one has expired, while others will reject all new
manifests indefinitely. Particularly in the case of TAs, the manifests indefinitely. Particularly in the case of TAs, the
manifest validity period may be quite long, too. Issuing a new TA manifest validity period may be quite long, too. Issuing a new TA
and distributing the associated Trust Anchor Locator (TAL) [RFC8630] and distributing the associated Trust Anchor Locator (TAL) [RFC8630]
skipping to change at page 3, line 49 skipping to change at line 138
installation of the new TAL. installation of the new TAL.
In order to avoid these problems, this document updates [RFC9286] by In order to avoid these problems, this document updates [RFC9286] by
defining how issuers and RPs can handle this scenario in order to defining how issuers and RPs can handle this scenario in order to
facilitate ongoing use of an affected repository. facilitate ongoing use of an affected repository.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Manifest Number Handling 2. Manifest Number Handling
For a given CA, an RP MUST NOT reject a new manifest issued by that 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 manifestNumber than a CA on the basis of it not having a higher manifestNumber than a
previously-validated manifest if the new manifest has a different previously validated manifest if the new manifest has a different
filename from that of the previously-validated manifest. In other filename from that of the previously validated manifest. In other
words, an RP has to reset its stored manifestNumber for a given CA if words, an RP has to reset its stored manifestNumber for a given CA if
the CA changes the filename of its manifest. This is an update to the CA changes the filename of its manifest. This is an update to
the requirements set out in Section 4.2.1 of [RFC9286]. the requirements set out in Section 4.2.1 of [RFC9286].
With this behaviour, it is possible for a CA to be configured such With this behaviour, it is possible for a CA to be configured such
that any time it issues a new manifest, it uses a new filename for that, any time it issues a new manifest, it uses a new filename for
that manifest. If a CA were configured in this way, the that manifest. If a CA were configured in this way, the
manifestNumber validation set out in Section 4.2.1 of [RFC9286] would manifestNumber validation set out in Section 4.2.1 of [RFC9286] would
have no purpose. To avoid this outcome, CAs SHOULD NOT use new have no purpose. To avoid this outcome, CAs SHOULD NOT use new
filenames for manifests except in situations where such a change is filenames for manifests except in situations where such a change is
necessary to address the invalidity problem described in this necessary to address the invalidity problem described in this
document. Similarly, an RP MUST alert its operators when a manifest document. Similarly, an RP MUST alert its operators when a manifest
filename changes for a given CA. filename changes for a given CA.
[RFC9286] requires that RPs perform two replay-related checks on [RFC9286] requires that RPs perform two replay-related checks on
newly-retrieved manifests: firstly, that the purported new manifest newly retrieved manifests:
has a greater manifestNumber than the cached manifest, and secondly,
that the purported new manifest has a more recent thisUpdate than the 1. Check that the purported new manifest has a greater
cached manifest. An RP that implements the behaviour in this section manifestNumber than the cached manifest, and
will momentarily omit the manifestNumber check following a manifest
filename change. So long as the RP still performs the second check 2. Check that the purported new manifest has a more recent
described above, it will be protected against replay attacks. thisUpdate than the cached manifest.
An RP that implements the behaviour in this section will momentarily
omit the manifestNumber check following a manifest filename change.
So long as the RP still performs the second check described above, it
will be protected against replay attacks.
3. Manifest Filenames 3. Manifest Filenames
A CA specifies its manifest URI by way of an SIA entry with an A CA specifies its manifest URI by way of a Subject Information
accessMethod of id-ad-rpkiManifest (Section 4.8.8.1 of [RFC6487]). Access (SIA) entry with an accessMethod of id-ad-rpkiManifest
For the purposes of this document, the manifest filename is the final (Section 4.8.8.1 of [RFC6487]). For the purposes of this document,
segment of the path of the accessLocation URI from that SIA entry. the manifest filename is the final segment of the path of the
accessLocation URI from that SIA entry.
Section 4.8.8.1 of [RFC6487] states that a CA may include in its Section 4.8.8.1 of [RFC6487] 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 the id-ad- comparisons, an RP may use the filename from any one of the id-ad-
rpkiManifest SIA entries in the previously-validated CA certificate. rpkiManifest SIA entries in the previously validated CA certificate.
If that filename does not appear in any of the id-ad-rpkiManifest SIA If that filename does not appear in any of the id-ad-rpkiManifest SIA
entries in the CA certificate that is currently being validated, then entries in the CA certificate that is currently being validated, then
the manifest filename has changed for the purposes of this document. the manifest filename has changed for the purposes of this document.
The corollary of the behaviour defined in the previous paragraph is The corollary of the behaviour defined in the previous paragraph is
that a CA that includes multiple id-ad-rpkiManifest SIA entries in that a CA that includes multiple id-ad-rpkiManifest SIA entries in
its certificate and wants to rely on the behaviour defined in this its certificate and wants to rely on the behaviour defined in this
document MUST ensure that none of the manifest filenames in the document MUST ensure that none of the manifest filenames in the
previous CA certificate appear in the newly-issued CA certificate. previous CA certificate appear in the newly issued CA certificate.
If one of the manifest filenames from the previous CA certificate If one of the manifest filenames from the previous CA certificate
appears in the newly-issued CA certificate, then an RP that is using appears in the newly issued CA certificate, then an RP that is using
that manifest filename for comparisons will determine that the that manifest filename for comparisons will determine that the
manifest filename for the CA has not changed, and will therefore not manifest filename for the CA has not changed and will therefore not
reset its stored manifestNumber for the CA. reset its stored manifestNumber for the CA.
4. Manifest SIA Verification 4. Manifest SIA Verification
To avoid certain forms of replay attack, RPs MUST verify that the URI To avoid certain forms of replay attack, RPs MUST verify that the URI
in the accessLocation in one of the id-ad-signedObject accessMethod in the accessLocation in one of the id-ad-signedObject accessMethod
instances in the manifest's Subject Information Access (SIA) instances in the manifest's SIA extension exactly matches the URI
extension exactly matches the URI presented in the RPKI Repository presented in the RPKI Repository Delta Protocol (RRDP) [RFC8182]
Delta Protocol (RRDP) [RFC8182] "publish" element or the path "publish" element or the path presented by remote rsync servers. If
presented by remote rsync servers. If this verification check is this verification check is unsuccessful, then the fetch has failed,
unsuccessful, then the fetch has failed, and the RP MUST proceed per and the RP MUST proceed per Section 6.6 of [RFC9286].
Section 6.6 of [RFC9286].
5. RFC8488 Comparison 5. Comparison with RFC 8488
Section 3.2.1 of [RFC8488] describes a manifest selection approach Section 3.2.1 of [RFC8488] describes a manifest-selection approach
for RPs that involves collecting all unexpired, valid manifests for a for RPs that involves collecting all unexpired valid manifests for a
CA, and then selecting from that collection the manifest that has the CA and then selecting from that collection the manifest that has the
highest manifestNumber. The approach set out in this document is highest manifestNumber. The approach set out in this document is
different from that approach. different from that approach.
6. General Repository Handling 6. General Repository Handling
Section 2 contains a specific update to [RFC9286] for the handling of Section 2 contains a specific update to [RFC9286] for the handling of
manifest numbers, in order to address one potential permanent manifest numbers, in order to address one potential permanent
invalidity scenario. RPs that encounter other permanent invalidity invalidity scenario. RPs that encounter other permanent invalidity
scenarios should also consider how those can be addressed such that scenarios should also consider how those can be addressed such that
the scenario does not require the relevant CA or TA to perform a key the scenario does not require the relevant CA or TA to perform a key
rollover operation. For example, in the event that an RP recognises rollover operation. For example, in the event that an RP recognises
that a permanent invalidity scenario has occurred, the RP could alert that a permanent invalidity scenario has occurred, the RP could alert
the operator and provide an option to the operator to stop relying on the operator and provide an option to the operator to stop relying on
cached data for the affected repository, so that the CA can rectify cached data for the affected repository so that the CA can rectify
the problem. the problem.
7. Operational Considerations 7. Operational Considerations
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 change the functionality in various ways. For example, it could change the
manifest filename when the manifestNumber reaches a certain manifest filename when the manifestNumber reaches a certain
threshold, or it could alert the operator in this scenario and threshold, or it could alert the operator in this scenario and
request confirmation that the filename should be changed. request confirmation that the filename should be changed.
skipping to change at page 6, line 26 skipping to change at line 263
requirements of [RFC9286]. requirements of [RFC9286].
Section 4 describes an additional protection against certain forms of Section 4 describes an additional protection against certain forms of
replay attack. replay attack.
Although this document updates [RFC9286], the security considerations Although this document updates [RFC9286], the security considerations
from [RFC9286] remain relevant. from [RFC9286] remain relevant.
9. IANA Considerations 9. IANA Considerations
This document has no actions for IANA. This document has no IANA actions.
10. Implementation status
This section is to be removed before publishing as an RFC.
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 [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 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.
According to [RFC7942], "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".
10.1. rpki-client
* Responsible Organization: OpenBSD
* Location: https://www.rpki-client.org
* Description: This implementation supports the behaviour described
in this document.
* Level of Maturity: This is a production implementation.
* Coverage: This implementation includes all of the features
described in this specification.
* Contact Information: Job Snijders, job@sobornost.net
10.2. Routinator
* Responsible Organization: NLNetLabs
* Location: https://github.com/NLnetLabs/routinator
* Description: This implementation supports the behaviour described
in this document.
* Level of Maturity: This is a production implementation.
* Coverage: This implementation supports the manifest number
handling changes described in this specification.
* Contact Information: NLNetLabs, labs@nlnetlabs.nl
11. Acknowledgements
The authors would like to thank Theo Buehler, Ben Maddison, Rob
Austein, Tim Bruijnzeels, Russ Housley, Mohamed Boucadair, Luigi
Iannone, Daniele Ceccarelli, Darren Dukes, Ines Robles, Barry Leiba,
Éric Vyncke, Gorry Fairhurst, Andy Newton, Roman Danyliw, Mike
Bishop, and Deb Cooley for their review and feedback on this
document.
12. References 10. References
12.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487, X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012, DOI 10.17487/RFC6487, February 2012,
<https://www.rfc-editor.org/info/rfc6487>. <https://www.rfc-editor.org/info/rfc6487>.
skipping to change at page 8, line 24 skipping to change at line 298
[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
"The RPKI Repository Delta Protocol (RRDP)", RFC 8182, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
DOI 10.17487/RFC8182, July 2017, DOI 10.17487/RFC8182, July 2017,
<https://www.rfc-editor.org/info/rfc8182>. <https://www.rfc-editor.org/info/rfc8182>.
[RFC9286] Austein, R., Huston, G., Kent, S., and M. Lepinski, [RFC9286] Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure "Manifests for the Resource Public Key Infrastructure
(RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022, (RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022,
<https://www.rfc-editor.org/info/rfc9286>. <https://www.rfc-editor.org/info/rfc9286>.
12.2. Informative References 10.2. Informative References
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/rfc6480>. February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", RFC 6481, Resource Certificate Repository Structure", RFC 6481,
DOI 10.17487/RFC6481, February 2012, DOI 10.17487/RFC6481, February 2012,
<https://www.rfc-editor.org/info/rfc6481>. <https://www.rfc-editor.org/info/rfc6481>.
[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification
Authority (CA) Key Rollover in the Resource Public Key Authority (CA) Key Rollover in the Resource Public Key
Infrastructure (RPKI)", BCP 174, RFC 6489, Infrastructure (RPKI)", BCP 174, RFC 6489,
DOI 10.17487/RFC6489, February 2012, DOI 10.17487/RFC6489, February 2012,
<https://www.rfc-editor.org/info/rfc6489>. <https://www.rfc-editor.org/info/rfc6489>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8488] Muravskiy, O. and T. Bruijnzeels, "RIPE NCC's [RFC8488] Muravskiy, O. and T. Bruijnzeels, "RIPE NCC's
Implementation of Resource Public Key Infrastructure Implementation of Resource Public Key Infrastructure
(RPKI) Certificate Tree Validation", RFC 8488, (RPKI) Certificate Tree Validation", RFC 8488,
DOI 10.17487/RFC8488, December 2018, DOI 10.17487/RFC8488, December 2018,
<https://www.rfc-editor.org/info/rfc8488>. <https://www.rfc-editor.org/info/rfc8488>.
[RFC8630] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T. [RFC8630] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
Bruijnzeels, "Resource Public Key Infrastructure (RPKI) Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630, Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630,
August 2019, <https://www.rfc-editor.org/info/rfc8630>. August 2019, <https://www.rfc-editor.org/info/rfc8630>.
Acknowledgements
The authors would like to thank Theo Buehler, Ben Maddison, Rob
Austein, Tim Bruijnzeels, Russ Housley, Mohamed Boucadair, Luigi
Iannone, Daniele Ceccarelli, Darren Dukes, Maria Ines Robles, Barry
Leiba, Éric Vyncke, Gorry Fairhurst, Andy Newton, Roman Danyliw, Mike
Bishop, and Deb Cooley for their review and feedback on this
document.
Authors' Addresses Authors' Addresses
Tom Harrison Tom Harrison
Asia Pacific Network Information Centre Asia Pacific Network Information Centre
6 Cordelia St 6 Cordelia St
South Brisbane QLD 4101 South Brisbane QLD 4101
Australia Australia
Email: tomh@apnic.net Email: tomh@apnic.net
George G. Michaelson George G. Michaelson
Asia-Pacific Network Information Centre Asia-Pacific Network Information Centre
6 Cordelia St 6 Cordelia St
South Brisbane QLD 4101 South Brisbane QLD 4101
Australia Australia
Email: ggm@apnic.net Email: ggm@apnic.net
Job Snijders Job Snijders
BSD Software Development
Amsterdam Amsterdam
Netherlands The Netherlands
Email: job@sobornost.net Email: job@bsd.nl
URI: https://www.bsd.nl
 End of changes. 33 change blocks. 
152 lines changed or deleted 102 lines changed or added

This html diff was produced by rfcdiff 1.48.