1169 lines
52 KiB
XML
1169 lines
52 KiB
XML
<?xml version="1.0" encoding="US-ASCII"?>
|
|
|
|
<?rfc sortrefs="yes"?>
|
|
<?rfc subcompact="no"?>
|
|
<?rfc symrefs="yes"?>
|
|
<?rfc toc="yes"?>
|
|
<?rfc tocdepth="3"?>
|
|
<?rfc compact="yes"?>
|
|
<?rfc subcompact="no"?>
|
|
|
|
<rfc category="std" docName="draft-ymbk-sidrops-9020-update-00" submissionType="IETF" consensus="true" ipr="trust200902">
|
|
|
|
<front>
|
|
|
|
<title abbrev="Finding Geofeeds">A Minor Update to Finding and Using Geofeed Data</title>
|
|
|
|
<author fullname="Randy Bush" initials="R." surname="Bush">
|
|
<organization>IIJ & Arrcus</organization>
|
|
<address>
|
|
<postal>
|
|
<street>5147 Crystal Springs</street>
|
|
<city>Bainbridge Island</city>
|
|
<region>Washington</region>
|
|
<code>98110</code>
|
|
<country>United States of America</country>
|
|
</postal>
|
|
<email>randy@psg.com</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author fullname="Massimo Candela" initials="M." surname="Candela">
|
|
<organization>NTT</organization>
|
|
<address>
|
|
<postal>
|
|
<street>Siriusdreef 70-72</street>
|
|
<city>Hoofddorp</city>
|
|
<code>2132 WT</code>
|
|
<country>Netherlands</country>
|
|
</postal>
|
|
<email>massimo@ntt.net</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author fullname="Warren Kumari" initials="W." surname="Kumari">
|
|
<organization>Google</organization>
|
|
<address>
|
|
<postal>
|
|
<street>1600 Amphitheatre Parkway</street>
|
|
<city>Mountain View</city>
|
|
<region>CA</region>
|
|
<code>94043</code>
|
|
<country>United States of America</country>
|
|
</postal>
|
|
<email>warren@kumari.net</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author fullname="Russ Housley" initials="R" surname="Housley">
|
|
<organization abbrev="Vigil Security">Vigil Security, LLC</organization>
|
|
<address>
|
|
<postal>
|
|
<street>516 Dranesville Road</street>
|
|
<city>Herndon</city>
|
|
<region>VA</region>
|
|
<code>20170</code>
|
|
<country>United States of America</country>
|
|
</postal>
|
|
<email>housley@vigilsec.com</email>
|
|
</address>
|
|
</author>
|
|
|
|
<date />
|
|
|
|
<keyword>geolocation</keyword>
|
|
<keyword>geo-location</keyword>
|
|
<keyword>RPSL</keyword>
|
|
|
|
<abstract>
|
|
<t>
|
|
This document specifies how to augment the Routing Policy
|
|
Specification Language inetnum: class to refer specifically to
|
|
geofeed data comma-separated values (CSV) files and describes an
|
|
optional scheme that uses the Routing Public Key Infrastructure
|
|
to authenticate the geofeed data CSV files.
|
|
</t>
|
|
</abstract>
|
|
|
|
</front>
|
|
|
|
<middle>
|
|
<section anchor="intro" numbered="true" toc="default">
|
|
<name>Introduction</name>
|
|
<t>
|
|
Providers of Internet content and other services may wish to
|
|
customize those services based on the geographic location of the
|
|
user of the service. This is often done using the source IP
|
|
address used to contact the service. Also, infrastructure and
|
|
other services might wish to publish the locale of their
|
|
services. <xref target="RFC8805" format="default"/> defines
|
|
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.
|
|
</t>
|
|
<t>
|
|
This document specifies how to augment the Routing Policy
|
|
Specification Language (RPSL) <xref target="RFC2725"
|
|
format="default"/> inetnum: class to refer specifically to
|
|
geofeed data CSV files and how to prudently use them. In all
|
|
places inetnum: is used, inet6num: should also be assumed <xref
|
|
target="RFC4012" format="default"/>.
|
|
</t>
|
|
<t>
|
|
The reader may find <xref target="INETNUM" format="default"/>
|
|
and <xref target="INET6NUM" format="default"/> informative, and
|
|
certainly more verbose, descriptions of the inetnum: database
|
|
classes.
|
|
</t>
|
|
<t>
|
|
An optional utterly awesome but slightly complex means for
|
|
authenticating geofeed data is also defined.
|
|
</t>
|
|
<section numbered="true" toc="default">
|
|
<name>Requirements Language</name>
|
|
|
|
<t>
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
|
|
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
|
|
"MAY", and "OPTIONAL" in this document are to be interpreted as
|
|
described in BCP 14 <xref format="default" pageno="false"
|
|
target="RFC2119"/> <xref format="default" pageno="false"
|
|
target="RFC8174"/> when, and only when, they appear in all
|
|
capitals, as shown here.
|
|
</t>
|
|
|
|
</section>
|
|
</section>
|
|
<section anchor="gf" numbered="true" toc="default">
|
|
<name>Geofeed Files</name>
|
|
<t>
|
|
Geofeed files are described in <xref target="RFC8805"
|
|
format="default"/>. They provide a facility for an IP address
|
|
resource "owner" to associate those IP addresses to geographic
|
|
locales.
|
|
</t>
|
|
|
|
<t>
|
|
Content providers and other parties who wish to locate an IP
|
|
address to a geographic locale need to find the relevant geofeed
|
|
data. In <xref target="inetnum" format="default"/>, this
|
|
document specifies how to find the relevant geofeed <xref
|
|
target="RFC8805" format="default"/> file given an IP address.
|
|
</t>
|
|
<t>
|
|
Geofeed data for large providers with significant horizontal
|
|
scale 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 prefixes, if dual IPv4/IPv6 spaces are
|
|
represented, etc.
|
|
</t>
|
|
<t>
|
|
Geofeed data do have privacy considerations (see <xref
|
|
target="privacy" format="default"/>); this process makes bulk
|
|
access to those data easier.
|
|
</t>
|
|
<t>
|
|
This document also suggests an optional signature to strongly
|
|
authenticate the data in the geofeed files.
|
|
</t>
|
|
</section>
|
|
<section anchor="inetnum" numbered="true" toc="default">
|
|
<name>inetnum: Class</name>
|
|
|
|
<t>
|
|
The original RPSL specifications starting with <xref
|
|
target="RIPE81" format="default"/>, <xref target="RIPE181"
|
|
format="default"/>, and a trail of subsequent documents were
|
|
written by the RIPE community. The IETF standardized RPSL in
|
|
<xref target="RFC2622" format="default"/> and <xref
|
|
target="RFC4012" format="default"/>. Since then, it has been
|
|
modified and extensively enhanced in the Regional Internet
|
|
Registry (RIR) community, mostly by RIPE <xref target="RIPE-DB"
|
|
format="default"/>. Currently, change control effectively lies
|
|
in the operator community.
|
|
</t>
|
|
|
|
<t>
|
|
The RPSL, and <xref target="RFC2725" format="default"/> and
|
|
<xref target="RFC4012" format="default"/> used by the Regional
|
|
Internet Registries (RIRs), specify the inetnum: database class.
|
|
Each of these objects describes an IP address range and its
|
|
attributes. The inetnum: objects form a hierarchy ordered on
|
|
the address space.
|
|
</t>
|
|
|
|
<t>
|
|
Ideally, RPSL would be augmented to define a new RPSL geofeed:
|
|
attribute in the inetnum: class. Until such time, this document
|
|
defines the syntax of a Geofeed remarks: attribute, which
|
|
contains an HTTPS URL of a geofeed file. The format of the
|
|
inetnum: geofeed remarks: attribute <bcp14>MUST</bcp14> be as in
|
|
this example, "remarks: Geofeed ", where the token "Geofeed "
|
|
<bcp14>MUST</bcp14> be case sensitive, followed by a URL that
|
|
will vary, but it <bcp14>MUST</bcp14> refer only to a single
|
|
geofeed <xref target="RFC8805" format="default"/> file.
|
|
</t>
|
|
|
|
<sourcecode type="rpsl"> <![CDATA[
|
|
inetnum: 192.0.2.0/24 # example
|
|
remarks: Geofeed https://example.com/geofeed.csv
|
|
]]></sourcecode>
|
|
<t>
|
|
While we leave global agreement of RPSL modification to the
|
|
relevant parties, we specify that a proper geofeed: attribute in
|
|
the inetnum: class <bcp14>MUST</bcp14> be "geofeed:" and
|
|
<bcp14>MUST</bcp14> be followed by a single URL that will vary,
|
|
but it <bcp14>MUST</bcp14> refer only to a single geofeed <xref
|
|
target="RFC8805" format="default"/> file.
|
|
</t>
|
|
<sourcecode type="rpsl"><![CDATA[
|
|
inetnum: 192.0.2.0/24 # example
|
|
geofeed: https://example.com/geofeed.csv
|
|
]]></sourcecode>
|
|
<t>
|
|
Registries <bcp14>MAY</bcp14>, for the interim, provide a mix of
|
|
the remarks: attribute form and the geofeed: attribute form.
|
|
</t>
|
|
<t>
|
|
The URL uses HTTPS, so the WebPKI provides authentication,
|
|
integrity, and confidentiality for the fetched geofeed file.
|
|
However, the WebPKI can not provide authentication of IP address
|
|
space assignment. In contrast, the RPKI (see <xref
|
|
target="RFC6481" format="default"/>) can be used to authenticate
|
|
IP space assignment; see optional authentication in <xref
|
|
target="auth" format="default"/>.
|
|
</t>
|
|
|
|
<t>
|
|
Until all producers of inetnum: objects, i.e., the RIRs, state
|
|
that they have migrated to supporting a geofeed: attribute,
|
|
consumers looking at inetnum: objects to find geofeed URLs
|
|
<bcp14>MUST</bcp14> be able to consume both the remarks: and
|
|
geofeed: forms.
|
|
|
|
|
|
The migration not only implies that the RIRs support the
|
|
geofeed: attribute, but that all registrants have migrated any
|
|
inetnum: objects from remarks: to geofeed: attributes.
|
|
</t>
|
|
|
|
<t>
|
|
Any particular inetnum: object <bcp14>MUST</bcp14> have, at
|
|
most, one geofeed reference, whether a remarks: or a proper
|
|
geofeed: attribute when it is implemented. If there is more
|
|
than one, the geofeed: attribute SHOULD be used.
|
|
</t>
|
|
<t>
|
|
If a geofeed CSV 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 <xref target="auth" format="default"/>.
|
|
</t>
|
|
<t>
|
|
When geofeed references are provided by multiple inetnum:
|
|
objects that have identical address ranges, then the geofeed
|
|
reference on the inetnum: with the most recent last-modified:
|
|
attribute <bcp14>SHOULD</bcp14> be preferred.
|
|
</t>
|
|
<t>
|
|
As inetnum: objects form a hierarchy, geofeed references
|
|
<bcp14>SHOULD</bcp14> be at the lowest applicable inetnum:
|
|
object covering the relevant address ranges in the referenced
|
|
geofeed file. When fetching, the most specific inetnum: object
|
|
with a geofeed reference <bcp14>MUST</bcp14> be used.
|
|
</t>
|
|
<t>
|
|
It is 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 in
|
|
which P has been subdivided into one or more longer prefixes.
|
|
</t>
|
|
<t>
|
|
Currently, the registry data published by ARIN are not the same
|
|
RPSL as that of the other registries (see <xref target="RFC7485"
|
|
format="default"/> for a survey of the WHOIS Tower of Babel);
|
|
therefore, when fetching from ARIN via FTP <xref
|
|
target="RFC0959" format="default"/>, WHOIS <xref
|
|
target="RFC3912" format="default"/>, the Registration Data
|
|
Access Protocol (RDAP) <xref target="RFC9082"
|
|
format="default"/>, etc., the "NetRange" attribute/key
|
|
<bcp14>MUST</bcp14> be treated as "inetnum", and the "Comment"
|
|
attribute <bcp14>MUST</bcp14> be treated as "remarks".
|
|
</t>
|
|
|
|
</section>
|
|
<section anchor="auth" numbered="true" toc="default">
|
|
<name>Authenticating Geofeed Data (Optional)</name>
|
|
<t>
|
|
The question arises whether a particular geofeed <xref
|
|
target="RFC8805" format="default"/> data set is valid, i.e., is
|
|
authorized by the "owner" of the IP address space and is
|
|
authoritative in some sense. The inetnum: that points to the
|
|
geofeed <xref target="RFC8805" format="default"/> file provides
|
|
some assurance. Unfortunately, the RPSL in many repositories is
|
|
weakly authenticated at best. An approach where RPSL was signed
|
|
per <xref target="RFC7909" format="default"/> would be good,
|
|
except it would have to be deployed by all RPSL registries, and
|
|
there is a fair number of them.
|
|
</t>
|
|
<t>
|
|
A single optional authenticator <bcp14>MAY</bcp14> be appended
|
|
to a geofeed <xref target="RFC8805" format="default"/> file. It
|
|
is a digest of the main body of the file signed by the private
|
|
key of the relevant RPKI certificate for a covering address
|
|
range. One needs a format that bundles the relevant RPKI
|
|
certificate with the signature of the geofeed text.
|
|
</t>
|
|
<t>
|
|
The canonicalization procedure converts the data from their
|
|
internal character representation to the UTF-8 <xref
|
|
target="RFC3629" format="default"/> character encoding, and the
|
|
<CRLF> sequence <bcp14>MUST</bcp14> be used to denote the
|
|
end of a line of text. A blank line is represented solely by
|
|
the <CRLF> sequence. For robustness, any non-printable
|
|
characters <bcp14>MUST NOT</bcp14> be changed by
|
|
canonicalization. Trailing blank lines <bcp14>MUST NOT</bcp14>
|
|
appear at the end of the file. That is, the file must not end
|
|
with multiple consecutive <CRLF> sequences. Any
|
|
end-of-file marker used by an operating system is not considered
|
|
to be part of the file content. When present, such end-of-file
|
|
markers <bcp14>MUST NOT</bcp14> be processed by the digital
|
|
signature algorithm.
|
|
</t>
|
|
<t>
|
|
Should the authenticator be syntactically incorrect per the
|
|
above, the authenticator is invalid.
|
|
</t>
|
|
|
|
<t>
|
|
Borrowing detached signatures from <xref target="RFC5485"
|
|
format="default"/>, after file canonicalization, the
|
|
Cryptographic Message Syntax (CMS) <xref target="RFC5652"
|
|
format="default"/> would be used to create a detached
|
|
DER-encoded signature that is then padded BASE64 encoded (as per
|
|
<xref target="RFC4648" sectionFormat="of" section="4"
|
|
format="default"/>) and line wrapped to 72 or fewer characters.
|
|
The same digest algorithm <bcp14>MUST</bcp14> be used for
|
|
calculating the message digest on content being signed, which is
|
|
the geofeed file, and for calculating the message digest on the
|
|
SignerInfo SignedAttributes <xref target="RFC8933"
|
|
format="default"/>. The message digest algorithm identifier
|
|
<bcp14>MUST</bcp14> appear in both the SignedData
|
|
DigestAlgorithmIdentifiers and the SignerInfo
|
|
DigestAlgorithmIdentifier <xref target="RFC5652"
|
|
format="default"/>.
|
|
</t>
|
|
<t>
|
|
The address range of the signing certificate <bcp14>MUST</bcp14>
|
|
cover all prefixes in the geofeed file it signs.
|
|
</t>
|
|
<t>
|
|
An address range A "covers" address range B if the range of B is
|
|
identical to or a subset of A. "Address range" is used here
|
|
because inetnum: objects and RPKI certificates need not align on
|
|
Classless Inter-Domain Routing (CIDR) <xref target="RFC4632"/>
|
|
prefix boundaries, while those of the CSV lines in a geofeed
|
|
file do.
|
|
</t>
|
|
<t>
|
|
As the signer specifies the covered RPKI resources relevant to
|
|
the signature, the RPKI certificate covering the inetnum:
|
|
object's address range is included in the <xref target="RFC5652"
|
|
format="default"/> CMS SignedData certificates field.
|
|
</t>
|
|
<t>
|
|
Identifying the private key associated with the certificate and
|
|
getting the department that controls the private key (which
|
|
might be trapped in a Hardware Security Module (HSM)) to sign
|
|
the CMS blob is left as an exercise for the implementor. On the
|
|
other hand, verifying the signature requires no complexity; the
|
|
certificate, which can be validated in the public RPKI, has the
|
|
needed public key.
|
|
|
|
The trust anchors for the RIRs are expected to already be
|
|
available to the party performing signature validation.
|
|
Validation of the CMS signature on the geofeed file
|
|
involves:</t>
|
|
<ol spacing="normal" type="1"><li>
|
|
<t>
|
|
Obtaining the signer's certificate from the CMS SignedData
|
|
CertificateSet <xref target="RFC5652" format="default"/>. The
|
|
certificate SubjectKeyIdentifier extension <xref
|
|
target="RFC5280" format="default"/> <bcp14>MUST</bcp14> match
|
|
the SubjectKeyIdentifier in the CMS SignerInfo
|
|
SignerIdentifier <xref target="RFC5652" format="default"/>.
|
|
If the key identifiers do not match, then validation
|
|
<bcp14>MUST</bcp14> fail.</t>
|
|
<t>
|
|
Validation of the signer's certificate <bcp14>MUST</bcp14>
|
|
ensure that it is part of the current <xref target="RFC6486"
|
|
format="default"/> manifest and that the resources are covered
|
|
by the RPKI certificate.
|
|
</t>
|
|
</li>
|
|
|
|
<li>
|
|
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 <bcp14>MUST</bcp14> be valid according to
|
|
the validation algorithm in <xref target="RFC5280"
|
|
format="default"/> and the additional checks specified in
|
|
<xref target="RFC3779" format="default"/> associated with the
|
|
IP Address Delegation certificate extension and the Autonomous
|
|
System Identifier Delegation certificate extension. If
|
|
certification path validation is unsuccessful, then validation
|
|
<bcp14>MUST</bcp14> fail.
|
|
</li>
|
|
|
|
<li>
|
|
Validating the CMS SignedData as specified in <xref
|
|
target="RFC5652" format="default"/> using the public key from
|
|
the validated signer's certificate. If the signature
|
|
validation is unsuccessful, then validation
|
|
<bcp14>MUST</bcp14> fail.
|
|
</li>
|
|
<li>
|
|
Verifying that the IP Address Delegation certificate extension
|
|
<xref target="RFC3779" format="default"/> covers all of the
|
|
address ranges of the geofeed file. If all of the address
|
|
ranges are not covered, then validation <bcp14>MUST</bcp14>
|
|
fail.
|
|
</li>
|
|
</ol>
|
|
<t>
|
|
All of these steps <bcp14>MUST</bcp14> be successful to consider
|
|
the geofeed file signature as valid.
|
|
</t>
|
|
<t>
|
|
As the signer specifies the covered RPKI resources relevant to the
|
|
signature, the RPKI certificate covering the inetnum: object's address
|
|
range is included in the CMS SignedData certificates field <xref
|
|
target="RFC5652" format="default"/>.
|
|
</t>
|
|
<t>
|
|
As an IP Address Delegation extension using "inherit" would
|
|
complicate processing, it <bcp14>MUST NOT</bcp14> be used. This
|
|
is consistent with other RPKI signed objects.
|
|
</t>
|
|
<t>
|
|
Identifying the private key associated with the certificate and
|
|
getting the department with the Hardware Security Module (HSM)
|
|
to sign the CMS blob is left as an exercise for the implementor.
|
|
On the other hand, verifying the signature requires no
|
|
complexity; the certificate, which can be validated in the
|
|
public RPKI, has the needed public key.
|
|
</t>
|
|
<t>
|
|
The appendix <bcp14>MUST</bcp14> be hidden as a series of "#" comments at the
|
|
end of the geofeed file. The following is a cryptographically
|
|
incorrect, albeit simple, example. A correct and full example is
|
|
in <xref target="example" format="default"/>.
|
|
</t>
|
|
<sourcecode type=""><![CDATA[
|
|
# RPKI Signature: 192.0.2.0 - 192.0.2.255
|
|
# MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
|
|
# IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
|
|
...
|
|
# imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa
|
|
# O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=
|
|
# End Signature: 192.0.2.0 - 192.0.2.255
|
|
]]></sourcecode>
|
|
<t>
|
|
The signature does not cover the signature lines.
|
|
</t>
|
|
<t>
|
|
The bracketing "# RPKI Signature:" and "# End Signature:"
|
|
<bcp14>MUST</bcp14> be present following the model as shown.
|
|
Their IP address range <bcp14>MUST</bcp14> match that of the
|
|
inetnum: URL followed to the file.
|
|
</t>
|
|
<t>
|
|
<xref target="RFC9323" format="default"/> describes
|
|
and provides code for a CMS profile for
|
|
a general purpose listing of checksums (a "checklist") for use with
|
|
the Resource Public Key Infrastructure (RPKI). It provides usable,
|
|
albeit complex, code to sign geofeed files.
|
|
</t>
|
|
<t>
|
|
<xref target="I-D.ietf-sidrops-rpki-rta" format="default"/> describes
|
|
a CMS profile for a general purpose Resource Tagged Attestation (RTA)
|
|
based on the RPKI. While this is expected to become applicable in the
|
|
long run, for the purposes of this document, a self-signed root trust
|
|
anchor is used.
|
|
</t>
|
|
</section>
|
|
<section anchor="ops" numbered="true" toc="default">
|
|
<name>Operational Considerations</name>
|
|
|
|
<t>
|
|
To create the needed inetnum: objects, an operator wishing to register
|
|
the location of their geofeed file needs to coordinate with their
|
|
Regional Internet Registry (RIR) or National Internet Registry (NIR)
|
|
and/or any provider Local Internet Registry (LIR) that has assigned
|
|
address ranges to them. RIRs/NIRs provide means for assignees to
|
|
create and maintain inetnum: objects. They also provide means of
|
|
assigning or sub-assigning IP address resources and allowing the
|
|
assignee to create WHOIS data, including inetnum: objects, thereby
|
|
referring to geofeed files.
|
|
</t>
|
|
<t>
|
|
The geofeed files <bcp14>MUST</bcp14> be published via and fetched using
|
|
HTTPS <xref target="RFC2818" format="default"/>.
|
|
</t>
|
|
<t>
|
|
When using data from a geofeed file, one <bcp14>MUST</bcp14> ignore data
|
|
outside the referring inetnum: object's inetnum: attribute
|
|
address range.
|
|
</t>
|
|
<t>
|
|
If and only if the geofeed file is not signed per <xref target="auth"
|
|
format="default"/>, then multiple inetnum: objects <bcp14>MAY</bcp14>
|
|
refer to the same geofeed file, and the consumer <bcp14>MUST</bcp14>
|
|
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.
|
|
</t>
|
|
<t>
|
|
If the geofeed file is signed, and the signer's certificate
|
|
changes, the signature in the geofeed file <bcp14>MUST</bcp14> be updated.
|
|
</t>
|
|
|
|
<t>
|
|
It is good key hygiene to use a given key for only one purpose.
|
|
To dedicate a signing private key for signing a geofeed file, an
|
|
RPKI Certification Authority (CA) may issue a subordinate certificate exclusively for
|
|
the purpose shown in <xref target="example" format="default"/>.
|
|
</t>
|
|
<t>
|
|
To minimize the load on RIR WHOIS <xref target="RFC3912"
|
|
format="default"/> services, use of the RIR's FTP <xref
|
|
target="RFC0959" format="default"/> services <bcp14>SHOULD</bcp14> be
|
|
used for large-scale access to gather geofeed URLs. This also
|
|
provides bulk access instead of fetching by brute-force search
|
|
through the IP space.
|
|
</t>
|
|
<t>
|
|
Currently, geolocation providers have bulk WHOIS data access at
|
|
all the RIRs. An anonymized version of such data is openly
|
|
available for all RIRs except ARIN, which requires an
|
|
authorization. However, for users without such authorization,
|
|
the same result can be achieved with extra RDAP effort. There is
|
|
open-source code to pass over such data across all RIRs, collect
|
|
all geofeed references, and process them <xref target="GEOFEED-FINDER" format="default"/>.
|
|
</t>
|
|
|
|
<t>
|
|
To prevent undue load on RPSL and geofeed servers, entity-fetching
|
|
geofeed data using these mechanisms <bcp14>MUST NOT</bcp14> do
|
|
frequent real-time lookups. <xref target="RFC8805" sectionFormat="of"
|
|
section="3.4" format="default"/> suggests use of the HTTP Expires
|
|
header <xref target="RFC7234" format="default"/> to signal when
|
|
geofeed data should be refetched. As the data change very
|
|
infrequently, in the absence of such an HTTP Header signal, collectors
|
|
<bcp14>SHOULD NOT</bcp14> fetch more frequently than weekly. It would
|
|
be polite not to fetch at magic times such as midnight UTC, the first
|
|
of the month, etc., because too many others are likely to do the same.
|
|
</t>
|
|
</section>
|
|
<section anchor="privacy" numbered="true" toc="default">
|
|
<name>Privacy Considerations</name>
|
|
|
|
|
|
<t>
|
|
<xref target="RFC8805" format="default"/> geofeed data may reveal the
|
|
approximate location of an IP address, which might in turn reveal the
|
|
approximate location of an individual user. Unfortunately, <xref
|
|
target="RFC8805" format="default"/> provides no privacy guidance on
|
|
avoiding or ameliorating possible damage due to this exposure of the
|
|
user. In 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 <xref
|
|
target="RFC8805" sectionFormat="of" section="4" format="default"/>
|
|
apply to this document.
|
|
</t>
|
|
<t>
|
|
Where <xref target="RFC8805" format="default"/> provided the ability
|
|
to publish location data, this document makes bulk access to those data
|
|
readily available. This is a goal, not an accident.
|
|
</t>
|
|
</section>
|
|
<section anchor="seccons" numbered="true" toc="default">
|
|
<name>Security Considerations</name>
|
|
<t>
|
|
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 <xref target="RFC8805" format="default"/> apply here as well.
|
|
</t>
|
|
<t>
|
|
As mentioned in <xref target="auth" format="default"/>, many RPSL
|
|
repositories have weak, if any, authentication. This allows spoofing
|
|
of inetnum: objects pointing to malicious geofeed files. <xref
|
|
target="auth" format="default"/> suggests an unfortunately complex
|
|
method for stronger authentication based on the RPKI.
|
|
</t>
|
|
|
|
|
|
<t>
|
|
For example, if an inetnum: for a wide address range (e.g., a
|
|
/16) points to an RPKI-signed 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,
|
|
abusing the rule that the most-specific inetnum: object with a
|
|
geofeed reference <bcp14>MUST</bcp14> be used.
|
|
</t>
|
|
<t>
|
|
If signatures were mandatory, the above attack would be stymied, but
|
|
of course that is not happening anytime soon.
|
|
</t>
|
|
<t>
|
|
The RPSL providers have had to throttle fetching from their
|
|
servers due to too-frequent queries. Usually, they throttle by
|
|
the querying IP address or block. Similar defenses will likely
|
|
need to be deployed by geofeed file servers.
|
|
</t>
|
|
</section>
|
|
<section anchor="iana" numbered="true" toc="default">
|
|
<name>IANA Considerations</name>
|
|
<t>
|
|
IANA has registered object identifiers for one content
|
|
type in the "SMI Security for S/MIME CMS Content Type
|
|
(1.2.840.113549.1.9.16.1)" registry as follows:
|
|
</t>
|
|
|
|
<table anchor="iana_table">
|
|
<thead>
|
|
<tr>
|
|
<th>Decimal</th>
|
|
<th>Description</th>
|
|
<th>References</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td>47</td>
|
|
<td>id-ct-geofeedCSVwithCRLF</td>
|
|
<td>RFC 9092</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
</section>
|
|
</middle>
|
|
<back>
|
|
|
|
<displayreference target="I-D.ietf-sidrops-rpki-rta" to="RPKI-RTA"/>
|
|
|
|
<references title="Normative References">
|
|
<?rfc include="reference.RFC.2119.xml"?>
|
|
<?rfc include="reference.RFC.2622.xml"?>
|
|
<?rfc include="reference.RFC.2725.xml"?>
|
|
<?rfc include="reference.RFC.2818.xml"?>
|
|
<?rfc include="reference.RFC.3629.xml"?>
|
|
<?rfc include="reference.RFC.3779.xml"?>
|
|
<?rfc include="reference.RFC.4012.xml"?>
|
|
<?rfc include="reference.RFC.4648.xml"?>
|
|
<?rfc include="reference.RFC.5280.xml"?>
|
|
<?rfc include="reference.RFC.5652.xml"?>
|
|
<?rfc include="reference.RFC.8174.xml"?>
|
|
<?rfc include="reference.RFC.6481.xml"?>
|
|
<?rfc include="reference.RFC.6486.xml"?>
|
|
<?rfc include="reference.RFC.8805.xml"?>
|
|
<?rfc include="reference.RFC.8933.xml"?>
|
|
</references>
|
|
|
|
<references title="Informative References">
|
|
<?rfc include="reference.RFC.0959.xml"?>
|
|
<?rfc include="reference.RFC.3912.xml"?>
|
|
<?rfc include="reference.RFC.4632.xml"?>
|
|
<?rfc include="reference.RFC.5485.xml"?>
|
|
<?rfc include="reference.RFC.7234.xml"?>
|
|
<?rfc include="reference.RFC.7485.xml"?>
|
|
<?rfc include="reference.RFC.7909.xml"?>
|
|
<?rfc include="reference.RFC.9082.xml"?>
|
|
<?rfc include="reference.RFC.9323.xml"?>
|
|
<?rfc include="reference.I-D.ietf-sidrops-rpki-rta.xml"?>
|
|
|
|
|
|
<reference anchor="RIPE81" target="https://www.ripe.net/publications/docs/ripe-081">
|
|
<front>
|
|
<title>Representation Of IP Routing Policies In The RIPE Database</title>
|
|
<author>
|
|
<organization>RIPE NCC</organization>
|
|
</author>
|
|
<date month="February" year="1993"/>
|
|
</front>
|
|
</reference>
|
|
|
|
<reference anchor="RIPE181" target="https://www.ripe.net/publications/docs/ripe-181">
|
|
<front>
|
|
<title>Representation Of IP Routing Policies In A Routing Registry</title>
|
|
<author>
|
|
<organization>RIPE NCC</organization>
|
|
</author>
|
|
<date month="October" year="1994"/>
|
|
</front>
|
|
</reference>
|
|
|
|
|
|
<reference anchor="RIPE-DB" target="https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation">
|
|
<front>
|
|
<title>RIPE Database Documentation</title>
|
|
<author>
|
|
<organization>RIPE NCC</organization>
|
|
</author>
|
|
<date/>
|
|
</front>
|
|
</reference>
|
|
|
|
<reference anchor="INETNUM" target="https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-4-description-of-the-inetnum-object">
|
|
<front>
|
|
<title>Description of the INETNUM Object</title>
|
|
<author>
|
|
<organization>RIPE NCC</organization>
|
|
</author>
|
|
<date month="June" year="2020"/>
|
|
</front>
|
|
</reference>
|
|
|
|
<reference anchor="INET6NUM" target="https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-3-description-of-the-inet6num-object">
|
|
<front>
|
|
<title>Description of the INET6NUM Object</title>
|
|
<author>
|
|
<organization>RIPE NCC</organization>
|
|
</author>
|
|
<date month="October" year="2019"/>
|
|
</front>
|
|
</reference>
|
|
|
|
<reference anchor="GEOFEED-FINDER" target="https://github.com/massimocandela/geofeed-finder">
|
|
<front>
|
|
<title>geofeed-finder</title>
|
|
<author>
|
|
<organization></organization>
|
|
</author>
|
|
<date month="June" year="2021"/>
|
|
</front>
|
|
<refcontent>commit 5f557a4</refcontent>
|
|
</reference>
|
|
|
|
</references>
|
|
<section anchor="example" numbered="true" toc="default">
|
|
<name>Example</name>
|
|
<t>
|
|
This appendix provides an example that includes a trust anchor, a CA
|
|
certificate subordinate to the trust anchor, an end-entity
|
|
certificate subordinate to the CA for signing the geofeed, and a
|
|
detached signature.
|
|
</t>
|
|
|
|
<t>
|
|
The trust anchor is represented by a self-signed certificate. As
|
|
usual in the RPKI, the trust anchor has authority over all IPv4
|
|
address blocks, all IPv6 address blocks, and all Autonomous System (AS) numbers.
|
|
</t>
|
|
<sourcecode type=""><![CDATA[
|
|
-----BEGIN CERTIFICATE-----
|
|
MIIEPjCCAyagAwIBAgIUPsUFJ4e/7pKZ6E14aBdkbYzms1gwDQYJKoZIhvcNAQEL
|
|
BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yMDA5MDMxODU0NTRaFw0zMDA5
|
|
MDExODU0NTRaMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEwggEiMA0GCSqGSIb3DQEB
|
|
AQUAA4IBDwAwggEKAoIBAQCelMmMDCGBhqn/a3VrNAoKMr1HVLKxGoG7VF/13HZJ
|
|
0twObUZlh3Jz+XeD+kNAURhELWTrsgdTkQQfqinqOuRemxTl55+x7nLpe5nmwaBH
|
|
XqqDOHubmkbAGanGcm6T/rD9KNk1Z46Uc2p7UYu0fwNO0mo0aqFL2FSyvzZwziNe
|
|
g7ELYZ4a3LvGn81JfP/JvM6pgtoMNuee5RV6TWaz7LV304ICj8Bhphy/HFpOA1rb
|
|
O9gs8CUMgqz+RroAIa8cV8gbF/fPCz9Ofl7Gdmib679JxxFrW4wRJ0nMJgJmsZXq
|
|
jaVc0g7ORc+eIAcHw7Uroc6h7Y7lGjOkDZF75j0mLQa3AgMBAAGjggGEMIIBgDAd
|
|
BgNVHQ4EFgQU3hNEuwvUGNCHY1TBatcUR03pNdYwHwYDVR0jBBgwFoAU3hNEuwvU
|
|
GNCHY1TBatcUR03pNdYwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYw
|
|
GAYDVR0gAQH/BA4wDDAKBggrBgEFBQcOAjCBuQYIKwYBBQUHAQsEgawwgakwPgYI
|
|
KwYBBQUHMAqGMnJzeW5jOi8vcnBraS5leGFtcGxlLm5ldC9yZXBvc2l0b3J5L2V4
|
|
YW1wbGUtdGEubWZ0MDUGCCsGAQUFBzANhilodHRwczovL3JyZHAuZXhhbXBsZS5u
|
|
ZXQvbm90aWZpY2F0aW9uLnhtbDAwBggrBgEFBQcwBYYkcnN5bmM6Ly9ycGtpLmV4
|
|
YW1wbGUubmV0L3JlcG9zaXRvcnkvMCcGCCsGAQUFBwEHAQH/BBgwFjAJBAIAATAD
|
|
AwEAMAkEAgACMAMDAQAwHgYIKwYBBQUHAQgEEjAQoA4wDDAKAgEAAgUA/////zAN
|
|
BgkqhkiG9w0BAQsFAAOCAQEAgZFQ0Sf3CI5Hwev61AUWHYOFniy69PuDTq+WnhDe
|
|
xX5rpjSDRrs5L756KSKJcaOJ36lzO45lfOPSY9fH6x30pnipaqRA7t5rApky24jH
|
|
cSUA9iRednzxhVyGjWKnfAKyNo2MYfaOAT0db1GjyLKbOADI9FowtHBUu+60ykcM
|
|
Quz66XrzxtmxlrRcAnbv/HtV17qOd4my6q5yjTPR1dmYN9oR/2ChlXtGE6uQVguA
|
|
rvNZ5CwiJ1TgGGTB7T8ORHwWU6dGTc0jk2rESAaikmLi1roZSNC21fckhapEit1a
|
|
x8CyiVxjcVc5e0AmS1rJfL6LIfwmtive/N/eBtIM92HkBA==
|
|
-----END CERTIFICATE-----
|
|
]]></sourcecode>
|
|
|
|
<t>
|
|
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).</t>
|
|
<sourcecode type=""><![CDATA[
|
|
-----BEGIN CERTIFICATE-----
|
|
MIIFBzCCA++gAwIBAgIUcyCzS10hdfG65kbRq7toQAvRDKowDQYJKoZIhvcNAQEL
|
|
BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yMDA5MDMxOTAyMTlaFw0yMTA5
|
|
MDMxOTAyMTlaMDMxMTAvBgNVBAMTKDNBQ0UyQ0VGNEZCMjFCN0QxMUUzRTE4NEVG
|
|
QzFFMjk3QjM3Nzg2NDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc
|
|
zz1qwTxC2ocw5rqp8ktm2XyYkl8riBVuqlXwfefTxsR2YFpgz9vkYUd5Az9EVEG7
|
|
6wGIyZbtmhK63eEeaqbKz2GHub467498BXeVrYysO+YuIGgCEYKznNDZ4j5aaDbo
|
|
j5+4/z0Qvv6HEsxQd0f8br6lKJwgeRM6+fm7796HNPB0aqD7Zj9NRCLXjbB0DCgJ
|
|
liH6rXMKR86ofgll9V2mRjesvhdKYgkGbOif9rvxVpLJ/6zdru5CE9yeuJZ59l+n
|
|
YH/r6PzdJ4Q7yKrJX8qD6A60j4+biaU4MQ72KpsjhQNTTqF/HRwi0N54GDaknEwE
|
|
TnJQHgLJDYqww9yKWtjjAgMBAAGjggIvMIICKzAdBgNVHQ4EFgQUOs4s70+yG30R
|
|
4+GE78Hil7N3hkIwHwYDVR0jBBgwFoAU3hNEuwvUGNCHY1TBatcUR03pNdYwDwYD
|
|
VR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwGAYDVR0gAQH/BA4wDDAKBggr
|
|
BgEFBQcOAjBhBgNVHR8EWjBYMFagVKBShlByc3luYzovL3Jwa2kuZXhhbXBsZS5u
|
|
ZXQvcmVwb3NpdG9yeS8zQUNFMkNFRjRGQjIxQjdEMTFFM0UxODRFRkMxRTI5N0Iz
|
|
Nzc4NjQyLmNybDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMnJzeW5jOi8v
|
|
cnBraS5leGFtcGxlLm5ldC9yZXBvc2l0b3J5L2V4YW1wbGUtdGEuY2VyMIG5Bggr
|
|
BgEFBQcBCwSBrDCBqTA+BggrBgEFBQcwCoYycnN5bmM6Ly9ycGtpLmV4YW1wbGUu
|
|
bmV0L3JlcG9zaXRvcnkvZXhhbXBsZS1jYS5tZnQwNQYIKwYBBQUHMA2GKWh0dHBz
|
|
Oi8vcnJkcC5leGFtcGxlLm5ldC9ub3RpZmljYXRpb24ueG1sMDAGCCsGAQUFBzAF
|
|
hiRyc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVwb3NpdG9yeS8wHwYIKwYBBQUH
|
|
AQcBAf8EEDAOMAwEAgABMAYDBADAAAIwHgYIKwYBBQUHAQgEEjAQoA4wDDAKAgMA
|
|
+/ACAwD78TANBgkqhkiG9w0BAQsFAAOCAQEAnLu+d1ZsUTiX3YWGueTHIalW4ad0
|
|
Kupi7pYMV2nXbxNGmdJMol9BkzVz9tj55ReMghUU4YLm/ICYe4fz5e0T8o9s/vIm
|
|
cGS29+WoGuiznMitpvbS/379gaMezk6KpqjH6Brw6meMqy09phmcmvm3x3WTmx09
|
|
mLlQneMptwk8qSYcnMUmGLJs+cVqmkOa3sWRdw8WrGu6QqYtQz3HFZQojF06YzEq
|
|
V/dBdCFdEOwTfVl2n2XqhoJl/oEBdC4uu2G0qRk3+WVs+uwVHP0Ttsbt7TzFgZfY
|
|
yxqvOg6QoldxZVZmHHncKmETu/BqCDGJot9may31ukrx34Bu+XFMVihm0w==
|
|
-----END CERTIFICATE-----
|
|
]]></sourcecode>
|
|
<t>
|
|
The end-entity certificate is issued by the CA. This
|
|
certificate grants signature authority for one IPv4 address block
|
|
(192.0.2.0/24). Signature authority for AS numbers is not needed for
|
|
geofeed data signatures, so no AS numbers are included in the
|
|
certificate.</t>
|
|
<sourcecode type=""><![CDATA[
|
|
-----BEGIN CERTIFICATE-----
|
|
MIIEpTCCA42gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZuQwDQYJKoZIhvcNAQEL
|
|
BQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExRTNFMTg0RUZDMUUyOTdC
|
|
Mzc3ODY0MjAeFw0yMTA1MjAxNjA1NDVaFw0yMjAzMTYxNjA1NDVaMDMxMTAvBgNV
|
|
BAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM0NUFCRjA1M0ExODcwggEi
|
|
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycTQrOb/qB2W3i3Ki8PhA/DEW
|
|
yii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQgtPCVwr62hTQZCIowBN0BL0c
|
|
K0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZmr5xphXRvE+mzuJVLgu2V1upm
|
|
BXuWloeymudh6WWJ+GDjwPXO3RiXBejBrOFNXhaFLe08y4DPfr/S/tXJOBm7QzQp
|
|
tmbPLYtGfprYu45liFFqqP94UeLpISfXd36AKGzqTFCcc3EW9l5UFE1MFLlnoEog
|
|
qtoLoKABt0IkOFGKeC/EgeaBdWLe469ddC9rQft5w6g6cmxG+aYDdIEB34zrAgMB
|
|
AAGjggGvMIIBqzAdBgNVHQ4EFgQUkUZSo71RwUQmAZiIn1xFq/BToYcwHwYDVR0j
|
|
BBgwFoAUOs4s70+yG30R4+GE78Hil7N3hkIwDAYDVR0TAQH/BAIwADAOBgNVHQ8B
|
|
Af8EBAMCB4AwGAYDVR0gAQH/BA4wDDAKBggrBgEFBQcOAjBhBgNVHR8EWjBYMFag
|
|
VKBShlByc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVwb3NpdG9yeS8zQUNFMkNF
|
|
RjRGQjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyLmNybDBsBggrBgEFBQcB
|
|
AQRgMF4wXAYIKwYBBQUHMAKGUHJzeW5jOi8vcnBraS5leGFtcGxlLm5ldC9yZXBv
|
|
c2l0b3J5LzNBQ0UyQ0VGNEZCMjFCN0QxMUUzRTE4NEVGQzFFMjk3QjM3Nzg2NDIu
|
|
Y2VyMBkGCCsGAQUFBwEHAQH/BAowCDAGBAIAAQUAMEUGCCsGAQUFBwELBDkwNzA1
|
|
BggrBgEFBQcwDYYpaHR0cHM6Ly9ycmRwLmV4YW1wbGUubmV0L25vdGlmaWNhdGlv
|
|
bi54bWwwDQYJKoZIhvcNAQELBQADggEBAEjC98gVp0Mb7uiKaHylP0453mtJ+AkN
|
|
07fsK/qGw/e90DJv7cp1hvjj4uy3sgf7PJQ7cKNGrgybq/lE0jce+ARgVjbi2Brz
|
|
ZsWAnB846Snwsktw6cenaif6Aww6q00NspAepMBd2Vg/9sKFvOwJFVOgNcqiQiXP
|
|
5rGJPWBcOMv52a/7adjfXwpnOijiTOgMloQGmC2TPZpydZKjlxEATdFEQssa33xD
|
|
nlpp+/r9xuNVYRtRcC36oWraVA3jzN6F6rDE8r8xs3ylISVz6JeCQ4YRYwbMsjjc
|
|
/tiJLM7ZYxIe5IrYz1ZtN6n/SEssJAswRIgps2EhCt/HS2xAmGCOhgU=
|
|
-----END CERTIFICATE-----
|
|
]]></sourcecode>
|
|
<t>
|
|
The end-entity certificate is displayed below in detail. For
|
|
brevity, the other two certificates are not.
|
|
</t>
|
|
<sourcecode type=""><![CDATA[
|
|
0 1189: SEQUENCE {
|
|
4 909: SEQUENCE {
|
|
8 3: [0] {
|
|
10 1: INTEGER 2
|
|
: }
|
|
13 20: INTEGER 27AD394083D7F2B5B99B8670C775B2B96EE166E4
|
|
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 20/05/2021 16:05:45 GMT
|
|
120 13: UTCTime 16/03/2022 16:05:45 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 431: [3] {
|
|
486 427: 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 12: SEQUENCE {
|
|
556 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19)
|
|
561 1: BOOLEAN TRUE
|
|
564 2: OCTET STRING, encapsulates {
|
|
566 0: SEQUENCE {}
|
|
: }
|
|
: }
|
|
568 14: SEQUENCE {
|
|
570 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
|
|
575 1: BOOLEAN TRUE
|
|
578 4: OCTET STRING, encapsulates {
|
|
580 2: BIT STRING 7 unused bits
|
|
: '1'B (bit 0)
|
|
: }
|
|
: }
|
|
584 24: SEQUENCE {
|
|
586 3: OBJECT IDENTIFIER certificatePolicies (2 5 29 32)
|
|
591 1: BOOLEAN TRUE
|
|
594 14: OCTET STRING, encapsulates {
|
|
596 12: SEQUENCE {
|
|
598 10: SEQUENCE {
|
|
600 8: OBJECT IDENTIFIER
|
|
: resourceCertificatePolicy (1 3 6 1 5 5 7 14 2)
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
610 97: SEQUENCE {
|
|
612 3: OBJECT IDENTIFIER cRLDistributionPoints (2 5 29 31)
|
|
617 90: OCTET STRING, encapsulates {
|
|
619 88: SEQUENCE {
|
|
621 86: SEQUENCE {
|
|
623 84: [0] {
|
|
625 82: [0] {
|
|
627 80: [6]
|
|
: 'rsync://rpki.example.net/repository/3ACE2CEF4F'
|
|
: 'B21B7D11E3E184EFC1E297B3778642.crl'
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
709 108: SEQUENCE {
|
|
711 8: OBJECT IDENTIFIER authorityInfoAccess
|
|
: (1 3 6 1 5 5 7 1 1)
|
|
721 96: OCTET STRING, encapsulates {
|
|
723 94: SEQUENCE {
|
|
725 92: SEQUENCE {
|
|
727 8: OBJECT IDENTIFIER caIssuers (1 3 6 1 5 5 7 48 2)
|
|
737 80: [6]
|
|
: 'rsync://rpki.example.net/repository/3ACE2CEF4F'
|
|
: 'B21B7D11E3E184EFC1E297B3778642.cer'
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
819 25: SEQUENCE {
|
|
821 8: OBJECT IDENTIFIER ipAddrBlocks (1 3 6 1 5 5 7 1 7)
|
|
831 1: BOOLEAN TRUE
|
|
834 10: OCTET STRING, encapsulates {
|
|
836 8: SEQUENCE {
|
|
838 6: SEQUENCE {
|
|
840 2: OCTET STRING 00 01
|
|
844 0: NULL
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
846 69: SEQUENCE {
|
|
848 8: OBJECT IDENTIFIER subjectInfoAccess
|
|
: (1 3 6 1 5 5 7 1 11)
|
|
858 57: OCTET STRING, encapsulates {
|
|
860 55: SEQUENCE {
|
|
862 53: SEQUENCE {
|
|
864 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 48 13'
|
|
874 41: [6]
|
|
: 'https://rrdp.example.net/notification.xml'
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
917 13: SEQUENCE {
|
|
919 9: OBJECT IDENTIFIER sha256WithRSAEncryption
|
|
: (1 2 840 113549 1 1 11)
|
|
930 0: NULL
|
|
: }
|
|
932 257: BIT STRING
|
|
: 48 C2 F7 C8 15 A7 43 1B EE E8 8A 68 7C A5 3F 4E
|
|
: 39 DE 6B 49 F8 09 0D D3 B7 EC 2B FA 86 C3 F7 BD
|
|
: D0 32 6F ED CA 75 86 F8 E3 E2 EC B7 B2 07 FB 3C
|
|
: 94 3B 70 A3 46 AE 0C 9B AB F9 44 D2 37 1E F8 04
|
|
: 60 56 36 E2 D8 1A F3 66 C5 80 9C 1F 38 E9 29 F0
|
|
: B2 4B 70 E9 C7 A7 6A 27 FA 03 0C 3A AB 4D 0D B2
|
|
: 90 1E A4 C0 5D D9 58 3F F6 C2 85 BC EC 09 15 53
|
|
: A0 35 CA A2 42 25 CF E6 B1 89 3D 60 5C 38 CB F9
|
|
: D9 AF FB 69 D8 DF 5F 0A 67 3A 28 E2 4C E8 0C 96
|
|
: 84 06 98 2D 93 3D 9A 72 75 92 A3 97 11 00 4D D1
|
|
: 44 42 CB 1A DF 7C 43 9E 5A 69 FB FA FD C6 E3 55
|
|
: 61 1B 51 70 2D FA A1 6A DA 54 0D E3 CC DE 85 EA
|
|
: B0 C4 F2 BF 31 B3 7C A5 21 25 73 E8 97 82 43 86
|
|
: 11 63 06 CC B2 38 DC FE D8 89 2C CE D9 63 12 1E
|
|
: E4 8A D8 CF 56 6D 37 A9 FF 48 4B 2C 24 0B 30 44
|
|
: 88 29 B3 61 21 0A DF C7 4B 6C 40 98 60 8E 86 05
|
|
: }
|
|
]]></sourcecode>
|
|
<t>
|
|
To allow reproduction of the signature results, the end-entity
|
|
private key is provided. For brevity, the other two private
|
|
keys are not.</t>
|
|
<sourcecode type=""><![CDATA[
|
|
-----BEGIN RSA PRIVATE KEY-----
|
|
MIIEpQIBAAKCAQEAsnE0Kzm/6gdlt4tyovD4QPwxFsootk4BqPaYAsDvZbCESOmW
|
|
/5Pmkollj/ZEnM5XEILTwlcK+toU0GQiKMATdAS9HCtP+ZNYpiXYuanTN57yrMDP
|
|
Ap6EddbwfKUBcK7mZq+caYV0bxPps7iVS4LtldbqZgV7lpaHsprnYellifhg48D1
|
|
zt0YlwXowazhTV4WhS3tPMuAz36/0v7VyTgZu0M0KbZmzy2LRn6a2LuOZYhRaqj/
|
|
eFHi6SEn13d+gChs6kxQnHNxFvZeVBRNTBS5Z6BKIKraC6CgAbdCJDhRingvxIHm
|
|
gXVi3uOvXXQva0H7ecOoOnJsRvmmA3SBAd+M6wIDAQABAoIBAQCyB0FeMuKm8bRo
|
|
18aKjFGSPEoZi53srIz5bvUgIi92TBLez7ZnzL6Iym26oJ+5th+lCHGO/dqlhXio
|
|
pI50C5Yc9TFbblb/ECOsuCuuqKFjZ8CD3GVsHozXKJeMM+/o5YZXQrORj6UnwT0z
|
|
ol/JE5pIGUCIgsXX6tz9s5BP3lUAvVQHsv6+vEVKLxQ3wj/1vIL8O/CN036EV0GJ
|
|
mpkwmygPjfECT9wbWo0yn3jxJb36+M/QjjUP28oNIVn/IKoPZRXnqchEbuuCJ651
|
|
IsaFSqtiThm4WZtvCH/IDq+6/dcMucmTjIRcYwW7fdHfjplllVPve9c/OmpWEQvF
|
|
t3ArWUt5AoGBANs4764yHxo4mctLIE7G7l/tf9bP4KKUiYw4R4ByEocuqMC4yhmt
|
|
MPCfOFLOQet71OWCkjP2L/7EKUe9yx7G5KmxAHY6jOjvcRkvGsl6lWFOsQ8p126M
|
|
Y9hmGzMOjtsdhAiMmOWKzjvm4WqfMgghQe+PnjjSVkgTt+7BxpIuGBAvAoGBANBg
|
|
26FF5cDLpixOd3Za1YXsOgguwCaw3Plvi7vUZRpa/zBMELEtyOebfakkIRWNm07l
|
|
nE+lAZwxm+29PTD0nqCFE91teyzjnQaLO5kkAdJiFuVV3icLOGo399FrnJbKensm
|
|
FGSli+3KxQhCNIJJfgWzq4bE0ioAMjdGbYXzIYQFAoGBAM6tuDJ36KDU+hIS6wu6
|
|
O2TPSfZhF/zPo3pCWQ78/QDb+Zdw4IEiqoBA7F4NPVLg9Y/H8UTx9r/veqe7hPOo
|
|
Ok7NpIzSmKTHkc5XfZ60Zn9OLFoKbaQ40a1kXoJdWEu2YROaUlAe9F6/Rog6PHYz
|
|
vLE5qscRbu0XQhLkN+z7bg5bAoGBAKDsbDEb/dbqbyaAYpmwhH2sdRSkphg7Niwc
|
|
DNm9qWa1J6Zw1+M87I6Q8naRREuU1IAVqqWHVLr/ROBQ6NTJ1Uc5/qFeT2XXUgkf
|
|
taMKv61tuyjZK3sTmznMh0HfzUpWjEhWnCEuB+ZYVdmO52ZGw2A75RdrILL2+9Dc
|
|
PvDXVubRAoGAdqXeSWoLxuzZXzl8rsaKrQsTYaXnOWaZieU1SL5vVe8nK257UDqZ
|
|
E3ng2j5XPTUWli+aNGFEJGRoNtcQvO60O/sFZUhu52sqq9mWVYZNh1TB5aP8X+pV
|
|
iFcZOLUvQEcN6PA+YQK5FU11rAI1M0Gm5RDnVnUl0L2xfCYxb7FzV6Y=
|
|
-----END RSA PRIVATE KEY-----
|
|
]]></sourcecode>
|
|
<t>
|
|
Signing of "192.0.2.0/24,US,WA,Seattle," (terminated by CR and LF) yields the
|
|
following detached CMS signature.</t>
|
|
<sourcecode type=""><![CDATA[
|
|
# RPKI Signature: 192.0.2.0 - 192.0.2.255
|
|
# MIIGjwYJKoZIhvcNAQcCoIIGgDCCBnwCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
|
|
# IhvcNAQkQAS+gggSpMIIEpTCCA42gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
|
|
# QwDQYJKoZIhvcNAQELBQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExR
|
|
# TNFMTg0RUZDMUUyOTdCMzc3ODY0MjAeFw0yMTA1MjAxNjA1NDVaFw0yMjAzMTYx
|
|
# NjA1NDVaMDMxMTAvBgNVBAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM
|
|
# 0NUFCRjA1M0ExODcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycT
|
|
# QrOb/qB2W3i3Ki8PhA/DEWyii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQg
|
|
# tPCVwr62hTQZCIowBN0BL0cK0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZm
|
|
# r5xphXRvE+mzuJVLgu2V1upmBXuWloeymudh6WWJ+GDjwPXO3RiXBejBrOFNXha
|
|
# FLe08y4DPfr/S/tXJOBm7QzQptmbPLYtGfprYu45liFFqqP94UeLpISfXd36AKG
|
|
# zqTFCcc3EW9l5UFE1MFLlnoEogqtoLoKABt0IkOFGKeC/EgeaBdWLe469ddC9rQ
|
|
# ft5w6g6cmxG+aYDdIEB34zrAgMBAAGjggGvMIIBqzAdBgNVHQ4EFgQUkUZSo71R
|
|
# wUQmAZiIn1xFq/BToYcwHwYDVR0jBBgwFoAUOs4s70+yG30R4+GE78Hil7N3hkI
|
|
# wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCB4AwGAYDVR0gAQH/BA4wDDAKBg
|
|
# grBgEFBQcOAjBhBgNVHR8EWjBYMFagVKBShlByc3luYzovL3Jwa2kuZXhhbXBsZ
|
|
# S5uZXQvcmVwb3NpdG9yeS8zQUNFMkNFRjRGQjIxQjdEMTFFM0UxODRFRkMxRTI5
|
|
# N0IzNzc4NjQyLmNybDBsBggrBgEFBQcBAQRgMF4wXAYIKwYBBQUHMAKGUHJzeW5
|
|
# jOi8vcnBraS5leGFtcGxlLm5ldC9yZXBvc2l0b3J5LzNBQ0UyQ0VGNEZCMjFCN0
|
|
# QxMUUzRTE4NEVGQzFFMjk3QjM3Nzg2NDIuY2VyMBkGCCsGAQUFBwEHAQH/BAowC
|
|
# DAGBAIAAQUAMEUGCCsGAQUFBwELBDkwNzA1BggrBgEFBQcwDYYpaHR0cHM6Ly9y
|
|
# cmRwLmV4YW1wbGUubmV0L25vdGlmaWNhdGlvbi54bWwwDQYJKoZIhvcNAQELBQA
|
|
# DggEBAEjC98gVp0Mb7uiKaHylP0453mtJ+AkN07fsK/qGw/e90DJv7cp1hvjj4u
|
|
# y3sgf7PJQ7cKNGrgybq/lE0jce+ARgVjbi2BrzZsWAnB846Snwsktw6cenaif6A
|
|
# ww6q00NspAepMBd2Vg/9sKFvOwJFVOgNcqiQiXP5rGJPWBcOMv52a/7adjfXwpn
|
|
# OijiTOgMloQGmC2TPZpydZKjlxEATdFEQssa33xDnlpp+/r9xuNVYRtRcC36oWr
|
|
# aVA3jzN6F6rDE8r8xs3ylISVz6JeCQ4YRYwbMsjjc/tiJLM7ZYxIe5IrYz1ZtN6
|
|
# n/SEssJAswRIgps2EhCt/HS2xAmGCOhgUxggGqMIIBpgIBA4AUkUZSo71RwUQmA
|
|
# ZiIn1xFq/BToYcwCwYJYIZIAWUDBAIBoGswGgYJKoZIhvcNAQkDMQ0GCyqGSIb3
|
|
# DQEJEAEvMBwGCSqGSIb3DQEJBTEPFw0yMTA1MjAxNjI4MzlaMC8GCSqGSIb3DQE
|
|
# JBDEiBCAr4vKeUvHJINsE0YQwUMxoo48qrOU+iPuFbQR8qX3BFjANBgkqhkiG9w
|
|
# 0BAQEFAASCAQB85HsCBrU3EcVOcf4nC6Z3jrOjT+fVlyTDAObF6GTNWgrxe7jSA
|
|
# Inyf51UzuIGqhVY3sQiiXbdWcVYtPb4118KvyeXh8A/HLp4eeAJntl9D3igt38M
|
|
# o84q5pf9pTQXx3hbsm51ilpOip/TKVMqzE42s6OPox3M0+6eKH3/vBKnw1s1ayM
|
|
# 0MUnPDTBfZL3JJEGPWfIZHEcrypevbqR7Jjsz5vp0qyF2D9v+w+nyhZOPmuePm7
|
|
# YqLyOw/E99PVBs9uI+hmBiCz/BK2Z3VRjrrlrUU+49eldSTkZ2sJyhCbbV2Ufgi
|
|
# S2FOquAgJzjilyN3BDQLV8Rp9cGh0PpVslKH2na
|
|
# End Signature: 192.0.2.0 - 192.0.2.255
|
|
]]></sourcecode>
|
|
</section>
|
|
|
|
<section anchor="ack" numbered="false" toc="default">
|
|
<name>Acknowledgments</name>
|
|
<t>
|
|
Thanks to <contact fullname="Rob Austein"/> for CMS and detached
|
|
signature clue, <contact fullname="George Michaelson"/> for the
|
|
first and substantial external review, and <contact
|
|
fullname="Erik Kline"/> who was too shy to agree to
|
|
coauthorship. Additionally, we express our gratitude to early
|
|
implementors, including <contact fullname="Menno Schepers"/>;
|
|
<contact fullname="Flavio Luciani"/>; <contact fullname="Eric
|
|
Dugas"/>; <contact fullname="Job Snijders"/>, who provided
|
|
running code; and <contact fullname="Kevin Pack"/>. Also,
|
|
thanks to the following geolocation providers who are consuming
|
|
geofeeds with this described solution: <contact
|
|
fullname="Jonathan Kosgei"/> (ipdata.co), <contact fullname="Ben
|
|
Dowling"/> (ipinfo.io), and <contact fullname="Pol Nisenblat"/>
|
|
(bigdatacloud.com). For an amazing number of helpful reviews,
|
|
we thank <contact fullname="Adrian Farrel"/>, <contact
|
|
fullname="Antonio Prado"/>, <contact fullname="Francesca
|
|
Palombini"/>, <contact fullname="Jean-Michel Combes"/> (INTDIR),
|
|
<contact fullname="John Scudder"/>, <contact fullname="Kyle
|
|
Rose"/> (SECDIR), <contact fullname="Martin Duke"/>, <contact
|
|
fullname="Murray Kucherawy"/>, <contact fullname="Paul
|
|
Kyzivat"/> (GENART), <contact fullname="Rob Wilton"/>, and
|
|
<contact fullname="Roman Danyliw"/>. The authors also thank
|
|
<contact fullname="George Michaelson"/>, the awesome document
|
|
shepherd.
|
|
</t>
|
|
</section>
|
|
|
|
</back>
|
|
</rfc>
|