From 69899755f34b7d6d118d5b02b24f4b426e9dd68c Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Mon, 6 Jul 2020 10:58:04 -0700 Subject: [PATCH] some egregious typos --- draft-ymbk-sidrops-6486bis.xml | 257 ++++++++++++++++----------------- 1 file changed, 122 insertions(+), 135 deletions(-) diff --git a/draft-ymbk-sidrops-6486bis.xml b/draft-ymbk-sidrops-6486bis.xml index e07794f..5ff4d70 100644 --- a/draft-ymbk-sidrops-6486bis.xml +++ b/draft-ymbk-sidrops-6486bis.xml @@ -571,20 +571,42 @@ -
+
- 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. + + + + 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). + + + + 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. @@ -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. @@ -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 . Similarly, if the CRL is not listed + on a valid, current manifest, acquired during a fetch, the fetch + has failed; proceed to , because the CRL is considered missing. + + 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). + +
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 ( to ) 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 below). - - - - 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 *???* - - - - 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, 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. - - - - Note that, during CA key rollover [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. - - - - 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. - - - + 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 ; otherwise proceed to . -
+ + Note that, during CA key rollover , + 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. + +
- 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 () proceed to . If - the publication point does not contain a valid manifest, and the - cached manifest is not current, proceed to . + 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 (), an RP MUST treat this as a + failed fetch and, proceed to ; + otherwise proceed to . -
- Check that the current time (translated to UTC) is between - thisUpdate and nextUpdate. If the current time lies within this - interval, proceed to . 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 . + 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 . If + the current time is earlier than thisUpdate, the CA has made an + error; this a failed fetch and the RP MUST proceed to . If the current time is later than + nextUpdate, then the manifest is stale; this is a failed fetch + and RP MUST proceed to ; otherwise + proceed to . -
- 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 , 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 . However, if _any_ of the - missing/invalid files cannot be replaced in this fashion, then - proceed to . + 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 , the fetch has failed and the RP + MUST proceed to ; otherwise, proceed to + . -
- 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 ; otherwise proceed to . -
- + If a current manifest contains entries for objects that are not - within the scope of the manifest (), then - the out-of-scope entries MUST be disregarded. + within the scope of the manifest (), + the fetch has failed and the RP proceed to ; otherwise the fetch is deemed successful + and the RP will process the fetched objects. -
-
+
- 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. - 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. -