Subject: [Sidrops] draft-ietf-sidrops-6486bis-04.txt

From: Stephen Kent <[email-masked]>
Date: Tue, 1 Jun 2021 09:36:15 -0400

I revised the text in Section 6 to reflect the suggestion Ties de Kock 
made in an off-list exchange in late December of last year. Although our 
esteemed chairs said that someone else would assume responsibility for 
this I-D early this year, that has not happened. Moreover, there has 
been no more on-list discussion of this topic, so I elected to complete 
the agreed-upon changes and publish an update before the old version 
expired.

Steve

---

From: Job Snijders <[email-masked]>
Date: Tue, 1 Jun 2021 17:25:19 +0200

Dear all,

On Tue, Jun 01, 2021 at 09:36:15AM -0400, Stephen Kent wrote:
> I revised the text in Section 6 to reflect the suggestion Ties de Kock made
> in an off-list exchange in late December of last year. Although our esteemed
> chairs said that someone else would assume responsibility for this I-D early
> this year, that has not happened. Moreover, there has been no more on-list
> discussion of this topic, so I elected to complete the agreed-upon changes
> and publish an update before the old version expired.

welcome back and thank you for your efforts!

I re-read the document and was wondering whether it is useful to retain
the section 5 text about 'one-time-use' vs 'sequential-use' EE
certificates. Perhaps the text describing the procedure would be become
simpler if this (for RP undetectable?) difference is not highlighted.

OLD: """
 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.
"""

NEW: """
 The validity times of the EE certificate MUST encompass the time
interval from thisUpdate to nextUpdate.
"""

-------------------------------------------------------------------

Section 5.2 - could perhaps benefit from some tighting up.

OLD: """
 A new manifest MUST be issued and published on or before the nextUpdate time.
"""

NEW: """
 A new manifest MUST be issued and published before the nextUpdate time.
"""

I'm suggesting this edit because we should encourage operators to make
before break and not do things 'at the last moment'.

-------------------------------------------------------------------

In section 5.2, """Repository operators SHOULD implement some form of"""
could be upgraded to a "MUST"? Repository Operators should be encouraged
to consciously avoid potential for race conditions or failed fetches.

-------------------------------------------------------------------

The paragraph describing "chicken and egg" (to me) seems confusing. I
don't see a 'circular dependency'.

The Manifest's EE certificate MUST contain the 'X509v3 CRL Distribution
Points' extension which tells us where the CRL is, and ADDITIONALLY (in
a later stage) the RP confirms whether the digest calculated over the
obtained CRL matches the hash listed in the Manifest eContent.

But whether the hashes match or not, or whether the eContent even lists
a FileAndHash entry for a .crl file at all... is a moot point if the EE
certificate has been revoked and its serial appears on a signed CRL...
right?

Kind regards,

Job

---

From: Stephen Kent <[email-masked]>
Date: Fri, 4 Jun 2021 15:01:37 -0400

Job,

> interval from thisUpdate to nextUpdate.

The term "one-time-use" EE certs is introduced in RFC 6487 (section 3) 
and that section includes a reference to 6486. Note that there are are 
several other references to one-time-use certs in manifests in Sections 
3 & 4, and the 4.2.1 mention cites the same requirement on the validity 
period. Also note that the validity interval requirements for these 
certs constitute directions to CAs. The text in 4.2.1 provides rationale 
for this requirement, i.e., to avoid needless growth of CRLs. Since the 
text you cited in 5.1 is providing direction to CAs, I don't see a need 
to change it based on any RP considerations; the text does not impose a 
requirement on RPs to verify this. If you feel that's not clear, I could 
add text to note that.

I agree that make before break is the right strategy, and I am happy to 
make this change. But, since the nextUpdate field expresses times down 
to the second, I doubt if the change is meaningful :-).

I'm happy to change the SHOULD to a MUST, if nobody objects.

When an RP fetches the contents of a pub point, it should find a 
manifest and a set of files, one of which is a CRL. The processing steps 
in section 6.1 describe the order of checks to be performed on the 
manifest, and on the files fetched from the pub point. It does not say 
when the CRL listed in the manifest is checked to verify that the EE 
cert for the manifest is not revoked. So, it seems possible that an RP 
might verify the signature on the manifest, using the embedded EE cert, 
fetch the listed files, check the hashes of the files, and then process 
the CRL that is listed in the manifest. If, at that point the CRL is 
found to be current and valid, but the manifest EE cert is listed as 
revoked, the CA has made a serious error. I just wanted to explicitly 
address this case.

Steve

---

From: Ties de Kock <[email-masked]>
Date: Mon, 7 Jun 2021 08:42:37 +0200

Hi Stephen,

> On 4 Jun 2021, at 21:01, Stephen Kent <stkent=[email-masked]> wrote:
> 
> Job,
> 
> The term "one-time-use" EE certs is introduced in RFC 6487 (section 3) and that section includes a reference to 6486. Note that there are are several other references to one-time-use certs in manifests in Sections 3 & 4, and the 4.2.1 mention cites the same requirement on the validity period. Also note that the validity interval requirements for these certs constitute directions to CAs. The text in 4.2.1 provides rationale for this requirement, i.e., to avoid needless growth of CRLs. Since the text you cited in 5.1 is providing direction to CAs, I don't see a need to change it based on any RP considerations; the text does not impose a requirement on RPs to verify this. If you feel that's not clear, I could add text to note that.

First a nit: The reference to a substitution attack in 4.2.1 no longer current.
I think that it would be good to capture the rationale (substitution attacks and
prevent diverging behaviour between implementations) for rejecting stale
manifests in the document - it would help a future reader who does not have the
context of the discussion around 6486bis.

While the requirement Job mentioned is undetectable (?) for RPs, I think some
guidance on what directions to CAs should be checked by RPs would be helpful,
since checking these requirements may lead to a situation where we do not reach
the end goal of all RPs with the same cache and RPKI repository data having the
same set of validated repository files.

Specifically (from 5.1.2):
...
      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 [RFC3779]).
...

The second requirement was part of the BBN conformance cases (792 
MFTIPv4NotInherit, 793 MFTIPv6NotInherit, 794 MFTASNotInherit).
I would expect all RPs to check the first requirement. I also know that most RP
implementations do not check the second one - leading to divergence if these
differences were present in real repositories.

Indicating what to do with these directions to CAs would prevent divergence. I
do not have a strong preference, but if forced to pick a side because we want
converged behaviour, I would err on the side of checking it over being tolerant
of sloppy CAs.

Kind regards,
Ties

> I agree that make before break is the right strategy, and I am happy to make this change. But, since the nextUpdate field expresses times down to the second, I doubt if the change is meaningful :-).
> 
> When an RP fetches the contents of a pub point, it should find a manifest and a set of files, one of which is a CRL. The processing steps in section 6.1 describe the order of checks to be performed on the manifest, and on the files fetched from the pub point. It does not say when the CRL listed in the manifest is checked to verify that the EE cert for the manifest is not revoked. So, it seems possible that an RP might verify the signature on the manifest, using the embedded EE cert, fetch the listed files, check the hashes of the files, and then process the CRL that is listed in the manifest. If, at that point the CRL is found to be current and valid, but the manifest EE cert is listed as revoked, the CA has made a serious error. I just wanted to explicitly address this case.
> 
> Steve
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Jun 2021 16:11:18 -0400

Ties,
> context of the discussion around 6486bis.

I have removed the forward pointer to 6.4 from the text in 4.2.1

The document already notes that manifests are intended to allow an RP to 
detect removal or substitution of stale version of objects (see the 
intro), so I don;t this needs to be repeated in 4.2.1.

> same set of validated repository files.
Good point. I have annotated the steps in 5.1 to note ones where an RP 
is required to check that the CA has produced the manifest as directed, 
and to note where this is not the case.

A new version will be posted soon.

Steve

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 11 Jun 2021 15:36:38 +0200

Dear Steve,

Thank you for taking this effort!

I have some comments / questions I would like to bring up.

- Section 2 Manifest Scope

This section may benefit from a reference to RFC 6481. In particular, it may not be clear to the reader now that there MUST be only one CRL issued under a CA (certificate). Perhaps replace:
 
   o  the most recent CRL issued by this CA, and

With:

   o  the single, most recent, CRL issued by this CA [RFC 6481], and

- Section 3 Manifest Signing

Job talked a bit about this as well. From my point of view, I believe that all CA implementations use single-use EE certificates for manifests. I don't see a use-case for multi-use in this context.

This is not a showstopper to me, but I think that we have an opportunity to say the single use EE certificates MUST be used, and if we have just one option then this will make the document easier to parse and reason about. E.g. section 4.2.1 can be simplified.

- Section 5 Manifest Generation

There is no text here that says that the single use EE certificate for the previous manifest (if single-use applies) should be revoked. Although later it is implied that a manifest can be revoked. Is this intentional?

Currently my CA implementation revokes old manifests. It is trying to be thorough.

That said, I think there is little point in doing this. The reason is that if an RP would find the new CRL, but still have the old manifest because of some timing issue - then it would find that the CRL hash does not match what is said on the manifest. It would be a failed fetch as described in section 6. Revoking the current manifest on its current CRL is possible, but somewhat hard to achieve with single-use EEs (assuming random serials are used) as well as obviously ill-advised.

One could therefore argue that rather than revoking previous manifest, the 'thisUpdate' or possibly 'manifestNumber' should be leading in selecting an eligible manifest - should an RP have multiple validly signed and current manifests for the same CA somehow. Not revoking previous manifests would help to avoid the "chicken and egg" issue raised in section 6. It is not clear to me that this would really be less safe.

But look, really, rather than trying to pick an argument over this, I raise this because I would like to see explicit text in the document that says what's expected here :)

- Section 6

I believe we have had discussions as a WG and concluded that any current RPKI object (such as ROAs) which are NOT on a manifest can be considered out-of-scope and de-facto invalid by RP software. Notable exception to this would be objects which are never intended to be published inside the regular RPKI such as RSC and RTA objects in future. 

If I misunderstood please let me know. But otherwise might I suggest updating the first sentence:

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

Suggest:

   Each RP MUST use the current manifest of a CA and add each listed
   file to the set of 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). Any files not listed on the manifest MUST NOT be
   used for validation, unless the profile of its RPKI object type
   explicitly states otherwise. ...

Tim

> On 1 Jun 2021, at 15:36, Stephen Kent <stkent=[email-masked]> wrote:
> 
> I revised the text in Section 6 to reflect the suggestion Ties de Kock made in an off-list exchange in late December of last year. Although our esteemed chairs said that someone else would assume responsibility for this I-D early this year, that has not happened. Moreover, there has been no more on-list discussion of this topic, so I elected to complete the agreed-upon changes and publish an update before the old version expired.
> 
> Steve
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Jun 2021 09:53:54 -0400

Tim,

>     o  the single, most recent, CRL issued by this CA [RFC 6481], and

done.

> This is not a showstopper to me, but I think that we have an opportunity to say the single use EE certificates MUST be used, and if we have just one option then this will make the document easier t…

I agree this change would make the doc simpler, but I need to hear from 
other CAs to confirm that NOBODY issues multi-use EE certs in manifest 
before making this change.

> There is no text here that says that the single use EE certificate for the previous manifest (if single-use applies) should be revoked. Although later it is implied that a manifest can be revoked.…

Recall that 4.2.1 calls for the manifest EE cert (if single use) to have 
a validity period that matches that of the manifest, to avoid the need 
to revoke that cert when a new manifest is issued. So, unless a new 
manifest is issued before the old one expires, it is intentional that 
the cert for the old manifest not be revoked.

> Currently my CA implementation revokes old manifests. It is trying to be thorough.

does it do this in all cases? since you indicate that you are employing 
single-use EE certs here, that behavior runs counter to 4.2.1, unless 
the new manifest is issued before the old one expires. Also, do you 
remove the revoked EE cert from the CRL as soon as it expires, which 
should usually be before the next manifest is issued.

> But look, really, rather than trying to pick an argument over this, I raise this because I would like to see explicit text in the document that says what's expected here :)

as I said, unless a CA issues a new manifest before the next scheduled 
issue time, this ought not be an issue.

> I believe we have had discussions as a WG and concluded that any current RPKI object (such as ROAs) which are NOT on a manifest can be considered out-of-scope and de-facto invalid by RP software. N…

The notion of manifest scope is defined in Section 2. It says that "... 
all published signed objects that are verifiable using EEcertificates 
[RFC6487] issued by this CA." are in scope. So, based on that text, it 
would seem that the RSC and RTA objects are in scope. Also, the RTA ID 
indicates that these objects may appear on a manifest, so I find the 
proposed, revised text confusing.

Steve

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 14 Jun 2021 17:06:10 +0200

Dear Steve, WG,

> On 14 Jun 2021, at 15:53, Stephen Kent <stkent=[email-masked]> wrote:
> 
> Tim,
> 
> I agree this change would make the doc simpler, but I need to hear from other CAs to confirm that NOBODY issues multi-use EE certs in manifest before making this change.
> 
> Recall that 4.2.1 calls for the manifest EE cert (if single use) to have a validity period that matches that of the manifest, to avoid the need to revoke that cert when a new manifest is issued. So, unless a new manifest is issued before the old one expires, it is intentional that the cert for the old manifest not be revoked.

> does it do this in all cases? since you indicate that you are employing single-use EE certs here, that behavior runs counter to 4.2.1, unless the new manifest is issued before the old one expires. Also, do you remove the revoked EE cert from the CRL as soon as it expires, which should usually be before the next manifest is issued.

Krill defaults to 24 hours for the next update time on CRLs and Manifests. The not-after time on the manifest EE currently still defaults to 7 days following discussions we had about this in sidr many years ago. I am quite happy to change this match the next update time instead as this document now instructs.

But in any case a new Manifest and CRL are issued by default 8 hours before they would go stale. I don't dare to leave this much longer, I think a CA operator needs this window to be able to deal with unforeseen outages.

When a manifest is replaced the previous EE cert is revoked - and its not-after (expire) time is remembered. When that time has passed the entry is removed.

All these values are configurable. I don't know for sure how other CA implementations do this. It would be good to hear from them. Based on memory at least the RIPE NCC managed CA uses a similar strategy.

> as I said, unless a CA issues a new manifest before the next scheduled issue time, this ought not be an issue.

As above, I don't dare to leave this to the last moment.

Furthermore, there could be other changes like a change in ROAs that require a new manifest to be issued.

Which reminds me.. I am not sure now if or where this is required, but in order to keep things simple to reason about I always issue a new manifest and CRL together.

It's not that the CRLs get huge, because revocations for expired EE certificates get removed as well. But, then again, I still think these manifest EE revocations are most likely not needed at all because with this -bis because RPs would only accept a new CRL with a changed hash, when they have already seen the replacement manifest.

> The notion of manifest scope is defined in Section 2. It says that " ... all published signed objects that are verifiable using EE certificates [RFC6487] issued by this CA." are in scope. So, based on that text, it would seem that the RSC and RTA objects are in scope. Also, the RTA ID indicates that these objects may appear on a manifest, so I find the proposed, revised text confusing. 

I am not vested in the text I proposed.

I believe that for normal top-down validation RPs need not consider any objects not found on manifests. This seems to align with what you are saying.

But what I am after is the following. RTA as proposed supports the idea of out-of-band exchanges of RTA objects, where those objects may NOT appear in RPKI. I believe RSC supports this option as well (but I need to re-read). So, in short, they may or may not appear on manifests. So, I would prefer that RPs can still do ad-hoc validation of RTA objects which they received out-of-band. Typically the RTA EE certificate would refer to a CRL and parent CA certificate which can be found in the RPKI (and manifests).

Open to other text and discussion.

Tim

---

From: Job Snijders <[email-masked]>
Date: Mon, 14 Jun 2021 17:17:30 +0200

On Mon, Jun 14, 2021 at 05:06:10PM +0200, Tim Bruijnzeels wrote:
> I believe that for normal top-down validation RPs need not consider
> any objects not found on manifests. This seems to align with what you
> are saying.
> 
> But what I am after is the following. RTA as proposed supports the
> idea of out-of-band exchanges of RTA objects, where those objects may
> NOT appear in RPKI. I believe RSC supports this option as well (but I
> need to re-read). So, in short, they may or may not appear on
> manifests. So, I would prefer that RPs can still do ad-hoc validation
> of RTA objects which they received out-of-band. Typically the RTA EE
> certificate would refer to a CRL and parent CA certificate which can
> be found in the RPKI (and manifests).
> 

RSC is always distributed 'out-of-band', thus they MUST NOT appear on a
Manifest, please see:
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rsc-04#section-2

As a consequence, RSC objects do not have a 'Subject Information Access'
extension. The RSC's AIA and CRLDP point to objects in the global RPKI.

A (currently valid under RIPE TA) example RSC file can be found here:
https://mailarchive.ietf.org/arch/msg/sidrops/TbCem3eu_PW8BRyBl48oqh1La74/

Kind regards,

Job

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Jun 2021 19:57:51 -0400

Tim,
> Krill defaults to 24 hours for the next update time on CRLs and 
> Manifests. The not-after time on the manifest EE currently still 
> defaults to 7 days following discussions we had about this in sidr 
> many years ago. I am quite happy to change this match the next update 
> time instead as this document now instructs. 

So, to be clear, a new CRL and manifest are issued every 24 hours, but 
the manifest EE cert has a 7-day lifespan, right? Since you say that the 
manifest EE cert is a one-time use, this clearly contradicts the text in 
the manifest spec. Please do change the validity interval.

> All these values are configurable. I don't know for sure how other CA implementations do this. It would be good to hear from them. Based on memory at least the RIPE NCC managed CA uses a similar st…

It would seem that each old manifest cert lives on a CRL for about 6 
days, so there might be 5 or 6 of them on the CRL at any time, 
needlessly. That's not awful, but it's not pretty either.

> Furthermore, there could be other changes like a change in ROAs that require a new manifest to be issued.

I am curious- do you track how often a new manifest needs to be issued 
because a ROA has changed? It would be useful to know if manifests are 
being reissued frequently only because a timer dictates it, not because 
any object covered by the manifest has actually changed.

> Which reminds me.. I am not sure now if or where this is required, but in order to keep things simple to reason about I always issue a new manifest and CRL together.

I don't think any text requires that a new CRL MUST be issued with every 
new manifest, although the opposite is obviously true if the old 
manifest EE cert is revoked. If a new manifest is issued 8 hours before 
the old one expires, and if there are no changes in the objects covered 
by the manifest, other than a new CRL, and if that CRL is also unchanged 
in terms of the revoked certs being listed, then there seems to be a lot 
of churn for no obvious reason.

> I believe that for normal top-down validation RPs need not consider any objects not found on manifests. This seems to align with what you are saying.
cert path validation is always top-down, as per 5280 and its predecessors.
> But what I am after is the following. RTA as proposed supports the idea of out-of-band exchanges of RTA objects, where those objects may NOT appear in RPKI. I believe RSC supports this option as we…

Well, we've been reminded by Job that RSC doesn't assume distribution 
via the RPKI, so ...

I propose the following text to begin Section 6:

Each RP MUST use the current manifest of a CA to control addition of listed

files to the set of signed objects the RP employs for validating basic RPKI

objects: certificates, ROAs, and CRLs. Any files not

listed on the manifest MUST NOT be used for validation of these objects.

However, files not listed on a manifest MAY be employed to validate other

signed objects, if the profile of the object type explicitly states that

such behavior is allowed. Note that relying on files not listed in a

manifest may allow an attacker to effect substitution attacks against such

objects.

Steve

---

From: Di Ma <[email-masked]>
Date: Tue, 15 Jun 2021 10:35:29 +0800

Steve,

>   manifest may allow an attacker to effect substitution attacks against such

Does your proposal mean we have to extend RFC 3779 or RFC 6487 to generally support an RPKI object noting itself required in MFT?

Or we just need to make RSC/RTA to offer such information?

I think the former will bring more tasks for IETF but may be a good way to enhance the security of the RPKI.

Di

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 15 Jun 2021 10:04:21 +0200

Steve,

Thank you for your response.

> On 15 Jun 2021, at 01:57, Stephen Kent <stkent=[email-masked]> wrote:
> 
> Tim,
> So, to be clear, a new CRL and manifest are issued every 24 hours, but the manifest EE cert has a 7-day lifespan, right? Since you say that the manifest EE cert is a one-time use, this clearly contradicts the text in the manifest spec. Please do change the validity interval.

More than happy to do so..

Fwiw this goes back to a discussion we had in sidr over 10 years ago. Of course now I can't find the slides or email threads anymore, but I remember presenting a question to the WG on this specific question - and the outcome back then in my understanding was that it would good, desired even, to have a slightly longer lifespan on the manifest EE certs - and that 'stale' manifests and CRLs could result in warnings as per local policy, while expired manifests would always be invalid. So, right or wrong (probably) - this behaviour was based on what I believed to be that outcome..

Anyway, I am more than happy to change this. I actually prefer to have the lifespan of the EE match the next update time and have eliminate the difference based on local policy of stale vs expired manifest that may still be present in older deployed RP software.

> It would seem that each old manifest cert lives on a CRL for about 6 days, so there might be 5 or 6 of them on the CRL at any time, needlessly. That's not awful, but it's not pretty either.

I agree that the amount is not too bad.

Still it is not clear to me whether I MUST, or MAY, or am RECOMMENDED to revoke replaced manifests.

Remember that you would only find the revocation if you had found a new manifest and accepted the new CRL revoking the now irrelevant previous. Given the choice I would rather *not* revoke them ever.

> I am curious- do you track how often a new manifest needs to be issued because a ROA has changed? It would be useful to know if manifests are being reissued frequently only because a timer dictates it, not because any object covered by the manifest has actually changed.

I do not track how users of our software do this. It does not call home :) But, this can be observed by anyone looking at the RPKI with sufficient granularity.

Generally speaking any change in ROAs or delegated certificates results in a changed manifest. I believe that most RPKI CAs try to publish such changes within seconds to minutes.

For our own prefixes this is very infrequent - we just have few prefixes out there which don't change, unless we are running experiments. For an RIR or NIR delegated certificates change multiple times per day. For big operators ROAs may change much more frequently than in our case.

> I don't think any text requires that a new CRL MUST be issued with every new manifest, although the opposite is obviously true if the old manifest EE cert is revoked. If a new manifest is issued 8 hours before the old one expires, and if there are no changes in the objects covered by the manifest, other than a new CRL, and if that CRL is also unchanged in terms of the revoked certs being listed, then there seems to be a lot of churn for no obvious reason.

One reason is that it's just easier to reason about the next update time for publishing both.

Another reason is that I am always issuing new manifests before they would expire, because I don't want a publication point to be rejected if I am a few minutes late because of some issue. And the old manifest is revoked, so that means the CRL changes.

Furthermore I use the same 'next update' time on CRLs and manifests. And I want to update the CRL before it would go stale for the same reason as updating manifests. Longer lived CRLs could only work if I used different times for both.

Note that if I do not need to revoke previous manifest this CRL is generally small, which reduces churn as well.

> Well, we've been reminded by Job that RSC doesn't assume distribution via the RPKI, so ...
> 

That works for me.

Similar question to revocation of replaced manifests..

If I replace a .cer or .roa file with another one that has the same name, and a new hash, do I still need to revoke the old file as well? Given that a hash mismatch would be seen as a 'failed fetch'.

Currently I do. I can keep doing it. But I observe that the CRL and manifest are signed under the same CA certificate so I am not convinced that doing both (replace hash and revoke old) adds security, while it does make the CRL longer if there is lots of churn in ROAs or delegated CA certificates.

So, given the choice I would rather revoke objects only when their name goes out of scope, or perhaps even never - as they "MUST NOT" be used for validation if they are not listed.

Note that I see full value in the CRL for validating out-of-band RSC/RTA objects, or any object type which may be out of scope for manifests by design.

So, I hope that it's clear why I keep going on about the CRLs in this context. I can keep revoking things like I do today, but I would appreciate a clarification why this is better, and I think it may be worthwhile documenting this explicitly.

Tim