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

Author: ID Bot

subca-bypass/draft-ietf-plants-merkle-tree-certs.html

@@ -5316,7 +5316,7 @@ <h3 id="name-subordinate-certification-a">
 <a href="#section-12.9" class="section-number selfRef">12.9. </a><a href="#name-subordinate-certification-a" class="section-name selfRef">Subordinate Certification Authorities</a>
         </h3>
 <p id="section-12.9-1">Merkle Tree Certificates' transparency properties only apply to certificates directly issued by the CA, not certification paths. The CA might issue a certificate that describes an unconstrained, subordinate, non-MTC CA. Certificates issued by the subordinate CA would not be visible in the MTC CA's issuance log and thus may not be visible to monitors. However, the certificate that enables this transparency bypass will still be visible in the issuance logs.<a href="#section-12.9-1" class="pilcrow">¶</a></p>
-<p id="section-12.9-2">Relying parties with transparency requirements SHOULD impose policies that prevent these bypasses. For example, a relying party might require that all subordinate CAs have name constraints (<span><a href="https://rfc-editor.org/rfc/rfc5280#section-4.2.1.10" class="relref">Section 4.2.1.10</a> of [<a href="#RFC5280" class="cite xref">RFC5280</a>]</span>) or forbid subordinate CAs entirely. Relying parties MAY enforce these policies as part of certification path validation.<a href="#section-12.9-2" class="pilcrow">¶</a></p>
+<p id="section-12.9-2">Relying parties with transparency requirements SHOULD impose policies that prevent these bypasses. For example, a relying party might require that all subordinate CAs have name constraints (<span><a href="https://rfc-editor.org/rfc/rfc5280#section-4.2.1.10" class="relref">Section 4.2.1.10</a> of [<a href="#RFC5280" class="cite xref">RFC5280</a>]</span>) or forbid subordinate CAs entirely. Relying parties SHOULD enforce these policies as part of certification path validation.<a href="#section-12.9-2" class="pilcrow">¶</a></p>
 <p id="section-12.9-3">Monitors SHOULD monitor for adherence to applicable policies as part of monitoring for unauthorized certificates. For example, a monitor that looks for entries covering <code>example.com</code> SHOULD look for either a subject alternative name (<span><a href="https://rfc-editor.org/rfc/rfc5280#section-4.2.1.6" class="relref">Section 4.2.1.6</a> of [<a href="#RFC5280" class="cite xref">RFC5280</a>]</span>) of <code>example.com</code> or a basic constraints (<span><a href="https://rfc-editor.org/rfc/rfc5280#section-4.2.1.9" class="relref">Section 4.2.1.9</a> of [<a href="#RFC5280" class="cite xref">RFC5280</a>]</span>) extension with the cA boolean set to true.<a href="#section-12.9-3" class="pilcrow">¶</a></p>
 <p id="section-12.9-4">It is not sufficient to constrain the MTC CA with a path length constraint (<span><a href="https://rfc-editor.org/rfc/rfc5280#section-4.2.1.9" class="relref">Section 4.2.1.9</a> of [<a href="#RFC5280" class="cite xref">RFC5280</a>]</span>) of zero. Self-issued certificates do not contribute to path length constraints, so such an MTC CA might still issue CA certificates with the same name as itself.<a href="#section-12.9-4" class="pilcrow">¶</a></p>
 </section>

subca-bypass/draft-ietf-plants-merkle-tree-certs.txt

@@ -3203,8 +3203,8 @@ Table of Contents
    that prevent these bypasses.  For example, a relying party might
    require that all subordinate CAs have name constraints
    (Section 4.2.1.10 of [RFC5280]) or forbid subordinate CAs entirely.
-   Relying parties MAY enforce these policies as part of certification
-   path validation.
+   Relying parties SHOULD enforce these policies as part of
+   certification path validation.
 
    Monitors SHOULD monitor for adherence to applicable policies as part
    of monitoring for unauthorized certificates.  For example, a monitor