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

[George Michaelson <[e-mail]>]

On Thu, May 13, 2021 at 5:06 AM Randy Bush <[e-mail]> wrote:
> 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.

Sorry I ratholed. It was stupid.

>
> 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.

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.

>
> 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.

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
> authority.

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'

>
> 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?

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