Subject: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)

From: Stephen Kent <[email-masked]>
Date: Fri, 8 May 2020 11:26:22 -0400

6.Relying Party Use 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). 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.

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. However, 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

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

6.2 Acquiring a Manifest for a CA

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 (Section 4.4) proceed to 6.3. If the publication point
does not contain a valid manifest, and the cached manifest is not current,

proceed to 6.7.

6.3 Detecting Stale and or Prematurely-issued Manifests

Check that the current time (translated to UTC) is between
thisUpdate and nextUpdate. If the current time lies within this interval,

proceed to 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 6.7.

6.4 Acquiring Files Referenced by a Manifest

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

[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 6.5. However, if _any_ of the 
missing/invalid files cannot be replaced in this fashion, then proceed 
to 6.7.

6.5 Matching File Names and Hashes

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 
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 2), then the out-of-scope

entries MUST be disregarded.

6.7 Termination of Processing

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 indicating the reason(s) for 
termination of processing with regard to this CA.

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.

---

From: Di Ma <[email-masked]>
Date: Sat, 9 May 2020 01:33:29 +0800

Steve,

Thanks for your efforts for writing MFT update and reflecting the feedback from the mailing list.

I am fine with it except the re-use of previous local cache.

I find it is hard to implement the logic about retrieving objects from local cache with RPSTIR2. 

As I replied to Robert in your discussion with him, in terms of synchronization, RPSTIR2 keeps its incumbent local version exactly the same with global repositories.

Although RPSTIR2 keeps the historic versions locally, they are stored for diagnose and analysis (maybe to trigger SLURM)

If some RP can retrieve missing objects while others can not, data inconsistence will occur among different RPs.

I think we just need to keep RP in alignment with PP and then can perform some analysis and diagnose (if necessary) to ascertain errors (RFC 8211) to give warning or make use of SLURM (RFC8416) if the RP operator is confident enough that he catch the wrong data and knows how to remedy locally.

To sum up, I would like to see :

1) RPs are encouraged to store historic versions locally especially the validated RTR-output

2) If the RP finds some missing objects (not in the CRL, still in the MFT) , it is suggested to issue warning to operators and SLURM can be used by the historic data.

I therefore really look forwards to hearing from folks of other RP software to comment on this.

Di

> 2020年5月8日 23:26，Stephen Kent <stkent=[email-masked]> 写道：
> 
> 
> 6.  Relying Party Use of Manifests
>  
> errors by a CA or repository manager. Unless all of the files 
> 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 
> references do not reside at the same publication point, an RP MUST ???
>  
> one encountered MUST be used.  Any other .crl files MUST be ignored and a warning MUST be issued.
>  
> 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.
> are available locally. If all of the missing/invalid files are available
> from the publication point, and proceed to 6.5. However, if any of the missing/invalid files cannot be replaced in this fashion, then proceed to 6.7.
> 
> 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 6.6.
> 
> 
> has failed. The RP MUST issue a warning indicating the reason(s) for termination of processing with regard to this CA. 
>  
> 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, 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops
>

---

From: Job Snijders <[email-masked]>
Date: Fri, 8 May 2020 18:00:39 +0000

Dear Di Ma,

> local cache with RPSTIR2. 

Can you elaborate on why it is hard in RSTPIR2? I am not familiar with
this implementation and can perhaps learn from it, or offer suggestions.

> As I replied to Robert in your discussion with him, in terms of
> synchronization, RPSTIR2 keeps its incumbent local version exactly the
> same with global repositories.

An RP can't know if it is in sync with the global repository. The trust
derives from the pre-obtained RPKI TALs, through the X509 validation
procedure and outputs Validated ROA Payloads.

In this process the data that can be *least* trusted is what came in via
the untrusted network channel (be it rsync or RRDP). Withholding or
corruption by issuing 'withdraws' (RRDP)  or '--delete' (rsync) cannot
be trusted at all. With this in mind, one really really aught to
reconstruct the original publication point's repository, suppplementing
it with locally cached data as much as possible.

> Although RPSTIR2 keeps the historic versions locally, they are stored
> for diagnose and analysis (maybe to trigger SLURM)
> 
> If some RP can retrieve missing objects while others can not, data
> inconsistence will occur among different RPs.

This already always is the case, and will not change. RPs pull from the
CA's publication point from different places on the Internet, at
different times.

> I think we just need to keep RP in alignment with PP and then can
> perform some analysis and diagnose (if necessary) to ascertain errors
> (RFC 8211) to give warning or make use of SLURM (RFC8416) if the RP
> operator is confident enough that he catch the wrong data and knows
> how to remedy locally.

How will the RP stay in alignment with the PP when the RP is under
attack? Intercepting and corrupting rsync connections is trivial and the
RRDP protocol does not offer protections against unauthorised
modification of the data presented to the RP.

> 2) If the RP finds some missing objects (not in the CRL, still in the
> MFT) , it is suggested to issue warning to operators and SLURM can be
> used by the historic data.

What is the 'timing' of the process you describe under (2)? I cannot
imagine any manual intervention in the validation process to scale for
the purpose of the Internet routing system. Perhaps I'm
misunderstanding.

> software to comment on this.

It is my intention to provide the working group with an implementation
report of OpenBSD's current rpki-client version in relation to the text
that Stephen Kent provided today as 'rev 4'. I hope to be able to do
that next week. My report will be usable as a template for other
implementation maintainers. Comparing and sharing implementation notes
is fun, stay tuned!

Kind regards,

Job

---

From: Di Ma <[email-masked]>
Date: Mon, 11 May 2020 14:21:45 +0800

Job,

> 2020年5月9日 02:00，Job Snijders <[email-masked]> 写道：
> 
> Dear Di Ma,
> 

When I say hard, I mean I cannot estimate when ‘a specific object’ will be retrieved from a specific historic version of local cache. 

And we don’t know then we need to cache all the historic versions in case of missing objects. 

And it is even worse when the missing stuff is Resource Certificate, the SIA of which will affect where the RP to find the subordinate repository. This happens in the middle of sync. Accordingly the RP will use a well-designed algorithm to search all the historic versions efficiently.

I am not saying we cannot do that but this is really deserves an effort.

I really look forwards to seeing your big idea or suggestions:-)

> CA's publication point from different places on the Internet, at

I have to admit that keep all the RP throughout the Internet keep in pace for sync is over-ideal. 

> modification of the data presented to the RP.

I am considering deploying multiple RP instances by diversifying its locations to avoid MITM attack. 

> the purpose of the Internet routing system. Perhaps I'm

I expect this work this way:

1) A missing object found;
2) Warning issued to RP operator, indicating which VRP will be adversely affected and providing suggested SLURM Assertion;
3) SLURM acknowledged to add this Assertion to the validated cache affected by the missing object (ROA for example)

> implementation maintainers. Comparing and sharing implementation notes

Always glad to see someone sharing RP implementation notes :-)

Di

---

From: Rob Austein <[email-masked]>
Date: Tue, 12 May 2020 17:13:14 -0400

On Fri, 08 May 2020 11:26:22 -0400, Stephen Kent wrote:
...
> 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.

I went back and looked at how my RP code handled this.  One can very
quickly get lost in the weeds here, but briefly: I start with a set of
"candidate manifests" and a set of "candidate CRLs", and keep pruning
those sets down with one form of validity check after another
(signatures and hashes must match, timestamps must be sane, URIs must
match, yada yada).  If, at the end of this I still have more than one
candidate CRL, I don't necessarily pick the first CRL in the manifest:
instead, I sort the candidates by CRL Number, thisUpdate, and time at
which I retrieved that CRL object (in descending order of preference,
so the timestamps only matter if CRL Number is identical, etc), and
use this to pick the "most recent" valid CRL.

YMMV, but this arguably yields a more useful result in this screwball
situation.  That said, this is (obviously) more complex to describe
and to implement, so may not be worth it, given that this should never
be happening in the first place.

If one wants a simplified version of this algorithm that stays within
the confines of a single manifest, one could do the sort by CRL
Number, then thisUpdate, then position in the manifest.

--Rob

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 13 May 2020 11:22:44 +0200

Hi,

> On 12 May 2020, at 23:13, Rob Austein <[email-masked]> wrote:
> 

To the best of my knowledge there has never been any RPKI CA implementation which will use more than one .crl per manifest. So, can't we just simplify life and make sure that no one does in future?

It won't break any existing code, we just need to make it clear to new CA implementers that they should not needlessly complicate life for themselves and everybody else.

Tim

---

From: Stephen Kent <[email-masked]>
Date: Wed, 13 May 2020 09:53:18 -0400

Rob,
>> at the location specified in the CRLDP in the manifestοΏ½s EE
I will revise the text describing how to handle this case, based on WG 
consensus. Your approach is very robust, but also complex. Since there 
should be only one CRL in the manifest, and since Tim says that no RPKI 
CA generates more thanοΏ½ one, I tend to favor a simple requirement here, 
but ...

Steve

---

From: Randy Bush <[email-masked]>
Date: Wed, 13 May 2020 07:05:15 -0700

> should be only one CRL in the manifest, and since Tim says that no
> RPKI CA generates more than� one, I tend to favor a simple
> requirement here, but ...

indeed no ca SHOULD push more than one CRL.  but i do not think i would
recommend not defending against it.

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 13 May 2020 16:32:15 +0200

> On 13 May 2020, at 16:05, Randy Bush <[email-masked]> wrote:
> 

In my opinion there should be a MUST include one and only one CRL. Then offending MFTs can be considered broken, and there is no defensive code needed.

I don't see how this could be an issue for CAs given that none include more than one CRL on MFTs until now. But if other CA implementers disagree then I would be very happy to hear about it.

Tim

---

From: Randy Bush <[email-masked]>
Date: Wed, 13 May 2020 07:36:01 -0700

> In my opinion there should be a MUST include one and only one
> CRL. Then offending MFTs can be considered broken, and there is no
> defensive code needed.

you are talking to someone who thought that rsync MTI spec was
sufficient

my mother would recommend a bit of focus on defensive, not offensive,
programing.  do not naïvely trust the input.  assume that some QA geek
is gonna throw a fuzz test at you.

randy

---

From: Stephen Kent <[email-masked]>
Date: Wed, 13 May 2020 12:11:56 -0400

Guys,
>> RPKI CA generates more than??? one, I tend to favor a simple

I think we all agree that the revised Section 6 text needs to 
accommodate the possibility that a manifest will list more than one CRL, 
even though this OUGHT NOT happen (see RFC 6919). The only question?? is 
how hard do we require an RP to work if it encounters more than one CRL. 
I prefer a simple approach to selecting one, and a mandatory warning. 
Rob has offered a more sophisticated, and complex approach, based on his 
working RP code.

I await a consensus from the WG.

Steve

---

From: Martin Hoffmann <[email-masked]>
Date: Wed, 13 May 2020 18:21:13 +0200

Stephen Kent wrote:
> accommodate the possibility that a manifest will list more than one
> CRL, even though this OUGHT NOT happen (see RFC 6919). The only
> question?? is how hard do we require an RP to work if it encounters
> more than one CRL. I prefer a simple approach to selecting one, and a
> mandatory warning. Rob has offered a more sophisticated, and complex
> approach, based on his working RP code.

I would prefer a simple solution. Either that multiple CRLs make the
manifest invalid or as long as a CRL is listed on a manifest and the
manifest hash as well as its signatures and times check out, it can be
referenced and used. The latter is what Routinator does now.

Kind regards,
Martin

---

From: Di Ma <[email-masked]>
Date: Thu, 14 May 2020 00:32:20 +0800

I am in favor of Steve’s preference on behalf of RPSITR 2 implementation.

If we don’t place strict constraint on the RPKI provisioning side, we will see more inconsistence among RPs.

Di

> 2020年5月14日 00:11，Stephen Kent <stkent=[email-masked]> 写道：
> 
> Guys,
> I think we all agree that the revised Section 6 text needs to accommodate the possibility that a manifest will list more than one CRL, even though this OUGHT NOT happen (see RFC 6919). The only question?? is how hard do we require an RP to work if it encounters more than one CRL. I prefer a simple approach to selecting one, and a mandatory warning. Rob has offered a more sophisticated, and complex approach, based on his working RP code.
>

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 14 May 2020 09:35:49 +0200

Hi,

> On 13 May 2020, at 18:11, Stephen Kent <stkent=[email-masked]> wrote:
> 
> Guys,

What may not have been clear from my earlier message is that I agree that in today's world it's worth supporting the possibility of more than one .crl like Rob A. has done.

That said, we are looking to improve things here, and reducing corner cases is good.

This is about the number of current .crl files on a manifest, not about files that may still linger in the repository under the directory - e.g. for other keys. Even if it is not explicit, RFC 6480 certainly points at having one CRL per keypair. And 6 out of 6 independent CA implementations have done exactly that. Therefore I think it would be perfectly safe to add a requirement in the MFT RFC update that there MUST be one CRL only. This will simplify things greatly for RPs.

If not, then indeed we need to have a discussion about how to deal properly with multiple CRLS. E.g. do you check *all* of them for each issued certificate, or do you only check the CRL matching the CRLDP of that certificate? I would also be very curious to know which use case warrants having this complexity.

Tim

---

From: Stephen Kent <[email-masked]>
Date: Thu, 14 May 2020 14:13:48 -0400

Tim,
> This is about the number of current .crl files on a manifest, not about files that may still linger in the repository under the directory - e.g. for other keys.
I agree that the focus of this discussion is files listed on a specific 
manifest. If a CA has a different key, and thus a different cert, the 
CRL issued under that key will be on a different manifest, and thus is 
not part of the concern here.
> Even if it is not explicit, RFC 6480 certainly points at having one CRL per keypair. And 6 out of 6 independent CA implementations have done exactly that. Therefore I think it would be perfectly safe to add a requirement in the MFT RFC update that there MUST be one CRL only. This will simplify things greatly for RPs.
One CRL per manifest is my goal as well.
> If not, then indeed we need to have a discussion about how to deal properly with multiple CRLS. E.g. do you check *all* of them for each issued certificate, or do you only check the CRL matching th…

My suggestion is the KISS approach - first .crl file that has a valid 
hash is the one to use, and others are ignored. That's less forgiving 
than what Rob accommodates, but being forgiving here might take pressure 
of a CA to do its job properly.

Steve

---

From: Martin Hoffmann <[email-masked]>
Date: Fri, 15 May 2020 09:08:40 +0200

Stephen Kent wrote:
> Tim,
>
> > If not, then indeed we need to have a discussion about how to deal
> > properly with multiple CRLS. E.g. do you check *all* of them for
> > each issued certificate, or do you only check the CRL matching the
> > CRLDP of that certificate? I would also be very curious to know
> > which use case warrants having this complexity.  
> 
> than what Rob accommodates, but being forgiving here might take
> pressure of a CA to do its job properly.

I’m not sure it really does. Rather, it will lead to strange looking
issues: If the wrong CRL accidentally made it onto the manifest and it
comes first, all objects are invalid even though everything sort of
looks fine. This may even come and go if a CA reorders the CRLs when
it reissues the manifest[0]. If all CRLs are referenced by objects, some
objects suddenly are invalid while others aren’t.

I think invalidating the manifest with a clear warning is the more
straightforward approach and much easier to debug.

Kind regards,
Martin

[0] That may happen if it is file system based and just adds files as
    they appear when reading the directory without sorting the file
    names first.

---

From: Oleg Muravskiy <[email-masked]>
Date: Fri, 15 May 2020 11:18:05 +0200

> straightforward approach and much easier to debug.

I tend to agree with this approach. It will keep RFC and validator’s code simple and force CAs to fix their bugs.

Oleg

---

From: Mikhail Puzanov <[email-masked]>
Date: Fri, 15 May 2020 11:38:41 +0200

Agree.

RIPE NCC’s validator 2 implemented somewhat complicated logic for 
picking up “the latest valid manifest with the latest valid CRL”
and in the validator 3 it had been changed to a much simpler version
“pick up the latest manifest, validate it, and makes sure it has 
a hash pointing to a valid CRL”.

In the last 2 years of running both versions we have not seen any 
discrepancies in the results reported by them that would be attributed 
to this specific change of the algorithm. So for all (99.9% of?) 
practical purposes, nailing it down to “manifest MUST include exactly 
one hash pointing to a CRL” would be preferable. Let alone it would 
allow for simpler and more efficient RP code.

--
Mikhail Puzanov,
Senior Software Engineer,
RIPE NCC

> On 15 May 2020, at 11:18, Oleg Muravskiy <[email-masked]> wrote:
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 19 May 2020 19:42:56 -0400

Martin,
>      they appear when reading the directory without sorting the file

I'm not sure what to make of your message.

I don 't see a specific proposal here.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 19 May 2020 19:42:56 -0400

Martin,

Steve

---

From: Martin Hoffmann <[email-masked]>
Date: Wed, 20 May 2020 10:15:41 +0200

Stephen Kent wrote:
> >> My suggestion is the KISS approach - first .crl file that has a
> >> valid hash is the one to use, and others are ignored. That's less
> >> forgiving than what Rob accommodates, but being forgiving here
> >> might take pressure of a CA to do its job properly.  
> > issues: If the wrong CRL accidentally made it onto the manifest and
> > it comes first, all objects are invalid even though everything sort
> > of looks fine. This may even come and go if a CA reorders the CRLs
> > when it reissues the manifest[0]. If all CRLs are referenced by
> > objects, some objects suddenly are invalid while others aren’t.
> >
> > [0] That may happen if it is file system based and just adds files
> > as they appear when reading the directory without sorting the file
> >      names first.  
> 

My apologies if this was cryptic. I just wanted to caution against
devising complicated heuristics to try and salvage a manifest with
multiple CRLs.

As I elsewhere already voiced my preference for your proposal to simply
invalidate the manifest if there are multuple CRLs, you can safely
ignore the message, though ...

Kind regards,
Martin