Subject: [Sidrops] WGLC - draft-ietf-sidrops-rpki-has-no-identity - ENDS 12/16/2021 (Dec 16 2021)

From: Chris Morrow <[email-masked]>
Date: Thu, 02 Dec 2021 18:20:09 +0000

Howdy WG Folks!

The Author(s) of:
  draft-ietf-sidrops-rpki-has-no-identity

have requested a WGLC be made for their draft:
  https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-has-no-identity-02

with abstract content:
  "There is a false notion that Internet Number Resources (INRs) in the
   RPKI can be associated with the real world identity of the 'owner' of
   an INR.  This document attempts to put that notion to rest."

Please take some time to read the ~3 pages of content at:
  https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-has-no-identity-02

and provide you considered opinion on whether or not this document is prepared
for evaluation by the great and powerful OZ (IESG). Deadline for reply is
softly set at 12/16/2021 - Dec 16, 2021.

Thanks!
-chris
co-chair-persona

---

From: Geoff Huston <[email-masked]>
Date: Thu, 2 Dec 2021 20:04:39 +0000

I think the assertion in this draft is incorrect, or at least semantically imprecise.

What an RPKI certificate is attesting is that as far as the certificate issuer is concerned the holder of the private key whose public key is given in this certificate is the unique holder (or ‘owner’) of the resources listed in the certificate. 

Moreover, the same subject name will NOT be used by a CA to associate the resource holdings or two or more different and distinct entities.

And it's clear that anyone can use other data sources (such as registry queries) to associate a certificate subject name with a registry-listed entity's identity, and this draft is NOT saying that such a practice is foolhardy or wrong in any way.

regards,

   Geoff

> On 3 Dec 2021, at 5:20 am, Chris Morrow <[email-masked]> wrote:
> 
> 
> Howdy WG Folks!
> 
> The Author(s) of:
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Russ Housley <[email-masked]>
Date: Thu, 2 Dec 2021 15:43:57 -0500

Geoff:

I do not think you mean that it is appropriate for the private key associated with an RPKI certificate to sign a legal document or an email message.  What semantic imprecision needs to be resolved in your mind?

Russ

> On Dec 2, 2021, at 3:04 PM, Geoff Huston <[email-masked]> wrote:
>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 2 Dec 2021 16:48:06 -0500

Geoff,

In the security arena, objects that attest to identity are viewed as 
different from those that attest to authorization, and I think that is 
the message this document is trying to convey.

In the historical context, an RPKI cert would be viewed as a 
"capability" conferring authorization to the holder of the private key 
associated with the public key in the cert, irrespective of the identity 
of that private key holder. In the RPKI, an RP makes decisions about the 
validity of assertions about INR holdings based on this characteristic 
of the RPKI cert.

This is in stark contrast to the Web PKI, where CAs assert that the name 
embedded in a cert is the identity of the private key holder. RPs in 
that context make value judgements about "trusting" a specified web 
site, based in large part on the asserted identity.

because of this very significant difference, I think it';s appropriate 
to document the difference for users of the RPKI, who will, in general, 
be tempted to think about certs in the context of the Web PKI, with 
which they are more familiar.

Steve

---

From: Geoff Huston <[email-masked]>
Date: Thu, 2 Dec 2021 22:09:06 +0000

Hi Steve and WG folk,

If I may, please excuse my interleaved comments in response.

> On 3 Dec 2021, at 8:48 am, Stephen Kent <stephen.kent=[email-masked]> wrote:
> 
> Geoff,
> 
> In the security arena, objects that attest to identity are viewed as different from those that attest to authorization, and I think that is the message this document is trying to convey.

I have absolutely no problems with this characterisation of the different attestations between an authority and an attestation of corroboration of identification of identity. But in such a case it would be helpful if the words in the draft actually said precisely that.

> In the historical context, an RPKI cert would be viewed as a "capability" conferring authorization to the holder of the private key associated with the public key in the cert, irrespective of the identity of that private key holder. In the RPKI, an RP makes decisions about the validity of assertions about INR holdings based on this characteristic of the RPKI cert.
> 
> This is in stark contrast to the Web PKI, where CAs assert that the name embedded in a cert is the identity of the private key holder.

Opinions differ as to the precise intent of a domain name certificate, but that is perhaps a horse (?) of a different colour in the context of this discussion.

> RPs in that context make value judgements about "trusting" a specified web site, based in large part on the asserted identity.
> 
> because of this very significant difference, I think it';s appropriate to document the difference for users of the RPKI, who will, in general, be tempted to think about certs in the context of the Web PKI, with which they are more familiar.

I don't think we differ here Steve, aside from my discomfort about the draft leaving a bunch of things that are unsaid, and my previously tated desire to see a document be way more explicit and well defined.

regards,

 Geoff

---

From: Job Snijders <[email-masked]>
Date: Thu, 2 Dec 2021 23:33:55 +0100

Does the document in its current form succinctly edifice the general public
about the contrast between RPKI and WebPKI applicability, aptly denoted by
Stephen Kent?

To me the current draft appears somewhat comprehensible for “RPKI insiders”
(if one squints their eyes to ignore the somewhat testy title, abstract,
and introduction paragraphs), but is perhaps less informative to the wider
IETF community.

I believe there are real world business processes in which the ability to
produce a valid RSC Signed Object will suffice for the RP to proceed
certain process steps. Processes in which *who* issued the object doesn’t
matter - just like with ROAs, or BGPsec certs. Producing RSC objects is not
like signing via DocuSign, we know.

The current RSC draft links “no-identity” as WIP informative reference
(because it is!), I’m happy to keep doing so - but I can also see how the
“no-real-world-identity” draft would benefit from significant
restructuring. I’m not volunteering. :-)

Kind regards,

Job

---

From: Geoff Huston <[email-masked]>
Date: Fri, 3 Dec 2021 00:48:46 +0000

Hi Russ,

My point was that the text is handwaving and imprecise.

Even your text that says that I don't intend to say that "it is appropriate for the private key associated with an RPKI certificate to sign a legal document or an email message” seems to me to be lacking in precision. Yes I can use te same private key for a whole bunch of different uses, but I think what you mean is that the PKI that is being used to validate a particular use of the key provides a context of valid use. It's not the key per se you are referring to, but the terms and conditions where a CA was willing to issue a certificate for this key that defines its scope of use. If I used the same private key to generate a CSR from my government for some identity certificate as I had used to certify some resources under the RPKI. It's not the key value itself that is the constraint here, but the context of certification by third parties as to the universe of applicability of verification of products signed with that key that implicitly (or explicitly) reference that PKI. Now you might live and breath this space to the extent that you are able equate a term like “private key” with the PKI used to validate it, but I for one appreciate the use of a few more words to define these terms and their intended meaning with a little more detail.

regards,

Geoff

> On 3 Dec 2021, at 7:43 am, Russ Housley <[email-masked]> wrote:
> 
> Geoff:
>

---

From: Randy Bush <[email-masked]>
Date: Fri, 03 Dec 2021 08:44:41 -0800

> My point was that the text is handwaving and imprecise.

as our nlnet friends demonstrated, any text can be misconstrued.  so i
no longer put a lot of effort into preventing misconstruction.

but i was hoping you, having so aggressively argued for the rpki not
providing identity (and we did not disagree), might have some simple
text to propose.

randy

---

From: Stephen Kent <[email-masked]>
Date: Fri, 3 Dec 2021 14:09:06 -0500

Geoff,
> ...
CABF requirements make it very clear that accurate identification of the 
Subject Name, or Subject Alt Name in a cert is the primary focus of Web 
PKI certs.
> I don't think we differ here Steve, aside from my discomfort about the draft leaving a bunch of things that are unsaid, and my previously tated desire to see a document be way more explicit and wel…

I am not an author of the ID in question, and I am not interested in 
editing that document; I just wanted to note that identification is NOT 
a "feature" of the RPKI, which is consistent with the name of the ID.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 3 Dec 2021 14:13:18 -0500

Geoff,
> Even your text that says that I don't intend to say that "it is appropriate for the private key associated with an RPKI certificate to sign a legal document or an email message” seems to me to be lacking in precision. Yes I can use te same private key for a whole bunch of different uses,

Using the same private key in conjunction for different purposes, e.g., 
with different certs is a bad idea, just like reusing a password for 
different accounts. It also might violate the CPs under which the certs 
were issued.

> but I think what you mean is that the PKI that is being used to validate a particular use of the key provides a context of valid use. It's not the key per se you are referring to, but the terms and conditions where a CA was willing to issue a certificate for this key that defines its scope of use. If I used the same private key to generate a CSR from my government for some identity certificate as I had used to certify some resources under the RPKI.
as noted above, re-use of a key pair for different contexts would, in 
most cases, be a bad idea.

Steve

---

From: Geoff Huston <[email-masked]>
Date: Fri, 3 Dec 2021 19:13:23 +0000

> On 4 Dec 2021, at 3:44 am, Randy Bush <[email-masked]> wrote:
> 

ah yes, that’s part two of the process. First put up a hand to offer the opinion that it is not ready and why and then secondly suggest text to resolve the points. You have caught me between these two steps!

Geoff

---

From: Randy Bush <[email-masked]>
Date: Fri, 03 Dec 2021 11:20:24 -0800

> ah yes, that’s part two of the process. First put up a hand to offer
> the opinion that it is not ready and why and then secondly suggest
> text to resolve the points. You have caught me between these two
> steps!

:)

glad to work with you on text.  maybe out of band, as folk may not be
interested in our usual tussle about over terseness vs verbosity :)

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 03 Dec 2021 11:23:10 -0800

>> Even your text that says that I don't intend to say that "it is
>> appropriate for the private key associated with an RPKI certificate
>> to sign a legal document or an email message” seems to me to be
>> lacking in precision. Yes I can use te same private key for a whole
>> bunch of different uses,
> 
> Using the same private key in conjunction for different purposes,
> e.g., with different certs is a bad idea, just like reusing a password
> for different accounts. It also might violate the CPs under which the
> certs were issued.

giving geoff the benefit of doubt, i assume he will generate per-purpose
signing certs

randy

---

From: Geoff Huston <[email-masked]>
Date: Fri, 3 Dec 2021 20:04:41 +0000

> On 4 Dec 2021, at 6:23 am, Randy Bush <[email-masked]> wrote:
> 

Thanks for the benefit of the doubt Rand. Yes, my hypothetical self would do that. My point was that its the cert not the key that is the base reason for this, and I was simply observing that this lack of precision in the language was the cause of my moaning. I not claiming any better track record here (far, far from it!), but I was saying that in RFCs there is a good reason to be super-careful about precision and accuracy in the language used.

Geoff