Subject: Re: [Sidrops] [WG ADOPTION] draft-va-sidrops-deploy-reconsidered-01 - ENDS 08/11/2019 (Aug 11)

From: Nick Hilliard <[email-masked]>
Date: Fri, 13 Sep 2019 17:19:29 +0100

Chris Morrow wrote on 21/07/2019 22:19:
> SIDROps folks!
> 
> Please consider this an adoption call for the subject draft, abstract
> of which is:
> 
>    "This document defines a deployment model for reconsidered validation
>     [RFC8360] in the Resource Public Key Infrastructure (RPKI).
> 
>     It stipulates that Relying Parties in the RPKI MUST support
>     reconsidered validation by 1 July TBD-Year, and that Certificate
>     Authorities MAY use the reconsidered validation OIDs in CA
>     certificates that they issue from this date.  Furthermore Certificate
>     Authorities should monitor whether the set of resources in CA
>     certificate they receive has shrunk, and make adjustments in the CA
>     certificates and/or other RPKI objects when appropriate."
> 
> Please have a read, discuss, and comment over the next ~3 weeks period.
> Thanks for your prompt attention to this matter.

belatedly, this seems like a good idea.  My crypto ca/chain-of-trust fu 
is not up to seeing anything obviously wrong with the idea.

Nick

---

From: Stephen Kent <[email-masked]>
Date: Fri, 13 Sep 2019 19:50:19 -0400

CAs are "Certification Authorities", not "Certificate Authorities", if 
anyone cares.

>> ???? "This document defines a deployment model for reconsidered validation
>> ?????? [RFC8360] in the Resource Public Key Infrastructure (RPKI).
>>
>> ?????? It stipulates that Relying Parties in the RPKI MUST support
>> ?????? reconsidered validation by 1 July TBD-Year, and that Certificate
>> ?????? Authorities MAY use the reconsidered validation OIDs in CA
>> ?????? certificates that they issue from this date.?? Furthermore 
>> Certificate
>> ?????? Authorities should monitor whether the set of resources in CA
>> ?????? certificate they receive has shrunk, and make adjustments in the CA
>> ?????? certificates and/or other RPKI objects when appropriate."
>>
> belatedly, this seems like a good idea.?? My crypto ca/chain-of-trust 
> fu is not up to seeing anything obviously wrong with the idea.
>
> Nick
>
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops
>

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 14 Sep 2019 23:37:00 +0300

> CAs are "Certification Authorities", not "Certificate Authorities", if 

it's a bit tragic how few people really understand how the PKI hangs 
together and the subtleties associated with it :-(

Nick

---

From: Tim Bruijnzeels <[email-masked]>
Date: Sun, 15 Sep 2019 05:40:54 -0700

Hi

> On 14 Sep 2019, at 13:37, Nick Hilliard <[email-masked]> wrote:
> 
>> CAs are "Certification Authorities", not "Certificate Authorities", if anyone cares.
> 
> it's a bit tragic how few people really understand how the PKI hangs together and the subtleties associated with it :-(

I guess it's a bit like insisting that the whole world should call the metal aluminum, rather than aluminium.. or the other way around for that matter.

See here:
https://en.wikipedia.org/wiki/Certificate_authority <https://en.wikipedia.org/wiki/Certificate_authority>

But anyhow, if it's changed to say Certification Authorities, can we then have a constructive exchange about adoption? I think the real tragedy here is not the use of the term "Certificate Authority"

Tim

---

From: Stephen Kent <[email-masked]>
Date: Sun, 15 Sep 2019 11:20:48 -0400

Tim,

Wikipedia is not what I would call authoritative :-).

Look at the relevant IETF RFCs (e.g., 5280), and? X.509. They are 
authoritative.

I agree that major reasons for accepting or rejecting adoption of this 
document are not about whether the document authors use the correct 
terminology. However, if authors don't use the proper terms when 
describing PKI technology, it may cause readers to question the 
knowledge of the authors. You should want to avoid that possible outcome.

Steve

---

From: Randy Bush <[email-masked]>
Date: Sun, 15 Sep 2019 10:41:32 -0700

> I think the real tragedy here is not the use of the term "Certificate
> Authority"

i strongly agree.  imiho, this whole validation reconsidered path is of
no brnefit and, through complexity, offers opportunity for harm.  this
document tries to sugar coat a vile pill.

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Sun, 15 Sep 2019 13:46:13 -0700

Hi Randy, all,

> On 15 Sep 2019, at 10:41, Randy Bush <[email-masked]> wrote:
> 
> no brnefit and, through complexity, offers opportunity for harm.

While I do not agree with this, I respect that you bring this up. In fact I think that establishing that there is no consensus for having a discussion about the deployment of RFC8630 is much more constructive to the adoption question.

> this document tries to sugar coat a vile pill.

What this document tries to do, is to make it clear how, by example, RFC8630 could be deployed into the existing RPKI infrastructure, and what the consequences would be, so that we can have a constructive debate about how and why this would offer benefits and/or risks.

That being said, if there can be no consensus that we can even have that discussion because the goal of deploying RFC8630 in itself is rejected, then I don't see much point in spending more energy on this.

Tim

---

From: Tim Bruijnzeels <[email-masked]>
Date: Sun, 15 Sep 2019 13:54:01 -0700

> On 15 Sep 2019, at 13:46, Tim Bruijnzeels <[email-masked]> wrote:
> RFC8630

Oops, this should, of course, be RFC8360 (Resource Public Key Infrastructure (RPKI) Validation Reconsidered) not RFC8630 (Resource Public Key Infrastructure (RPKI) Trust Anchor Locator).

Tim