Subject: [Sidrops] revised text for section 6 of 6486bis

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Dec 2020 11:28:29 -0500

Based on the numerous comments posted over the past 2+ weeks I have 
revised the text of section 6 of the document. The revised text focuses 
exclusively on using a Manifest to ensure that the set of files 
retrieved from a pub point match those that were posted by the cognizant 
CA instance.

Thus, for example, the text no longer requires that the files being 
retrieved be verified based on RFC 6488.  As a result, there is no need 
to enumerate the object types that are mandatory to support. 
Consequently, there is no need to specify how to deal with files that 
are retrieved but that are not among the mandatory-to-support object 
types. All of that now belongs in other documents, given the 
newly-agreed upon scope limitation for Manifest processing.

For example, the section no longer requires that there be only one CRL, 
consistent with the notion that the purpose of the manifest is to ensure 
that the retrieved objects matches what the CA published.

Because we have removed the object validation constraints from this 
document, we can no longer state that "The processing described below is 
designed to cause all RPs with access to the same local cache and RPKI 
repository data to achieve the same results with regard to validation of 
RPKI data." Instead, the text now states: "The processing described 
below is designed to cause all RPs with access to the same local cache 
and RPKI repository data to acquire the same set of validated repository 
files. It does not ensure thatthe RPs will achieve the same results with 
regard to validation of RPKI data, since that depends on how each RP 
resolves any conflicts that may arise in processing the retrieved files."

Steve

--------

6.Relying Party Processing of Manifests

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).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.

[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).

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.

The processing described below is designed to cause all RPs with

access to the same local cache and RPKI repository data to acquire

the same set of validated repository files. It does not ensure that

the RPs will achieve the same results with regard to validation of

RPKI data, since that depends on how each RP resolves any conflicts

that may arise in processing the retrieved files. Moreover, 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

acquisition or validation of RPKI data.

Note also that there is a "chicken and egg" relationship between the

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 the fetch has failed; proceed to Section 6.7.

Similarly, if the CRL is not listed on a valid, current manifest,

acquired during a fetch, the fetch has failed; proceed to

Section 6.7, because the CRL is considered missing.

6.1.Manifest Processing Overview

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 (Section 6.2 to Section 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 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 Section 6.7

below).

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.

6.2.Acquiring a Manifest for a CA

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

(Section 4.4), an RP MUST treat this as a failed fetch and, proceed

to Section 6.7; otherwise proceed to Section 6.3.

6.3.Detecting Stale and or Prematurely-issued Manifests

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 Section 6.4.If the current time is

earlier than thisUpdate, the CA has made an error; this is a failed

fetch and the RP MUST proceed to Section 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 Section 6.7; otherwise proceed to

Section 6.4.

6.4.Acquiring Files Referenced by a Manifest

The RP MUST acquire all of the files enumerated in the manifest

(fileList) from the publication point. If there are files listed in

the manifest that cannot be retrieved from the publication point, the

fetch has failed and the RP MUST proceed to Section 6.7; otherwise,

proceed to Section 6.5

6.5.Matching File Names and Hashes

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

Section 6.7; otherwise proceed to Section 6.6.

6.6.Out of Scope Manifest Entries

If a current manifest contains entries for objects that are not

within the scope of the manifest (Section 6.2), the fetch has failed

and the RP SHOULD proceed to Section 6.7; otherwise the fetch is

deemed successful and the RP will process the fetched objects.

6.7.Failed Fetches

If a fetch fails for any of the reasons cited in 6.2-6.6, the RP MUST

issue a warning indicating the reason(s)for termination of processing

with regard to this CA instance.It is RECOMMENDED that a human

operator be notified of this warning.

Termination of 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.

---

From: Ties de Kock <[email-masked]>
Date: Wed, 23 Dec 2020 15:49:18 +0100

Hi all,

I was reading the draft, and I could not understand the intent of Section 6.6,
out of Scope Manifest Entries.

To me, this paragraph seems to be either a leftover from an earlier version of
RFC 6486 (6.1.5/6.1.6) or a reference to Section 2 (manifest scope). In the latter
case, it goes against the notion of just using the manifest to verify that the
publication point contains the files the CA intended to publish.

I would propose to remove the section in its current form, but in that case, I
think we need some text that clarifies how RPs should handle unknown objects.

Kind regards,
Ties

> On 18 Dec 2020, at 17:28, Stephen Kent <stkent=[email-masked]> wrote:
> 
> Based on the numerous comments posted over the past 2+ weeks I have revised the text of section 6 of the document. The revised text focuses exclusively on using a Manifest to ensure that the set of files retrieved from a pub point match those that were posted by the cognizant CA instance.
> 
> Thus, for example, the text no longer requires that the files being retrieved be verified based on RFC 6488.  As a result, there is no need to enumerate the object types that are mandatory to support. Consequently, there is no need to specify how to deal with files that are retrieved but that are not among the mandatory-to-support object types. All of that now belongs in other documents, given the newly-agreed upon scope limitation for Manifest processing.
> 
> For example, the section no longer requires that there be only one CRL, consistent with the notion that the purpose of the manifest is to ensure that the retrieved objects matches what the CA published.
> 
> Because we have removed the object validation constraints from this document, we can no longer state that "The processing described below is designed to cause all RPs with access to the same local cache and RPKI repository data to achieve the same results with regard to validation of RPKI data." Instead, the text now states: " The processing described below is designed to cause all RPs with access to the same local cache and RPKI repository data to acquire the same set of validated repository files. It does not ensure that the RPs will achieve the same results with regard to validation of RPKI data, since that depends on how each RP resolves any conflicts that may arise in processing the retrieved files."
> 
> Steve
> 
> --------
> 
> 
>  <>6.  Relying Party Processing of Manifests
>  
>    use in the construction of route filters).  As noted earlier,
>    successful, fetch represented in the RP's local cache.  This document
>    effect this operation.  Thus the term "fetch" refers to an operation
>    problems encountered during the fetch.  Until such time as a
>    previous, successful fetch.  This response is intended to prevent an
>    manifest and the CRL for a given CA instance.  If the EE certificate
>    error.  In this case the fetch has failed; proceed to Section 6.7.
> 6.1.  Manifest Processing Overview
>  
>    acceptable.  The tests described below (Section 6.2 to Section 6.6)
>    rpkiManifest URI extracted from a CA certificate's SIA.  All of the
>    (same) CA certificate's SIA.  The manifest and the files it
>    references MUST reside at the same publication point.  If an RP
>    point.  Manifest processing is to be performed separately for each CA
> 6.2.  Acquiring a Manifest for a CA
>  
>    rpkiManifest URI in the CA certificate.  If an RP cannot retrieve a
> 6.3.  Detecting Stale and or Prematurely-issued Manifests
>  
>    between thisUpdate and nextUpdate.  If the current time lies within
>    this interval, proceed to Section 6.4.  If the current time is
>    fetch and the RP MUST proceed to Section 6.7.  If the current time is
> 6.4.  Acquiring Files Referenced by a Manifest
>  
> 6.5.  Matching File Names and Hashes
>  
>    the publication point.  If the computed hash value of a file listed
> 6.6.  Out of Scope Manifest Entries
>  
> 6.7.  Failed Fetches
>    with regard to this CA instance.  It is RECOMMENDED that a human 
>    objects from a successful fetch.  This implies that the RP MUST not
> _______________________________________________
> Sidrops mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sidrops <https://www.ietf.org/mailman/listinfo/sidrops>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Dec 2020 11:41:20 -0500

Ties,

You make a good point. The text in 6.6 is a hold over from previous 
revisions. It does go against the notion of using the manifest only to 
ensure that the files retrieved by an RP are the same as the ones 
published by the relevant CA. So, I have removed that text as shown below.

Removing the requirement to verify that the retrieve files match the 
manifest scope will not be a concern if we can identify other RPKI RFCs 
that require the RP to perform all of the same checks. The scope of a 
manifest is defined in Section 2 of 8486 as:

 ��� 1. the set of (non-expired, non-revoked) certificates issued and 
published by this CA,

 �� 2. the most recent CRL issued by this CA, and

 �� 3. all published signed objects that are verifiable using EE 
certificates [RFC6487] issued by this CA

The cert validation described in 6487 should ensure that all of the 
certs encountered are not revoked and not expired, so #1 is satisfied 
elsewhere. Similarly, 6487 requires an RP to check that is has acquired 
a current CRL, although is does not address the issue of having 
encountered multiple CRL files as part of a fetch. That still seems to 
be an area where some additional clarification of behavior is needed.

It is not clear that #3 above is addressed in other RFCs. If a ROA is 
missing, because the CA failed to publish it, it's not clear which other 
PKIX RFC will cause an RP to detect this. Similarly, if a subordinate CA 
cert is missing from the pub point, and the manifest, it's not clear how 
an RP will detect this (possibly erroneous) omission by the CA. The 
simple requirement that what is retrieved is what was published will 
have been met, but this still allows several forms of CA errors to go 
undetected by an RP.

Steve

-----

Note also that there is a "chicken and egg" relationship between the
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 the fetch has failed; proceed to Section 6.6.
Similarly, if the CRL is not listed on a valid, current manifest,
acquired during a fetch, the fetch has failed; proceed to
Section 6.6, because the CRL is considered missing.

acceptable.The tests described below (Section 6.2 to Section 6.5)
fetch as failed, and a warning MUST be issued (see Section 6.6
below).

to Section 6.6; otherwise proceed to Section 6.3.

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 Section 6.4.If the current time is
earlier than thisUpdate, the CA has made an error; this is a failed
fetch and the RP MUST proceed to Section 6.6.If the current time is
later than nextUpdate, then the manifest is stale; this is a failed
fetch and RP MUST proceed to Section 6.6; otherwise proceed to
Section 6.4.

The RP MUST acquire all of the files enumerated in the manifest
(fileList) from the publication point. If there are files listed in
the manifest that cannot be retrieved from the publication point, the
fetch has failed and the RP MUST proceed to Section 6.6; otherwise,
proceed to Section 6.5

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
Section 6.6; otherwise he fetch isdeemed successful and the RP will
 � process the fetched objects.

6.6.Failed Fetches