Subject: [Sidrops] proposed, revised text for Section 6

From: Stephen Kent <[email-masked]>
Date: Mon, 4 May 2020 16:08:43 -0400

To get the discussion going, I generated the following text for Section 
6. I deleted anything that was not definitive (e.g., deferred to local 
policy) and removed the warning message suggested text (I assume RP 
software developers can write their own messages, but we can add this 
back if folks feel it's useful.

I also added a paragraph about the manifest/CRL circular relationship.

In all cases I adopted the approach George suggested, i.e., if there's 
an error indicating that one or more signed objects may be missing (or 
not current), ignore ALL data associated with the CA instance at the pub 
point and DO NOT rely on cached data.

Comments welcome, as usual.

All new text is in red.

Steve

-----

6.1. Determining Manifest State & Object Acceptance

For a given publication point, and given CA instance, an RP MUST perform

the following tests to determine the manifest state of the publication

point. (Note that, during CA key rollover [RFC6489], signed objects for

two or more different CA instances will appear at the same publication

point. The tests described below are to be performed for a specified CA

instance, i.e., a the manifest’s EE certificate was issued by that CA.)

1. Select the CA's current manifest (the "current" manifest is the

manifest issued by this CA having the highest manifestNumber among

all valid manifests (as defined in Section 4.4).

If the publication point does not contain a valid manifest, proceed

as described in Section 6.2. (Lacking a valid manifest, the following

tests cannot be performed.)

2. Check that the current time (translated to UTC) is between

thisUpdate and nextUpdate.

If the current time does not lie within this interval,proceed

as described in Section 6.4.

3. Acquire all objects at the publication point associated with this

CA instance, i.e., the CRL and each object containing an EE

certificate issued by the CA. If there are files listed in a manifest

that do not appear at the publication point, then proceed as

described Section 6.5.

4. Verify that the listed hash value of every file listed in the

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 proceed

as described in Section 6.6.

5. 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 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 Section 6.2.

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 manifest is revoked, the CA or publication point manager has

made an error. In this case all signed objects associated with the CA

instance MUST be ignored. Similarly, if the CRL for the CA instance

is not listed on a valid, current manifest, all signed objects

associated with the CA instance MUST be ignored, because the CRL is

missing.

6.2.Missing 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. To guard against the adverse impact of processing an

incomplete set of signed objects, an RP MUST treat all signed objects

associated with the missing manifest as invalid. (These objects are

all issued by the same instance of a CA.) RP software MUST issue a

warning when there is no current manifest for a CA instance.

An RP may have access to a local cache containing a previously

issued manifest that is still valid. It is RECOMMENDED that the RP

not make use of this data, to ensure consistent a consistent outcome

in when a manifest is missing.

6.3.Invalid 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.

If there is no valid, current manifest available at the publication

point for the CA instance, an RP MUST treat the signed objects at the

publication point as indicated above in Section 6.2. A warning MUST

be issued when an invalid manifest is encountered.

6.4.Stale Manifests

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, MUST be

treated at invalid and a warning MUST be issued.

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.

6.5.Mismatch between Manifest and Publication Point

If there exist valid signed objects associated with a CA instance and

they do not appear in any current, valid manifest for this CA instance,

these objects MUST be ignored by an RP, and a warning MUST be issued.

If there are files listed on the manifest that do not appear in

the repository, then these objects have been improperly deleted from

repository (via malice or accident).A primary purpose of manifests is

to detect such deletions.Therefore, in this case, an RP MUST ignore

all signed objects associated with this CA instance.

6.6.Hash Values Not Matching Manifests

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, e.g., one in which an older version of an object

has been substituted for a newer version of the object. In this case

an RP cannot know the content of the missing object, and thus all

signed objects associated with this instance of the CA MUST be ignored

by the RP, and a warning MUST be issued.

---

From: George Michaelson <[email-masked]>
Date: Tue, 5 May 2020 11:15:16 +1000

I just want to note that while I think you made a logically consistent
choice, I do not agree with its intent, in as much as I believe cached
state could be used to construct the valid state which the manifest
and CRL declare.

So, I think you drove to a harder place than I intended. But, I accept
this is a choice, and a strong choice.

I suspect I am in a minority of one on this. I would not seek to
impede a group decision driving to a more narrow constrained
definition.

-George

On Tue, May 5, 2020 at 6:09 AM Stephen Kent
<stkent=[email-masked]> wrote:
>
> To get the discussion going, I generated the following text for Section 6. I deleted anything that was not definitive (e.g., deferred to local policy) and removed the warning message suggested text (I assume RP software developers can write their own messages, but we can add this back if folks feel it's useful.
>
> In all cases I adopted the approach George suggested, i.e., if there's an error indicating that one or more signed objects may be missing (or not current), ignore ALL data associated with the CA instance at the pub point and DO NOT rely on cached data.
>
>       If the current time does not lie within this interval, proceed
>
>       MUST be disregarded in the context of this manifest.  If there
>
> 6.2.  Missing Manifests
> 6.3.  Invalid Manifests
>    accidental) corruption of a valid manifest.  An invalid manifest MUST
>
> 6.4.  Stale Manifests
>    nextUpdate time for the manifest.  This could be due to publisher
>
>    have been removed or replaced.  (For example, the new manifest might
>
>    revoked certificates).  Thus, the use of objects from a stale
>
>    valid.  The risk is that the CRL covered by the stale manifest has
>
> 6.5.  Mismatch between Manifest and Publication Point
>
>
>
>    repository (via malice or accident).  A primary purpose of manifests is
>
>    to detect such deletions.  Therefore, in this case, an RP MUST ignore
>
> 6.6.  Hash Values Not Matching Manifests
>
>
>
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 May 2020 21:33:06 -0700

> impede a group decision driving to a more narrow constrained

sra has bludgeoned me much closer to your position

randy

---

From: Job Snijders <[email-masked]>
Date: Tue, 5 May 2020 12:13:53 +0000

Dear group,

On Mon, May 04, 2020 at 04:08:43PM -0400, Stephen Kent wrote:
> To get the discussion going, I generated the following text for Section 6. I
> deleted anything that was not definitive (e.g., deferred to local policy)
> and removed the warning message suggested text (I assume RP software
> developers can write their own messages, but we can add this back if folks
> feel it's useful.
> 
> In all cases I adopted the approach George suggested, i.e., if there's an
> error indicating that one or more signed objects may be missing (or not
> current), ignore ALL data associated with the CA instance at the pub point
> and DO NOT rely on cached data.
> 

Small note: neither the archive
(https://mailarchive.ietf.org/arch/msg/sidrops/Qy7YAVOUYrDVZxUPFPNZfekoJKI/)
nor my mail client show any text in red. I am assuming the below quoted
text replaces all of section 6 in RFC 6486. I added section numbers to
the below quoted text and line-wrapped it. My comments are inline.

Stephen, question for you: is the use of the word 'files' and 'objects'
synonymous in the below text? Or are 'files' something different than
'objects'?

> For a given publication point, and given CA instance, an RP MUST
> perform the following tests to determine the manifest state of the
> publication point. (Note that, during CA key rollover [RFC6489],
> signed objects for two or more different CA instances will appear at
> the same publication point. The tests described below are to be
> performed for a specified CA instance, i.e., a the manifest’s EE
> certificate was issued by that CA.)
>
> 6.1.1. Select the CA's current manifest (the "current" manifest is the
> manifest issued by this CA having the highest manifestNumber among all
> valid manifests (as defined in Section 4.4). If the publication point
> does not contain a valid manifest, proceed as described in Section
> 6.2. (Lacking a valid manifest, the following tests cannot be
> performed.)
> 
> 6.1.2. Check that the current time (translated to UTC) is between
> thisUpdate and nextUpdate. If the current time does not lie within
> this interval, proceed as described in Section 6.4.
>
> 6.1.3. Acquire all objects at the publication point associated with
> this CA instance, i.e., the CRL and each object containing an EE
> that do not appear at the publication point, then proceed as described
> Section 6.5.
> 
> 6.1.4. Verify that the listed hash value of every file listed in 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
> proceed as described in Section 6.6.
> 
> 6.1.5. 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 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 Section 6.2.
> 
> instance MUST be ignored. Similarly, if the CRL for the CA instance is
> not listed on a valid, current manifest, all signed objects associated
> with the CA instance MUST be ignored, because the CRL is missing.
> 
> 6.2. Missing Manifests
> 
> An RP may have access to a local cache containing a previously issued
> manifest that is still valid. It is RECOMMENDED that the RP not make
> use of this data, to ensure consistent a consistent outcome in when a
> manifest is missing.
> 
> 6.3. Invalid Manifests
> 
> The presence of an invalid manifest at a publication point could occur
> 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.
> publication point as indicated above in Section 6.2. A warning MUST be
> issued when an invalid manifest is encountered.
> 
> 6.4. Stale Manifests
> 
> 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
> 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.
> 
> they do not appear in any current, valid manifest for this CA
> instance, these objects MUST be ignored by an RP, and a warning MUST
> be issued.

Are we sure about the above? The above approach would preclude us from
using the current valid manifest to determine which .roa files should be
deleted from the local system, right?

> If there are files listed on the manifest that do not appear in the
> repository, then these objects have been improperly deleted from

A more robust approach might be to *not* ignore locally cached data (iff
the locally cached data matches the filename and hash listed on the
valid manifest, and a valid CRL is present)

> by the RP, and a warning MUST be issued.

Same comment as in previous section: perhaps a more robust approach
might be to *not* ignore locally cached data (iff the locally cached
data matches the filename and hash listed on the valid manifest, and a
valid CRL is present).

Kind regards,

Job

---

From: Stephen Kent <[email-masked]>
Date: Tue, 5 May 2020 15:52:44 -0400

George,
> impede a group decision driving to a more narrow constrained

I believe Job made a good argument supporting your observation, and we 
can revise the text to take advantage of the cached state. I will note, 
in passing, that this can introduce variances in local processing based 
on local cache loss and/or differences in cache refresh timing by 
different RPs. But, if everyone is comfortable accepting the potential 
variance, I'm happy to proceed.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 5 May 2020 16:09:12 -0400

Job,
> the below quoted text and line-wrapped it. My comments are inline.
whoops. sorry about that. it was red when I sent it :-).
> synonymous in the below text? Or are 'files' something different than
every object is represented by a file in the repository, so  the terms 
are equivalent in most cases on this document.
>> with the CA instance MUST be ignored, because the CRL is missing.
The original text didn't mark each step in the process as a sub-sub 
section, but your marking is a good strategy.
> deleted from the local system, right?
I'm not an implementer, but can't one delete cached roa files based on 
them not appearing in the current, valid manifest?
> valid manifest, and a valid CRL is present)
Are you saying "IFF ALL of the missing files are present in the local 
cache, are not expired, and there is a valid CRL at the publication 
point, and it matches the file name and hash in the manifest, then we're 
OK to use the cached objects to fill in the missing files from the pub 
point? I think that's a reasonable exception. if others agree, I'll 
modify the text accordingly.
> data matches the filename and hash listed on the valid manifest, and a

I think I agree with your analysis here too.

One final note, as I mentioned in my reply to George- the goal of 
consistent RP processing of RPKI data is more dependent on RPs having 
consistent caches on which to rely in the context of 6.5 and 6.6 processing.

Steve

---

From: "Job Snijders" <[email-masked]>
Date: Tue, 05 May 2020 23:58:21 +0200

Dear Group,,

> variance, I'm happy to proceed.

About the next period of time: yes, Stephen, please proceed to write down your thoughts. I would like to read your messages (through this mailinglist). I can't compensate you for your efforts with a monetary currency, but I can commit my attention to what you write.

For what it is worth - as member (and dependent) of the community around OpenBSD rpki-client, I observe people are holding the various pieces of the puzzle up against the light in various direction and positions, trying to see how how to align (if possible) the implementation of our RPKI cache software with the spirit of George's observation. Test balloons in the form of POSIX.1 patch(1) files are shared within that community. And it appears it'll be a multi-week effort to resolve the puzzle in a way that all people involved would want to run in production on their EBGP routers.

As SIDROPS are not in an easy working space: the timezones differences are really hard, emails might not arrive, reliable distribution of audio from interim meetings seems challenging, and we all speak an approximation of a common language. Receiving messages in simple English helps improve my participation in this process.

Stephen, my request to you: share directly with the working group what you perceive as the space and "variances", and make strong strong suggestions about the specific single path/vector you perceive as most optimal through the space, and I look forward to comparing notes and observations.

Kind regards,

Job

---

From: Randy Bush <[email-masked]>
Date: Tue, 05 May 2020 14:59:48 -0700

> I will note, in passing, that this can introduce variances in local
> processing based on local cache loss and/or differences in cache
> refresh timing by different RPs. But, if everyone is comfortable
> accepting the potential variance, I'm happy to proceed.

if i insteaad not process current fetch, than we will also have
inconsistent views, yes?

and of course, as fetch times may vary, inconsistency will be normal

the question is how much and what kinds of inconsistency the attacker
can cause

randy

---

From: Stephen Kent <[email-masked]>
Date: Tue, 5 May 2020 21:34:39 -0400

Randy,
> the question is how much and what kinds of inconsistency the attacker

These are all valid questions. The WG needs to decide if per-RP 
variance, based on fetch timing, local cache failure, etc. meets the 
goal of uniform RP processing of RPKI data. I am agnostic on this point.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 5 May 2020 21:34:39 -0400

Randy,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 May 2020 08:04:03 -0400

Job,
> About the next period of time: yes, Stephen, please proceed to write down your thoughts. I would like to read your messages (through this mailinglist). I can't compensate you for your efforts with…
thanks for your review.
> As SIDROPS are not in an easy working space: the timezones differences are really hard, emails might not arrive, reliable distribution of audio from interim meetings seems challenging, and we all s…
I'll try to be clear in my writing.
> Stephen, my request to you: share directly with the working group what you perceive as the space and "variances", and make strong strong suggestions about the specific single path/vector you percei…

will do.

Steve

---

From: Oleg Muravskiy <[email-masked]>
Date: Wed, 6 May 2020 14:35:20 +0200

Hi Steve,

I have some comments inline:

> On 4 May 2020, at 22:08, Stephen Kent <stkent=[email-masked]> wrote:
> 

Without additional context (the discussion we've had here on the list), it would not be clear for the reader where the possible multiple candidates for the “current”  manifest come from. The CA certificate contains a link (rsync URL) to a manifest, which is only one file, so how could there be multiple options to “select” from? I guess you refer to a possible use of a cache, or a difference between contents of rsync and RRDP repositories?

>      that do not  appear at the publication point, then proceed as

Wouldn’t we miss all the subordinate Resource Certificates if we only look at objects containing an EE certificate?
I think it would be enough if we say

	Acquire from this publication point all files listed in a manifest and verify that they are issued by this CA instance.

Although it would be better to expand the “verify” part.

Also, we should probably mention explicitly what the “publication point” is (see my later remark about possible discrepancy between different URLs from the CA cert).

>    in when a manifest is missing. 

The end of last sentence should have some duplicate words removed.

>    they do not appear in any current, valid manifest for this CA instance,

This should probably be the “the current, valid manifest”, not “any” (as we only consider one manifest as the current in 6.1/1)?

>    by the RP, and a warning MUST be issued.

I wonder how far we should get with listing all possible inconsistencies in this document, but from my developer’s perspective I think  we should list as much as possible, if we want RP software to behave in the same way.

Going through what we described in RFC8488, one of such inconsistencies is when manifest contains more than one CRL entry.

Another is when the manifest is not in the publication point of a CA certificate. There are two distinct links from the CA certificate – one to the publication point, and one to the manifest. Technically, the manifest link could contain different directory than a publication point link. If you discover a manifest by following the manifest link, and follow the rules applied above, using the link from the CA cert (and not the location of the manifest), you would not catch this discrepancy.
Also note  that similar discrepancy could exist with the CRL location (as it also has its own link from the cert), but that one is covered by the new text above.

Cheers,
Oleg

---

From: Jay Borkenhagen <[email-masked]>
Date: Wed, 6 May 2020 15:46:35 -0400

> goal of uniform RP processing of RPKI data. I am agnostic on this point.

Recently I had attempted to gauge if there was WG consensus along
these lines:

   Each validation run of each RP MUST generate the same set of
   Validated ROA Payloads (VRPs) when presented with identical input,
   using unexpired records from the most recent successful retrieval
   to deal only with complete failure to retrieve from a PP.

Now I have come around to agree with Job's perspective that coarse
behavior like 'rsync --delete' is not what RPs should do.

An RP should not assume that objects missing in any PP retrieval are
the fault of the responsible CA.  The objects could be missing due to
fault of the CA, problems reaching the PP, or other potential causes,
and the RP cannot know which one it was.  If the RP's cached objects
can fill in the gaps, that's great.

Thus I now feel the straw proposal I offered above is too restrictive.
I would still want different RP implementations to be 'deterministic'
such that they produce the same VRPs, but only when operating on an
identical local cache (including an empty cache as one important case).

Thanks.

						Jay B.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 May 2020 16:09:34 -0400

Oleg,
> I have some comments inline:
I'm happy to see that your message shows the red highlighting I used.
>
>> On 4 May 2020, at 22:08, Stephen Kent 
>> <stkent=[email-masked] 
>> <mailto:stkent=[email-masked]>> wrote:
>>
>> For a given publication point, and given CA instance,an RP MUST perform
>> point.(Note that, during CA key rollover [RFC6489], signed objects for
>> 1.Selectthe CA's current manifest (the "current" manifest is the
>> manifest issued by this CAhaving the highest manifestNumber among
> Without additional context (the discussion we've had here on the 
> list), it would not be clear for the reader where the possible 
> multiple candidates for the “current”  manifest come from. The CA 
> certificate contains a link (rsync URL) to a manifest, which is only 
> one file, so how could there be multiple options to “select” from? I 
> guess you refer to a possible use of a cache, or a difference between 
> contents of rsync and RRDP repositories?

I will revise the text to say that the processing starts with the 
manifest URL extracted from a CA cert, which should simplify matters. I 
was not trying to refer to a local cache or RRDP in the text above.

>
>> If the publication point does not contain a valid manifest,proceed
>> 3.Acquire all objects at the publication point associated with this
>> that do notappear at the publication point, then proceed as
>> describedSection 6.5.
>
> Wouldn’t we miss all the subordinate Resource Certificates if we only 
> look at objects containing an EE certificate?
> Acquire from this publication point all files listed in a manifest and 
> verify that they are issued by this CA instance.
Good point. I will reword the description of this processing step.
> Although it would be better to expand the “verify” part.
I will do so.
>
> Also, we should probably mention explicitly what the “publication 
> point” is (see my later remark about possible discrepancy between 
> different URLs from the CA cert).
  I did not mean to refer the the local cache above. I would like to 
describe this process in terms of the repository system model, as 
described in 6480, ignoring use of RRDP vs. rsync.
>> objects.To guard against the adverse impact of processing an
yep.
>> If there exist valid signed objectsassociated with a CA instanceand
> This should probably be the “the current, valid manifest”, not “any” 
> (as we only consider one manifest as the current in 6.1/1)?
agreed. a will change to "the current, valid manifest"
>> attack has occurred,e.g., one in which an older version of an object
> I wonder how far we should get with listing all possible 
> inconsistencies in this document, but from my developer’s perspective 
> I think  we should list as much as possible, if we want RP software to 
> behave in the same way.
agreed.  I will try to address the inconsistencies you noted; feel free 
to suggest others.
>
> Going through what we described in RFC8488, one of such 
> inconsistencies is when manifest contains more than one CRL entry.
RFC 8488 talks only about the requirement to omit the optional CRL filed 
in the generic CMS format we adopted. It does not address the issue you 
mention here, i.e., what if the manifest includes more than one CRL. 
But, I agree that there does not appear to be an explicit prohibition of 
having more than one CRL enumerated in a manifest. We should say this 
explicitly. Next question: what do we do if we encounter more than one?
> Another is when the manifest is not in the publication point of a CA 
> certificate. There are two distinct links from the CA certificate – 
> one to the publication point, and one to the manifest.
yes, and 6487 does not say that the manifest must be in the directory 
specified by the pub point URI (id-ad-caRepository) Maybe we should 
revise 6487 to make that a requirement. I can address that here as well.
> Technically, the manifest link could contain different directory than 
> a publication point link. If you discover a manifest by following the 
> manifest link, and follow the rules applied above, using the link from 
> the CA cert (and not the location of the manifest), you would not 
> catch this discrepancy.
> Also note  that similar discrepancy could exist with the CRL location 
> (as it also has its own link from the cert), but that one is covered 
> by the new text above.

yes, 6487 does not require the CRLDP to point to a file in the pub point 
specified by the id-ad-caRepository URL in the CA cert. Again, how about 
a revision to 6487 to clarify this? It would make life simpler.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 May 2020 16:09:34 -0400

Oleg,

I will do so.
yep.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 May 2020 16:10:42 -0400

jay,
> can fill in the gaps, that's great.
I am revising the text to mandate use of an RP's cache to fill in for 
missing or damaged files.
> identical local cache (including an empty cache as one important case).

OK.

Steve

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 May 2020 18:16:37 -0700

in

   https://mailarchive.ietf.org/arch/msg/sidrops/tVb6sAm9g2KLOC2msTgxb-WW4zI/

i think sra told you how to get what you want

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 7 May 2020 11:00:38 +0200

Hi Steve,

> On 6 May 2020, at 22:09, Stephen Kent <stkent=[email-masked]> wrote:
> 
> agreed.  I will try to address the inconsistencies you noted; feel free to suggest others.
>> 
> RFC 8488 talks only about the requirement to omit the optional CRL filed in the generic CMS format we adopted. It does not address the issue you mention here, i.e., what if the manifest includes more than one CRL. But, I agree that there does not appear to be an explicit prohibition of having more than one CRL enumerated in a manifest. We should say this explicitly. Next question: what do we do if we encounter more than one?
>> Another is when the manifest is not in the publication point of a CA certificate. There are two distinct links from the CA certificate – one to the publication point, and one to the manifest. 
> yes, and 6487 does not say that the manifest must be in the directory specified by the pub point URI (id-ad-caRepository) Maybe we should revise 6487 to make that a requirement. I can address that here as well.
>> Technically, the manifest link could contain different directory than a publication point link. If you discover a manifest by following the manifest link, and follow the rules applied above, using the link from the CA cert (and not the location of the manifest), you would not catch this discrepancy.
> yes, 6487 does not require the CRLDP to point to a file in the pub point specified by the id-ad-caRepository URL in the CA cert. Again, how about a revision to 6487 to clarify this? It would make life simpler.
> 

I agree.

I think all CA implementations already do the following, which is implied by RFC 6487 and 6481 in particular. But the text is not sufficiently explicit. Updates will help, especially RP software.

* There is only ever one (1!) *current* CA certificate issued for a given key (implied by RFC6492)
* This CA certificate has the following SIA entries:
    - id-ad-caRepository pointing to its full publication point
    - id-ad-rpkiManifest pointing to a manifest in that publication point
    - (still optionally) id-ad-rpkiNotify pointing to the RRDP (RFC 8182) notification file

* For a CA certificate (i.e. a single key) there will be ONE current MFT only
* For a CA certificate (i.e. a single key) there will be ONE current CRL only
* That CRL name and hash MUST match the one and only .crl file on the MFT
* Any issued (EE or CA) certificate under this CA certificate (single key) MUST use a CRLDP that matches the name of this .crl file, under the issuing CA certificate's id-ad-caRepository

Did I miss anything still?

Tim

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 7 May 2020 12:40:04 +0200

Hi Steve, all,

> On 5 May 2020, at 22:09, Stephen Kent <stkent=[email-masked]> wrote:
> 
> I'm not an implementer, but can't one delete cached roa files based on them not appearing in the current, valid manifest?

We may be intending the same thing here. Generally speaking I am in favour of not deleting any objects because of rsync --delete, or updates / withdraws in RRDP only. So add things only, and delete them when you have seen a signed statement that the objects are no longer relevant.

The repository server is essentially untrusted by the RP, or should be! Definitely when using rsync, but RRDP with self-signed HTTPS is also highly questionable. Changing RRDP to say that TLS Verification MUST be done can help a bit, but even then there are issues with web TAs, and it could be that the repository server itself is compromised.

But details around this can be complicated. I don't think that we can specify one way to do deal with this that will be acceptable to all RP implementation. There is more than one way to do it, and therefore it may be better to specify the boundaries of what an RP MAY or MAY NOT do regarding caching.

I think the following consideration should be kept in mind:

1) stale/expired mft

Do NOT just delete things because the CA did not issue / you did not see a new current MFT. Only delete if you see a new current MFT that confirms that something is no longer relevant.

2) poisoning

Be careful if you rely on the SHA256 hashes only. I could include your object on my MFT and then remove it in an update. This should not remove your object from the cache.

3) key rolls

New keys may publish updated delegated .cer files under the same name. Be careful when just relying on the URIs.

4) require confirmation: rsync delete / RRDP update/withdraw?

If delegated .cer files are removed, should their content also be removed? Maybe. But what if this is a temporary issue at the parent? The child would not typically re-publish things. You will not see a new delta.

There is something to be said for deleting objects only if they are removed at the repository *AND* they are actively removed by a new manifest.

I have some ideas about how I would make this work if I were to implement something, but I do not presume that that would be the only or best way.

Note that different implementations regarding this will lead to differences in the availability of cached objects. But they would not lead to different validation outcomes based on the same set of objects.

Tim

---

From: Stephen Kent <[email-masked]>
Date: Thu, 7 May 2020 11:38:21 -0400

Tim,

> ...

This all sounds appropriate to me. I can state these assumptions in the 
intro for Section 6.

What do we want to do if we encounter two or more .crl files in a 
manifest? use the first one, ignore any others, and issue a warning?

What do we want to do if the CRLDP in a CA cert does not match the file 
name in the manifest? Issue a warning and use the .crl file from the 
manifest?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 7 May 2020 11:38:21 -0400

Tim,

Steve

---

From: Job Snijders <[email-masked]>
Date: Thu, 7 May 2020 15:45:52 +0000

> manifest?  use the first one, ignore any others, and issue a warning?

Which one is the first one? The fileList is an (unordered) sequence of
FileAndHash objects, right?

Shouldn't standard X509 be followed here? Only use the CRL that the .cer
points to? I was under the impression that the CRL exists as part of the
X509 validation, rather than as part of the 'RPKI validation overlay'?

> What do we want to do if the CRLDP in a CA cert does not match the
> file name in the manifest? Issue a warning and use the .crl file from
> the manifest?

The latter option seems counter-intuitive to me.

Kind regards,

Job

---

From: Stephen Kent <[email-masked]>
Date: Thu, 7 May 2020 13:30:31 -0400

Job,
> FileAndHash objects, right?

The ASN.1 for fileList is a SEQUENCE. In ASN.1 terms, this means it is 
ordered. A SET is used to represent an unordered collection of data 
items. So there is no ambiguity about ordering of files here.

> X509 validation, rather than as part of the 'RPKI validation overlay'?

This document focuses on how to use a manifest to decide which files at 
a pub point are to be processed, which is why I thought about the issue 
of multiple CRLs from that perspective. But, I agree that we ought to 
rely first on the CRL identified by the the CRLDP in the CA cert, and 
then confirm that the manifest includes that file. If we adopt that 
approach, the ordering or .crl files in a manifestwill not be relevant.

Steve

---

From: Oleg Muravskiy <[email-masked]>
Date: Thu, 7 May 2020 19:52:36 +0200

Steve,

> On 7 May 2020, at 17:38, Stephen Kent <[email-masked]> wrote:
> 
> Tim,
> 
>> ...
>> I agree.
>> 
> This all sounds appropriate to me. I can state these assumptions in the intro for Section 6.

I like this as well.

> What do we want to do if we encounter two or more .crl files in a manifest? use the first one, ignore any others, and issue a warning?
> 
> What do we want to do if the CRLDP in a CA cert does not match the file name in the manifest? Issue a warning and use the .crl file from the manifest?

I would suggest that we only use a CRL that is on a manifest AND matches the CRLDP in a CA cert (and all the above conditions that Tim mentioned are also true). If there are also other CRLs in the manifest, we ignore them with a warning.  

If there are CRLs in the manifest, but none matches the CRLDP, we continue as if there is no valid CRL (so follow rules of section 6.1 of your revised text).

Oleg