Script updating gh-pages from 2d35380. [ci skip]

Author: ID Bot

draft-ietf-plants-merkle-tree-certs.html

@@ -4794,7 +4794,7 @@ <h4 id="name-cosigner-costs">
           <h4 id="name-monitor-costs">
 <a href="#section-10.1.3" class="section-number selfRef">10.1.3. </a><a href="#name-monitor-costs" class="section-name selfRef">Monitor Costs</a>
           </h4>
-<p id="section-10.1.3-1">In a CT-based PKI, every log carries a potentially distinct subset of active certificates, so monitors must check the contents of every CT log. At the same time, certificates are commonly synchronized between CT logs. As a result, a monitor will typically download each certificate multiple times, once for every log. In Merkle Tree Certificates, each entry appears in exactly one log. A relying party might require a log to be covered by a quorum of mirrors, but each mirror is cryptographically verified to serve the same contents. Once a monitor has obtained some entry from one mirror, it does not need to download it from the others.<a href="#section-10.1.3-1" class="pilcrow">¶</a></p>
+<p id="section-10.1.3-1">In a CT-based PKI, every log carries a potentially distinct subset of active certificates. Monitors must check the contents of every CT log. At the same time, certificates are commonly synchronized between CT logs. As a result, a monitor will typically download each certificate multiple times, once for every log. In Merkle Tree Certificates, each entry appears in exactly one log. A relying party might require a log to be covered by a quorum of mirrors, but each mirror is cryptographically verified to serve the same contents. Once a monitor has obtained some entry from one mirror, it does not need to download it from the others.<a href="#section-10.1.3-1" class="pilcrow">¶</a></p>
 <p id="section-10.1.3-2">In addition to downloading each entry only once, the entries themselves are smaller, as discussed in <a href="#certification-authority-costs" class="auto internal xref">Section 10.1.1</a>.<a href="#section-10.1.3-2" class="pilcrow">¶</a></p>
 </section>
 </div>
@@ -4806,7 +4806,7 @@ <h3 id="name-choosing-cosigners">
 <a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-choosing-cosigners" class="section-name selfRef">Choosing Cosigners</a>
         </h3>
 <p id="section-10.2-1">In selecting trusted cosigners and cosigner requirements (<a href="#trusted-cosigners" class="auto internal xref">Section 7.3</a>), relying parties navigate a number of trade-offs:<a href="#section-10.2-1" class="pilcrow">¶</a></p>
-<p id="section-10.2-2">A consistency-checking cosigner, such as <span>[<a href="#TLOG-WITNESS" class="cite xref">TLOG-WITNESS</a>]</span>, is very cheap to run, but does not guarantee durable logging, while a mirroring cosigner is more expensive and may take longer to cosign structures. Requiring a mirror signature provides stronger guarantees to the relying party, which in turn can reduce the requirements on CAs (see <a href="#log-availability" class="auto internal xref">Section 10.3</a>), however it may cause certificate issuance to take longer. That said, mirrors are comparable to CT logs, if not cheaper (see <a href="#operational-costs" class="auto internal xref">Section 10.1</a>), so they may be appropriate in PKIs where running CT logs is already viable.<a href="#section-10.2-2" class="pilcrow">¶</a></p>
+<p id="section-10.2-2">A consistency-checking cosigner, such as <span>[<a href="#TLOG-WITNESS" class="cite xref">TLOG-WITNESS</a>]</span>, is inexpensive to run, but does not guarantee durable logging. A mirroring cosigner is more expensive and may take longer to cosign structures. Requiring a mirror signature provides stronger guarantees to the relying party, which in turn can reduce the requirements on CAs (see <a href="#log-availability" class="auto internal xref">Section 10.3</a>), however it may cause certificate issuance to take longer. That said, mirrors are comparable to CT logs, if not cheaper (see <a href="#operational-costs" class="auto internal xref">Section 10.1</a>), so they may be appropriate in PKIs where running CT logs is already viable.<a href="#section-10.2-2" class="pilcrow">¶</a></p>
 <p id="section-10.2-3">Relying parties that require larger quorums of trusted cosigners can reduce the trust placed in any individual cosigner. However, these larger quorums result in larger, more expensive full certificates. The cost of this will depend on how frequently the signatureless optimization occurs in a given PKI. Conversely, relying parties that require smaller quorums have smaller full certificates, but place more trust in their cosigners.<a href="#section-10.2-3" class="pilcrow">¶</a></p>
 <p id="section-10.2-4">Relying party policies also impact monitor operation. If a relying party accepts any one of three cosigners, monitors SHOULD check the checkpoints of all three. Otherwise, a malicious CA may send different split views to different cosigners. More generally, monitors SHOULD check the checkpoints in the union of all cosigners trusted by all supported relying parties. This is an efficient check because, if the CA is operating correctly, all cosigners will observe the same tree. Thus the monitor only needs to check consistency proofs between the checkpoints, and check the log contents themselves once. Monitors MAY also rely on other parties in the transparency ecosystem to perform this check.<a href="#section-10.2-4" class="pilcrow">¶</a></p>
 </section>
@@ -4821,7 +4821,7 @@ <h3 id="name-log-availability">
 <p id="section-10.3-3">Availability policies SHOULD specify how long an entry must be made available, before a CA or mirror is permitted to prune the entry. It is RECOMMENDED to define this using a <em>retention period</em>, which is some time after the entry has expired. In such a policy, an entry could only be pruned if it, and all preceding entries, have already expired for the retention period. Policies MAY opt to set different retention periods between CAs and mirrors. Permitting limited log retention is analogous to the CT practice of temporal sharding <span>[<a href="#CHROME-CT" class="cite xref">CHROME-CT</a>]</span>, except that a pruned issuance log remains compatible with older, unupdated relying parties.<a href="#section-10.3-3" class="pilcrow">¶</a></p>
 <p id="section-10.3-4">Such policies impact monitors. If the retention period is, e.g. 6 months, this means that monitors are expected to check entries of interest within 6 months. It also means that a new monitor may only be aware of a 6 month history of entries issued for a particular domain.<a href="#section-10.3-4" class="pilcrow">¶</a></p>
 <p id="section-10.3-5">If historical data is not available to verify the retention period, such as information in another mirror or a trusted summary of expiration dates of entries, it may not be possible to confirm correct behavior. This is mitigated by the revocation process described in <a href="#revocation-by-index" class="auto internal xref">Section 7.5</a>: if a CA were to prune a forward-dated entry and, in the 6 months when the entry was available, no monitor noticed the unusual expiry, an updated relying party would not accept it anyway.<a href="#section-10.3-5" class="pilcrow">¶</a></p>
-<p id="section-10.3-6">The log pruning process simply makes some resources unavailable, so availability policies SHOULD constrain log pruning in the same way as general resource availability. That is, if it would be a policy violation for the log to fail to serve a resource, it should also be a policy violation for the log to prune such that the resource is removed, and vice versa.<a href="#section-10.3-6" class="pilcrow">¶</a></p>
+<p id="section-10.3-6">The log pruning process simply makes some resources unavailable. Availability policies SHOULD constrain log pruning in the same way as general resource availability. That is, if it would be a policy violation for the log to fail to serve a resource, it should also be a policy violation for the log to prune such that the resource is removed, and vice versa.<a href="#section-10.3-6" class="pilcrow">¶</a></p>
 <p id="section-10.3-7">PKIs that require mirror cosignatures (<a href="#trusted-cosigners" class="auto internal xref">Section 7.3</a>) can impose minimal to no availability requirements on CAs without compromising transparency goals. If a CA never makes an entry available, mirrors will be unable to update. This will prevent relying parties from accepting the undisclosed entries. However, a CA that is persistently unavailable may not offer sufficient benefit to be used by authenticating parties or trusted by relying parties.<a href="#section-10.3-7" class="pilcrow">¶</a></p>
 <p id="section-10.3-8">However, if a mirror's interface becomes unavailable, monitors may be unable to check for unauthorized issuance, if the entries are not available in another mirror. This does compromise transparency goals. As such, availability policies SHOULD set availability expectations on mirrors. This can also be mitigated by using multiple mirrors, either directly enforced in cosigner requirements, or by keeping mirrors up-to-date with each other.<a href="#section-10.3-8" class="pilcrow">¶</a></p>
 <p id="section-10.3-9">In PKIs that do not require mirroring cosigners, the CA's serving endpoint is more crucial for monitors. Such PKIs SHOULD set availability requirements on CAs.<a href="#section-10.3-9" class="pilcrow">¶</a></p>

draft-ietf-plants-merkle-tree-certs.txt

@@ -2389,7 +2389,7 @@ Table of Contents
 10.1.3.  Monitor Costs
 
    In a CT-based PKI, every log carries a potentially distinct subset of
-   active certificates, so monitors must check the contents of every CT
+   active certificates.  Monitors must check the contents of every CT
    log.  At the same time, certificates are commonly synchronized
    between CT logs.  As a result, a monitor will typically download each
    certificate multiple times, once for every log.  In Merkle Tree
@@ -2407,8 +2407,8 @@ Table of Contents
    In selecting trusted cosigners and cosigner requirements
    (Section 7.3), relying parties navigate a number of trade-offs:
 
-   A consistency-checking cosigner, such as [TLOG-WITNESS], is very
-   cheap to run, but does not guarantee durable logging, while a
+   A consistency-checking cosigner, such as [TLOG-WITNESS], is
+   inexpensive to run, but does not guarantee durable logging.  A
    mirroring cosigner is more expensive and may take longer to cosign
    structures.  Requiring a mirror signature provides stronger
    guarantees to the relying party, which in turn can reduce the
@@ -2477,8 +2477,8 @@ Table of Contents
    the unusual expiry, an updated relying party would not accept it
    anyway.
 
-   The log pruning process simply makes some resources unavailable, so
-   availability policies SHOULD constrain log pruning in the same way as
+   The log pruning process simply makes some resources unavailable.
+   Availability policies SHOULD constrain log pruning in the same way as
    general resource availability.  That is, if it would be a policy
    violation for the log to fail to serve a resource, it should also be
    a policy violation for the log to prune such that the resource is

index.html

@@ -79,7 +79,7 @@ <h2>Preview for branch <a href="bas/andy-sentence-splitting">bas/andy-sentence-s
                   <tr>
                     <td><a href="bas/andy-sentence-splitting/draft-ietf-plants-merkle-tree-certs.html" class="html draft-ietf-plants-merkle-tree-certs" title="Merkle Tree Certificates (HTML)">Merkle Tree Certificates</a></td>
                     <td><a href="bas/andy-sentence-splitting/draft-ietf-plants-merkle-tree-certs.txt" class="txt draft-ietf-plants-merkle-tree-certs" title="Merkle Tree Certificates (Text)">plain text</a></td>
-                    <td><a href="https://author-tools.ietf.org/api/iddiff?url_1=https://davidben.github.io/merkle-tree-certs/draft-ietf-plants-merkle-tree-certs.txt&amp;url_2=https://davidben.github.io/merkle-tree-certs/bas/andy-sentence-splitting/draft-ietf-plants-merkle-tree-certs.txt" class="diff draft-ietf-plants-merkle-tree-certs">diff with main</a></td>
+                    <td>same as main</td>
                   </tr>
                 </table>
                 <h2>Preview for branch <a href="bas/andy-grammar-fixes">bas/andy-grammar-fixes</a></h2>
@@ -95,7 +95,7 @@ <h2>Preview for branch <a href="bas/andy-editorial-tightening">bas/andy-editoria
                   <tr>
                     <td><a href="bas/andy-editorial-tightening/draft-ietf-plants-merkle-tree-certs.html" class="html draft-ietf-plants-merkle-tree-certs" title="Merkle Tree Certificates (HTML)">Merkle Tree Certificates</a></td>
                     <td><a href="bas/andy-editorial-tightening/draft-ietf-plants-merkle-tree-certs.txt" class="txt draft-ietf-plants-merkle-tree-certs" title="Merkle Tree Certificates (Text)">plain text</a></td>
-                    <td>same as main</td>
+                    <td><a href="https://author-tools.ietf.org/api/iddiff?url_1=https://davidben.github.io/merkle-tree-certs/draft-ietf-plants-merkle-tree-certs.txt&amp;url_2=https://davidben.github.io/merkle-tree-certs/bas/andy-editorial-tightening/draft-ietf-plants-merkle-tree-certs.txt" class="diff draft-ietf-plants-merkle-tree-certs">diff with main</a></td>
                   </tr>
                 </table>
                 <h2>Preview for branch <a href="rename-cert-types">rename-cert-types</a></h2>