rfc9255v1.txt   rfc9255.txt 
Internet Engineering Task Force (IETF) R. Bush Internet Engineering Task Force (IETF) R. Bush
Request for Comments: 9255 Arrcus & Internet Initiative Japan Request for Comments: 9255 Arrcus & IIJ
Category: Standards Track R. Housley Category: Standards Track R. Housley
ISSN: 2070-1721 Vigil Security ISSN: 2070-1721 Vigil Security
June 2022 June 2022
The 'I' in RPKI Does Not Stand for Identity The 'I' in RPKI Does Not Stand for Identity
Abstract Abstract
There is a false notion that Internet Number Resources (INRs) in the There is a false notion that Internet Number Resources (INRs) in the
RPKI can be associated with the real-world identity of the 'holder' RPKI can be associated with the real-world identity of the 'holder'
skipping to change at line 143 skipping to change at line 143
document or transaction. Given such external, i.e. non-RPKI, document or transaction. Given such external, i.e. non-RPKI,
verification of authority, the use of RPKI-based credentials adds no verification of authority, the use of RPKI-based credentials adds no
authenticity. authenticity.
3. Discussion 3. Discussion
Section 2.1 of the RPKI base document [RFC6480] says explicitly "An Section 2.1 of the RPKI base document [RFC6480] says explicitly "An
important property of this PKI is that certificates do not attest to important property of this PKI is that certificates do not attest to
the identity of the subject." the identity of the subject."
Section 3.1.2 of "Template for a Certification Practice Statement Section 3.1 of "Template for a Certification Practice Statement (CPS)
(CPS) for the Resource PKI (RPKI)" [RFC7382] makes very clear that for the Resource PKI (RPKI)" [RFC7382] states that the Subject name
"The Subject name in each certificate SHOULD NOT be 'meaningful'" and in each certificate SHOULD NOT be meaningful and goes on to explain
goes on to do so at some length. this at some length.
Normally, the INR holder does not hold the private key attesting to Normally, the INR holder does not hold the private key attesting to
their resources; the CA does. The INR holder has a real-world their resources; the CA does. The INR holder has a real-world
business relationship with the CA for which they have likely signed business relationship with the CA for which they have likely signed
real-world documents. real-world documents.
As the INR holder does not have the keying material, they rely on the As the INR holder does not have the keying material, they rely on the
CA, to which they presumably present credentials, to manipulate their CA, to which they presumably present credentials, to manipulate their
INRs. These credentials may be user ID and password (with two-factor INRs. These credentials may be user ID and password (with two-factor
authentication one hopes), a hardware token, client browser authentication one hopes), a hardware token, client browser
certificates, etc. certificates, etc.
Hence schemes such as [RPKI-RTA] and [RPKI-RSC] must go to great Hence schemes such as Resource Tagged Attestations [RPKI-RTA] and
lengths to extract the supposedly relevant keys from the CA. Signed Checklists [RPKI-RSC] must go to great lengths to extract the
supposedly relevant keys from the CA.
For some particular INR, say, Bill's Bait and Sushi's Autonomous For some particular INR, say, Bill's Bait and Sushi's Autonomous
System (AS) number, someone out on the net probably has the System (AS) number, someone out on the net probably has the
credentials to the CA account in which BB&S's INRs are registered. 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, an IT vendor, That could be the owner of BB&S, Roberto's Taco Stand (in San Diego),
or the Government of Elbonia. One simply can not know. an IT vendor, or the Government of Elbonia. One simply can not know.
In large organizations, INR management is often compartmentalized In large organizations, INR management is often compartmentalized
with no authority over anything beyond dealing with INR registration. with no authority over anything beyond dealing with INR registration.
The INR manager for Bill's Bait and Sushi is unlikely to be The INR manager for Bill's Bait and Sushi is unlikely to be
authorized to conduct bank transactions for BB&S, or even to authorized to conduct bank transactions for BB&S, or even to
authorize access to BB&S's servers in some colocation facility. authorize access to BB&S's servers in some colocation facility.
Then there is the temporal issue. The holder of that AS may be BB&S Then there is the temporal issue. The holder of that AS may be BB&S
today when some document was signed, and could be the Government of today when some document was signed, and could be the Government of
Elbonia tomorrow. Or the resource could have been administratively Elbonia tomorrow. Or the resource could have been administratively
skipping to change at line 195 skipping to change at line 196
Usually, before registering INRs, CAs require proof of an INR holding Usually, before registering INRs, CAs require proof of an INR holding
via external documentation and authorities. It is somewhat droll via external documentation and authorities. It is somewhat droll
that the CPS Template [RFC7382] does not mention any diligence the CA that the CPS Template [RFC7382] does not mention any diligence the CA
must, or even might, conduct to assure the INRs are in fact owned by must, or even might, conduct to assure the INRs are in fact owned by
a registrant. a registrant.
That someone can provide 'proof of possession' of the private key That someone can provide 'proof of possession' of the private key
signing over a particular INR should not be taken to imply that they signing over a particular INR should not be taken to imply that they
are a valid legal representative of the organization in possession of are a valid legal representative of the organization in possession of
that INR. They could be just an INR administrative person. that INR. They could be in an INR administrative role, and not be a
formal representative of the organization.
Autonomous System Numbers do not identify real-world entities. They Autonomous System Numbers do not identify real-world entities. They
are identifiers some network operators 'own' and are only used for are identifiers some network operators 'own' and are only used for
loop detection in routing. They have no inherent semantics other loop detection in routing. They have no inherent semantics other
than uniqueness. than uniqueness.
4. Security Considerations 4. Security Considerations
Attempts to use RPKI data to authenticate real-world documents or Attempts to use RPKI data to authenticate real-world documents or
other artifacts requiring identity, while possibly cryptographically other artifacts requiring identity, while possibly cryptographically
 End of changes. 5 change blocks. 
10 lines changed or deleted 12 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/