russ suggested some good stuff, incorporated

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

@@ -31,6 +31,20 @@
     </address>
   </author>
 
+  <author fullname="Russ Housley" initials="R" surname="Housley">
+    <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
+    <address>
+      <postal>
+	<street>516 Dranesville Road</street>
+	<city>Herndon</city>
+	<region>VA</region>
+	<code>20170</code>
+	<country>USA</country>
+	 </postal>
+      <email>housley@vigilsec.com</email>
+    </address>
+  </author>
+
   <date />
 
   <abstract>
@@ -61,67 +75,77 @@
 
     <t>The Resource Public Key Infrastructure (RPKI), see <xref
     target="RFC6480"/>, "represents the allocation hierarchy of IP
-    address space and Autonomous System (AS) numbers."</t>
+    address space and Autonomous System (AS) numbers."  Though since, it
+    has grown to include other similar resource and routing data.</t>
 
     <t>In security terms the phrase "Public Key" implies there are also
-    private keys, a la <xref target="RFC2459"/>.  And, as the RPKI has
+    private keys, a la <xref target="RFC5280"/>.  And, as the RPKI has
     strong authority over ownership of Internet Number Resources (INRs),
     there is a desire to use these private keys to sign arbitrary
     documents to attest that the 'owner' of those resources has
-    authorized or authenticated a real world document or
+    authorized or authenticated a real world document or transaction.
-    transaction.</t>
+    Instead, it is an authorization to speak for the named IP address
+    blocks and AS numbers themselves, not their unidentifiable
+    owners.</t>
 
-    <t>The desire is to authenticate real world business transactions
+    <t>There is a desire is to authenticate real world business
-    with the signatures of INR holders.  E.g. for Bill's Bait and Sushi
+    transactions with the signatures of INR holders.  E.g. for Bill's
-    to use their AS in the RPKI to sign a Letter of Authorization (LOA)
+    Bait and Sushi to use their AS in the RPKI to sign a Letter of
-    for some other party to rack and stack hardware owned by BB&amp;S.
+    Authorization (LOA) for some other party to rack and stack hardware
-    Unfortunately, this is not formally feasible.</t>
+    owned by BB&amp;S.  Unfortunately, this is not formally
+    feasible.</t>
 
     <t>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.</t>
+    world holder(s) of those INRs.  The RPKI provides authorization to
+    speak for the named IP address blocks and AS numbers.</t>
 
     </section>
   
   <section anchor="bottom" title="The Bottom Line">
 
-    <t>The RPKI base document, <xref target="RFC6480"/>, Section 2.1
+    <t>The RPKI was designed and specified to sign certificates for use
-    says explicitly "An important property of this PKI is that
+    within the RPKI itself　and to generate Route Origin Authorizations
-    certificates do not attest to the identity of the subject."</t>
+    (ROAs), <xref target="RFC6480"/>, for use in routing.  It's design
-
+    intentionally precluded use for attesting to real world identity as,
-    <t>The "Template for a Certification Practice Statement (CPS) for
+    among other issues, it would expose the Certification Authority (CA)
-    the Resource PKI (RPKI)" <xref target="RFC7382"/> Section 3.1,
+    to liability.</t>
-    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>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
+    feature not a bug.  If it tried to do so, aside from the liability,
-    complexity with no proof of termination, as X.400 learned.</t>
+    it would end in a world of complexity with no proof of termination,
+    as X.400 learned.</t>
 
+    <t>Registries such as the Regional Internet Resistries (RIRs)
+    provide INR to real world identity mapping through whois and similar
+    services.  They claim to be authoritative, at least for for the INRs
+    which they allocate.</t>
+    
     <t>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.</t>
 
+<!--
     <t>If there is sufficient external, i.e. non-RPKI, verifcation of
     authority, then use of RPKI-based credentials seems superfluous.</t>
-
+-->
     </section>
   
   <section anchor="discuss" title="Discussion">
 
     <t>An INR holder does not actually hold the private key attesting to
-    their resources; a Certification Authority (CA) does.  The INR
+    their resources; a CA does.  The INR holder has a real world
-    holder has a real world business relationship with the CA for which
+    business relationship with the CA for which they have likely signed
-    they have likely signed real world documents.</t>
+    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, in order
     to manipulate their INRs.  These credentials may be userid/password
     (with two factor authentication one hopes), hardware tokens, client
-    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
@@ -161,7 +185,17 @@
 
     <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.</t>
+    in 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>
 
@@ -208,7 +242,7 @@
 
   <references title="Normative References">
     <?rfc include="reference.RFC.2119"?>
-    <?rfc include="reference.RFC.2459"?>
+    <?rfc include="reference.RFC.5280"?>
     <?rfc include="reference.RFC.6480"?>
     <?rfc include="reference.RFC.7382"?>
     <?rfc include="reference.RFC.8174"?>