-01 published

draft-ietf-sidrops-rpki-has-no-identity.xml

@@ -11,7 +11,7 @@
 <?rfc tocindent="yes"?>
 <?rfc tocompact="yes"?>
 
-<rfc category="std" docName="draft-ietf-sidrops-rpki-has-no-identity-00" ipr="trust200902">
+<rfc category="std" consensus="true" docName="draft-ietf-sidrops-rpki-has-no-identity-01" ipr="trust200902">
 
 <front>
 
@@ -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.</t>
 
-    <t>There is a desire to authenticate real world business
+    <t>It has been suggested that one could authenticate real world
-    transactions with the signatures of INR holders.  E.g. for Bill's
+    business transactions with the signatures of INR holders.  E.g.
-    Bait and Sushi to use their AS in the RPKI to sign a Letter of
+    Bill's Bait and Sushi could use their AS in the RPKI to sign a
-    Authorization (LOA) for some other party to rack and stack hardware
+    Letter of Authorization (LOA) for some other party to rack and stack
-    owned by BB&amp;S.  Unfortunately, this is not formally
+    hardware owned by BB&amp;S.  Unfortunately, this is not formally
     feasible.</t>
 
     <t>The I in RPKI actually stands for "Infrastructure," as in
@@ -126,24 +126,33 @@
     anonymous INR holder to authenticate the particular document or
     transaction.</t>
 
-<!--
+    <t>Note that, if there is sufficient external, i.e. non-RPKI,
-    <t>If there is sufficient external, i.e. non-RPKI, verifcation of
+    verifcation of authority, then use of RPKI-based credentials seems
-    authority, then use of RPKI-based credentials seems superfluous.</t>
+    superfluous.</t>
--->
-    </section>
   
+    </section>
+
   <section anchor="discuss" title="Discussion">
 
+    <t>The RPKI base document, <xref target="RFC6480"/>, Section 2.1
+    says explicitly "An important property of this PKI is that
+    certificates do not attest to the identity of the subject."</t>
+
+    <t>The Template for a Certification Practice Statement (CPS) for the
+    Resource PKI (RPKI) <xref target="RFC7382"/> 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.</t>
+
     <t>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.</t>
 
     <t>As the INR owner does not have the keying material, they rely on
-    the CA, to which they presumably must present credentials, to
+    the CA, to which they presumably present credentials, to manipulate
-    manipulate their INRs.  These credentials may be userid/password
+    their INRs.  These credentials may be userid/password (with two
-    (with two factor authentication one hopes), a hardware token, client
+    factor authentication one hopes), a hardware token, client browser
-    browser certificates, etc.</t>
+    certificates, etc.</t>
 
     <t>Hence schemes such as <xref target="I-D.ietf-sidrops-rpki-rta"/>
     and <xref target="I-D.ietf-sidrops-rpki-rsc"/> must go to great
@@ -156,7 +165,7 @@
     Stand, an IT vendor, or the Government of Elbonia.  One simply can
     not know.</t>
 
-    <t>In large operations, INR management is often compartmentalized
+    <t>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&amp;S, or even
@@ -184,18 +193,9 @@
 
     <t>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.</t>
 
-    <t>The RPKI base document, <xref target="RFC6480"/>, Section 2.1
-    says explicitly "An important property of this PKI is that
-    certificates do not attest to the identity of the subject."</t>
-
-    <t>The Template for a Certification Practice Statement (CPS) for the
-    Resource PKI (RPKI) <xref target="RFC7382"/> 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.</t>
-
     </section>
 
   <section anchor="security" title="Security Considerations">
@@ -250,18 +250,18 @@
 <back>
 
   <references title="Normative References">
-    <?rfc include="reference.RFC.2119"?>
+    <?rfc include="reference.RFC.2119.xml"?>
-    <?rfc include="reference.RFC.5280"?>
+    <?rfc include="reference.RFC.5280.xml"?>
-    <?rfc include="reference.RFC.6480"?>
+    <?rfc include="reference.RFC.6480.xml"?>
-    <?rfc include="reference.RFC.7382"?>
+    <?rfc include="reference.RFC.7382.xml"?>
-    <?rfc include="reference.RFC.8174"?>
+    <?rfc include="reference.RFC.8174.xml"?>
-    <?rfc include="reference.RFC.8635"?>
+    <?rfc include="reference.RFC.8635.xml"?>
     </references>
 
   <references title="Informative References">
-    <?rfc include="reference.RFC.6493"?>
+    <?rfc include="reference.RFC.6493.xml"?>
-    <?rfc include="reference.I-D.ietf-sidrops-rpki-rsc"?>
+    <?rfc include="reference.I-D.ietf-sidrops-rpki-rsc.xml"?>
-    <?rfc include="reference.I-D.ietf-sidrops-rpki-rta"?>
+    <?rfc include="reference.I-D.ietf-sidrops-rpki-rta.xml"?>
     </references>
     
   </back>