RFC 9632

Finding and Using Geofeed Data

📅 published August 2024, from ietf

📮 RFC 9632: Finding and Using Geofeed Data 🌸

Okay bestie, so this is the Standards Track doc that tells you how to find and use geofeed data 💅. Geofeeds are CSV files that map IP address ranges to geographic locales, and this one is the glow-up that makes finding them way easier. It is literally the spec for the geofeed situation ✨.

The title block, the important bits: this is RFC 9632 by R. Bush (IIJ Research & Arrcus), M. Candela (NTT), W. Kumari (Google), and R. Housley (Vigil Security). It's from August 2024 and it's a Standards Track doc 🎀. It obsoletes RFC 9092 💀, so 9092 is officially retired, and it doesn't update anything else. The ISSN is 2070-1721 🦋.

Abstract 🦋

Okay so the abstract says this doc adds to the RPSL inetnum: class so it can point to geofeed CSV files specifically 🧚. It also describes an optional way to use RPKI to authenticate those files 🔐. And yeah, it obsoletes RFC 9092 🙈.

Status of This Memo 💜

This is an Internet Standards Track document ✨. It's a product of the IETF and reflects the consensus of the IETF community. It got public review and was approved by the IESG 🫶. If you want more on Internet Standards, check out Section 2 of RFC 7841 💅.

Info about the current status, errata, and feedback lives at https://www.rfc-editor.org/info/rfc9632 🌈.

Copyright Notice 🌈

Copyright (c) 2024 IETF Trust and the document authors, all rights reserved 💖. This doc is subject to BCP 78 and the IETF Trust's Legal Provisions (https://trustee.ietf.org/license-info) as of the publication date, so read those carefully because they're your rights and restrictions 🙈. Code extracted from this doc needs to include the Revised BSD License text from Section 4.e of the Trust Legal Provisions, and it comes with no warranty 🔥.

Table of Contents 🍓

1.  Introduction
  1.1.  Requirements Language
2.  Geofeed Files
3.  inetnum: Class
4.  Fetching Geofeed Data
5.  Authenticating Geofeed Data (Optional)
6.  Operational Considerations
7.  Privacy Considerations
8.  Implementation Status
9.  Security Considerations
10. IANA Considerations
11. References
  11.1.  Normative References
  11.2.  Informative References
Appendix A.  Example
Acknowledgments
Authors' Addresses

1. Introduction ✨

Okay so content providers and other services love to tailor stuff based on where you are 🌍. They usually do this with your source IP address, which isn't always a reliable pin on a person, so see Section 14 of [RFC6269] for the deets 🙈. Infrastructure admins also want to publish where their stuff lives 🏢. [RFC8805] defines geofeed, which is the syntax for linking geographic locales to IP addresses 🗺️, but it doesn't say how to find the right geofeed for an IP address 😭.

This doc adds to the RPSL [RFC2725] inetnum: class so it can point at geofeed data files, and it explains how to use them responsibly 💅. Wherever inetnum: shows up, inet6num: should be assumed too [RFC4012] 🦋.

The reader might find [INETNUM] and [INET6NUM] helpful, and they're definitely more wordy descriptions of the inetnum: database classes 📚.

There's also an optional authentication scheme for geofeed data in Section 5, which is an utterly awesome but slightly complex glow-up 🔐👑.

This doc obsoletes [RFC9092] 💀. Here's what changed from it:

RIPE has implemented the geofeed: attribute 🎉.
This doc allows, but discourages, an inetnum: to have both a geofeed remarks: attribute and a geofeed: attribute 🙈.
Section 5 (Authentication) got rewritten to be more formal 📝.
Geofeed files are only UTF-8 CSV 💖.
This doc stresses that authenticating geofeed data is optional 🫶.
IP Address Delegation extensions must not use "inherit" 🚫.
If geofeed data are present, geographic location hints in other data should be ignored ✨.

1.1. Requirements Language 💜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc mean what BCP 14 [RFC2119] [RFC8174] says, but only when they appear in ALL CAPS like shown here 🔥.

2. Geofeed Files 🎀

Geofeed files are described in [RFC8805] 📖. They give an IP address resource "owner" a way to link those IP addresses to geographic locales 🌏.

Per [RFC8805], geofeed files are comma-separated values (CSV) in UTF-8 text, not HTML, richtext, or other formats 💅.

Content providers and anyone else who wants to locate an IP address to a geographic locale need to find the right geofeed data 🔍. Section 3 explains how to find the relevant geofeed [RFC8805] file for a given IP address 🧚.

Geofeed data for big providers with lots of horizontal scale and high granularity can get really large 😭. A file can be even bigger if an unsigned geofeed file mashes together data for many prefixes, or if dual IPv4/IPv6 spaces are represented, etc. 📦

Geofeed data do have privacy considerations (see Section 7), and this process makes bulk access to those data easier 🙈.

This doc also suggests an optional signature to strongly authenticate the data in geofeed files 🔐.

3. inetnum: Class 🦋

The original RPSL specs, starting with [RIPE81], [RIPE181], and a bunch of later docs, were written by the RIPE community 🇪🇺. The IETF standardized RPSL in [RFC2622] and [RFC4012] 📜. Since then, the Regional Internet Registry (RIR) community has modified and really extended it, mostly RIPE [RIPE-DB] 💫. When this doc was published, change control of RPSL effectively sat with the operator community 👑.

The inetnum: database class is specified by RPSL, along with Routing Policy System Security [RFC2725] and RPSLng [RFC4012], which the Regional Internet Registries (RIRs) use 🌸. Each of these objects describes an IP address range and its attributes 🎀. The inetnum: objects form a hierarchy ordered on the address space 🌳.

Ideally, RPSL would get a new geofeed: attribute in the inetnum: class 🥰. Until a particular RIR database has the geofeed: attribute, this doc defines the syntax of a Geofeed remarks: attribute, which holds an HTTPS URL of a geofeed file 🔗. The format of the inetnum: geofeed remarks: attribute MUST be as in this example, "remarks: Geofeed ", where the token "Geofeed " MUST be case sensitive, followed by a URL that will vary, but it MUST refer only to a single geofeed [RFC8805] file 🚨.

inetnum: 192.0.2.0/24 # example
remarks: Geofeed https://example.com/geofeed

We leave global agreement on RPSL modification to the relevant parties 🤝, but we specify that a proper geofeed: attribute in the inetnum: class MUST be "geofeed:" and MUST be followed by a single URL that will vary, but it MUST refer only to a single geofeed [RFC8805] file 💖.

inetnum: 192.0.2.0/24 # example
geofeed: https://example.com/geofeed

The URL uses HTTPS, so the WebPKI gives authentication, integrity, and confidentiality for the fetched geofeed file 🔒. But the WebPKI can't authenticate IP address space assignment 😬. The RPKI (see [RFC6481]) can authenticate IP space assignment, so check out optional authentication in Section 5 👑.

Until all producers of inetnum: objects (aka the RIRs) say they've moved to supporting the geofeed: attribute, consumers who look at inetnum: objects to find geofeed URLs MUST be able to consume both the remarks: and geofeed: forms 🫶.

The migration doesn't just mean the RIRs support geofeed:. It also means all registrants have moved their inetnum: objects from remarks: to geofeed: attributes 🌈.

Any particular inetnum: object SHOULD have, at most, one geofeed reference, whether that's a remarks: or a proper geofeed: attribute when it's implemented 🎯. Since the RIR can't formally check the remarks: form, this can't be formally enforced 🙃. A geofeed: attribute is preferred, obviously, if the RIR supports it 💅. If there's more than one type of attribute in the inetnum: object, the geofeed: attribute MUST be used ✨.

For inetnum: objects covering the same address range, a signed geofeed file MUST 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: attribute MUST be preferred 🕰️.

If a geofeed file describes multiple disjoint ranges of IP address space, there are likely to be geofeed references from multiple inetnum: objects 🧩. Files with geofeed references from multiple inetnum: objects are not compatible with the signing procedure in Section 5 😭.

An unsigned, and only an unsigned, geofeed file MAY be referenced by multiple inetnum: objects and MAY contain prefixes from more than one registry 🌍.

When fetching, the most specific inetnum: object with a geofeed reference MUST be used 🎯.

It's significant that geofeed 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 geofeed file where P has been subdivided into one or more longer prefixes 🧚.

4. Fetching Geofeed Data 💅

okay bestie, this section is all about how interested parties should fetch and read geofeed files 🧚 It's a guideline, so the vibe is "here's the cute way to do it," not a strict rulebook.

Back before [RFC9092] showed up, everyone fetched geofeeds however they wanted 🙈 It was up to each implementor, usually with no consistent authentication, and a lot of the data got passed around by email with zero formal authorization or validation. Chaotic, honestly 💀

To keep the load down on the RIRs' WHOIS [RFC3912] services, the RIR's FTP [RFC0959] services SHOULD be used when you're gathering inetnum: objects with geofeed references at scale 🫶 Bulk access is way more efficient than brute-forcing through the IP space one address at a time. Main character move 👑

When you're reading data from an unsigned geofeed file, you MUST ignore any data outside the address range of the referring inetnum: object 🎀 The point is to avoid importing data about ranges the operator doesn't control. Also, signed files MUST only contain prefixes within the referring inetnum:'s range, as Section 5 requires 💜

If you do fetch geofeed files, any other location information from the inetnum: MUST be ignored 🙅‍♀️

Given an address range you care about, the most specific inetnum: object with a geofeed reference MUST be used to fetch the geofeed file ✨ Here's an example. Say the fetching party finds these inetnum: objects:

inetnum: 192.0.0.0/22 # example
remarks: Geofeed https://example.com/geofeed_1

inetnum: 192.0.2.0/24 # example
remarks: Geofeed https://example.com/geofeed_2

An application looking for geofeed data for 192.0.2.0/29 MUST ignore the data in geofeed_1 🙅‍♀️ Why? Because 192.0.2.0/29 sits inside the more specific 192.0.2.0/24 inetnum:, which covers that address range, and that inetnum: does have a geofeed reference. Literally the most specific one wins, periodt 💅

Hints in inetnum: objects like country:, geoloc:, and so on tend to be administrative, not deployment-specific 🌍 Think about big, maybe global, providers whose headquarters are super far from most of their actual deployments. So if geofeed data is specified, either as a geofeed: attribute or in a geofeed remarks: attribute, then other geographic hints for that address range MUST be ignored. That includes country:, geoloc:, DNS geoloc RRsets, and so on 🙈

There's open-source code that walks the RPSL data across all of the RIRs, collects every geofeed reference, and processes them [GEOFEED-FINDER] 🧚 It implements the steps above, plus all of the Operational Considerations in Section 6, including caching. It spits out one single geofeed file that merges all the geofeed files it found. You can run this open-source code daily with a cron job, and the output file can be used directly. Low-effort, high-reward, iconic 🌸

RIRs are converging on Registration Data Access Protocol (RDAP) support, and that includes geofeed data; see [RDAP-GEOFEED] 🦋 Just know that RDAP SHOULD NOT be used for bulk retrieval of geofeed data. Bulk is FTP's job 😭

5. Authenticating Geofeed Data (Optional) 🔐

okay so the big question is whether a particular geofeed [RFC8805] data set is actually valid. Like, is it authorized by the "owner" of the IP address space, and is it authoritative in some sense? ✨ The inetnum: that points to the geofeed [RFC8805] file gives you some assurance. The catch is that the RPSL in some repositories is weakly authenticated at best 💀 Signing the RPSL per [RFC7909] would be the dream, except every RPSL registry would have to deploy it, and there are a LOT of them 😩

So this section specifies an optional authenticator for the geofeed data set. It follows "Signed Object Template for the Resource Public Key Infrastructure (RPKI)" [RFC6488] 💜

A single optional authenticator MAY be appended to a geofeed [RFC8805] file 🎀 It's 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 format below bundles the relevant RPKI certificate together with a signature over the geofeed text 🫶

Canonicalization is the first step. It converts the data from its internal character representation to the UTF-8 [RFC3629] character encoding, and the <CRLF> sequence MUST 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 characters MUST NOT be changed by canonicalization. Trailing blank lines MUST NOT appear at the end of the file, so the file must not end with multiple consecutive <CRLF> sequences. Any end-of-file marker used by an operating system is not considered part of the file content. When present, those end-of-file markers MUST NOT be covered by the digital signature 🙅‍♀️

If the authenticator isn't in the canonical form described above, then the authenticator is invalid 💀

Next, borrowing detached signatures from [RFC5485], and after file canonicalization, you use the Cryptographic Message Syntax (CMS) [RFC5652] to create a detached DER-encoded signature. That signature then gets Base64 encoded with padding (as defined in Section 4 of [RFC4648]) and line wrapped to 72 or fewer characters 🍓 The same digest algorithm MUST be used for calculating the message digest of the content being signed (the geofeed file) and for calculating the message digest on the SignerInfo SignedAttributes [RFC8933]. The message digest algorithm identifier MUST appear in both the CMS SignedData DigestAlgorithmIdentifiers and the SignerInfo DigestAlgorithmIdentifier [RFC5652]. The RPKI certificate covering the geofeed inetnum: object's address range is included in the CMS SignedData certificates field [RFC5652] 👑

The address range of the signing certificate MUST cover all prefixes in the signed geofeed file. If it doesn't, the authenticator is invalid 🙈

The signing certificate MUST NOT include the Autonomous System Identifier Delegation certificate extension [RFC3779]. If it's present, the authenticator is invalid 🚫

As with many other RPKI signed objects, the IP Address Delegation certificate extension MUST NOT use the "inherit" capability defined in Section 2.2.3.5 of [RFC3779]. If "inherit" is used, the authenticator is invalid 💅

Why the no-inherit rule? An IP Address Delegation extension using "inherit" would complicate processing 😩 The implementation would have to build the certification path from the end entity to the trust anchor, then validate the path from the trust anchor to the end entity, and then remember that parameter when the validated public key gets used to check a signature on a CMS object. Remembering things from certification path validation for later CMS processing would be quite complex and error-prone. Plus, the certificates don't get that much bigger by just repeating the information, so it's not worth the mess 🧚

Here's a key definition. An address range A "covers" address range B if the range of B is identical to or a subset of A. We say "address range" because inetnum: objects and RPKI certificates don't need to align on Classless Inter-Domain Routing (CIDR) [RFC4632] prefix boundaries, while the lines in a geofeed file do 🦋

The Certification Authority (CA) SHOULD sign only one geofeed file with each generated private key, and SHOULD generate a new key pair for each new version of a particular geofeed file. The CA MUST generate a new end entity (EE) certificate for each signing of a particular geofeed file. An associated EE certificate used this way is called a "one-time-use" EE certificate (see Section 3 of [RFC6487]) 🌸

Identifying the private key tied to the certificate, and getting the department that controls it (which might live in a Hardware Security Module (HSM)) to generate the CMS signature, is left as an exercise for the implementor 🙃 Verifying the signature, though, has no similar complexity. The certificate, which is validated in the public RPKI, contains the public key you need. The RPKI trust anchors for the RIRs are expected to already be available to the party doing signature validation. Validation of the CMS signature over the geofeed file involves these steps:

Obtaining the signer's certificate from the CMS SignedData CertificateSet [RFC5652]. The certificate SubjectKeyIdentifier extension [RFC5280] MUST match the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier [RFC5652]. If the key identifiers do not match, then validation MUST fail 🔑
Validating the signer's certificate MUST ensure that it is part of the current [RFC9286] manifest and that all resources are covered by the RPKI certificate 📜
Constructing 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 path MUST be valid according to the validation algorithm in [RFC5280] and the additional checks specified in [RFC3779] associated with the IP Address Delegation certificate extension and the Autonomous System Identifier Delegation certificate extension. If certification path validation is unsuccessful, then validation MUST fail 🛤️
Validating the CMS SignedData as specified in [RFC5652] using the public key from the validated signer's certificate. If the signature validation is unsuccessful, then validation MUST fail ✍️
Confirming that the eContentType object identifier (OID) is id-ct-geofeedCSVwithCRLF (1.2.840.113549.1.9.16.1.47). This OID MUST appear within both the eContentType in the encapContentInfo object and within the ContentType signed attribute in the signerInfo object (see [RFC6488]) 🏷️
Verifying that the IP Address Delegation certificate extension [RFC3779] covers all of the address ranges of the geofeed file. If all of the address ranges are not covered, then validation MUST fail 🗺️

All of the above steps MUST be successful for the geofeed file signature to be considered valid 🥹

The authenticator MUST be hidden as a series of "#" comments at the end of the geofeed file 🫣 The following simple example is cryptographically incorrect (so don't copy it for real!):

# 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

A correct and full example is in Appendix A 📖

The CMS signature does not cover the signature lines 💜

The bracketing "# RPKI Signature:" and "# End Signature:" lines MUST be present as shown in the example. The RPKI Signature's IP address range MUST match that of the geofeed URL in the inetnum: that points to the geofeed file 🎀

6. Operational Considerations 🛠️

Okay bestie, so first things first 💅 To make the inetnum: objects, an operator who wants to register where their geofeed file lives has to coordinate with their Regional Internet Registry (RIR) or National Internet Registry (NIR) and/or any provider Local Internet Registry (LIR) that assigned them their address ranges 🗺️. The RIRs/NIRs give assignees ways to create and maintain inetnum: objects. They also handle assigning or sub-assigning IP address resources, and they let the assignee create WHOIS data, including inetnum: objects, that refers to geofeed files 🧚.

The geofeed files MUST be published via and fetched using HTTPS [RFC9110]. 🔒

When using data from a geofeed file, one MUST ignore data outside the referring inetnum: object's inetnum: attribute address range. ✨

If and only if the geofeed file is not signed per Section 5, then multiple inetnum: objects MAY refer to the same geofeed file, and the consumer MUST use only lines in the geofeed file where the prefix is covered by the address range of the inetnum: object's URL it has followed. 🎀

If the geofeed file is signed, and the signer's certificate changes, the signature in the geofeed file MUST be updated. 🔁

It is good key hygiene to use a given key for only one purpose 🔑 To dedicate a signing private key for signing a geofeed file, an RPKI Certification Authority (CA) may issue a subordinate certificate exclusively for the purpose shown in Appendix A. 🌸

Harvesting and publishing aggregated geofeed data outside of the RPSL model should be avoided, because detailed data from one aggregatee could undesirably affect the less detailed data of a different aggregatee 🙈 Moreover, publishing aggregated geofeed data stops the reader of that data from performing the checks described in Sections 4 and 5. Not ideal!

At the time of publishing this document, geolocation providers have bulk WHOIS data access at all the RIRs 📦 An anonymized version of that data is openly available for all RIRs except ARIN, which requires an authorization. For users without that authorization, the same result can be achieved with extra RDAP effort. There is open-source code that passes over this data across all RIRs, collects all geofeed references, and processes them [GEOFEED-FINDER]. Iconic tooling, honestly 🧚

To prevent undue load on RPSL and geofeed servers, entity-fetching geofeed data using these mechanisms MUST NOT do frequent real-time lookups 🚫 Section 3.4 of [RFC8805] suggests using the HTTP Expires header [RFC9111] to signal when geofeed data should be refetched. Because the data change very infrequently, in the absence of such an HTTP Header signal, collectors SHOULD NOT fetch more frequently than weekly 📅 It would also be polite not to fetch at magic times such as midnight UTC, the first of the month, etc., because way too many others are likely to do the same 🙃💀

7. Privacy Considerations 🔐

Okay, this section is kind of a big deal 😭 [RFC8805] geofeed data may reveal the approximate location of an IP address, which might in turn reveal the approximate location of an individual user. Unfortunately, [RFC8805] provides no privacy guidance on avoiding or easing possible damage from this exposure of the user. When publishing pointers to geofeed files as described in this document, the operator should be aware of this exposure in geofeed data and be cautious 👀 All the privacy considerations of Section 4 of [RFC8805] apply to this document too.

Where [RFC8805] provided the ability to publish location data, this document makes bulk access to that data readily available. This is a goal, not an accident 💅

8. Implementation Status 📊

At the time of publishing this document, the geofeed: attribute in inetnum objects has been implemented in the RIPE and APNIC databases 🇪🇺🇦🇺✨

Registrants in databases that do not yet support the geofeed: attribute are using the remarks: attribute, or an equivalent 🧩

At the time of publishing this document, the registry data published by ARIN is not the same RPSL as that of the other registries (see [RFC7485] for a survey of the WHOIS Tower of Babel) 🗼 Therefore, when fetching from ARIN via FTP [RFC0959], WHOIS [RFC3912], the RDAP [RFC9082], etc., the "NetRange" attribute/key must be treated as "inetnum", and the "Comment" attribute must be treated as "remarks". Lowkey confusing, but that's the vibe 🙈

[rpki-client] can be used to authenticate a signed geofeed file 🔏

9. Security Considerations 🛡️

This section is SERIOUS, bestie 🚨 It is generally prudent for a consumer of geofeed data to also use other sources to cross-validate the data. All the security considerations of [RFC8805] apply here as well.

The consumer of geofeed data SHOULD fetch and process the data themselves. Importing data sets produced and/or processed by a third party places significant trust in that third party 🫣

As mentioned in Section 5, some RPSL repositories have weak, if any, authentication. This allows spoofing of inetnum: objects pointing to malicious geofeed files 😈 Section 5 suggests an unfortunately complex method for stronger authentication based on the RPKI. Ugh, I know 😩

For example, if an inetnum: for a wide address range (e.g., a /16) points to an RPKI-signed geofeed 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. That works by abusing the rule that the most-specific inetnum: object with a geofeed reference MUST be used 🕵️‍♀️💀

If signatures were mandatory, the above attack would be stymied, but of course that is not happening anytime soon 🥲

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 geofeed file servers 🚧

10. IANA Considerations 🦋

In the SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group (located at <https://www.iana.org/assignments/smi-numbers/>), the reference for this registration has been updated to this document 📝

         +=========+==========================+===========+
         | Decimal | Description              | Reference |
         +=========+==========================+===========+
         | 47      | id-ct-geofeedCSVwithCRLF | RFC 9632  |
         +---------+--------------------------+-----------+

            Table 1: From SMI Security for S/MIME Module
                Identifier (1.2.840.113549.1.9.16.1)

11. References 📚

11.1. Normative References 🎀

Here's the full squad of normative references, all the details included 💖

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC2622]  Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
           Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
           "Routing Policy Specification Language (RPSL)", RFC 2622,
           DOI 10.17487/RFC2622, June 1999,
           <https://www.rfc-editor.org/info/rfc2622>.

[RFC2725]  Villamizar, C., Alaettinoglu, C., Meyer, D., and S.
           Murphy, "Routing Policy System Security", RFC 2725,
           DOI 10.17487/RFC2725, December 1999,
           <https://www.rfc-editor.org/info/rfc2725>.

[RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
           10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
           2003, <https://www.rfc-editor.org/info/rfc3629>.

[RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
           Addresses and AS Identifiers", RFC 3779,
           DOI 10.17487/RFC3779, June 2004,
           <https://www.rfc-editor.org/info/rfc3779>.

[RFC4012]  Blunk, L., Damas, J., Parent, F., and A. Robachevsky,
           "Routing Policy Specification Language next generation
           (RPSLng)", RFC 4012, DOI 10.17487/RFC4012, March 2005,
           <https://www.rfc-editor.org/info/rfc4012>.

[RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
           Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
           <https://www.rfc-editor.org/info/rfc4648>.

[RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
           Housley, R., and W. Polk, "Internet X.509 Public Key
           Infrastructure Certificate and Certificate Revocation List
           (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
           <https://www.rfc-editor.org/info/rfc5280>.

[RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
           RFC 5652, DOI 10.17487/RFC5652, September 2009,
           <https://www.rfc-editor.org/info/rfc5652>.

[RFC6481]  Huston, G., Loomans, R., and G. Michaelson, "A Profile for
           Resource Certificate Repository Structure", RFC 6481,
           DOI 10.17487/RFC6481, February 2012,
           <https://www.rfc-editor.org/info/rfc6481>.

[RFC6487]  Huston, G., Michaelson, G., and R. Loomans, "A Profile for
           X.509 PKIX Resource Certificates", RFC 6487,
           DOI 10.17487/RFC6487, February 2012,
           <https://www.rfc-editor.org/info/rfc6487>.

[RFC6488]  Lepinski, M., Chi, A., and S. Kent, "Signed Object
           Template for the Resource Public Key Infrastructure
           (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
           <https://www.rfc-editor.org/info/rfc6488>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8805]  Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W.
           Kumari, "A Format for Self-Published IP Geolocation
           Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020,
           <https://www.rfc-editor.org/info/rfc8805>.

[RFC8933]  Housley, R., "Update to the Cryptographic Message Syntax
           (CMS) for Algorithm Identifier Protection", RFC 8933,
           DOI 10.17487/RFC8933, October 2020,
           <https://www.rfc-editor.org/info/rfc8933>.

[RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
           Ed., "HTTP Semantics", STD 97, RFC 9110,
           DOI 10.17487/RFC9110, June 2022,
           <https://www.rfc-editor.org/info/rfc9110>.

[RFC9286]  Austein, R., Huston, G., Kent, S., and M. Lepinski,
           "Manifests for the Resource Public Key Infrastructure
           (RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022,
           <https://www.rfc-editor.org/info/rfc9286>.

11.2. Informative References 📚

[GEOFEED-FINDER] "geofeed-finder", commit 5f557a4, March 2024, <https://github.com/massimocandela/geofeed-finder>.
[INET6NUM] RIPE NCC, "RIPE Database Documentation: Description of the INET6NUM Object", <https://apps.db.ripe.net/docs/RPSL-Object-Types/Descriptions-of-Primary-Objects/#description-of-the-inet6num-object>.
[INETNUM] RIPE NCC, "RIPE Database Documentation: Description of the INETNUM Object", <https://apps.db.ripe.net/docs/RPSL-Object-Types/Descriptions-of-Primary-Objects/#description-of-the-inetnum-object>.
[RDAP-GEOFEED] Singh, J. and T. Harrison, "An RDAP Extension for Geofeed Data", Work in Progress, Internet-Draft, draft-ietf-regext-rdap-geofeed-07, 6 August 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-geofeed-07>.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, <https://www.rfc-editor.org/info/rfc959>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI 10.17487/RFC3912, September 2004, <https://www.rfc-editor.org/info/rfc3912>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC5485] Housley, R., "Digital Signatures on Internet-Draft Documents", RFC 5485, DOI 10.17487/RFC5485, March 2009, <https://www.rfc-editor.org/info/rfc5485>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, <https://www.rfc-editor.org/info/rfc6269>.
[RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, "Inventory and Analysis of WHOIS Registration Objects", RFC 7485, DOI 10.17487/RFC7485, March 2015, <https://www.rfc-editor.org/info/rfc7485>.
[RFC7909] Kisteleki, R. and B. Haberman, "Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures", RFC 7909, DOI 10.17487/RFC7909, June 2016, <https://www.rfc-editor.org/info/rfc7909>.
[RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access Protocol (RDAP) Query Format", STD 95, RFC 9082, DOI 10.17487/RFC9082, June 2021, <https://www.rfc-editor.org/info/rfc9082>.
[RFC9092] Bush, R., Candela, M., Kumari, W., and R. Housley, "Finding and Using Geofeed Data", RFC 9092, DOI 10.17487/RFC9092, July 2021, <https://www.rfc-editor.org/info/rfc9092>.
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, <https://www.rfc-editor.org/info/rfc9111>.
[RIPE-DB] RIPE NCC, "RIPE Database Documentation", September 2023, <https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation>.
[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>.
[rpki-client] Snijders, J., "Example on how to use rpki-client to authenticate a signed Geofeed", September 2023, <https://sobornost.net/~job/using_geofeed_authenticators.txt>.

Appendix A. Example ✨

This appendix is a worked example, and it's giving full RPKI vibes 🔐. It includes a trust anchor, a Certificate Revocation List (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 geofeed, and a detached signature.

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 👑.

The CRL is issued by the trust anchor. 🧾

The CA certificate is issued by the trust anchor. This certificate grants authority over one IPv4 address block (192.0.2.0/24) and two AS numbers (64496 and 64497) 🌸.

The CRL is issued by the CA. 💅

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 AS numbers is not needed for geofeed data signatures, so no AS numbers are included in the end entity certificate 🫶.

The end entity certificate is up next, and it's giving main character 🎀✨. I'll show you the full thing, but I'm skipping the other two certificates bc they're just for brevity 🙈

     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 F0
    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 23/09/2023 15:55:38 GMT
   120   13:    UTCTime 19/07/2024 15:55:38 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
           :   97 1B 76 E4 55 1E 7B 4F AE 0A 27 53 1F EE 29 EC
           :   0B 77 BB 69 DC 80 77 06 4E C6 A0 DD 47 28 3E 37
           :   04 FC 8D 49 81 02 51 BB D4 E2 33 88 8D 07 50 BB
           :   2D B7 5D D7 7D 60 31 D9 62 2F 91 90 DC FE 10 7C
           :   A9 DF 92 E3 D1 E9 2D 55 F2 CB AA E9 94 F5 29 04
           :   72 2C 9C 7E 10 F8 03 37 6A DB FE 28 E2 D1 33 8A
           :   E9 12 8F 34 17 46 95 75 4B 8E D8 78 C7 FB AE D4
           :   EE 15 E7 81 8B 12 10 C0 3D 00 BC 21 49 B9 8A 7B
           :   4B FC 7C 75 33 5C 76 A6 D3 7F FA 3E 47 0F 75 D4
           :   5D DD F1 D7 7C A2 B3 AB BB E7 C9 DB 03 B3 43 E3
           :   42 4D 84 61 B9 24 D1 90 80 37 21 2F 82 10 CC 88
           :   72 94 C3 42 F9 B2 94 8B 2C 8C 1F 3D CC AA 85 40
           :   92 52 01 F3 A2 16 51 CB FB D8 C7 A4 AB E8 B8 E9
           :   3F F0 DD 19 DA 1A 7E 31 ED 10 09 72 D5 49 5B 0D
           :   DE E5 83 2B 16 74 1C BA E6 86 3A CD 10 72 8C 56
           :   EC 18 B8 5B B1 20 F1 F2 B5 7D DF DF E9 F8 D9 F7
           :   }

Now, to make the signature results reproducible 🔑✨, the end entity private key is included too. Again, the other two private keys are left out for brevity 💅

Next up 🦋: we sign the string "192.0.2.0/24,US,WA,Seattle," (ending with a CR and LF) and get the detached CMS signature 🧚💜

Acknowledgments 🫶

Okay bestie, the people who made this happen deserve a shoutout! 📣 Huge thanks to Rob Austein for the CMS and detached signature clue 🔐, and to George Michaelson for the first and substantial external review 💖. Erik Kline gets a special mention too 🥹 because he was too shy to agree to coauthorship, but he still helped out, and that's so iconic. 🌸

We also have to hype the early implementors 🔥: Menno Schepers, Flavio Luciani, Eric Dugas, and Kevin Pack. They were building with this before it was a whole thing. Literally main character energy 👑.

Thanks as well to the geolocation providers who are already consuming geofeeds with this described solution ✨: Jonathan Kosgei (ipdata.co), Ben Dowling (ipinfo.io), and Pol Nisenblat (bigdatacloud.com). 🌍

For an amazing number of helpful reviews 💅, we thank Job Snijders, who also found an ASN.1 'inherit' issue 🙈, along with Adrian Farrel, Antonio Prado, Francesca Palombini, Jean-Michel Combes (INTDIR), John Scudder, Kyle Rose (SECDIR), Martin Duke, Mohamed Boucadair, Murray Kucherawy, Paul Kyzivat (GENART), Rob Wilton, Roman Danyliw, and Ties de Kock. You all are absolutely iconic 🌈✨

Authors' Addresses 💌

Randy Bush IIJ Research & Arrcus 5147 Crystal Springs Bainbridge Island, Washington 98110 United States of America Email: randy@psg.com

Massimo Candela NTT Veemweg 23 3771 MT Barneveld Netherlands Email: massimo@ntt.net

Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America Email: warren@kumari.net

Russ Housley Vigil Security, LLC 516 Dranesville Road Herndon, VA 20170 United States of America Email: housley@vigilsec.com

The end, bestie! 🦋 Every author's contact info is right there, so you can slide into their inbox if you have questions 💜

📦 where this page comes from

ietf: rfc9632 2024-08
💖 girlified by claude-haiku-5-5 on 2026-10-19: a language model's rewrite of the original, under its terms