randy/draft-6486bis
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

some egregious typos

Browse source
This commit is contained in:
Randy Bush 2020-07-06 10:58:04 -07:00
parent 166c20ddb1
commit 69899755f3
1 changed files with 122 additions and 135 deletions
Download patch file Download diff file Expand all files Collapse all files

257
draft-ymbk-sidrops-6486bis.xml
View file

@ -571,20 +571,42 @@
</section> </section>
<section title="Relying Party Use of Manifests" anchor="sect-6"> <section title="Relying Party Processing of Manifests" anchor="sect-6">
<t> <t>
Each RP MUST determine which signed objects it will use for Each RP must determine which signed objects it will use for
validating assertions about INRs and their use (e.g., which ROAs validating assertions about INRs and their use (e.g., which ROAs
to use in the construction of route filters). Manifests are to use in the construction of route filters). As noted earlier,
designed to allow an RP to detect manipulation of repository data manifests are designed to allow an RP to detect manipulation of
and/or errors by a CA or repository manager. Unless _all_ of the repository data, errors by a CA or repository manager, and/or
files enumerated in a manifest can be obtained by an RP (either active attacks on the communication channel between an RP and a
from a publication point or from a local cache), an RP MUST ignore repository. Unless all of the files enumerated in a manifest can
the data associated with the publication point. This stringent be obtained by an RP during a fetch operation, the fetch is
response is needed to prevent an RP from misinterpreting data considered to have failed and the RP MUST retry the fetch later.
associated with a publication point, and thus possibly treating </t>
invalid routes as valid, or vice versa.
<t>
<xref target="RFC6480"/> suggests (but does not mandate) that the
RPKI model employ fetches that are incremental, e.g., an RP
transfers files from a publication point only if they are
new/changed since the previous, successful, fetch represented in
the RP's local cache. This document avoids language that relies on
details of the underlying file transfer mechanism employed by an
RP and a publication point to effect this operation. Thus the term
"fetch" refers to an operation that attempts to acquire the full
set of files at a publication point, consistent with the
id-ad-rpkiManifest URI extracted from a CA certificate's SIA (see
below).
</t>
<t>
If a fetch fails, it is assumed that a subsequent fetch will
resolve problems encountered during the fetch. Until such time as
a successful fetch is executed, an RP SHOULD use cached data from
a previous, successful fetch. This response is intended to prevent
an RP from misinterpreting data associated with a publication
point, and thus possibly treating invalid routes as valid, or vice
versa.
</t> </t>
<t> <t>
@ -594,7 +616,7 @@
in operation, different RPs will access repositories at different in operation, different RPs will access repositories at different
times, and some RPs may experience local cache failures, so there times, and some RPs may experience local cache failures, so there
is no guarantee that all RPs will achieve the same results with is no guarantee that all RPs will achieve the same results with
regard to validation of RPKI data regard to validation of RPKI data.
</t> </t>
<t> <t>
@ -602,181 +624,146 @@
manifest and the CRL for a given CA instance. If the EE manifest and the CRL for a given CA instance. If the EE
certificate for the current manifest is revoked, i.e., it appears certificate for the current manifest is revoked, i.e., it appears
in the current CRL, then the CA or publication point manager has in the current CRL, then the CA or publication point manager has
made a serious error. In this case all signed objects associated made a serious error. In this case the fetch has failed; proceed
with the CA instance MUST be ignored. Similarly, if the CRL is to <xref target="sect-6.7"/>. Similarly, if the CRL is not listed
not listed on a valid, current manifest, all signed objects on a valid, current manifest, acquired during a fetch, the fetch
associated with the CA instance MUST be ignored, because the CRL has failed; proceed to <xref target="sect-6.7"/>, because the CRL
is considered missing. is considered missing.
</t> </t>
<t>
Note that if a CA and its associated publication point are
operating properly, there will always be exactly one manifest and
one associated CRL at the publication point identified in the CA's
SIA (see below).
</t>
<section title="Manifest Processing Overview" anchor="sect-6.1"> <section title="Manifest Processing Overview" anchor="sect-6.1">
<t> <t>
For a given publication point, an RP MUST perform a series of For a given publication point, an RP MUST perform a series of
tests to determine which signed object files at the publication tests to determine which signed object files at the publication
point are acceptable. The tests described below are to be point are acceptable. The tests described below (<xref
performed using themanifest identified by the id-ad-rpkiManifest target="sect-6.2"/> to <xref target="sect-6.6"/>) are to
URI extracted from a CA certificate's SIA. _All_ of the files be performed using the manifest identified by the
referenced by the manifest MUST be be located at the publication id-ad-rpkiManifest URI extracted from a CA certificate's
point specified by the id-ad-caRepositoryURI from the (same) SIA. All of the files referenced by the manifest MUST be be
certificate's SIA. The manifest and the files it references located at the publication point specified by the
MUST reside at the same publication point. An RP MUST id-ad-caRepository URI from the (same) CA certificate's SIA. The
ignore any files that appear on a manifest but do not reside as manifest and the files it references MUST reside at the same
the same publication point as the manifest. publication point. If an RP encounters any files that appear on
a manifest but do not reside at the same publication point as
the manifest the RP MUST treat the fetch as failed, and a
warning MUST be issued (see <xref target="sect-6.7"/> below).
</t> </t>
<t> <t>
<list style="numbers"> A manifest SHOULD contain exactly one CRL (.crl) file and it
MUST be at the location specified in the CRLDP in the manifest's
<t> EE certificate. If more than one .crl file appears in the
All of the files referenced by the manifest MUST be be located manifest, the fetch has failed and the RP MUST proceed to <xref
at the publication point specified by the id-ad-caRepository URI target="sect-6.7"/>; otherwise proceed to <xref
from the (same) certificate's SIA. If the manifest and the target="sect-6.2"/>.
files it references do not reside at the same publication point,
an RP MUST *???*
</t>
<t>
A manifest SHOULD contain exactly one CRL (.crl) file and it
MUST be at the location specified in the CRLDP in the manifest's
EE certificate.
</t>
<t>
If more than one .crl file appears in the manifest, only file
names matching the CRL specified by the CRLDP will be
processed. If more than one .crl entry appears in the manifest,
and matches the CRLDP, the first one encountered MUST be
used. Any other .crl files MUST be ignored and a warning MUST be
issued.
</t>
<t>
Note that, during CA key rollover [RFC6489], signed objects for
two or more different CA instances will appear at the same
publication point.
</t>
<t>
Manifest processing is to be performed separately for each CA
instance, guided by the SIA id-ad-rpkiManifest URI in each CA
certificate.
</t>
<t>
Note also that the processing described here will be performed
using locally cached files if an RP does not detect newer
versions of the files in the RPKI repository system.
</t>
</list>
</t> </t>
</section> <t>
Note that, during CA key rollover <xref target="RFC6489"/>,
signed objects for two or more different CA instances will
appear at the same publication point. Manifest processing is to
be performed separately for each CA instance, guided by the SIA
id-ad-rpkiManifest URI in each CA certificate.
</t>
</section>
<section title="Acquiring a Manifest for a CA" anchor="sect-6.2"> <section title="Acquiring a Manifest for a CA" anchor="sect-6.2">
<t> <t>
Acquire the manifest identified by the SIA id-ad-rpkiManifest The RP MUST fetch the manifest identified by the SIA
URI in the CA certificate. If an RP cannot retrieve a manifest id-ad-rpkiManifest URI in the CA certificate. If an RP cannot
using this URI, or if the manifest is not valid (Section 4.4), retrieve a manifest using this URI, or if the manifest is not
an RP SHOULD examine the most recent, cached manifest matching valid (<xref target="sect-4.4"/>), an RP MUST treat this as a
this URI. If that manifest is current (<xref failed fetch and, proceed to <xref target="sect-6.7"/>;
target="sect-4.4"/>) proceed to <xref target="sect-6.3"/>. If otherwise proceed to <xref target="sect-6.3"/>.
the publication point does not contain a valid manifest, and the
cached manifest is not current, proceed to <xref
target="sect-6.7"/>.
</t> </t>
</section> </section>
<section title="Detecting Stale and or Prematurely-issued Manifests" anchor="sect-6.3"> <section title="Detecting Stale and or Prematurely-issued Manifests" anchor="sect-6.3">
<t> <t>
Check that the current time (translated to UTC) is between The RP MUST check that the current time (translated to UTC) is
thisUpdate and nextUpdate. If the current time lies within this between thisUpdate and nextUpdate. If the current time lies
interval, proceed to <xref target="sect-6.4"/>. If the current within this interval, proceed to <xref target="sect-6.4"/>. If
time is earlier than thisUpdate, the CA has made an error. If the current time is earlier than thisUpdate, the CA has made an
the RP cache contains a current manifest, use that manifest error; this a failed fetch and the RP MUST proceed to <xref
instead and issue a warning. If an RP has no access to a current target="sect-6.7"/>. If the current time is later than
manifest, processing stops and a warning MUST be issued. If the nextUpdate, then the manifest is stale; this is a failed fetch
current time is later than nextUpdate, then the manifest is and RP MUST proceed to <xref target="sect-6.7"/>; otherwise
stale. If the RP cache contains a current manifest, use that proceed to <xref target="sect-6.4"/>.
manifest instead and issue a warning.If no current manifest is
available, proceed to <xref target="sect-6.7"/>.
</t> </t>
</section> </section>
<section title="Acquiring Files Referenced by a Manifest" anchor="sect-6.4"> <section title="Acquiring Files Referenced by a Manifest" anchor="sect-6.4">
<t> <t>
Acquire all files enumerated in the manifest (fileList) from the The RP MUST acquire all of the files enumerated in the manifest
publication point. This includes the CRL, each object containing (fileList) from the publication point. This includes the CRL,
an EE certificate issued by the C, and all subordinate CA and EE each object containing an EE certificate issued by the CA, and
certificates. If there are files listed in the manifest that any subordinate CA and EE certificates. If there are files
cannot be retrieved from the publication point, or if they fail listed in the manifest that cannot be retrieved from the
the validity tests specified in <xref target="RFC6488"/>, the RP publication point, or if they fail the validity tests specified
SHOULD examine its cache to determine if these files are in <xref target="RFC6488"/>, the fetch has failed and the RP
available locally. If all of the missing/invalid files are MUST proceed to <xref target="sect-6.7"/>; otherwise, proceed to
available from the RP's cache, i.e., each file name matches the <xref target="sect-6.5"/>.
list extracted from the manifest, the RP SHOULD use the cached
files to replace those missing from the publication point, and
proceed to <xref target="sect-6.5"/>. However, if _any_ of the
missing/invalid files cannot be replaced in this fashion, then
proceed to <xref target="sect-6.7"/>.
</t> </t>
</section> </section>
<section title="Matching File Names and Hashes" anchor="sect-6.5"> <section title="Matching File Names and Hashes" anchor="sect-6.5">
<t> <t>
Verify that the hash value of every file listed in the manifest The RP MUST verify that the hash value of each file listed in
matches the value obtained by hashing the file acquired from the the manifest matches the value obtained by hashing the file
publication point or local cache. If the computed hash value of acquired from the publication point. If the computed hash value
a file listed on the manifest does not match the hash value of a file listed on the manifest does not match the hash value
contained in the manifest, then an RP SHOULD examine its local contained in the manifest, then the fetch has failed and the RP
cache to determine if the same file is available. The RP SHOULD MUST proceed to <xref target="sect-6.7"/>; otherwise proceed to
use cached files to replace any (damaged) downloaded files, so
long as the hash of the cached file matches the hash from the
manifest. If any of the files with hash mismatches cannot be
replaced in this fashion, proceed to 6.7. Otherwise proceed to
<xref target="sect-6.6"/>. <xref target="sect-6.6"/>.
</t> </t>
</section> </section>
<section title="Out of Scope Manifest Entries" anchor="sect-6.6"> <section title="Out of Scope Manifest Entries" anchor="sect-6.6">
<t> <t>
If a current manifest contains entries for objects that are not If a current manifest contains entries for objects that are not
within the scope of the manifest (<xref target="sect-2"/>), then within the scope of the manifest (<xref target="sect-6.2"/>),
the out-of-scope entries MUST be disregarded. the fetch has failed and the RP proceed to <xref
target="sect-6.7"/>; otherwise the fetch is deemed successful
and the RP will process the fetched objects.
</t> </t>
</section> </section>
<section title="Termination of Processing" anchor="sect-6.7"> <section title="Failed Fetches" anchor="sect-6.7">
<t> <t>
If an RP cannot acquire a current, valid manifest, or acquire If an RP does not acquire a current valid manifest, or does not
current, valid instances of all of the objects enumerated in a acquire current valid instances of all of the objects enumerated
current valid manifest, then processing of the signed objects in a current valid manifest as a result of a fetch, then
associated with the CA has failed. The RP MUST issue a warning processing of the signed objects associated with the CA instance
has failed for this fetch cycle. The RP MUST issue a warning
indicating the reason(s) for termination of processing with indicating the reason(s) for termination of processing with
regard to this CA. regard to this CA instance. It is RECOMMENDED that a human
operator be notified of this warning.
</t> </t>
<t> <t>
Termination or processing means that all of the ROAs and Termination or processing means that the RP SHOULD continue to
subordinate certificates (CA and EE) MUST be considered use cached versions of the objects associated with this CA
invalid. This implies that the RP MUST not try to acquire and instance, until such time as they become stale or they can be
validate _subordinate_ signed objects, until the next interval replaced by objects from a successful fetch. This implies that
when the RP is scheduled to process data for this part of the the RP MUST not try to acquire and validate subordinate signed
RPKI repository system. objects, e.g., subordinate CA certificates, until the next
interval when the RP is scheduled to fetch and process data for
this CA instance.
</t> </t>
</section> </section>
</section> </section>