Subject: [Sidrops] draft-ietf-sidrops-rpki-has-no-identity-00

From: Randy Bush <[email-masked]>
Date: Mon, 10 May 2021 16:14:42 -0700

hi folk,

what do i need to work on here before whining about wglc?  some solid
constructive wg reviewers would be great.

[ sad to say, two other (not sidrops) drafts did not get real review
  until ietf last call. ]

randy

---
[email-masked]
`gpg --locate-external-keys --auto-key-locate wkd [email-masked]`
signatures are back, thanks to dmarc header butchery

---

From: George Michaelson <[email-masked]>
Date: Tue, 11 May 2021 09:19:33 +1000

I'd like the draft to at least address the idea you could cross sign.
Not that the RPKI cert can formally validate the identity, but there
is no implicit barrier to using it to countersign, or cosign a
structure, saying something like this:

If another mechanism can provide positive proof (eg an x509 identity
certificate which lies under a non-RPKI TA you trust) then there is no
barrier to countersigning an assertion over that proof (the public key
and a nonce, for example) binding the INR you can validate inside the
RPKI, and an identity which lies outside the RPKI.

and

No part of the RPKi validation can "prove" the identity in the
signing. What it can do, is relate the INR in RPKI, to a specific
assertion about identity. Validation of that assertion is not subject
to RPKI validation. Validation of the INR which is being associated,
is a function of the RPKI

-G

On Tue, May 11, 2021 at 9:15 AM Randy Bush <[email-masked]> wrote:
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Randy Bush <[email-masked]>
Date: Mon, 10 May 2021 17:03:37 -0700

> is a function of the RPKI

are you trying to say

  the owner of some j random inr is attesting to some identity binding
  in some k random pki?

maybe a concrete example would help me wrap what is left of my head
around this.

there exists an rpki cert attesting to a holding of 192.83.230.0/24.
iij has a corporate x.509-based employee database in which i have a
cert.  so the unknown owner of 192.83.230.0/24 cross-signs (let's
leave out the ugnlies) my iij cert.  what is the real world meaning of
this?  in few small words.

or, what is the meaning if i cross-sign the cert for 203.119.101.18
from iij?

what are the attestations and what is the trust?

randy

---
[email-masked]

---

From: George Michaelson <[email-masked]>
Date: Tue, 11 May 2021 10:50:46 +1000

holder of RPKI cert over 192.83.230.0/24 creates a nonce, and
communicates it OOB to cert holder in "iij has a corporate x.509-based
employee database" using their public key: this is private, only can
be decoded by private keyholder.

the specific person, they sign "I saw nonce" with IIJ corp cert
private key. they hand it back to RPKI cert person.

holder of RPKI cert validates: yep: under the IIJ TA they signed over
the nonce I gave them. This private key, it is the one I passed the
nonce to, no matter how indirect that happened, it wound up being a
chain from the nonce to the Private Key. If you care, you need to
communicate the nonce over some secure channel, but its out of band.

You sent them a thing only the bPKI private key holder can decode,
they sent you back a reply only the bPKI private keyholder can encode.

you then sign over some other assertion, saying "I did a nonce check,
and this private key here, which IIJ says is employee X, they seem to
check out." with the INR you want to associate. Your RPKI sign, can
only validate you control the INR. if you use either RTA or RSC, you
co-validate the hash of >some other assertion< but only in X509
cryptographic sense: the hash is asserted to be valid, under the
constraint it was signed over by this specific RPKI INR. You cannot
validate the >applicability< of that hash, it lies outside the RPKI
validation model.

neither PKI has to breach its own validation policy. They only ever
apply to validate the property of "which INR is associated with the
specific assert being made here" for RPKI validation and "which
identity, outside of RPKI, is being asserted here" for bPKI
validation.

why did you trust the bPKI in the first place? You have a TA. Thats
what TA do: they tell you to trust things. This isn't an RPKI TA, its
a bPKI TA. I can imagine somebody is whispering PGP at this point.

-G

---

From: Russ Housley <[email-masked]>
Date: Tue, 11 May 2021 10:20:17 -0400

George:

I am confused.  The RPKI design purposely avoids binding IIJ's identity to the resources assigned to IIJ. What kind of assertions need two signatures, one that ca be validated with an RPKI certificate and the other can be validated with a certificate from an identity-confirming PKI?

Russ

> On May 10, 2021, at 8:50 PM, George Michaelson <[email-masked]> wrote:
>

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 11 May 2021 16:38:09 +0200

Russ, all,

> On 11 May 2021, at 16:20, Russ Housley <[email-masked]> wrote:
> 
> George:
> 

I believe that the main point here is that a parent RPKI CA does not attest to the identity of a child. It just associates INRs to $their public key.

However, with RSC/RTA the operator of that child CA could then sign an attestation containing anything else, including a public B-PKI key that they may wish to associate with their INRs in specific use cases.

At least that is how understood George's words. Please correct me if I misunderstood George :)

Tim

---

From: Russ Housley <[email-masked]>
Date: Tue, 11 May 2021 10:45:49 -0400

> At least that is how understood George's words. Please correct me if I misunderstood George :)

I think that RSC/RTA are saying that the holder of an INR has signed a statement.  The identity is not important in that context.  The fact that the are the holder of that INR is waht is important to validate the signed statement.

Russ

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 May 2021 07:46:47 -0700

this confuses me even further.  perhaps less words would help.

> they sent you back a reply only the bPKI private keyholder can encode.

near as i can tell, this was three paragraphs describing a classic nonce
exchange to demonstrate proof of possession of a private key (see, i can
use important words too:).  what am i missing?

> check out." with the INR you want to associate.

eh what?  "this private key here, which IIJ says is employee X?"  there
ain't no here here.  no one has that *private* key except the iij
employee.

> Your RPKI sign, can only validate you control the INR. if you use
> either RTA or RSC, you co-validate the hash of>some other assertion<
> but only in X509 cryptographic sense: the hash is asserted to be
> valid, under the constraint it was signed over by this specific RPKI
> INR. You cannot validate the>applicability< of that hash, it lies
> outside the RPKI validation model.

a lot of words to say the INR holder can use hacks to sign some hash?
a hash of what?

> neither PKI has to breach its own validation policy.

i suspect that A has to validate B certs up to B's TA which A got by
magic.  unless you want to add validation signaling; which i suggest
that you not do.  and how does A know that B has not taken some weird
validation altering drug?  but let's ignore that and assume we're in
drug free normal X.509 world; sorry i could not resist.

> They only ever apply to validate the property of "which INR is
> associated with the specific assert being made here" for RPKI
> validation and "which identity, outside of RPKI, is being asserted
> here" for bPKI validation.

dragging the bpki in confounds things even further.  do you really mean
the bpki used to assure the rpki left/right and up/down communication?

> a bPKI TA. I can imagine somebody is whispering PGP at this point.

i thought i knew what an x.509 TA was.  though this conversation could
start to alter that assurance.

>> what is the real world meaning of this?  in few small words.

what i was hoping for was something such as "this means randy from iij
must be the owner of 192.83.230.0/24 and can say authorative things
about it by showing you his iij identity badge."  or "the owner of
192.83.230.0/24 can speak for randy from iij."

but i do not see that you have made that leap; likely due to my being
too easily confused.

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 11 May 2021 16:52:41 +0200

Russ:

> On 11 May 2021, at 16:45, Russ Housley <[email-masked]> wrote:
> 
> Tim:
> 

Indeed, I think we are saying the same thing.

What I am saying, and understanding George to say, is that data part in the signed statement can _contain_ identity information. Such as a B-PKI public key, or public PGP key, to be used in out of band communications about the resources.

But again George, if I misunderstood you correct me..

Tim

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 May 2021 07:55:23 -0700

aside: "BPKI" has meaning in the RPKI internal protocols.  i have come
to strongly suspect you are accidentally reusing this keyword for other
meanings.

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 11 May 2021 17:03:33 +0200

> On 11 May 2021, at 16:55, Randy Bush <[email-masked]> wrote:
> 

I agree.

BPKI is used in the context of provisioning (6492), publication (8181) and the out-of-band identity exchanges (8183).

We may not want to use the term in this context, or if we do then with proper clarity. This is not about the above RPKI internals.

Tim

---

From: Job Snijders <[email-masked]>
Date: Tue, 11 May 2021 18:18:44 +0200

Dear Randy & Russ,

> constructive wg reviewers would be great.

The current -00 title might distract from the substance of the memo.

Perhaps: "Clarification on Opaqueness of Resource Public Key Infrastructure (RPKI) Identifiers"

Most of the document's content don't appear accessible to newcomers to
the RPKI, it reads as if a lot of prior knowledge is required. The
'Discussion' section is somewhat hard to follow. For example, perhaps
'large operations' might be better as 'large corporations' or
'organizations'? 

The RFC 6480 and RFC 7382 references are useful, but overshadowed by a
(to me) somewhat confusing story about sushi and taco.

The 'Security' section appears to contain some useful clarifications.

> If so, how does one determine if the signature on the real world
> document is still valid?

Would the EE certificates contained in the signed objects not
be periodically validated, including the applicable CRLs?

I would suggest to keep the document in the queue, and enrich it based
on some field experience with RSC. it shouldn't be too long before the
first tests can be conducted with RSC objects.

Kind regards,

Job

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 May 2021 11:54:35 -0700

hi job,

thanks for reading

> Infrastructure (RPKI) Identifiers"

in my dotage, i try to impress with words less and less

> the RPKI, it reads as if a lot of prior knowledge is required.

it's why we have references.  but indeed, we have woven a tangled web,
as we saw in the secdir review of draft-ietf-opsawg-finding-geofeeds.
sympathies to the reviewer.  but i doubt we can fix it here.

> The 'Discussion' section is somewhat hard to follow. For example,
> perhaps 'large operations' might be better as 'large corporations' or
> 'organizations'?

you really think this make it easier to understand?  but sure,
organizations it now is.

> (to me) somewhat confusing story about sushi and taco.

you are not expected to remember bill's bait and sushi.  i assume you
would prefer examples use more erudite names.  sigh.

fyi, bb&s is an iconic internet org similar to foo widget company.  in
this case, bill was bill manning, a friend to many who died recently;
hence the bit of memoriam.  and roberto's taco stand is just up the
road.  i strongly recommend the carne asada burrito.

> be periodically validated, including the applicable CRLs?

you are referring to

   Then there is the temporal issue.  The owner of that AS may be BB&S
   today when some document was signed, and could be the Government of
   Elbonia tomorrow.  Or the resource could have been administratively
   moved from one CA to another, likely requiring a change of keys.  If
   so, how does one determine if the signature on the real world
   document is still valid?

are you suggesting automated periodic validation off a cron job or
whatever?

> first tests can be conducted with RSC objects.

clue or example on how this will help make this document better?

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 May 2021 14:43:15 -0700

> However, with RSC/RTA the operator of that child CA could then sign an
> attestation containing anything else, including a public B-PKI key
> that they may wish to associate with their INRs in specific use cases.

is your intent to authorize the non-rpki identity to act in all matters
for the INR?  i.e. how would one constrain the use cases?  e.g. may the
non-rpki identity write to the RPKI parent, e.g. ripe, and order the
transfer of the INR?  and don't tell me about administrative procedures;
this is a PKI discussion.

so the real-world identity system would sign the rpki INR which then
signs the LOA?  but why is the rpki INR even needed if the real world
identity can simply sign the LOA?

i thought that, way back when, ggm was trying to do the inverse.  using
the rpki private key to authorize some action in the real world.  the
example i remember was a letter of authorization to run a circuit, aka
an LOA for a PNI.

and what also confuses me; well i guess many things about this do; is
that i am not seeing/understanding where CA cross-certification, in the
normal up-the-tree sense, fits.  but i am not an expert on this.

and can we try to reduce use of long complex erudite seeming text
designed to impress rather than explain?

randy

---

From: George Michaelson <[email-masked]>
Date: Wed, 12 May 2021 09:45:19 +1000

You can't provide identity inside RPKI. It's forbidden in the profile.

You can use RTA and RSC to sign over things, which could be assertions
about identity. RPKI can't "prove" the assertion. But it can associate
INR with the assertion.

If you do an identity check out of band, with a public-private keypair
(for example doing a nonce check) you can use RTA or RSC to sign over
things which include the public key you just "checked" in some
unstated, undefined, OOB manner. This binds the INR to the validation
of that keypair.

If you want to define the context of use of the INR and the identity
in the RTA and RSC, how you do that is out of scope for RPKI.

All your questions about risk and consequence are valid. They're out
of scope for RPKI.

I think repeatedly saying "you can't provide identity in RPKI" is a
bit pointless. Sure: we all know that. You can "bridge" from RPKI to
identity, if you use some mechanism to say that, and RSC or RTA can
help you do that, without breaching the RPKI profile which forbids
directly certifying identity.

You asked "how" and I tried to say how. I did it badly. well, that
doesn't help me sell the idea, I get that, but I still think this
document is a bit pointless. Nobody is trying to say you can certify
identity directly, inside RPKI. What I wanted the document to say,
which would make it more useful (I think) is that you CAN associate
identity and RPKI, if you do it through a mechanism like RTA or RSC.

What I say about identity, can be said about Geolocation, or any other
quality you want to associate with INR.  If it is not permitted inside
RPKI, then assert a declaration outside of RPKI, but sign over it
using RTA or RSC.

Yes, bPKI was a stupid thing to use, to say "some PKI which isn't RPKI"

-G

---

From: Russ Housley <[email-masked]>
Date: Wed, 12 May 2021 11:07:26 -0400

George:

I do not understand the value of the "nonce check".  CMS allows multiple parallel signatures.  See RFC 4853 for some clarifications, and see RFC 5752 when there are concerns about stripping one of the signatures.

Russ

> On May 11, 2021, at 7:45 PM, George Michaelson <[email-masked]> wrote:
>

---

From: Randy Bush <[email-masked]>
Date: Wed, 12 May 2021 12:06:52 -0700

> I do not understand the value of the "nonce check".  CMS allows
> multiple parallel signatures.  See RFC 4853 for some clarifications,
> and see RFC 5752 when there are concerns about stripping one of the
> signatures.

i am lost a few meters higher up; which is what i suspect you may be
hinting.  at the start of this tangled thread, ggm asked us to include
an example of useful "bridging" (ggm's term) MTA/RSC signing.

if i had a cms blob signed by an INR CA and by X-CA or whatever, what
can i do with it?  and i most definitely do not mean the mechanics of
signing, proofs of possession, etc.

i do not see how it has more authority to issue an LOA for a PNI than
would be granted by simply using X-CA.

perhaps if X-CA has been used to contract with the issuing RPKI CA, it
could authorize modification of RPKI holdings; but no more so than just
that X-CA.

i suppose that if both signed a blob which somehow encoded that the RPKI
INR signer was authorized to represent the X-CA signer in some
restricted (i hope) class of transactions, the RPKI INR signer could
then issue the LOA for the PNI.  this seems a tenuous and therefore
dangerous chain (the blob's restrictions must be tested to include the
authorization for the LOA[0]), with zero advantage over X-CA just
signing the LOA.

i keep looping, with the X-CA being the inescapable base real world
authority.

i think i'll go shopping. :)

randy

[0] - and who is going down the capybara hole of writing the rfc
      describing the syntax and semantics of these authorizations and
      restrictions?

---
[email-masked]

---

From: George Michaelson <[email-masked]>
Date: Thu, 13 May 2021 09:45:27 +1000

> signing, proofs of possession, etc.

Sorry I ratholed. It was stupid.

> would be granted by simply using X-CA.

The LOA, I never quite got why anyone is waving a PDF with a company
logo on it, to decide to do something. An RPKI signed LOA, means you
can show the IP addresses are legitimate. If its some kind of LOA-like
thing about an ASN, same-same: the RPKi can show you control the ASN.
But, what shows you're speaking for the logo on the corner of the LOA?

Thats how I came into "ok: something else has to certify that this
company letterhead really is provably about the company, and you have
authority to speak for the company" which is not about the INR, its
about the .. identity behind the LOA.

> authorization for the LOA[0]), with zero advantage over X-CA just

Yes. You have to validate in both domains. It's tedious, but
certification is like that. Trust nothing. No?

> i keep looping, with the X-CA being the inescapable base real world

Only of the identity assertion. It has no global validity, no testable
quality regarding disposition of the INR.

You really want the product of both. Thats the CMS, signed
independently by both, AS Russ Says, or some construct in the RTA/RSC
space which is 'nested'

>       describing the syntax and semantics of these authorizations and

Problem for another day. Never said it wasn't a problem, never said it
didn't need to be defined. Wanted to say, Can imagine future uses, and
used LOA to exemplify. the B2B cases, don't (yet) have an open-basis.
Its (specific)B to (customer)B and the context is private, and defined
.. elsewhere. The second identity is defined by the Business which
defines the transaction. in the case of AWS or kubectl, its JSON blob
bound and the identity part is being solved inside that REST protocol,
outside of RPKI with no reference. The signed object is that business
establishing you're entitled to say whats to happen to the INR, in
their preferred format.

Maybe I should have stuck to talking about B2B private, and ignored
the identity thing. You decided to stomp on Identity, believing
somebody was saying RPKI can "prove" it but that was never my intent:
RPKI can be *bound* to identity, or anything else, by CMS or other
mechanisms tying both into a common statement. You can bind an LOA
identity if you can prove it in some other PKI, to the specific INR,
by both PKI being used to sign something.

If you want identity or anything else *proven*, you have to use
another domain of validation.  Proof isn't the binding, its the
validation behind what has been said in the binding.

RPKI can't validate it. I never sought to say RPKI can prove identity: It can't.

-G

---

From: Randy Bush <[email-masked]>
Date: Wed, 12 May 2021 16:55:31 -0700

likely more later

> logo on it, to decide to do something.

because that is how business is done.  and the signature on that piece
of paper is kinda important.  but they don't wave it; they fax it.  yes,
in 2021 they fax it.  some hipsters use docusign.

< rathole >

as i just said in chat to an apple support tech while waiting for
their manager to do something

    hardware has advanced far faster than software.  and a snail has
    advanced faster than human computer use.  here we are in chat, which
    i used in the late '70s on the arpanet.  and next it will be a phone
    call.

randy