rfc9632.original   rfc9632.txt 
Network Working Group R. Bush Internet Engineering Task Force (IETF) R. Bush
Internet-Draft IIJ Research & Arrcus Request for Comments: 9632 IIJ Research & Arrcus
Obsoletes: 9092 (if approved) M. Candela Obsoletes: 9092 M. Candela
Intended status: Standards Track NTT Category: Standards Track NTT
Expires: 25 August 2024 W. Kumari ISSN: 2070-1721 W. Kumari
Google Google
R. Housley R. Housley
Vigil Security Vigil Security
22 February 2024 July 2024
Finding and Using Geofeed Data Finding and Using Geofeed Data
draft-ietf-opsawg-9092-update-11
Abstract Abstract
This document specifies how to augment the Routing Policy This document specifies how to augment the Routing Policy
Specification Language inetnum: class to refer specifically to Specification Language (RPSL) inetnum: class to refer specifically to
geofeed comma-separated values (CSV) data files and describes an geofeed comma-separated values (CSV) data files and describes an
optional scheme that uses the Resource Public Key Infrastructure to optional scheme that uses the Resource Public Key Infrastructure
authenticate the geofeed data files. This document obsoletes RFC (RPKI) to authenticate the geofeed data files. This document
9092. obsoletes RFC 9092.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 25 August 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9632.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Please review these documents carefully, as they describe your rights carefully, as they describe your rights and restrictions with respect
and restrictions with respect to this document. Code Components to this document. Code Components extracted from this document must
extracted from this document must include Revised BSD License text as include Revised BSD License text as described in Section 4.e of the
described in Section 4.e of the Trust Legal Provisions and are Trust Legal Provisions and are provided without warranty as described
provided without warranty as described in the Revised BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
2. Geofeed Files . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Geofeed Files
3. inetnum: Class . . . . . . . . . . . . . . . . . . . . . . . 4 3. inetnum: Class
4. Fetching Geofeed Data . . . . . . . . . . . . . . . . . . . . 5 4. Fetching Geofeed Data
5. Authenticating Geofeed Data (Optional) . . . . . . . . . . . 7 5. Authenticating Geofeed Data (Optional)
6. Operational Considerations . . . . . . . . . . . . . . . . . 10 6. Operational Considerations
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 7. Privacy Considerations
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 8. Implementation Status
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 11. References
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References
12.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References
12.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Example
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 17 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses
1. Introduction 1. Introduction
Providers of Internet content and other services may wish to Providers of Internet content and other services may wish to
customize those services based on the geographic location of the user customize those services based on the geographic location of the user
of the service. This is often done using the source IP address used of the service. This is often done using the source IP address used
to contact the service, which may not point to a user, see [RFC6269], to contact the service, which may not point to a user; see Section 14
Section 14 in particular. Also, infrastructure and other services of [RFC6269] in particular. Also, administrators of infrastructure
might wish to publish the locale of their services. [RFC8805] and other services might wish to publish the locale of said
defines geofeed, a syntax to associate geographic locales with IP infrastructure or services. infrastructure and other services might
addresses, but it does not specify how to find the relevant geofeed wish to publish the locale of their services. [RFC8805] defines
data given an IP address. geofeed, a syntax to associate geographic locales with IP addresses,
but it does not specify how to find the relevant geofeed data given
an IP address.
This document specifies how to augment the Routing Policy This document specifies how to augment the Routing Policy
Specification Language (RPSL) [RFC2725] inetnum: class to refer Specification Language (RPSL) [RFC2725] inetnum: class to refer
specifically to geofeed data files and how to prudently use them. In specifically to geofeed data files and how to prudently use them. In
all places inetnum: is used, inet6num: should also be assumed all places inetnum: is used, inet6num: should also be assumed
[RFC4012]. [RFC4012].
The reader may find [INETNUM] and [INET6NUM] informative, and The reader may find [INETNUM] and [INET6NUM] informative, and
certainly more verbose, descriptions of the inetnum: database certainly more verbose, descriptions of the inetnum: database
classes. classes.
An optional utterly awesome but slightly complex means for An optional utterly awesome but slightly complex means for
authenticating geofeed data is also defined in Section 5. authenticating geofeed data is also defined in Section 5.
This document obsoletes [RFC9092]. Changes from [RFC9092] include This document obsoletes [RFC9092]. Changes from [RFC9092] include
the following: the following:
* RIPE has implemented the geofeed: attribute. * RIPE has implemented the geofeed: attribute.
* Allow, but discourage, an inetnum: to have both a geofeed remarks:
attribute and a geofeed: attribute. * This document allows, but discourages, an inetnum: to have both a
* Rewrite Authentication Section 5 to be more formal. geofeed remarks: attribute and a geofeed: attribute.
* Geofeed file only UTF-8 CSV.
* Stress that authenticating geofeed data is optional. * The Authentication section (Section 5) has been rewritten to be
more formal.
* Geofeed files are only UTF-8 CSV.
* This document stresses that authenticating geofeed data is
optional.
* IP Address Delegation extensions must not use "inherit". * IP Address Delegation extensions must not use "inherit".
* If geofeed data are present, ignore geographic location hints in
other data. * If geofeed data are present, geographic location hints in other
data should be ignored.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Geofeed Files 2. Geofeed Files
Geofeed files are described in [RFC8805]. They provide a facility Geofeed files are described in [RFC8805]. They provide a facility
for an IP address resource "owner" to associate those IP addresses to for an IP address resource "owner" to associate those IP addresses to
geographic locales. geographic locales.
Per [RFC8805], geofeed files consist of CSVs (Comma Separated Values) Per [RFC8805], geofeed files consist of comma-separated values (CSV)
in UTF-8 text format; not HTML, richtext, or other formats. in UTF-8 text format, not HTML, richtext, or other formats.
Content providers and other parties who wish to locate an IP address Content providers and other parties who wish to locate an IP address
to a geographic locale need to find the relevant geofeed data. In to a geographic locale need to find the relevant geofeed data. In
Section 3, this document specifies how to find the relevant geofeed Section 3, this document specifies how to find the relevant geofeed
[RFC8805] file given an IP address. [RFC8805] file given an IP address.
Geofeed data for large providers with significant horizontal scale Geofeed data for large providers with significant horizontal scale
and high granularity can be quite large. The size of a file can be and high granularity can be quite large. The size of a file can be
even larger if an unsigned geofeed file combines data for many even larger if an unsigned geofeed file combines data for many
prefixes, if dual IPv4/IPv6 spaces are represented, etc. prefixes, if dual IPv4/IPv6 spaces are represented, etc.
skipping to change at page 4, line 12 skipping to change at line 160
This document also suggests an optional signature to strongly This document also suggests an optional signature to strongly
authenticate the data in the geofeed files. authenticate the data in the geofeed files.
3. inetnum: Class 3. inetnum: Class
The original RPSL specifications starting with [RIPE81], [RIPE181], The original RPSL specifications starting with [RIPE81], [RIPE181],
and a trail of subsequent documents were written by the RIPE and a trail of subsequent documents were written by the RIPE
community. The IETF standardized RPSL in [RFC2622] and [RFC4012]. community. The IETF standardized RPSL in [RFC2622] and [RFC4012].
Since then, it has been modified and extensively enhanced in the Since then, it has been modified and extensively enhanced in the
Regional Internet Registry (RIR) community, mostly by RIPE [RIPE-DB]. Regional Internet Registry (RIR) community, mostly by RIPE [RIPE-DB].
At the time of publishing this document, change control of RPSL At the time of publishing this document, change control of the RPSL
effectively lies in the operator community. effectively lies in the operator community.
The RPSL, and [RFC2725] and [RFC4012] used by the Regional Internet The inetnum: database class is specified by the RPSL, as well as
Registries (RIRs), specify the inetnum: database class. Each of Routing Policy System Security [RFC2725] and RPSLng [RFC4012], which
these objects describes an IP address range and its attributes. The are used by the Regional Internet Registries (RIRs). Each of these
objects describes an IP address range and its attributes. The
inetnum: objects form a hierarchy ordered on the address space. inetnum: objects form a hierarchy ordered on the address space.
Ideally, RPSL would be augmented to define a new RPSL geofeed: Ideally, the RPSL would be augmented to define a new RPSL geofeed:
attribute in the inetnum: class. Absent implementation of the attribute in the inetnum: class. Absent implementation of the
geofeed: attribute in a particular RIR database, this document geofeed: attribute in a particular RIR database, this document
defines the syntax of a Geofeed remarks: attribute, which contains an defines the syntax of a Geofeed remarks: attribute, which contains an
HTTPS URL of a geofeed file. The format of the inetnum: geofeed HTTPS URL of a geofeed file. The format of the inetnum: geofeed
remarks: attribute MUST be as in this example, "remarks: Geofeed ", remarks: attribute MUST be as in this example, "remarks: Geofeed ",
where the token "Geofeed " MUST be case sensitive, followed by a URL 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] that will vary, but it MUST refer only to a single geofeed [RFC8805]
file. file.
inetnum: 192.0.2.0/24 # example inetnum: 192.0.2.0/24 # example
skipping to change at page 4, line 43 skipping to change at line 192
While we leave global agreement of RPSL modification to the relevant While we leave global agreement of RPSL modification to the relevant
parties, we specify that a proper geofeed: attribute in the inetnum: parties, we specify that a proper geofeed: attribute in the inetnum:
class MUST be "geofeed:" and MUST be followed by a single URL that 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. will vary, but it MUST refer only to a single geofeed [RFC8805] file.
inetnum: 192.0.2.0/24 # example inetnum: 192.0.2.0/24 # example
geofeed: https://example.com/geofeed geofeed: https://example.com/geofeed
The URL uses HTTPS, so the WebPKI provides authentication, integrity, The URL uses HTTPS, so the WebPKI provides authentication, integrity,
and confidentiality for the fetched geofeed file. However, the and confidentiality for the fetched geofeed file. However, the
WebPKI can not provide authentication of IP address space assignment. WebPKI cannot provide authentication of IP address space assignment.
In contrast, the RPKI (see [RFC6481]) can be used to authenticate IP In contrast, the RPKI (see [RFC6481]) can be used to authenticate IP
space assignment; see optional authentication in Section 5. space assignment; see optional authentication in Section 5.
Until all producers of inetnum: objects, i.e., the RIRs, state that Until all producers of inetnum: objects, i.e., the RIRs, state that
they have migrated to supporting a geofeed: attribute, consumers they have migrated to supporting a geofeed: attribute, consumers
looking at inetnum: objects to find geofeed URLs MUST be able to looking at inetnum: objects to find geofeed URLs MUST be able to
consume both the remarks: and geofeed: forms. consume both the remarks: and geofeed: forms.
The migration not only implies that the RIRs support the geofeed: The migration not only implies that the RIRs support the geofeed:
attribute, but that all registrants have migrated any inetnum: attribute, but that all registrants have migrated any inetnum:
objects from remarks: to geofeed: attributes. objects from remarks: to geofeed: attributes.
Any particular inetnum: object SHOULD have, at most, one geofeed Any particular inetnum: object SHOULD have, at most, one geofeed
reference, whether a remarks: or a proper geofeed: attribute when it reference, whether a remarks: or a proper geofeed: attribute when it
is implemented. As the remarks: form can not be formally checked by is implemented. As the remarks: form cannot be formally checked by
the RIR, this can not be formally enforced. A geofeed: attribute is the RIR, this cannot be formally enforced. A geofeed: attribute is
preferred, of course, if the RIR supports it. If there is more than preferred, of course, if the RIR supports it. If there is more than
one type of attribute in the intetnum: object, the geofeed: attribute one type of attribute in the intetnum: object, the geofeed: attribute
MUST be used. MUST be used.
For inetnum:s covering the same address range, a signed geofeed file For inetnum: objects covering the same address range, a signed
MUST be preferred over an unsigned file. If none are signed, or more geofeed file MUST be preferred over an unsigned file. If none are
than one is signed, the (signed) inetnum: with the most recent last- signed, or more than one is signed, the (signed) inetnum: with the
modified: attribute MUST be preferred. most recent last-modified: attribute MUST be preferred.
If a geofeed file describes multiple disjoint ranges of IP address If a geofeed file describes multiple disjoint ranges of IP address
space, there are likely to be geofeed references from multiple space, there are likely to be geofeed references from multiple
inetnum: objects. Files with geofeed references from multiple inetnum: objects. Files with geofeed references from multiple
inetnum: objects are not compatible with the signing procedure in inetnum: objects are not compatible with the signing procedure in
Section 5. Section 5.
An unsigned, and only an unsigned, geofeed file MAY be referenced by An unsigned, and only an unsigned, geofeed file MAY be referenced by
multiple inetnum:s and MAY contain prefixes from more than one multiple inetnum: objects and MAY contain prefixes from more than one
registry. registry.
When fetching, the most specific inetnum: object with a geofeed When fetching, the most specific inetnum: object with a geofeed
reference MUST be used. reference MUST be used.
It is significant that geofeed data may have finer granularity than It is significant that geofeed data may have finer granularity than
the inetnum: that refers to them. For example, an INETNUM object for the inetnum: that refers to them. For example, an INETNUM object for
an address range P could refer to a geofeed file in which P has been an address range P could refer to a geofeed file in which P has been
subdivided into one or more longer prefixes. subdivided into one or more longer prefixes.
4. Fetching Geofeed Data 4. Fetching Geofeed Data
This document is to provides a guideline for how interested parties This document provides a guideline for how interested parties should
should fetch and read geofeed files. fetch and read geofeed files.
Historically, before [RFC9092], this was done in varied ways, at the Historically, before [RFC9092], this was done in varied ways, at the
discretion of the implementer, often without consistent discretion of the implementor, often without consistent
authentication, where data were mostly imported from email without authentication, where data were mostly imported from email without
formal authorisation or validation. formal authorization or validation.
To minimize the load on RIRs' WHOIS [RFC3912] services, the RIR's FTP To minimize the load on RIRs' WHOIS [RFC3912] services, the RIR's FTP
[RFC0959] services SHOULD be used for large-scale access to gather [RFC0959] services SHOULD be used for large-scale access to gather
inetnum:s with geofeed references. This uses efficient bulk access inetnum: objects with geofeed references. This uses efficient bulk
instead of fetching via brute-force search through the IP space. access instead of fetching via brute-force search through the IP
space.
When reading data from an unsigned geofeed file, one MUST ignore data When reading data from an unsigned geofeed file, one MUST ignore data
outside the referring inetnum: object's address range. This is to outside the referring inetnum: object's address range. This is to
avoid importing data about ranges not under the control of the avoid importing data about ranges not under the control of the
operator. Note that signed files MUST only contain prefixes within operator. Note that signed files MUST only contain prefixes within
the referring inetnum:'s range as mandated in Section 5. the referring inetnum:'s range as mandated in Section 5.
If geofeed files are fetched, other location information from the If geofeed files are fetched, other location information from the
inetnum: MUST be ignored. inetnum: MUST be ignored.
Given an address range of interest, the most specific inetnum: object Given an address range of interest, the most specific inetnum: object
with a geofeed reference MUST be used to fetch the geofeed file. For with a geofeed reference MUST be used to fetch the geofeed file. For
example, if the fetching party finds the following inetnum: objects: example, if the fetching party finds the following inetnum: objects:
inetnum: 192.0.0.0/22 # example inetnum: 192.0.0.0/22 # example
remarks: Geofeed https://example.com/geofeed_1 remarks: Geofeed https://example.com/geofeed_1
inetnum: 192.0.2.0/24 # example inetnum: 192.0.2.0/24 # example
remarks: Geofeed https://example.com/geofeed_2 remarks: Geofeed https://example.com/geofeed_2
An application looking for geofeed data for 192.0.2.0/29, MUST ignore An application looking for geofeed data for 192.0.2.0/29 MUST ignore
data in geofeed_1 because 192.0.2.0/29 is within the more specific data in geofeed_1 because 192.0.2.0/29 is within the more specific
192.0.2.0/24 inetnum: covering that address range and that inetnum: 192.0.2.0/24 inetnum: covering that address range and that inetnum:
does have a geofeed reference. does have a geofeed reference.
Hints in inetnum:s such as country:, geoloc:, etc. tend to be Hints in inetnum: objects such as country:, geoloc:, etc. tend to be
administrative, and not deployment specific. Consider large, administrative, and not deployment specific. Consider large,
possibly global, providers with headquarters very far from most of possibly global, providers with headquarters very far from most of
their deployments. Therefore, if geofeed data are specified, either their deployments. Therefore, if geofeed data are specified, either
as a geofeed: attribute or in a geofeed remarks: attribute, other as a geofeed: attribute or in a geofeed remarks: attribute, other
geographic hints such as country:, geoloc:, DNS geoloc RRsets, etc., geographic hints such as country:, geoloc:, DNS geoloc RRsets, etc.,
for that address range MUST be ignored. for that address range MUST be ignored.
There is open-source code to traverse the RPSL data across all of the There is open-source code to traverse the RPSL data across all of the
RIRs, collect all geofeed references, and process them RIRs, collect all geofeed references, and process them
[GEOFEED-FINDER]. It implements the steps above and of all the [GEOFEED-FINDER]. It implements the steps above and of all the
Operational Considerations described in Section 6, including caching. Operational Considerations described in Section 6, including caching.
It produces a single geofeed file, merging all the geofeed files It produces a single geofeed file, merging all the geofeed files
found. This open-source code can be run daily by a cronjob, and the found. This open-source code can be run daily by a cron job, and the
output file can be directly used. output file can be directly used.
RIRs are converging on RDAP support which includes geofeed data, see RIRs are converging on Registration Data Access Protocol (RDAP)
[I-D.ietf-regext-rdap-geofeed]. This SHOULD NOT be used for bulk support, which includes geofeed data; see [RDAP-GEOFEED]. This
retrieval of geofeed data. SHOULD NOT be used for bulk retrieval of geofeed data.
5. Authenticating Geofeed Data (Optional) 5. Authenticating Geofeed Data (Optional)
The question arises whether a particular geofeed [RFC8805] data set The question arises whether a particular geofeed [RFC8805] data set
is valid, i.e., is authorized by the "owner" of the IP address space 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 and is authoritative in some sense. The inetnum: that points to the
geofeed [RFC8805] file provides some assurance. Unfortunately, the geofeed [RFC8805] file provides some assurance. Unfortunately, the
RPSL in some repositories is weakly authenticated at best. An RPSL in some repositories is weakly authenticated at best. An
approach where RPSL was signed per [RFC7909] would be good, except it approach where the RPSL was signed per [RFC7909] would be good,
would have to be deployed by all RPSL registries, and there is a fair except it would have to be deployed by all RPSL registries, and there
number of them. is a fair number of them.
The remainder of this section specifies an optional authenticator for The remainder of this section specifies an optional authenticator for
the geofeed data set that follows the Signed Object Template for the the geofeed data set that follows "Signed Object Template for the
Resource Public Key Infrastructure (RPKI) [RFC6488]. Resource Public Key Infrastructure (RPKI)" [RFC6488].
A single optional authenticator MAY be appended to a geofeed A single optional authenticator MAY be appended to a geofeed
[RFC8805] file. It is a digest of the main body of the file signed [RFC8805] 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 by the private key of the relevant RPKI certificate for a covering
address range. The following format bundles the relevant RPKI address range. The following format bundles the relevant RPKI
certificate with a signature over the geofeed text. certificate with a signature over the geofeed text.
The canonicalization procedure converts the data from their internal The canonicalization procedure converts the data from their internal
character representation to the UTF-8 [RFC3629] character encoding, character representation to the UTF-8 [RFC3629] character encoding,
and the <CRLF> sequence MUST be used to denote the end of each line 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. of text. A blank line is represented solely by the <CRLF> sequence.
For robustness, any non-printable characters MUST NOT be changed by For robustness, any non-printable characters MUST NOT be changed by
canonicalization. Trailing blank lines MUST NOT appear at the end of canonicalization. Trailing blank lines MUST NOT appear at the end of
the file. That is, the file must not end with multiple consecutive the file. That is, the file must not end with multiple consecutive
<CRLF> sequences. Any end-of-file marker used by an operating system <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 is not considered to be part of the file content. When present, such
end-of-file markers MUST NOT be covered by the digital signature. end-of-file markers MUST NOT be covered by the digital signature.
If the authenticator is not in the canonical form described above, If the authenticator is not in the canonical form described above,
then, the authenticator is invalid. then the authenticator is invalid.
Borrowing detached signatures from [RFC5485], after file Borrowing detached signatures from [RFC5485], after file
canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652] is canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652] is
used to create a detached DER-encoded signature that is then Base64 used to create a detached DER-encoded signature that is then Base64
encoded with padding (as defined in Section 4 of [RFC4648]) and line encoded with padding (as defined in Section 4 of [RFC4648]) and line
wrapped to 72 or fewer characters. The same digest algorithm MUST be wrapped to 72 or fewer characters. The same digest algorithm MUST be
used for calculating the message digest of the content being signed, used for calculating the message digest of the content being signed,
which is the geofeed file, and for calculating the message digest on which is the geofeed file, and for calculating the message digest on
the SignerInfo SignedAttributes [RFC8933]. The message digest the SignerInfo SignedAttributes [RFC8933]. The message digest
algorithm identifier MUST appear in both the CMS SignedData algorithm identifier MUST appear in both the CMS SignedData
skipping to change at page 8, line 19 skipping to change at line 359
Identifier Delegation certificate extension [RFC3779]. If it is Identifier Delegation certificate extension [RFC3779]. If it is
present, the authenticator is invalid. present, the authenticator is invalid.
As with many other RPKI signed objects, the IP Address Delegation As with many other RPKI signed objects, the IP Address Delegation
certificate extension MUST NOT use the "inherit" capability defined certificate extension MUST NOT use the "inherit" capability defined
in Section 2.2.3.5 of [RFC3779]. If "inherit" is used, the in Section 2.2.3.5 of [RFC3779]. If "inherit" is used, the
authenticator is invalid. authenticator is invalid.
An IP Address Delegation extension using "inherit" would complicate An IP Address Delegation extension using "inherit" would complicate
processing. The implementation would have to build the certification processing. The implementation would have to build the certification
path from the end-entity to the trust anchor, then validate the path path from the end entity to the trust anchor, then validate the path
from the trust anchor to the end-entity, and then the parameter would from the trust anchor to the end entity, and then the parameter would
have to be remembered when the validated public key was used to have to be remembered when the validated public key was used to
validate a signature on a CMS object. Having to remember things from validate a signature on a CMS object. Having to remember things from
certification path validation for use with CMS object processing certification path validation for use with CMS object processing
would be quite complex and error prone. And, the certificates do not would be quite complex and error-prone. Additionally, the
get that much bigger by repeating the information. certificates do not get that much bigger by repeating the
information.
An address range A "covers" address range B if the range of B is 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 identical to or a subset of A. "Address range" is used here because
inetnum: objects and RPKI certificates need not align on Classless inetnum: objects and RPKI certificates need not align on Classless
Inter-Domain Routing (CIDR) [RFC4632] prefix boundaries, while those Inter-Domain Routing (CIDR) [RFC4632] prefix boundaries, while those
of the lines in a geofeed file do align. of the lines in a geofeed file do align.
The Certificate Authority (CA) SHOULD sign only one geofeed file with The Certification Authority (CA) SHOULD sign only one geofeed file
each generated private key and SHOULD generate a new key pair for with each generated private key and SHOULD generate a new key pair
each new version of a perticular geofeed file. The CA MUST generate for each new version of a particular geofeed file. The CA MUST
a new End Entity (EE) certificate for each signing of a particular generate a new end entity (EE) certificate for each signing of a
geofeed file. An associated EE certificate used in this fashion is particular geofeed file. An associated EE certificate used in this
termed a "one-time-use" EE certificate (see Section 3 of [RFC6487]). fashion is termed a "one-time-use" EE certificate (see Section 3 of
[RFC6487]).
Identifying the private key associated with the certificate and Identifying the private key associated with the certificate and
getting the department that controls the private key (which might be getting the department that controls the private key (which might be
stored in a Hardware Security Module (HSM)) to generate the CMS stored in a Hardware Security Module (HSM)) to generate the CMS
signature is left as an exercise for the implementor. On the other signature is left as an exercise for the implementor. On the other
hand, verifying the signature has no similar complexity; the hand, verifying the signature has no similar complexity; the
certificate, which is validated in the public RPKI, contains the certificate, which is validated in the public RPKI, contains the
needed public key. The RPKI trust anchors for the RIRs are expected needed public key. The RPKI trust anchors for the RIRs are expected
to already be available to the party performing signature validation. to already be available to the party performing signature validation.
Validation of the CMS signature over the geofeed file involves: Validation of the CMS signature over the geofeed file involves:
skipping to change at page 9, line 32 skipping to change at line 419
certification path validation is unsuccessful, then validation certification path validation is unsuccessful, then validation
MUST fail. MUST fail.
4. Validating the CMS SignedData as specified in [RFC5652] using the 4. Validating the CMS SignedData as specified in [RFC5652] using the
public key from the validated signer's certificate. If the public key from the validated signer's certificate. If the
signature validation is unsuccessful, then validation MUST fail. signature validation is unsuccessful, then validation MUST fail.
5. Confirming that the eContentType object identifier (OID) is id- 5. Confirming that the eContentType object identifier (OID) is id-
ct-geofeedCSVwithCRLF (1.2.840.113549.1.9.16.1.47). This OID ct-geofeedCSVwithCRLF (1.2.840.113549.1.9.16.1.47). This OID
MUST appear within both the eContentType in the encapContentInfo MUST appear within both the eContentType in the encapContentInfo
object and the ContentType signed attribute in the signerInfo object and within the ContentType signed attribute in the
object (see [RFC6488]). signerInfo object (see [RFC6488]).
6. Verifying that the IP Address Delegation certificate extension 6. Verifying that the IP Address Delegation certificate extension
[RFC3779] covers all of the address ranges of the geofeed file. [RFC3779] covers all of the address ranges of the geofeed file.
If all of the address ranges are not covered, then validation If all of the address ranges are not covered, then validation
MUST fail. MUST fail.
All of the above steps MUST be successful to consider the geofeed All of the above steps MUST be successful to consider the geofeed
file signature as valid. file signature as valid.
The authenticator MUST be hidden as a series of "#" comments at the The authenticator MUST be hidden as a series of "#" comments at the
skipping to change at page 11, line 6 skipping to change at line 484
If the geofeed file is signed, and the signer's certificate changes, If the geofeed file is signed, and the signer's certificate changes,
the signature in the geofeed file MUST be updated. the signature in the geofeed file MUST be updated.
It is good key hygiene to use a given key for only one purpose. To 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 dedicate a signing private key for signing a geofeed file, an RPKI
Certification Authority (CA) may issue a subordinate certificate Certification Authority (CA) may issue a subordinate certificate
exclusively for the purpose shown in Appendix A. exclusively for the purpose shown in Appendix A.
Harvesting and publishing aggregated geofeed data outside of the RPSL Harvesting and publishing aggregated geofeed data outside of the RPSL
model should be avoided as it can have the effect that more specifics model should be avoided as it could lead to detailed data of one
from one aggregatee could undesirably affect the less specifics of a aggregatee undesirably affecting the less detailed data of a
different aggregatee. Moreover, publishing aggregated geofeed data different aggregatee. Moreover, publishing aggregated geofeed data
prevents the reader of the data to perform the checks described in prevents the reader of the data from performing the checks described
Section 4 and Section 5. in Section 4 and Section 5.
At the time of publishing this document, geolocation providers have At the time of publishing this document, geolocation providers have
bulk WHOIS data access at all the RIRs. An anonymized version of bulk WHOIS data access at all the RIRs. An anonymized version of
such data is openly available for all RIRs except ARIN, which such data is openly available for all RIRs except ARIN, which
requires an authorization. However, for users without such requires an authorization. However, for users without such
authorization, the same result can be achieved with extra RDAP authorization, the same result can be achieved with extra RDAP
effort. There is open-source code to pass over such data across all effort. There is open-source code to pass over such data across all
RIRs, collect all geofeed references, and process them RIRs, collect all geofeed references, and process them
[GEOFEED-FINDER]. [GEOFEED-FINDER].
To prevent undue load on RPSL and geofeed servers, entity-fetching To prevent undue load on RPSL and geofeed servers, entity-fetching
geofeed data using these mechanisms MUST NOT do frequent real-time geofeed data using these mechanisms MUST NOT do frequent real-time
lookups. Section 3.4 of [RFC8805] suggests use of the HTTP Expires lookups. Section 3.4 of [RFC8805] suggests use of the HTTP Expires
header [RFC7234] to signal when geofeed data should be refetched. As header [RFC9111] to signal when geofeed data should be refetched. As
the data change very infrequently, in the absence of such an HTTP the data change very infrequently, in the absence of such an HTTP
Header signal, collectors SHOULD NOT fetch more frequently than Header signal, collectors SHOULD NOT fetch more frequently than
weekly. It would be polite not to fetch at magic times such as 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 midnight UTC, the first of the month, etc., because too many others
are likely to do the same. are likely to do the same.
7. Privacy Considerations 7. Privacy Considerations
[RFC8805] geofeed data may reveal the approximate location of an IP [RFC8805] geofeed data may reveal the approximate location of an IP
address, which might in turn reveal the approximate location of an address, which might in turn reveal the approximate location of an
skipping to change at page 11, line 51 skipping to change at line 529
Where [RFC8805] provided the ability to publish location data, this Where [RFC8805] provided the ability to publish location data, this
document makes bulk access to those data readily available. This is document makes bulk access to those data readily available. This is
a goal, not an accident. a goal, not an accident.
8. Implementation Status 8. Implementation Status
At the time of publishing this document, the geofeed: attribute in At the time of publishing this document, the geofeed: attribute in
inetnum objects has been implemented in the RIPE and APNIC databases. inetnum objects has been implemented in the RIPE and APNIC databases.
Registrants in databases which do not yet support the geofeed: Registrants in databases that do not yet support the geofeed:
attribute are using the remarks:, or equivalent, attribute. attribute are using the remarks: attribute, or equivalent.
At the time of publishing this document, the registry data published 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 by ARIN are not the same RPSL as that of the other registries (see
[RFC7485] for a survey of the WHOIS Tower of Babel); therefore, when [RFC7485] for a survey of the WHOIS Tower of Babel). Therefore, when
fetching from ARIN via FTP [RFC0959], WHOIS [RFC3912], the fetching from ARIN via FTP [RFC0959], WHOIS [RFC3912], the RDAP
Registration Data Access Protocol (RDAP) [RFC9082], etc., the [RFC9082], etc., the "NetRange" attribute/key must be treated as
"NetRange" attribute/key must be treated as "inetnum", and the "inetnum", and the "Comment" attribute must be treated as "remarks".
"Comment" attribute must be treated as "remarks".
[rpki-client] can be used to authenticate a signed geofeed file. [rpki-client] can be used to authenticate a signed geofeed file.
9. Security Considerations 9. Security Considerations
It is generally prudent for a consumer of geofeed data to also use It is generally prudent for a consumer of geofeed data to also use
other sources to cross-validate the data. All the security other sources to cross-validate the data. All the security
considerations of [RFC8805] apply here as well. considerations of [RFC8805] apply here as well.
The consumer of geofeed data SHOULD fetch and process the data The consumer of geofeed data SHOULD fetch and process the data
themselves. Importing datasets produced and/or processed by a third- themselves. Importing data sets produced and/or processed by a
party places significant trust in the third-party. third-party places significant trust in the third-party.
As mentioned in Section 5, some RPSL repositories have weak, if any, As mentioned in Section 5, some RPSL repositories have weak, if any,
authentication. This allows spoofing of inetnum: objects pointing to authentication. This allows spoofing of inetnum: objects pointing to
malicious geofeed files. Section 5 suggests an unfortunately complex malicious geofeed files. Section 5 suggests an unfortunately complex
method for stronger authentication based on the RPKI. method for stronger authentication based on the RPKI.
For example, if an inetnum: for a wide address range (e.g., a /16) 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 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 publish an unsigned equal or narrower (e.g., a /24) inetnum: in a
WHOIS registry that has weak authorization, abusing the rule that the WHOIS registry that has weak authorization, abusing the rule that the
skipping to change at page 12, line 48 skipping to change at line 574
The RPSL providers have had to throttle fetching from their servers The RPSL providers have had to throttle fetching from their servers
due to too-frequent queries. Usually, they throttle by the querying due to too-frequent queries. Usually, they throttle by the querying
IP address or block. Similar defenses will likely need to be IP address or block. Similar defenses will likely need to be
deployed by geofeed file servers. deployed by geofeed file servers.
10. IANA Considerations 10. IANA Considerations
In the SMI Security for S/MIME CMS Content Type In the SMI Security for S/MIME CMS Content Type
(1.2.840.113549.1.9.16.1) in the Structure of Management Information (1.2.840.113549.1.9.16.1) in the Structure of Management Information
(SMI) Numbers (MIB Module Registrations) registry group located at: (SMI) Numbers (MIB Module Registrations) registry group (located at
https://www.iana.org/assignments/smi-numbers/ there is an existing <https://www.iana.org/assignments/smi-numbers/>), the reference for
registration for: this registration has been updated to this document:
Decimal: 47
Description: id-ct-geofeedCSVwithCRLF
On publication of this document, that reference needs to be changed
to the new [ RFC-to-be ].
11. Acknowledgments +=========+==========================+===========+
| Decimal | Description | Reference |
+=========+==========================+===========+
| 47 | id-ct-geofeedCSVwithCRLF | RFC 9632 |
+---------+--------------------------+-----------+
Thanks to Rob Austein for CMS and detached signature clue, George Table 1: From SMI Security for S/MIME Module
Michaelson for the first and substantial external review, and Erik Identifier (1.2.840.113549.1.9.16.1)
Kline who was too shy to agree to coauthorship. Additionally, we
express our gratitude to early implementors, including Menno
Schepers; Flavio Luciani; Eric Dugas; and Kevin Pack. Also, thanks
to the following geolocation providers who are 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; 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.
12. References 11. References
12.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
"Routing Policy Specification Language (RPSL)", RFC 2622, "Routing Policy Specification Language (RPSL)", RFC 2622,
DOI 10.17487/RFC2622, June 1999, DOI 10.17487/RFC2622, June 1999,
skipping to change at page 15, line 20 skipping to change at line 674
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>. <https://www.rfc-editor.org/info/rfc9110>.
[RFC9286] Austein, R., Huston, G., Kent, S., and M. Lepinski, [RFC9286] Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure "Manifests for the Resource Public Key Infrastructure
(RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022, (RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022,
<https://www.rfc-editor.org/info/rfc9286>. <https://www.rfc-editor.org/info/rfc9286>.
12.2. Informative References 11.2. Informative References
[GEOFEED-FINDER] [GEOFEED-FINDER]
"geofeed-finder", commit 5f557a4, June 2021, "geofeed-finder", commit 5f557a4, March 2024,
<https://github.com/massimocandela/geofeed-finder>. <https://github.com/massimocandela/geofeed-finder>.
[I-D.ietf-regext-rdap-geofeed] [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 Singh, J. and T. Harrison, "An RDAP Extension for Geofeed
Data", Work in Progress, Internet-Draft, draft-ietf- Data", Work in Progress, Internet-Draft, draft-ietf-
regext-rdap-geofeed-01, 17 December 2023, regext-rdap-geofeed-06, 30 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-regext- <https://datatracker.ietf.org/doc/html/draft-ietf-regext-
rdap-geofeed-01>. rdap-geofeed-06>.
[INET6NUM] RIPE NCC, "Description of the INET6NUM Object", October
2019, <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>.
[INETNUM] RIPE NCC, "Description of the INETNUM Object", June 2020,
<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>.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
<https://www.rfc-editor.org/info/rfc959>. <https://www.rfc-editor.org/info/rfc959>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
DOI 10.17487/RFC3912, September 2004, DOI 10.17487/RFC3912, September 2004,
<https://www.rfc-editor.org/info/rfc3912>. <https://www.rfc-editor.org/info/rfc3912>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
skipping to change at page 16, line 19 skipping to change at line 719
[RFC5485] Housley, R., "Digital Signatures on Internet-Draft [RFC5485] Housley, R., "Digital Signatures on Internet-Draft
Documents", RFC 5485, DOI 10.17487/RFC5485, March 2009, Documents", RFC 5485, DOI 10.17487/RFC5485, March 2009,
<https://www.rfc-editor.org/info/rfc5485>. <https://www.rfc-editor.org/info/rfc5485>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
P. Roberts, "Issues with IP Address Sharing", RFC 6269, P. Roberts, "Issues with IP Address Sharing", RFC 6269,
DOI 10.17487/RFC6269, June 2011, DOI 10.17487/RFC6269, June 2011,
<https://www.rfc-editor.org/info/rfc6269>. <https://www.rfc-editor.org/info/rfc6269>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>.
[RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, [RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin,
"Inventory and Analysis of WHOIS Registration Objects", "Inventory and Analysis of WHOIS Registration Objects",
RFC 7485, DOI 10.17487/RFC7485, March 2015, RFC 7485, DOI 10.17487/RFC7485, March 2015,
<https://www.rfc-editor.org/info/rfc7485>. <https://www.rfc-editor.org/info/rfc7485>.
[RFC7909] Kisteleki, R. and B. Haberman, "Securing Routing Policy [RFC7909] Kisteleki, R. and B. Haberman, "Securing Routing Policy
Specification Language (RPSL) Objects with Resource Public Specification Language (RPSL) Objects with Resource Public
Key Infrastructure (RPKI) Signatures", RFC 7909, Key Infrastructure (RPKI) Signatures", RFC 7909,
DOI 10.17487/RFC7909, June 2016, DOI 10.17487/RFC7909, June 2016,
<https://www.rfc-editor.org/info/rfc7909>. <https://www.rfc-editor.org/info/rfc7909>.
skipping to change at page 16, line 45 skipping to change at line 740
[RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access [RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", STD 95, RFC 9082, Protocol (RDAP) Query Format", STD 95, RFC 9082,
DOI 10.17487/RFC9082, June 2021, DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/info/rfc9082>. <https://www.rfc-editor.org/info/rfc9082>.
[RFC9092] Bush, R., Candela, M., Kumari, W., and R. Housley, [RFC9092] Bush, R., Candela, M., Kumari, W., and R. Housley,
"Finding and Using Geofeed Data", RFC 9092, "Finding and Using Geofeed Data", RFC 9092,
DOI 10.17487/RFC9092, July 2021, DOI 10.17487/RFC9092, July 2021,
<https://www.rfc-editor.org/info/rfc9092>. <https://www.rfc-editor.org/info/rfc9092>.
[RIPE-DB] RIPE NCC, "RIPE Database Documentation", [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- <https://www.ripe.net/manage-ips-and-
asns/db/support/documentation/ripe-database- asns/db/support/documentation/ripe-database-
documentation>. documentation>.
[RIPE181] RIPE NCC, "Representation Of IP Routing Policies In A [RIPE181] RIPE NCC, "Representation Of IP Routing Policies In A
Routing Registry", October 1994, Routing Registry", October 1994,
<https://www.ripe.net/publications/docs/ripe-181>. <https://www.ripe.net/publications/docs/ripe-181>.
[RIPE81] RIPE NCC, "Representation Of IP Routing Policies In The [RIPE81] RIPE NCC, "Representation Of IP Routing Policies In The
RIPE Database", February 1993, RIPE Database", February 1993,
skipping to change at page 17, line 20 skipping to change at line 769
Snijders, J., "Example on how to use rpki-client to Snijders, J., "Example on how to use rpki-client to
authenticate a signed Geofeed", September 2023, authenticate a signed Geofeed", September 2023,
<https://sobornost.net/~job/ <https://sobornost.net/~job/
using_geofeed_authenticators.txt>. using_geofeed_authenticators.txt>.
Appendix A. Example Appendix A. Example
This appendix provides an example, including a trust anchor, a This appendix provides an example, including a trust anchor, a
Certificate Revocation List (CRL) signed by the trust anchor, a CA Certificate Revocation List (CRL) signed by the trust anchor, a CA
certificate subordinate to the trust anchor, a CRL signed by the CA, certificate subordinate to the trust anchor, a CRL signed by the CA,
an end-entity certificate subordinate to the CA for signing the an end entity certificate subordinate to the CA for signing the
geofeed, and a detached signature. geofeed, and a detached signature.
The trust anchor is represented by a self-signed certificate. As The trust anchor is represented by a self-signed certificate. As
usual in the RPKI, the trust anchor has authority over all IPv4 usual in the RPKI, the trust anchor has authority over all IPv4
address blocks, all IPv6 address blocks, and all Autonomous Systam address blocks, all IPv6 address blocks, and all Autonomous System
(AS) numbers. (AS) numbers.
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIEQTCCAymgAwIBAgIUEggycNoFVRjAuN/Fw7URu0DEZNAwDQYJKoZIhvcNAQEL MIIEQTCCAymgAwIBAgIUEggycNoFVRjAuN/Fw7URu0DEZNAwDQYJKoZIhvcNAQEL
BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yMzA5MTkyMDMzMzlaFw0zMzA5 BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yMzA5MTkyMDMzMzlaFw0zMzA5
MTYyMDMzMzlaMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEwggEiMA0GCSqGSIb3DQEB MTYyMDMzMzlaMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDQprR+g/i4JyObVURTp1JpGM23vGPyE5fDKFPqV7rw AQUAA4IBDwAwggEKAoIBAQDQprR+g/i4JyObVURTp1JpGM23vGPyE5fDKFPqV7rw
M1Amm7cnew66U02IzV0X5oiv5nSGfRX5UxsbR+vwPBMceQyDgS5lexFiv4fB/Vjf M1Amm7cnew66U02IzV0X5oiv5nSGfRX5UxsbR+vwPBMceQyDgS5lexFiv4fB/Vjf
DT2qX/UjsLL9QOeaSOh7ToJSLjmtpa0D9iz7ful3hdxRjpMMZiE/reX9/ymdpW/E DT2qX/UjsLL9QOeaSOh7ToJSLjmtpa0D9iz7ful3hdxRjpMMZiE/reX9/ymdpW/E
dg0F6+T9WGZE1miPeIjl5OZwnmLHCftkN/aaYk1iPNjNniHYIOjC1jSpABmoZyTj dg0F6+T9WGZE1miPeIjl5OZwnmLHCftkN/aaYk1iPNjNniHYIOjC1jSpABmoZyTj
skipping to change at page 18, line 5 skipping to change at line 803
YW1wbGUubmV0L3JlcG9zaXRvcnkvMCcGCCsGAQUFBwEHAQH/BBgwFjAJBAIAATAD YW1wbGUubmV0L3JlcG9zaXRvcnkvMCcGCCsGAQUFBwEHAQH/BBgwFjAJBAIAATAD
AwEAMAkEAgACMAMDAQAwIQYIKwYBBQUHAQgBAf8EEjAQoA4wDDAKAgEAAgUA//// AwEAMAkEAgACMAMDAQAwIQYIKwYBBQUHAQgBAf8EEjAQoA4wDDAKAgEAAgUA////
/zANBgkqhkiG9w0BAQsFAAOCAQEAa9eLY9QAmnlZOIyOzbpta5wqcOUQV/yR7o/0 /zANBgkqhkiG9w0BAQsFAAOCAQEAa9eLY9QAmnlZOIyOzbpta5wqcOUQV/yR7o/0
1zkEZaSavKBt19lMK6AXZurx1T5jyjIwG7bEtZZThjtH2m80V5kc2tsFjSq/yp7N 1zkEZaSavKBt19lMK6AXZurx1T5jyjIwG7bEtZZThjtH2m80V5kc2tsFjSq/yp7N
JBclMHVd3tXse9If3nXYF4bxRIcir1lXlAbYN+Eo1U3i5qJO+fxouzt7Merk2Dih JBclMHVd3tXse9If3nXYF4bxRIcir1lXlAbYN+Eo1U3i5qJO+fxouzt7Merk2Dih
nsenTeXKzN7tfmuCYZZHCC8viCoJWdH+o1uRM4TiQApZsUJ8sF4TABrrRJmA/Ed5 nsenTeXKzN7tfmuCYZZHCC8viCoJWdH+o1uRM4TiQApZsUJ8sF4TABrrRJmA/Ed5
v0CTBbgqTx7yg0+VarFLPdnjYgtpoCJqwE2C1UpX15rZSaLVuGXtbwXd/cHEg5vF v0CTBbgqTx7yg0+VarFLPdnjYgtpoCJqwE2C1UpX15rZSaLVuGXtbwXd/cHEg5vF
W6QTsMeMQFEUa6hkicDGtxLTUdhckBgmCGoF2nlZii5f1BTWAg== W6QTsMeMQFEUa6hkicDGtxLTUdhckBgmCGoF2nlZii5f1BTWAg==
-----END CERTIFICATE----- -----END CERTIFICATE-----
The CRL issued by the trust anchor. The CRL is issued by the trust anchor.
-----BEGIN X509 CRL----- -----BEGIN X509 CRL-----
MIIBjjB4AgEBMA0GCSqGSIb3DQEBCwUAMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEX MIIBjjB4AgEBMA0GCSqGSIb3DQEBCwUAMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEX
DTIzMDkyMzE1NTUzOFoXDTIzMTAyMzE1NTUzOFqgLzAtMB8GA1UdIwQYMBaAFMC9 DTIzMDkyMzE1NTUzOFoXDTIzMTAyMzE1NTUzOFqgLzAtMB8GA1UdIwQYMBaAFMC9
Ul2+0niyFuyzo0OV0gYLmQgyMAoGA1UdFAQDAgEEMA0GCSqGSIb3DQEBCwUAA4IB Ul2+0niyFuyzo0OV0gYLmQgyMAoGA1UdFAQDAgEEMA0GCSqGSIb3DQEBCwUAA4IB
AQCngOu+Nq3WC4y/pHtLoheAOtNg32WWsKPNiEyL+QalmOtURUsWMzOq41bmoPzQ AQCngOu+Nq3WC4y/pHtLoheAOtNg32WWsKPNiEyL+QalmOtURUsWMzOq41bmoPzQ
NDQoRmXe9mvohAVRe0CnM7A07HOtSfjw5aoouPXGTtfwEomHG2CYk+2U1bvxgZyA NDQoRmXe9mvohAVRe0CnM7A07HOtSfjw5aoouPXGTtfwEomHG2CYk+2U1bvxgZyA
E1c5TvyhkabFMO0+857wqxRP+ht9NV0lMX6kUFlEOCw3ELVd9oNNRBwKQtXj1huM E1c5TvyhkabFMO0+857wqxRP+ht9NV0lMX6kUFlEOCw3ELVd9oNNRBwKQtXj1huM
6Sf26va2a1tnC5zP01hN+EY3S9T5T1gcgPGBcqRWKoXJEbRzCrLsb/TMj5cMpIje 6Sf26va2a1tnC5zP01hN+EY3S9T5T1gcgPGBcqRWKoXJEbRzCrLsb/TMj5cMpIje
AHZoBojVAmvL1AIH/BnGAQj0+XqaJ0axHvlqJa8iX8QwKqhp+o6sv/atY2QDDRmE AHZoBojVAmvL1AIH/BnGAQj0+XqaJ0axHvlqJa8iX8QwKqhp+o6sv/atY2QDDRmE
skipping to change at page 19, line 5 skipping to change at line 851
b3NpdG9yeS8wHwYIKwYBBQUHAQcBAf8EEDAOMAwEAgABMAYDBADAAAIwIQYIKwYB b3NpdG9yeS8wHwYIKwYBBQUHAQcBAf8EEDAOMAwEAgABMAYDBADAAAIwIQYIKwYB
BQUHAQgBAf8EEjAQoA4wDDAKAgMA+/ACAwD78TANBgkqhkiG9w0BAQsFAAOCAQEA BQUHAQgBAf8EEjAQoA4wDDAKAgMA+/ACAwD78TANBgkqhkiG9w0BAQsFAAOCAQEA
arIrZWb22wFmP+hVjhdg3IsKHB6fQdMuUR0u2DyZTVvbL6C+HyGAH32pi5mR/QLX arIrZWb22wFmP+hVjhdg3IsKHB6fQdMuUR0u2DyZTVvbL6C+HyGAH32pi5mR/QLX
FAfdqALaB7r68tQTGLIW6bGljT+BqUPJmZcj56x3cBLJlltxwFatTloypjFt3cls FAfdqALaB7r68tQTGLIW6bGljT+BqUPJmZcj56x3cBLJlltxwFatTloypjFt3cls
xFCuuD9J2iBxc6odTKi6u0mhQjD+C9m4xkbe8XXWWx85IHm1s6rYbpGgiMWxBC80 xFCuuD9J2iBxc6odTKi6u0mhQjD+C9m4xkbe8XXWWx85IHm1s6rYbpGgiMWxBC80
qqAzmBHGROWKUEvh00EYIYdiAvyFcrj7QtDiRJL5TDOySVd9pWJkerDzhqwE1IaZ qqAzmBHGROWKUEvh00EYIYdiAvyFcrj7QtDiRJL5TDOySVd9pWJkerDzhqwE1IaZ
rpHck+lkYTS7jTD++6v32HG62GdsmryOQUk3aU1rLb3kS8vzaGbrgHpGPid0Hd0x rpHck+lkYTS7jTD++6v32HG62GdsmryOQUk3aU1rLb3kS8vzaGbrgHpGPid0Hd0x
ZSl1AoIMpp5mZ7/h9aW5+A== ZSl1AoIMpp5mZ7/h9aW5+A==
-----END CERTIFICATE----- -----END CERTIFICATE-----
The CRL issued by the CA. The CRL is issued by the CA.
-----BEGIN X509 CRL----- -----BEGIN X509 CRL-----
MIIBrTCBlgIBATANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEygzQUNFMkNFRjRG MIIBrTCBlgIBATANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEygzQUNFMkNFRjRG
QjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyFw0yMzA5MjMxNTU1MzhaFw0y QjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyFw0yMzA5MjMxNTU1MzhaFw0y
MzEwMjMxNTU1MzhaoC8wLTAfBgNVHSMEGDAWgBQ6zizvT7IbfRHj4YTvweKXs3eG MzEwMjMxNTU1MzhaoC8wLTAfBgNVHSMEGDAWgBQ6zizvT7IbfRHj4YTvweKXs3eG
QjAKBgNVHRQEAwIBATANBgkqhkiG9w0BAQsFAAOCAQEACwCNzcAoqbMcUL1kBY65 QjAKBgNVHRQEAwIBATANBgkqhkiG9w0BAQsFAAOCAQEACwCNzcAoqbMcUL1kBY65
YhL95OnBqAcuc99pD4i9c1BmVOl7bXU3cJqLaOZ6Z8CmN0kBbcHyqlHBJ9oA/aYD YhL95OnBqAcuc99pD4i9c1BmVOl7bXU3cJqLaOZ6Z8CmN0kBbcHyqlHBJ9oA/aYD
ByhxsjzKk7jxtM2IlTpEvCEqvnGLSVihgS3h0NA+sgWqHGL3Rhcj6hVsi+j9GENc ByhxsjzKk7jxtM2IlTpEvCEqvnGLSVihgS3h0NA+sgWqHGL3Rhcj6hVsi+j9GENc
T6F9np1mxbI3i2xhgeDJG1pryvH0hWXh7yJiYS8ItNEaIIXDT3szK/J9wnPjukTR T6F9np1mxbI3i2xhgeDJG1pryvH0hWXh7yJiYS8ItNEaIIXDT3szK/J9wnPjukTR
5MITiK9P3TCFujawb3O7rIT5PPgkM6eiCdwDgt6gjmw6cow5+rMjNHSRa+GOviSd 5MITiK9P3TCFujawb3O7rIT5PPgkM6eiCdwDgt6gjmw6cow5+rMjNHSRa+GOviSd
gXljVDfJvF4tKHmw59Jc2aFnSGfX1/ITDNiNfXYpUYFOcsqxkYf8F0uO7AtbRmTF gXljVDfJvF4tKHmw59Jc2aFnSGfX1/ITDNiNfXYpUYFOcsqxkYf8F0uO7AtbRmTF
2w== 2w==
-----END X509 CRL----- -----END X509 CRL-----
The end-entity certificate is issued by the CA. This certificate The end entity certificate is issued by the CA. This certificate
grants signature authority for one IPv4 address block (192.0.2.0/24). grants signature authority for one IPv4 address block (192.0.2.0/24).
Signature authority for AS numbers is not needed for geofeed data Signature authority for AS numbers is not needed for geofeed data
signatures, so no AS numbers are included in the end-entity signatures, so no AS numbers are included in the end entity
certificate. certificate.
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIEVjCCAz6gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZvAwDQYJKoZIhvcNAQEL MIIEVjCCAz6gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZvAwDQYJKoZIhvcNAQEL
BQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExRTNFMTg0RUZDMUUyOTdC BQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExRTNFMTg0RUZDMUUyOTdC
Mzc3ODY0MjAeFw0yMzA5MjMxNTU1MzhaFw0yNDA3MTkxNTU1MzhaMDMxMTAvBgNV Mzc3ODY0MjAeFw0yMzA5MjMxNTU1MzhaFw0yNDA3MTkxNTU1MzhaMDMxMTAvBgNV
BAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM0NUFCRjA1M0ExODcwggEi BAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM0NUFCRjA1M0ExODcwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycTQrOb/qB2W3i3Ki8PhA/DEW MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycTQrOb/qB2W3i3Ki8PhA/DEW
yii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQgtPCVwr62hTQZCIowBN0BL0c yii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQgtPCVwr62hTQZCIowBN0BL0c
K0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZmr5xphXRvE+mzuJVLgu2V1upm K0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZmr5xphXRvE+mzuJVLgu2V1upm
skipping to change at page 20, line 5 skipping to change at line 899
RjRGQjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyLmNlcjAfBggrBgEFBQcB RjRGQjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyLmNlcjAfBggrBgEFBQcB
BwEB/wQQMA4wDAQCAAEwBgMEAMAAAjANBgkqhkiG9w0BAQsFAAOCAQEAlxt25FUe BwEB/wQQMA4wDAQCAAEwBgMEAMAAAjANBgkqhkiG9w0BAQsFAAOCAQEAlxt25FUe
e0+uCidTH+4p7At3u2ncgHcGTsag3UcoPjcE/I1JgQJRu9TiM4iNB1C7Lbdd131g e0+uCidTH+4p7At3u2ncgHcGTsag3UcoPjcE/I1JgQJRu9TiM4iNB1C7Lbdd131g
MdliL5GQ3P4QfKnfkuPR6S1V8suq6ZT1KQRyLJx+EPgDN2rb/iji0TOK6RKPNBdG MdliL5GQ3P4QfKnfkuPR6S1V8suq6ZT1KQRyLJx+EPgDN2rb/iji0TOK6RKPNBdG
lXVLjth4x/uu1O4V54GLEhDAPQC8IUm5intL/Hx1M1x2ptN/+j5HD3XUXd3x13yi lXVLjth4x/uu1O4V54GLEhDAPQC8IUm5intL/Hx1M1x2ptN/+j5HD3XUXd3x13yi
s6u758nbA7ND40JNhGG5JNGQgDchL4IQzIhylMNC+bKUiyyMHz3MqoVAklIB86IW s6u758nbA7ND40JNhGG5JNGQgDchL4IQzIhylMNC+bKUiyyMHz3MqoVAklIB86IW
Ucv72Mekq+i46T/w3RnaGn4x7RAJctVJWw3e5YMrFnQcuuaGOs0QcoxW7Bi4W7Eg Ucv72Mekq+i46T/w3RnaGn4x7RAJctVJWw3e5YMrFnQcuuaGOs0QcoxW7Bi4W7Eg
8fK1fd/f6fjZ9w== 8fK1fd/f6fjZ9w==
-----END CERTIFICATE----- -----END CERTIFICATE-----
The end-entity certificate is displayed below in detail. For The end entity certificate is displayed below in detail. For
brevity, the other two certificates are not. brevity, the other two certificates are not.
0 1110: SEQUENCE { 0 1110: SEQUENCE {
4 830: SEQUENCE { 4 830: SEQUENCE {
8 3: [0] { 8 3: [0] {
10 1: INTEGER 2 10 1: INTEGER 2
: } : }
13 20: INTEGER 13 20: INTEGER
: 27 AD 39 40 83 D7 F2 B5 B9 9B 86 70 C7 75 B2 B9 : 27 AD 39 40 83 D7 F2 B5 B9 9B 86 70 C7 75 B2 B9
: 6E E1 66 F0 : 6E E1 66 F0
skipping to change at page 23, line 45 skipping to change at line 1084
: 4B FC 7C 75 33 5C 76 A6 D3 7F FA 3E 47 0F 75 D4 : 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 : 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 : 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 : 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 : 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 : 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 : 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 : EC 18 B8 5B B1 20 F1 F2 B5 7D DF DF E9 F8 D9 F7
: } : }
To allow reproduction of the signature results, the end-entity To allow reproduction of the signature results, the end entity
private key is provided. For brevity, the other two private keys are private key is provided. For brevity, the other two private keys are
not. not.
-----BEGIN RSA PRIVATE KEY----- -----BEGIN RSA PRIVATE KEY-----
MIIEpQIBAAKCAQEAsnE0Kzm/6gdlt4tyovD4QPwxFsootk4BqPaYAsDvZbCESOmW MIIEpQIBAAKCAQEAsnE0Kzm/6gdlt4tyovD4QPwxFsootk4BqPaYAsDvZbCESOmW
/5Pmkollj/ZEnM5XEILTwlcK+toU0GQiKMATdAS9HCtP+ZNYpiXYuanTN57yrMDP /5Pmkollj/ZEnM5XEILTwlcK+toU0GQiKMATdAS9HCtP+ZNYpiXYuanTN57yrMDP
Ap6EddbwfKUBcK7mZq+caYV0bxPps7iVS4LtldbqZgV7lpaHsprnYellifhg48D1 Ap6EddbwfKUBcK7mZq+caYV0bxPps7iVS4LtldbqZgV7lpaHsprnYellifhg48D1
zt0YlwXowazhTV4WhS3tPMuAz36/0v7VyTgZu0M0KbZmzy2LRn6a2LuOZYhRaqj/ zt0YlwXowazhTV4WhS3tPMuAz36/0v7VyTgZu0M0KbZmzy2LRn6a2LuOZYhRaqj/
eFHi6SEn13d+gChs6kxQnHNxFvZeVBRNTBS5Z6BKIKraC6CgAbdCJDhRingvxIHm eFHi6SEn13d+gChs6kxQnHNxFvZeVBRNTBS5Z6BKIKraC6CgAbdCJDhRingvxIHm
gXVi3uOvXXQva0H7ecOoOnJsRvmmA3SBAd+M6wIDAQABAoIBAQCyB0FeMuKm8bRo gXVi3uOvXXQva0H7ecOoOnJsRvmmA3SBAd+M6wIDAQABAoIBAQCyB0FeMuKm8bRo
skipping to change at page 24, line 33 skipping to change at line 1116
O2TPSfZhF/zPo3pCWQ78/QDb+Zdw4IEiqoBA7F4NPVLg9Y/H8UTx9r/veqe7hPOo O2TPSfZhF/zPo3pCWQ78/QDb+Zdw4IEiqoBA7F4NPVLg9Y/H8UTx9r/veqe7hPOo
Ok7NpIzSmKTHkc5XfZ60Zn9OLFoKbaQ40a1kXoJdWEu2YROaUlAe9F6/Rog6PHYz Ok7NpIzSmKTHkc5XfZ60Zn9OLFoKbaQ40a1kXoJdWEu2YROaUlAe9F6/Rog6PHYz
vLE5qscRbu0XQhLkN+z7bg5bAoGBAKDsbDEb/dbqbyaAYpmwhH2sdRSkphg7Niwc vLE5qscRbu0XQhLkN+z7bg5bAoGBAKDsbDEb/dbqbyaAYpmwhH2sdRSkphg7Niwc
DNm9qWa1J6Zw1+M87I6Q8naRREuU1IAVqqWHVLr/ROBQ6NTJ1Uc5/qFeT2XXUgkf DNm9qWa1J6Zw1+M87I6Q8naRREuU1IAVqqWHVLr/ROBQ6NTJ1Uc5/qFeT2XXUgkf
taMKv61tuyjZK3sTmznMh0HfzUpWjEhWnCEuB+ZYVdmO52ZGw2A75RdrILL2+9Dc taMKv61tuyjZK3sTmznMh0HfzUpWjEhWnCEuB+ZYVdmO52ZGw2A75RdrILL2+9Dc
PvDXVubRAoGAdqXeSWoLxuzZXzl8rsaKrQsTYaXnOWaZieU1SL5vVe8nK257UDqZ PvDXVubRAoGAdqXeSWoLxuzZXzl8rsaKrQsTYaXnOWaZieU1SL5vVe8nK257UDqZ
E3ng2j5XPTUWli+aNGFEJGRoNtcQvO60O/sFZUhu52sqq9mWVYZNh1TB5aP8X+pV E3ng2j5XPTUWli+aNGFEJGRoNtcQvO60O/sFZUhu52sqq9mWVYZNh1TB5aP8X+pV
iFcZOLUvQEcN6PA+YQK5FU11rAI1M0Gm5RDnVnUl0L2xfCYxb7FzV6Y= iFcZOLUvQEcN6PA+YQK5FU11rAI1M0Gm5RDnVnUl0L2xfCYxb7FzV6Y=
-----END RSA PRIVATE KEY----- -----END RSA PRIVATE KEY-----
Signing of "192.0.2.0/24,US,WA,Seattle," (terminated by CR and LF), The signing of "192.0.2.0/24,US,WA,Seattle," (terminated by CR and
yields the following detached CMS signature. LF) yields the following detached CMS signature.
# RPKI Signature: 192.0.2.0/24 # RPKI Signature: 192.0.2.0/24
# MIIGQAYJKoZIhvcNAQcCoIIGMTCCBi0CAQMxDTALBglghkgBZQMEAgEwDQYLKoZ # MIIGQAYJKoZIhvcNAQcCoIIGMTCCBi0CAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
# IhvcNAQkQAS+gggRaMIIEVjCCAz6gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZv # IhvcNAQkQAS+gggRaMIIEVjCCAz6gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZv
# AwDQYJKoZIhvcNAQELBQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExR # AwDQYJKoZIhvcNAQELBQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExR
# TNFMTg0RUZDMUUyOTdCMzc3ODY0MjAeFw0yMzA5MjMxNTU1MzhaFw0yNDA3MTkx # TNFMTg0RUZDMUUyOTdCMzc3ODY0MjAeFw0yMzA5MjMxNTU1MzhaFw0yNDA3MTkx
# NTU1MzhaMDMxMTAvBgNVBAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM # NTU1MzhaMDMxMTAvBgNVBAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM
# 0NUFCRjA1M0ExODcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycT # 0NUFCRjA1M0ExODcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycT
# QrOb/qB2W3i3Ki8PhA/DEWyii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQg # QrOb/qB2W3i3Ki8PhA/DEWyii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQg
# tPCVwr62hTQZCIowBN0BL0cK0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZm # tPCVwr62hTQZCIowBN0BL0cK0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZm
skipping to change at page 25, line 42 skipping to change at line 1156
# iG9w0BCQMxDQYLKoZIhvcNAQkQAS8wHAYJKoZIhvcNAQkFMQ8XDTIzMDkyMzE1N # iG9w0BCQMxDQYLKoZIhvcNAQkQAS8wHAYJKoZIhvcNAQkFMQ8XDTIzMDkyMzE1N
# TUzOFowLwYJKoZIhvcNAQkEMSIEICvi8p5S8ckg2wTRhDBQzGijjyqs5T6I+4Vt # TUzOFowLwYJKoZIhvcNAQkEMSIEICvi8p5S8ckg2wTRhDBQzGijjyqs5T6I+4Vt
# BHypfcEWMA0GCSqGSIb3DQEBAQUABIIBAKZND7pKdVdfpB6zaJN89wTt+sXd0io # BHypfcEWMA0GCSqGSIb3DQEBAQUABIIBAKZND7pKdVdfpB6zaJN89wTt+sXd0io
# 0WULMc+o6gRJFt3wmKNW2nYPrDbocJ+Q/rDMGxbp4QetJ0MQtn1+AYAS8v5jPDO # 0WULMc+o6gRJFt3wmKNW2nYPrDbocJ+Q/rDMGxbp4QetJ0MQtn1+AYAS8v5jPDO
# 4a63U4/mJ2D3wSnQsDP0lUVknqRzfnS66HgHqiOVdHB0U+OnMEJuqHNTLx0dknb # 4a63U4/mJ2D3wSnQsDP0lUVknqRzfnS66HgHqiOVdHB0U+OnMEJuqHNTLx0dknb
# L3zwxyDJTHdo+dMB0U9xdcjwpsPM3xqg57EXj5EIQK5JbardXCjrsysAnEdktUY # L3zwxyDJTHdo+dMB0U9xdcjwpsPM3xqg57EXj5EIQK5JbardXCjrsysAnEdktUY
# oyayGNbbQelANYJcOmuHhSXArR+qqzvNP2MDRqqKEcpd65YW6FSnqlVMIBH2M3P # oyayGNbbQelANYJcOmuHhSXArR+qqzvNP2MDRqqKEcpd65YW6FSnqlVMIBH2M3P
# D2F0p3sdm4IeGAZWaERVB4AXO1PUFDNdhamr4XpIwqIoAig7xiLm7j8qu5Oc= # D2F0p3sdm4IeGAZWaERVB4AXO1PUFDNdhamr4XpIwqIoAig7xiLm7j8qu5Oc=
# End Signature: 192.0.2.0/24 # End Signature: 192.0.2.0/24
Acknowledgments
Thanks to Rob Austein for the CMS and detached signature clue, George
Michaelson for the first and substantial external review, and Erik
Kline who was too shy to agree to coauthorship. Additionally, we
express our gratitude to early implementors, including Menno
Schepers, Flavio Luciani, Eric Dugas, and Kevin Pack. Also, thanks
to the following geolocation providers who are 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, 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.
Authors' Addresses Authors' Addresses
Randy Bush Randy Bush
IIJ Research & Arrcus IIJ Research & Arrcus
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, Washington 98110 Bainbridge Island, Washington 98110
United States of America United States of America
Email: randy@psg.com Email: randy@psg.com
Massimo Candela Massimo Candela
NTT NTT
Veemweg 23 Veemweg 23
3771 MT Barneveld 3771 MT Barneveld
Netherlands Netherlands
Email: massimo@ntt.net Email: massimo@ntt.net
Warren Kumari Warren Kumari
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
 End of changes. 66 change blocks. 
180 lines changed or deleted 191 lines changed or added

This html diff was produced by rfcdiff 1.48.