diff --git a/draft-ietf-sidrops-rpki-has-no-identity.xml b/draft-ietf-sidrops-rpki-has-no-identity.xml index 09984ae..3510030 100644 --- a/draft-ietf-sidrops-rpki-has-no-identity.xml +++ b/draft-ietf-sidrops-rpki-has-no-identity.xml @@ -11,7 +11,7 @@ - + @@ -82,15 +82,15 @@ 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. Instead, it is an + to the authenticity of those documents. But in reality, it is an authorization to speak for the named IP address blocks and AS numbers themselves, not their unidentifiable owners. - There is a desire 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 formally + 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 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 formally feasible. The I in RPKI actually stands for "Infrastructure," as in @@ -126,24 +126,33 @@ anonymous INR holder to authenticate the particular document or transaction. - - + Note that, if there is sufficient external, i.e. non-RPKI, + verifcation of authority, then use of RPKI-based credentials seems + superfluous. + +
+ 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. + Normally, the INR holder does not hold the private key attesting to their resources; the Certification Authority (CA) does. The INR 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 - 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. + 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 + certificates, etc. Hence schemes such as and must go to great @@ -156,7 +165,7 @@ Stand, an IT vendor, or the Government of Elbonia. One simply can not know. - In large operations, INR management is often compartmentalized + In large organizations, INR management is often compartmentalized with no authority over anything beyond dealing with INR registration. The INR manager for Bill's Bait and Sushi is unlikely to be authorized to conduct bank transactions for BB&S, or even @@ -184,18 +193,9 @@ Autonomous System Numbers do not identify real world entities. They are identifiers some network operators 'own' and are only used - in loop detection in routing. They have no inherent semantics other + for loop detection in routing. They have no inherent semantics other than uniqueness. - 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. -
@@ -250,18 +250,18 @@ - - - - - - + + + + + + - - - + + +