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

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Jun 2021 09:49:36 -0400

Tim,

Sorry to be replying belatedly- I was away when your message arrived and 
I lost track of it when I merged messages received during my trip with 
my inbox at home.

So, I think we're in agreement to synch the lifetime of the EE cert use 
for the manifest with the NextUpdate time for the manifest. I don;t 
recall the discussions you cited, but it's long ago so ...

To answer your question, I plan to change the text to say that a CA 
SHOULD revoke an expired, superseded manifest,until thecert for that 
manifest expires.

I know what changes trigger generation of a new manifest; the question 
is how often is this triggered only by a CRL being republished, with no 
changes. It wuld be useful if anyone closely monitoring the RKI could 
provide info on this topic.

It's good that you use the same NextUpdate time for manifests and CRLs. 
Since every new CRL (even if unchanged) requires a new manifest this is 
very appropriate. I also appreciate the desire to issue new versions of 
these data items prior to the expiration  of the prior version, to 
minimize the likelihood that an RP might reject the contents of a pub 
point because of unfortunate timing.

You asked if replacing a .cer of .roa file, with the same name but a new 
hash, requires revoking the [cert] for the replaced objects. The generic 
PKI answer is yes. I'd rather not complicate life for RPs by having 
multiple, valid, not revoked certs and/or ROAs in the system simultaneously.

Steve

p.s. I am still waiting to hear from more CAs about whether they always 
employ singe-use EE certs for manifests. If this is what everyone does, 
then I will change the text to mandate this behavior, to reduce the 
complexity of the document.

---

From: Randy Bush <[email-masked]>
Date: Mon, 28 Jun 2021 14:29:30 -0700

> So, I think we're in agreement to synch the lifetime of the EE cert
> use for the manifest with the NextUpdate time for the manifest. I
> don;t recall the discussions you cited, but it's long ago so ...

sra raised this a few years back, showing actual failures do to the
lack of congruence.  we can dig it up if it would help.

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 29 Jun 2021 11:25:56 +0200

Hi,

> On 28 Jun 2021, at 23:29, Randy Bush <[email-masked]> wrote:
> 

First off.. again, I am perfectly fine with syncing the nextUpdate to the single use manifest EE not after.
I think that the insight today is that this this preferable and it's what the RFC says.

I have done some digging on this.. provided purely so people understand the background of how current behaviour of CAs came to be.

I believe there was earlier discussion even, but the best lead I found is in a follow-up presentation I did at IETF 87 to change this to allow a *longer* validity time for the EE certificates. Back then the thinking was that CAs should have room to specify a soft limit (next update) and hard limit (EE not after) for manifest validity. There seemed to be agreement in the room back then (see minutes):

https://www.ietf.org/proceedings/87/slides/slides-87-sidr-2.pdf
https://www.ietf.org/proceedings/87/minutes/minutes-87-sidr

But.. the proposed work on drafts / updates never materialized.

Still, as a result of this the behaviour of the RIPE NCC CA (where I worked at the time) was changed to use 7 days for not-after, and 24 hours for the next update time. Krill does the same today.

All that said, I think today's insight is that even stale manifests should be rejected (not accepted with warnings), so it makes sense to align the times.

Tim