diff --git a/draft-ietf-sidrops-rpki-has-no-identity.xml b/draft-ietf-sidrops-rpki-has-no-identity.xml index ae21159..c9b2377 100644 --- a/draft-ietf-sidrops-rpki-has-no-identity.xml +++ b/draft-ietf-sidrops-rpki-has-no-identity.xml @@ -49,7 +49,7 @@ There is a false notion that Internet Number Resources (INRs) in - the RPKI can be associated with the real-world identity of the 'owner' + the RPKI can be associated with the real-world identity of the 'holder' of an INR. This document attempts to put that notion to rest. @@ -80,23 +80,24 @@ target="RFC8635"/>. In security terms, the phrase "Public Key" implies there is also - a corresponding private key . The RPKI's - strong authority over ownership of INRs has misled some people - toward a desire to use RPKI private keys to sign arbitrary documents - attesting that the INR 'owner' of those resources has attested to - the authenticity of the document content. But in reality, the RPKI - certificate is only an authorization to speak for the explicitly - identified INRs; it is explicitly not intended for authentication of - the 'owners' of the INRs. This situation is emphasized in Section - 2.1 of . + a corresponding private key . The RPKI + provides strong authority to the current holder of INRs; however, + some people a have a desire to use RPKI private keys to sign + arbitrary documents as the INR 'holder' of those resources with the + inappropriate expectation that the signature will be considered an + attestation to the authenticity of the document content. But in + reality, the RPKI certificate is only an authorization to speak for + the explicitly identified INRs; it is explicitly not intended for + authentication of the 'holders' of the INRs. This situation is + emphasized in Section 2.1 of . 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 the private key attesting to - ownership of 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, while this may be technically possible, it - is neither appropriate nor meaningful. + Bill's Bait and Sushi could use the private key attesting to that + they are the holder of 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, while this may be technically + possible, it is neither appropriate nor meaningful. The I in RPKI actually stands for "Infrastructure," as in Resource Public Key Infrastructure, not for "Identity". In fact, @@ -167,7 +168,7 @@ 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 + As the INR holder does not have the keying material, they rely on the CA, to which they presumably present credentials, to manipulate their INRs. These credentials may be userid/password (with two factor authentication one hopes), a hardware token, client browser @@ -191,7 +192,7 @@ to authorize access to BB&S's servers in some colocation facility. - Then there is the temporal issue. The owner of that AS may be + 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 Elbonia tomorrow. Or the resource could have been administratively moved from one CA to another, likely requiring a @@ -200,15 +201,15 @@ 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. + arbitrary, and does not attest to holding of any INRs. 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 might, conduct to - assure the INRs are in fact owned by a registrant. + Usually, before registering INRs, CAs require proof of an INR + holding via external documentation and authorities. It is somewhat + droll that the CPS Template, , does not + mention any diligence the CA must, or even might, conduct to assure + the INRs are in fact owned by a registrant. That someone can provide 'proof of possession' of the private key signing over a particular INR should not be taken to imply that they