Script updating gh-pages from 96de61e. [ci skip]

Author: ID Bot

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

@@ -4773,7 +4773,7 @@ <h4 id="name-certification-authority-cost">
           </h4>
 <p id="section-10.1.1-1">While Merkle Tree certificates expect CAs to operate logs, the costs of these logs are expected to be much lower than a CT log from <span>[<a href="#RFC6962" class="cite xref">RFC6962</a>]</span> or <span>[<a href="#RFC9162" class="cite xref">RFC9162</a>]</span>:<a href="#section-10.1.1-1" class="pilcrow">¶</a></p>
 <p id="section-10.1.1-2"><a href="#publishing-logs" class="auto internal xref">Section 5.6</a> does not constrain the API to the one defined in <span>[<a href="#RFC6962" class="cite xref">RFC6962</a>]</span> or <span>[<a href="#RFC9162" class="cite xref">RFC9162</a>]</span>. If the PKI uses a tile-based protocol, such as <span>[<a href="#TLOG-TILES" class="cite xref">TLOG-TILES</a>]</span>, the issuance log benefits from the improved caching properties of such designs.<a href="#section-10.1.1-2" class="pilcrow">¶</a></p>
-<p id="section-10.1.1-3">Unlike a CT log, an issuance log does not have public submission APIs. Log entries are only added by the CA directly. The costs are thus expected to scale with the CA's own operations.<a href="#section-10.1.1-3" class="pilcrow">¶</a></p>
+<p id="section-10.1.1-3">Unlike a CT log, an issuance log does not have public submission APIs. Log entries are only added by the CA directly. Costs are thus expected to scale with the CA's own issuance.<a href="#section-10.1.1-3" class="pilcrow">¶</a></p>
 <p id="section-10.1.1-4">A CA only needs to produce a digital signature for every checkpoint, rather than for every certificate. The lower signature rate requirements could allow more secure and/or economical key storage choices.<a href="#section-10.1.1-4" class="pilcrow">¶</a></p>
 <p id="section-10.1.1-5">Individual entries are kept small and do not scale with public key or signature sizes. This mitigates growth from post-quantum algorithms. Public keys in entries are replaced with fixed-sized hashes. There are no signatures in entries themselves, and only signatures on the very latest checkpoint are retained. Every new checkpoint completely subsumes the old checkpoint, so there is no need to retain older signatures. Likewise, a subtree is only signed if contained in another signed checkpoint.<a href="#section-10.1.1-5" class="pilcrow">¶</a></p>
 <p id="section-10.1.1-6">Log pruning (<a href="#log-pruning" class="auto internal xref">Section 5.6.1</a>) allows a long-lived log to serve only the more recent entries, scaling with the size of the retention window, rather than the log's total lifetime.<a href="#section-10.1.1-6" class="pilcrow">¶</a></p>
@@ -4786,7 +4786,7 @@ <h4 id="name-cosigner-costs">
 <a href="#section-10.1.2" class="section-number selfRef">10.1.2. </a><a href="#name-cosigner-costs" class="section-name selfRef">Cosigner Costs</a>
           </h4>
 <p id="section-10.1.2-1">The costs of cosigners vary by cosigner role. A consistency-checking cosigner, such as <span>[<a href="#TLOG-WITNESS" class="cite xref">TLOG-WITNESS</a>]</span>, requires very little state and can be run with low cost.<a href="#section-10.1.2-1" class="pilcrow">¶</a></p>
-<p id="section-10.1.2-2">A mirroring cosigner, such as <span>[<a href="#TLOG-MIRROR" class="cite xref">TLOG-MIRROR</a>]</span>, performs a role comparable to CT logs, but several of the cost-saving properties in <a href="#certification-authority-costs" class="auto internal xref">Section 10.1.1</a> also apply: improved protocols, smaller entries, less frequent signatures, and log pruning. While a mirror does need to accommodate another party's (the CA's) growth rate, it grows only from new issuances from that one CA. If one CA's issuance rate exceeds the mirror's capacity, that does not impact the mirror's copies of other CAs. Mirrors also do not need to defend against a client uploading a large number of existing certificates all at once. Submissions are also naturally batched and serialized.<a href="#section-10.1.2-2" class="pilcrow">¶</a></p>
+<p id="section-10.1.2-2">A mirroring cosigner, such as <span>[<a href="#TLOG-MIRROR" class="cite xref">TLOG-MIRROR</a>]</span>, performs a role comparable to CT logs, but several of the cost-saving properties in <a href="#certification-authority-costs" class="auto internal xref">Section 10.1.1</a> also apply: improved protocols, smaller entries, less frequent signatures, and log pruning. While a mirror does need to accommodate another party's (the CA's) growth rate, it grows only from new issuances from that one CA. If one CA's issuance rate exceeds the mirror's capacity, that does not impact the mirror's copies of other CAs. Mirrors also do not need to defend against a client uploading a large number of existing certificates all at once. Submissions are naturally batched and serialized.<a href="#section-10.1.2-2" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="monitor-costs">
@@ -4807,7 +4807,7 @@ <h3 id="name-choosing-cosigners">
         </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 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-3">Relying parties that require larger quorums of trusted cosigners can reduce the trust placed in any individual cosigner. However, larger quorums result in larger, more expensive full certificates. The cost of full certificates 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>
 </div>
@@ -4817,7 +4817,7 @@ <h3 id="name-log-availability">
 <a href="#section-10.3" class="section-number selfRef">10.3. </a><a href="#name-log-availability" class="section-name selfRef">Log Availability</a>
         </h3>
 <p id="section-10.3-1">CAs and mirrors are expected to serve their log contents over HTTP. It is possible for the contents to be unavailable, either due to temporary service outage or because the log has been pruned (<a href="#log-pruning" class="auto internal xref">Section 5.6.1</a>). If some resources are unavailable, they may not be visible to monitors.<a href="#section-10.3-1" class="pilcrow">¶</a></p>
-<p id="section-10.3-2">As in CT, PKIs that deploy Merkle Tree certificates SHOULD establish availability policies, adhered to by trusted CAs and mirrors, and enforced by relying party vendors as a condition of trust. Exact availability policies for these services are out of scope for this document, but this section provides some general guidance.<a href="#section-10.3-2" class="pilcrow">¶</a></p>
+<p id="section-10.3-2">As in CT, PKIs that deploy Merkle Tree certificates SHOULD establish availability policies. These policies SHOULD be adhered to by trusted CAs and mirrors, and enforced by relying party vendors as a condition of trust. Exact availability policies for these services are out of scope for this document, but this section provides some general guidance.<a href="#section-10.3-2" class="pilcrow">¶</a></p>
 <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>

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

@@ -2342,8 +2342,8 @@ Table of Contents
    properties of such designs.
 
    Unlike a CT log, an issuance log does not have public submission
-   APIs.  Log entries are only added by the CA directly.  The costs are
-   thus expected to scale with the CA's own operations.
+   APIs.  Log entries are only added by the CA directly.  Costs are thus
+   expected to scale with the CA's own issuance.
 
    A CA only needs to produce a digital signature for every checkpoint,
    rather than for every certificate.  The lower signature rate
@@ -2384,7 +2384,7 @@ Table of Contents
    exceeds the mirror's capacity, that does not impact the mirror's
    copies of other CAs.  Mirrors also do not need to defend against a
    client uploading a large number of existing certificates all at once.
-   Submissions are also naturally batched and serialized.
+   Submissions are naturally batched and serialized.
 
 10.1.3.  Monitor Costs
 
@@ -2418,9 +2418,9 @@ Table of Contents
    be appropriate in PKIs where running CT logs is already viable.
 
    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
+   reduce the trust placed in any individual cosigner.  However, larger
+   quorums result in larger, more expensive full certificates.  The cost
+   of full certificates 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.
@@ -2446,10 +2446,11 @@ Table of Contents
    visible to monitors.
 
    As in CT, PKIs that deploy Merkle Tree certificates SHOULD establish
-   availability policies, adhered to by trusted CAs and mirrors, and
-   enforced by relying party vendors as a condition of trust.  Exact
-   availability policies for these services are out of scope for this
-   document, but this section provides some general guidance.
+   availability policies.  These policies SHOULD be adhered to by
+   trusted CAs and mirrors, and enforced by relying party vendors as a
+   condition of trust.  Exact availability policies for these services
+   are out of scope for this document, but this section provides some
+   general guidance.
 
    Availability policies SHOULD specify how long an entry must be made
    available, before a CA or mirror is permitted to prune the entry.  It

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>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-sentence-splitting/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="bas/andy-grammar-fixes">bas/andy-grammar-fixes</a></h2>