| Internet-Draft | Constraining RPKI Trust Anchors | February 2026 |
| Snijders & Buehler | Expires 7 August 2026 | [Page] |
This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) to impose locally configured Constraints on cryptographic products subordinate to Trust Anchors (TAs). The ability to constrain a Trust Anchor operator's effective signing authority to a limited set of Internet Number Resources (INRs) allows Relying Parties to enjoy the potential benefits of assuming trust - within a bounded scope. The specified approach and configuration format allow RPKI operators to communicate efficiently about observations related to Trust Anchor operations.¶
This Internet-Draft is submitted in full conformance with the 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 7 August 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) to impose locally configured Constraints on cryptographic products subordinate to trusted Trust Anchors (TAs). The ability to constrain a Trust Anchor operator's effective signing authority to a limited set of Internet Number Resources (INRs) allows Relying Parties to enjoy the potential benefits of assuming trust - within a bounded scope. The specified approach and configuration format allow RPKI operators to communicate efficiently about observations related to Trust Anchor operations.¶
It is important to emphasize that each Relying Party makes its Trust Anchor inclusion decisions independently, on its own timelines, based on its own inclusion criteria; and that imposed Constraints (if any) are a matter of local configuration.¶
This document is intended to address user (meaning, Network Operator and Relying Party) needs and concerns, and was authored to benefit users and providers of RPKI services by providing a common body of knowledge to be communicated within the global Internet routing system community.¶
Readers should be familiar with the RPKI, the RPKI repository structure, and the various RPKI objects, uses, and interpretations described in the following: [RFC3779], [RFC6480], [RFC6481], [RFC6487], and [RFC6488].¶
A process to construct and sign RPKI Trust Anchor constraints is specified in [I-D.nro-sidrops-ta-constraints]. Such signed distributed constraints can serve as an input to the methodology specified in this document.¶
Currently, all five Regional Internet Registries (RIRs) list 'all-resources' (0.0.0.0/0, ::/0, and AS 0-4294967295) as subordinate on their Trust Anchor certificates in order to reduce some potential for risk of invalidation in the case of transient registry inconsistencies [I-D.rir-rpki-allres-ta-app-statement]. Such 'all-resources' listings demonstrate that - in the course of normal operations - Trust Anchors may claim authority for INRs outside the registry's current resource holdings.¶
The primary reason for transient registry inconsistencies to occur would be when resources are transferred from one registry to another. However, the ability to transfer resources between registries is not universally available: this ability depends on the implementation of registry-specific consensus-driven policy development reciprocated by other registries. Another source of churn would be the inflow of new resources following allocations made by the IANA; but because of IPv4 address exhaustion, IPv6 abundance, and 32-bit ASNs being allocated in large blocks - IANA allocations occur far less often than they used to.¶
Absent a registry's ability to execute inter-registry transfers or frequently receive new allocations from IANA, that registry's set of holdings would be a fairly static list of resources.¶
Therefore, a Relying Party need not trust each and every signed product in a derived trust relationship to any and all INRs subordinate to the registry's Trust Anchor, even when the Trust Anchor certificate lists 'all-resources' as subordinate. Following the widely deployed information security principle of least privilege [PRIVSEP], constraining a given Trust Anchor's capacity strictly to just that what relates to the their respective current INR holdings, provides some degree of risk reduction for all stakeholders involved.¶
Consequently, knowing a registry's current resource holdings and knowing this set of holdings will not change in the near-term future; following the principle of least privilege, operators can consider applying a restricted-service operating mode towards what otherwise would be an unbounded authority. The principle of constraining Trust Anchors might be useful when for example working with RPKI testbeds [OTE], risky Trust Anchors which cover unallocated space with AS0 ROAs [AS0TAL], but also in dealings with publicly-trusted registries.¶
As noted in Section 2, the current set of publicly-trusted RPKI TA certificates are expected to overclaim in the course of normal operations. However, applying a bespoke implementation of the certification path validation algorithm to CA certificates to prune all possible certificate paths related to INRs not contained within the locally configured Constraints would not be a trivial task. Instead, an alternative and simpler approach operating on EE certificates is proposed.¶
To constrain a Trust Anchor, the IP address and AS number resources listed in a given EE certificate's [RFC3779] extensions MUST be fully contained within the locally configured union set of IP prefixes, IP address ranges, AS identifiers, and AS identifier ranges for which the Relying Party operator anticipates the Trust Anchor operator to issue cryptographic products. If a given EE certificate's listed resources are not fully contained within the Constraints, the RP should halt processing and consider the EE certificate invalid.¶
The above described approach applies to all RPKI objects for which an explicit listing of resources is mandated in their respective [RFC3779] extensions; such as BGPSec Router Certificates [RFC8209], ROAs [RFC9582], ASPAs [I-D.ietf-sidrops-aspa-profile], RSCs [RFC9323], and Geofeeds [RFC9632].¶
The approach has no application in context of Signed Objects unrelated to INRs (which thus use 'inherit' elements); such as Ghostbusters records [RFC6493], Signed TALs [RFC9691], and Manifests [RFC9286].¶
The validation of Constraint containment is a check in addition to all the validation checks specified in [RFC6487], [RFC6488], and each Signed Object's profile specification.¶
As it's clumsy and error prone to calculate the complement of a block of resources, for efficiency a simple notation in the form of allow and deny keywords is used to indicate INRs which may or may not appear subordinate to a Trust Anchor (rather than merely using lengthy exhaustive allowlists of what INRs may appear under a given Trust Anchor).¶
An example is available in Appendix B.¶
When assessing the feasibility of constraining a Trust Anchor's effective signing abilities to the registry's current set of holdings, it is important to take note of existing policies (or lack thereof) and possible future events which might impact the degree of churn in the registry's holdings. Examples are:¶
The ARIN policy development community abandoned a proposal to allow inter-regional IPv6 resource transfers [ARIN-2019-4]. Since it's currently not possible to transfer IPv6 resources from ARIN to any other RIR, ARIN's IANA-allocated IPv6 resources should not appear subordinate to any Trust Anchor other than ARIN's own Trust Anchor.¶
The APNIC policy development community has not developed policy [APNIC-interrir] to support inter-RIR IPv6 transfers.¶
The LACNIC policy development community has not developed policy [LACNIC-interrir] to support inter-RIR IPv6 or ASN transfers.¶
The RIPE NCC policy development community did develop policy [RIPE-interrir] to support inter-RIR IPv6 transfers, but being the only community to have done so, inter-RIR transfers are not possible.¶
AFRINIC has not ratified an inter-registry transfer policy [AFPUB-2020-GEN-006-DRAFT03]. The policy proposal indicates implementation is expected to take an additional 12 months after ratification. Since it's not possible to transfer resources into AFRINIC, non-AFRINIC resources should not appear subordinate to AFRINIC's Trust Anchor for the foreseeable future.¶
The RIRs collectively manage only a subset of 0.0.0.0/0 [IANA-IPV4] and 2000::/3 [IANA-IPV6]; and have no authority over any parts of 10.0.0.0/8 [RFC1918], 2001:db8::/32 [RFC3849], and AS 64512 - 65534 [RFC6996], for example. Since it's not possible to transfer private internet allocations, documentation prefixes, or private use ASNs into an RIR's management, such resources should not appear subordinate to any RIR's Trust Anchor.¶
In recent times IANA has not made allocations from the Current Recovered IPv4 Pool [IANA-RECOVERED], and Autonomous System Number allocations are also fairly infrequent [IANA-ASNS].¶
It is clear from the aforementioned observations that, while there are sound reasons to declare 'all resources' as subordinate ([I-D.rir-rpki-allres-ta-app-statement]), there are resources which would never be subordinate to any particular Regional Internet Registry in the normal course of operations. Maintainers of Constraint lists disseminated as part of an operating system or a third-party software package release process would do well to assume a six month delay for users to update.¶
The routing security benefits promised by the RPKI are derived from assuming trust in registry operators to run flawless certification services. Assuming such trust exposes users to some potential for [risks] and adverse actions by Certificate Authorities [RFC8211]. Restricting a Trust Anchor's effective signing abilities to its respective registry's current holdings - rather assuming unbounded trust in such authorities - is a constructive approach to limit some potential for risk.¶
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 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.¶
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".¶
The approach specified in this document has been implemented in [rpki-client] and has been enabled by default in releases since 2023.¶
If the below content is placed in a file named example.constraints next to a Trust Anchor Locator file named example.tal, the [rpki-client] implementation will only accept an End-Entity certificate subordinate to example.tal if all its resources are fully contained within the resources allowed in example.constraints.¶
# Example constraints following the format described in # draft-snij-sidrops-constraining-rpki-trust-anchors # This is a comment allow 10.0.0.0/8 # comments may follow entries allow 192.168.0.0/12 deny 192.168.1.0/24 # carve a hole in the above entry allow 192.0.2.0/24 allow 100.64.0.0 - 100.127.255.254 # this is a range allow 203.0.113.0 - 203.0.113.255 # this too allow 3fff::/20 # IPv6 is also supported deny 3fff::/48 deny 2001:db8:: - 2001:db8::ffff # an IPv6 range # From https://www.iana.org/assignments/as-numbers/ allow 64496 - 64511 deny 65123 # carve a hole in the above entry allow 65536 # can declare for single ASN deny 4200000000 - 4294967294 # There is an implicit deny for all resources which were not # explicitly allowed through 'allow' declarations.¶
Thanks to Niels Bakker, Joel Jaeggli, Tony Tauber, Tom Scholl, Erik Bais, Simon Leinen, and Nick Hilliard for their feedback and input.¶