diff --git a/draft-ymbk-rpki-has-no-identity.xml b/draft-ymbk-rpki-has-no-identity.xml deleted file mode 100644 index 43a5cf0..0000000 --- a/draft-ymbk-rpki-has-no-identity.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - - - - - - - - - - - - The I in RPKI does not stand for Identity - - - 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 arbitrary - 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. - -
- -
- - Normally, the INR holder does not hold the private key attesting - to their resources; the Certification Authority (CA) does. - - 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), a hardware token, 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 it is registered. That could be the owner of - BB&S, Roberto's Taco Stand, or the Government of Elbonia. One - simply can not know. - - Then there is the temporal issue. The owner 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 - change of kets. If so, is the signature still valid? - - Beware that, while Ghostbuster Records - may seem to identify a real world entity, in fact their semantic - content is completely arbitrary, and does not attest to INR - ownership. They are merely a clue for operational support contact - in case of technical RPKI problems. - - 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. - -
- -
- - This document has no IANA Considerations. - - - -
- -
- - The authors thank George Michaelson and Job Snijders for lively - discussion. - -
- - - - - - - - - - - - - - - - - - - - -