diff --git a/draft-ymbk-sidrops-6486bis.xml b/draft-ymbk-sidrops-6486bis.xml index a542f0c..da7c5bf 100644 --- a/draft-ymbk-sidrops-6486bis.xml +++ b/draft-ymbk-sidrops-6486bis.xml @@ -27,9 +27,9 @@ APNIC
- 6 Cordelia St - South Brisbane - QLD 4101 + 6 Cordelia St + South Brisbane + QLD 4101 Australia gih@apnic.net @@ -38,18 +38,19 @@ Independent +
kkent@alum.mit.edu
- New College Florida + New College Florida
- 5800 Bay Shore Rd. - Sarasota, FL - 34243 - USA + 5800 Bay Shore Rd. + Sarasota, FL + 34243 + USA mlepinski@ncf.edu
@@ -129,22 +130,22 @@ Origination Authorizations (ROAs). +
+ + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL + NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", + "MAY", and "OPTIONAL" in this document are to be interpreted as + described in BCP 14 when, and only when, they appear in all + capitals, as shown here. + + +
+ -
- - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL - NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", - "MAY", and "OPTIONAL" in this document are to be interpreted as - described in BCP 14 when, and only when, they appear in all - capitals, as shown here. - - -
-
@@ -155,19 +156,19 @@ - - the set of (non-expired, non-revoked) certificates issued and - published by this CA, - + + the set of (non-expired, non-revoked) certificates issued and + published by this CA, + - - the most recent CRL issued by this CA, and - + + the most recent CRL issued by this CA, and + - - all published signed objects that are verifiable using EE - certificates issued by this CA. - + + all published signed objects that are verifiable using EE + certificates issued by this CA. + @@ -233,20 +234,21 @@
- The eContentType for a manifest is defined as id-ct-rpkiManifest - and has the numerical value of 1.2.840.113549.1.9.16.1.26. + The eContentType for a manifest is defined as id-ct-rpkiManifest + and has the numerical value of 1.2.840.113549.1.9.16.1.26.
- + - + ]]> +
@@ -254,125 +256,126 @@ The content of a manifest is ASN.1 encoded using the - Distinguished Encoding Rules (DER) [X.690]. The content of a - manifest is defined as follows: + Distinguished Encoding Rules (DER) . The + content of a manifest is defined as follows:
- + - + file IA5String, + hash BIT STRING + } + ]]> +
- - The manifestNumber, thisUpdate, and nextUpdate fields are - modeled after the corresponding fields in X.509 CRLs (see - ). Analogous to CRLs, a manifest is - nominally current until the time specified in nextUpdate or - until a manifest is issued with a greater manifest number, - whichever comes first. - + + The manifestNumber, thisUpdate, and nextUpdate fields are + modeled after the corresponding fields in X.509 CRLs (see + ). Analogous to CRLs, a manifest is + nominally current until the time specified in nextUpdate or + until a manifest is issued with a greater manifest number, + whichever comes first. + - - If a "one-time-use" EE certificate is employed to verify a - manifest, the EE certificate MUST have a validity period that - coincides with the interval from thisUpdate to nextUpdate, to - prevent needless growth of the CA's CRL. - + + If a "one-time-use" EE certificate is employed to verify a + manifest, the EE certificate MUST have a validity period that + coincides with the interval from thisUpdate to nextUpdate, to + prevent needless growth of the CA's CRL. + - - If a "sequential-use" EE certificate is employed to verify a - manifest, the EE certificate's validity period needs to be no - shorter than the nextUpdate time of the current manifest. - The extended validity time raises the possibility of a - substitution attack using a stale manifest, as described in - . - + + If a "sequential-use" EE certificate is employed to verify a + manifest, the EE certificate's validity period needs to be no + shorter than the nextUpdate time of the current manifest. + The extended validity time raises the possibility of a + substitution attack using a stale manifest, as described in + . + - - The data elements of the manifest structure are defined as - follows: - + + The data elements of the manifest structure are defined as + follows: + - - + + - - The version number of this version of the manifest - specification MUST be 0. - + + The version number of this version of the manifest + specification MUST be 0. + - This field is an integer that is incremented each time a - new manifest is issued for a given publication point. - This field allows an RP to detect gaps in a sequence of - published manifests. - - As the manifest is modeled on the CRL specification, the - ManifestNumber is analogous to the CRLNumber, and the - guidance in for CRLNumber values - is appropriate as to the range of number values that can - be used for the manifestNumber. Manifest numbers can be - expected to contain long integers. Manifest verifiers - MUST be able to handle number values up to 20 octets. - Conforming manifest issuers MUST NOT use number values - longer than 20 octets. - - - - This field contains the time when the manifest was - created. This field has the same format constraints as - specified in for the CRL field of - the same name. - - - - - This field contains the time at which the next scheduled - manifest will be issued. The value of nextUpdate MUST be - later than the value of thisUpdate. The specification of - the GeneralizedTime value is the same as required for the - thisUpdate field. + This field is an integer that is incremented each time a + new manifest is issued for a given publication point. + This field allows an RP to detect gaps in a sequence of + published manifests. - If the authority alters any of the items that it has - published in the repository publication point, then the - authority MUST issue a new manifest before the nextUpdate - time. If a manifest encompasses a CRL, the nextUpdate - field of the manifest MUST match that of the CRL's - nextUpdate field, as the manifest will be re-issued when a - new CRL is published. If a "one-time-use" EE certificate - is used to verify the manifest, then when a new manifest - is issued before the time specified in nextUpdate of the - current manifest, the CA MUST also issue a new CRL that - includes the EE certificate corresponding to the old - manifest. - + As the manifest is modeled on the CRL specification, the + ManifestNumber is analogous to the CRLNumber, and the + guidance in for CRLNumber values + is appropriate as to the range of number values that can + be used for the manifestNumber. Manifest numbers can be + expected to contain long integers. Manifest verifiers + MUST be able to handle number values up to 20 octets. + Conforming manifest issuers MUST NOT use number values + longer than 20 octets. + - - This field contains the OID of the hash algorithm used to - hash the files that the authority has placed into the - repository. The hash algorithm used MUST conform to the - RPKI Algorithms and Key Size Profile specification . - + + This field contains the time when the manifest was + created. This field has the same format constraints as + specified in for the CRL field of + the same name. + - - + + + This field contains the time at which the next scheduled + manifest will be issued. The value of nextUpdate MUST be + later than the value of thisUpdate. The specification of + the GeneralizedTime value is the same as required for the + thisUpdate field. + + If the authority alters any of the items that it has + published in the repository publication point, then the + authority MUST issue a new manifest before the nextUpdate + time. If a manifest encompasses a CRL, the nextUpdate + field of the manifest MUST match that of the CRL's + nextUpdate field, as the manifest will be re-issued when a + new CRL is published. If a "one-time-use" EE certificate + is used to verify the manifest, then when a new manifest + is issued before the time specified in nextUpdate of the + current manifest, the CA MUST also issue a new CRL that + includes the EE certificate corresponding to the old + manifest. + + + + This field contains the OID of the hash algorithm used to + hash the files that the authority has placed into the + repository. The hash algorithm used MUST conform to the + RPKI Algorithms and Key Size Profile specification . + + + + This field is a sequence of FileAndHash objects. There is one FileAndHash entry for each currently valid signed object that has been published by the authority (at this @@ -380,9 +383,9 @@ consisting of the name of the file in the repository publication point (directory) that contains the object in question and a hash of the file's contents. - - - + + +
@@ -407,22 +410,22 @@ - + - - The eContentType in the EncapsulatedContentInfo is - id-ad-rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). - + + The eContentType in the EncapsulatedContentInfo is + id-ad-rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). + - - The version of the rpkiManifest is 0. - + + The version of the rpkiManifest is 0. + - - In the rpkiManifest, thisUpdate precedes nextUpdate. - + + In the rpkiManifest, thisUpdate precedes nextUpdate. + - + @@ -447,79 +450,79 @@ - + - - If no key pair exists, or if using a "one-time-use" EE - certificate with a new key pair, generate a key pair. - + + If no key pair exists, or if using a "one-time-use" EE + certificate with a new key pair, generate a key pair. + - - If using a "one-time-use" EE certificate, or if a key pair - was generated in step 1, or if using a "sequential-use" EE - certificate that will expire before the intended nextUpdate - time of this manifest, issue an EE certificate for this key - pair. This EE certificate MUST have - an SIA extension access description field with an - accessMethod OID value of id-ad-signedobject, where the - associated accessLocation references the publication point - of the manifest as an object URL. - - This EE certificate MUST describe its Internet Number - Resources (INRs) using the "inherit" attribute, rather than - explicit description of a resource set (see ). - - In the case of a "one-time-use" EE certificate, the validity - times of the EE certificate MUST exactly match the - thisUpdate and nextUpdate times of the manifest. - - In the case of a "sequential-use" EE certificate, the - validity times of the EE certificate MUST encompass the time - interval from thisUpdate to nextUpdate. - + + If using a "one-time-use" EE certificate, or if a key pair + was generated in step 1, or if using a "sequential-use" EE + certificate that will expire before the intended nextUpdate + time of this manifest, issue an EE certificate for this key + pair. This EE certificate MUST have + an SIA extension access description field with an + accessMethod OID value of id-ad-signedobject, where the + associated accessLocation references the publication point + of the manifest as an object URL. + + This EE certificate MUST describe its Internet Number + Resources (INRs) using the "inherit" attribute, rather than + explicit description of a resource set (see ). + + In the case of a "one-time-use" EE certificate, the validity + times of the EE certificate MUST exactly match the + thisUpdate and nextUpdate times of the manifest. + + In the case of a "sequential-use" EE certificate, the + validity times of the EE certificate MUST encompass the time + interval from thisUpdate to nextUpdate. + - - The EE certificate MUST NOT be published in the authority's - repository publication point. - + + The EE certificate MUST NOT be published in the authority's + repository publication point. + - - Construct the manifest content. The - manifest content is described in . The manifest's fileList includes the - file name and hash pair for each object issued by this CA - that has been published at this repository publication point - (directory). The collection of objects to be included in - the manifest includes all certificates issued by this CA - that are published at the CA's repository publication point, - the most recent CRL issued by the CA, and all objects - verified by EE certificates that were issued by this CA that - are published at this repository publication point. - - Note that the manifest does not include a self reference - (i.e., its own file name and hash), since it would be - impossible to compute the hash of the manifest itself prior - to it being signed. - + + Construct the manifest content. The + manifest content is described in . The manifest's fileList includes the + file name and hash pair for each object issued by this CA + that has been published at this repository publication point + (directory). The collection of objects to be included in + the manifest includes all certificates issued by this CA + that are published at the CA's repository publication point, + the most recent CRL issued by the CA, and all objects + verified by EE certificates that were issued by this CA that + are published at this repository publication point. + + Note that the manifest does not include a self reference + (i.e., its own file name and hash), since it would be + impossible to compute the hash of the manifest itself prior + to it being signed. + - - Encapsulate the manifest content using the CMS SignedData - content type (as specified ), sign - the manifest using the private key corresponding to the - subject key contained in the EE certificate, and publish the - manifest in the repository system publication point that is - described by the manifest. - + + Encapsulate the manifest content using the CMS SignedData + content type (as specified ), sign + the manifest using the private key corresponding to the + subject key contained in the EE certificate, and publish the + manifest in the repository system publication point that is + described by the manifest. + - - In the case of a key pair that is to be used only once, in - conjunction with a "one-time-use" EE certificate, the - private key associated with this key pair MUST now be - destroyed. - + + In the case of a key pair that is to be used only once, in + conjunction with a "one-time-use" EE certificate, the + private key associated with this key pair MUST now be + destroyed. + - + @@ -527,41 +530,41 @@
- A new manifest MUST be issued and published on or before the - nextUpdate time. + A new manifest MUST be issued and published on or before the + nextUpdate time. - An authority MUST issue a new manifest in conjunction with the - finalization of changes made to objects in the publication - point. An authority MAY perform a number of object operations - on a publication repository within the scope of a repository - change before issuing a single manifest that covers all the - operations within the scope of this change. Repository - operators SHOULD implement some form of repository update - procedure that mitigates, to the extent possible, the risk that - RPs that are performing retrieval operations on the repository - are exposed to inconsistent, transient, intermediate states - during updates to the repository publication point (directory) - and the associated manifest. + An authority MUST issue a new manifest in conjunction with the + finalization of changes made to objects in the publication + point. An authority MAY perform a number of object operations + on a publication repository within the scope of a repository + change before issuing a single manifest that covers all the + operations within the scope of this change. Repository + operators SHOULD implement some form of repository update + procedure that mitigates, to the extent possible, the risk that + RPs that are performing retrieval operations on the repository + are exposed to inconsistent, transient, intermediate states + during updates to the repository publication point (directory) + and the associated manifest. - Since the manifest object URL is included in the SIA of issued - certificates, a new manifest MUST NOT invalidate the manifest - object URL of previously issued certificates. This implies that - the manifest's publication name in the repository, in the form - of an object URL, is unchanged across manifest generation - cycles. + Since the manifest object URL is included in the SIA of issued + certificates, a new manifest MUST NOT invalidate the manifest + object URL of previously issued certificates. This implies that + the manifest's publication name in the repository, in the form + of an object URL, is unchanged across manifest generation + cycles. - When a CA entity is performing a key rollover, the entity MAY - choose to have two CA instances simultaneously publishing into - the same repository publication point. In this case, there will - be one manifest associated with each active CA instance that is - publishing into the common repository publication point - (directory). + When a CA entity is performing a key rollover, the entity MAY + choose to have two CA instances simultaneously publishing into + the same repository publication point. In this case, there will + be one manifest associated with each active CA instance that is + publishing into the common repository publication point + (directory).
@@ -592,101 +595,106 @@
- For a given publication point, the RP SHOULD perform the - following tests to determine the manifest state of the - publication point: + For a given publication point, the RP SHOULD perform the + following tests to determine the manifest state of the + publication point: - + - - For each CA using this publication point, select the CA's - current manifest (the "current" manifest is the manifest - issued by this CA having the highest manifestNumber among - all valid manifests, and where manifest validity is defined - in ). If - the publication point does not contain a valid manifest, see - . Lacking a valid manifest, the - following tests cannot be performed. - + + For each CA using this publication point, select the CA's + current manifest (the "current" manifest is the manifest + issued by this CA having the highest manifestNumber among + all valid manifests, and where manifest validity is defined + in ). If + the publication point does not contain a valid manifest, see + . Lacking a valid manifest, the + following tests cannot be performed. + - - To verify completeness, an RP MAY check that every file at - each publication point appears in one and only one current - manifest, and that every file listed in a current manifest - is published at the same publication point as the - manifest. If there exist files at - the publication point that do not appear on any manifest, or - files listed in a manifest that do not appear at the - publication point, then see , but - still continue with the following test. - + + To verify completeness, an RP MAY check that every file at + each publication point appears in one and only one current + manifest, and that every file listed in a current manifest + is published at the same publication point as the + manifest. If there exist files at + the publication point that do not appear on any manifest, or + files listed in a manifest that do not appear at the + publication point, then see , but + still continue with the following test. + - - Check that the current time (translated to UTC) is between - thisUpdate and nextUpdate. If the - current time does not lie within this interval, then see - , but still continue with the - following tests. - + + Check that the current time (translated to UTC) is between + thisUpdate and nextUpdate. If the + current time does not lie within this interval, then see + , but still continue with the + following tests. + - - Verify that the listed hash value of every file listed in - each manifest matches the value obtained by hashing the file - at 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 see - . - + + Verify that the listed hash value of every file listed in + each manifest matches the value obtained by hashing the file + at 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 see + . + - - An RP MAY check that the contents of each current manifest - conforms to the manifest's scope constraints, as specified - in . - + + An RP MAY check that the contents of each current manifest + conforms to the manifest's scope constraints, as specified + in . + - - If a current manifest contains entries for objects that are - not within the scope of the manifest, then the out-of-scope - entries SHOULD be disregarded in the context of this - manifest. If there is no other current manifest that - describes these objects within that other manifest's scope, - then see . - - + + If a current manifest contains entries for objects that are + not within the scope of the manifest, then the out-of-scope + entries SHOULD be disregarded in the context of this + manifest. If there is no other current manifest that + describes these objects within that other manifest's scope, + then see . - - the manifest for its publication and the associated - publication point pass all of the above checks; - + - - the signed object is valid; and - + + - - the manifests for every certificate on the certification - path used to validate the signed object and the - associated publication points pass all of the above - checks; - + - - + + the manifest for its publication and the associated + publication point pass all of the above checks; + - - - + + the signed object is valid; and + + + + the manifests for every certificate on the + certification path used to validate the signed + object and the associated publication points pass + all of the above checks; + + + + + + + + + - then the RP can conclude that no attack against the repository - system has compromised the given signed object, and the signed - object MUST be treated as valid (relative to manifest - checking). + then the RP can conclude that no attack against the repository + system has compromised the given signed object, and the signed + object MUST be treated as valid (relative to manifest + checking).
@@ -694,49 +702,49 @@
- The absence of a current manifest at a publication point could - occur due to an error by the publisher or due to (malicious or - accidental) deletion or corruption of all valid manifests. + The absence of a current manifest at a publication point could + occur due to an error by the publisher or due to (malicious or + accidental) deletion or corruption of all valid manifests. - When no valid manifest is available, there is no protection - against attacks that delete signed objects or replay old - versions of signed objects. All signed objects at the - publication point, and all descendant objects that are validated - using a certificate at this publication point, SHOULD be viewed - as suspect, but MAY be used by the RP, as per local policy. + When no valid manifest is available, there is no protection + against attacks that delete signed objects or replay old + versions of signed objects. All signed objects at the + publication point, and all descendant objects that are validated + using a certificate at this publication point, SHOULD be viewed + as suspect, but MAY be used by the RP, as per local policy. - The primary risk in using signed objects at this publication - point is that a superseded (but not stale) CRL would cause an RP - to improperly accept a revoked certificate as valid (and thus - rely upon signed objects that are validated using that - certificate). This risk is somewhat mitigated if the CRL for - this publication point has a short time between thisUpdate and - nextUpdate (and the current time is within this interval). The - risk in discarding signed objects at this publication point is - that an RP may incorrectly discard a large number of valid - objects. This gives significant power to an adversary that is - able to delete a manifest at the publication point. + The primary risk in using signed objects at this publication + point is that a superseded (but not stale) CRL would cause an RP + to improperly accept a revoked certificate as valid (and thus + rely upon signed objects that are validated using that + certificate). This risk is somewhat mitigated if the CRL for + this publication point has a short time between thisUpdate and + nextUpdate (and the current time is within this interval). The + risk in discarding signed objects at this publication point is + that an RP may incorrectly discard a large number of valid + objects. This gives significant power to an adversary that is + able to delete a manifest at the publication point. - Regardless of whether signed objects from this publication are - deemed fit for use by an RP, this situation SHOULD result in a - warning to the effect that: "No manifest is available for - <pub point name>, and thus there may have been undetected - deletions or replay substitutions from the publication point." + Regardless of whether signed objects from this publication are + deemed fit for use by an RP, this situation SHOULD result in a + warning to the effect that: "No manifest is available for + <pub point name>, and thus there may have been undetected + deletions or replay substitutions from the publication point." - In the case where an RP has access to a local cache of - previously issued manifests that are valid, the RP MAY use the - most recently previously issued valid manifests for this RPKI - repository publication collection for each entity that publishes - at this publication point. + In the case where an RP has access to a local cache of + previously issued manifests that are valid, the RP MAY use the + most recently previously issued valid manifests for this RPKI + repository publication collection for each entity that publishes + at this publication point.
@@ -744,37 +752,37 @@
- The presence of an invalid manifest at a publication point could - occur due to an error by the publisher or due to (malicious or - accidental) corruption of a valid manifest. An invalid manifest - MUST never be used, even if the manifestNumber of the invalid - manifest is greater than that of other (valid) manifests. + The presence of an invalid manifest at a publication point could + occur due to an error by the publisher or due to (malicious or + accidental) corruption of a valid manifest. An invalid manifest + MUST never be used, even if the manifestNumber of the invalid + manifest is greater than that of other (valid) manifests. - There are no risks associated with using signed objects at a - publication point containing an invalid manifest, provided that - valid manifests that collectively cover all the signed objects - are also present. + There are no risks associated with using signed objects at a + publication point containing an invalid manifest, provided that + valid manifests that collectively cover all the signed objects + are also present. - If an invalid manifest is present at a publication point that - also contains one or more valid manifests, this situation SHOULD - result in a warning to the effect that: "An invalid manifest was - found at <pub point name>, this indicates an attack - against the publication point or an error by the publisher. - Processing for this publication point will continue using the - most recent valid manifest(s)." + If an invalid manifest is present at a publication point that + also contains one or more valid manifests, this situation SHOULD + result in a warning to the effect that: "An invalid manifest was + found at <pub point name>, this indicates an attack + against the publication point or an error by the publisher. + Processing for this publication point will continue using the + most recent valid manifest(s)." - In the case where the RP has access to a local cache of - previously issued (valid) manifests, an RP MAY make use of that - locally cached data. Specifically, the RP MAY use the locally - cached, most recent, previously issued, valid manifest issued by - the entity that (appears to have) issued the invalid manifest. + In the case where the RP has access to a local cache of + previously issued (valid) manifests, an RP MAY make use of that + locally cached data. Specifically, the RP MAY use the locally + cached, most recent, previously issued, valid manifest issued by + the entity that (appears to have) issued the invalid manifest.
@@ -782,162 +790,162 @@
- A manifest is considered stale if the current time is after the - nextUpdate time for the manifest. This could be due to - publisher failure to promptly publish a new manifest, or due to - (malicious or accidental) corruption or suppression of a more - recent manifest. + A manifest is considered stale if the current time is after the + nextUpdate time for the manifest. This could be due to + publisher failure to promptly publish a new manifest, or due to + (malicious or accidental) corruption or suppression of a more + recent manifest. - All signed objects at the publication point issued by the entity - that has published the stale manifest, and all descendant signed - objects that are validated using a certificate issued by the - entity that has published the stale manifest at this publication - point, SHOULD be viewed as somewhat suspect, but MAY be used by - the RP as per local policy. + All signed objects at the publication point issued by the entity + that has published the stale manifest, and all descendant signed + objects that are validated using a certificate issued by the + entity that has published the stale manifest at this publication + point, SHOULD be viewed as somewhat suspect, but MAY be used by + the RP as per local policy. - The primary risk in using such signed objects is that a newer - manifest exists that, if present, would indicate that certain - objects have been removed or replaced. (For example, the new - manifest might show the existence of a newer CRL and the removal - of one or more revoked certificates). Thus, the use of objects - from a stale manifest may cause an RP to incorrectly treat - invalid objects as valid. The risk is that the CRL covered by - the stale manifest has been superseded, and thus an RP will - improperly treat a revoked certificate as valid. This risk is - somewhat mitigated if the time between the nextUpdate field of - the manifest and the current time is short. The risk in - discarding signed objects at this publication point is that the - RP may incorrectly discard a large number of valid objects. - This gives significant power to an adversary that is able to - prevent the publication of a new manifest at a given publication - point. + The primary risk in using such signed objects is that a newer + manifest exists that, if present, would indicate that certain + objects have been removed or replaced. (For example, the new + manifest might show the existence of a newer CRL and the removal + of one or more revoked certificates). Thus, the use of objects + from a stale manifest may cause an RP to incorrectly treat + invalid objects as valid. The risk is that the CRL covered by + the stale manifest has been superseded, and thus an RP will + improperly treat a revoked certificate as valid. This risk is + somewhat mitigated if the time between the nextUpdate field of + the manifest and the current time is short. The risk in + discarding signed objects at this publication point is that the + RP may incorrectly discard a large number of valid objects. + This gives significant power to an adversary that is able to + prevent the publication of a new manifest at a given publication + point. - Regardless of whether signed objects from this publication are - deemed fit for use by an RP, this situation SHOULD result in a - warning to the effect that: "A manifest found at <pub point - name> is no longer current. It is possible that undetected - deletions have occurred at this publication point." + Regardless of whether signed objects from this publication are + deemed fit for use by an RP, this situation SHOULD result in a + warning to the effect that: "A manifest found at <pub point + name> is no longer current. It is possible that undetected + deletions have occurred at this publication point." - Note that there is also the potential for the current time to be - before the thisUpdate time for the manifest. This case could be - due to publisher error or a local clock error; in such a case, - this situation SHOULD result in a warning to the effect that: "A - manifest found at <pub point name> has an incorrect - thisUpdate field. This could be due to publisher error, or a - local clock error, and processing for this publication point - will continue using this otherwise valid manifest." + Note that there is also the potential for the current time to be + before the thisUpdate time for the manifest. This case could be + due to publisher error or a local clock error; in such a case, + this situation SHOULD result in a warning to the effect that: "A + manifest found at <pub point name> has an incorrect + thisUpdate field. This could be due to publisher error, or a + local clock error, and processing for this publication point + will continue using this otherwise valid manifest."
+ anchor="sect-6.5"> - If there exist valid signed objects that do not appear in any - manifest, then, provided the manifest is not stale (see ), it is likely that their omission is an - error by the publisher. It is also possible that this state - could be the result of a (malicious or accidental) replacement - of a current manifest with an older, but still valid, manifest. - However, regarding the appropriate interpretation of such - objects, it remains the case that if the objects were intended - to be invalid, then they should have been revoked using whatever - revocation mechanism is appropriate for the signed object in - question. Therefore, there is little risk in using such signed - objects. If the publication point contains a stale manifest, - then there is a greater risk that the objects in question were - revoked, along with a missing Certificate Revocation List (CRL), - the absence of which is undetectable since the manifest is - stale. In any case, the use of signed objects not present on a - manifest, or descendant objects that are validated using such - signed objects, is a matter of local policy. + If there exist valid signed objects that do not appear in any + manifest, then, provided the manifest is not stale (see ), it is likely that their omission is an + error by the publisher. It is also possible that this state + could be the result of a (malicious or accidental) replacement + of a current manifest with an older, but still valid, manifest. + However, regarding the appropriate interpretation of such + objects, it remains the case that if the objects were intended + to be invalid, then they should have been revoked using whatever + revocation mechanism is appropriate for the signed object in + question. Therefore, there is little risk in using such signed + objects. If the publication point contains a stale manifest, + then there is a greater risk that the objects in question were + revoked, along with a missing Certificate Revocation List (CRL), + the absence of which is undetectable since the manifest is + stale. In any case, the use of signed objects not present on a + manifest, or descendant objects that are validated using such + signed objects, is a matter of local policy. - Regardless of whether objects not appearing on a manifest are - deemed fit for use by the RP, this situation SHOULD result in a - warning to the effect that: "The following files are present in - the repository at <pub point name>, but are not listed on - any manifest <file list> for <pub point name>." + Regardless of whether objects not appearing on a manifest are + deemed fit for use by the RP, this situation SHOULD result in a + warning to the effect that: "The following files are present in + the repository at <pub point name>, but are not listed on + any manifest <file list> for <pub point name>." - If there exists files listed on the manifest that do not appear - in the repository, then these objects are likely to have been - improperly (via malice or accident) deleted from the repository. - A primary purpose of manifests is to detect such deletions. - Therefore, in such a case, this situation SHOULD result in a - warning to the effect that: "The following files that should - have been present in the repository at <pub point name> - are missing <file list>. This indicates an attack against - this publication point, or the repository, or an error by the - publisher." + If there exists files listed on the manifest that do not appear + in the repository, then these objects are likely to have been + improperly (via malice or accident) deleted from the repository. + A primary purpose of manifests is to detect such deletions. + Therefore, in such a case, this situation SHOULD result in a + warning to the effect that: "The following files that should + have been present in the repository at <pub point name> + are missing <file list>. This indicates an attack against + this publication point, or the repository, or an error by the + publisher."
+ anchor="sect-6.6"> - A file appearing on a manifest with an incorrect hash value - could occur because of publisher error, but it also may indicate - that an attack has occurred. + A file appearing on a manifest with an incorrect hash value + could occur because of publisher error, but it also may indicate + that an attack has occurred. - If an object appeared on a previous valid manifest with a - correct hash value, and it now appears with an invalid hash - value, then it is likely that the object has been superseded by - a new (unavailable) version of the object. If the object is - used, there is a risk that the RP will be treating a stale - object as valid. This risk is more significant if the object in - question is a CRL. If the object can be validated using the - RPKI, the use of these objects is a matter of local policy. + If an object appeared on a previous valid manifest with a + correct hash value, and it now appears with an invalid hash + value, then it is likely that the object has been superseded by + a new (unavailable) version of the object. If the object is + used, there is a risk that the RP will be treating a stale + object as valid. This risk is more significant if the object in + question is a CRL. If the object can be validated using the + RPKI, the use of these objects is a matter of local policy. - If an object appears on a manifest with an invalid hash and has - never previously appeared on a manifest, then it is unclear - whether the available version of the object is more or less - recent than the version indicated by the manifest. If the - manifest is stale (see ), then it - becomes more likely that the available version is more recent - than the version indicated on the manifest, but this is never - certain. Whether to use such objects is a matter of local - policy. However, in general, it is better to use a possibly - outdated version of the object than to discard the object - completely. + If an object appears on a manifest with an invalid hash and has + never previously appeared on a manifest, then it is unclear + whether the available version of the object is more or less + recent than the version indicated by the manifest. If the + manifest is stale (see ), then it + becomes more likely that the available version is more recent + than the version indicated on the manifest, but this is never + certain. Whether to use such objects is a matter of local + policy. However, in general, it is better to use a possibly + outdated version of the object than to discard the object + completely. - While it is a matter of local policy, in the case of CRLs, an RP - SHOULD endeavor to use the most recently issued valid CRL, even - where the hash value in the manifest matches an older CRL or - does not match any available CRL for a CA instance. The - thisUpdate field of the CRL can be used to establish the most - recent CRL in the case where an RP has more than one valid CRL - for a CA instance. + While it is a matter of local policy, in the case of CRLs, an RP + SHOULD endeavor to use the most recently issued valid CRL, even + where the hash value in the manifest matches an older CRL or + does not match any available CRL for a CA instance. The + thisUpdate field of the CRL can be used to establish the most + recent CRL in the case where an RP has more than one valid CRL + for a CA instance. - Regardless of whether objects with incorrect hashes are deemed - fit for use by the RP, this situation SHOULD result in a warning - to the effect that: "The following files at the repository - <pub point name> appear on a manifest with incorrect hash - values <file list>. It is possible that these objects - have been superseded by a more recent version. It is very - likely that this problem is due to an attack on the publication - point, although it also could be due to a publisher error." + Regardless of whether objects with incorrect hashes are deemed + fit for use by the RP, this situation SHOULD result in a warning + to the effect that: "The following files at the repository + <pub point name> appear on a manifest with incorrect hash + values <file list>. It is possible that these objects + have been superseded by a more recent version. It is very + likely that this problem is due to an attack on the publication + point, although it also could be due to a publisher error."
@@ -1010,11 +1018,11 @@
- +
@@ -1026,11 +1034,11 @@
- + ]]>
@@ -1054,88 +1062,87 @@ - + + + + + + + + - - - - + --> + - + + + -
+
-
- - - -
+
+ + - - - -
-
+ END + ]]> + + +
-