some egregious typos
This commit is contained in:
parent
166c20ddb1
commit
69899755f3
1 changed files with 122 additions and 135 deletions
|
|
@ -571,20 +571,42 @@
|
|||
|
||||
</section>
|
||||
|
||||
<section title="Relying Party Use of Manifests" anchor="sect-6">
|
||||
<section title="Relying Party Processing of Manifests" anchor="sect-6">
|
||||
|
||||
<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
|
||||
to use in the construction of route filters). Manifests are
|
||||
designed to allow an RP to detect manipulation of repository data
|
||||
and/or errors by a CA or repository manager. Unless _all_ of the
|
||||
files enumerated in a manifest can be obtained by an RP (either
|
||||
from a publication point or from a local cache), an RP MUST ignore
|
||||
the data associated with the publication point. This stringent
|
||||
response is needed to prevent an RP from misinterpreting data
|
||||
associated with a publication point, and thus possibly treating
|
||||
invalid routes as valid, or vice versa.
|
||||
to use in the construction of route filters). As noted earlier,
|
||||
manifests are designed to allow an RP to detect manipulation of
|
||||
repository data, errors by a CA or repository manager, and/or
|
||||
active attacks on the communication channel between an RP and a
|
||||
repository. Unless all of the files enumerated in a manifest can
|
||||
be obtained by an RP during a fetch operation, the fetch is
|
||||
considered to have failed and the RP MUST retry the fetch later.
|
||||
</t>
|
||||
|
||||
<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>
|
||||
|
|
@ -594,7 +616,7 @@
|
|||
in operation, different RPs will access repositories at different
|
||||
times, and some RPs may experience local cache failures, so there
|
||||
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>
|
||||
|
|
@ -602,181 +624,146 @@
|
|||
manifest and the CRL for a given CA instance. If the EE
|
||||
certificate for the current manifest is revoked, i.e., it appears
|
||||
in the current CRL, then the CA or publication point manager has
|
||||
made a serious error. In this case all signed objects associated
|
||||
with the CA instance MUST be ignored. Similarly, if the CRL is
|
||||
not listed on a valid, current manifest, all signed objects
|
||||
associated with the CA instance MUST be ignored, because the CRL
|
||||
made a serious error. In this case the fetch has failed; proceed
|
||||
to <xref target="sect-6.7"/>. Similarly, if the CRL is not listed
|
||||
on a valid, current manifest, acquired during a fetch, the fetch
|
||||
has failed; proceed to <xref target="sect-6.7"/>, because the CRL
|
||||
is considered missing.
|
||||
</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">
|
||||
|
||||
<t>
|
||||
For a given publication point, an RP MUST perform a series of
|
||||
tests to determine which signed object files at the publication
|
||||
point are acceptable. The tests described below are to be
|
||||
performed using themanifest identified by the id-ad-rpkiManifest
|
||||
URI extracted from a CA certificate's SIA. _All_ of the files
|
||||
referenced by the manifest MUST be be located at the publication
|
||||
point specified by the id-ad-caRepositoryURI from the (same)
|
||||
certificate's SIA. The manifest and the files it references
|
||||
MUST reside at the same publication point. An RP MUST
|
||||
ignore any files that appear on a manifest but do not reside as
|
||||
the same publication point as the manifest.
|
||||
point are acceptable. The tests described below (<xref
|
||||
target="sect-6.2"/> to <xref target="sect-6.6"/>) are to
|
||||
be performed using the manifest identified by the
|
||||
id-ad-rpkiManifest URI extracted from a CA certificate's
|
||||
SIA. All of the files referenced by the manifest MUST be be
|
||||
located at the publication point specified by the
|
||||
id-ad-caRepository URI from the (same) CA certificate's SIA. The
|
||||
manifest and the files it references MUST reside at the same
|
||||
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>
|
||||
<list style="numbers">
|
||||
|
||||
<t>
|
||||
All of the files referenced by the manifest MUST be be located
|
||||
at the publication point specified by the id-ad-caRepository URI
|
||||
from the (same) certificate's SIA. If the manifest and the
|
||||
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>
|
||||
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. If more than one .crl file appears in the
|
||||
manifest, the fetch has failed and the RP MUST proceed to <xref
|
||||
target="sect-6.7"/>; otherwise proceed to <xref
|
||||
target="sect-6.2"/>.
|
||||
</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">
|
||||
|
||||
<t>
|
||||
Acquire the manifest identified by the SIA id-ad-rpkiManifest
|
||||
URI in the CA certificate. If an RP cannot retrieve a manifest
|
||||
using this URI, or if the manifest is not valid (Section 4.4),
|
||||
an RP SHOULD examine the most recent, cached manifest matching
|
||||
this URI. If that manifest is current (<xref
|
||||
target="sect-4.4"/>) proceed to <xref target="sect-6.3"/>. If
|
||||
the publication point does not contain a valid manifest, and the
|
||||
cached manifest is not current, proceed to <xref
|
||||
target="sect-6.7"/>.
|
||||
The RP MUST fetch the manifest identified by the SIA
|
||||
id-ad-rpkiManifest URI in the CA certificate. If an RP cannot
|
||||
retrieve a manifest using this URI, or if the manifest is not
|
||||
valid (<xref target="sect-4.4"/>), an RP MUST treat this as a
|
||||
failed fetch and, proceed to <xref target="sect-6.7"/>;
|
||||
otherwise proceed to <xref target="sect-6.3"/>.
|
||||
</t>
|
||||
|
||||
</section>
|
||||
|
||||
<section title="Detecting Stale and or Prematurely-issued Manifests" anchor="sect-6.3">
|
||||
|
||||
<t>
|
||||
Check that the current time (translated to UTC) is between
|
||||
thisUpdate and nextUpdate. If the current time lies within this
|
||||
interval, proceed to <xref target="sect-6.4"/>. If the current
|
||||
time is earlier than thisUpdate, the CA has made an error. If
|
||||
the RP cache contains a current manifest, use that manifest
|
||||
instead and issue a warning. If an RP has no access to a current
|
||||
manifest, processing stops and a warning MUST be issued. If the
|
||||
current time is later than nextUpdate, then the manifest is
|
||||
stale. If the RP cache contains a current manifest, use that
|
||||
manifest instead and issue a warning.If no current manifest is
|
||||
available, proceed to <xref target="sect-6.7"/>.
|
||||
The RP MUST check that the current time (translated to UTC) is
|
||||
between thisUpdate and nextUpdate. If the current time lies
|
||||
within this interval, proceed to <xref target="sect-6.4"/>. If
|
||||
the current time is earlier than thisUpdate, the CA has made an
|
||||
error; this a failed fetch and the RP MUST proceed to <xref
|
||||
target="sect-6.7"/>. If the current time is later than
|
||||
nextUpdate, then the manifest is stale; this is a failed fetch
|
||||
and RP MUST proceed to <xref target="sect-6.7"/>; otherwise
|
||||
proceed to <xref target="sect-6.4"/>.
|
||||
</t>
|
||||
|
||||
</section>
|
||||
|
||||
<section title="Acquiring Files Referenced by a Manifest" anchor="sect-6.4">
|
||||
|
||||
<t>
|
||||
Acquire all files enumerated in the manifest (fileList) from the
|
||||
publication point. This includes the CRL, each object containing
|
||||
an EE certificate issued by the C, and all subordinate CA and EE
|
||||
certificates. If there are files listed in the manifest that
|
||||
cannot be retrieved from the publication point, or if they fail
|
||||
the validity tests specified in <xref target="RFC6488"/>, the RP
|
||||
SHOULD examine its cache to determine if these files are
|
||||
available locally. If all of the missing/invalid files are
|
||||
available from the RP's cache, i.e., each file name matches the
|
||||
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"/>.
|
||||
The RP MUST acquire all of the files enumerated in the manifest
|
||||
(fileList) from the publication point. This includes the CRL,
|
||||
each object containing an EE certificate issued by the CA, and
|
||||
any subordinate CA and EE certificates. If there are files
|
||||
listed in the manifest that cannot be retrieved from the
|
||||
publication point, or if they fail the validity tests specified
|
||||
in <xref target="RFC6488"/>, the fetch has failed and the RP
|
||||
MUST proceed to <xref target="sect-6.7"/>; otherwise, proceed to
|
||||
<xref target="sect-6.5"/>.
|
||||
</t>
|
||||
|
||||
</section>
|
||||
|
||||
<section title="Matching File Names and Hashes" anchor="sect-6.5">
|
||||
|
||||
<t>
|
||||
Verify that the hash value of every file listed in the manifest
|
||||
matches the value obtained by hashing the file acquired from the
|
||||
publication point or local cache. If the computed 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
|
||||
cache to determine if the same file is available. The RP SHOULD
|
||||
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
|
||||
The RP MUST verify that the hash value of each file listed in
|
||||
the manifest matches the value obtained by hashing the file
|
||||
acquired from the publication point. If the computed hash value
|
||||
of a file listed on the manifest does not match the hash value
|
||||
contained in the manifest, then the fetch has failed and the RP
|
||||
MUST proceed to <xref target="sect-6.7"/>; otherwise proceed to
|
||||
<xref target="sect-6.6"/>.
|
||||
</t>
|
||||
|
||||
</section>
|
||||
|
||||
<section title="Out of Scope Manifest Entries" anchor="sect-6.6">
|
||||
|
||||
|
||||
<t>
|
||||
If a current manifest contains entries for objects that are not
|
||||
within the scope of the manifest (<xref target="sect-2"/>), then
|
||||
the out-of-scope entries MUST be disregarded.
|
||||
within the scope of the manifest (<xref target="sect-6.2"/>),
|
||||
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>
|
||||
|
||||
</section>
|
||||
|
||||
<section title="Termination of Processing" anchor="sect-6.7">
|
||||
<section title="Failed Fetches" anchor="sect-6.7">
|
||||
|
||||
<t>
|
||||
If an RP cannot acquire a current, valid manifest, or acquire
|
||||
current, valid instances of all of the objects enumerated in a
|
||||
current valid manifest, then processing of the signed objects
|
||||
associated with the CA has failed. The RP MUST issue a warning
|
||||
If an RP does not acquire a current valid manifest, or does not
|
||||
acquire current valid instances of all of the objects enumerated
|
||||
in a current valid manifest as a result of a fetch, then
|
||||
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
|
||||
regard to this CA.
|
||||
regard to this CA instance. It is RECOMMENDED that a human
|
||||
operator be notified of this warning.
|
||||
</t>
|
||||
|
||||
<t>
|
||||
Termination or processing means that all of the ROAs and
|
||||
subordinate certificates (CA and EE) MUST be considered
|
||||
invalid. This implies that the RP MUST not try to acquire and
|
||||
validate _subordinate_ signed objects, until the next interval
|
||||
when the RP is scheduled to process data for this part of the
|
||||
RPKI repository system.
|
||||
Termination or processing means that the RP SHOULD continue to
|
||||
use cached versions of the objects associated with this CA
|
||||
instance, until such time as they become stale or they can be
|
||||
replaced by objects from a successful fetch. This implies that
|
||||
the RP MUST not try to acquire and validate subordinate signed
|
||||
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>
|
||||
|
||||
</section>
|
||||
|
||||
</section>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue