Script updating gh-pages from d427681. [ci skip]

remove_root-CA_terminology/draft-ietf-lamps-rfc4210bis.html

@@ -4187,7 +4187,7 @@ <h4 id="name-certificate-identification">
           <h4 id="name-out-of-band-trusted-ca-publ">
 <a href="#section-5.2.5" class="section-number selfRef">5.2.5. </a><a href="#name-out-of-band-trusted-ca-publ" class="section-name selfRef">Out-of-band trusted CA Public Key</a>
           </h4>
-<p id="section-5.2.5-1">Each trusted CA must be able to publish its current public key via some
+<p id="section-5.2.5-1">Each trusted CA that provides its self-signed certificate must be able to publish its current public key via some
 "out-of-band" means or together with the respective link certificate using an online mechanism.  While such mechanisms are beyond the scope of
 this document, we define data structures that can support such
 mechanisms.<a href="#section-5.2.5-1" class="pilcrow">¶</a></p>
@@ -6137,9 +6137,9 @@ <h4 id="name-out-of-band-verification-of">
 <a href="#section-6.7.2" class="section-number selfRef">6.7.2. </a><a href="#name-out-of-band-verification-of" class="section-name selfRef">Out-of-Band Verification of Trusted CA Key</a>
           </h4>
 <p id="section-6.7.2-1">An end entity must securely possess the public key of its trusted CA.
-One method to achieve this is to provide the end entity with the CA's
-self-certificate fingerprint via some secure "out-of-band" means.
-The end entity can then securely use the CA's self-certificate.<a href="#section-6.7.2-1" class="pilcrow">¶</a></p>
+One method to achieve this is to provide the end entity with the trusted CA's
+certificate fingerprint via some secure "out-of-band" means.
+The end entity can then securely use the trusted CA's certificate.<a href="#section-6.7.2-1" class="pilcrow">¶</a></p>
 <p id="section-6.7.2-2">See <a href="#sect-6.1" class="auto internal xref">Section 6.1</a> for further details.<a href="#section-6.7.2-2" class="pilcrow">¶</a></p>
 </section>
 </div>
@@ -6387,7 +6387,7 @@ <h3 id="name-entropy-of-random-numbers-k">
 different key pairs, the security of the shared secret information should
 exceed the security strength of each individual key pair.<a href="#section-8.7-3" class="pilcrow">¶</a></p>
 <p id="section-8.7-4">For the case of a PKI management operation that delivers a new trust anchor
-(e.g., a trusted CA certificate) using caPubs or genp that is (a) not concluded
+(i.e., a trusted CA certificate) using caPubs or genp that is (a) not concluded
 in a timely manner or (b) where the shared secret information is reused
 for several key management operations, the entropy of the shared secret information,
 if known, should not be less than the security strength of the trust anchor

remove_root-CA_terminology/draft-ietf-lamps-rfc4210bis.txt

@@ -2315,11 +2315,11 @@ Table of Contents
 
 5.2.5.  Out-of-band trusted CA Public Key
 
-   Each trusted CA must be able to publish its current public key via
-   some "out-of-band" means or together with the respective link
-   certificate using an online mechanism.  While such mechanisms are
-   beyond the scope of this document, we define data structures that can
-   support such mechanisms.
+   Each trusted CA that provides its self-signed certificate must be
+   able to publish its current public key via some "out-of-band" means
+   or together with the respective link certificate using an online
+   mechanism.  While such mechanisms are beyond the scope of this
+   document, we define data structures that can support such mechanisms.
 
    There are generally two methods available: Either the CA directly
    publishes its self-signed certificate, or this information is
@@ -3749,9 +3749,10 @@ Table of Contents
 6.7.2.  Out-of-Band Verification of Trusted CA Key
 
    An end entity must securely possess the public key of its trusted CA.
-   One method to achieve this is to provide the end entity with the CA's
-   self-certificate fingerprint via some secure "out-of-band" means.
-   The end entity can then securely use the CA's self-certificate.
+   One method to achieve this is to provide the end entity with the
+   trusted CA's certificate fingerprint via some secure "out-of-band"
+   means.  The end entity can then securely use the trusted CA's
+   certificate.
 
    See Section 6.1 for further details.
 
@@ -3977,7 +3978,7 @@ Table of Contents
    individual key pair.
 
    For the case of a PKI management operation that delivers a new trust
-   anchor (e.g., a trusted CA certificate) using caPubs or genp that is
+   anchor (i.e., a trusted CA certificate) using caPubs or genp that is
    (a) not concluded in a timely manner or (b) where the shared secret
    information is reused for several key management operations, the
    entropy of the shared secret information, if known, should not be