Script updating gh-pages from 0e26a0a. [ci skip]

Author: ID Bot

bas/andy-clarity-improvements/draft-ietf-plants-merkle-tree-certs.html

@@ -4886,7 +4886,7 @@ <h3 id="name-authenticity">
         <h3 id="name-transparency">
 <a href="#section-12.2" class="section-number selfRef">12.2. </a><a href="#name-transparency" class="section-name selfRef">Transparency</a>
         </h3>
-<p id="section-12.2-1">The transparency mechanisms in this document do not prevent a CA from issuing an unauthorized certificate. Rather, they provide comparable security properties as Certificate Transparency <span>[<a href="#RFC9162" class="cite xref">RFC9162</a>]</span> in ensuring that all certificates are either rejected by relying parties, or visible to monitors.<a href="#section-12.2-1" class="pilcrow">¶</a></p>
+<p id="section-12.2-1">The transparency mechanisms in this document do not prevent a CA from issuing an unauthorized certificate. Rather, they provide comparable security properties as Certificate Transparency <span>[<a href="#RFC9162" class="cite xref">RFC9162</a>]</span> in ensuring that all certificates are either rejected by relying parties, or visible to monitors and, in particular, the subject of the certificate.<a href="#section-12.2-1" class="pilcrow">¶</a></p>
 <p id="section-12.2-2">Compared to Certificate Transparency, some of the responsibilities of a log have moved to the CA. All signatures generated by the CA in this system are assertions about some view of the CA's issuance log. However, a CA does not need to function correctly to ensure transparency properties. Relying parties are expected to require a quorum of additional cosigners, which together enforce properties of the log (<a href="#trusted-cosigners" class="auto internal xref">Section 7.3</a>) and prevent or detect CA misbehavior:<a href="#section-12.2-2" class="pilcrow">¶</a></p>
 <p id="section-12.2-3">A CA might violate the append-only property of its log and present different views to different parties. However, each individual cosigner will only follow a single append-only view of the log history. Provided the cosigners are correctly operated, relying parties and monitors will observe consistent views. Views that were not cosigned at all may not be detected, but they also will not be accepted by relying parties.<a href="#section-12.2-3" class="pilcrow">¶</a></p>
 <p id="section-12.2-4">If the CA sends one view to some cosigners and another view to other cosigners, it is possible that multiple views will be accepted by relying parties. However, in that case monitors will observe that cosigners do not match each other. Relying parties can then react by revoking the inconsistent indices (<a href="#revocation-by-index" class="auto internal xref">Section 7.5</a>), and likely removing the CA. If the cosigners are mirrors, the underlying entries in both views will also be visible.<a href="#section-12.2-4" class="pilcrow">¶</a></p>

bas/andy-clarity-improvements/draft-ietf-plants-merkle-tree-certs.txt

@@ -2605,7 +2605,8 @@ Table of Contents
    issuing an unauthorized certificate.  Rather, they provide comparable
    security properties as Certificate Transparency [RFC9162] in ensuring
    that all certificates are either rejected by relying parties, or
-   visible to monitors.
+   visible to monitors and, in particular, the subject of the
+   certificate.
 
    Compared to Certificate Transparency, some of the responsibilities of
    a log have moved to the CA.  All signatures generated by the CA in