Script updating gh-pages from 6795e4f. [ci skip]

Author: ID Bot

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

@@ -1382,6 +1382,14 @@ <h2 id="name-copyright-notice">
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.2">
                 <p id="section-toc.1-1.12.2.2.1"><a href="#section-12.2" class="auto internal xref">12.2</a>.  <a href="#name-transparency" class="internal xref">Transparency</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.2.2.1">
+                    <p id="section-toc.1-1.12.2.2.2.1.1"><a href="#section-12.2.1" class="auto internal xref">12.2.1</a>.  <a href="#name-log-failures" class="internal xref">Log Failures</a></p>
+</li>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.2.2.2">
+                    <p id="section-toc.1-1.12.2.2.2.2.1"><a href="#section-12.2.2" class="auto internal xref">12.2.2</a>.  <a href="#name-limiting-issuance-logs" class="internal xref">Limiting Issuance Logs</a></p>
+</li>
+                </ul>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.3">
                 <p id="section-toc.1-1.12.2.3.1"><a href="#section-12.3" class="auto internal xref">12.3</a>.  <a href="#name-public-key-hashes" class="internal xref">Public Key Hashes</a></p>
@@ -3839,7 +3847,7 @@ <h3 id="name-issuance-logs">
 <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>
-<p id="section-5.2-9">At any point in time, one of the CA's issuance logs is its <em>current</em> log. Initially, this is log 1. A CA MUST NOT append to any log that is not the current log. Logs before the current log may have historical entries. Logs after the current log MUST be empty. A CA MAY increment its current log number as part of recovering from certain operational failures.<a href="#section-5.2-9" class="pilcrow">¶</a></p>
+<p id="section-5.2-9">At any point in time, one of the CA's issuance logs is its <em>current</em> log. Initially, this is log 1. A CA MUST NOT append to any log that is not the current log. Logs before the current log may have historical entries. Logs after the current log MUST be empty. A CA MAY increment its current log number as part of recovering from certain operational failures. See <a href="#log-failures" class="auto internal xref">Section 12.2.1</a> for further discussion.<a href="#section-5.2-9" class="pilcrow">¶</a></p>
 <div id="log-entries">
 <section id="section-5.2.1">
           <h4 id="name-log-entries">
@@ -5235,6 +5243,55 @@ <h3 id="name-transparency">
             <p id="section-12.2-6.2.1">If the relying party accepts log views without a trusted mirror, the unauthorized entry may not be available. However, the existence of <em>some</em> entry at that index will be visible, so monitors will know the CA is failing to present an entry. This is sufficient to determine the serial number, so relying parties can then react by revoking the undisclosed entries (<a href="#revoked-ranges" class="auto internal xref">Section 7.5</a>), and likely removing the CA.<a href="#section-12.2-6.2.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
+<div id="log-failures">
+<section id="section-12.2.1">
+          <h4 id="name-log-failures">
+<a href="#section-12.2.1" class="section-number selfRef">12.2.1. </a><a href="#name-log-failures" class="section-name selfRef">Log Failures</a>
+          </h4>
+<p id="section-12.2.1-1">Merkle Tree Certificates introduce additional state to PKI deployments and thus new kinds of operational failures. CAs are required to only sign subtree hashes that are consistent with a single append-only view of each issuance log. A CA might violate this as a result of operational failures. For example:<a href="#section-12.2.1-1" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-12.2.1-2.1">
+              <p id="section-12.2.1-2.1.1">A CA loses some state and signs subtree hashes from two inconsistent copies of the log<a href="#section-12.2.1-2.1.1" class="pilcrow">¶</a></p>
+</li>
+            <li class="normal" id="section-12.2.1-2.2">
+              <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-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">
+              <p id="section-12.2.1-5.1.1">While the incident is diagnosed, authenticating parties may still need new certificates.<a href="#section-12.2.1-5.1.1" class="pilcrow">¶</a></p>
+</li>
+            <li class="normal" id="section-12.2.1-5.2">
+              <p id="section-12.2.1-5.2.1">If relying parties consider the CA operator and the CA instance still trustworthy, repairing the incident without changing the CA requires less overhead.<a href="#section-12.2.1-5.2.1" class="pilcrow">¶</a></p>
+</li>
+            <li class="normal" id="section-12.2.1-5.3">
+              <p id="section-12.2.1-5.3.1">If relying parties consider either the CA operator or the CA instance no longer trustworthy and in need of replacement, the CA may still be needed to serve older, unupdated relying parties.<a href="#section-12.2.1-5.3.1" class="pilcrow">¶</a></p>
+</li>
+          </ul>
+<p id="section-12.2.1-6">This is mitigated by a CA instance consisting of a series of issuance logs (<a href="#issuance-logs" class="auto internal xref">Section 5.2</a>). After a log failure, the CA SHOULD increment its current issuance log to restore availability. Both the underlying log failure and the use of a new issuance log will be visible to monitors and SHOULD be treated as a PKI incident. Such PKI incidents can be handled by some combination of:<a href="#section-12.2.1-6" class="pilcrow">¶</a></p>
+<ul class="normal">
+<li class="normal" id="section-12.2.1-7.1">
+              <p id="section-12.2.1-7.1.1">Revoking the diverging log indices (<a href="#revoked-ranges" class="auto internal xref">Section 7.5</a>)<a href="#section-12.2.1-7.1.1" class="pilcrow">¶</a></p>
+</li>
+            <li class="normal" id="section-12.2.1-7.2">
+              <p id="section-12.2.1-7.2.1">Reevaluating trusted CAs and, if necessary, removing the old CA instance and switching to a new CA instance<a href="#section-12.2.1-7.2.1" class="pilcrow">¶</a></p>
+</li>
+          </ul>
+<p id="section-12.2.1-8">In the latter case, the CA operator MAY continue to operate the removed CA instance if, for example, there remain unupdated relying parties that require it.<a href="#section-12.2.1-8" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="limiting-issuance-logs">
+<section id="section-12.2.2">
+          <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-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>
+</section>
+</div>
 </section>
 </div>
 <div id="public-key-hashes">

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

@@ -144,6 +144,8 @@ Table of Contents
    12. Security Considerations
      12.1.  Authenticity
      12.2.  Transparency
+       12.2.1.  Log Failures
+       12.2.2.  Limiting Issuance Logs
      12.3.  Public Key Hashes
      12.4.  Non-Repudiation
      12.5.  Extensibility
@@ -1247,7 +1249,8 @@ Table of Contents
    is not the current log.  Logs before the current log may have
    historical entries.  Logs after the current log MUST be empty.  A CA
    MAY increment its current log number as part of recovering from
-   certain operational failures.
+   certain operational failures.  See Section 12.2.1 for further
+   discussion.
 
 5.2.1.  Log Entries
 
@@ -3008,6 +3011,77 @@ Table of Contents
       then react by revoking the undisclosed entries (Section 7.5), and
       likely removing the CA.
 
+12.2.1.  Log Failures
+
+   Merkle Tree Certificates introduce additional state to PKI
+   deployments and thus new kinds of operational failures.  CAs are
+   required to only sign subtree hashes that are consistent with a
+   single append-only view of each issuance log.  A CA might violate
+   this as a result of operational failures.  For example:
+
+   *  A CA loses some state and signs subtree hashes from two
+      inconsistent copies of the log
+
+   *  A CA miscalculates some hash and signs a subtree hash that cannot
+      be computed from some underlying sequence of entries
+
+   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.
+
+   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:
+
+   *  While the incident is diagnosed, authenticating parties may still
+      need new certificates.
+
+   *  If relying parties consider the CA operator and the CA instance
+      still trustworthy, repairing the incident without changing the CA
+      requires less overhead.
+
+   *  If relying parties consider either the CA operator or the CA
+      instance no longer trustworthy and in need of replacement, the CA
+      may still be needed to serve older, unupdated relying parties.
+
+   This is mitigated by a CA instance consisting of a series of issuance
+   logs (Section 5.2).  After a log failure, the CA SHOULD increment its
+   current issuance log to restore availability.  Both the underlying
+   log failure and the use of a new issuance log will be visible to
+   monitors and SHOULD be treated as a PKI incident.  Such PKI incidents
+   can be handled by some combination of:
+
+   *  Revoking the diverging log indices (Section 7.5)
+
+   *  Reevaluating trusted CAs and, if necessary, removing the old CA
+      instance and switching to a new CA instance
+
+   In the latter case, the CA operator MAY continue to operate the
+   removed CA instance if, for example, there remain unupdated relying
+   parties that require it.
+
+12.2.2.  Limiting Issuance Logs
+
+   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.
+
+   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.
+
+   Log number limits in relying parties can be implemented by revoking
+   all serial numbers above some threshold.  (See Section 7.5.)
+
 12.3.  Public Key Hashes
 
    Unlike Certificate Transparency, the mechanisms in this document do

index.html

@@ -77,15 +77,15 @@ <h2>Preview for branch <a href="log-number-security-considerations">log-number-s
       <tr>
         <td><a href="log-number-security-considerations/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="log-number-security-considerations/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://ietf-plants-wg.github.io/merkle-tree-certs/draft-ietf-plants-merkle-tree-certs.txt&amp;url_2=https://ietf-plants-wg.github.io/merkle-tree-certs/log-number-security-considerations/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="current-log-number">current-log-number</a></h2>
     <table id="branch-current-log-number">
       <tr>
         <td><a href="current-log-number/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="current-log-number/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://ietf-plants-wg.github.io/merkle-tree-certs/draft-ietf-plants-merkle-tree-certs.txt&amp;url_2=https://ietf-plants-wg.github.io/merkle-tree-certs/current-log-number/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="lvalenta">lvalenta</a></h2>