Script updating gh-pages from 545b71f. [ci skip]

Author: ID Bot

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

@@ -3854,7 +3854,7 @@ <h3 id="name-issuance-logs">
 </li>
         </ul>
 <p id="section-5.2-4">A log ID specifies both the CA and the log number in a single ID.<a href="#section-5.2-4" class="pilcrow">¶</a></p>
-<p id="section-5.2-5">Each issuance log describes an append-only sequence of <em>entries</em> (<a href="#log-entries" class="auto internal xref">Section 5.2.1</a>), identified consecutively by an index value, starting from zero. Each entry is an assertion that the CA has certified. The entries in the issuance log are represented as a Merkle Tree, described in <span><a href="https://rfc-editor.org/rfc/rfc9162#section-2.1" class="relref">Section 2.1</a> of [<a href="#RFC9162" class="cite xref">RFC9162</a>]</span>.<a href="#section-5.2-5" class="pilcrow">¶</a></p>
+<p id="section-5.2-5">Each issuance log describes an append-only sequence of <em>entries</em> (<a href="#log-entries" class="auto internal xref">Section 5.2.1</a>). Each entry is identified by an integer <em>index</em>, assigned consecutively starting from zero. Indices are at most 2<sup>48</sup>-1. Each entry is an assertion that the CA has certified. The entries in the issuance log are represented as a Merkle Tree, described in <span><a href="https://rfc-editor.org/rfc/rfc9162#section-2.1" class="relref">Section 2.1</a> of [<a href="#RFC9162" class="cite xref">RFC9162</a>]</span>.<a href="#section-5.2-5" class="pilcrow">¶</a></p>
 <p id="section-5.2-6">Each log additionally maintains a <em>minimum index</em> value, which is the index of the first log entry which is available. See <a href="#log-pruning" class="auto internal xref">Section 5.2.3</a>. This value changes over the lifetime of the log.<a href="#section-5.2-6" class="pilcrow">¶</a></p>
 <p id="section-5.2-7">Unlike <span>[<a href="#RFC6962" class="cite xref">RFC6962</a>]</span> and <span>[<a href="#RFC9162" class="cite xref">RFC9162</a>]</span>, an issuance log does not have a public submission interface. The log only contains entries which the log operator, i.e. the CA, chose to add. As entries are added, the Merkle Tree is updated to be computed over the new sequence.<a href="#section-5.2-7" class="pilcrow">¶</a></p>
 <p id="section-5.2-8">A snapshot of the log is known as a <em>checkpoint</em>. A checkpoint is identified by its <em>tree size</em>, that is the number of elements committed to the log at the time. Its contents can be described by the Merkle Tree Hash (<span><a href="https://rfc-editor.org/rfc/rfc9162#section-2.1.1" class="relref">Section 2.1.1</a> of [<a href="#RFC9162" class="cite xref">RFC9162</a>]</span>) of entries zero through <code>tree_size - 1</code>.<a href="#section-5.2-8" class="pilcrow">¶</a></p>
@@ -4466,10 +4466,14 @@ <h3 id="name-representing-certification-">
 -- From draft-ietf-tls-trust-anchor-ids
 TrustAnchorID ::= RELATIVE-OID
 
+-- This is 2^64-1, the maximum possible serial number in this protocol.
+mtcMaxSerial INTEGER ::= 18446744073709551615
+
 MTCCertificationAuthority ::= SEQUENCE {
     logHash   AlgorithmIdentifier{DIGEST-ALGORITHM, {...}},
     sigAlg    AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}},
-    minSerial INTEGER
+    minSerial INTEGER (0..mtcMaxSerial),
+    maxSerial INTEGER (0..mtcMaxSerial)
 }
 </pre><a href="#section-5.5-6" class="pilcrow">¶</a>
 </div>
@@ -4483,7 +4487,7 @@ <h3 id="name-representing-certification-">
             <p id="section-5.5-9.2.1"><code>sigAlg</code> is the CA cosigner's signature algorithm (<a href="#signature-algorithms" class="auto internal xref">Section 5.3.3</a>).<a href="#section-5.5-9.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-5.5-9.3">
-            <p id="section-5.5-9.3.1"><code>minSerial</code> is an integer describing the minimum allowed serial number from this CA. Since the serial number encodes both the log number (<a href="#issuance-logs" class="auto internal xref">Section 5.2</a>) and the entry index into a specific log, it can be used to set a minimum allowed log number or a minimum allowed index in a particular log (<a href="#log-pruning" class="auto internal xref">Section 5.2.3</a>).<a href="#section-5.5-9.3.1" class="pilcrow">¶</a></p>
+            <p id="section-5.5-9.3.1"><code>minSerial</code> and <code>maxSerial</code> describe the minimum and maximum allowed serial numbers from this CA, respectively. See <a href="#revoked-ranges" class="auto internal xref">Section 7.5</a> for discussion on setting these values.<a href="#section-5.5-9.3.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 <p id="section-5.5-10">If this extension is present, the key described in <code>subjectPublicKeyInfo</code> is a CA cosigner key and subject to the usage restrictions described in <a href="#certification-authority-cosigners" class="auto internal xref">Section 5.4</a>. In particular, it MUST NOT be used to directly sign TBSCertificate structures.<a href="#section-5.5-10" class="pilcrow">¶</a></p>
@@ -4767,7 +4771,7 @@ <h3 id="name-relying-party-configuration">
             <p id="section-7.1-4.4.1">No trusted subtrees are directly represented by the CA certificate structure, but the relying party MAY incorporate trusted subtrees from out-of-band information.<a href="#section-7.1-4.4.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="section-7.1-4.5">
-            <p id="section-7.1-4.5.1">The revoked serial number ranges include the half-open range <code>[0, minSerial)</code>, but the relying party MAY incorporate additional ranges from out-of-band information.<a href="#section-7.1-4.5.1" class="pilcrow">¶</a></p>
+            <p id="section-7.1-4.5.1">The revoked serial number ranges include the half-open ranges <code>[0, minSerial)</code> and <code>[maxSerial+1, 2^64)</code>, but the relying party MAY incorporate additional ranges from out-of-band information.<a href="#section-7.1-4.5.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 </section>
@@ -4976,10 +4980,11 @@ <h3 id="name-revoked-ranges">
 <a href="#section-7.5" class="section-number selfRef">7.5. </a><a href="#name-revoked-ranges" class="section-name selfRef">Revoked Ranges</a>
         </h3>
 <p id="section-7.5-1">For each supported Merkle Tree CA, the relying party maintains a list of revoked ranges of serial numbers. A serial number combines a log number and a log index. A relying party can thus efficiently revoke both ranges of entries of an issuance log, and ranges of issuance logs, even if the contents are not necessarily known. This may be used to mitigate the security consequences of misbehavior by a CA, or other parties in the ecosystem.<a href="#section-7.5-1" class="pilcrow">¶</a></p>
-<p id="section-7.5-2">When a relying party is first configured to trust an issuance log, it SHOULD be configured to revoke all entries from zero up to but not including the first available unexpired certificate at the time. This revocation SHOULD be periodically updated as entries expire and logs are pruned (<a href="#log-pruning" class="auto internal xref">Section 5.2.3</a>). In particular, when CAs prune entries, relying parties SHOULD be updated to revoke all newly unavailable entries. This gives assurance that, even if some unavailable entry had not yet expired, the relying party will not trust it. It also allows monitors to start monitoring a log without processing expired entries.<a href="#section-7.5-2" class="pilcrow">¶</a></p>
-<p id="section-7.5-3">A misbehaving CA might correctly construct a globally consistent log, but refuse to make some entries or intermediate nodes available. Consistency proofs between checkpoints and subtrees would pass, but monitors cannot observe the entries themselves. Relying parties whose cosigner policies (<a href="#trusted-cosigners" class="auto internal xref">Section 7.3</a>) do not require durable logging (e.g. via <span>[<a href="#TLOG-MIRROR" class="cite xref">TLOG-MIRROR</a>]</span>) are particularly vulnerable to this. In this case, the indices of the missing entries will still be known, so relying parties can use this mechanism to revoke the unknown entries, possibly as an initial, targeted mitigation before complete CA removal.<a href="#section-7.5-3" class="pilcrow">¶</a></p>
-<p id="section-7.5-4">When a CA is found to be untrustworthy, relying parties SHOULD remove trust in that CA. To minimize the compatibility impact of this mitigation, index-based revocation can be used to only distrust entries after some index, while leaving existing entries accepted. This is analogous to the <span>[<a href="#SCTNotAfter" class="cite xref">SCTNotAfter</a>]</span> mechanism used in some PKIs.<a href="#section-7.5-4" class="pilcrow">¶</a></p>
-<p id="section-7.5-5">The revocation mechanism in this section is complementary to certificate-level revocation mechanisms. log entries are uniquely identified by their serial number and issuer, existing revocation mechanisms like CRLs <span>[<a href="#RFC5280" class="cite xref">RFC5280</a>]</span> and OCSP <span>[<a href="#RFC6960" class="cite xref">RFC6960</a>]</span> apply unchanged.<a href="#section-7.5-5" class="pilcrow">¶</a></p>
+<p id="section-7.5-2">When a relying party is first configured to trust an issuance log, it SHOULD be configured to revoke all entries from zero up to but not including the first available unexpired certificate at the time. This revocation SHOULD be periodically updated as entries expire and logs are pruned (<a href="#log-pruning" class="auto internal xref">Section 5.2.3</a>). In particular, when CAs prune entries, relying parties SHOULD be updated to revoke all newly unavailable entries. This gives assurance that, even if some unavailable entry had not yet expired, the relying party will not trust it. It also allows monitors to start monitoring a log without processing expired entries. If using the format defined in <a href="#representing-certification-authorities" class="auto internal xref">Section 5.5</a>, this can be configured with the <code>minSerial</code> value.<a href="#section-7.5-2" class="pilcrow">¶</a></p>
+<p id="section-7.5-3">A relying party with transparency requirements additionally SHOULD revoke all log numbers above some threshold to bound monitoring overhead. If using the format defined in <a href="#representing-certification-authorities" class="auto internal xref">Section 5.5</a>, this can be configured with the <code>maxSerial</code> value. See <a href="#limiting-issuance-logs" class="auto internal xref">Section 12.2.2</a>.<a href="#section-7.5-3" class="pilcrow">¶</a></p>
+<p id="section-7.5-4">A misbehaving CA might correctly construct a globally consistent log, but refuse to make some entries or intermediate nodes available. Consistency proofs between checkpoints and subtrees would pass, but monitors cannot observe the entries themselves. Relying parties whose cosigner policies (<a href="#trusted-cosigners" class="auto internal xref">Section 7.3</a>) do not require durable logging (e.g. via <span>[<a href="#TLOG-MIRROR" class="cite xref">TLOG-MIRROR</a>]</span>) are particularly vulnerable to this. In this case, the indices of the missing entries will still be known, so relying parties can use this mechanism to revoke the unknown entries, possibly as an initial, targeted mitigation before complete CA removal.<a href="#section-7.5-4" class="pilcrow">¶</a></p>
+<p id="section-7.5-5">When a CA is found to be untrustworthy, relying parties SHOULD remove trust in that CA. To minimize the compatibility impact of this mitigation, index-based revocation can be used to only distrust entries after some index, while leaving existing entries accepted. This is analogous to the <span>[<a href="#SCTNotAfter" class="cite xref">SCTNotAfter</a>]</span> mechanism used in some PKIs.<a href="#section-7.5-5" class="pilcrow">¶</a></p>
+<p id="section-7.5-6">The revocation mechanism in this section is complementary to certificate-level revocation mechanisms. log entries are uniquely identified by their serial number and issuer, existing revocation mechanisms like CRLs <span>[<a href="#RFC5280" class="cite xref">RFC5280</a>]</span> and OCSP <span>[<a href="#RFC6960" class="cite xref">RFC6960</a>]</span> apply unchanged.<a href="#section-7.5-6" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>
@@ -5286,7 +5291,7 @@ <h4 id="name-log-failures">
               <p id="section-12.2.1-2.2.1">A CA miscalculates some hash and signs a subtree hash that cannot be computed from some underlying sequence of entries<a href="#section-12.2.1-2.2.1" class="pilcrow">¶</a></p>
 </li>
           </ul>
-<p id="section-12.2.1-3">As described above, PKIs can use additional cosigners to provide transparency guarantees even in the face of such CA violations. In doing so, individual cosigners may be locked to only one of two views of the log or unable to sign further checkpoints because some hash's preimage is unknown. It may then no longer be possible to add entries to the log that are trusted by existing relying parties.<a href="#section-12.2.1-3" class="pilcrow">¶</a></p>
+<p id="section-12.2.1-3">As described in <a href="#transparency" class="auto internal xref">Section 12.2</a>, PKIs can use additional cosigners to provide transparency guarantees even in the face of such CA violations. In doing so, individual cosigners may be locked to only one of two views of the log or unable to sign further checkpoints because some hash's preimage is unknown. It may then no longer be possible to add entries to the log that are trusted by existing relying parties.<a href="#section-12.2.1-3" class="pilcrow">¶</a></p>
 <p id="section-12.2.1-4">Whether by accident or compromise, these violations are ultimately CA failures. However, it is useful for the CA instance to remain functional during and after incident management:<a href="#section-12.2.1-4" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="section-12.2.1-5.1">
@@ -5316,9 +5321,9 @@ <h4 id="name-log-failures">
           <h4 id="name-limiting-issuance-logs">
 <a href="#section-12.2.2" class="section-number selfRef">12.2.2. </a><a href="#name-limiting-issuance-logs" class="section-name selfRef">Limiting Issuance Logs</a>
           </h4>
-<p id="section-12.2.2-1">While multiple issuance logs help mitigate log failures, as described above, they introduce transparency risks. If a CA violates the requirement to only use one issuance log at a time, it might add an entry in some far future log number. To be accepted in transparency-enforcing relying parties, the log state must still be cosigned. However, monitors may not know which log numbers to monitor.<a href="#section-12.2.2-1" class="pilcrow">¶</a></p>
+<p id="section-12.2.2-1">While multiple issuance logs help mitigate log failures, as described in <a href="#log-failures" class="auto internal xref">Section 12.2.1</a>, they introduce transparency risks. If a CA violates the requirement to only use one issuance log at a time, it might add an entry in some far future log number. To be accepted in transparency-enforcing relying parties, the log state must still be cosigned. However, monitors may not know which log numbers to monitor.<a href="#section-12.2.2-1" class="pilcrow">¶</a></p>
 <p id="section-12.2.2-2">PKIs with transparency requirements SHOULD mitigate this by only accepting a limited range of log numbers in relying parties, transparency cosigners, or both. This limit MAY be set to a fixed value or a rolling value that is updated whenever the CA switches its current log. Fixed values require committing to a limit of recoverable log failures over the lifetime of a CA.<a href="#section-12.2.2-2" class="pilcrow">¶</a></p>
-<p id="section-12.2.2-3">Log number limits in relying parties can be implemented by revoking all serial numbers above some threshold. (See <a href="#revoked-ranges" class="auto internal xref">Section 7.5</a>.)<a href="#section-12.2.2-3" class="pilcrow">¶</a></p>
+<p id="section-12.2.2-3">Log number limits in relying parties can be implemented by revoking all serial numbers above some threshold. (See <a href="#revoked-ranges" class="auto internal xref">Section 7.5</a>.) If using the format described in <a href="#representing-certification-authorities" class="auto internal xref">Section 5.5</a>, this can be implemented with the <code>maxSerial</code> field.<a href="#section-12.2.2-3" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>
@@ -5855,10 +5860,14 @@ <h2 id="name-asn1-module">
     CRITICALITY TRUE
 }
 
+-- This is 2^64-1, the maximum possible serial number in this protocol.
+mtcMaxSerial INTEGER ::= 18446744073709551615
+
 MTCCertificationAuthority ::= SEQUENCE {
     logHash   AlgorithmIdentifier{DIGEST-ALGORITHM, {...}},
     sigAlg    AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}},
-    minSerial INTEGER
+    minSerial INTEGER (0..mtcMaxSerial),
+    maxSerial INTEGER (0..mtcMaxSerial)
 }
 
 END
@@ -7350,6 +7359,9 @@ <h3 id="name-since-draft-ietf-plants-merkle-">
 </li>
           <li class="normal" id="appendix-E.16-1.6">
             <p id="appendix-E.16-1.6.1">Switch the ACME construction to a new link relation and change the HTTP status code<a href="#appendix-E.16-1.6.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-E.16-1.7">
+            <p id="appendix-E.16-1.7.1">Add a maxSerial field to the CA format<a href="#appendix-E.16-1.7.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 </section>