1353 lines
57 KiB
XML
1353 lines
57 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-ietf-opsawg-9092-update-09"
|
|
submissionType="IETF" consensus="true" ipr="trust200902"
|
|
obsoletes="9092" version="2" >
|
|
|
|
<front>
|
|
|
|
<title abbrev="Finding and Using Geofeed Data">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>Veemweg 23</street>
|
|
<city>Barneveld</city>
|
|
<code>3771 MT</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>
|
|
<keyword>inetnum</keyword>
|
|
|
|
<abstract>
|
|
<t>
|
|
This document specifies how to augment the Routing Policy
|
|
Specification Language inetnum: class to refer specifically to
|
|
geofeed comma-separated values (CSV) data files and describes an
|
|
optional scheme that uses the Resource Public Key Infrastructure
|
|
to authenticate the geofeed data files. This document obsoletes
|
|
RFC 9092.
|
|
</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, which may not point to a
|
|
user, see <xref target ="RFC6269"/>, Section 14 in particular.
|
|
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 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 in <xref
|
|
target="auth"/>.
|
|
</t>
|
|
<t>
|
|
This document obsoletes <xref target="RFC9092"/>. Changes from
|
|
<xref target="RFC9092"/> include the following:
|
|
<ul spacing="compact">
|
|
<li>
|
|
RIPE has implemented the geofeed: attribute.
|
|
</li>
|
|
<li>
|
|
Allow, but discourage, an inetnum: to have both a geofeed
|
|
remarks: attribute and a geofeed: attribute.
|
|
</li>
|
|
<li>
|
|
Rewrite Authentication <xref target="auth"/> to be more
|
|
formal.
|
|
</li>
|
|
<li>
|
|
Geofeed file only UTF-8 CSV.
|
|
</li>
|
|
<li>
|
|
Stress that authenticating geofeed data is optional.
|
|
</li>
|
|
<li>
|
|
IP Address Delegation extensions must not use "inherit".
|
|
</li>
|
|
<li>
|
|
If geofeed data are present, ignore geographic location
|
|
hints in other data.
|
|
</li>
|
|
</ul>
|
|
|
|
</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>
|
|
Per <xref target="RFC8805"/>, geofeed files consist of CSVs
|
|
(Comma Separated Values) in UTF-8 text format; not HTML,
|
|
richtext, or other formats.
|
|
</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"/>. At the time of publishing this document,
|
|
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. Absent implementation of the
|
|
geofeed: attribute in a particular RIR database, 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 MUST be as in this example,
|
|
"remarks: Geofeed ", where the token "Geofeed " MUST be case
|
|
sensitive, followed by a URL that will vary, but it MUST refer
|
|
only to a single geofeed <xref target="RFC8805"
|
|
format="default"/> file.
|
|
</t>
|
|
|
|
<sourcecode type="rpsl"> <![CDATA[
|
|
inetnum: 192.0.2.0/24 # example
|
|
remarks: Geofeed https://example.com/geofeed
|
|
]]></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 MUST be "geofeed:" and
|
|
MUST be followed by a single URL that will vary,
|
|
but it MUST 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
|
|
]]></sourcecode>
|
|
<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
|
|
MUST be able to consume both the remarks: and
|
|
geofeed: forms.
|
|
</t>
|
|
|
|
<t>
|
|
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 SHOULD have, at most, one geofeed
|
|
reference, whether a remarks: or a proper geofeed: attribute
|
|
when it is implemented. A geofeed: attribute is preferred, of
|
|
course, if the RIR supports it. If there is more than one type
|
|
of attribute in the intetnum: object, the geofeed: attribute
|
|
SHOULD be used.
|
|
</t>
|
|
<t>
|
|
For inetnum:s covering the same address range, or an inetnum:
|
|
with both remarks: and geofeed: attributes, a signed geofeed
|
|
file SHOULD be preferred over an unsigned file.
|
|
</t>
|
|
<t>
|
|
If a geofeed file describes multiple disjoint ranges of IP
|
|
address space, there are likely to be geofeed references from
|
|
multiple inetnum: objects. Files with geofeed references from
|
|
multiple inetnum: objects are not compatible with the signing
|
|
procedure in <xref target="auth" format="default"/>.
|
|
</t>
|
|
<t>
|
|
An unsigned, and only an unsigned, geofeed file MAY be
|
|
referenced by multiple inetnum:s and MAY contain prefixes from
|
|
more than one registry.
|
|
</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 SHOULD be preferred.
|
|
</t>
|
|
<t>
|
|
As inetnum: objects form a hierarchy, geofeed references
|
|
SHOULD 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 MUST 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>
|
|
|
|
</section>
|
|
|
|
<section anchor="fetch" numbered="true" toc="default">
|
|
<name>Fetching Geofeed Data</name>
|
|
|
|
<t>
|
|
This document is to provides a guideline for how interested
|
|
parties should fetch and read geofeed files.
|
|
</t>
|
|
|
|
<t>
|
|
Historically, before <xref target="RFC9092"/>, this was done in
|
|
varied ways, at the discretion of the implementer, often without
|
|
consistent authentication, where data were mostly imported from
|
|
email without formal authorisation or validation.
|
|
</t>
|
|
|
|
<t>
|
|
To minimize the load on RIRs' WHOIS <xref target="RFC3912"/>
|
|
services, the RIR's FTP <xref target="RFC0959"/> services SHOULD
|
|
be used for large-scale access to gather inetnum:s with geofeed
|
|
references. This uses efficient bulk access instead of fetching
|
|
via brute-force search through the IP space.
|
|
</t>
|
|
|
|
<t>
|
|
When reading data from the geofeed file, one MUST ignore data
|
|
outside the referring inetnum: object's address range. This is
|
|
to avoid importing data about ranges not under the control of
|
|
the operator. If geofeed files are fetched, other location
|
|
information from the inetnum: MUST be ignored.
|
|
</t>
|
|
|
|
<t>
|
|
Given an address range of interest, the most specific inetnum:
|
|
object with a geofeed reference MUST be used to fetch the
|
|
geofeed file. For example, if the fetching party finds
|
|
the following inetnum: objects:
|
|
<sourcecode type="rpsl"> <![CDATA[
|
|
inetnum: 192.0.2.0/12 # example
|
|
remarks: Geofeed https://example.com/geofeed_1
|
|
|
|
inetnum: 192.0.2.0/24 # example
|
|
remarks: Geofeed https://example.com/geofeed_2
|
|
]]></sourcecode>
|
|
Since geofeed_1 contains geolocation data about 192.0.2.0/29,
|
|
it is discarded because 192.0.2.0/24 is within the more
|
|
specific inetnum: covering the address range and that inetnum:
|
|
has a geofeed reference.
|
|
</t>
|
|
|
|
<t>
|
|
Hints in inetnum:s such as country:, geoloc:, etc. tend to be
|
|
administrative, and not deployment specific. Consider large,
|
|
possibly global, providers with headquarters very far from most
|
|
of their deployments. Therefore, if geofeed data are specified,
|
|
either as a geofeed: attribute or in a geofeed remarks:
|
|
attribute, other geographic hints such as country:, geoloc:, DNS
|
|
geoloc RRsets, etc., for that address range MUST be ignored.
|
|
</t>
|
|
|
|
<t>
|
|
There is open-source code to traverse the RPSL data across all
|
|
of the RIRs, collect all geofeed references, and process them
|
|
<xref target="GEOFEED-FINDER"/>. It implements the steps above
|
|
and of all the Operational Considerations described in <xref
|
|
target="ops"/>, including caching. It produces a single geofeed
|
|
file, merging all the geofeed files found. This open-source
|
|
code can be run daily by a cronjob, and the output file can be
|
|
directly used.
|
|
</t>
|
|
<t>
|
|
RIRs are converging on RDAP support which includes geofeed data,
|
|
see <xref target="I-D.ietf-regext-rdap-geofeed"/>. This SHOULD
|
|
NOT be used for bulk retrieval of geofeed data.
|
|
</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"/> 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"/> file provides some assurance. Unfortunately,
|
|
the RPSL in some repositories is weakly authenticated at best.
|
|
An approach where RPSL was signed per <xref target="RFC7909"/>
|
|
would be good, except it would have to be deployed by all RPSL
|
|
registries, and there is a fair number of them.
|
|
</t>
|
|
|
|
<t>
|
|
The remainder of this section specifies an optional
|
|
authenticator for the geofeed data set that follows the Signed
|
|
Object Template for the Resource Public Key Infrastructure
|
|
(RPKI) <xref target="RFC6488"/>.
|
|
</t>
|
|
|
|
<t>
|
|
A single optional authenticator MAY be appended to a geofeed
|
|
<xref target="RFC8805"/> file. It is a digest of the main body
|
|
of the file signed by the private key of the relevant RPKI
|
|
certificate for a covering address range. The following format
|
|
bundles the relevant RPKI certificate with a signature over the
|
|
geofeed text.
|
|
</t>
|
|
|
|
<t>
|
|
The canonicalization procedure converts the data from their
|
|
internal character representation to the UTF-8 <xref
|
|
target="RFC3629"/> character encoding, and the <CRLF>
|
|
sequence MUST be used to denote the end of each line of text. A
|
|
blank line is represented solely by the <CRLF> sequence.
|
|
For robustness, any non-printable characters MUST NOT be changed
|
|
by canonicalization. Trailing blank lines MUST NOT appear at
|
|
the end of the file. 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
|
|
MUST NOT be covered by the digital signature.
|
|
</t>
|
|
|
|
<t>
|
|
If the authenticator is not in the canonical form described above,
|
|
then, the authenticator is invalid.
|
|
</t>
|
|
|
|
<t>
|
|
Borrowing detached signatures from <xref target="RFC5485"/>,
|
|
after file canonicalization, the Cryptographic Message Syntax
|
|
(CMS) <xref target="RFC5652"/> is used to create a detached
|
|
DER-encoded signature that is then Base64 encoded with padding
|
|
(as defined in Section 4 of <xref target="RFC4648"/>) and line
|
|
wrapped to 72 or fewer characters. The same digest algorithm
|
|
MUST be used for calculating the message digest of the content
|
|
being signed, which is the geofeed file, and for calculating the
|
|
message digest on the SignerInfo SignedAttributes <xref
|
|
target="RFC8933"/>. The message digest algorithm identifier
|
|
MUST appear in both the CMS SignedData
|
|
DigestAlgorithmIdentifiers and the SignerInfo
|
|
DigestAlgorithmIdentifier <xref target="RFC5652"/>. The RPKI
|
|
certificate covering the geofeed inetnum: object's address range
|
|
is included in the CMS SignedData certificates field <xref
|
|
target="RFC5652"/>.
|
|
</t>
|
|
|
|
<t>
|
|
The address range of the signing certificate MUST cover all
|
|
prefixes in the signed geofeed file. The signing certificate
|
|
MUST NOT include the Autonomous System Identifier Delegation
|
|
certificate extension <xref target="RFC3779"/>.
|
|
</t>
|
|
|
|
<t>
|
|
As with many other RPKI signed objects, the IP Address
|
|
Delegation certificate extension MUST NOT use the "inherit"
|
|
capability defined in Section 2.2.3.5 of <xref
|
|
target="RFC3779"/>. An IP Address Delegation extension using
|
|
"inherit" would complicate processing. The implementation would
|
|
have to build the certification path from the end-entity to the
|
|
trust anchor, then validate the path from the trust anchor to
|
|
the end-entity, and then the parameter would have to be
|
|
remembered when the validated public key was used to validate a
|
|
signature on a CMS object. Having to remember things from
|
|
certification path validation for use with CMS object processing
|
|
is too hard. And, the certificates do not get that much bigger
|
|
by repeating the information.
|
|
</t>
|
|
|
|
<t>
|
|
An address range A "covers" address range B if the range of B is
|
|
identical to or a subset of A. "Address range" is used here
|
|
because inetnum: objects and RPKI certificates need not align on
|
|
Classless Inter-Domain Routing (CIDR) <xref target="RFC4632"/>
|
|
prefix boundaries, while those of the lines in a geofeed file do
|
|
align.
|
|
</t>
|
|
|
|
<t>
|
|
The Certificate Authority (CA) SHOULD sign only one geofeed file
|
|
with each generated private key and SHOULD generate a new key
|
|
pair for each new version of a perticular geofeed file. The CA
|
|
MUST generate a new End Entity (EE) certificate for each signing
|
|
of a particular geofeed file. An associated EE certificate used
|
|
in this fashion is termed a "one-time-use" EE certificate (see
|
|
Section 3 of <xref target="RFC6487"/>).
|
|
</t>
|
|
|
|
<t>
|
|
Identifying the private key associated with the certificate and
|
|
getting the department that controls the private key (which
|
|
might be stored in a Hardware Security Module (HSM)) to generate
|
|
the CMS signature is left as an exercise for the implementor.
|
|
On the other hand, verifying the signature has no similar
|
|
complexity; the certificate, which is validated in the public
|
|
RPKI, contains the needed public key. The RPKI trust anchors
|
|
for the RIRs are expected to already be available to the party
|
|
performing signature validation. Validation of the CMS
|
|
signature over the geofeed file involves:
|
|
</t>
|
|
<ol spacing="normal" type="1">
|
|
<li>
|
|
Obtaining the signer's certificate from the CMS SignedData
|
|
CertificateSet <xref target="RFC5652"/>. The certificate
|
|
SubjectKeyIdentifier extension <xref target="RFC5280"/> MUST
|
|
match the SubjectKeyIdentifier in the CMS SignerInfo
|
|
SignerIdentifier <xref target="RFC5652"/>. If the key
|
|
identifiers do not match, then validation MUST fail.
|
|
</li>
|
|
|
|
<li>
|
|
Validating the signer's certificate MUST ensure that it is
|
|
part of the current <xref target="RFC9286"/> manifest and that
|
|
all resources are covered by the RPKI certificate.
|
|
</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 MUST be valid according to the validation
|
|
algorithm in <xref target="RFC5280"/> and the additional
|
|
checks specified in <xref target="RFC3779"/> associated with
|
|
the IP Address Delegation certificate extension and the
|
|
Autonomous System Identifier Delegation certificate extension.
|
|
If certification path validation is unsuccessful, then
|
|
validation MUST fail.
|
|
</li>
|
|
|
|
<li>
|
|
Validating the CMS SignedData as specified in <xref
|
|
target="RFC5652"/> using the public key from the validated
|
|
signer's certificate. If the signature validation is
|
|
unsuccessful, then validation MUST fail.
|
|
</li>
|
|
|
|
<li>
|
|
Confirming that the eContentType object identifier (OID) is
|
|
id-ct-geofeedCSVwithCRLF (1.2.840.113549.1.9.16.1.47). This
|
|
OID MUST appear within both the eContentType in the
|
|
encapContentInfo object and the ContentType signed attribute
|
|
in the signerInfo object (see <xref target="RFC6488"/>).
|
|
</li>
|
|
|
|
<li>
|
|
Verifying that the IP Address Delegation certificate
|
|
extension <xref target="RFC3779"/> covers all of the address
|
|
ranges of the geofeed file. If all of the address ranges are
|
|
not covered, then validation MUST fail.
|
|
</li>
|
|
</ol>
|
|
|
|
<t>
|
|
All of the above steps MUST be successful to consider the
|
|
geofeed file signature as valid.
|
|
</t>
|
|
|
|
<t>
|
|
The authenticator MUST be hidden as a series of "#" comments at the
|
|
end of the geofeed file. The following simple example is
|
|
cryptographically incorrect:
|
|
</t>
|
|
<sourcecode type=""><![CDATA[
|
|
# RPKI Signature: 192.0.2.0 - 192.0.2.255
|
|
# MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
|
|
# IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
|
|
...
|
|
# imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa
|
|
# O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=
|
|
# End Signature: 192.0.2.0 - 192.0.2.255
|
|
]]></sourcecode>
|
|
|
|
<t>
|
|
A correct and full example is in Appendix A.
|
|
</t>
|
|
|
|
<t>
|
|
The CMS signature does not cover the signature lines.
|
|
</t>
|
|
|
|
<t>
|
|
The bracketing "# RPKI Signature:" and "# End Signature:" MUST
|
|
be present as shown in the example. The RPKI Signature's IP
|
|
address range MUST match that of the geofeed URL in the inetnum:
|
|
that points to the geofeed file.
|
|
</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 MUST be published via and fetched using
|
|
HTTPS <xref target="RFC9110" format="default"/>.
|
|
</t>
|
|
<t>
|
|
When using data from a geofeed file, one MUST 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 MAY
|
|
refer to the same geofeed file, and the consumer MUST
|
|
use only lines in the geofeed file where the prefix is covered by the
|
|
address range of the inetnum: object's URL it has followed.
|
|
</t>
|
|
<t>
|
|
If the geofeed file is signed, and the signer's certificate
|
|
changes, the signature in the geofeed file MUST
|
|
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>
|
|
Harvesting and publishing aggregated geofeed data outside of the
|
|
RPSL model should be avoided as it can have the effect that more
|
|
specifics from one aggregatee could undesirably affect the less
|
|
specifics of a different aggregatee. Moreover, publishing
|
|
aggregated geofeed data prevents the reader of the data to
|
|
perform the checks described in <xref target="fetch"/> and <xref
|
|
target="auth"/>.
|
|
</t>
|
|
<t>
|
|
At the time of publishing this document, 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 MUST
|
|
NOT 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
|
|
SHOULD NOT 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="impl" numbered="true" toc="default">
|
|
<name>Implementation Status</name>
|
|
|
|
<t>
|
|
At the time of publishing this document, the geofeed: attribute
|
|
in inetnum objects has been implemented in the RIPE and APNIC
|
|
databases.
|
|
</t>
|
|
|
|
<t>
|
|
Registrants in databases which do not yet support the geofeed:
|
|
attribute are using the remarks:, or equivalent, attribute.
|
|
</t>
|
|
|
|
<t>
|
|
At the time of publishing this document, the registry data
|
|
published by ARIN are not the same RPSL as that of the other
|
|
registries (see <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 must be
|
|
treated as "inetnum", and the "Comment" attribute must be
|
|
treated as "remarks".
|
|
</t>
|
|
|
|
<t>
|
|
<xref target="rpki-client"/> can be used to authenticate a
|
|
signed geofeed file.
|
|
</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>
|
|
The consumer of geofeed data SHOULD fetch and process the data
|
|
themselves. Importing datasets produced and/or processed by a
|
|
third-party places ill-advised trust in the third-party.
|
|
</t>
|
|
<t>
|
|
As mentioned in <xref target="auth" format="default"/>, some
|
|
RPSL repositories have weak, if any, authentication. This
|
|
allows spoofing of inetnum: objects pointing to malicious
|
|
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 MUST 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>
|
|
There are no new actions needed by the IANA.
|
|
</t>
|
|
</section>
|
|
<section title="Acknowledgments" anchor="acks">
|
|
<t>Thanks to Rob Austein for CMS and detached signature clue,
|
|
George Michaelson for the first and substantial external review,
|
|
and Erik Kline who was too shy to agree to coauthorship.
|
|
Additionally, we express our gratitude to early implementors,
|
|
including Menno Schepers; Flavio Luciani; Eric Dugas; and Kevin
|
|
Pack. Also, thanks to the following geolocation providers who are
|
|
consuming geofeeds with this described solution: Jonathan Kosgei
|
|
(ipdata.co), Ben Dowling (ipinfo.io), and Pol Nisenblat
|
|
(bigdatacloud.com). For an amazing number of helpful reviews, we
|
|
thank Job Snijders, who also found an ASN.1 'inherit' issue;
|
|
Adrian Farrel; Antonio Prado; Francesca Palombini; Jean-Michel
|
|
Combes (INTDIR); John Scudder; Kyle Rose (SECDIR); Martin Duke;
|
|
Mohamed Boucadair; Murray Kucherawy; Paul Kyzivat (GENART); Rob
|
|
Wilton; Roman Danyliw; and Ties de Kock.</t>
|
|
</section>
|
|
</middle>
|
|
<back>
|
|
|
|
<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.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.6487.xml"?>
|
|
<?rfc include="reference.RFC.6488.xml"?>
|
|
<?rfc include="reference.RFC.8805.xml"?>
|
|
<?rfc include="reference.RFC.8933.xml"?>
|
|
<?rfc include="reference.RFC.9110.xml"?>
|
|
<?rfc include="reference.RFC.9286.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.6269.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.9092.xml"?>
|
|
<?rfc include="reference.I-D.ietf-regext-rdap-geofeed"?>
|
|
|
|
<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>
|
|
|
|
<reference anchor="rpki-client" target="https://sobornost.net/~job/using_geofeed_authenticators.txt">
|
|
<front>
|
|
<title>Example on how to use rpki-client to authenticate a signed Geofeed</title>
|
|
<author fullname="Job Snijders"/>
|
|
<date month="September" year="2023" />
|
|
</front>
|
|
</reference>
|
|
|
|
</references>
|
|
|
|
|
|
<section title="Example" anchor="example">
|
|
<t>
|
|
This appendix provides an example, including a trust anchor, a
|
|
Certificate Revocation List (CRL) signed by the trust anchor, a CA
|
|
certificate subordinate to the trust anchor, a CRL signed by the CA,
|
|
an end-entity certificate subordinate to the CA for signing the
|
|
geofeed, and a detached signature.</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 Systam
|
|
(AS) numbers.</t>
|
|
|
|
<figure><artwork><![CDATA[
|
|
-----BEGIN CERTIFICATE-----
|
|
MIIEQTCCAymgAwIBAgIUEggycNoFVRjAuN/Fw7URu0DEZNAwDQYJKoZIhvcNAQEL
|
|
BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yMzA5MTkyMDMzMzlaFw0zMzA5
|
|
MTYyMDMzMzlaMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEwggEiMA0GCSqGSIb3DQEB
|
|
AQUAA4IBDwAwggEKAoIBAQDQprR+g/i4JyObVURTp1JpGM23vGPyE5fDKFPqV7rw
|
|
M1Amm7cnew66U02IzV0X5oiv5nSGfRX5UxsbR+vwPBMceQyDgS5lexFiv4fB/Vjf
|
|
DT2qX/UjsLL9QOeaSOh7ToJSLjmtpa0D9iz7ful3hdxRjpMMZiE/reX9/ymdpW/E
|
|
dg0F6+T9WGZE1miPeIjl5OZwnmLHCftkN/aaYk1iPNjNniHYIOjC1jSpABmoZyTj
|
|
sgrwLE2F1fIRkVkwASqToq/D5v9voXaYYaXUNJb4H/5wenRuvT5O/n6PXh70rMQy
|
|
F5yzLs96ytxqg5gGX9kabVnvxFU8nHfPa0rhlwfTJnljAgMBAAGjggGHMIIBgzAd
|
|
BgNVHQ4EFgQUwL1SXb7SeLIW7LOjQ5XSBguZCDIwHwYDVR0jBBgwFoAUwL1SXb7S
|
|
eLIW7LOjQ5XSBguZCDIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYw
|
|
GAYDVR0gAQH/BA4wDDAKBggrBgEFBQcOAjCBuQYIKwYBBQUHAQsEgawwgakwPgYI
|
|
KwYBBQUHMAqGMnJzeW5jOi8vcnBraS5leGFtcGxlLm5ldC9yZXBvc2l0b3J5L2V4
|
|
YW1wbGUtdGEubWZ0MDUGCCsGAQUFBzANhilodHRwczovL3JyZHAuZXhhbXBsZS5u
|
|
ZXQvbm90aWZpY2F0aW9uLnhtbDAwBggrBgEFBQcwBYYkcnN5bmM6Ly9ycGtpLmV4
|
|
YW1wbGUubmV0L3JlcG9zaXRvcnkvMCcGCCsGAQUFBwEHAQH/BBgwFjAJBAIAATAD
|
|
AwEAMAkEAgACMAMDAQAwIQYIKwYBBQUHAQgBAf8EEjAQoA4wDDAKAgEAAgUA////
|
|
/zANBgkqhkiG9w0BAQsFAAOCAQEAa9eLY9QAmnlZOIyOzbpta5wqcOUQV/yR7o/0
|
|
1zkEZaSavKBt19lMK6AXZurx1T5jyjIwG7bEtZZThjtH2m80V5kc2tsFjSq/yp7N
|
|
JBclMHVd3tXse9If3nXYF4bxRIcir1lXlAbYN+Eo1U3i5qJO+fxouzt7Merk2Dih
|
|
nsenTeXKzN7tfmuCYZZHCC8viCoJWdH+o1uRM4TiQApZsUJ8sF4TABrrRJmA/Ed5
|
|
v0CTBbgqTx7yg0+VarFLPdnjYgtpoCJqwE2C1UpX15rZSaLVuGXtbwXd/cHEg5vF
|
|
W6QTsMeMQFEUa6hkicDGtxLTUdhckBgmCGoF2nlZii5f1BTWAg==
|
|
-----END CERTIFICATE-----
|
|
]]></artwork></figure>
|
|
|
|
<t>
|
|
The CRL issued by the trust anchor.</t>
|
|
|
|
<figure><artwork><![CDATA[
|
|
-----BEGIN X509 CRL-----
|
|
MIIBjjB4AgEBMA0GCSqGSIb3DQEBCwUAMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEX
|
|
DTIzMDkyMzE1NTUzOFoXDTIzMTAyMzE1NTUzOFqgLzAtMB8GA1UdIwQYMBaAFMC9
|
|
Ul2+0niyFuyzo0OV0gYLmQgyMAoGA1UdFAQDAgEEMA0GCSqGSIb3DQEBCwUAA4IB
|
|
AQCngOu+Nq3WC4y/pHtLoheAOtNg32WWsKPNiEyL+QalmOtURUsWMzOq41bmoPzQ
|
|
NDQoRmXe9mvohAVRe0CnM7A07HOtSfjw5aoouPXGTtfwEomHG2CYk+2U1bvxgZyA
|
|
E1c5TvyhkabFMO0+857wqxRP+ht9NV0lMX6kUFlEOCw3ELVd9oNNRBwKQtXj1huM
|
|
6Sf26va2a1tnC5zP01hN+EY3S9T5T1gcgPGBcqRWKoXJEbRzCrLsb/TMj5cMpIje
|
|
AHZoBojVAmvL1AIH/BnGAQj0+XqaJ0axHvlqJa8iX8QwKqhp+o6sv/atY2QDDRmE
|
|
Yjq/VrBVKu5VsDY2Lr29HszA
|
|
-----END X509 CRL-----
|
|
]]></artwork></figure>
|
|
|
|
<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>
|
|
|
|
<figure><artwork><![CDATA[
|
|
-----BEGIN CERTIFICATE-----
|
|
MIIE7DCCA9SgAwIBAgIUcyCzS10hdfG65kbRq7toQAvRDLkwDQYJKoZIhvcNAQEL
|
|
BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yMzA5MjMxNTU1MzhaFw0yNDA5
|
|
MjIxNTU1MzhaMDMxMTAvBgNVBAMTKDNBQ0UyQ0VGNEZCMjFCN0QxMUUzRTE4NEVG
|
|
QzFFMjk3QjM3Nzg2NDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc
|
|
zz1qwTxC2ocw5rqp8ktm2XyYkl8riBVuqlXwfefTxsR2YFpgz9vkYUd5Az9EVEG7
|
|
6wGIyZbtmhK63eEeaqbKz2GHub467498BXeVrYysO+YuIGgCEYKznNDZ4j5aaDbo
|
|
j5+4/z0Qvv6HEsxQd0f8br6lKJwgeRM6+fm7796HNPB0aqD7Zj9NRCLXjbB0DCgJ
|
|
liH6rXMKR86ofgll9V2mRjesvhdKYgkGbOif9rvxVpLJ/6zdru5CE9yeuJZ59l+n
|
|
YH/r6PzdJ4Q7yKrJX8qD6A60j4+biaU4MQ72KpsjhQNTTqF/HRwi0N54GDaknEwE
|
|
TnJQHgLJDYqww9yKWtjjAgMBAAGjggIUMIICEDAdBgNVHQ4EFgQUOs4s70+yG30R
|
|
4+GE78Hil7N3hkIwHwYDVR0jBBgwFoAUwL1SXb7SeLIW7LOjQ5XSBguZCDIwDwYD
|
|
VR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwGAYDVR0gAQH/BA4wDDAKBggr
|
|
BgEFBQcOAjBDBgNVHR8EPDA6MDigNqA0hjJyc3luYzovL3Jwa2kuZXhhbXBsZS5u
|
|
ZXQvcmVwb3NpdG9yeS9leGFtcGxlLXRhLmNybDBOBggrBgEFBQcBAQRCMEAwPgYI
|
|
KwYBBQUHMAKGMnJzeW5jOi8vcnBraS5leGFtcGxlLm5ldC9yZXBvc2l0b3J5L2V4
|
|
YW1wbGUtdGEuY2VyMIG5BggrBgEFBQcBCwSBrDCBqTA+BggrBgEFBQcwCoYycnN5
|
|
bmM6Ly9ycGtpLmV4YW1wbGUubmV0L3JlcG9zaXRvcnkvZXhhbXBsZS1jYS5tZnQw
|
|
NQYIKwYBBQUHMA2GKWh0dHBzOi8vcnJkcC5leGFtcGxlLm5ldC9ub3RpZmljYXRp
|
|
b24ueG1sMDAGCCsGAQUFBzAFhiRyc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVw
|
|
b3NpdG9yeS8wHwYIKwYBBQUHAQcBAf8EEDAOMAwEAgABMAYDBADAAAIwIQYIKwYB
|
|
BQUHAQgBAf8EEjAQoA4wDDAKAgMA+/ACAwD78TANBgkqhkiG9w0BAQsFAAOCAQEA
|
|
arIrZWb22wFmP+hVjhdg3IsKHB6fQdMuUR0u2DyZTVvbL6C+HyGAH32pi5mR/QLX
|
|
FAfdqALaB7r68tQTGLIW6bGljT+BqUPJmZcj56x3cBLJlltxwFatTloypjFt3cls
|
|
xFCuuD9J2iBxc6odTKi6u0mhQjD+C9m4xkbe8XXWWx85IHm1s6rYbpGgiMWxBC80
|
|
qqAzmBHGROWKUEvh00EYIYdiAvyFcrj7QtDiRJL5TDOySVd9pWJkerDzhqwE1IaZ
|
|
rpHck+lkYTS7jTD++6v32HG62GdsmryOQUk3aU1rLb3kS8vzaGbrgHpGPid0Hd0x
|
|
ZSl1AoIMpp5mZ7/h9aW5+A==
|
|
-----END CERTIFICATE-----
|
|
]]></artwork></figure>
|
|
|
|
<t>
|
|
The CRL issued by the CA.</t>
|
|
|
|
<figure><artwork><![CDATA[
|
|
-----BEGIN X509 CRL-----
|
|
MIIBrTCBlgIBATANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEygzQUNFMkNFRjRG
|
|
QjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyFw0yMzA5MjMxNTU1MzhaFw0y
|
|
MzEwMjMxNTU1MzhaoC8wLTAfBgNVHSMEGDAWgBQ6zizvT7IbfRHj4YTvweKXs3eG
|
|
QjAKBgNVHRQEAwIBATANBgkqhkiG9w0BAQsFAAOCAQEACwCNzcAoqbMcUL1kBY65
|
|
YhL95OnBqAcuc99pD4i9c1BmVOl7bXU3cJqLaOZ6Z8CmN0kBbcHyqlHBJ9oA/aYD
|
|
ByhxsjzKk7jxtM2IlTpEvCEqvnGLSVihgS3h0NA+sgWqHGL3Rhcj6hVsi+j9GENc
|
|
T6F9np1mxbI3i2xhgeDJG1pryvH0hWXh7yJiYS8ItNEaIIXDT3szK/J9wnPjukTR
|
|
5MITiK9P3TCFujawb3O7rIT5PPgkM6eiCdwDgt6gjmw6cow5+rMjNHSRa+GOviSd
|
|
gXljVDfJvF4tKHmw59Jc2aFnSGfX1/ITDNiNfXYpUYFOcsqxkYf8F0uO7AtbRmTF
|
|
2w==
|
|
-----END X509 CRL-----
|
|
]]></artwork></figure>
|
|
|
|
<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
|
|
end-entity certificate.</t>
|
|
|
|
<figure><artwork><![CDATA[
|
|
-----BEGIN CERTIFICATE-----
|
|
MIIEVjCCAz6gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZvAwDQYJKoZIhvcNAQEL
|
|
BQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExRTNFMTg0RUZDMUUyOTdC
|
|
Mzc3ODY0MjAeFw0yMzA5MjMxNTU1MzhaFw0yNDA3MTkxNTU1MzhaMDMxMTAvBgNV
|
|
BAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM0NUFCRjA1M0ExODcwggEi
|
|
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycTQrOb/qB2W3i3Ki8PhA/DEW
|
|
yii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQgtPCVwr62hTQZCIowBN0BL0c
|
|
K0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZmr5xphXRvE+mzuJVLgu2V1upm
|
|
BXuWloeymudh6WWJ+GDjwPXO3RiXBejBrOFNXhaFLe08y4DPfr/S/tXJOBm7QzQp
|
|
tmbPLYtGfprYu45liFFqqP94UeLpISfXd36AKGzqTFCcc3EW9l5UFE1MFLlnoEog
|
|
qtoLoKABt0IkOFGKeC/EgeaBdWLe469ddC9rQft5w6g6cmxG+aYDdIEB34zrAgMB
|
|
AAGjggFgMIIBXDAdBgNVHQ4EFgQUkUZSo71RwUQmAZiIn1xFq/BToYcwHwYDVR0j
|
|
BBgwFoAUOs4s70+yG30R4+GE78Hil7N3hkIwDgYDVR0PAQH/BAQDAgeAMBgGA1Ud
|
|
IAEB/wQOMAwwCgYIKwYBBQUHDgIwYQYDVR0fBFowWDBWoFSgUoZQcnN5bmM6Ly9y
|
|
cGtpLmV4YW1wbGUubmV0L3JlcG9zaXRvcnkvM0FDRTJDRUY0RkIyMUI3RDExRTNF
|
|
MTg0RUZDMUUyOTdCMzc3ODY0Mi5jcmwwbAYIKwYBBQUHAQEEYDBeMFwGCCsGAQUF
|
|
BzAChlByc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVwb3NpdG9yeS8zQUNFMkNF
|
|
RjRGQjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyLmNlcjAfBggrBgEFBQcB
|
|
BwEB/wQQMA4wDAQCAAEwBgMEAMAAAjANBgkqhkiG9w0BAQsFAAOCAQEAlxt25FUe
|
|
e0+uCidTH+4p7At3u2ncgHcGTsag3UcoPjcE/I1JgQJRu9TiM4iNB1C7Lbdd131g
|
|
MdliL5GQ3P4QfKnfkuPR6S1V8suq6ZT1KQRyLJx+EPgDN2rb/iji0TOK6RKPNBdG
|
|
lXVLjth4x/uu1O4V54GLEhDAPQC8IUm5intL/Hx1M1x2ptN/+j5HD3XUXd3x13yi
|
|
s6u758nbA7ND40JNhGG5JNGQgDchL4IQzIhylMNC+bKUiyyMHz3MqoVAklIB86IW
|
|
Ucv72Mekq+i46T/w3RnaGn4x7RAJctVJWw3e5YMrFnQcuuaGOs0QcoxW7Bi4W7Eg
|
|
8fK1fd/f6fjZ9w==
|
|
-----END CERTIFICATE-----
|
|
]]></artwork></figure>
|
|
|
|
<t>
|
|
The end-entity certificate is displayed below in detail. For
|
|
brevity, the other two certificates are not.</t>
|
|
|
|
<figure><artwork><![CDATA[
|
|
0 1110: SEQUENCE {
|
|
4 830: SEQUENCE {
|
|
8 3: [0] {
|
|
10 1: INTEGER 2
|
|
: }
|
|
13 20: INTEGER
|
|
: 27 AD 39 40 83 D7 F2 B5 B9 9B 86 70 C7 75 B2 B9
|
|
: 6E E1 66 F0
|
|
35 13: SEQUENCE {
|
|
37 9: OBJECT IDENTIFIER
|
|
: sha256WithRSAEncryption (1 2 840 113549 1 1 11)
|
|
48 0: NULL
|
|
: }
|
|
50 51: SEQUENCE {
|
|
52 49: SET {
|
|
54 47: SEQUENCE {
|
|
56 3: OBJECT IDENTIFIER commonName (2 5 4 3)
|
|
61 40: PrintableString
|
|
: '3ACE2CEF4FB21B7D11E3E184EFC1E297B3778642'
|
|
: }
|
|
: }
|
|
: }
|
|
103 30: SEQUENCE {
|
|
105 13: UTCTime 23/09/2023 15:55:38 GMT
|
|
120 13: UTCTime 19/07/2024 15:55:38 GMT
|
|
: }
|
|
135 51: SEQUENCE {
|
|
137 49: SET {
|
|
139 47: SEQUENCE {
|
|
141 3: OBJECT IDENTIFIER commonName (2 5 4 3)
|
|
146 40: PrintableString
|
|
: '914652A3BD51C144260198889F5C45ABF053A187'
|
|
: }
|
|
: }
|
|
: }
|
|
188 290: SEQUENCE {
|
|
192 13: SEQUENCE {
|
|
194 9: OBJECT IDENTIFIER
|
|
: rsaEncryption (1 2 840 113549 1 1 1)
|
|
205 0: NULL
|
|
: }
|
|
207 271: BIT STRING, encapsulates {
|
|
212 266: SEQUENCE {
|
|
216 257: INTEGER
|
|
: 00 B2 71 34 2B 39 BF EA 07 65 B7 8B 72 A2 F0 F8
|
|
: 40 FC 31 16 CA 28 B6 4E 01 A8 F6 98 02 C0 EF 65
|
|
: B0 84 48 E9 96 FF 93 E6 92 89 65 8F F6 44 9C CE
|
|
: 57 10 82 D3 C2 57 0A FA DA 14 D0 64 22 28 C0 13
|
|
: 74 04 BD 1C 2B 4F F9 93 58 A6 25 D8 B9 A9 D3 37
|
|
: 9E F2 AC C0 CF 02 9E 84 75 D6 F0 7C A5 01 70 AE
|
|
: E6 66 AF 9C 69 85 74 6F 13 E9 B3 B8 95 4B 82 ED
|
|
: 95 D6 EA 66 05 7B 96 96 87 B2 9A E7 61 E9 65 89
|
|
: F8 60 E3 C0 F5 CE DD 18 97 05 E8 C1 AC E1 4D 5E
|
|
: 16 85 2D ED 3C CB 80 CF 7E BF D2 FE D5 C9 38 19
|
|
: BB 43 34 29 B6 66 CF 2D 8B 46 7E 9A D8 BB 8E 65
|
|
: 88 51 6A A8 FF 78 51 E2 E9 21 27 D7 77 7E 80 28
|
|
: 6C EA 4C 50 9C 73 71 16 F6 5E 54 14 4D 4C 14 B9
|
|
: 67 A0 4A 20 AA DA 0B A0 A0 01 B7 42 24 38 51 8A
|
|
: 78 2F C4 81 E6 81 75 62 DE E3 AF 5D 74 2F 6B 41
|
|
: FB 79 C3 A8 3A 72 6C 46 F9 A6 03 74 81 01 DF 8C
|
|
: EB
|
|
477 3: INTEGER 65537
|
|
: }
|
|
: }
|
|
: }
|
|
482 352: [3] {
|
|
486 348: SEQUENCE {
|
|
490 29: SEQUENCE {
|
|
492 3: OBJECT IDENTIFIER
|
|
: subjectKeyIdentifier (2 5 29 14)
|
|
497 22: OCTET STRING, encapsulates {
|
|
499 20: OCTET STRING
|
|
: 91 46 52 A3 BD 51 C1 44 26 01 98 88 9F 5C 45 AB
|
|
: F0 53 A1 87
|
|
: }
|
|
: }
|
|
521 31: SEQUENCE {
|
|
523 3: OBJECT IDENTIFIER
|
|
: authorityKeyIdentifier (2 5 29 35)
|
|
528 24: OCTET STRING, encapsulates {
|
|
530 22: SEQUENCE {
|
|
532 20: [0]
|
|
: 3A CE 2C EF 4F B2 1B 7D 11 E3 E1 84 EF C1 E2 97
|
|
: B3 77 86 42
|
|
: }
|
|
: }
|
|
: }
|
|
554 14: SEQUENCE {
|
|
556 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
|
|
561 1: BOOLEAN TRUE
|
|
564 4: OCTET STRING, encapsulates {
|
|
566 2: BIT STRING 7 unused bits
|
|
: '1'B (bit 0)
|
|
: }
|
|
: }
|
|
570 24: SEQUENCE {
|
|
572 3: OBJECT IDENTIFIER certificatePolicies (2 5 29 32)
|
|
577 1: BOOLEAN TRUE
|
|
580 14: OCTET STRING, encapsulates {
|
|
582 12: SEQUENCE {
|
|
584 10: SEQUENCE {
|
|
586 8: OBJECT IDENTIFIER
|
|
: resourceCertificatePolicy (1 3 6 1 5 5 7 14 2)
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
596 97: SEQUENCE {
|
|
598 3: OBJECT IDENTIFIER
|
|
: cRLDistributionPoints (2 5 29 31)
|
|
603 90: OCTET STRING, encapsulates {
|
|
605 88: SEQUENCE {
|
|
607 86: SEQUENCE {
|
|
609 84: [0] {
|
|
611 82: [0] {
|
|
613 80: [6]
|
|
: 'rsync://rpki.example.net/repository/3ACE'
|
|
: '2CEF4FB21B7D11E3E184EFC1E297B3778642.crl'
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
695 108: SEQUENCE {
|
|
697 8: OBJECT IDENTIFIER
|
|
: authorityInfoAccess (1 3 6 1 5 5 7 1 1)
|
|
707 96: OCTET STRING, encapsulates {
|
|
709 94: SEQUENCE {
|
|
711 92: SEQUENCE {
|
|
713 8: OBJECT IDENTIFIER
|
|
: caIssuers (1 3 6 1 5 5 7 48 2)
|
|
723 80: [6]
|
|
: 'rsync://rpki.example.net/repository/3ACE'
|
|
: '2CEF4FB21B7D11E3E184EFC1E297B3778642.cer'
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
805 31: SEQUENCE {
|
|
807 8: OBJECT IDENTIFIER
|
|
: ipAddrBlocks (1 3 6 1 5 5 7 1 7)
|
|
817 1: BOOLEAN TRUE
|
|
820 16: OCTET STRING, encapsulates {
|
|
822 14: SEQUENCE {
|
|
824 12: SEQUENCE {
|
|
826 2: OCTET STRING 00 01
|
|
830 6: SEQUENCE {
|
|
832 4: BIT STRING
|
|
: '010000000000000000000011'B
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
838 13: SEQUENCE {
|
|
840 9: OBJECT IDENTIFIER
|
|
: sha256WithRSAEncryption (1 2 840 113549 1 1 11)
|
|
851 0: NULL
|
|
: }
|
|
853 257: BIT STRING
|
|
: 97 1B 76 E4 55 1E 7B 4F AE 0A 27 53 1F EE 29 EC
|
|
: 0B 77 BB 69 DC 80 77 06 4E C6 A0 DD 47 28 3E 37
|
|
: 04 FC 8D 49 81 02 51 BB D4 E2 33 88 8D 07 50 BB
|
|
: 2D B7 5D D7 7D 60 31 D9 62 2F 91 90 DC FE 10 7C
|
|
: A9 DF 92 E3 D1 E9 2D 55 F2 CB AA E9 94 F5 29 04
|
|
: 72 2C 9C 7E 10 F8 03 37 6A DB FE 28 E2 D1 33 8A
|
|
: E9 12 8F 34 17 46 95 75 4B 8E D8 78 C7 FB AE D4
|
|
: EE 15 E7 81 8B 12 10 C0 3D 00 BC 21 49 B9 8A 7B
|
|
: 4B FC 7C 75 33 5C 76 A6 D3 7F FA 3E 47 0F 75 D4
|
|
: 5D DD F1 D7 7C A2 B3 AB BB E7 C9 DB 03 B3 43 E3
|
|
: 42 4D 84 61 B9 24 D1 90 80 37 21 2F 82 10 CC 88
|
|
: 72 94 C3 42 F9 B2 94 8B 2C 8C 1F 3D CC AA 85 40
|
|
: 92 52 01 F3 A2 16 51 CB FB D8 C7 A4 AB E8 B8 E9
|
|
: 3F F0 DD 19 DA 1A 7E 31 ED 10 09 72 D5 49 5B 0D
|
|
: DE E5 83 2B 16 74 1C BA E6 86 3A CD 10 72 8C 56
|
|
: EC 18 B8 5B B1 20 F1 F2 B5 7D DF DF E9 F8 D9 F7
|
|
: }
|
|
]]></artwork></figure>
|
|
|
|
<t>
|
|
To allow reproduction of the signature results, the end-entity
|
|
private key is provided. For brevity, the other two private
|
|
keys are not.</t>
|
|
|
|
<figure><artwork><![CDATA[
|
|
-----BEGIN RSA PRIVATE KEY-----
|
|
MIIEpQIBAAKCAQEAsnE0Kzm/6gdlt4tyovD4QPwxFsootk4BqPaYAsDvZbCESOmW
|
|
/5Pmkollj/ZEnM5XEILTwlcK+toU0GQiKMATdAS9HCtP+ZNYpiXYuanTN57yrMDP
|
|
Ap6EddbwfKUBcK7mZq+caYV0bxPps7iVS4LtldbqZgV7lpaHsprnYellifhg48D1
|
|
zt0YlwXowazhTV4WhS3tPMuAz36/0v7VyTgZu0M0KbZmzy2LRn6a2LuOZYhRaqj/
|
|
eFHi6SEn13d+gChs6kxQnHNxFvZeVBRNTBS5Z6BKIKraC6CgAbdCJDhRingvxIHm
|
|
gXVi3uOvXXQva0H7ecOoOnJsRvmmA3SBAd+M6wIDAQABAoIBAQCyB0FeMuKm8bRo
|
|
18aKjFGSPEoZi53srIz5bvUgIi92TBLez7ZnzL6Iym26oJ+5th+lCHGO/dqlhXio
|
|
pI50C5Yc9TFbblb/ECOsuCuuqKFjZ8CD3GVsHozXKJeMM+/o5YZXQrORj6UnwT0z
|
|
ol/JE5pIGUCIgsXX6tz9s5BP3lUAvVQHsv6+vEVKLxQ3wj/1vIL8O/CN036EV0GJ
|
|
mpkwmygPjfECT9wbWo0yn3jxJb36+M/QjjUP28oNIVn/IKoPZRXnqchEbuuCJ651
|
|
IsaFSqtiThm4WZtvCH/IDq+6/dcMucmTjIRcYwW7fdHfjplllVPve9c/OmpWEQvF
|
|
t3ArWUt5AoGBANs4764yHxo4mctLIE7G7l/tf9bP4KKUiYw4R4ByEocuqMC4yhmt
|
|
MPCfOFLOQet71OWCkjP2L/7EKUe9yx7G5KmxAHY6jOjvcRkvGsl6lWFOsQ8p126M
|
|
Y9hmGzMOjtsdhAiMmOWKzjvm4WqfMgghQe+PnjjSVkgTt+7BxpIuGBAvAoGBANBg
|
|
26FF5cDLpixOd3Za1YXsOgguwCaw3Plvi7vUZRpa/zBMELEtyOebfakkIRWNm07l
|
|
nE+lAZwxm+29PTD0nqCFE91teyzjnQaLO5kkAdJiFuVV3icLOGo399FrnJbKensm
|
|
FGSli+3KxQhCNIJJfgWzq4bE0ioAMjdGbYXzIYQFAoGBAM6tuDJ36KDU+hIS6wu6
|
|
O2TPSfZhF/zPo3pCWQ78/QDb+Zdw4IEiqoBA7F4NPVLg9Y/H8UTx9r/veqe7hPOo
|
|
Ok7NpIzSmKTHkc5XfZ60Zn9OLFoKbaQ40a1kXoJdWEu2YROaUlAe9F6/Rog6PHYz
|
|
vLE5qscRbu0XQhLkN+z7bg5bAoGBAKDsbDEb/dbqbyaAYpmwhH2sdRSkphg7Niwc
|
|
DNm9qWa1J6Zw1+M87I6Q8naRREuU1IAVqqWHVLr/ROBQ6NTJ1Uc5/qFeT2XXUgkf
|
|
taMKv61tuyjZK3sTmznMh0HfzUpWjEhWnCEuB+ZYVdmO52ZGw2A75RdrILL2+9Dc
|
|
PvDXVubRAoGAdqXeSWoLxuzZXzl8rsaKrQsTYaXnOWaZieU1SL5vVe8nK257UDqZ
|
|
E3ng2j5XPTUWli+aNGFEJGRoNtcQvO60O/sFZUhu52sqq9mWVYZNh1TB5aP8X+pV
|
|
iFcZOLUvQEcN6PA+YQK5FU11rAI1M0Gm5RDnVnUl0L2xfCYxb7FzV6Y=
|
|
-----END RSA PRIVATE KEY-----
|
|
]]></artwork></figure>
|
|
|
|
<t>
|
|
Signing of "192.0.2.0/24,US,WA,Seattle," (terminated by CR and LF),
|
|
yields the following detached CMS signature.</t>
|
|
|
|
<figure><artwork><![CDATA[
|
|
# RPKI Signature: 192.0.2.0/24
|
|
# MIIGQAYJKoZIhvcNAQcCoIIGMTCCBi0CAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
|
|
# IhvcNAQkQAS+gggRaMIIEVjCCAz6gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZv
|
|
# AwDQYJKoZIhvcNAQELBQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExR
|
|
# TNFMTg0RUZDMUUyOTdCMzc3ODY0MjAeFw0yMzA5MjMxNTU1MzhaFw0yNDA3MTkx
|
|
# NTU1MzhaMDMxMTAvBgNVBAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM
|
|
# 0NUFCRjA1M0ExODcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycT
|
|
# QrOb/qB2W3i3Ki8PhA/DEWyii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQg
|
|
# tPCVwr62hTQZCIowBN0BL0cK0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZm
|
|
# r5xphXRvE+mzuJVLgu2V1upmBXuWloeymudh6WWJ+GDjwPXO3RiXBejBrOFNXha
|
|
# FLe08y4DPfr/S/tXJOBm7QzQptmbPLYtGfprYu45liFFqqP94UeLpISfXd36AKG
|
|
# zqTFCcc3EW9l5UFE1MFLlnoEogqtoLoKABt0IkOFGKeC/EgeaBdWLe469ddC9rQ
|
|
# ft5w6g6cmxG+aYDdIEB34zrAgMBAAGjggFgMIIBXDAdBgNVHQ4EFgQUkUZSo71R
|
|
# wUQmAZiIn1xFq/BToYcwHwYDVR0jBBgwFoAUOs4s70+yG30R4+GE78Hil7N3hkI
|
|
# wDgYDVR0PAQH/BAQDAgeAMBgGA1UdIAEB/wQOMAwwCgYIKwYBBQUHDgIwYQYDVR
|
|
# 0fBFowWDBWoFSgUoZQcnN5bmM6Ly9ycGtpLmV4YW1wbGUubmV0L3JlcG9zaXRvc
|
|
# nkvM0FDRTJDRUY0RkIyMUI3RDExRTNFMTg0RUZDMUUyOTdCMzc3ODY0Mi5jcmww
|
|
# bAYIKwYBBQUHAQEEYDBeMFwGCCsGAQUFBzAChlByc3luYzovL3Jwa2kuZXhhbXB
|
|
# sZS5uZXQvcmVwb3NpdG9yeS8zQUNFMkNFRjRGQjIxQjdEMTFFM0UxODRFRkMxRT
|
|
# I5N0IzNzc4NjQyLmNlcjAfBggrBgEFBQcBBwEB/wQQMA4wDAQCAAEwBgMEAMAAA
|
|
# jANBgkqhkiG9w0BAQsFAAOCAQEAlxt25FUee0+uCidTH+4p7At3u2ncgHcGTsag
|
|
# 3UcoPjcE/I1JgQJRu9TiM4iNB1C7Lbdd131gMdliL5GQ3P4QfKnfkuPR6S1V8su
|
|
# q6ZT1KQRyLJx+EPgDN2rb/iji0TOK6RKPNBdGlXVLjth4x/uu1O4V54GLEhDAPQ
|
|
# C8IUm5intL/Hx1M1x2ptN/+j5HD3XUXd3x13yis6u758nbA7ND40JNhGG5JNGQg
|
|
# DchL4IQzIhylMNC+bKUiyyMHz3MqoVAklIB86IWUcv72Mekq+i46T/w3RnaGn4x
|
|
# 7RAJctVJWw3e5YMrFnQcuuaGOs0QcoxW7Bi4W7Eg8fK1fd/f6fjZ9zGCAaowggG
|
|
# mAgEDgBSRRlKjvVHBRCYBmIifXEWr8FOhhzALBglghkgBZQMEAgGgazAaBgkqhk
|
|
# iG9w0BCQMxDQYLKoZIhvcNAQkQAS8wHAYJKoZIhvcNAQkFMQ8XDTIzMDkyMzE1N
|
|
# TUzOFowLwYJKoZIhvcNAQkEMSIEICvi8p5S8ckg2wTRhDBQzGijjyqs5T6I+4Vt
|
|
# BHypfcEWMA0GCSqGSIb3DQEBAQUABIIBAKZND7pKdVdfpB6zaJN89wTt+sXd0io
|
|
# 0WULMc+o6gRJFt3wmKNW2nYPrDbocJ+Q/rDMGxbp4QetJ0MQtn1+AYAS8v5jPDO
|
|
# 4a63U4/mJ2D3wSnQsDP0lUVknqRzfnS66HgHqiOVdHB0U+OnMEJuqHNTLx0dknb
|
|
# L3zwxyDJTHdo+dMB0U9xdcjwpsPM3xqg57EXj5EIQK5JbardXCjrsysAnEdktUY
|
|
# oyayGNbbQelANYJcOmuHhSXArR+qqzvNP2MDRqqKEcpd65YW6FSnqlVMIBH2M3P
|
|
# D2F0p3sdm4IeGAZWaERVB4AXO1PUFDNdhamr4XpIwqIoAig7xiLm7j8qu5Oc=
|
|
# End Signature: 192.0.2.0/24
|
|
]]></artwork></figure>
|
|
|
|
</section>
|
|
</back>
|
|
</rfc>
|