1370 lines
59 KiB
XML
1370 lines
59 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-03"
|
|
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 data files and describes an optional scheme that uses
|
|
the Resource Public Key Infrastructure to authenticate the
|
|
geofeed datafiles.
|
|
</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>
|
|
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"/>. 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. 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. If there is more
|
|
than one, 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 geofeed files, 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 geofeed URLs. This
|
|
uses efficient bulk access instead of fetching via brute-force
|
|
search through the IP space.
|
|
</t>
|
|
|
|
<t>
|
|
When an inetnum: with a geofeed file reference is identified,
|
|
the file MUST be downloaded using HTTPS.
|
|
</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>
|
|
and the file geofeed_1 contains geolocation data about
|
|
192.0.2.0/29, this MUST be 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>
|
|
If an inetnum: object has both remarks: with geofeed data and
|
|
also has a geofeed: attribute, the geofeed: attribute SHOULD be
|
|
used and the remarks: ignored.
|
|
</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>
|
|
</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 some 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 MAY 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 MUST 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 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 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 MUST 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
|
|
MUST appear in both the SignedData
|
|
DigestAlgorithmIdentifiers and the SignerInfo
|
|
DigestAlgorithmIdentifier <xref target="RFC5652"
|
|
format="default"/>.
|
|
</t>
|
|
<t>
|
|
The address range of the signing certificate MUST cover all
|
|
prefixes on the geofeed file it signs. The certificate MUST NOT
|
|
include the Autonomous System Identifier Delegation certificate
|
|
extension <xref target="RFC3779"/>.
|
|
</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.
|
|
</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>
|
|
The CA MUST sign only one Geofeed with each generated private
|
|
key and MUST generate a new key pair for each new version of the
|
|
Geofeed. 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 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"/> MUST match
|
|
the SubjectKeyIdentifier in the CMS SignerInfo
|
|
SignerIdentifier <xref target="RFC5652" format="default"/>.
|
|
If the key identifiers do not match, then validation
|
|
MUST fail.</t>
|
|
<t>
|
|
Validation of the signer's certificate MUST
|
|
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 MUST 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
|
|
MUST 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
|
|
MUST 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 MUST
|
|
fail.
|
|
</li>
|
|
</ol>
|
|
<t>
|
|
All of these steps MUST 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>
|
|
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>
|
|
Therefore an extension using "inherit" MUST NOT 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 MUST be hidden as a series of "#" comments at the
|
|
end of the geofeed file. The following is a cryptographically
|
|
incorrect, albeit simple, example. A correct and full example is
|
|
in <xref target="example" format="default"/>.
|
|
</t>
|
|
<sourcecode type=""><![CDATA[
|
|
# RPKI Signature: 192.0.2.0 - 192.0.2.255
|
|
# MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
|
|
# IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
|
|
...
|
|
# imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa
|
|
# O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=
|
|
# End Signature: 192.0.2.0 - 192.0.2.255
|
|
]]></sourcecode>
|
|
<t>
|
|
The signature does not cover the signature lines.
|
|
</t>
|
|
<t>
|
|
The bracketing "# RPKI Signature:" and "# End Signature:"
|
|
MUST be present following the model as shown.
|
|
Their IP address range MUST 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 MUST be published via and fetched using
|
|
HTTPS <xref target="RFC2818" 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. The
|
|
validation model in Section <xref target="auth"/> handles this
|
|
issue within the RPSL model.
|
|
</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 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>
|
|
Currently, 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>
|
|
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 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;
|
|
Murray Kucherawy; Paul Kyzivat (GENART); Rob Wilton; Roman
|
|
Danyliw; and Ties de Kock.</t>
|
|
</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.6487.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.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.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>
|
|
|
|
<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
|
|
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 AS numbers.</t>
|
|
|
|
<figure><artwork><![CDATA[
|
|
-----BEGIN CERTIFICATE-----
|
|
MIIEPjCCAyagAwIBAgIUPsUFJ4e/7pKZ6E14aBdkbYzms1gwDQYJKoZIhvcNAQEL
|
|
BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yMDA5MDMxODU0NTRaFw0zMDA5
|
|
MDExODU0NTRaMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEwggEiMA0GCSqGSIb3DQEB
|
|
AQUAA4IBDwAwggEKAoIBAQCelMmMDCGBhqn/a3VrNAoKMr1HVLKxGoG7VF/13HZJ
|
|
0twObUZlh3Jz+XeD+kNAURhELWTrsgdTkQQfqinqOuRemxTl55+x7nLpe5nmwaBH
|
|
XqqDOHubmkbAGanGcm6T/rD9KNk1Z46Uc2p7UYu0fwNO0mo0aqFL2FSyvzZwziNe
|
|
g7ELYZ4a3LvGn81JfP/JvM6pgtoMNuee5RV6TWaz7LV304ICj8Bhphy/HFpOA1rb
|
|
O9gs8CUMgqz+RroAIa8cV8gbF/fPCz9Ofl7Gdmib679JxxFrW4wRJ0nMJgJmsZXq
|
|
jaVc0g7ORc+eIAcHw7Uroc6h7Y7lGjOkDZF75j0mLQa3AgMBAAGjggGEMIIBgDAd
|
|
BgNVHQ4EFgQU3hNEuwvUGNCHY1TBatcUR03pNdYwHwYDVR0jBBgwFoAU3hNEuwvU
|
|
GNCHY1TBatcUR03pNdYwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYw
|
|
GAYDVR0gAQH/BA4wDDAKBggrBgEFBQcOAjCBuQYIKwYBBQUHAQsEgawwgakwPgYI
|
|
KwYBBQUHMAqGMnJzeW5jOi8vcnBraS5leGFtcGxlLm5ldC9yZXBvc2l0b3J5L2V4
|
|
YW1wbGUtdGEubWZ0MDUGCCsGAQUFBzANhilodHRwczovL3JyZHAuZXhhbXBsZS5u
|
|
ZXQvbm90aWZpY2F0aW9uLnhtbDAwBggrBgEFBQcwBYYkcnN5bmM6Ly9ycGtpLmV4
|
|
YW1wbGUubmV0L3JlcG9zaXRvcnkvMCcGCCsGAQUFBwEHAQH/BBgwFjAJBAIAATAD
|
|
AwEAMAkEAgACMAMDAQAwHgYIKwYBBQUHAQgEEjAQoA4wDDAKAgEAAgUA/////zAN
|
|
BgkqhkiG9w0BAQsFAAOCAQEAgZFQ0Sf3CI5Hwev61AUWHYOFniy69PuDTq+WnhDe
|
|
xX5rpjSDRrs5L756KSKJcaOJ36lzO45lfOPSY9fH6x30pnipaqRA7t5rApky24jH
|
|
cSUA9iRednzxhVyGjWKnfAKyNo2MYfaOAT0db1GjyLKbOADI9FowtHBUu+60ykcM
|
|
Quz66XrzxtmxlrRcAnbv/HtV17qOd4my6q5yjTPR1dmYN9oR/2ChlXtGE6uQVguA
|
|
rvNZ5CwiJ1TgGGTB7T8ORHwWU6dGTc0jk2rESAaikmLi1roZSNC21fckhapEit1a
|
|
x8CyiVxjcVc5e0AmS1rJfL6LIfwmtive/N/eBtIM92HkBA==
|
|
-----END CERTIFICATE-----
|
|
]]></artwork></figure>
|
|
|
|
<t>
|
|
The CRL issued by the trust anchor.</t>
|
|
|
|
<figure><artwork><![CDATA[
|
|
-----BEGIN X509 CRL-----
|
|
MIIBjjB4AgEBMA0GCSqGSIb3DQEBCwUAMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEX
|
|
DTIzMDkyMDE4MDkxMVoXDTIzMTAyMDE4MDkxMVqgLzAtMB8GA1UdIwQYMBaAFMC9
|
|
Ul2+0niyFuyzo0OV0gYLmQgyMAoGA1UdFAQDAgEBMA0GCSqGSIb3DQEBCwUAA4IB
|
|
AQALdNwYgIPHVauhT9yGV2Oj28aj6yI8X/xQz53Gh7zqz4AfKSA3rmFUiQiPnLiA
|
|
oO+oI83tzoTwxwVRdGpzc8ZhZ5yCwAQYZdiGteagLFi1zghWbRNWH/m7q/ypw1xd
|
|
GZs3ow6b29OMr9ue/5s++bWMQ6oHh24cVB5S9kX3v7N0OeE0/SGcKtaeT+WE5SWC
|
|
hudIB52s5NPcKu1SEnn/D8JLGoadxatmFEGMfRX2Wo9dcntcyCr/MPl6ZhvM9tsF
|
|
Oxoom7RRnAfz+AWwptYrCkvKFdk974UCe9Bq2Bq3xuhrLs1kT6+yy0U9y7hyJYK/
|
|
Dq9IJ9RuBsQagykwbwLbzlTr
|
|
-----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-----
|
|
MIIFBzCCA++gAwIBAgIUcyCzS10hdfG65kbRq7toQAvRDLUwDQYJKoZIhvcNAQEL
|
|
BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yMzA5MTYyMTAzMjhaFw0yNDA5
|
|
MTUyMTAzMjhaMDMxMTAvBgNVBAMTKDNBQ0UyQ0VGNEZCMjFCN0QxMUUzRTE4NEVG
|
|
QzFFMjk3QjM3Nzg2NDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc
|
|
zz1qwTxC2ocw5rqp8ktm2XyYkl8riBVuqlXwfefTxsR2YFpgz9vkYUd5Az9EVEG7
|
|
6wGIyZbtmhK63eEeaqbKz2GHub467498BXeVrYysO+YuIGgCEYKznNDZ4j5aaDbo
|
|
j5+4/z0Qvv6HEsxQd0f8br6lKJwgeRM6+fm7796HNPB0aqD7Zj9NRCLXjbB0DCgJ
|
|
liH6rXMKR86ofgll9V2mRjesvhdKYgkGbOif9rvxVpLJ/6zdru5CE9yeuJZ59l+n
|
|
YH/r6PzdJ4Q7yKrJX8qD6A60j4+biaU4MQ72KpsjhQNTTqF/HRwi0N54GDaknEwE
|
|
TnJQHgLJDYqww9yKWtjjAgMBAAGjggIvMIICKzAdBgNVHQ4EFgQUOs4s70+yG30R
|
|
4+GE78Hil7N3hkIwHwYDVR0jBBgwFoAU3hNEuwvUGNCHY1TBatcUR03pNdYwDwYD
|
|
VR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwGAYDVR0gAQH/BA4wDDAKBggr
|
|
BgEFBQcOAjBhBgNVHR8EWjBYMFagVKBShlByc3luYzovL3Jwa2kuZXhhbXBsZS5u
|
|
ZXQvcmVwb3NpdG9yeS8zQUNFMkNFRjRGQjIxQjdEMTFFM0UxODRFRkMxRTI5N0Iz
|
|
Nzc4NjQyLmNybDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMnJzeW5jOi8v
|
|
cnBraS5leGFtcGxlLm5ldC9yZXBvc2l0b3J5L2V4YW1wbGUtdGEuY2VyMIG5Bggr
|
|
BgEFBQcBCwSBrDCBqTA+BggrBgEFBQcwCoYycnN5bmM6Ly9ycGtpLmV4YW1wbGUu
|
|
bmV0L3JlcG9zaXRvcnkvZXhhbXBsZS1jYS5tZnQwNQYIKwYBBQUHMA2GKWh0dHBz
|
|
Oi8vcnJkcC5leGFtcGxlLm5ldC9ub3RpZmljYXRpb24ueG1sMDAGCCsGAQUFBzAF
|
|
hiRyc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVwb3NpdG9yeS8wHwYIKwYBBQUH
|
|
AQcBAf8EEDAOMAwEAgABMAYDBADAAAIwHgYIKwYBBQUHAQgEEjAQoA4wDDAKAgMA
|
|
+/ACAwD78TANBgkqhkiG9w0BAQsFAAOCAQEAkWoRJBJRgIMRkTUgPDG/rqcd/fz+
|
|
eN8L3Yme1hNJuAnkf6S3pr5GT1NG9hVTphLFPI4jPSoPZSEQtZ6gsswU3KacnS2A
|
|
VtgHYfZA9gfRHhURuiWvFNSp+d7A2MeBmmRyBOD3a5v4f+wNoXPgPhUTZUsXh2Q4
|
|
q7WFgiQp6P8vdIXjZDKFB7Xtu7Fl1S5RVowV68DexjVfmaPTPZjetHaAqpz6C4/E
|
|
s4NArJzIL+8sqmIeuWUD11WXQ3wsC0IWuPMi6XOJQnPQQFtMPr79cftsw+Ynr/vc
|
|
F+WPd2Mdaby93ASOE2MyXdaaOf8Av3wIpMvhMuAuM03V/mPVksqxUbfOLw==
|
|
-----END CERTIFICATE-----
|
|
]]></artwork></figure>
|
|
|
|
<t>
|
|
The CRL issued by the CA.</t>
|
|
|
|
<figure><artwork><![CDATA[
|
|
-----BEGIN X509 CRL-----
|
|
MIIBrTCBlgIBATANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEygzQUNFMkNFRjRG
|
|
QjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyFw0yMzA5MjAxODIzNTBaFw0y
|
|
MzEwMjAxODIzNTBaoC8wLTAfBgNVHSMEGDAWgBQ6zizvT7IbfRHj4YTvweKXs3eG
|
|
QjAKBgNVHRQEAwIBATANBgkqhkiG9w0BAQsFAAOCAQEAiiqMfYMxDTKYosc77UM0
|
|
qzLuVsik3QHRMZI1YC/WVMNnuNrppjKr5e9lrfHF92XX4nO7odJk9TuCT+xpn6of
|
|
/E5XQMh0btrgRO4lFS8SBqhD32++j65EWeOVHxwwiVIw0Nq9l+5kNa3a5Rfvr03d
|
|
/c2DvgIUmrhQkJqUEYH0009oTsx2cFNIURhgpwdXulCcaPVO8QnKE0Vz7JwmuQJH
|
|
U1vj8wB7rbW9gszbimInb1WNjR8cGL/USnDBTtoc1GSjQyhPck/UGyh5zgrmbS5R
|
|
HpDVvN3FM6f8nfuz8qNy7TC8umV8IUzkJ+3+bxlUnyPUV9VNuQOQJHIgWzciA0cS
|
|
XQ==
|
|
-----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-----
|
|
MIIEZDCCA0ygAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZuwwDQYJKoZIhvcNAQEL
|
|
BQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExRTNFMTg0RUZDMUUyOTdC
|
|
Mzc3ODY0MjAeFw0yMzA5MTYyMTAzMjhaFw0yNDA3MTIyMTAzMjhaMDMxMTAvBgNV
|
|
BAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM0NUFCRjA1M0ExODcwggEi
|
|
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycTQrOb/qB2W3i3Ki8PhA/DEW
|
|
yii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQgtPCVwr62hTQZCIowBN0BL0c
|
|
K0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZmr5xphXRvE+mzuJVLgu2V1upm
|
|
BXuWloeymudh6WWJ+GDjwPXO3RiXBejBrOFNXhaFLe08y4DPfr/S/tXJOBm7QzQp
|
|
tmbPLYtGfprYu45liFFqqP94UeLpISfXd36AKGzqTFCcc3EW9l5UFE1MFLlnoEog
|
|
qtoLoKABt0IkOFGKeC/EgeaBdWLe469ddC9rQft5w6g6cmxG+aYDdIEB34zrAgMB
|
|
AAGjggFuMIIBajAdBgNVHQ4EFgQUkUZSo71RwUQmAZiIn1xFq/BToYcwHwYDVR0j
|
|
BBgwFoAUOs4s70+yG30R4+GE78Hil7N3hkIwDAYDVR0TAQH/BAIwADAOBgNVHQ8B
|
|
Af8EBAMCB4AwGAYDVR0gAQH/BA4wDDAKBggrBgEFBQcOAjBhBgNVHR8EWjBYMFag
|
|
VKBShlByc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVwb3NpdG9yeS8zQUNFMkNF
|
|
RjRGQjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyLmNybDBsBggrBgEFBQcB
|
|
AQRgMF4wXAYIKwYBBQUHMAKGUHJzeW5jOi8vcnBraS5leGFtcGxlLm5ldC9yZXBv
|
|
c2l0b3J5LzNBQ0UyQ0VGNEZCMjFCN0QxMUUzRTE4NEVGQzFFMjk3QjM3Nzg2NDIu
|
|
Y2VyMB8GCCsGAQUFBwEHAQH/BBAwDjAMBAIAATAGAwQAwAACMA0GCSqGSIb3DQEB
|
|
CwUAA4IBAQAIdkoBMQydWkkaE91zFTX6xIzzDhllfDR5bgw8C2XrAkTiWlMce+/A
|
|
794a7j3+fIAyDrQ1fjgPLof6I7xMaiqyNtb+5GqXNk+sHwjg6AnInZV2Xgz2X6lJ
|
|
dtNck25zGwfj/RZ8BxO+UUzP0JUOCTAaCed2KOVF9qWfmXeZ2HPvZVD+01G0PNKd
|
|
DGKzBmtWKzXsWVk00fvm+xaDs/sBTf28O907AUM+2ipuFYfWYc2mPaT3C4uK0udl
|
|
3/FhUzH6loqs/c1jIsL3mWd8iR2eAwBa+rsp9sc3wbnPCjFOuFZKN85nnXzrbJ6d
|
|
FjqNix9Z2it7TCmU89JltreRt5Q1xX+m
|
|
-----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 1124: SEQUENCE {
|
|
4 844: 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 EC
|
|
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 16/09/2023 21:03:28 GMT
|
|
120 13: UTCTime 12/07/2024 21:03:28 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 366: [3] {
|
|
486 362: SEQUENCE {
|
|
490 29: SEQUENCE {
|
|
492 3: OBJECT IDENTIFIER
|
|
: subjectKeyIdentifier (2 5 29 14)
|
|
497 22: OCTET STRING, encapsulates {
|
|
499 20: OCTET STRING
|
|
: 91 46 52 A3 BD 51 C1 44 26 01 98 88 9F 5C 45 AB
|
|
: F0 53 A1 87
|
|
: }
|
|
: }
|
|
521 31: SEQUENCE {
|
|
523 3: OBJECT IDENTIFIER
|
|
: authorityKeyIdentifier (2 5 29 35)
|
|
528 24: OCTET STRING, encapsulates {
|
|
530 22: SEQUENCE {
|
|
532 20: [0]
|
|
: 3A CE 2C EF 4F B2 1B 7D 11 E3 E1 84 EF C1 E2 97
|
|
: B3 77 86 42
|
|
: }
|
|
: }
|
|
: }
|
|
554 12: SEQUENCE {
|
|
556 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19)
|
|
561 1: BOOLEAN TRUE
|
|
564 2: OCTET STRING, encapsulates {
|
|
566 0: SEQUENCE {}
|
|
: }
|
|
: }
|
|
568 14: SEQUENCE {
|
|
570 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
|
|
575 1: BOOLEAN TRUE
|
|
578 4: OCTET STRING, encapsulates {
|
|
580 2: BIT STRING 7 unused bits
|
|
: '1'B (bit 0)
|
|
: }
|
|
: }
|
|
584 24: SEQUENCE {
|
|
586 3: OBJECT IDENTIFIER
|
|
: certificatePolicies (2 5 29 32)
|
|
591 1: BOOLEAN TRUE
|
|
594 14: OCTET STRING, encapsulates {
|
|
596 12: SEQUENCE {
|
|
598 10: SEQUENCE {
|
|
600 8: OBJECT IDENTIFIER
|
|
: resourceCertificatePolicy
|
|
: (1 3 6 1 5 5 7 14 2)
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
610 97: SEQUENCE {
|
|
612 3: OBJECT IDENTIFIER
|
|
: cRLDistributionPoints (2 5 29 31)
|
|
617 90: OCTET STRING, encapsulates {
|
|
619 88: SEQUENCE {
|
|
621 86: SEQUENCE {
|
|
623 84: [0] {
|
|
625 82: [0] {
|
|
627 80: [6]
|
|
: 'rsync://rpki.example.net/repository/3ACE'
|
|
: '2CEF4FB21B7D11E3E184EFC1E297B3778642.crl'
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
709 108: SEQUENCE {
|
|
711 8: OBJECT IDENTIFIER
|
|
: authorityInfoAccess (1 3 6 1 5 5 7 1 1)
|
|
721 96: OCTET STRING, encapsulates {
|
|
723 94: SEQUENCE {
|
|
725 92: SEQUENCE {
|
|
727 8: OBJECT IDENTIFIER
|
|
: caIssuers (1 3 6 1 5 5 7 48 2)
|
|
737 80: [6]
|
|
: 'rsync://rpki.example.net/repository/3ACE'
|
|
: '2CEF4FB21B7D11E3E184EFC1E297B3778642.cer'
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
819 31: SEQUENCE {
|
|
821 8: OBJECT IDENTIFIER
|
|
: ipAddrBlocks (1 3 6 1 5 5 7 1 7)
|
|
831 1: BOOLEAN TRUE
|
|
834 16: OCTET STRING, encapsulates {
|
|
836 14: SEQUENCE {
|
|
838 12: SEQUENCE {
|
|
840 2: OCTET STRING 00 01
|
|
844 6: SEQUENCE {
|
|
846 4: BIT STRING
|
|
: '010000000000000000000011'B
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
: }
|
|
852 13: SEQUENCE {
|
|
854 9: OBJECT IDENTIFIER
|
|
: sha256WithRSAEncryption (1 2 840 113549 1 1 11)
|
|
865 0: NULL
|
|
: }
|
|
867 257: BIT STRING
|
|
: 08 76 4A 01 31 0C 9D 5A 49 1A 13 DD 73 15 35 FA
|
|
: C4 8C F3 0E 19 65 7C 34 79 6E 0C 3C 0B 65 EB 02
|
|
: 44 E2 5A 53 1C 7B EF C0 EF DE 1A EE 3D FE 7C 80
|
|
: 32 0E B4 35 7E 38 0F 2E 87 FA 23 BC 4C 6A 2A B2
|
|
: 36 D6 FE E4 6A 97 36 4F AC 1F 08 E0 E8 09 C8 9D
|
|
: 95 76 5E 0C F6 5F A9 49 76 D3 5C 93 6E 73 1B 07
|
|
: E3 FD 16 7C 07 13 BE 51 4C CF D0 95 0E 09 30 1A
|
|
: 09 E7 76 28 E5 45 F6 A5 9F 99 77 99 D8 73 EF 65
|
|
: 50 FE D3 51 B4 3C D2 9D 0C 62 B3 06 6B 56 2B 35
|
|
: EC 59 59 34 D1 FB E6 FB 16 83 B3 FB 01 4D FD BC
|
|
: 3B DD 3B 01 43 3E DA 2A 6E 15 87 D6 61 CD A6 3D
|
|
: A4 F7 0B 8B 8A D2 E7 65 DF F1 61 53 31 FA 96 8A
|
|
: AC FD CD 63 22 C2 F7 99 67 7C 89 1D 9E 03 00 5A
|
|
: FA BB 29 F6 C7 37 C1 B9 CF 0A 31 4E B8 56 4A 37
|
|
: CE 67 9D 7C EB 6C 9E 9D 16 3A 8D 8B 1F 59 DA 2B
|
|
: 7B 4C 29 94 F3 D2 65 B6 B7 91 B7 94 35 C5 7F A6
|
|
: }
|
|
]]></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
|
|
# MIIGTgYJKoZIhvcNAQcCoIIGPzCCBjsCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
|
|
# IhvcNAQkQAS+gggRoMIIEZDCCA0ygAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
|
|
# wwDQYJKoZIhvcNAQELBQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExR
|
|
# TNFMTg0RUZDMUUyOTdCMzc3ODY0MjAeFw0yMzA5MTYyMTAzMjhaFw0yNDA3MTIy
|
|
# MTAzMjhaMDMxMTAvBgNVBAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM
|
|
# 0NUFCRjA1M0ExODcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycT
|
|
# QrOb/qB2W3i3Ki8PhA/DEWyii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQg
|
|
# tPCVwr62hTQZCIowBN0BL0cK0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZm
|
|
# r5xphXRvE+mzuJVLgu2V1upmBXuWloeymudh6WWJ+GDjwPXO3RiXBejBrOFNXha
|
|
# FLe08y4DPfr/S/tXJOBm7QzQptmbPLYtGfprYu45liFFqqP94UeLpISfXd36AKG
|
|
# zqTFCcc3EW9l5UFE1MFLlnoEogqtoLoKABt0IkOFGKeC/EgeaBdWLe469ddC9rQ
|
|
# ft5w6g6cmxG+aYDdIEB34zrAgMBAAGjggFuMIIBajAdBgNVHQ4EFgQUkUZSo71R
|
|
# wUQmAZiIn1xFq/BToYcwHwYDVR0jBBgwFoAUOs4s70+yG30R4+GE78Hil7N3hkI
|
|
# wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCB4AwGAYDVR0gAQH/BA4wDDAKBg
|
|
# grBgEFBQcOAjBhBgNVHR8EWjBYMFagVKBShlByc3luYzovL3Jwa2kuZXhhbXBsZ
|
|
# S5uZXQvcmVwb3NpdG9yeS8zQUNFMkNFRjRGQjIxQjdEMTFFM0UxODRFRkMxRTI5
|
|
# N0IzNzc4NjQyLmNybDBsBggrBgEFBQcBAQRgMF4wXAYIKwYBBQUHMAKGUHJzeW5
|
|
# jOi8vcnBraS5leGFtcGxlLm5ldC9yZXBvc2l0b3J5LzNBQ0UyQ0VGNEZCMjFCN0
|
|
# QxMUUzRTE4NEVGQzFFMjk3QjM3Nzg2NDIuY2VyMB8GCCsGAQUFBwEHAQH/BBAwD
|
|
# jAMBAIAATAGAwQAwAACMA0GCSqGSIb3DQEBCwUAA4IBAQAIdkoBMQydWkkaE91z
|
|
# FTX6xIzzDhllfDR5bgw8C2XrAkTiWlMce+/A794a7j3+fIAyDrQ1fjgPLof6I7x
|
|
# MaiqyNtb+5GqXNk+sHwjg6AnInZV2Xgz2X6lJdtNck25zGwfj/RZ8BxO+UUzP0J
|
|
# UOCTAaCed2KOVF9qWfmXeZ2HPvZVD+01G0PNKdDGKzBmtWKzXsWVk00fvm+xaDs
|
|
# /sBTf28O907AUM+2ipuFYfWYc2mPaT3C4uK0udl3/FhUzH6loqs/c1jIsL3mWd8
|
|
# iR2eAwBa+rsp9sc3wbnPCjFOuFZKN85nnXzrbJ6dFjqNix9Z2it7TCmU89Jltre
|
|
# Rt5Q1xX+mMYIBqjCCAaYCAQOAFJFGUqO9UcFEJgGYiJ9cRavwU6GHMAsGCWCGSA
|
|
# FlAwQCAaBrMBoGCSqGSIb3DQEJAzENBgsqhkiG9w0BCRABLzAcBgkqhkiG9w0BC
|
|
# QUxDxcNMjMwOTE2MjEwMzI4WjAvBgkqhkiG9w0BCQQxIgQgK+LynlLxySDbBNGE
|
|
# MFDMaKOPKqzlPoj7hW0EfKl9wRYwDQYJKoZIhvcNAQEBBQAEggEAm1SGhxyTWRb
|
|
# jf+ewdePchggMKR8zY7FRy+Z5ietrNaWkF2ZgqluVmm3mRDpQDeqTYrcTcBdR3o
|
|
# szs89XxWNf81Afs1mBcUdgPHxcghJNoVsDFmcPd+LEFikOtGjaFCwS2meF3RYaM
|
|
# 51jKer8SObP9nqV1JdPYzaArIpzhjHUA1wktTblEmg9lEOJPqALMI9uL7ngcKaE
|
|
# w4omrcNSBXt9vqge/I5wG7q9tMw2RRcYXTj1XG6nSm7bo9L4JQfBrsubaANmGO9
|
|
# NEAZeHyTQq7TzO9w7KBsB3Cg8qRhCzAY8bznt+r1DVPpQj4EHUBizYUMQRCxD5o
|
|
# IUjEELzssfleF8pQ==
|
|
# End Signature: 192.0.2.0/24
|
|
]]></artwork></figure>
|
|
|
|
</section>
|
|
</back>
|
|
</rfc>
|