russ's one paragraph hack
This commit is contained in:
parent
5deadcb09b
commit
ae2a50bcd8
1 changed files with 187 additions and 158 deletions
|
|
@ -13,7 +13,7 @@
|
||||||
|
|
||||||
<front>
|
<front>
|
||||||
|
|
||||||
<title abbrev="Finding Geofeeds">Finding and Using Geofeed Data</title>
|
<title abbrev="Finding Geofeeds">A Minor Update to Finding and Using Geofeed Data</title>
|
||||||
|
|
||||||
<seriesInfo name="RFC" value="9092"/>
|
<seriesInfo name="RFC" value="9092"/>
|
||||||
|
|
||||||
|
|
@ -140,29 +140,30 @@
|
||||||
<section anchor="gf" numbered="true" toc="default">
|
<section anchor="gf" numbered="true" toc="default">
|
||||||
<name>Geofeed Files</name>
|
<name>Geofeed Files</name>
|
||||||
<t>
|
<t>
|
||||||
Geofeed files are described in <xref target="RFC8805" format="default"/>. They
|
Geofeed files are described in <xref target="RFC8805"
|
||||||
provide a facility for an IP address resource "owner" to
|
format="default"/>. They provide a facility for an IP address
|
||||||
associate those IP addresses to geographic locales.
|
resource "owner" to associate those IP addresses to geographic
|
||||||
|
locales.
|
||||||
</t>
|
</t>
|
||||||
|
|
||||||
<t>
|
<t>
|
||||||
Content providers and other parties who wish to locate an IP address
|
Content providers and other parties who wish to locate an IP
|
||||||
to a geographic locale need to find the relevant geofeed data. In
|
address to a geographic locale need to find the relevant geofeed
|
||||||
<xref target="inetnum" format="default"/>, this document specifies how
|
data. In <xref target="inetnum" format="default"/>, this
|
||||||
to find the relevant geofeed <xref target="RFC8805" format="default"/>
|
document specifies how to find the relevant geofeed <xref
|
||||||
file given an IP address.
|
target="RFC8805" format="default"/> file given an IP address.
|
||||||
</t>
|
</t>
|
||||||
<t>
|
<t>
|
||||||
Geofeed data for large providers with significant horizontal
|
Geofeed data for large providers with significant horizontal
|
||||||
scale and high granularity can be quite large. The size of a
|
scale and high granularity can be quite large. The size of a
|
||||||
file can be even larger if an unsigned geofeed file combines
|
file can be even larger if an unsigned geofeed file combines
|
||||||
data for many prefixes, if dual IPv4/IPv6 spaces are represented,
|
data for many prefixes, if dual IPv4/IPv6 spaces are
|
||||||
etc.
|
represented, etc.
|
||||||
</t>
|
</t>
|
||||||
<t>
|
<t>
|
||||||
Geofeed data do have privacy considerations (see <xref
|
Geofeed data do have privacy considerations (see <xref
|
||||||
target="privacy" format="default"/>); this process makes bulk access
|
target="privacy" format="default"/>); this process makes bulk
|
||||||
to those data easier.
|
access to those data easier.
|
||||||
</t>
|
</t>
|
||||||
<t>
|
<t>
|
||||||
This document also suggests an optional signature to strongly
|
This document also suggests an optional signature to strongly
|
||||||
|
|
@ -172,34 +173,38 @@
|
||||||
<section anchor="inetnum" numbered="true" toc="default">
|
<section anchor="inetnum" numbered="true" toc="default">
|
||||||
<name>inetnum: Class</name>
|
<name>inetnum: Class</name>
|
||||||
|
|
||||||
|
|
||||||
<t>
|
<t>
|
||||||
The original RPSL specifications starting with <xref target="RIPE81" format="default"/>, <xref target="RIPE181" format="default"/>, and a trail of
|
The original RPSL specifications starting with <xref
|
||||||
subsequent documents were written by the RIPE community. The IETF
|
target="RIPE81" format="default"/>, <xref target="RIPE181"
|
||||||
standardized RPSL in <xref target="RFC2622" format="default"/> and <xref target="RFC4012" format="default"/>. Since then, it has been modified and
|
format="default"/>, and a trail of subsequent documents were
|
||||||
extensively enhanced in the Regional Internet Registry (RIR)
|
written by the RIPE community. The IETF standardized RPSL in
|
||||||
community, mostly by RIPE <xref target="RIPE-DB" format="default"/>. Currently,
|
<xref target="RFC2622" format="default"/> and <xref
|
||||||
change control effectively lies in the operator community.
|
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>
|
||||||
|
|
||||||
<t>
|
<t>
|
||||||
The RPSL, and <xref target="RFC2725" format="default"/> and <xref target="RFC4012" format="default"/> used by the
|
The RPSL, and <xref target="RFC2725" format="default"/> and
|
||||||
Regional Internet Registries (RIRs), specify the inetnum:
|
<xref target="RFC4012" format="default"/> used by the Regional
|
||||||
database class. Each of these objects describes an IP address
|
Internet Registries (RIRs), specify the inetnum: database class.
|
||||||
range and its attributes. The inetnum: objects form a hierarchy
|
Each of these objects describes an IP address range and its
|
||||||
ordered on the address space.
|
attributes. The inetnum: objects form a hierarchy ordered on
|
||||||
|
the address space.
|
||||||
</t>
|
</t>
|
||||||
|
|
||||||
<t>
|
<t>
|
||||||
Ideally, RPSL would be augmented to define a new RPSL geofeed:
|
Ideally, RPSL would be augmented to define a new RPSL geofeed:
|
||||||
attribute in the inetnum: class. Until such time, this document
|
attribute in the inetnum: class. Until such time, this document
|
||||||
defines the syntax of a Geofeed remarks: attribute, which contains an
|
defines the syntax of a Geofeed remarks: attribute, which
|
||||||
HTTPS URL of a geofeed file. The format of the inetnum: geofeed
|
contains an HTTPS URL of a geofeed file. The format of the
|
||||||
remarks: attribute <bcp14>MUST</bcp14> be as in this example,
|
inetnum: geofeed remarks: attribute <bcp14>MUST</bcp14> be as in
|
||||||
"remarks: Geofeed ", where the token "Geofeed " <bcp14>MUST</bcp14> be
|
this example, "remarks: Geofeed ", where the token "Geofeed "
|
||||||
case sensitive, followed by a URL that will vary, but it
|
<bcp14>MUST</bcp14> be case sensitive, followed by a URL that
|
||||||
<bcp14>MUST</bcp14> refer only to a single geofeed <xref
|
will vary, but it <bcp14>MUST</bcp14> refer only to a single
|
||||||
target="RFC8805" format="default"/> file.
|
geofeed <xref target="RFC8805" format="default"/> file.
|
||||||
</t>
|
</t>
|
||||||
|
|
||||||
<sourcecode type="rpsl"> <![CDATA[
|
<sourcecode type="rpsl"> <![CDATA[
|
||||||
|
|
@ -207,47 +212,49 @@
|
||||||
remarks: Geofeed https://example.com/geofeed.csv
|
remarks: Geofeed https://example.com/geofeed.csv
|
||||||
]]></sourcecode>
|
]]></sourcecode>
|
||||||
<t>
|
<t>
|
||||||
While we leave global agreement of RPSL modification to the relevant
|
While we leave global agreement of RPSL modification to the
|
||||||
parties, we specify that a proper geofeed: attribute in the inetnum:
|
relevant parties, we specify that a proper geofeed: attribute in
|
||||||
class <bcp14>MUST</bcp14> be "geofeed:" and <bcp14>MUST</bcp14> be
|
the inetnum: class <bcp14>MUST</bcp14> be "geofeed:" and
|
||||||
followed by a single URL that will vary, but it <bcp14>MUST</bcp14>
|
<bcp14>MUST</bcp14> be followed by a single URL that will vary,
|
||||||
refer only to a single geofeed <xref target="RFC8805"
|
but it <bcp14>MUST</bcp14> refer only to a single geofeed <xref
|
||||||
format="default"/> file.
|
target="RFC8805" format="default"/> file.
|
||||||
</t>
|
</t>
|
||||||
<sourcecode type="rpsl"><![CDATA[
|
<sourcecode type="rpsl"><![CDATA[
|
||||||
inetnum: 192.0.2.0/24 # example
|
inetnum: 192.0.2.0/24 # example
|
||||||
geofeed: https://example.com/geofeed.csv
|
geofeed: https://example.com/geofeed.csv
|
||||||
]]></sourcecode>
|
]]></sourcecode>
|
||||||
<t>
|
<t>
|
||||||
Registries <bcp14>MAY</bcp14>, for the interim, provide a mix of the remarks:
|
Registries <bcp14>MAY</bcp14>, for the interim, provide a mix of
|
||||||
attribute form and the geofeed: attribute form.
|
the remarks: attribute form and the geofeed: attribute form.
|
||||||
</t>
|
</t>
|
||||||
<t>
|
<t>
|
||||||
The URL uses HTTPS, so the WebPKI provides authentication, integrity,
|
The URL uses HTTPS, so the WebPKI provides authentication,
|
||||||
and confidentiality for the fetched geofeed file. However, the WebPKI
|
integrity, and confidentiality for the fetched geofeed file.
|
||||||
can not provide authentication of IP address space assignment. In
|
However, the WebPKI can not provide authentication of IP address
|
||||||
contrast, the RPKI (see <xref target="RFC6481" format="default"/>) can
|
space assignment. In contrast, the RPKI (see <xref
|
||||||
be used to authenticate IP space assignment; see optional
|
target="RFC6481" format="default"/>) can be used to authenticate
|
||||||
authentication in <xref target="auth" format="default"/>.
|
IP space assignment; see optional authentication in <xref
|
||||||
|
target="auth" format="default"/>.
|
||||||
</t>
|
</t>
|
||||||
|
|
||||||
<t>
|
<t>
|
||||||
Until all producers of inetnum: objects, i.e., the RIRs, state that they
|
Until all producers of inetnum: objects, i.e., the RIRs, state
|
||||||
have migrated to supporting a geofeed: attribute, consumers
|
that they have migrated to supporting a geofeed: attribute,
|
||||||
looking at inetnum: objects to find geofeed URLs <bcp14>MUST</bcp14> be able to
|
consumers looking at inetnum: objects to find geofeed URLs
|
||||||
consume both the remarks: and geofeed: forms.
|
<bcp14>MUST</bcp14> be able to consume both the remarks: and
|
||||||
|
geofeed: forms.
|
||||||
|
|
||||||
|
|
||||||
The migration not only implies that the RIRs support the geofeed:
|
The migration not only implies that the RIRs support the
|
||||||
attribute, but that all registrants have migrated any inetnum: objects
|
geofeed: attribute, but that all registrants have migrated any
|
||||||
from remarks: to geofeed: attributes.
|
inetnum: objects from remarks: to geofeed: attributes.
|
||||||
</t>
|
</t>
|
||||||
|
|
||||||
<t>
|
<t>
|
||||||
Any particular inetnum: object <bcp14>MUST</bcp14> have, at most, one geofeed
|
Any particular inetnum: object <bcp14>MUST</bcp14> have, at
|
||||||
reference, whether a remarks: or a proper geofeed: attribute
|
most, one geofeed reference, whether a remarks: or a proper
|
||||||
when it is implemented. If there is more than one, all are
|
geofeed: attribute when it is implemented. If there is more
|
||||||
ignored.
|
than one, all are ignored.
|
||||||
</t>
|
</t>
|
||||||
<t>
|
<t>
|
||||||
If a geofeed CSV file describes multiple disjoint ranges of IP
|
If a geofeed CSV file describes multiple disjoint ranges of IP
|
||||||
|
|
@ -263,11 +270,11 @@
|
||||||
attribute <bcp14>SHOULD</bcp14> be preferred.
|
attribute <bcp14>SHOULD</bcp14> be preferred.
|
||||||
</t>
|
</t>
|
||||||
<t>
|
<t>
|
||||||
As inetnum: objects form a hierarchy, geofeed references <bcp14>SHOULD</bcp14>
|
As inetnum: objects form a hierarchy, geofeed references
|
||||||
be at the lowest applicable inetnum: object covering the
|
<bcp14>SHOULD</bcp14> be at the lowest applicable inetnum:
|
||||||
relevant address ranges in the referenced geofeed file. When
|
object covering the relevant address ranges in the referenced
|
||||||
fetching, the most specific inetnum: object with a geofeed
|
geofeed file. When fetching, the most specific inetnum: object
|
||||||
reference <bcp14>MUST</bcp14> be used.
|
with a geofeed reference <bcp14>MUST</bcp14> be used.
|
||||||
</t>
|
</t>
|
||||||
<t>
|
<t>
|
||||||
It is significant that geofeed data may have finer granularity
|
It is significant that geofeed data may have finer granularity
|
||||||
|
|
@ -276,12 +283,13 @@
|
||||||
which P has been subdivided into one or more longer prefixes.
|
which P has been subdivided into one or more longer prefixes.
|
||||||
</t>
|
</t>
|
||||||
<t>
|
<t>
|
||||||
Currently, the registry data published by ARIN are not the same RPSL as
|
Currently, the registry data published by ARIN are not the same
|
||||||
that of the other registries (see <xref target="RFC7485"
|
RPSL as that of the other registries (see <xref target="RFC7485"
|
||||||
format="default"/> for a survey of the WHOIS Tower of Babel);
|
format="default"/> for a survey of the WHOIS Tower of Babel);
|
||||||
therefore, when fetching from ARIN via FTP <xref target="RFC0959"
|
therefore, when fetching from ARIN via FTP <xref
|
||||||
format="default"/>, WHOIS <xref target="RFC3912" format="default"/>,
|
target="RFC0959" format="default"/>, WHOIS <xref
|
||||||
the Registration Data Access Protocol (RDAP) <xref target="RFC9082"
|
target="RFC3912" format="default"/>, the Registration Data
|
||||||
|
Access Protocol (RDAP) <xref target="RFC9082"
|
||||||
format="default"/>, etc., the "NetRange" attribute/key
|
format="default"/>, etc., the "NetRange" attribute/key
|
||||||
<bcp14>MUST</bcp14> be treated as "inetnum", and the "Comment"
|
<bcp14>MUST</bcp14> be treated as "inetnum", and the "Comment"
|
||||||
attribute <bcp14>MUST</bcp14> be treated as "remarks".
|
attribute <bcp14>MUST</bcp14> be treated as "remarks".
|
||||||
|
|
@ -293,128 +301,143 @@
|
||||||
<t>
|
<t>
|
||||||
The question arises whether a particular geofeed <xref
|
The question arises whether a particular geofeed <xref
|
||||||
target="RFC8805" format="default"/> data set is valid, i.e., is
|
target="RFC8805" format="default"/> data set is valid, i.e., is
|
||||||
authorized by the "owner" of the IP address space and is authoritative
|
authorized by the "owner" of the IP address space and is
|
||||||
in some sense. The inetnum: that points to the geofeed <xref
|
authoritative in some sense. The inetnum: that points to the
|
||||||
target="RFC8805" format="default"/> file provides some assurance.
|
geofeed <xref target="RFC8805" format="default"/> file provides
|
||||||
Unfortunately, the RPSL in many repositories is weakly authenticated
|
some assurance. Unfortunately, the RPSL in many repositories is
|
||||||
at best. An approach where RPSL was signed per <xref target="RFC7909"
|
weakly authenticated at best. An approach where RPSL was signed
|
||||||
format="default"/> would be good, except it would have to be deployed
|
per <xref target="RFC7909" format="default"/> would be good,
|
||||||
by all RPSL registries, and there is a fair number of them.
|
except it would have to be deployed by all RPSL registries, and
|
||||||
|
there is a fair number of them.
|
||||||
</t>
|
</t>
|
||||||
<t>
|
<t>
|
||||||
A single optional authenticator <bcp14>MAY</bcp14> be appended to a
|
A single optional authenticator <bcp14>MAY</bcp14> be appended
|
||||||
geofeed <xref target="RFC8805" format="default"/> file. It is a
|
to a geofeed <xref target="RFC8805" format="default"/> file. It
|
||||||
digest of the main body of the file signed by the private key of the
|
is a digest of the main body of the file signed by the private
|
||||||
relevant RPKI certificate for a covering address range. One needs a
|
key of the relevant RPKI certificate for a covering address
|
||||||
format that bundles the relevant RPKI certificate with the signature
|
range. One needs a format that bundles the relevant RPKI
|
||||||
of the geofeed text.
|
certificate with the signature of the geofeed text.
|
||||||
</t>
|
</t>
|
||||||
<t>
|
<t>
|
||||||
The canonicalization procedure converts the data from their internal
|
The canonicalization procedure converts the data from their
|
||||||
character representation to the UTF-8 <xref target="RFC3629"
|
internal character representation to the UTF-8 <xref
|
||||||
format="default"/> character encoding, and the <CRLF> sequence
|
target="RFC3629" format="default"/> character encoding, and the
|
||||||
<bcp14>MUST</bcp14> be used to denote the end of a line of text. A
|
<CRLF> sequence <bcp14>MUST</bcp14> be used to denote the
|
||||||
blank line is represented solely by the <CRLF> sequence. For
|
end of a line of text. A blank line is represented solely by
|
||||||
robustness, any non-printable characters <bcp14>MUST NOT</bcp14> be
|
the <CRLF> sequence. For robustness, any non-printable
|
||||||
changed by canonicalization. Trailing blank lines <bcp14>MUST
|
characters <bcp14>MUST NOT</bcp14> be changed by
|
||||||
NOT</bcp14> appear at the end of the file. That is, the file must not
|
canonicalization. Trailing blank lines <bcp14>MUST NOT</bcp14>
|
||||||
end with multiple consecutive <CRLF> sequences. Any end-of-file
|
appear at the end of the file. That is, the file must not end
|
||||||
marker used by an operating system is not considered to be part of the
|
with multiple consecutive <CRLF> sequences. Any
|
||||||
file content. When present, such end-of-file markers <bcp14>MUST
|
end-of-file marker used by an operating system is not considered
|
||||||
NOT</bcp14> be processed by the digital signature algorithm.
|
to be part of the file content. When present, such end-of-file
|
||||||
|
markers <bcp14>MUST NOT</bcp14> be processed by the digital
|
||||||
|
signature algorithm.
|
||||||
</t>
|
</t>
|
||||||
<t>
|
<t>
|
||||||
Should the authenticator be syntactically incorrect per the
|
Should the authenticator be syntactically incorrect per the
|
||||||
above, the authenticator is invalid.
|
above, the authenticator is invalid.
|
||||||
</t>
|
</t>
|
||||||
|
|
||||||
|
|
||||||
<t>
|
<t>
|
||||||
Borrowing detached signatures from <xref target="RFC5485"
|
Borrowing detached signatures from <xref target="RFC5485"
|
||||||
format="default"/>, after file canonicalization, the Cryptographic
|
format="default"/>, after file canonicalization, the
|
||||||
Message Syntax (CMS) <xref target="RFC5652" format="default"/> would
|
Cryptographic Message Syntax (CMS) <xref target="RFC5652"
|
||||||
be used to create a detached DER-encoded signature that is then padded
|
format="default"/> would be used to create a detached
|
||||||
BASE64 encoded (as per <xref target="RFC4648" sectionFormat="of"
|
DER-encoded signature that is then padded BASE64 encoded (as per
|
||||||
section="4" format="default"/>) and line wrapped to 72 or fewer
|
<xref target="RFC4648" sectionFormat="of" section="4"
|
||||||
characters. The same digest algorithm <bcp14>MUST</bcp14> be used for
|
format="default"/>) and line wrapped to 72 or fewer characters.
|
||||||
calculating the message digest on content being signed, which is the
|
The same digest algorithm <bcp14>MUST</bcp14> be used for
|
||||||
geofeed file, and for calculating the message digest on the SignerInfo
|
calculating the message digest on content being signed, which is
|
||||||
SignedAttributes <xref target="RFC8933" format="default"/>. The
|
the geofeed file, and for calculating the message digest on the
|
||||||
message digest algorithm identifier <bcp14>MUST</bcp14> appear in both
|
SignerInfo SignedAttributes <xref target="RFC8933"
|
||||||
the SignedData DigestAlgorithmIdentifiers and the SignerInfo
|
format="default"/>. The message digest algorithm identifier
|
||||||
DigestAlgorithmIdentifier <xref target="RFC5652" format="default"/>.
|
<bcp14>MUST</bcp14> appear in both the SignedData
|
||||||
|
DigestAlgorithmIdentifiers and the SignerInfo
|
||||||
|
DigestAlgorithmIdentifier <xref target="RFC5652"
|
||||||
|
format="default"/>.
|
||||||
</t>
|
</t>
|
||||||
<t>
|
<t>
|
||||||
The address range of the signing certificate <bcp14>MUST</bcp14> cover all
|
The address range of the signing certificate <bcp14>MUST</bcp14>
|
||||||
prefixes in the geofeed file it signs.
|
cover all prefixes in the geofeed file it signs.
|
||||||
</t>
|
</t>
|
||||||
<t>
|
<t>
|
||||||
An address range A "covers" address range B if the range of B is
|
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
|
identical to or a subset of A. "Address range" is used here
|
||||||
inetnum: objects and RPKI certificates need not align on Classless
|
because inetnum: objects and RPKI certificates need not align on
|
||||||
Inter-Domain Routing (CIDR) <xref target="RFC4632"/> prefix
|
Classless Inter-Domain Routing (CIDR) <xref target="RFC4632"/>
|
||||||
boundaries, while those of the CSV lines in a geofeed file do.
|
prefix boundaries, while those of the CSV lines in a geofeed
|
||||||
|
file do.
|
||||||
</t>
|
</t>
|
||||||
<t>
|
<t>
|
||||||
As the signer specifies the covered RPKI resources relevant to the
|
As the signer specifies the covered RPKI resources relevant to
|
||||||
signature, the RPKI certificate covering the inetnum: object's address
|
the signature, the RPKI certificate covering the inetnum:
|
||||||
range is included in the <xref target="RFC5652" format="default"/> CMS
|
object's address range is included in the <xref target="RFC5652"
|
||||||
SignedData certificates field.
|
format="default"/> CMS SignedData certificates field.
|
||||||
</t>
|
</t>
|
||||||
<t>
|
<t>
|
||||||
Identifying the private key associated with the certificate and
|
Identifying the private key associated with the certificate and
|
||||||
getting the department that controls the private key (which might be
|
getting the department that controls the private key (which
|
||||||
trapped in a Hardware Security Module (HSM)) to sign the CMS blob is
|
might be trapped in a Hardware Security Module (HSM)) to sign
|
||||||
left as an exercise for the implementor. On the other hand, verifying
|
the CMS blob is left as an exercise for the implementor. On the
|
||||||
the signature requires no complexity; the certificate, which can be
|
other hand, verifying the signature requires no complexity; the
|
||||||
validated in the public RPKI, has the needed public key.
|
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
|
The trust anchors for the RIRs are expected to already be
|
||||||
available to the party performing signature validation.
|
available to the party performing signature validation.
|
||||||
Validation of the CMS signature on the geofeed file
|
Validation of the CMS signature on the geofeed file
|
||||||
involves:</t>
|
involves:</t>
|
||||||
<ol spacing="normal" type="1"><li>
|
<ol spacing="normal" type="1"><li>
|
||||||
<t> Obtaining the signer's certificate from the CMS SignedData
|
<t>
|
||||||
CertificateSet <xref target="RFC5652" format="default"/>. The certificate
|
Obtaining the signer's certificate from the CMS SignedData
|
||||||
SubjectKeyIdentifier extension <xref target="RFC5280" format="default"/>
|
CertificateSet <xref target="RFC5652" format="default"/>. The
|
||||||
<bcp14>MUST</bcp14> match the SubjectKeyIdentifier in the CMS SignerInfo
|
certificate SubjectKeyIdentifier extension <xref
|
||||||
SignerIdentifier <xref target="RFC5652" format="default"/>. If the key
|
target="RFC5280" format="default"/> <bcp14>MUST</bcp14> match
|
||||||
identifiers do not match, then validation <bcp14>MUST</bcp14> fail.</t>
|
the SubjectKeyIdentifier in the CMS SignerInfo
|
||||||
<t>
|
SignerIdentifier <xref target="RFC5652" format="default"/>.
|
||||||
Validation of the signer's certificate <bcp14>MUST</bcp14> ensure
|
If the key identifiers do not match, then validation
|
||||||
that it is part of the current <xref target="RFC6486"
|
<bcp14>MUST</bcp14> fail.</t>
|
||||||
format="default"/> manifest and that the resources are covered by
|
<t>
|
||||||
the RPKI certificate.
|
Validation of the signer's certificate <bcp14>MUST</bcp14>
|
||||||
</t>
|
ensure that it is part of the current <xref target="RFC6486"
|
||||||
|
format="default"/> manifest and that the resources are covered
|
||||||
</li>
|
by the RPKI certificate.
|
||||||
|
</t>
|
||||||
<li>
|
|
||||||
Constructing the certification path for the signer's certificate.
|
|
||||||
All of the needed certificates are expected to be readily
|
|
||||||
available in the RPKI repository. The certification path <bcp14>MUST</bcp14>
|
|
||||||
be valid according to the validation algorithm in <xref target="RFC5280" format="default"/> and the additional checks specified in
|
|
||||||
<xref target="RFC3779" format="default"/> associated with the IP Address
|
|
||||||
Delegation certificate extension and the Autonomous System
|
|
||||||
Identifier Delegation certificate extension. If certification
|
|
||||||
path validation is unsuccessful, then validation <bcp14>MUST</bcp14> fail.
|
|
||||||
</li>
|
</li>
|
||||||
|
|
||||||
<li>
|
<li>
|
||||||
Validating the CMS SignedData as specified in <xref target="RFC5652" format="default"/> using the public key from the validated
|
Constructing the certification path for the signer's
|
||||||
signer's certificate. If the signature validation is
|
certificate. All of the needed certificates are expected to
|
||||||
unsuccessful, then validation <bcp14>MUST</bcp14> fail.
|
be readily available in the RPKI repository. The
|
||||||
|
certification path <bcp14>MUST</bcp14> be valid according to
|
||||||
|
the validation algorithm in <xref target="RFC5280"
|
||||||
|
format="default"/> and the additional checks specified in
|
||||||
|
<xref target="RFC3779" format="default"/> associated with the
|
||||||
|
IP Address Delegation certificate extension and the Autonomous
|
||||||
|
System Identifier Delegation certificate extension. If
|
||||||
|
certification path validation is unsuccessful, then validation
|
||||||
|
<bcp14>MUST</bcp14> fail.
|
||||||
|
</li>
|
||||||
|
|
||||||
|
<li>
|
||||||
|
Validating the CMS SignedData as specified in <xref
|
||||||
|
target="RFC5652" format="default"/> using the public key from
|
||||||
|
the validated signer's certificate. If the signature
|
||||||
|
validation is unsuccessful, then validation
|
||||||
|
<bcp14>MUST</bcp14> fail.
|
||||||
</li>
|
</li>
|
||||||
<li>
|
<li>
|
||||||
Verifying that the IP Address Delegation certificate extension
|
Verifying that the IP Address Delegation certificate extension
|
||||||
<xref target="RFC3779" format="default"/> covers all of the address ranges of
|
<xref target="RFC3779" format="default"/> covers all of the
|
||||||
the geofeed file. If all of the address ranges are not
|
address ranges of the geofeed file. If all of the address
|
||||||
covered, then validation <bcp14>MUST</bcp14> fail.
|
ranges are not covered, then validation <bcp14>MUST</bcp14>
|
||||||
|
fail.
|
||||||
</li>
|
</li>
|
||||||
|
|
||||||
</ol>
|
</ol>
|
||||||
<t>
|
<t>
|
||||||
All of these steps <bcp14>MUST</bcp14> be successful to consider the geofeed
|
All of these steps <bcp14>MUST</bcp14> be successful to consider
|
||||||
file signature as valid.
|
the geofeed file signature as valid.
|
||||||
</t>
|
</t>
|
||||||
<t>
|
<t>
|
||||||
As the signer specifies the covered RPKI resources relevant to the
|
As the signer specifies the covered RPKI resources relevant to the
|
||||||
|
|
@ -422,12 +445,18 @@
|
||||||
range is included in the CMS SignedData certificates field <xref
|
range is included in the CMS SignedData certificates field <xref
|
||||||
target="RFC5652" format="default"/>.
|
target="RFC5652" format="default"/>.
|
||||||
</t>
|
</t>
|
||||||
|
<t>
|
||||||
|
As an IP Address Delegation extension using "inherit" would
|
||||||
|
complicate processing, it <bcp14>MUST NOT</bcp14> be used. This
|
||||||
|
is consistent with other RPKI signed objects.
|
||||||
|
</t>
|
||||||
<t>
|
<t>
|
||||||
Identifying the private key associated with the certificate and
|
Identifying the private key associated with the certificate and
|
||||||
getting the department with the Hardware Security Module (HSM) to sign
|
getting the department with the Hardware Security Module (HSM)
|
||||||
the CMS blob is left as an exercise for the implementor. On the other
|
to sign the CMS blob is left as an exercise for the implementor.
|
||||||
hand, verifying the signature requires no complexity; the certificate,
|
On the other hand, verifying the signature requires no
|
||||||
which can be validated in the public RPKI, has the needed public key.
|
complexity; the certificate, which can be validated in the
|
||||||
|
public RPKI, has the needed public key.
|
||||||
</t>
|
</t>
|
||||||
<t>
|
<t>
|
||||||
The appendix <bcp14>MUST</bcp14> be hidden as a series of "#" comments at the
|
The appendix <bcp14>MUST</bcp14> be hidden as a series of "#" comments at the
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue