The 'I' in RPKI Does Not Stand for Identity
Extracted elements (15)
Autonomous System Numbers do not identify real-world entities — they are identifiers used only for loop detection in routing and have no inherent semantics beyond uniqueness. Using AS numbers as identity anchors is therefore meaningless.
Ghostbuster Records (RFC 6493) may seem to identify real-world entities, but their semantic content is completely arbitrary and does not attest to holding of any INRs. They serve only as operational contact clues for RPKI problems.
Given external (non-RPKI) verification of authority, the use of RPKI-based credentials adds no authenticity. External identity verification and RPKI authorization are orthogonal; combining them does not produce stronger identity guarantees.
INR management is often compartmentalized in large organizations with no authority beyond INR registration. The INR manager is unlikely to be authorized to conduct broader business transactions, so RPKI key control does not imply general organizational authority.
Normally the INR holder does not hold the private key attesting to their resources — the CA does. The INR holder has a real-world business relationship with the CA and relies on it to manipulate INRs, meaning proof of key possession does not imply organizational authority.
Per RFC 7382 Section 3.1, the Subject name in each RPKI certificate SHOULD NOT be meaningful. The CPS template deliberately avoids any attestation of real-world identity in certificate subject fields.
The 'I' in RPKI stands for 'Infrastructure,' not 'Identity.' RFC 6480 Section 2.1 states explicitly: 'An important property of this PKI is that certificates do not attest to the identity of the subject.'
The RPKI was intentionally designed to preclude use for attesting to real-world identity. Permitting such use would expose Certification Authorities to liability and would result in unbounded complexity with no proof of termination.
There is a temporal issue with using RPKI for identity: the holder of an AS or IP prefix may change after a document was signed, or resources may be administratively moved between CAs requiring a key change, making it impossible to determine if a real-world signature remains valid.
Regional Internet Registries (RIRs) provide INR-to-real-world identity mapping through WHOIS (RFC 3912) and similar services, and claim to be authoritative for the INRs they allocate. This is the appropriate mechanism for INR identity, not RPKI.
RPKI-based credentials of INRs MUST NOT be used to authenticate real-world documents or transactions. The RPKI provides authorization to speak for INRs, not identity attestation of their holders.
An RPKI certificate authorizes the holder to speak for the explicitly identified Internet Number Resources (IP address prefixes and AS numbers). It is not a credential for authenticating the real-world identity of the INR holder.
Route Origin Authorizations (ROAs) and ASPA records are the intended outputs of RPKI signing operations, scoped strictly to routing-related assertions about INRs. Schemes like Resource Tagged Attestations and Signed Checklists must extract keys from CAs to attempt identity-adjacent uses.
Attempts to use RPKI data to authenticate real-world documents are misleading as to authenticity. When a document is signed with an RPKI private key, the signer is speaking for INRs (an authorization), not asserting a real-world identity.
Control of INRs for an entity could be exploited to falsely authorize transactions or documents for which the INR manager has no legal or organizational authority, since key possession over an INR does not imply broader representative authority.