<?xmlversion="1.0"?>version='1.0' encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITYRFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">nbsp " "> <!ENTITYRFC2622 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2622.xml">zwsp "​"> <!ENTITYRFC2725 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2725.xml">nbhy "‑"> <!ENTITYRFC3629 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"> <!ENTITY RFC3779 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3779.xml"> <!ENTITY RFC4012 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4012.xml"> <!ENTITY RFC4180 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4180.xml"> <!ENTITY RFC4648 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"> <!ENTITY RFC5280 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"> <!ENTITY RFC5652 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"> <!ENTITY RFC8174 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY RFC6481 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6481.xml"> <!ENTITY RFC6487 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6487.xml"> <!ENTITY RFC6488 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6488.xml"> <!ENTITY RFC6598 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6598.xml"> <!ENTITY RFC8805 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8805.xml"> <!ENTITY RFC8933 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8933.xml"> <!ENTITY RFC8981 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8981.xml"> <!ENTITY RFC9110 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"> <!ENTITY RFC9286 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9286.xml"> <!ENTITY RFC0959 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0959.xml"> <!ENTITY RFC3912 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3912.xml"> <!ENTITY RFC4632 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4632.xml"> <!ENTITY RFC5485 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5485.xml"> <!ENTITY RFC6268 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6268.xml"> <!ENTITY RFC7485 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7485.xml"> <!ENTITY RFC7909 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7909.xml"> <!ENTITY RFC9083 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9083.xml"> <!ENTITY RFC9111 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9111.xml"> <!ENTITY RFC9632 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9632.xml"> <!ENTITY RFC9839 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9839.xml"> <!ENTITY RFC9877 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9877.xml">wj "⁠"> ]><?rfc sortrefs="yes"?> <?rfc subcompact="no"?> <?rfc symrefs="yes"?> <?rfc toc="yes"?> <?rfc tocdepth="3"?> <?rfc compact="yes"?> <?rfc subcompact="no"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-opsawg-prefix-lengths-14" number="9977" updates="" obsoletes="" submissionType="IETF" consensus="true" ipr="trust200902"version="2" >version="3" sortRefs="true" symRefs="true" tocInclude="true" tocDepth="3" xml:lang="en"> <front> <title abbrev="Publishing End-Site Prefix Lengths">Publishing End-Site Prefix Lengths</title> <seriesInfo name="RFC" value="9977"/> <author fullname="Oliver Gasser" initials="O." surname="Gasser"> <organization>IPinfo</organization> <address> <email>oliver@ipinfo.io</email> </address> </author> <author fullname="Randy Bush" initials="R." surname="Bush"> <organization>IIJ Research & Arrcus</organization> <address> <postal> <street>5147 Crystal Springs</street> <city>Bainbridge Island</city> <region>Washington</region> <code>98110</code> <country>United States of America</country> </postal> <email>randy@psg.com</email> </address> </author> <author fullname="Massimo Candela" initials="M." surname="Candela"> <organization>NTT</organization> <address> <postal> <street>Siriusdreef 70-72</street> <city>Hoofddorp</city> <code>2132 WT</code> <country>Netherlands</country> </postal> <email>massimo@ntt.net</email> </address> </author> <author fullname="Russ Housley"initials="R"initials="R." surname="Housley"> <organization abbrev="Vigil Security">Vigil Security, LLC</organization> <address> <postal> <street>516 Dranesville Road</street> <city>Herndon</city> <region>VA</region> <code>20170</code><country>USA</country><country>United States of America</country> </postal> <email>housley@vigilsec.com</email> </address> </author> <date/>month="May" year="2026"/> <keyword>prefix</keyword> <keyword>allocation</keyword> <keyword>RPSL</keyword> <keyword>inetnum</keyword> <abstract> <t> This document specifies how to augment the Routing Policy Specification Language (RPSL) inetnum: class to refer specifically to prefixlenfilesfiles, which arecomma-separated valuesComma-Separated Values (CSV) files used to specify end-site prefix lengths. This document also describes an optional mechanism that uses the Resource Public Key Infrastructure (RPKI) to authenticate the prefixlen files. </t> </abstract> </front> <middle> <section anchor="intro" numbered="true" toc="default"> <name>Introduction</name> <t> Internetservice providersService Providers (ISPs) delegate IP addresses or entire IP prefixes to their users. Similarly, cloud providers assign customers who use theirservicesservices, such as virtual machines (VMs), a prefix of a specific size. <!--[rfced] Please review our updates to the following to ensure we've maintained your intended meaning: Original: Therefore, there are a multitude of variations of different end-site prefix length present in the Internet. Current: Therefore, there are many variations of end-site prefix lengths present in the Internet. --> Therefore, there are many variations of end-site prefix lengths present in the Internet. Currently, there is no easy way for content providers to know the end-site prefix size of someone accessing their service. Knowing the correct end-site's prefix size has multiple implications such as:<ul</t> <dl spacing="normal"><li> Blocklisting/throttling: In<dt>Blocklisting/throttling:</dt><dd>In IPv4, IP addresses can be blocked using variable prefix lengths for different prefixes, such as /22 for prefix A, /27 for prefix B, or /32 to block a single IPv4 address. Due to the large address space in IPv6, blocking at, e.g., the /48 or /56 level could lead to overblocking (throwing multiple VMs from different users into the same bucket), while blocking at more fine-granular levels, e.g., /64, /96, or even/128/128, to block a single IPv6 address would lead to filling up space in the blocklist pretty quickly. The use of temporary addresses in IPv6 <xref target="RFC8981" format="default"/> might lead to unwanted unblocking when addresses are blocked at atoo fine-granulartoo-fine-granular level (e.g., /128). All these issues apply to throttling as well.</li> <li> Rate limiting/CAPTCHAs: A</dd> <dt>Rate limiting/CAPTCHAs:</dt><dd>A similar issue arises on the Web, where neighboring prefixes might be thrown together (e.g., in the same /48 or/56,/56 even though the ISP hands out /64s), which leads to people "jointly" running into rate limits and then either being blocked from a service or having to solve annoying CAPTCHAs.</li> <li> Geolocation: Getting</dd> <dt>Geolocation:</dt><dd>Getting the right prefix size for geolocation is similarlyhard,difficult, especially for IPv6. If you aggregate too much, you throw together different clients in differentlocations, andlocations; if you aggregate too little, you fill up the geolocation database with unnecessary entries.</li> </ul> </t></dd> </dl> <t> This document specifies how to augment the Routing Policy Specification Language (RPSL) <xref target="RFC2725" format="default"/> inetnum: class to refer specifically to prefixlen files and how to usethem.the files. In all places where inetnum: is used, inet6num: must also be assumed <xref target="RFC4012" format="default"/>. </t> <t> The reader may find <xref target="INETNUM" format="default"/> and <xref target="INET6NUM" format="default"/> informative, and certainly moreverbose,verbose descriptions of the inetnum: databaseclasses.classes exist in those documents. </t> <t> An optional means for authenticating prefixlen data is also defined in <xref target="auth"/>. </t> </section> <section numbered="true" toc="default"> <name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</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"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xrefformat="default" pageno="false"target="RFC2119"/> <xrefformat="default" pageno="false"target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> <section anchor="pl" numbered="true" toc="default"> <name>prefixlen Files</name> <!-- Note to PE: [RFC4180] has mixed use of "Comma-Separated Values" and "Comma seperated values" --> <t> prefixlen files are CSV(Comma Separated Values)files <xref target="RFC4180" format="default"/> in text format with UTF-8 encoding <xref target="RFC3629" format="default"/>, excluding problematic code points as described in <xref target="RFC9839" format="default"/>. LinesMUST<bcp14>MUST</bcp14> be delimited by a line break (CRLF), and blank linesMUST<bcp14>MUST</bcp14> be ignored. Text from a '#' character to the end of the current lineMUST<bcp14>MUST</bcp14> be treated as a comment only and is similarly ignored. The first field of eachnon-ignoredline that is not ignored specifies the prefix in question, the secondfieldthe end-site prefix length within that prefix as an integer, and the thirdfieldthe number of end-sites within an end-site prefix length for networks using Carrier-Grade NAT (CGN) <xref target="RFC6598" format="default"/> or proxies. <!--[rfced] Please clarify the antecedent of "this": Original: In all places Carrier-Grade NAT or CGN is used in this document, this applies to proxies as well. --> In all places Carrier-Grade NAT or CGN is used in this document, this applies to proxies as well. Note that all three fieldsMUST<bcp14>MUST</bcp14> be present. This means thereMUST<bcp14>MUST</bcp14> be exactly two commas in each non-commented line delimiting the three fields. The first fieldMUST NOT<bcp14>MUST NOT</bcp14> be empty on lineswhichthat are not comments, while the second and third field can be empty in certain scenarios. If both the second and third fields are empty,this means thatthe publisher does not want to disclose any prefix length information. </t> <section numbered="true" toc="default"><name>End-site prefix length without<name>End-Site Prefix Length Without CGN orproxies</name>Proxies</name> <t> If an ISP delegates /56 IPv6 prefixes of the 2001:db8::/32range,range and /32 IPv4 prefixes (i.e., a single IPv4 address) of the 192.0.2.0/24 range to its customers without the use ofCarrier-Grade NAT (CGN)CGN <xref target="RFC6598" format="default"/> or proxy techniques, it would create a prefix length file containing the following example entries: </t> <sourcecodetype="csv"> <![CDATA[type="csv"><![CDATA[ 2001:db8::/32,56,1192.0.2.0/24,32,1 ]]></sourcecode>192.0.2.0/24,32,1]]></sourcecode> <t> Note the third field being set to '1', which signals the absence of CGN or proxies. This has the same meaning as the third field being left empty in this scenario. </t> </section> <section numbered="true" toc="default"><name>End-site prefix length<name>End-Site Prefix Length with CGN orproxies</name>Proxies</name> <t> prefixlen files can also be used to signal the presence ofCarrier-Grade NAT (CGN)CGN <xref target="RFC6598" format="default"/> or proxies in networks. This is especially useful for cases where multiple end-sites behind a CGN or proxy service accessing a service at the same time might run intorate limitingrate-limiting issues by service providers.In caseIf a prefixlen file signals the presence of a CGN, service providers can treat these prefixes in a way that rate limits are adjusted. To signal the presence of a CGN, the number of CGN end-sitesareis specified in the third field. For example, a CGN prefix 192.0.2.0/24 containing 4000 CGNend sitesend-sites would be specified as follows:<sourcecode type="csv"> <![CDATA[ 192.0.2.0/24,24,4000 ]]></sourcecode></t> <sourcecode type="csv"><![CDATA[ 192.0.2.0/24,24,4000]]></sourcecode> <t> Note the second field in the above example is set to '24', signaling that the 4000 CGN end-sites are present in the complete 192.0.2.0/24 prefix. </t> <t>If onOn the otherhandhand, if these 4000 CGN end-sites are distributed 1000 each in the four /26 sub-prefixes within 192.0.2.0/24, this is specified as follows: </t> <sourcecodetype="csv"> <![CDATA[ 192.0.2.0/24,26,1000 ]]></sourcecode>type="csv"><![CDATA[ 192.0.2.0/24,26,1000]]></sourcecode> <t> It is important to note that the third field denoting the number of CGN end-sites is referring to the prefix length specified in the second field. </t> <t> Note that this specification can be applied to IPv6 networks as well. </t> </section> <section numbered="true" toc="default"> <name>Longestprefix matching</name>Prefix Matching</name> <!--[rfced] We had a few questions about the following text: Original: Prefix length files can contain sub-prefixes entries of a parent prefix, which needs to be taken into account when processing these files. a) Please confirm the use of the plural "sub-prefixes". Perhaps: Prefix length files can contain sub-prefix entries of a parent prefix,.. b) Might this sentence be rephrased as: Perhaps: Prefix length files can contain sub-prefix entries of a parent prefix; this needs to be taken into account when processing these files. --> <t> Prefix length files can contain sub-prefixes entries of a parent prefix, which needs to be taken into account when processing these files. For example, if a cloud provider assigns /120 IPv6 prefixes to each customer VM and a /64 prefix to premium customers, it would create a prefix length file containing the following example entries: </t> <sourcecodetype="csv"> <![CDATA[type="csv"><![CDATA[ 2001:db8::/32,120,2001:db8:abcd::/48,64, ]]></sourcecode>2001:db8:abcd::/48,64,]]></sourcecode> <t> Note that the second entry in the above example is a subprefix of the first entry. Therefore, longest prefix matching has to be performed when parsing prefixlen files. </t> </section> <section numbered="true" toc="default"> <name>Notspecifying any end-site prefix length</name>Specifying Any End-Site Prefix Length</name> <t> If an ISP delegates /32 IPv4 prefixes (i.e., a single IPv4 address) of the 192.0.2.0/24 range to its customers without the use ofCarrier-Grade NAT (CGN),CGN, and it has a special sub-prefix 192.0.2.0/28 where this policy does not apply, it can signal so with the following prefix length file: </t> <sourcecodetype="csv"> <![CDATA[type="csv"><![CDATA[ 192.0.2.0/24,32,192.0.2.0/28,, ]]></sourcecode>192.0.2.0/28,,]]></sourcecode> <t> If both the second and third fields are empty,this means thatthe publisher does not want to disclose any prefix length information. Any prefix length information from covering prefixes (192.0.2.0/24 in our example)MUST<bcp14>MUST</bcp14> be discarded for sub-prefixes specified in prefixlen files (192.0.2.0/28 in our example). </t> </section> <section numbered="true" toc="default"> <name>Processing prefixlenfiles</name>Files</name> <t> Multiple entries with exactly the same prefixMUST<bcp14>MUST</bcp14> be considered an error, and consumer implementationsSHOULD<bcp14>SHOULD</bcp14> log the repeated entries for further administrative review. PublishersMUST<bcp14>MUST</bcp14> take measures to ensure there is one and only one entry per prefix. </t> <t> Upon encountering an erroneous entry in a prefixlen file, consumer implementationsMUST<bcp14>MUST</bcp14> skip that entry, log the error, and continue processing the remaining entries. </t> <t> Content providers and other parties who wish to differentiate services based onend siteend-site prefixes need to find the relevant prefixlen data.In<xref target="inetnum"format="default"/>, this documentformat="default"/> specifies how to find the relevant prefixlen file given an IP address. </t> <t> prefixlen data for large providers administrating a large number of networks and end-sites can contain millions of entries. The size of a file can be even larger if an unsigned prefixlen file combines data for many prefixes, if dual IPv4/IPv6 spaces are represented, etc. </t> <t> This document also suggests an optional signature to strongly authenticate the data in the prefixlen files. The same approach to signatures is used in this document that was used in <xref target="RFC9632"/>. </t> </section> </section> <section anchor="inetnum" numbered="true" toc="default"> <name>inetnum: Class</name> <t> The original RPSL specifications (<xref target="RIPE81" format="default"/>, <xref target="RIPE181" format="default"/>, and a trail of subsequent documents) were written by the RIPE community. The IETF standardized RPSL in <xref target="RFC2622" format="default"/> and <xref target="RFC4012" format="default"/>. Since then, it has been modified and extensively enhanced in the Regional Internet Registry (RIR) community, mostly by RIPE <xref target="RIPE-DB" format="default"/>. At the time ofpublishing this document,publication, change control of RPSL effectively lies in the operator community. </t> <t> The RPSL, and <xref target="RFC2725" format="default"/> and <xref target="RFC4012" format="default"/> used by theRegional Internet Registries (RIRs),RIRs, specify the inetnum: database class. Each of these objects describes an IP address range and its attributes. The inetnum: objects form a hierarchy ordered on the address space. </t> <t> Ideally, RPSL would be augmented to define a new RPSL prefixlen: attribute in the inetnum: class. Absent implementation of the prefixlen: attribute in a particular RIR database, this document defines the syntax of a prefixlen remarks: attribute, which contains an HTTPS URL of a prefixlen file. The format of the inetnum: prefixlen remarks: attributeMUST<bcp14>MUST</bcp14> be as in this example, "remarks: Prefixlen ", where the token "Prefixlen"MUST<bcp14>MUST</bcp14> be case-sensitive, followed by a URL that willvary,vary butit MUSTthat <bcp14>MUST</bcp14> refer only to a single prefixlen file. </t> <sourcecodetype="rpsl"> <![CDATA[type="rpsl"><![CDATA[ inetnum: 192.0.2.0/24 # example remarks: Prefixlenhttps://example.com/prefixlen ]]></sourcecode>https://example.com/prefixlen]]></sourcecode> <t> While we leave global agreement of RPSL modification to the relevant parties, we specify that a proper prefixlen: attribute in the inetnum: classMUST<bcp14>MUST</bcp14> be "prefixlen:" andMUST<bcp14>MUST</bcp14> be followed by a single URL that will vary, but itMUST<bcp14>MUST</bcp14> refer only to a single prefixlen file. </t> <sourcecode type="rpsl"><![CDATA[ inetnum: 192.0.2.0/24 # example prefixlen:https://example.com/prefixlen ]]></sourcecode>https://example.com/prefixlen]]></sourcecode> <t> The URL uses HTTPS, so theWebPKIWeb Public Key Infrastructure (WebPKI) provides authentication, integrity, and confidentiality for the fetched prefixlen file. However, the WebPKI cannot provide authentication of IP address space assignment. In contrast, the RPKI (see <xref target="RFC6481" format="default"/>) can be used to authenticate IP space assignment; see optional authentication in <xref target="auth" format="default"/>. </t> <t> Until all producers of inetnum: objects, i.e., the RIRs, state that they have migrated to supporting the prefixlen: attribute, consumers looking at inetnum: objects to find prefixlen URLsMUST<bcp14>MUST</bcp14> be able to consume the remarks: and prefixlen: forms. </t> <t> The migration not only implies that the RIRs support the prefixlen: attribute, but that all registrants have migrated any inetnum: objects from remarks: to prefixlen:. </t> <t> Any particular inetnum: objectSHOULD<bcp14>SHOULD</bcp14> have, at most, one prefixlen reference, whether a remarks: or prefixlen: attribute when it is implemented. As the remarks: form cannot be formally checked by the RIR, this cannot be formally enforced. A prefixlen: attribute is preferred, of course, if the RIR supports it. If there is more than one type of attribute in the inetnum: object, the prefixlen: attributeMUST<bcp14>MUST</bcp14> be prioritized over the remarks: attribute. </t> <t> For inetnum: instances covering the same address range, a signed prefixlen fileMUST<bcp14>MUST</bcp14> be preferred over an unsigned file. If none are signed, or more than one is signed, the (signed) inetnum: with the most recent last-modified: attributeMUST<bcp14>MUST</bcp14> be preferred. </t> <t> If a prefixlen file describes multiple disjoint ranges of IP address space, there are likely to be prefixlen references from multiple inetnum: objects. Files with prefixlen references from multiple inetnum: objects are not compatible with the signing procedure in <xref target="auth" format="default"/>. </t> <t> An unsigned, and only an unsigned, prefixlen fileMAY<bcp14>MAY</bcp14> be referenced by multiple inetnum: instances andMAY<bcp14>MAY</bcp14> contain prefixes from more than one registry. </t> <t> When fetching, the most specific inetnum: object with a prefixlen referenceMUST<bcp14>MUST</bcp14> be used. </t> <t> It is significant that prefixlen data may have finer granularity than the inetnum: that refers to them. For example, an inetnum: object for an address range P could refer to a prefixlen file in which P has been subdivided into one or more longer prefixes. </t> <t>Backward compatibilityBackward-compatibility issues regarding the implementation of new RPSL attributes are covered bySection 10.2 of<xreftarget="RFC2622"/>.target="RFC2622" section="10.2"/>. </t> </section> <section anchor="fetch" numbered="true" toc="default"> <name>Fetching prefixlen Data</name> <t> This document provides a guideline for how interested parties should fetch and read prefixlen files. </t> <t> To minimize the load on RIRs' WHOIS <xref target="RFC3912"/> services, the RIR'sbulk downloadbulk-download servicesSHOULD<bcp14>SHOULD</bcp14> be used for large-scale access to gather inetnum: instances with prefixlen references. This uses efficient bulk access instead of fetching via brute-force search through the IP space. When usingbulk download servicesbulk-download services, theyMUST<bcp14>MUST</bcp14> be accessed using HTTPS <xref target="RFC9110"format="default"/>,format="default"/>; FTP <xref target="RFC0959"/>MUST NOT<bcp14>MUST NOT</bcp14> be used. </t> <t> On the other hand, RIRs are converging on RDAPsupportsupport, which includes geofeeddata,data; see <xref target="RFC9877"/>. It is hoped that this will be extended, or generalized, to support prefixlen data. </t> <t> When reading data from a prefixlen file, oneMUST<bcp14>MUST</bcp14> ignore data outside the referring inetnum: object's address range. This is to avoid importing data about ranges not under the control of the operator. Note that signed filesMUST<bcp14>MUST</bcp14> only contain prefixes within the referring inetnum:'s range as mandated in <xref target="auth"/>. </t> <t> If prefixlen files are fetched, other prefix length information from the inetnum:MUST<bcp14>MUST</bcp14> be ignored. </t> <t> Given an address range of interest, the most specific inetnum: object with a prefixlen referenceMUST<bcp14>MUST</bcp14> be used to fetch the prefixlen file. For example, if the fetching party finds the following inetnum: objects: </t> <sourcecodetype="rpsl"> <![CDATA[type="rpsl"><![CDATA[ inetnum: 192.0.2.0/24 # example remarks: Prefixlen https://example.com/prefixlen_1 inetnum: 192.0.2.0/26 # example remarks: Prefixlenhttps://example.com/prefixlen_2 ]]></sourcecode>https://example.com/prefixlen_2]]></sourcecode> <t> An application looking for prefixlen data for192.0.2.0/29, MUST192.0.2.0/29 <bcp14>MUST</bcp14> ignore data in prefixlen_1 because 192.0.2.0/29 is within the more specific 192.0.2.0/26 inetnum: covering that address range and that inetnum: does have a prefixlen reference. </t> </section> <section anchor="auth" numbered="true" toc="default"> <name>Authenticating prefixlen Data (Optional)</name> <t> The question arises whether a particular prefixlen data set is valid, i.e., is authorized by the "owner" of the IP address space and is authoritative in some sense. The inetnum: that points to the prefixlen file provides some assurance. Unfortunately, the RPSL in some repositories is weakly authenticated at best. An approach where RPSL was signed per the guidance in <xref target="RFC7909"/> would be good, except it would have to be deployed by all RPSL registries, and there is a fair number of them. </t> <t> The remainder of this section specifies an optional authenticator for the prefixlen data set that follows the Signed Object Template for the Resource Public Key Infrastructure (RPKI) <xref target="RFC6488"/>. </t> <t> A single optional authenticatorMAY<bcp14>MAY</bcp14> be appended to a prefixlen file. It is a digest of the main body of the file signed by the private key of the relevant RPKI certificate for a covering address range. The following format bundles the relevant RPKI certificate with a signature over the prefixlen text. </t> <t> The canonicalization procedure converts the data from their internal character representation to the UTF-8<xref target="RFC3629"/>characterencoding,encoding (see <xref target="RFC3629"/>), and the <CRLF> sequenceMUST<bcp14>MUST</bcp14> be used to denote the end of each line of text. A blank line is represented solely by the <CRLF> sequence. For robustness, any non-printable charactersMUST NOT<bcp14>MUST NOT</bcp14> be changed by canonicalization. Trailing blank linesMUST NOT<bcp14>MUST NOT</bcp14> appear at the end of the file. That is, the file must not end with multiple consecutive <CRLF> sequences. Any end-of-file marker used by an operating system is not considered to be part of the file content. When present, such end-of-file markersMUST NOT<bcp14>MUST NOT</bcp14> be covered by the digital signature. </t> <t> If the authenticator is not in the canonical form described above,then,then the authenticator is invalid, which means that it is treated in the same manner as an unauthenticated prefixlen data. </t> <t> Borrowing detached signatures from <xref target="RFC5485"/>, after file canonicalization, theCryptographic Message Syntax (CMS)CMS (see <xreftarget="RFC5652"/>target="RFC5652"/>) is used to create a detached DER-encoded signature that is thenBase64 encodedBase64-encoded with padding (as defined inSection 4 of<xreftarget="RFC4648"/>)target="RFC4648" section="4"/>) and line wrapped to 72 or fewer characters. The same digest algorithmMUST<bcp14>MUST</bcp14> be used for calculating the message digest of the content being signed, which is the prefixlen file, and for calculating the message digest on the SignerInfo SignedAttributes (see <xreftarget="RFC8933"/>.target="RFC8933"/>). The message digest algorithm identifierMUST<bcp14>MUST</bcp14> appear in both the CMS SignedData DigestAlgorithmIdentifiers and the SignerInfo DigestAlgorithmIdentifier <xref target="RFC5652"/>. The RPKI certificate covering the prefixlen inetnum: object's address range is included in the CMS SignedData certificates field <xref target="RFC5652"/>. </t> <t> The address range of the signing certificateMUST<bcp14>MUST</bcp14> cover all prefixes in the signed prefixlen file. If not, the authenticator is invalid. </t> <t> The signing certificateMUST NOT<bcp14>MUST NOT</bcp14> include the Autonomous System Identifier Delegation certificate extension <xref target="RFC3779"/>. If it is present, the authenticator is invalid. </t> <t> As with many other RPKI signed objects, the IP Address Delegation certificate extensionMUST NOT<bcp14>MUST NOT</bcp14> use the "inherit" capability defined inSection 2.2.3.5 of<xreftarget="RFC3779"/>.target="RFC3779" section="2.2.3.5"/>. If "inherit" is used, the authenticator is invalid. </t> <t> An IP Address Delegation certificate extension using "inherit" would complicate processing. The implementation would have to build the certification path from the end-entity to the trustanchor,anchor and then validate the path from the trust anchor to theend-entity, and thenend-entity. Then, the parameter would have to be remembered when the validated public key was used to validate a signature on a CMS object. Having to remember things fromcertification pathcertification-path validation for use with CMS object processing would be quite complex and error-prone. And, the certificates do not get that much bigger by repeating the information. </t> <t> An address range A "covers" address range B if the range of B is identical to or a subset of A. "Address range" is used here because inetnum: objects and RPKI certificates need not align on Classless Inter-Domain Routing (CIDR) <xref target="RFC4632"/> prefix boundaries, while those of the lines in a prefixlen file do align. </t> <t> The Certification Authority (CA)MUST<bcp14>MUST</bcp14> generate a new End Entity (EE) certificate for each signing of a particular prefixlen file. The private key associated with the EE certificateSHOULD<bcp14>SHOULD</bcp14> sign only one prefixlen file. That is, a new key pairSHOULD<bcp14>SHOULD</bcp14> be generated for each new version of a particular prefixlen file. When the EE certificate is used in this fashion, it is termed a "one-time-use" EE certificate (seeSection 3 of<xreftarget="RFC6487"/>).target="RFC6487" section="3"/>). </t> <t> On the other hand, verifying the signature has no similar complexity; the certificate, which is validated in the RPKI, contains the needed public key. The RPKI trust anchors for the RIRs are available to the party performing signature validation. Validation of the CMS signature over the prefixlen file involves: </t> <ol spacing="normal" type="1"> <li> Obtaining the signer's certificate from the CMS SignedData CertificateSet <xref target="RFC5652"/>. The certificate SubjectKeyIdentifier extension <xref target="RFC5280"/>MUST<bcp14>MUST</bcp14> match the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier <xref target="RFC5652"/>. If the key identifiers do not match, then validationMUST<bcp14>MUST</bcp14> fail. </li> <li> Validating the signer's certificateMUST<bcp14>MUST</bcp14> ensure that it is part of the current manifest per <xref target="RFC9286"/>manifestand that all resources are covered by the RPKI certificate. </li> <li>ConstructConstructing andvalidatevalidating the certification path for the signer's certificate. All of the needed certificates are expected to be readily available in the RPKI repository. The certification pathMUST<bcp14>MUST</bcp14> be valid according to the validation algorithm in <xref target="RFC5280"/> and the additional checks specified in <xref target="RFC3779"/> associated with the IP Address Delegation certificate extension. If certification path validation is unsuccessful, then validationMUST<bcp14>MUST</bcp14> fail. </li> <li> Validating the CMS SignedData as specified in <xref target="RFC5652"/> using the public key from the validated signer's certificate. If the signature validation is unsuccessful, then validationMUST<bcp14>MUST</bcp14> fail. </li> <li> Confirming that the eContentTypeobject identifierObject IDentifier (OID) is id-ct-prefixlenCSVwithCRLF(1.2.840.113549.1.9.16.1.TBD).(1.2.840.113549.1.9.16.1.57). This OIDMUST<bcp14>MUST</bcp14> appear within both the eContentType in the encapContentInfo object and the ContentType signed attribute in the signerInfo object (see <xref target="RFC6488"/>). </li> <li> Verifying that the IP Address Delegation certificate extension <xref target="RFC3779"/> covers all of the address ranges of the prefixlen file. If all of the address ranges are not covered, then validationMUST<bcp14>MUST</bcp14> fail. </li> </ol> <t> All of the above stepsMUST<bcp14>MUST</bcp14> be successful to consider the prefixlen file signatureasto be valid. </t> <t> The authenticatorMUST<bcp14>MUST</bcp14> be hidden as a series of "#" comments at the end of the prefixlen file. The following simple example is cryptographically incorrect: </t> <sourcecode type=""><![CDATA[ # RPKI Signature: 192.0.2.0 - 192.0.2.255 # MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ # IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu ... # imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa # O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk= # End Signature: 192.0.2.0 -192.0.2.255 ]]></sourcecode>192.0.2.255]]></sourcecode> <t> A correct and full example is inAppendix A.<xref target="asn1"/>. </t> <t> The CMS signature does not cover the signature lines. </t> <t> The bracketing "# RPKI Signature:" and "# End Signature:"MUST<bcp14>MUST</bcp14> be present as shown in the example. The RPKI Signature's IP address rangeMUST<bcp14>MUST</bcp14> match that of the prefixlen URL in the inetnum: that points to the prefixlen file. </t> </section> <section anchor="ops" numbered="true" toc="default"> <name>Operational Considerations</name> <t> To create the needed inetnum: objects, an operator wishing to register the location of their prefixlen file needs to coordinate with their Regional Internet Registry (RIR) or National Internet Registry (NIR) and/or any provider Local Internet Registry (LIR) that has assigned address ranges to them. RIRs/NIRs provide means for assignees to create and maintain inetnum: objects. They also provide means of assigning or sub-assigning IP address resources and allowing the assignee to create WHOIS data, including inetnum: objects, thereby referring to prefixlen files. </t> <t> The prefixlen filesMUST<bcp14>MUST</bcp14> be published via and fetched using HTTPS <xref target="RFC9110" format="default"/>. </t> <t> When using data from a prefixlen file, oneMUST<bcp14>MUST</bcp14> ignore data outside the referring inetnum: object's inetnum: attribute address range. </t> <t> If and only if the prefixlen file is not signed per <xref target="auth" format="default"/>, then multiple inetnum: objectsMAY<bcp14>MAY</bcp14> refer to the same prefixlen file, and the consumerMUST<bcp14>MUST</bcp14> use only lines in the prefixlen file where the prefix is covered by the address range of the inetnum: object's URL it has followed. </t> <t> If the prefixlen file is signed, and the signer's certificate is replaced with another certificate, then the signature in the prefixlen fileMUST<bcp14>MUST</bcp14> be updated so that it can be properly validated with the new certificate. </t> <t> It is good key hygiene to use a given key for only one purpose. To dedicate a signing private key for signing a prefixlen file, an RPKI Certification Authority (CA) may issue a subordinate certificate exclusively for the purpose shown in <xref target="example" format="default"/>. </t> <t> Harvesting and publishing aggregated prefixlen data outside of the RPSL modelSHOULD<bcp14>SHOULD</bcp14> beavoided asavoided: it can have the effect that more specifics from one aggregatee could undesirably affect the less specifics of a different aggregatee. Moreover, publishing aggregated prefixlen data prevents the reader of the data to perform the checks described in Sections <xreftarget="fetch"/>target="fetch" format="counter"/> and <xreftarget="auth"/>.target="auth" format="counter"/>. </t> <t> An anonymized version of bulk WHOIS data is openly available for all RIRs except ARIN, which requires an authorization. However, for users without such authorization, the same result can be achieved with extra RDAP effort. There is open-source code to pass over such data across all RIRs, collect all prefixlen references, and process them <xref target="PREFIXLEN-FINDER" format="default"/>. </t> <t> To prevent undue load on RPSL and prefixlen servers, entity-fetching prefixlen data using these mechanismsMUST NOT<bcp14>MUST NOT</bcp14> do frequent real-time lookups. prefixlen serversSHOULD<bcp14>SHOULD</bcp14> send an HTTP Expires header <xref target="RFC9111" format="default"/> to signal when prefixlen data should be refetched. If an HTTP Expires or Cache-Control header is present, itMUST<bcp14>MUST</bcp14> be honored by clients. As the data change very infrequently, in the absence of such an HTTP header signal, collectorsSHOULD NOT<bcp14>SHOULD NOT</bcp14> fetch more frequently than weekly. It would be polite not to fetch at magic times such as midnight UTC, the first of the month, etc., because too many others are likely to do the same. </t> </section> <!--[rfced] Please confirm that the Implementation Status section should remain in the document for publication (see RFC 7942). --> <section anchor="impl" numbered="true" toc="default"> <name>Implementation Status</name> <t>InAs of November 2025, the prefixlen: attribute in inetnum objects has been implemented by the RIPE NCC database. </t> <t> Registrants in databaseswhichthat do not yet support the prefixlen: attribute are using the remarks:, or equivalent, attribute. </t><t><!-- Note to PE: I couldn't find any instance of "Tower of Babel" in [RFC7485]: Current: At the time of publishing this document, the registry data published by ARIN are not the same RPSL as that of the other registries (see [RFC7485] for a survey of the WHOIS Tower of Babel);... --> <t> At the time of publication, the registry data published by ARIN are not the same RPSL as that of the other registries (see <xref target="RFC7485" format="default"/> for a survey of the WHOIS Tower of Babel); therefore, when fetching via bulk WHOIS over HTTPS <xref target="RFC9110" format="default"/>, WHOIS <xref target="RFC3912" format="default"/>, the Registration Data Access Protocol (RDAP) <xref target="RFC9083" format="default"/>, etc., the "NetRange" or "ip network" attribute/key must be treated as"inetnum","inetnum" and the "Comment" attribute must be treated as "remarks". </t> </section> <section anchor="seccons" numbered="true" toc="default"> <name>Security Considerations</name> <t> The consumer of prefixlen dataSHOULD<bcp14>SHOULD</bcp14> fetch and process the data themselves. Importing datasets produced and/or processed by a third party places significant trust in the third party. </t> <t> As mentioned in <xref target="auth" format="default"/>, some RPSL repositories have weak, if any, authentication. This allows spoofing of inetnum: objects pointing to malicious prefixlen files. <xref target="auth" format="default"/> suggests an unfortunately complex method for stronger authentication based on the RPKI. </t> <t> For example, if an inetnum: for a wide address range (e.g., a /16) points to an RPKI-signed prefixlen file, a customer or attacker could publish an unsigned equal or narrower (e.g., a /24) inetnum: in a WHOIS registry that has weak authorization, abusing the rule that the most-specific inetnum: object with a prefixlen referenceMUST<bcp14>MUST</bcp14> be used. </t> <t> If signatures were mandatory, the above attack would be stymied,butbut, ofcoursecourse, that is not happening anytime soon. </t> <t> The RPSL providers have had to throttle fetching from their servers due to too-frequent queries. Usually, they throttle by the querying IP address or block. Similar defenses will likely need to be deployed by prefixlen file servers. </t> <t> As prefixlen files disclose which parts of a prefix belong to anend site,end-site, attackers could better focus DDoS traffic towards a website hosted by a cloud provider by overwhelming only IP addresses from that specificend site.end-site. Furthermore, information collected from prefixlen files could allow for more targeted IPv6 scanning/reconnaissance, where scanners (be it benevolent or malicious ones) can target specific sub-prefixeswhichthat they deem more interesting. </t> <t> It is possible for publishers of prefixlen data to specify incorrect prefixlen data about their prefixes. This couldeitherbe done either by mistake or on purpose. One example could be a malicious network operator trying to overflow the storage of databases that consume prefixlen data by setting a very specific prefix size (e.g., /128 for large blocks of IPv6 address space). In anotherexampleexample, a network operator might annotate their prefixes as using CGN to go around legitimate blocking or throttling. A third example would be a malicious provider publishing fake small allocations, so on receipt of complaints, they could plausibly respond by saying that they stopped the actions of a bad customer and move their malicious activities to a different prefix. As a fourth example, network operators could overwhelm consumers by publishing prefixlen files containing millions or even billions of entries (e.g., enumerating all possible /96 subprefixes of a /32 IPv6 prefix). Therefore, care should be taken when processing prefixlen data, as with any external third-party data. </t> </section> <section anchor="iana" numbered="true" toc="default"> <name>IANA Considerations</name> <t> IANAis asked to registerhas registered an object identifier for one ASN.1 Module in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry as follows: </t><figure> <artwork><![CDATA[ Description OID<table> <thead> <tr> <th>Description</th> <th>OID</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>id-mod-prefixlen-2025</td> <td>1.2.840.113549.1.9.16.0.87</td> <td>RFC 9977</td> </tr> </tbody> </table> <!--[rfced] FYI - we have cut the following text as we believe that this is referring to updating the Reference----------------------------------------------------------------- id-mod-prefixlen-2025 1.2.840.113549.1.9.16.0.TBD0 [RFC-TBD] ]]></artwork> </figure> <t> The SMI Securitycolumn. If there was some other intent (e.g., adding this document as a reference forS/MIME Module Identifier (1.2.840.113549.1.9.16.0) registry is located at: https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-0.the entire registry), please let us know. Original: On publication of this document, the [RFC-TBD] reference needs to be changed to the RFC number assigned to this document.</t> <t> IANA is asked to register an object identifiers for one content type in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry as follows: </t> <figure> <artwork><![CDATA[ Description OID Reference ------------------------------------------------------------------ id-ct-prefixlenCSVwithCRLF 1.2.840.113549.1.9.16.1.TBD1 [RFC-TBD] ]]></artwork> </figure> <t> The SMI Security for S/MIME Content Type Identifier (1.2.840.113549.1.9.16.1) registry is located at: https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-1.and On publication of this document, the [RFC-TBD] reference needs to be changed to the RFC number assigned to this document.</t> </section> <section title="Acknowledgments" anchor="acks">--> <t>Thanks to the authors of <xref target="RFC8805"/> and <xref target="RFC9632"/> and the folk they acknowledge from whom ideas and text have been liberally expropriated. Thanks to John R. LevineIANA has registered an object identifier forproviding useful feedback onone content type in thedraft."SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry as follows: </t> <table> <thead> <tr> <th>Description</th> <th>OID</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>id-ct-prefixlenCSVwithCRLF</td> <td>1.2.840.113549.1.9.16.1.57</td> <td>RFC 9977</td> </tr> </tbody> </table> </section> </middle> <back><references title="Normative References"> &RFC2119; &RFC2622; &RFC2725; &RFC3629; &RFC3779; &RFC4012; &RFC4180; &RFC4648; &RFC5280; &RFC5652; &RFC8174; &RFC6268; &RFC6481; &RFC6487; &RFC6488; &RFC8933; &RFC9110; &RFC9286; &RFC9839;<references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2622.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2725.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3779.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4012.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4180.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6268.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6481.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6487.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6488.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8933.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9286.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9839.xml"/> <reference anchor="X680" target="https://www.itu.int/rec/T-REC-X.680"> <front> <title>Information technology--- Abstract Syntax Notation One (ASN.1): Specification of basic notation</title> <author> <organization>ITU-T</organization> </author> <date year="2021" month="February"/> </front> <seriesInfo name="ITU-T Recommendation" value="X.680"/> <seriesInfo name="ISO/IEC" value="8824-1:2021"/> </reference> </references><references title="Informative References"> &RFC0959; &RFC3912; &RFC4632; &RFC5485; &RFC6598; &RFC7485; &RFC7909; &RFC8805; &RFC8981; &RFC9083; &RFC9111; &RFC9632; &RFC9877;<references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0959.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3912.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4632.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5485.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6598.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7485.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7909.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8805.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8981.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9083.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9111.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9632.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9877.xml"/> <!-- [rfced] FYI: We made some formatting edits to [RIPE81] and [RIPE181] to include the authors for those documents in the reference entries. Original: [RIPE181] RIPE NCC, "Representation Of IP Routing Policies In A Routing Registry", October 1994, <https://www.ripe.net/publications/docs/ripe-181>. [RIPE81] RIPE NCC, "Representation Of IP Routing Policies In The RIPE Database", February 1993, <https://www.ripe.net/publications/docs/ripe-081>. Current: [RIPE181] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J., Karrenberg, D., Terpstra, M., and J. Yu, "Representation Of IP Routing Policies In A Routing Registry", RIPE-181, October 1994, <https://www.ripe.net/publications/docs/ripe-181>. [RIPE81] Bates, T., Jouanigot, J., Karrenberg, D., Lothberg, P., and M. Terpstra, "Representation Of IP Routing Policies In The RIPE Database", RIPE-081, February 1993, <https://www.ripe.net/publications/docs/ripe-081>. --> <reference anchor="RIPE81" target="https://www.ripe.net/publications/docs/ripe-081"> <front> <title>Representation Of IP Routing Policies In The RIPE Database</title><author> <organization>RIPE NCC</organization> </author><author fullname="Tony Bates"/> <author fullname="Jean-Michel Jouanigot"/> <author fullname="Daniel Karrenberg"/> <author fullname="Peter Lothberg"/> <author fullname="Marten Terpstra"/> <date month="February" year="1993"/> </front> <refcontent>RIPE-081</refcontent> </reference> <reference anchor="RIPE181" target="https://www.ripe.net/publications/docs/ripe-181"> <front> <title>Representation Of IP Routing Policies In A Routing Registry</title><author> <organization>RIPE NCC</organization> </author><author fullname="Tony Bates"/> <author fullname="Elise Gerich"/> <author fullname="Laurent Joncheray"/> <author fullname="Jean-Michel Jouanigot"/> <author fullname="Daniel Karrenberg"/> <author fullname="Marten Terpstra"/> <author fullname="Jessica Yu"/> <date month="October" year="1994"/> </front> <refcontent>RIPE-181</refcontent> </reference> <reference anchor="RIPE-DB" target="https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation"> <front> <title>RIPE Database Documentation</title> <author> <organization>RIPE NCC</organization> </author> <date/> </front> </reference> <!-- [rfced] Regarding reference entries [INET6NUM] and [INETNUM]: The original URLs for [INET6NUM] and [INETNUM] point to a page with an "Sorry, we can't seem to find the page you're looking for" error message. We found the following URL that seems to contain the information from the original URLs: https://docs.db.ripe.net/RPSL-Object-Types/Descriptions-of-Primary-Objects Is this the appropriate URL for these references? --> <reference anchor="INETNUM" target="https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-4-description-of-the-inetnum-object"> <front> <title>Description of the INETNUM Object</title> <author> <organization>RIPE NCC</organization> </author> <date month="June" year="2020"/> </front> </reference> <reference anchor="INET6NUM" target="https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-3-description-of-the-inet6num-object"> <front> <title>Description of the INET6NUM Object</title> <author> <organization>RIPE NCC</organization> </author> <date month="October" year="2019"/> </front> </reference> <!-- [rfced] Regarding reference entry [PREFIXLEN-FINDER:] Please review. References to GitHub repositories require a commit hash (see: https://www.rfc-editor.org/styleguide/part2/#ref_repo). The original date for this reference - June 2021 - does not appear in this repositories commit history (https://github.com/massimocandela/prefixlen-finder/commits/main/). May we update this reference to use the most recent commit date and commit hash? Current: [PREFIXLEN-FINDER] "prefixlen-finder", June 2021, <https://github.com/massimocandela/prefixlen-finder>. Perhaps: [PREFIXLEN-FINDER] "prefixlen-finder", commit fa70e6b, 3 June 2025, <https://github.com/massimocandela/prefixlen-finder>. --> <reference anchor="PREFIXLEN-FINDER" target="https://github.com/massimocandela/prefixlen-finder"> <front> <title>prefixlen-finder</title> <author><organization></organization><organization/> </author> <date month="June" year="2021"/> </front> </reference> </references> </references> <sectiontitle="ASN.1 Module"anchor="asn1"> <name>ASN.1 Module</name> <t> This appendix provides an ASN.1 Module <xref target="X680"/> for the CMS content type used for the prefixlen file.</t> <t> CONTENT-TYPE is imported from the ASN.1 Module in <xref target="RFC6268" format="default"/>.</t><t><sourcecode type="asn.1"><![CDATA[ <CODE BEGINS><sourcecode type="asn.1" markers="true"><![CDATA[ PrefixLengthsModule-2025 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) mod(0)TBD087 } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- IMPORTS CONTENT-TYPE FROM CryptographicMessageSyntax-2010 -- in [RFC6268] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ; ContentSet CONTENT-TYPE ::= { ct-prefixlenCSVwithCRLF, ... } ct-prefixlenCSVwithCRLF CONTENT-TYPE ::= { TYPE UTF8String IDENTIFIED BY id-ct-prefixlenCSVwithCRLF } id-ct-prefixlenCSVwithCRLF OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1)TBD157 }END <CODE ENDS> ]]></sourcecode></t>END]]></sourcecode> </section> <sectiontitle="Example"anchor="example"> <name>Example</name> <t> This appendix provides an example, including a trust anchor, a CRL signed by the trust anchor, a CA certificate subordinate to the trust anchor, a CRL signed by the CA, an end-entity certificate subordinate to the CA for signing the prefixlen file, and a detached signature.</t> <t> The trust anchor is represented by a self-signed certificate. As usual in the RPKI, the trust anchor has authority over all IPv4 address blocks, all IPv6 address blocks, and all Autonomous System (AS) numbers.</t><figure><artwork><![CDATA[<artwork><![CDATA[ -----BEGIN CERTIFICATE----- MIIEQTCCAymgAwIBAgIUEggycNoFVRjAuN/Fw7URu0DEZNAwDQYJKoZIhvcNAQEL BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yMzA5MTkyMDMzMzlaFw0zMzA5 MTYyMDMzMzlaMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDQprR+g/i4JyObVURTp1JpGM23vGPyE5fDKFPqV7rw M1Amm7cnew66U02IzV0X5oiv5nSGfRX5UxsbR+vwPBMceQyDgS5lexFiv4fB/Vjf DT2qX/UjsLL9QOeaSOh7ToJSLjmtpa0D9iz7ful3hdxRjpMMZiE/reX9/ymdpW/E dg0F6+T9WGZE1miPeIjl5OZwnmLHCftkN/aaYk1iPNjNniHYIOjC1jSpABmoZyTj sgrwLE2F1fIRkVkwASqToq/D5v9voXaYYaXUNJb4H/5wenRuvT5O/n6PXh70rMQy F5yzLs96ytxqg5gGX9kabVnvxFU8nHfPa0rhlwfTJnljAgMBAAGjggGHMIIBgzAd BgNVHQ4EFgQUwL1SXb7SeLIW7LOjQ5XSBguZCDIwHwYDVR0jBBgwFoAUwL1SXb7S eLIW7LOjQ5XSBguZCDIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYw GAYDVR0gAQH/BA4wDDAKBggrBgEFBQcOAjCBuQYIKwYBBQUHAQsEgawwgakwPgYI KwYBBQUHMAqGMnJzeW5jOi8vcnBraS5leGFtcGxlLm5ldC9yZXBvc2l0b3J5L2V4 YW1wbGUtdGEubWZ0MDUGCCsGAQUFBzANhilodHRwczovL3JyZHAuZXhhbXBsZS5u ZXQvbm90aWZpY2F0aW9uLnhtbDAwBggrBgEFBQcwBYYkcnN5bmM6Ly9ycGtpLmV4 YW1wbGUubmV0L3JlcG9zaXRvcnkvMCcGCCsGAQUFBwEHAQH/BBgwFjAJBAIAATAD AwEAMAkEAgACMAMDAQAwIQYIKwYBBQUHAQgBAf8EEjAQoA4wDDAKAgEAAgUA//// /zANBgkqhkiG9w0BAQsFAAOCAQEAa9eLY9QAmnlZOIyOzbpta5wqcOUQV/yR7o/0 1zkEZaSavKBt19lMK6AXZurx1T5jyjIwG7bEtZZThjtH2m80V5kc2tsFjSq/yp7N JBclMHVd3tXse9If3nXYF4bxRIcir1lXlAbYN+Eo1U3i5qJO+fxouzt7Merk2Dih nsenTeXKzN7tfmuCYZZHCC8viCoJWdH+o1uRM4TiQApZsUJ8sF4TABrrRJmA/Ed5 v0CTBbgqTx7yg0+VarFLPdnjYgtpoCJqwE2C1UpX15rZSaLVuGXtbwXd/cHEg5vF W6QTsMeMQFEUa6hkicDGtxLTUdhckBgmCGoF2nlZii5f1BTWAg== -----END CERTIFICATE-----]]></artwork></figure>]]></artwork> <t> The CRL issued by the trust anchor.</t><figure><artwork><![CDATA[<artwork><![CDATA[ -----BEGIN X509 CRL----- MIIBjjB4AgEBMA0GCSqGSIb3DQEBCwUAMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEX DTI1MTIwNDEzNDgxMVoXDTI2MDEwMzEzNDgxMVqgLzAtMB8GA1UdIwQYMBaAFMC9 Ul2+0niyFuyzo0OV0gYLmQgyMAoGA1UdFAQDAgELMA0GCSqGSIb3DQEBCwUAA4IB AQDLltErZwESHDSkwhnL++hFPAJUJf6NapOV9bzUBr5D6vLgs01dke3AFoUNJCng 15p5EPi7BZnZMx3b+My+Hh8jMOxloKBe6eeZ0impCw5ZveWGwe4u3vH3snl9QkjZ Slz+zxaNidKl/9W5h4rjznwKD98//t75ACa9UFImsE53U5cXwUor0QKd3VDkKLVf nivSzVPaC3hvN85wOXMgC/M3MwD5PCKJ/jEBDfEADfnUIXUbjys13ycH2mX3gBZa svDot/HDgpcQVRZBJC4ecPy9aBfj8EEfmIwidQtS+4vyh7lrR9xKn8wUqvti3Ulx wYTdSdP9LWR+Ha7xdvSMJUiU -----END X509 CRL-----]]></artwork></figure>]]></artwork> <t> The CA certificate is issued by the trust anchor. This certificate grants authority over one IPv4 address block (192.0.2.0/24), one IPv6 address block(2001:db8::/32), and two AS numbers (64496 and 64497).</t><figure><artwork><![CDATA[<artwork><![CDATA[ -----BEGIN CERTIFICATE----- MIIE+zCCA+OgAwIBAgIUcyCzS10hdfG65kbRq7toQAvRDMEwDQYJKoZIhvcNAQEL BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yNTEyMDQxMzQ4MTFaFw0yNjEy MDQxMzQ4MTFaMDMxMTAvBgNVBAMTKDNBQ0UyQ0VGNEZCMjFCN0QxMUUzRTE4NEVG QzFFMjk3QjM3Nzg2NDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc zz1qwTxC2ocw5rqp8ktm2XyYkl8riBVuqlXwfefTxsR2YFpgz9vkYUd5Az9EVEG7 6wGIyZbtmhK63eEeaqbKz2GHub467498BXeVrYysO+YuIGgCEYKznNDZ4j5aaDbo j5+4/z0Qvv6HEsxQd0f8br6lKJwgeRM6+fm7796HNPB0aqD7Zj9NRCLXjbB0DCgJ liH6rXMKR86ofgll9V2mRjesvhdKYgkGbOif9rvxVpLJ/6zdru5CE9yeuJZ59l+n YH/r6PzdJ4Q7yKrJX8qD6A60j4+biaU4MQ72KpsjhQNTTqF/HRwi0N54GDaknEwE TnJQHgLJDYqww9yKWtjjAgMBAAGjggIjMIICHzAdBgNVHQ4EFgQUOs4s70+yG30R 4+GE78Hil7N3hkIwHwYDVR0jBBgwFoAUwL1SXb7SeLIW7LOjQ5XSBguZCDIwDwYD VR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwGAYDVR0gAQH/BA4wDDAKBggr BgEFBQcOAjBDBgNVHR8EPDA6MDigNqA0hjJyc3luYzovL3Jwa2kuZXhhbXBsZS5u ZXQvcmVwb3NpdG9yeS9leGFtcGxlLXRhLmNybDBOBggrBgEFBQcBAQRCMEAwPgYI KwYBBQUHMAKGMnJzeW5jOi8vcnBraS5leGFtcGxlLm5ldC9yZXBvc2l0b3J5L2V4 YW1wbGUtdGEuY2VyMIG5BggrBgEFBQcBCwSBrDCBqTA+BggrBgEFBQcwCoYycnN5 bmM6Ly9ycGtpLmV4YW1wbGUubmV0L3JlcG9zaXRvcnkvZXhhbXBsZS1jYS5tZnQw NQYIKwYBBQUHMA2GKWh0dHBzOi8vcnJkcC5leGFtcGxlLm5ldC9ub3RpZmljYXRp b24ueG1sMDAGCCsGAQUFBzAFhiRyc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVw b3NpdG9yeS8wLgYIKwYBBQUHAQcBAf8EHzAdMAwEAgABMAYDBADAAAIwDQQCAAIw BwMFACABDbgwIQYIKwYBBQUHAQgBAf8EEjAQoA4wDDAKAgMA+/ACAwD78TANBgkq hkiG9w0BAQsFAAOCAQEAdgCV/G9f6NIC3MhqAqSoA56/7bJJ2QC3bChnwZH0MB3p VjYNhcY99ZFBv9TdsAd0GsPMEL4zGqvxkSQZjrJHSqe6GHJB5Kr4/SDbbyu6vylh QPDNIBnH2o5iXU/34Klx3Wf42ttsi7DAhGcR6OOAR4UrO/7ng19oFXe3tBWDcVLf Jd6Bqptp8fkfpSyHQEezZ0xA5h/SXeN+qvbL0rOJcI4+Ybbqa7U21+cz/JftAdgw vatxQzGxl47HyvC7IpROI0+8jXB9xwOGKxznBve9/LeIZzMYBRuYV6jVWe4V6ja9 2crgaoDZaOH78JLjg3Qt+hVSQ667lak3QXZ1FVp1WA== -----END CERTIFICATE-----]]></artwork></figure>]]></artwork> <t> The CRL issued by the CA.</t><figure><artwork><![CDATA[<artwork><![CDATA[ -----BEGIN X509 CRL----- MIIBrTCBlgIBATANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEygzQUNFMkNFRjRG QjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyFw0yNTEyMDQxMzQ4MTFaFw0y NjAxMDMxMzQ4MTFaoC8wLTAfBgNVHSMEGDAWgBQ6zizvT7IbfRHj4YTvweKXs3eG QjAKBgNVHRQEAwIBATANBgkqhkiG9w0BAQsFAAOCAQEAyxbVA6TeFHU8BqciB0q1 Of81r/Ux/PTKIyhpVznTcVxa4wodsQcaMVNKYxINHNwctCm901Rx3nO61BqZpvaL XPdkstlnzG+WaHcfUj09sTx7Eb/r17J1EACr2p9dVq4fTpuw/+Nq7ecj80NM74z6 uCiA5iyEjI0PYen4/IOgods0ceUm0QBOCTKNI3cbjZjiAfY9tRgqR1F2eeeproEM +ulVORW4yfivsMGMHApaeLVnUTnAln9YqnL7mQGMBrRIBwYi2dk76K++iQBhWEP0 Ofv22y7UIbfqycrYROuJ9yGdwi5IAhpbKoQIzS5DimN+xykJdGPm0d2jUwNRibPh GQ== -----END X509 CRL-----]]></artwork></figure>]]></artwork> <t> The end-entity certificate is issued by the CA. This certificate grants signature authority for one IPv4 address block (192.0.2.0/24). Signature authority for the IPv6 address block and the AS numbers is not needed for the prefixlen file that will be signed, so these items are not included in the end-entity certificate.</t><figure><artwork><![CDATA[<artwork><![CDATA[ -----BEGIN CERTIFICATE----- MIIEVjCCAz6gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZvowDQYJKoZIhvcNAQEL BQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExRTNFMTg0RUZDMUUyOTdC Mzc3ODY0MjAeFw0yNTEyMDQxMzQ4MTFaFw0yNjA5MzAxMzQ4MTFaMDMxMTAvBgNV BAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM0NUFCRjA1M0ExODcwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycTQrOb/qB2W3i3Ki8PhA/DEW yii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQgtPCVwr62hTQZCIowBN0BL0c K0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZmr5xphXRvE+mzuJVLgu2V1upm BXuWloeymudh6WWJ+GDjwPXO3RiXBejBrOFNXhaFLe08y4DPfr/S/tXJOBm7QzQp tmbPLYtGfprYu45liFFqqP94UeLpISfXd36AKGzqTFCcc3EW9l5UFE1MFLlnoEog qtoLoKABt0IkOFGKeC/EgeaBdWLe469ddC9rQft5w6g6cmxG+aYDdIEB34zrAgMB AAGjggFgMIIBXDAdBgNVHQ4EFgQUkUZSo71RwUQmAZiIn1xFq/BToYcwHwYDVR0j BBgwFoAUOs4s70+yG30R4+GE78Hil7N3hkIwDgYDVR0PAQH/BAQDAgeAMBgGA1Ud IAEB/wQOMAwwCgYIKwYBBQUHDgIwYQYDVR0fBFowWDBWoFSgUoZQcnN5bmM6Ly9y cGtpLmV4YW1wbGUubmV0L3JlcG9zaXRvcnkvM0FDRTJDRUY0RkIyMUI3RDExRTNF MTg0RUZDMUUyOTdCMzc3ODY0Mi5jcmwwbAYIKwYBBQUHAQEEYDBeMFwGCCsGAQUF BzAChlByc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVwb3NpdG9yeS8zQUNFMkNF RjRGQjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyLmNlcjAfBggrBgEFBQcB BwEB/wQQMA4wDAQCAAEwBgMEAMAAAjANBgkqhkiG9w0BAQsFAAOCAQEAwvEWPwHe VSFYwknmaOJrVeHrDez4BYg/uqpws0ny8LNUApsStUTrvsdkOMYVqJBifFpUtx7y 1hfEZDkDIP7TC78pYaiTR5WAxSv/dxr9GuGUNgx7YDmvOST9OAZvfEBrNtj7DC+Z jumMNWxMdTkjsLswXmlUF7dZxQjt01w5Wf5aD/MlV87d6mX49A0rjuaeIRTMglUq EzqmnqSVTHVqtQwWlCG45ltS2Keu788RMnkiRDL2CJUoy8Axy5xcYSpf+keqFE13 UUyegHcBUEODfk8AP0hnc6YhXC6+oBz72HbgYqTYyjQNYGS+49b58u5nXWqJoMJm yxybgehJbawpCA== -----END CERTIFICATE-----]]></artwork></figure>]]></artwork> <t> The end-entity certificate is displayed below in detail. For brevity, the other two certificates are not.</t><figure><artwork><![CDATA[<artwork><![CDATA[ 0 1110: SEQUENCE { 4 830: SEQUENCE { 8 3: [0] { 10 1: INTEGER 2 : } 13 20: INTEGER : 27 AD 39 40 83 D7 F2 B5 B9 9B 86 70 C7 75 B2 B9 : 6E E1 66 FA 35 13: SEQUENCE { 37 9: OBJECT IDENTIFIER : sha256WithRSAEncryption (1 2 840 113549 1 1 11) 48 0: NULL : } 50 51: SEQUENCE { 52 49: SET { 54 47: SEQUENCE { 56 3: OBJECT IDENTIFIER commonName (2 5 4 3) 61 40: PrintableString : '3ACE2CEF4FB21B7D11E3E184EFC1E297B3778642' : } : } : } 103 30: SEQUENCE { 105 13: UTCTime 04/12/2025 13:48:11 GMT 120 13: UTCTime 30/09/2026 13:48:11 GMT : } 135 51: SEQUENCE { 137 49: SET { 139 47: SEQUENCE { 141 3: OBJECT IDENTIFIER commonName (2 5 4 3) 146 40: PrintableString : '914652A3BD51C144260198889F5C45ABF053A187' : } : } : } 188 290: SEQUENCE { 192 13: SEQUENCE { 194 9: OBJECT IDENTIFIER : rsaEncryption (1 2 840 113549 1 1 1) 205 0: NULL : } 207 271: BIT STRING, encapsulates { 212 266: SEQUENCE { 216 257: INTEGER : 00 B2 71 34 2B 39 BF EA 07 65 B7 8B 72 A2 F0 F8 : 40 FC 31 16 CA 28 B6 4E 01 A8 F6 98 02 C0 EF 65 : B0 84 48 E9 96 FF 93 E6 92 89 65 8F F6 44 9C CE : 57 10 82 D3 C2 57 0A FA DA 14 D0 64 22 28 C0 13 : 74 04 BD 1C 2B 4F F9 93 58 A6 25 D8 B9 A9 D3 37 : 9E F2 AC C0 CF 02 9E 84 75 D6 F0 7C A5 01 70 AE : E6 66 AF 9C 69 85 74 6F 13 E9 B3 B8 95 4B 82 ED : 95 D6 EA 66 05 7B 96 96 87 B2 9A E7 61 E9 65 89 : F8 60 E3 C0 F5 CE DD 18 97 05 E8 C1 AC E1 4D 5E : 16 85 2D ED 3C CB 80 CF 7E BF D2 FE D5 C9 38 19 : BB 43 34 29 B6 66 CF 2D 8B 46 7E 9A D8 BB 8E 65 : 88 51 6A A8 FF 78 51 E2 E9 21 27 D7 77 7E 80 28 : 6C EA 4C 50 9C 73 71 16 F6 5E 54 14 4D 4C 14 B9 : 67 A0 4A 20 AA DA 0B A0 A0 01 B7 42 24 38 51 8A : 78 2F C4 81 E6 81 75 62 DE E3 AF 5D 74 2F 6B 41 : FB 79 C3 A8 3A 72 6C 46 F9 A6 03 74 81 01 DF 8C : EB 477 3: INTEGER 65537 : } : } : } 482 352: [3] { 486 348: SEQUENCE { 490 29: SEQUENCE { 492 3: OBJECT IDENTIFIER : subjectKeyIdentifier (2 5 29 14) 497 22: OCTET STRING, encapsulates { 499 20: OCTET STRING : 91 46 52 A3 BD 51 C1 44 26 01 98 88 9F 5C 45 AB : F0 53 A1 87 : } : } 521 31: SEQUENCE { 523 3: OBJECT IDENTIFIER : authorityKeyIdentifier (2 5 29 35) 528 24: OCTET STRING, encapsulates { 530 22: SEQUENCE { 532 20: [0] : 3A CE 2C EF 4F B2 1B 7D 11 E3 E1 84 EF C1 E2 97 : B3 77 86 42 : } : } : } 554 14: SEQUENCE { 556 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 561 1: BOOLEAN TRUE 564 4: OCTET STRING, encapsulates { 566 2: BIT STRING 7 unused bits : '1'B (bit 0) : } : } 570 24: SEQUENCE { 572 3: OBJECT IDENTIFIER certificatePolicies (2 5 29 32) 577 1: BOOLEAN TRUE 580 14: OCTET STRING, encapsulates { 582 12: SEQUENCE { 584 10: SEQUENCE { 586 8: OBJECT IDENTIFIER : resourceCertificatePolicy (1 3 6 1 5 5 7 14 2) : } : } : } : } 596 97: SEQUENCE { 598 3: OBJECT IDENTIFIER : cRLDistributionPoints (2 5 29 31) 603 90: OCTET STRING, encapsulates { 605 88: SEQUENCE { 607 86: SEQUENCE { 609 84: [0] { 611 82: [0] { 613 80: [6] : 'rsync://rpki.example.net/repository/3ACE' : '2CEF4FB21B7D11E3E184EFC1E297B3778642.crl' : } : } : } : } : } : } 695 108: SEQUENCE { 697 8: OBJECT IDENTIFIER : authorityInfoAccess (1 3 6 1 5 5 7 1 1) 707 96: OCTET STRING, encapsulates { 709 94: SEQUENCE { 711 92: SEQUENCE { 713 8: OBJECT IDENTIFIER : caIssuers (1 3 6 1 5 5 7 48 2) 723 80: [6] : 'rsync://rpki.example.net/repository/3ACE' : '2CEF4FB21B7D11E3E184EFC1E297B3778642.cer' : } : } : } : } 805 31: SEQUENCE { 807 8: OBJECT IDENTIFIER : ipAddrBlocks (1 3 6 1 5 5 7 1 7) 817 1: BOOLEAN TRUE 820 16: OCTET STRING, encapsulates { 822 14: SEQUENCE { 824 12: SEQUENCE { 826 2: OCTET STRING 00 01 830 6: SEQUENCE { 832 4: BIT STRING : '010000000000000000000011'B : } : } : } : } : } : } : } : } 838 13: SEQUENCE { 840 9: OBJECT IDENTIFIER : sha256WithRSAEncryption (1 2 840 113549 1 1 11) 851 0: NULL : } 853 257: BIT STRING : C2 F1 16 3F 01 DE 55 21 58 C2 49 E6 68 E2 6B 55 : E1 EB 0D EC F8 05 88 3F BA AA 70 B3 49 F2 F0 B3 : 54 02 9B 12 B5 44 EB BE C7 64 38 C6 15 A8 90 62 : 7C 5A 54 B7 1E F2 D6 17 C4 64 39 03 20 FE D3 0B : BF 29 61 A8 93 47 95 80 C5 2B FF 77 1A FD 1A E1 : 94 36 0C 7B 60 39 AF 39 24 FD 38 06 6F 7C 40 6B : 36 D8 FB 0C 2F 99 8E E9 8C 35 6C 4C 75 39 23 B0 : BB 30 5E 69 54 17 B7 59 C5 08 ED D3 5C 39 59 FE : 5A 0F F3 25 57 CE DD EA 65 F8 F4 0D 2B 8E E6 9E : 21 14 CC 82 55 2A 13 3A A6 9E A4 95 4C 75 6A B5 : 0C 16 94 21 B8 E6 5B 52 D8 A7 AE EF CF 11 32 79 : 22 44 32 F6 08 95 28 CB C0 31 CB 9C 5C 61 2A 5F : FA 47 AA 14 4D 77 51 4C 9E 80 77 01 50 43 83 7E : 4F 00 3F 48 67 73 A6 21 5C 2E BE A0 1C FB D8 76 : E0 62 A4 D8 CA 34 0D 60 64 BE E3 D6 F9 F2 EE 67 : 5D 6A 89 A0 C2 66 CB 1C 9B 81 E8 49 6D AC 29 08 : }]]></artwork></figure>]]></artwork> <t> To allow reproduction of the signature results, the end-entity private key is provided. For brevity, the other two private keys are not.</t><figure><artwork><![CDATA[<artwork><![CDATA[ -----BEGIN RSA PRIVATE KEY----- MIIEpQIBAAKCAQEAsnE0Kzm/6gdlt4tyovD4QPwxFsootk4BqPaYAsDvZbCESOmW /5Pmkollj/ZEnM5XEILTwlcK+toU0GQiKMATdAS9HCtP+ZNYpiXYuanTN57yrMDP Ap6EddbwfKUBcK7mZq+caYV0bxPps7iVS4LtldbqZgV7lpaHsprnYellifhg48D1 zt0YlwXowazhTV4WhS3tPMuAz36/0v7VyTgZu0M0KbZmzy2LRn6a2LuOZYhRaqj/ eFHi6SEn13d+gChs6kxQnHNxFvZeVBRNTBS5Z6BKIKraC6CgAbdCJDhRingvxIHm gXVi3uOvXXQva0H7ecOoOnJsRvmmA3SBAd+M6wIDAQABAoIBAQCyB0FeMuKm8bRo 18aKjFGSPEoZi53srIz5bvUgIi92TBLez7ZnzL6Iym26oJ+5th+lCHGO/dqlhXio pI50C5Yc9TFbblb/ECOsuCuuqKFjZ8CD3GVsHozXKJeMM+/o5YZXQrORj6UnwT0z ol/JE5pIGUCIgsXX6tz9s5BP3lUAvVQHsv6+vEVKLxQ3wj/1vIL8O/CN036EV0GJ mpkwmygPjfECT9wbWo0yn3jxJb36+M/QjjUP28oNIVn/IKoPZRXnqchEbuuCJ651 IsaFSqtiThm4WZtvCH/IDq+6/dcMucmTjIRcYwW7fdHfjplllVPve9c/OmpWEQvF t3ArWUt5AoGBANs4764yHxo4mctLIE7G7l/tf9bP4KKUiYw4R4ByEocuqMC4yhmt MPCfOFLOQet71OWCkjP2L/7EKUe9yx7G5KmxAHY6jOjvcRkvGsl6lWFOsQ8p126M Y9hmGzMOjtsdhAiMmOWKzjvm4WqfMgghQe+PnjjSVkgTt+7BxpIuGBAvAoGBANBg 26FF5cDLpixOd3Za1YXsOgguwCaw3Plvi7vUZRpa/zBMELEtyOebfakkIRWNm07l nE+lAZwxm+29PTD0nqCFE91teyzjnQaLO5kkAdJiFuVV3icLOGo399FrnJbKensm FGSli+3KxQhCNIJJfgWzq4bE0ioAMjdGbYXzIYQFAoGBAM6tuDJ36KDU+hIS6wu6 O2TPSfZhF/zPo3pCWQ78/QDb+Zdw4IEiqoBA7F4NPVLg9Y/H8UTx9r/veqe7hPOo Ok7NpIzSmKTHkc5XfZ60Zn9OLFoKbaQ40a1kXoJdWEu2YROaUlAe9F6/Rog6PHYz vLE5qscRbu0XQhLkN+z7bg5bAoGBAKDsbDEb/dbqbyaAYpmwhH2sdRSkphg7Niwc DNm9qWa1J6Zw1+M87I6Q8naRREuU1IAVqqWHVLr/ROBQ6NTJ1Uc5/qFeT2XXUgkf taMKv61tuyjZK3sTmznMh0HfzUpWjEhWnCEuB+ZYVdmO52ZGw2A75RdrILL2+9Dc PvDXVubRAoGAdqXeSWoLxuzZXzl8rsaKrQsTYaXnOWaZieU1SL5vVe8nK257UDqZ E3ng2j5XPTUWli+aNGFEJGRoNtcQvO60O/sFZUhu52sqq9mWVYZNh1TB5aP8X+pV iFcZOLUvQEcN6PA+YQK5FU11rAI1M0Gm5RDnVnUl0L2xfCYxb7FzV6Y= -----END RSA PRIVATE KEY-----]]></artwork></figure>]]></artwork> <t> Signing of "192.0.2.0/24,32,1" (terminated by CR and LF), yields the following detached CMS signature.</t><figure><artwork><![CDATA[<artwork><![CDATA[ # RPKI Signature: 192.0.2.0 - 192.0.2.255 # MIIGQAYJKoZIhvcNAQcCoIIGMTCCBi0CAQMxDTALBglghkgBZQMEAgEwDQYLKoZ # IhvcNAQkQAS+gggRaMIIEVjCCAz6gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZv # owDQYJKoZIhvcNAQELBQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExR # TNFMTg0RUZDMUUyOTdCMzc3ODY0MjAeFw0yNTEyMDQxMzQ4MTFaFw0yNjA5MzAx # MzQ4MTFaMDMxMTAvBgNVBAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM # 0NUFCRjA1M0ExODcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycT # QrOb/qB2W3i3Ki8PhA/DEWyii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQg # tPCVwr62hTQZCIowBN0BL0cK0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZm # r5xphXRvE+mzuJVLgu2V1upmBXuWloeymudh6WWJ+GDjwPXO3RiXBejBrOFNXha # FLe08y4DPfr/S/tXJOBm7QzQptmbPLYtGfprYu45liFFqqP94UeLpISfXd36AKG # zqTFCcc3EW9l5UFE1MFLlnoEogqtoLoKABt0IkOFGKeC/EgeaBdWLe469ddC9rQ # ft5w6g6cmxG+aYDdIEB34zrAgMBAAGjggFgMIIBXDAdBgNVHQ4EFgQUkUZSo71R # wUQmAZiIn1xFq/BToYcwHwYDVR0jBBgwFoAUOs4s70+yG30R4+GE78Hil7N3hkI # wDgYDVR0PAQH/BAQDAgeAMBgGA1UdIAEB/wQOMAwwCgYIKwYBBQUHDgIwYQYDVR # 0fBFowWDBWoFSgUoZQcnN5bmM6Ly9ycGtpLmV4YW1wbGUubmV0L3JlcG9zaXRvc # nkvM0FDRTJDRUY0RkIyMUI3RDExRTNFMTg0RUZDMUUyOTdCMzc3ODY0Mi5jcmww # bAYIKwYBBQUHAQEEYDBeMFwGCCsGAQUFBzAChlByc3luYzovL3Jwa2kuZXhhbXB # sZS5uZXQvcmVwb3NpdG9yeS8zQUNFMkNFRjRGQjIxQjdEMTFFM0UxODRFRkMxRT # I5N0IzNzc4NjQyLmNlcjAfBggrBgEFBQcBBwEB/wQQMA4wDAQCAAEwBgMEAMAAA # jANBgkqhkiG9w0BAQsFAAOCAQEAwvEWPwHeVSFYwknmaOJrVeHrDez4BYg/uqpw # s0ny8LNUApsStUTrvsdkOMYVqJBifFpUtx7y1hfEZDkDIP7TC78pYaiTR5WAxSv # /dxr9GuGUNgx7YDmvOST9OAZvfEBrNtj7DC+ZjumMNWxMdTkjsLswXmlUF7dZxQ # jt01w5Wf5aD/MlV87d6mX49A0rjuaeIRTMglUqEzqmnqSVTHVqtQwWlCG45ltS2 # Keu788RMnkiRDL2CJUoy8Axy5xcYSpf+keqFE13UUyegHcBUEODfk8AP0hnc6Yh # XC6+oBz72HbgYqTYyjQNYGS+49b58u5nXWqJoMJmyxybgehJbawpCDGCAaowggG # mAgEDgBSRRlKjvVHBRCYBmIifXEWr8FOhhzALBglghkgBZQMEAgGgazAaBgkqhk # iG9w0BCQMxDQYLKoZIhvcNAQkQAS8wHAYJKoZIhvcNAQkFMQ8XDTI1MTIwNDEzN # DgxMVowLwYJKoZIhvcNAQkEMSIEIGMBdMKw5mjZYL9qP4ivwgMt8g2+qEO0+Dcn # N5vQO1bNMA0GCSqGSIb3DQEBAQUABIIBABRER8F8BATarhuti2Zkqv6sxEgV6Kb # Xjd5NCHiumoD57flhRf68BmdR5agZDq7whq68MpRXxPwwRHWGSCKUXoIOo5O4VX # 1xKwAlu8t8Wpx+P+wGmIi1nDuFSPNSHtgw1cMGNSwCYfDzkn18pBB6qKCWyS0Ea # tTIBp/oqvlUHHOyN4bFsvdbyahEQ5JGmF9yZaSZ8LV73B+X5VbpkjpQP+SL9Lpu # mh41Jg2BrPyvnWgJakE2S0G3U/b9dujknHM5JpuQP8fX4guziTVu+3LoF0sD6ux # rd3g39IKaRz/hukUI02tMLI0ZpNp4Kjc/ObD4tcwvg2bmOjHF953M5EWGYZE= # End Signature: 192.0.2.0 - 192.0.2.255]]></artwork></figure>]]></artwork> </section> <section anchor="acks" numbered="false"> <name>Acknowledgments</name> <t> Thanks to the authors of <xref target="RFC8805"/> and <xref target="RFC9632"/> and the folk they acknowledge from whom ideas and text have been liberally expropriated. Thanks to <contact fullname="John R. Levine"/> for providing useful feedback on the document. </t> </section> <!--[rfced] We had the following questions/comments related to abbreviation use throughout the document: a) May we expand CRL as Certificate Revocation List per RFC 5280? b) FYI - we have removed subsequent expansions of abbreviations per the guidance at https://www.rfc-editor.org/styleguide/part2/#exp_abbrev. --> <!--[rfced] We had the following questions/comments related to terminology used throughout the document: a) we have used the hyphenated end-site throughout; please let us know any objections. --> <!-- [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> </rfc>