Arrcus & Internet Initiative Japan

5147 Crystal Springs Bainbridge Island WA 98110 US randy@psg.com

There is a false notion that internet number resource in the RPKI can be associated with the real world identity of the 'owner' of an internet number resource. This document attempts to put that notion to rest. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The Resource Public Key Infrastructure (RPKI), see , "represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers." In security terms the phrase "Public Key" implies there are also private keys, a la . And, as the RPKI has strong authority over ownership of Internet Number Resources (INRs), there is a desire to use the private keys to sign arbitraty documents to attest that the 'owner' of those resources has attested to the authenticity of those documents. The desire is to authenticate real world business transactions with the signatures of INR holders. E.g. for Bill's Bait and Sushi to 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 feasible. The I in RPKI actually stands for "Infrastructure," as in Resource Public Key Infrastructure, not for "Identity". In fact, the RPKI does not provide any association between INRs and the real world holder(s) of those INRs.

The Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI) Section 3.1, Naming, makes very clear that "The Subject name in each certificate SHOULD NOT be meaningful;" and goes on to do so at some length. That the RPKI does not authenticate real world identity is a feature not a bug. If it tried to do so, it would end in a world of complexity with no proof of termination, as X.400 learned.

In reality, the INR holder does not even hold the private key attesting to their resources; the Certification Authority (CA) does. Which is why schemes such as and must go to great lengths to extract the supposedly [not really] relevant keys from the CA. As the INR owner does not have the keying material, they rely on the CA, to which they presumably must present credentials to manipulate their INRs. These credentials may be userid/password (with two factor authentication one hopes), client browser certificates, etc. For some particular INR, say Bill's Bait and Sushi's AS number, someone out on the net probably has the credentials to the CA where it is registered. That could be the owner of BB&S, Roberto's Taco Stand, or the Government of Elbonia. One simpley can not know. Then there is the temporal issue. The owner of that AS may be BB&S today when your document was signed, and could be the Government of Elbonia tomorrow. If so, is the signature still valid? It is somewhat droll that the CPS template, , does not mention any diligence the CA MUST, or even SHOULD, conduct to assure the INRs are in fact owned by a registrant. While Ghostbuster Records may seem to identify a real world entity, in fact their content is completely arbitrary, and do not attest to INR ownership. They are merely an clue for operational support in case of problems.

Attempts to use RPKI data to authenticate real world documents or other artifacts requiring indentiy are invalid and misleading.

This document has no IANA Considerations.

The authors thank George Michaelson and Job Snijders for lively discussion.