Subject: Re: [Last-Call] [lamps] Fwd: Last Call: <draft-ietf-sidrops-rpki-has-no-identity-04.txt> (The I in RPKI does not stand for Identity) to Proposed Standard

From: Michael Richardson <[email-masked]>
Date: Sat, 05 Mar 2022 13:45:04 -0500

I have read the document.
I was unaware of it until it was posted.

It seems like this document is fighting some kind of guerilla fight against
pressures to provide a higher RoI for doing RPKI.

I'm personally really annoyed that ARIN has been so restrictive with access
to the public key that can used to validate the RPKI that originates with
them.

} It has been suggested that one could authenticate real-world business
} transactions with the signatures of INR holders. E.g. Bill's Bait and Sushi
} could use their AS in the RPKI to sign a Letter of Authorization (LOA) for
} some other party to rack and stack hardware owned by BB&S. Unfortunately,
} this is not formally feasible.

I think that it would be nice if some specific proposals were mentioned.

I don't really know what:
  } no proof of termination

means.

I feel like this document might better be written by an ARIN or ICANN lawyer
in a cease and decist kind of fashion, and that really, adults should be
allowed to do whatever they like with their private keys in the privacy of
their own HSMs.

It isn't clear that we gain by publishing this document.

At some poine in the 1990s, I was assured that Dunn & Bradstreet where going
to issue certificates useful for business transactions.  That never, AFAIK,
happened.

} Government of Elbonia

citation! citation! :-) :-)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Sat, 05 Mar 2022 13:55:32 -0500

Michael Jenkins <[email-masked]> wrote:
    > It appears that RPKI certificates are actually authorization bearer tokens
    > issued by the CA. The CA holds the private key, and the INR holder doesn't?
    > But somehow does, and is somehow using it to sign invoices and love
    > letters.

I read that part too, and I was a bit confused as well.
It's not that the CA holds the private key to the EE RPKI certificate.

It's that, the EE RPKI certificate, being a certificate, is signed by the CA.
(Exactly as you'd expect any CA->EE certificate).
The RPKI certificate is a statement of ownership of INRs by that EE.
That certificate can be updated/replaced based upon somewhat weak
username/passwords logins to the RIR's web sites.

The EE certificate can then be used in various forms of BGP security (mostly
not yet well deployed), and also to sign policy objects about which ASN is
authoritative for which prefixes.

    > Ultimately, I'm not sure why anyone will pay attention to this RFC(-to-be)
    > any more than RFC 6480, which apparently already says "An important
    > property of this PKI is that certificates do not attest to the identity of
    > the subject" - which again calls into question whether these are
    > certificates at all (as opposed to authorization tokens). Maybe the
    > solution isn't more RFCs asserting the lack of identity binding, but more
    > token management?

I agree.
I don't think another RFC will help among those technical people who really
understand things, nor will help among the semi-technical lawyers who don't understand things.
It's only the people in between that might be impressed by an RFC.

If I want to sign an agreement with AS64512 for something, and my lawyer says
that I can obtain AS64512's public key from the RPKI, then it seems like
maybe that's between me and my lawyer.
Maybe we also want to exchange some hashes of SubjectPublicKeyInfo as well,
but that would really be a private discussion.

Should I be concerned that the people who control the HSM for AS64512 might
not be authoritative to sign contracts?  Sure.   Do I need an RFC to tell me
that?  I dunno.