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

Author: ID Bot

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

@@ -1050,7 +1050,7 @@
 </tr></thead>
 <tfoot><tr>
 <td class="left">Benjamin, et al.</td>
-<td class="center">Expires 5 December 2026</td>
+<td class="center">Expires 6 December 2026</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
 </table>
@@ -1063,12 +1063,12 @@
 <dd class="internet-draft">draft-ietf-plants-merkle-tree-certs-latest</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2026-06-03" class="published">3 June 2026</time>
+<time datetime="2026-06-04" class="published">4 June 2026</time>
     </dd>
 <dt class="label-intended-status">Intended Status:</dt>
 <dd class="intended-status">Standards Track</dd>
 <dt class="label-expires">Expires:</dt>
-<dd class="expires"><time datetime="2026-12-05">5 December 2026</time></dd>
+<dd class="expires"><time datetime="2026-12-06">6 December 2026</time></dd>
 <dt class="label-authors">Authors:</dt>
 <dd class="authors">
 <div class="author">
@@ -1134,7 +1134,7 @@ <h2 id="name-status-of-this-memo">
         time. It is inappropriate to use Internet-Drafts as reference
         material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
 <p id="section-boilerplate.1-4">
-        This Internet-Draft will expire on 5 December 2026.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+        This Internet-Draft will expire on 6 December 2026.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="copyright">
@@ -5315,10 +5315,11 @@ <h3 id="name-signature-domain-separation">
         <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 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>
+<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 subordinate CA certificate that enables this 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">Although the scope is larger, this scenario is similar to an unauthorized end-entity certificate and can be handled analogously:<a href="#section-12.9-2" class="pilcrow">¶</a></p>
+<p id="section-12.9-3">Relying parties with transparency requirements SHOULD define policy requirements on trusted CAs that prevent these bypasses, with any violation treated as an unauthorized certificate. 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. In addition to holding CAs responsible for meeting these policies, relying parties SHOULD programmatically enforce these policies as part of certification path validation.<a href="#section-12.9-3" class="pilcrow">¶</a></p>
+<p id="section-12.9-4">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-4" class="pilcrow">¶</a></p>
+<p id="section-12.9-5">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-5" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>

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

@@ -5,13 +5,13 @@
 PKI, Logs, And Tree Signatures                               D. Benjamin
 Internet-Draft                                                Google LLC
 Intended status: Standards Track                              D. O'Brien
-Expires: 5 December 2026                                      Apple Inc.
+Expires: 6 December 2026                                      Apple Inc.
                                                         B. E. Westerbaan
                                                               L. Valenta
                                                               Cloudflare
                                                              F. Valsorda
                                                                   Geomys
-                                                             3 June 2026
+                                                             4 June 2026
 
 
                         Merkle Tree Certificates
@@ -63,7 +63,7 @@ Status of This Memo
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on 5 December 2026.
+   This Internet-Draft will expire on 6 December 2026.
 
 Copyright Notice
 
@@ -3196,15 +3196,20 @@ Table of Contents
    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.
-
-   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
-   (Section 4.2.1.10 of [RFC5280]) or forbid subordinate CAs entirely.
-   Relying parties SHOULD enforce these policies as part of
-   certification path validation.
+   visible to monitors.  However, the subordinate CA certificate that
+   enables this bypass will still be visible in the issuance logs.
+
+   Although the scope is larger, this scenario is similar to an
+   unauthorized end-entity certificate and can be handled analogously:
+
+   Relying parties with transparency requirements SHOULD define policy
+   requirements on trusted CAs that prevent these bypasses, with any
+   violation treated as an unauthorized certificate.  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.  In addition to holding CAs responsible for meeting these
+   policies, relying parties SHOULD programmatically 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