Subject: Re: [Sidrops] 6486 bis

From: Job Snijders <[email-masked]>
Date: Wed, 1 Jul 2020 15:06:48 +0000

Dear all,

Its been a week since the interim and I think it is important to have a
draft uploaded into the IETF system so that the process towards
publication formally starts. There are RPKI implementers who tell me
that they are waiting for an RFC to be published before making changes
to their software. Not optimal.

Stephen Kent - if it is of any help to you, I'm happy to help navigate
the IETF datatracker and XML goo. I don't like XML either, but I do know
some of the magic incantations to make the computer happy. I think there
are other people on this email list that would be happy to help too.

I vaguely recall there being some text or xml being hosted at Randy's
git server, but I don't seem to be able to connect to that server, which
means for now I can't continue the implementation report because there
is no text to look at.

This process is blocked, please help.

Kind regards,

Job

On Thu, May 21, 2020 at 11:51:55AM -0400, Stephen Kent wrote:
> It seems the list prefers a KISS approach to the issue of multiple CRLs in a
> manifest. So, absent any additional suggestions, I'll plan to post a revised
> version of 6486 with the version 4 text that I posted to the list last week.
> 
> Thanks,
> 
> Steve
> 

> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 1 Jul 2020 11:26:27 -0400

> to their software. Not optimal.

apologies, I didn't note that there was some discussion off-list by
the author folk.. I believe they are aiming to send to the system end
of week or perhaps (because holiday) early next week.

if it's beyond next wed the author(s) should put out a 'expect text
DD/MM/YYYY' please.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 1 Jul 2020 13:49:12 -0400

Job,

Sorry for the delay. As Chris noted a few of us have been reviewing the 
changes before publishing.

I have a question for the CA operators on the list. The manifest RFC 
calls out the possibility of using "one-time-use" manifests, in a few 
places (not in Section 6, which I have been revising). Does anyone make 
use of that "feature?" If not, I suggest we delete the discussion of 
this feature as part of the document revision.

Steve

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 2 Jul 2020 12:27:14 +0200

Hi,

> On 1 Jul 2020, at 19:49, Stephen Kent <stkent=[email-masked]> wrote:
> 
> I have a question for the CA operators on the list. The manifest RFC calls out the possibility of using "one-time-use" manifests, in a few places (not in Section 6, which I have been revising). Does anyone make use of that "feature?" If not, I suggest we delete the discussion of this feature as part of the document revision.

Speaking for Krill - it *always* uses "one-time-use" EE certificates for Manifests, and for other RPKI signed objects for that matter.

Personally I would be happy with "one-time-use" being mandatory or RECOMMENDED.. I don't see any real advantage in multi-use. But, I understand this is another issue. It's not a big deal, although having one flavour only could potentially allow simplifying the text.

Tim

---

From: Nathalie Trenaman <[email-masked]>
Date: Fri, 3 Jul 2020 14:34:20 +0200

Hi Steve,

> Op 1 jul. 2020, om 19:49 heeft Stephen Kent <stkent=[email-masked]> het volgende geschreven:
> 
> Job,
> 
> Sorry for the delay. As Chris noted a few of us have been reviewing the changes before publishing.
> 

As RIPE NCC (CA operator), we do have “one-time-use” manifests, since 2011. 

Thanks,
Nathalie Trenaman
RIPE NCC

---

From: Stephen Kent <[email-masked]>
Date: Fri, 3 Jul 2020 08:37:23 -0400

Nathalie,

Thanks for the info. Maybe we ought to deprecate the multi-use 
manifests, to simplify matters, if other CA operators have adopted 
one-time-use as their model.

Steve

---

From: George Michaelson <[email-masked]>
Date: Mon, 6 Jul 2020 09:32:19 +1000

This is the model adopted by APNIC as well, since the inception of the service.

-G

---

From: ntrenaman <[email-masked]>
Date: Fri, 03 Jul 2020 11:08:45 +0200

Hi Steve,

On 2020-07-01 19:49, Stephen Kent wrote:
> places (not in Section 6, which I have been revising). Does anyone
> make use of that "feature?" If not, I suggest we delete the discussion
> of this feature as part of the document revision.

Yes, we at RIPE NCC have only one-time-use certificates for manifests 
(since 2011).

Thanks,
Nathalie Trenaman
Routing Security Programme Manager
RIPE NCC

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 6 Jul 2020 13:18:31 -0400

> This is the model adopted by APNIC as well, since the inception of the service.

clarifying question:
  "apnic's implementation only uses one-time.."

yes?

---

From: Randy Bush <[email-masked]>
Date: Mon, 06 Jul 2020 12:37:09 -0700

>   "apnic's implementation only uses one-time.."

i would be  surprised to learn of a CA which multi-used

but, if you want to learn about strange differences, much more
interesting to ask about validity periods of mft, crl, ...

randy

---

From: George Michaelson <[email-masked]>
Date: Tue, 7 Jul 2020 08:17:25 +1000

>   "apnic's implementation only uses one-time.."

Yes.