1085 lines
51 KiB
XML
1085 lines
51 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, an Update">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. Currently, this has been
|
|
implemented in only the RIPE Database. 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: 2001:db8::/32
|
|
# MIIGLgYJKoZIhvcNAQcCoIIGHzCCBhsCAQMxDTALBglghkgBZQMEAgEwDQYLKoZI
|
|
# hvcNAQkQAS+gggRIMIIERDCCAyygAwIBAgIBADANBgkqhkiG9w0BAQsFADAzMTEw
|
|
...
|
|
# oD+3aK++ef1zZdMXuyn7qE/z2ITT+98MY+GVIouFrL7+tMKOj8rhCnvZtlkrv9lz
|
|
# RvA=
|
|
# End Signature: 2001:db8::/32
|
|
]]></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-----
|
|
MIIDzTCCArWgAwIBAgIBATANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDDApleGFt
|
|
cGxlLXRhMB4XDTIyMTIwNzEwMTkxNFoXDTMyMTIwNDEwMTkxNFowFTETMBEGA1UE
|
|
AwwKZXhhbXBsZS10YTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMdb
|
|
hyqTPhg4o1dG+TfogdLiiDVGi56jVcrjMt3umDfcdup5NuDu3l5tJQlXSIe3NmwB
|
|
3jjuE0YV1sqIqbt7tflnA8MFczOrrn12I8WHi6Gy23n1x0bw96hmHXgXcJfOohS9
|
|
ktR2Y3BKIjvfjK7ru7ojFMCGEq/wtZkjA9mYN9TG0FUXLR08OXs9/xRefiLomNuP
|
|
wGp27NPx3/lV2AmeBtLJYdDXpmBoXO4vQ1FdFHNQuZ9SxE22SOTX/Ow1uUtLZf6L
|
|
3PkFU/KJyuUqUckzpVMqNzZmhQWt3CpiYh3kBARGosbU5xVbZoFmAyhDh6xZhvCc
|
|
UQ79m/aUOCaStUJxRqsCAwEAAaOCASYwggEiMA8GA1UdEwEB/wQFMAMBAf8wHQYD
|
|
VR0OBBYEFMQZWCDkIcMYkD1pYn8h16RoGd/YMA4GA1UdDwEB/wQEAwIBBjB6Bggr
|
|
BgEFBQcBCwRuMGwwMAYIKwYBBQUHMAWGJHJzeW5jOi8vcnBraS5leGFtcGxlLm5l
|
|
dC9yZXBvc2l0b3J5LzA4BggrBgEFBQcwCoYscnN5bmM6Ly9ycGtpLmV4YW1wbGUu
|
|
bmV0L3JlcG9zaXRvcnkvcm9vdC5tZnQwGAYDVR0gAQH/BA4wDDAKBggrBgEFBQcO
|
|
AjAhBggrBgEFBQcBCAEB/wQSMBCgDjAMMAoCAQACBQD/////MCcGCCsGAQUFBwEH
|
|
AQH/BBgwFjAJBAIAATADAwEAMAkEAgACMAMDAQAwDQYJKoZIhvcNAQELBQADggEB
|
|
ABQi1zxIoHao95LHXrn2dZVoIS3ZcHxcHIAvjXO0gr1F9P+ydTpurm0G02G3bwL0
|
|
58pirQYG7dRecSdU6GEk07FOwmYpwYFx9DgkLuok4w9PdYvIDOwP6Rv3EWR7CxbW
|
|
kcHpOy+eMyIwbX+90z7tajJWK6aAUI/AEjQFL6P7hBqodujpgMoUu8u2FImslhYK
|
|
vKHXgSMMiBin6/IiMiZKcWsUoxtcL8ZECFyPXQieuyRGubPg9Q6lAPYMrJ8WqngH
|
|
GmOy5TmbIHhxz5Aej/7lqXIRcoIHh7e+P0dPWSrdTS+zhJhdKTOW+Ctpf1dXXfX+
|
|
vXXiZtI/UPe3iyRVQeErym0=
|
|
-----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), one IPv6 address block (2001:db8::/32),
|
|
and one AS numbers (64496).</t>
|
|
<sourcecode type=""><![CDATA[
|
|
-----BEGIN CERTIFICATE-----
|
|
MIIEojCCA4qgAwIBAgIBADANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDDApleGFt
|
|
cGxlLXRhMB4XDTIyMTIwNzEwMTkxNVoXDTI0MTIwNjEwMTkxNVowMzExMC8GA1UE
|
|
AwwoM0M2QjMzRTU3MDlDMDczQTg2OEM5NUQ5NTVCMEY1NkUzNzgyMUQ3QjCCASIw
|
|
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL7A4NZ/AgbMO8SJIlYWlC+rL8AC
|
|
N5jHzuHGlKsXsTjKg4Pwlq2O02VfroMi4LOe9jnNR/JTt3YAer+lHAFdB4XBHQgM
|
|
Es/JfSdSfNEZrwkrZ9rTiY21c3naSPj64HeXmTxl4Z0eTQKhPoiKgG582lCubdO6
|
|
ws6FZTeS91sXUY8VH9pP+W+e5Xs8YYkCl3co9N0voOaUjpjexZ5Nrx2dJIUf0MGz
|
|
j7Ncagd2vXU47GduTRtW/cSDLMigl0oAUh/Coa4KcbL6fTyoe39LNGfkFlIkkdGG
|
|
gYQFNxWkfCLZTHM/VjVbkomJoEM0vnQa0xGMt+aUHP1jRCoF+UF1z57wTV0CAwEA
|
|
AaOCAd0wggHZMB0GA1UdDgQWBBQ4FgEDRqNA4XXaFVAKyLrqmhhO/DAfBgNVHSME
|
|
GDAWgBTEGVgg5CHDGJA9aWJ/IdekaBnf2DAPBgNVHRMBAf8EBTADAQH/MA4GA1Ud
|
|
DwEB/wQEAwIBBjBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMnJzeW5jOi8v
|
|
cnBraS5leGFtcGxlLm5ldC9yZXBvc2l0b3J5L2V4YW1wbGUtdGEuY2VyMIGABggr
|
|
BgEFBQcBCwR0MHIwMAYIKwYBBQUHMAWGJHJzeW5jOi8vcnBraS5leGFtcGxlLm5l
|
|
dC9yZXBvc2l0b3J5LzA+BggrBgEFBQcwCoYycnN5bmM6Ly9ycGtpLmV4YW1wbGUu
|
|
bmV0L3JlcG9zaXRvcnkvZXhhbXBsZS1jYS5tZnQwPQYDVR0fBDYwNDAyoDCgLoYs
|
|
cnN5bmM6Ly9ycGtpLmV4YW1wbGUubmV0L3JlcG9zaXRvcnkvcm9vdC5jcmwwGAYD
|
|
VR0gAQH/BA4wDDAKBggrBgEFBQcOAjAaBggrBgEFBQcBCAEB/wQLMAmgBzAFAgMA
|
|
+/AwLgYIKwYBBQUHAQcBAf8EHzAdMAwEAgABMAYDBADAAAIwDQQCAAIwBwMFACAB
|
|
DbgwDQYJKoZIhvcNAQELBQADggEBACU1s/+CGThdasY1e5E4o3La2y94Leb5EPzO
|
|
51ARVinKkJSmmDJWtTTUlZnGHV0Tggp7uN/CVSPu5dWrt7zEHa+Tycwe2r6Mz3BM
|
|
IPGI0RUKKebS9lSnEWFn01u2TrM7gEBe8X6fF55qoH8pnut7d5N1V+CnAd6720zf
|
|
ob/MENQ4r4ZU6pVj2c3R0MLLEX/rz1wbr/f7N1Cjij0vnTHHD+ViqgJO+ZxboYOn
|
|
RZFPG3uQM5xBKH36a32ON4B5xUb9DDdOOlXqbmW7BUDXgUSN1MheuXgCVExuxTTn
|
|
MF+ONSJCk8UqgGA7TlXusYO8wygQQgZLUGq6a8Ls6oYF7UJlvB4=
|
|
-----END CERTIFICATE-----
|
|
]]></sourcecode>
|
|
|
|
<t>
|
|
The CRL 'root.crl' referenced by the above CA certificate.</t>
|
|
<sourcecode type=""><![CDATA[
|
|
-----BEGIN X509 CRL-----
|
|
MIIBgjBsAgEBMA0GCSqGSIb3DQEBCwUAMBUxEzARBgNVBAMMCmV4YW1wbGUtdGEX
|
|
DTIyMTIwNzEwMTkxNFoXDTIyMTIwOTEwMTkxNFqgIzAhMB8GA1UdIwQYMBaAFMQZ
|
|
WCDkIcMYkD1pYn8h16RoGd/YMA0GCSqGSIb3DQEBCwUAA4IBAQC5r9IizRpG6Epw
|
|
w2S03J8iLaJyxWT7anAweZO0KS7XbjuD5ZgrPd3O4UZ9kDs9G1RxVR1wfLYU6caI
|
|
BydGYr/n5ClRUq+4d4+0GxfJT4QcIT7/MSHupHywY/GsJFPWMzkox2it+TRt0S+a
|
|
W0o7d8Cs0beTJKAwTvPsx+vPzJaQvoo44pgKfKsvTbvMi9RY2T8ktU7y03M/yMkF
|
|
Oo0Q5XF1TEnPlSd+pkhVBH1BDzYLJSGI4wPMLI7CO7evkD9dQlCX0JHhGw4NOl8W
|
|
w/Ln909WZIbntBF5uER23KFhdRkrkMTN7fkTULXbVQlEANQmdd2QUvjEmGnZo+Ln
|
|
ltXaR53q
|
|
-----END X509 CRL-----
|
|
]]></sourcecode>
|
|
|
|
<t>
|
|
The CRL '3C6B33E5709C073A868C95D955B0F56E37821D7B.crl' referenced by
|
|
the below EE certificate.</t>
|
|
<sourcecode type=""><![CDATA[
|
|
-----BEGIN X509 CRL-----
|
|
MIIBoTCBigIBATANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDDCgzQzZCMzNFNTcw
|
|
OUMwNzNBODY4Qzk1RDk1NUIwRjU2RTM3ODIxRDdCFw0yMjEyMDcxMDE5MTVaFw0y
|
|
MjEyMDkxMDE5MTVaoCMwITAfBgNVHSMEGDAWgBQ4FgEDRqNA4XXaFVAKyLrqmhhO
|
|
/DANBgkqhkiG9w0BAQsFAAOCAQEAJysjVqBT8CgYA2PHdtGOeNR17Qz70yp2yBn3
|
|
plfdEvRHc2mtyuWt1uUNkCeZCninNhyAQi+In7az42rNomWYUBoqzQAAEmvxwgkA
|
|
zM0Mnt9nbWO00coUl4+tx61LArUMq7EYXWX8Bi49O2jBUZ23+HL+ViXVbZzI5nYQ
|
|
SZ3o7pN28on6dNgJs1NyfAJ6RjeIc5d11JpFgWIu9zIGkS1kCK3+HghOvKPlug94
|
|
De/pWbK7PwHXPKSxrsLef12ZWTAaRS6ceCmd58ng8agHb3rUuPMlOyLQA/6kM7DL
|
|
KJT4BxPuo9wA0zJyTWOy+7aiZ9YbxGRkzTL5VUe9eLj1oQbLGg==
|
|
-----END X509 CRL-----
|
|
]]></sourcecode>
|
|
|
|
<t>
|
|
The end-entity certificate is displayed below in detail. For
|
|
brevity, the other two certificates are not.
|
|
</t>
|
|
<sourcecode type=""><![CDATA[
|
|
0:d=0 hl=4 l=1092 cons: SEQUENCE
|
|
4:d=1 hl=4 l= 812 cons: SEQUENCE
|
|
8:d=2 hl=2 l= 3 cons: cont [ 0 ]
|
|
10:d=3 hl=2 l= 1 prim: INTEGER :02
|
|
13:d=2 hl=2 l= 1 prim: INTEGER :00
|
|
16:d=2 hl=2 l= 13 cons: SEQUENCE
|
|
18:d=3 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption
|
|
29:d=3 hl=2 l= 0 prim: NULL
|
|
31:d=2 hl=2 l= 51 cons: SEQUENCE
|
|
33:d=3 hl=2 l= 49 cons: SET
|
|
35:d=4 hl=2 l= 47 cons: SEQUENCE
|
|
37:d=5 hl=2 l= 3 prim: OBJECT :commonName
|
|
42:d=5 hl=2 l= 40 prim: UTF8STRING :3C6B33E5709C073A868C95D955B0F56E37821D7B
|
|
84:d=2 hl=2 l= 30 cons: SEQUENCE
|
|
86:d=3 hl=2 l= 13 prim: UTCTIME :221207101915Z
|
|
101:d=3 hl=2 l= 13 prim: UTCTIME :231207101915Z
|
|
116:d=2 hl=2 l= 51 cons: SEQUENCE
|
|
118:d=3 hl=2 l= 49 cons: SET
|
|
120:d=4 hl=2 l= 47 cons: SEQUENCE
|
|
122:d=5 hl=2 l= 3 prim: OBJECT :commonName
|
|
127:d=5 hl=2 l= 40 prim: UTF8STRING :BAB90687EB8CC6BA4D9F455D3FD4FA37C0C372C6
|
|
169:d=2 hl=4 l= 290 cons: SEQUENCE
|
|
173:d=3 hl=2 l= 13 cons: SEQUENCE
|
|
175:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption
|
|
186:d=4 hl=2 l= 0 prim: NULL
|
|
188:d=3 hl=4 l= 271 prim: BIT STRING
|
|
0000 - 00 30 82 01 0a 02 82 01-01 00 ad 90 8a 95 f4 72 .0.............r
|
|
0010 - c8 86 b7 8e e3 46 f2 68-b9 41 82 e5 ca 21 68 a0 .....F.h.A...!h.
|
|
0020 - 38 17 96 c8 9e a8 81 c2-c0 78 c6 a7 51 21 94 28 8........x..Q!.(
|
|
0030 - 03 97 7a 50 d6 18 1f 87-ef 28 5d 31 41 65 8e 42 ..zP.....(]1Ae.B
|
|
0040 - 52 44 5a d6 d6 3d 9b 53-a8 03 1e 7e ad b5 0d 84 RDZ..=.S...~....
|
|
0050 - 77 ed 92 60 05 2b aa b0-58 a3 ee b6 5f 6b cd 04 w..`.+..X..._k..
|
|
0060 - 55 3a 71 40 a9 ae eb a1-85 be c9 3c a8 98 bd 14 U:q@.......<....
|
|
0070 - 28 c6 b0 fd 3d 8c 7f 5d-80 62 0a c5 13 ab 9a 1c (...=..].b......
|
|
0080 - e4 1e d9 eb 51 61 ba 66-f9 41 82 49 d1 18 35 bc ....Qa.f.A.I..5.
|
|
0090 - 83 a0 5a 09 07 f0 13 3d-92 19 c4 28 26 f2 06 1e ..Z....=...(&...
|
|
00a0 - 34 90 73 79 8f 18 a5 a2-11 f6 a8 36 e5 eb 02 82 4.sy.......6....
|
|
00b0 - 40 58 c7 2c f0 2f 20 9e-a2 ab 95 8d 13 cc f0 5b @X.,./ ........[
|
|
00c0 - 35 62 67 7f 77 41 5f b4-df f0 73 0c 25 e5 45 eb 5bg.wA_...s.%.E.
|
|
00d0 - 7c 60 52 ca 23 36 e1 0a-ae 54 5f 44 ca fe fe a8 |`R.#6...T_D....
|
|
00e0 - 77 21 ec b8 9b 36 b7 d0-7e 30 7f e1 02 2c cf 37 w!...6..~0...,.7
|
|
00f0 - 17 1a b7 30 c2 e5 ef 3b-e6 1c c5 be ce d3 f4 13 ...0...;........
|
|
0100 - 53 8c a5 66 54 c2 96 a3-37 05 02 03 01 00 01 S..fT...7......
|
|
463:d=2 hl=4 l= 353 cons: cont [ 3 ]
|
|
467:d=3 hl=4 l= 349 cons: SEQUENCE
|
|
471:d=4 hl=2 l= 29 cons: SEQUENCE
|
|
473:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Identifier
|
|
478:d=5 hl=2 l= 22 prim: OCTET STRING
|
|
0000 - 04 14 07 e9 9a fe a1 8e-1c b6 e1 5c 2d d6 b8 8a ...........\-...
|
|
0010 - 7e b8 1c 7d 83 c0 ~..}..
|
|
502:d=4 hl=2 l= 31 cons: SEQUENCE
|
|
504:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Authority Key Identifier
|
|
509:d=5 hl=2 l= 24 prim: OCTET STRING
|
|
0000 - 30 16 80 14 38 16 01 03-46 a3 40 e1 75 da 15 50 0...8...F.@.u..P
|
|
0010 - 0a c8 ba ea 9a 18 4e fc- ......N.
|
|
535:d=4 hl=2 l= 24 cons: SEQUENCE
|
|
537:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Certificate Policies
|
|
542:d=5 hl=2 l= 1 prim: BOOLEAN :255
|
|
545:d=5 hl=2 l= 14 prim: OCTET STRING
|
|
0000 - 30 0c 30 0a 06 08 2b 06-01 05 05 07 0e 02 0.0...+.......
|
|
561:d=4 hl=2 l= 97 cons: SEQUENCE
|
|
563:d=5 hl=2 l= 3 prim: OBJECT :X509v3 CRL Distribution Points
|
|
568:d=5 hl=2 l= 90 prim: OCTET STRING
|
|
0000 - 30 58 30 56 a0 54 a0 52-86 50 72 73 79 6e 63 3a 0X0V.T.R.Prsync:
|
|
0010 - 2f 2f 72 70 6b 69 2e 65-78 61 6d 70 6c 65 2e 6e //rpki.example.n
|
|
0020 - 65 74 2f 72 65 70 6f 73-69 74 6f 72 79 2f 33 43 et/repository/3C
|
|
0030 - 36 42 33 33 45 35 37 30-39 43 30 37 33 41 38 36 6B33E5709C073A86
|
|
0040 - 38 43 39 35 44 39 35 35-42 30 46 35 36 45 33 37 8C95D955B0F56E37
|
|
0050 - 38 32 31 44 37 42 2e 63-72 6c 821D7B.crl
|
|
660:d=4 hl=2 l= 108 cons: SEQUENCE
|
|
662:d=5 hl=2 l= 8 prim: OBJECT :Authority Information Access
|
|
672:d=5 hl=2 l= 96 prim: OCTET STRING
|
|
0000 - 30 5e 30 5c 06 08 2b 06-01 05 05 07 30 02 86 50 0^0\..+.....0..P
|
|
0010 - 72 73 79 6e 63 3a 2f 2f-72 70 6b 69 2e 65 78 61 rsync://rpki.exa
|
|
0020 - 6d 70 6c 65 2e 6e 65 74-2f 72 65 70 6f 73 69 74 mple.net/reposit
|
|
0030 - 6f 72 79 2f 33 43 36 42-33 33 45 35 37 30 39 43 ory/3C6B33E5709C
|
|
0040 - 30 37 33 41 38 36 38 43-39 35 44 39 35 35 42 30 073A868C95D955B0
|
|
0050 - 46 35 36 45 33 37 38 32-31 44 37 42 2e 63 65 72 F56E37821D7B.cer
|
|
770:d=4 hl=2 l= 14 cons: SEQUENCE
|
|
772:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage
|
|
777:d=5 hl=2 l= 1 prim: BOOLEAN :255
|
|
780:d=5 hl=2 l= 4 prim: OCTET STRING
|
|
0000 - 03 02 07 80 ....
|
|
786:d=4 hl=2 l= 32 cons: SEQUENCE
|
|
788:d=5 hl=2 l= 8 prim: OBJECT :sbgp-ipAddrBlock
|
|
798:d=5 hl=2 l= 1 prim: BOOLEAN :255
|
|
801:d=5 hl=2 l= 17 prim: OCTET STRING
|
|
0000 - 30 0f 30 0d 04 02 00 02-30 07 03 05 00 20 01 0d 0.0.....0.... ..
|
|
0010 - b8 .
|
|
820:d=1 hl=2 l= 13 cons: SEQUENCE
|
|
822:d=2 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption
|
|
833:d=2 hl=2 l= 0 prim: NULL
|
|
835:d=1 hl=4 l= 257 prim: BIT STRING
|
|
0000 - 00 7f 98 3a d7 0d 44 2b-0c ec 55 53 40 72 fc c4 ...:..D+..US@r..
|
|
0010 - f6 4e 7b b9 09 70 73 8d-e2 69 77 af 56 84 56 d4 .N{..ps..iw.V.V.
|
|
0020 - 5e 06 4b 57 81 54 29 a5-d4 e6 47 25 a8 65 58 41 ^.KW.T)...G%.eXA
|
|
0030 - e3 5d 36 5e 6c 13 d1 f9-54 af b8 4d 5f 8b 42 06 .]6^l...T..M_.B.
|
|
0040 - f8 c3 b1 7f 10 11 b5 11-62 8b 57 36 15 f1 63 59 ........b.W6..cY
|
|
0050 - e1 e0 64 16 5a 1e de 23-01 51 08 ef e4 c4 65 51 ..d.Z..#.Q....eQ
|
|
0060 - 71 80 2e 7b 92 3e 3d 2b-ad 82 61 13 dd e3 a9 17 q..{.>=+..a.....
|
|
0070 - 10 69 1e 12 4f 54 e2 74-a0 b2 f9 59 37 0e 3c ea .i..OT.t...Y7.<.
|
|
0080 - 66 a4 2f 97 5b ea 5b 90-ea 59 06 c8 9e 87 f4 cb f./.[.[..Y......
|
|
0090 - b2 24 62 24 f2 10 9c 79-85 0e 05 90 21 52 4a 76 .$b$...y....!RJv
|
|
00a0 - 0e 24 0d f5 72 bd 8a 7c-94 44 31 86 1f 20 bb 02 .$..r..|.D1.. ..
|
|
00b0 - 96 d7 29 bd fc 03 b2 28-94 65 97 28 a7 00 96 4a ..)....(.e.(...J
|
|
00c0 - a0 31 76 f0 03 e3 d0 f6-af 99 4a bb d0 16 d7 e5 .1v.......J.....
|
|
00d0 - e0 0c 0e e1 1f e6 84 fc-b1 0f f9 ff c9 72 12 af .............r..
|
|
00e0 - 52 07 9d 18 88 34 49 0e-34 0f fb 69 9d 26 1e 27 R....4I.4..i.&.'
|
|
00f0 - 1b 59 c9 63 60 b3 6a 8b-25 01 42 e5 aa 7d 5b 16 .Y.c`.j.%.B..}[.
|
|
0100 - 48 H
|
|
]]></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-----
|
|
MIIEpAIBAAKCAQEArZCKlfRyyIa3juNG8mi5QYLlyiFooDgXlsieqIHCwHjGp1Eh
|
|
lCgDl3pQ1hgfh+8oXTFBZY5CUkRa1tY9m1OoAx5+rbUNhHftkmAFK6qwWKPutl9r
|
|
zQRVOnFAqa7roYW+yTyomL0UKMaw/T2Mf12AYgrFE6uaHOQe2etRYbpm+UGCSdEY
|
|
NbyDoFoJB/ATPZIZxCgm8gYeNJBzeY8YpaIR9qg25esCgkBYxyzwLyCeoquVjRPM
|
|
8Fs1Ymd/d0FftN/wcwwl5UXrfGBSyiM24QquVF9Eyv7+qHch7LibNrfQfjB/4QIs
|
|
zzcXGrcwwuXvO+Ycxb7O0/QTU4ylZlTClqM3BQIDAQABAoIBAHDMX0TVeUOZSfIz
|
|
AwjHxp4s0+ppi/WUfsAf4fzhWBB+bZyPvaLr3mmztJVvWA6f/zuRp065BaExi1fU
|
|
JHWuCKL+TpXV9NMCngNjI/kdFT6GS716hjTXfAxfTgb5B2oR4cwm/+tD9rYJaz0p
|
|
owWjXqxZE3uVKrNcDjDSHjHFUubp+b/Pge/Ygsh31uzI5vBX8zxz/GhfqwFBYXLz
|
|
VPf1AsX0M4NtvgyoFtnKxrXhltQuGCTX12BL/DVxEyYiWrTgDdUc53pLQ4Kd/s7I
|
|
f36ZRxsQVQtFwXkDojnqB7aSNyXZz/X5d8UNT7EYrJV6xDePeJAHpzm+wu16xnrN
|
|
vgnbkIECgYEA3n8is+zhh0G1wOLgQ6X1Os5BXbNPwBO+v55fGDXExNuymkkDmvRy
|
|
Z2adIGGAX57FucTQu3sf3Qelq8GKVImKieEuJFexPiGDjaL+kt5PEzMEFGak6dZk
|
|
O+kc4iPjpHDHva+pADlTGZkgRURMu4FYMWWIMhqabfIaC3puRUBcMAcCgYEAx7Mp
|
|
F4vSaTnwEOqXrKCoxjgFmlYzdltoSS31rRZeMskUCkuJukrVnYHTgt1ZAVYwN/1x
|
|
caxphuQyrUubug5Sf9S8Xh6up+LV1mLqeB2C1Rf7sXnswe5RDUP3pmnNKl55Kx0Y
|
|
qKbJIXuTqgPX8RHy/dfYa3o6UK3RsBpTAq1AhZMCgYBa8dSZfuXgh3dnVFUe0aMf
|
|
WldVmYmrlWaOpIlyN+gqHzMt5VJX8DsjEMqBBdmXPCrN+CjpuTYY/ps1TXLhgybh
|
|
nO1jZYTJRKGlL06ncb8Yte2g+SPHgR6PboWj2c+e04qRek+2C7hv6itKpNRIgGIw
|
|
LrQw5rbg4ejLcEvKergz2QKBgQDCmIz0SuXQcArFETSXnT6ZWUHscQ9YyB3JIaYC
|
|
8ob8SgDjP1SIWh/qifYH0ZXHvarjBG8la/Kw5XGUeNbY6NfvhOfBd3iOVHY3oNAG
|
|
GAvDhslW2g6hs477tD2AxhyMqt676nB693uKyxbLV093tBvqzAgyQzrMH3Tze9Nk
|
|
CluTTQKBgQCpwcrHmOB8+jZhwjz1tEfGdgJWylxeIc0so799joTK7NoUCsUdPstx
|
|
Xvnfrz/l2zu5mZDg5KnOgv6rT9Dq6Ks4sYoYcvGv/rY8gZSIakWPwjktNkwr/uhW
|
|
cy8osak23bfcGfgNsjgE2kOZlu92TwmT8ANOtDao8dvdeUPQKMxErQ==
|
|
-----END RSA PRIVATE KEY-----
|
|
]]></sourcecode>
|
|
|
|
<t>
|
|
Signing of the two lines "2001:db8::/32,NL,,," and
|
|
"2001:db8::/48,NL,NL-NH,Amsterdam," (both terminated by CR and LF)
|
|
yields the following detached CMS signature.</t>
|
|
<sourcecode type=""><![CDATA[
|
|
# RPKI Signature: 2001:db8::/32
|
|
# MIIGLgYJKoZIhvcNAQcCoIIGHzCCBhsCAQMxDTALBglghkgBZQMEAgEwDQYLKoZI
|
|
# hvcNAQkQAS+gggRIMIIERDCCAyygAwIBAgIBADANBgkqhkiG9w0BAQsFADAzMTEw
|
|
# LwYDVQQDDCgzQzZCMzNFNTcwOUMwNzNBODY4Qzk1RDk1NUIwRjU2RTM3ODIxRDdC
|
|
# MB4XDTIyMTIwNzEwMTkxNVoXDTIzMTIwNzEwMTkxNVowMzExMC8GA1UEAwwoQkFC
|
|
# OTA2ODdFQjhDQzZCQTREOUY0NTVEM0ZENEZBMzdDMEMzNzJDNjCCASIwDQYJKoZI
|
|
# hvcNAQEBBQADggEPADCCAQoCggEBAK2QipX0csiGt47jRvJouUGC5cohaKA4F5bI
|
|
# nqiBwsB4xqdRIZQoA5d6UNYYH4fvKF0xQWWOQlJEWtbWPZtTqAMefq21DYR37ZJg
|
|
# BSuqsFij7rZfa80EVTpxQKmu66GFvsk8qJi9FCjGsP09jH9dgGIKxROrmhzkHtnr
|
|
# UWG6ZvlBgknRGDW8g6BaCQfwEz2SGcQoJvIGHjSQc3mPGKWiEfaoNuXrAoJAWMcs
|
|
# 8C8gnqKrlY0TzPBbNWJnf3dBX7Tf8HMMJeVF63xgUsojNuEKrlRfRMr+/qh3Iey4
|
|
# mza30H4wf+ECLM83Fxq3MMLl7zvmHMW+ztP0E1OMpWZUwpajNwUCAwEAAaOCAWEw
|
|
# ggFdMB0GA1UdDgQWBBQH6Zr+oY4ctuFcLda4in64HH2DwDAfBgNVHSMEGDAWgBQ4
|
|
# FgEDRqNA4XXaFVAKyLrqmhhO/DAYBgNVHSABAf8EDjAMMAoGCCsGAQUFBw4CMGEG
|
|
# A1UdHwRaMFgwVqBUoFKGUHJzeW5jOi8vcnBraS5leGFtcGxlLm5ldC9yZXBvc2l0
|
|
# b3J5LzNDNkIzM0U1NzA5QzA3M0E4NjhDOTVEOTU1QjBGNTZFMzc4MjFEN0IuY3Js
|
|
# MGwGCCsGAQUFBwEBBGAwXjBcBggrBgEFBQcwAoZQcnN5bmM6Ly9ycGtpLmV4YW1w
|
|
# bGUubmV0L3JlcG9zaXRvcnkvM0M2QjMzRTU3MDlDMDczQTg2OEM5NUQ5NTVCMEY1
|
|
# NkUzNzgyMUQ3Qi5jZXIwDgYDVR0PAQH/BAQDAgeAMCAGCCsGAQUFBwEHAQH/BBEw
|
|
# DzANBAIAAjAHAwUAIAENuDANBgkqhkiG9w0BAQsFAAOCAQEAf5g61w1EKwzsVVNA
|
|
# cvzE9k57uQlwc43iaXevVoRW1F4GS1eBVCml1OZHJahlWEHjXTZebBPR+VSvuE1f
|
|
# i0IG+MOxfxARtRFii1c2FfFjWeHgZBZaHt4jAVEI7+TEZVFxgC57kj49K62CYRPd
|
|
# 46kXEGkeEk9U4nSgsvlZNw486makL5db6luQ6lkGyJ6H9MuyJGIk8hCceYUOBZAh
|
|
# Ukp2DiQN9XK9inyURDGGHyC7ApbXKb38A7IolGWXKKcAlkqgMXbwA+PQ9q+ZSrvQ
|
|
# Ftfl4AwO4R/mhPyxD/n/yXISr1IHnRiINEkONA/7aZ0mHicbWcljYLNqiyUBQuWq
|
|
# fVsWSDGCAaowggGmAgEDgBQH6Zr+oY4ctuFcLda4in64HH2DwDALBglghkgBZQME
|
|
# AgGgazAaBgkqhkiG9w0BCQMxDQYLKoZIhvcNAQkQAS8wHAYJKoZIhvcNAQkFMQ8X
|
|
# DTIyMTIwNzEwMTkxNVowLwYJKoZIhvcNAQkEMSIEIHHgork/z1WyatmZx/c9FGUG
|
|
# +Ev7SDajfxTeQwmQwS9xMA0GCSqGSIb3DQEBAQUABIIBAHOegVJi2amezico1ivI
|
|
# EbouVZG7nfzY+Ym3i+rXzqIGLAuvtpFxtorCvr35wctPW27G5ux1Rx9cdmaxJEsl
|
|
# NAPPSlUCktzb4lo+FF2t2gXG47Ly8WotYn1oOK0c3Veh2GTvwU0fH+/cmhXf93ol
|
|
# X91of7RxKDlZKWvDOzx6VH1hfRcVW2754HR67IRQpRH5uQbIMONbEpVsahanmXhU
|
|
# TE7STNdO3CQPuZYafNfdqBbfnKqjvru23qxtyaY/cH0g+7fX9KWxmxD3VsFhIDIP
|
|
# oD+3aK++ef1zZdMXuyn7qE/z2ITT+98MY+GVIouFrL7+tMKOj8rhCnvZtlkrv9lz
|
|
# RvA=
|
|
# End Signature: 2001:db8::/32
|
|
]]></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>
|