diff --git a/draft-ymbk-rpki-has-no-identity.xml b/draft-ymbk-rpki-has-no-identity.xml index 057de66..91648fc 100644 --- a/draft-ymbk-rpki-has-no-identity.xml +++ b/draft-ymbk-rpki-has-no-identity.xml @@ -58,19 +58,97 @@
- 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. + 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 arbitraty + 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. + +
+ +
+ + In reality, the INR holder does not even hold the private key + attesting to their resources; the Certification Authority (CA) does. + Which is why schemes such as and must go to great lengths to + extract the supposedly [not really] relevant keys from the CA. + + 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), client browser + certificates, etc. + + 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 where + it is registered. That could be the owner of BB&S, Roberto's + Taco Stand, or the Government of Elbonia. One simpley can not + know. + + Then there is the temporal issue. The owner of that AS may be + BB&S today when your document was signed, and could be the + Government of Elbonia tomorrow. If so, is the signature still + valid? + + 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. + + While Ghostbuster Records may seem to + identify a real world entity, in fact their content is completely + arbitrary, and do not attest to INR ownership. They are merely an + clue for operational support in case of problems. + +
+
+ Attempts to use RPKI data to authenticate real world documents or + other artifacts requiring indentiy are invalid and misleading. +
+ This document has no IANA Considerations. + + +
@@ -86,14 +164,17 @@ + + -