spell check

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

@@ -65,7 +65,7 @@
     <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
+    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.</t>
 
@@ -97,46 +97,49 @@
   
   <section anchor="discuss" title="Discussion">
 
-    <t>In reality, the INR holder does not even hold the private key
+    <t>Normally, the INR holder does not hold the private key attesting
-    attesting to their resources; the Certification Authority (CA) does.
+    to their resources; the Certification Authority (CA) does.</t>
-    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
+    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
+    (with two factor authentication one hopes), a hardware token, client
-    certificates, etc.</t>
+    browser 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
+    lengths to extract the supposedly [not really] relevant keys from
+    the CA.</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
+    someone out on the net probably has the credentials to the CA
-    it is registered.  That could be the owner of BB&amp;S, Roberto's
+    account in which it is registered.  That could be the owner of
-    Taco Stand, or the Government of Elbonia.  One simpley can not
+    BB&amp;S, Roberto's Taco Stand, or the Government of Elbonia.  One
-    know.</t>
+    simply 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
+    BB&amp;S today when some document was signed, and could be the
-    Government of Elbonia tomorrow.  If so, is the signature still
+    Government of Elbonia tomorrow.  Or the resource could have been
-    valid?</t>
+    administratively moved from one CA to another, likely requiring a
+    change of kets.  If so, is the signature still valid?</t>
+
+    <t>Beware that, while Ghostbuster Records <xref target="RFC6493"/>
+    may seem to identify a real world entity, in fact their semantic
+    content is completely arbitrary, and does not attest to INR
+    ownership.  They are merely a clue for operational support contact
+    in case of technical RPKI problems.</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>
+    other artifacts requiring identity are invalid and misleading.</t>
 
     </section>