diff --git a/draft-ymbk-sidrops-rpki-has-no-identity.xml b/draft-ymbk-sidrops-rpki-has-no-identity.xml index c12240d..90c731f 100644 --- a/draft-ymbk-sidrops-rpki-has-no-identity.xml +++ b/draft-ymbk-sidrops-rpki-has-no-identity.xml @@ -75,7 +75,7 @@ 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. + Unfortunately, this is not formally feasible. The I in RPKI actually stands for "Infrastructure," as in Resource Public Key Infrastructure, not for "Identity". In fact, @@ -86,15 +86,28 @@
- 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 RPKI base document, , Section 2.1 + says explicitly "An important property of this PKI is that + certificates do not attest to the identity of the subject." + + 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. + RPKI-based credentials of INRs MUST NOT be used to authenticate + real world documents or transactions without some formal external + authentication of the INR and the authority for the actually + anonymous INR holder to authenticate the particular document or + transaction. + + If there is sufficient external, i.e. non-RPKI, verifcation of + authority, then use of RPKI-based credentials seems superfluous. +
@@ -105,21 +118,20 @@ they have likely signed real world documents. 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 + the CA, to which they presumably must present credentials, in order + to manipulate their INRs. These credentials may be userid/password (with two factor authentication one hopes), hardware tokens, 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. + lengths to extract the supposedly 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 BB&S's INRs are registered. That could be the - owner of BB&S, Roberto's Taco Stand, or the Government of - Elbonia. One simply can not know. + For some particular INR, say Bill's Bait and Sushi's Autonompus + System (AS) number, someone out on the net probably has the + 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, or the Government of Elbonia. One simply can not know. In large operations, INR management is often compartmentalized with no authority over anything beyond dealing with INR @@ -128,12 +140,12 @@ to authorize access to BB&S's servers in some colocation facility. - There is also a temporal issue. The owner of an AS may be + There is the temporal issue that the owner of an INR 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 keys. If so, how to determine if the signature on the - real world document still valid? + change of keys. If so, how does one determine if the signature on + the real world document is still valid? While Ghostbuster Records may seem to identify real world entities, their semantic content is completely @@ -143,8 +155,8 @@ 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 should, conduct to + 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.
@@ -152,16 +164,18 @@
Attempts to use RPKI data to authenticate real world documents or - other artifacts requiring identity are invalid and misleading. + other artifacts requiring identity are inappropriate and + dangerous. - The control of INRs for an entity could be used to falsely - authorize transactions or documents for which the INR manager has no + Control of INRs for an entity could be used to falsely authorize + transactions or documents for which the INR manager has no authority. - RPKI-based keying from INRs MUST NOT be used to authenticate real - world documents or transactions without some external authentication - of the INR and the authority for the actually anonymous INR holder - to authenticate the particular document or transaction. + RPKI-based credentials of INRs MUST NOT be used to authenticate + real world documents or transactions without some formal external + authentication of the INR and the authority for the actually + anonymous INR holder to authenticate the particular document or + transaction.
@@ -179,7 +193,8 @@
The authors thank George Michaelson and Job Snijders for lively - discussion. + discussion; and last but not least, Biff for the loan of Bill's Bait + and Sushi.