Script updating gh-pages from 739f0e3. [ci skip]

Author: ID Bot

lvalenta/rename-landmark/draft-davidben-tls-merkle-tree-certs.html

@@ -2905,7 +2905,7 @@ <h4 id="name-landmarks">
 <p id="section-6.3.1-6">Landmarks determine <em>landmark subtrees</em>: for each landmark, other than number zero, let <code>tree_size</code> be the landmark's tree size and <code>prev_tree_size</code> be that of the previous landmark. As described in <a href="#arbitrary-intervals" class="auto internal xref">Section 4.4</a>, select the one or two subtrees that cover <code>[prev_tree_size, tree_size)</code>. Each of those subtrees is a landmark subtree.<a href="#section-6.3.1-6" class="pilcrow">¶</a></p>
 <p id="section-6.3.1-7">The most recent <code>max_landmarks</code> landmarks are said to be <em>active</em>. Landmarks MUST be allocated such that, at any given time, only active landmarks contain unexpired certificates. The active landmark subtrees are those determined by the active landmarks. There are at most <code>2 * max_landmarks</code> active landmark subtrees at any time. Every unexpired entry will be contained in one or more landmark subtree, or between the last landmark subtree and the latest checkpoint. Active landmark subtrees are predistributed to the relying party as trusted subtrees, as described in <a href="#trusted-subtrees" class="auto internal xref">Section 7.4</a>.<a href="#section-6.3.1-7" class="pilcrow">¶</a></p>
 <p id="section-6.3.1-8">If landmarks are allocated incorrectly (e.g. past landmarks change, or <code>max_landmarks</code> is inaccurate), there are no security consequences, but some older certificates may fail to validate.<a href="#section-6.3.1-8" class="pilcrow">¶</a></p>
-<p id="section-6.3.1-9">It is RECOMMENDED that landmarks be allocated by picking some <code>time_between_landmarks</code> interval, and then appending the latest checkpoint tree size (although any size less or equal to the latest checkpoint tree size is valid) to the sequence, once per interval. If the latest checkpoint tree size is already a landmark, the interval is skipped. <code>max_landmarks</code> can then be set to <code>ceil(max_cert_lifetime / time_between_landmarks)</code>, where <code>max_cert_lifetime</code> is the CA's maximum certificate lifetime. Allocations do not need to be precise, as long as <code>max_landmarks</code> is accurate.<a href="#section-6.3.1-9" class="pilcrow">¶</a></p>
+<p id="section-6.3.1-9">It is RECOMMENDED that landmarks be allocated by picking some <code>time_between_landmarks</code> interval, and then appending the latest checkpoint tree size to the sequence, once per interval. If the latest checkpoint tree size is already a landmark, the interval is skipped. <code>max_landmarks</code> can then be set to <code>ceil(max_cert_lifetime / time_between_landmarks)</code>, where <code>max_cert_lifetime</code> is the CA's maximum certificate lifetime. Allocations do not need to be precise, as long as <code>max_landmarks</code> is accurate.<a href="#section-6.3.1-9" class="pilcrow">¶</a></p>
 <p id="section-6.3.1-10">Relying parties will locally retain up to <code>2 * max_landmarks</code> hashes (<a href="#trusted-subtrees" class="auto internal xref">Section 7.4</a>) per CA, so <code>max_landmarks</code> should be set to balance the delay between landmarks and the amount of state the relying party must maintain. Using the recommended procedure above, a CA with a maximum certificate lifetime of 7 days, allocating a landmark every hour, will have a <code>max_landmarks</code> of 168. The client state is then 336 hashes, or 10,752 bytes with SHA-256.<a href="#section-6.3.1-10" class="pilcrow">¶</a></p>
 <p id="section-6.3.1-11"><code>landmark_url</code> MUST serve a resource with <code>Content-Type: text/plain; charset=utf-8</code> and the following lines. Each line MUST be terminated by a newline character (U+000A):<a href="#section-6.3.1-11" class="pilcrow">¶</a></p>
 <ul class="normal">

lvalenta/rename-landmark/draft-davidben-tls-merkle-tree-certs.txt

@@ -1351,14 +1351,12 @@ Table of Contents
 
    It is RECOMMENDED that landmarks be allocated by picking some
    time_between_landmarks interval, and then appending the latest
-   checkpoint tree size (although any size less or equal to the latest
-   checkpoint tree size is valid) to the sequence, once per interval.
-   If the latest checkpoint tree size is already a landmark, the
-   interval is skipped. max_landmarks can then be set to
-   ceil(max_cert_lifetime / time_between_landmarks), where
-   max_cert_lifetime is the CA's maximum certificate lifetime.
-   Allocations do not need to be precise, as long as max_landmarks is
-   accurate.
+   checkpoint tree size to the sequence, once per interval.  If the
+   latest checkpoint tree size is already a landmark, the interval is
+   skipped. max_landmarks can then be set to ceil(max_cert_lifetime /
+   time_between_landmarks), where max_cert_lifetime is the CA's maximum
+   certificate lifetime.  Allocations do not need to be precise, as long
+   as max_landmarks is accurate.
 
    Relying parties will locally retain up to 2 * max_landmarks hashes
    (Section 7.4) per CA, so max_landmarks should be set to balance the