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

Russ, all,

> On 11 May 2021, at 16:20, Russ Housley <housley@vigilsec.com> wrote:
> 
> 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?

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

> 
> Russ
> 
> 
>> On May 10, 2021, at 8:50 PM, George Michaelson <ggm@algebras.org> wrote:
>> 
>> 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
>> 
>> 
>> On Tue, May 11, 2021 at 10:03 AM Randy Bush <randy@psg.com> wrote:
>>> 
>>>> 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
>>> 
>>> 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
>>> 
>>> ---
>>> randy@psg.com
>>> `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com`
>>> signatures are back, thanks to dmarc header butchery
>> 
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidrops
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops