-07 published
This commit is contained in:
parent
879db0ac8b
commit
e64c9fc9bb
1 changed files with 36 additions and 40 deletions
|
|
@ -8,7 +8,7 @@
|
|||
<?rfc compact="yes"?>
|
||||
<?rfc subcompact="no"?>
|
||||
|
||||
<rfc category="std" docName="draft-ietf-opsawg-9092-update-06"
|
||||
<rfc category="std" docName="draft-ietf-opsawg-9092-update-07"
|
||||
submissionType="IETF" consensus="true" ipr="trust200902"
|
||||
obsoletes="9092" version="2" >
|
||||
|
||||
|
|
@ -82,9 +82,10 @@
|
|||
<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.
|
||||
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>
|
||||
|
||||
|
|
@ -381,16 +382,10 @@
|
|||
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.
|
||||
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>
|
||||
|
|
@ -518,13 +513,13 @@
|
|||
</t>
|
||||
|
||||
<t>
|
||||
The 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 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"/>).
|
||||
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>
|
||||
|
|
@ -551,7 +546,7 @@
|
|||
|
||||
<li>
|
||||
Validation of the signer's certificate MUST ensure that it is
|
||||
part of the current <xref target="RFC6486"/> manifest and that
|
||||
part of the current <xref target="RFC9286"/> manifest and that
|
||||
all resources are covered by the RPKI certificate.
|
||||
</li>
|
||||
|
||||
|
|
@ -652,7 +647,7 @@
|
|||
</t>
|
||||
<t>
|
||||
The geofeed files MUST be published via and fetched using
|
||||
HTTPS <xref target="RFC2818" format="default"/>.
|
||||
HTTPS <xref target="RFC9110" format="default"/>.
|
||||
</t>
|
||||
<t>
|
||||
When using data from a geofeed file, one MUST ignore data
|
||||
|
|
@ -824,15 +819,15 @@
|
|||
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;
|
||||
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>
|
||||
Mohamed Boucadair; Murray Kucherawy; Paul Kyzivat (GENART); Rob
|
||||
Wilton; Roman Danyliw; and Ties de Kock.</t>
|
||||
</section>
|
||||
</middle>
|
||||
<back>
|
||||
|
|
@ -841,7 +836,6 @@
|
|||
<?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"?>
|
||||
|
|
@ -850,11 +844,12 @@
|
|||
<?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.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">
|
||||
|
|
@ -888,7 +883,6 @@
|
|||
</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>
|
||||
|
|
@ -943,15 +937,17 @@
|
|||
|
||||
<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>
|
||||
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 AS numbers.</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-----
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue