The I in RPKI does not stand for Identity

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 these private keys to sign arbitrary documents to attest that the 'owner' of those resources has authorized or authenticated a real world document or transaction. 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.

An INR holder does not actually hold the private key attesting to their resources; a Certification Authority (CA) does. The INR holder has a real world business relationship with the CA for which they have likely signed real world documents. 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), hardware tokens, client browser certificates, etc. Hence schemes such as and must go to great lengths to extract the supposedly [not really] relevant keys from the CA. 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 account in which BB&S's INRs are registered. That could be the owner of BB&S, Roberto's Taco Stand, or the Government of Elbonia. One simply can not know. In large operations, INR management is often compartmentalized with no authority over anything beyond dealing with INR registration. The INR manager for Bill's Bait and Sushi is unlikely to be authorized to conduct bank transactions for BB&S, or even to authorize access to BB&S's servers in some colocation facility. There is also a temporal issue. The owner of an 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 to determine if the signature on the real world document still valid? While Ghostbuster Records may seem to identify real world entities, their semantic content is completely arbitrary, and does not attest to INR ownership. They are merely clues for operational support contact in case of technical RPKI problems. Usually, before registering INRs, CAs require proof of INR ownership via external documentation and authorities. 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.

Attempts to use RPKI data to authenticate real world documents or other artifacts requiring identity are invalid and misleading. The control of INRs for an entity could be used to falsely authorize transactions or documents for which the INR manager has no authority. RPKI-based keying from INRs MUST NOT be used to authenticate real world documents or transactions without some external authentication of the INR and the authority for the actually anonymous INR holder to authenticate the particular document or transaction.

This document has no IANA Considerations.

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