break point

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

@@ -58,19 +58,97 @@
 
   <section anchor="intro" title="Introduction">
 
-    <t>The Template for a Certification Practice Statement (CPS) for the
+    <t>The Resource Public Key Infrastructure (RPKI), see <xref
-    Resource PKI (RPKI) <xref target="RFC7382"/> Section 3.1, Naming,
+    target="RFC6480"/>, "represents the allocation hierarchy of IP
-    makes very clear that "The Subject name in each certificate SHOULD
+    address space and Autonomous System (AS) numbers."</t>
-    NOT be "meaningful;" and goes on to do so at some length.</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
+    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.</t>
+
+    <t>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&amp;S.
+    Unfortunately, this is not 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>
 
     </section>
   
+  <section anchor="bottom" title="The Bottom Line">
+
+    <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>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.</t>
+
+    </section>
+  
+  <section anchor="discuss" title="Discussion">
+
+    <t>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 <xref
+    target="I-D.ietf-sidrops-rpki-rta"/> and <xref
+    target="I-D.ietf-sidrops-rpki-rsc"/> must go to great lengths to
+    extract the supposedly [not really] relevant keys from the CA.</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
+    manipulate their INRs.  These credentials may be userid/password
+    (with two factor authentication one hopes), client browser
+    certificates, etc.</t>
+
+    <t>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&amp;S, Roberto's
+    Taco Stand, or the Government of Elbonia.  One simpley can not
+    know.</t>
+
+    <t>Then there is the temporal issue.  The owner of that AS may be
+    BB&amp;S today when your document was signed, and could be the
+    Government of Elbonia tomorrow.  If so, is the signature still
+    valid?</t>
+
+    <t>It is somewhat droll that the CPS template, <xref
+    target="RFC7382"/>, does not mention any diligence the CA MUST, or
+    even SHOULD, conduct to assure the INRs are in fact owned by a
+    registrant.</t>
+
+    <t>While Ghostbuster Records <xref target="RFC6493"/> 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.</t>
+
+    </section>
+
   <section anchor="security" title="Security Considerations">
 
+    <t>Attempts to use RPKI data to authenticate real world documents or
+    other artifacts requiring indentiy are invalid and misleading.</t>
+
     </section>
 
   <section anchor="iana" title="IANA Considerations">
 
+    <t>This document has no IANA Considerations.</t>
+    
+    <!--
+    <t>Note to RFC Editor: this section may be replaced on publication
+    as an RFC.</t>
+    -->
+    
     </section>
 
   <section anchor="acks" title="Acknowledgments">
@@ -86,14 +164,17 @@
 
   <references title="Normative References">
     <?rfc include="reference.RFC.2119"?>
+    <?rfc include="reference.RFC.2459"?>
+    <?rfc include="reference.RFC.6480"?>
     <?rfc include="reference.RFC.7382"?>
     <?rfc include="reference.RFC.8174"?>
     </references>
 
-<!--
   <references title="Informative References">
+    <?rfc include="reference.RFC.6493"?>
+    <?rfc include="reference.I-D.ietf-sidrops-rpki-rsc"?>
+    <?rfc include="reference.I-D.ietf-sidrops-rpki-rta"?>
     </references>
--->
     
   </back>
 </rfc>