Script updating gh-pages from 7a2d5f1. [ci skip]

Author: ID Bot

current-log-number/draft-ietf-plants-merkle-tree-certs.html

@@ -5,13 +5,13 @@
 PKI, Logs, And Tree Signatures                               D. Benjamin
 Internet-Draft                                                Google LLC
 Intended status: Standards Track                              D. O'Brien
-Expires: 23 January 2027                                      Apple Inc.
+Expires: 28 January 2027                                      Apple Inc.
                                                         B. E. Westerbaan
                                                               L. Valenta
                                                               Cloudflare
                                                              F. Valsorda
                                                                   Geomys
-                                                            22 July 2026
+                                                            27 July 2026
 
 
                         Merkle Tree Certificates
@@ -63,7 +63,7 @@ Status of This Memo
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on 23 January 2027.
+   This Internet-Draft will expire on 28 January 2027.
 
 Copyright Notice
 
@@ -1379,16 +1379,14 @@ Table of Contents
    Note the subject's public key algorithm is incorporated into both
    subjectPublicKeyAlgorithm and subjectPublicKeyInfoHash.
 
-   MTCLogEntry is an extensible structure.  Future documents may define
+   MTCLogEntry is an extensible structure.  Future documents MAY define
    new values for MTCLogEntryType or MTCLogEntryExtensionType, with
    corresponding semantics.  See Section 5.4 and Section 12.5 for
    additional discussion.
 
-   An MTCLogEntry's size SHOULD NOT exceed 65535 (2^16-1) bytes.  Doing
-   so may exceed size limits in common log-serving protocols, such as
-   [TLOG-TILES].  TBSCertificateLogEntry does not include signatures and
-   hashes public keys, so post-quantum algorithms do not contribute to
-   this size.
+   An MTCLogEntry's size MUST NOT exceed 65535 (2^16-1) bytes.
+   TBSCertificateLogEntry does not include signatures and hashes public
+   keys, so post-quantum algorithms do not contribute to this size.
 
 5.2.2.  Publishing Logs
 
@@ -1397,7 +1395,7 @@ Table of Contents
 
    This document does not prescribe a particular method of observing the
    issuance log.  The access protocols do not affect certificate
-   interoperability, and different applications may have different
+   interoperability, and different applications could have different
    needs.  For example, a PKI that authenticates public services might
    publicly serve issuance logs, while a PKI that authenticates a single
    organization's intranet services might keep the log private to the
@@ -1418,10 +1416,11 @@ Table of Contents
    section.
 
    Pruning makes some prefix of the log unavailable, without changing
-   the tree structure.  It may be used to reduce the serving cost of
-   long-lived logs, where any entries have long expired.  Section 10.3
-   discusses policies on when pruning may be permitted.  This section
-   discusses how it is done and the impact on log structure.
+   the tree structure.  It is a technique to reduce the serving cost of
+   long-lived logs, by dropping entries that have long expired.
+   Section 10.3 discusses policies on when pruning MAY be performed.
+   This section discusses how it is done and the impact on log
+   structure.
 
    An issuance log is pruned by updating its _minimum index_ parameter
    (Section 5.2).  The minimum index is the index of the first log entry
@@ -1535,7 +1534,7 @@ Table of Contents
    subtree, determined by the cosigner's role.  This document defines
    one concrete cosigner role, a CA cosigner (Section 5.4), to
    authenticate the log and certify entries.  Other documents and
-   specific deployments may define other cosigner roles, to perform
+   specific deployments MAY define other cosigner roles, to perform
    different functions in a PKI.  For example, [TLOG-WITNESS] defines a
    cosigner that only checks the log is append-only, and [TLOG-MIRROR]
    defines a cosigner that mirrors a log.
@@ -1605,7 +1604,7 @@ Table of Contents
 
    start and end MUST define a valid subtree of the log, and
    subtree_hash MUST be the subtree's hash value in the cosigner's view
-   of the log.
+   of the log.  See Section 4.1.
 
    If timestamp is non-zero, it MUST be the time that the signature was
    produced.  This time is represented as seconds since the Epoch, as
@@ -1618,27 +1617,28 @@ Table of Contents
       cosigner has observed for the log.
 
    timestamp MAY be zero, in which case no additional constraints are
-   placed on start or end, and no statement is made about the signing
-   time or largest observed tree.
+   placed on start or end (beyond being a valid subtree), and no
+   statement is made about the signing time or largest observed tree.
 
 5.3.2.  Signature Semantics
 
    Before signing a subtree of some log, the cosigner MUST ensure that
    subtree_hash is consistent with its view of the log.  Different
-   cosigner roles may obtain this assurance differently.  For example:
+   cosigner roles will obtain this assurance differently.  For example:
 
-   *  A cosigner may maintain a full copy of the log, e.g. if it's the
+   *  A cosigner MAY maintain a full copy of the log, e.g. if it's the
       log operator.  The cosigner can then compute subtree_hash from
       this copy.
 
-   *  A cosigner may maintain the hash of the largest consistent tree
+   *  A cosigner MAY maintain the hash of the largest consistent tree
       observed by the log.  The cosigner can then check subtree_hash
       with a subtree consistency proof (Section 4.4).
 
-   In both cases, the cosigner MUST ensure that, as it updates its view
-   of the log, the old and new views are consistent.  For example,
-   [TLOG-WITNESS] defines a cosigner that checks consistency proofs
-   (Section 2.1.4 of [RFC9162]) between the two views.
+   *  A cosigner MAY maintain any other representation of the log which
+      allows it to verify the consistency of the log.
+
+   In all cases, the cosigner MUST ensure that, as it updates its view
+   of the log, the old and new views are consistent.
 
    When a cosigner signs a subtree, it is held separately responsible
    _both_ for the subtree being consistent with its other signatures,
@@ -1648,15 +1648,14 @@ Table of Contents
    even if some other signed subtree exists that asserts different
    entries.
 
-   Subtree signatures can be used to sign timestamped log checkpoints
-   with a non-zero timestamp.  A signature with a non-zero timestamp
+   Subtree signatures can be used to sign timestamped log checkpoints by
+   using a non-zero timestamp.  A signature with a non-zero timestamp
    asserts the complete state of the cosigner's view of the log at a
    given time.  These signatures are not directly used in Merkle Tree
    Certificates (Section 6.2), but cosigners MAY generate them, subject
-   to the rules above, as part of other functions in a PKI.  This may
-   include log serving or integrating an issuance log into a
-   transparency ecosystem.  For example, [TLOG-TILES] and [TLOG-WITNESS]
-   use such signatures.
+   to the rules above, as part of other functions in a PKI, such as log
+   serving or integrating an issuance log into a transparency ecosystem.
+   For example, [TLOG-TILES] and [TLOG-WITNESS] use such signatures.
 
 5.3.3.  Signature Algorithms
 
@@ -1698,12 +1697,12 @@ Table of Contents
       TBSCertificateLogEntry, as defined in Section 5.2.1.
 
    Entries are extensible.  Future documents MAY define type and
-   extension_type values and what it means to certify them.  A CA MUST
-   NOT sign a subtree if it contains an entry with type or
-   extension_type that it does not recognize.  Doing so would certify
-   that the CA has validated the information in some not-yet-defined
-   format.  Section 12.5 further discusses security implications of such
-   extensions.
+   extension_type values and the semantics of the data that they
+   contain.  A CA MUST NOT sign a subtree if it contains an entry with
+   type or extension_type that it does not recognize.  Doing so would
+   certify that the CA has validated the information in some not-yet-
+   defined format.  Section 12.5 further discusses security implications
+   of such extensions.
 
    If the CA issues certificate revocation lists (CRLs) [RFC5280] or
    Online Certificate Status Protocol (OCSP) responses [RFC6960], the
@@ -1804,7 +1803,7 @@ Table of Contents
    A CA certificate using this format SHOULD NOT be self-signed by the
    Merkle Tree Certificate CA.  Doing so would require writing the
    information in the issuance log.  Instead, if used to represent a
-   trust anchor, the certificate should be an unsigned certificate
+   trust anchor, the certificate SHOULD be an unsigned certificate
    [RFC9925].
 
 6.  Certificates
@@ -1831,13 +1830,13 @@ Table of Contents
       that subtree, which together satisfy relying party requirements
       (Section 7.3)
 
-   For any given TBSCertificateLogEntry, there are multiple possible
-   certificates that may prove the entry is certified by the CA and
-   publicly logged, varying by choice of subtree and signatures.
-   Section 6.2 defines how the certificate is constructed based on those
-   choices.  Section 6.3 and Section 6.4 define two profiles of Merkle
-   Tree Certificates, standalone certificates and landmark-relative
-   certificates, and how to select the subtree and signatures for them.
+   By varying the choice of subtree and signatures, there can be
+   multiple ways to prove the entry is in the log, and thus certified by
+   the CA.  Section 6.2 defines how a certificate is constructed based
+   on those choices.  Section 6.3 and Section 6.4 define two profiles of
+   Merkle Tree Certificates, standalone certificates and landmark-
+   relative certificates, and how to select the subtree and signatures
+   for them.
 
 6.2.  Certificate Format
 
@@ -2000,8 +1999,9 @@ Table of Contents
 
 6.4.1.  Landmark Tree Sizes
 
-   To issue landmark-relative certificates, a CA must additionally
-   maintain a _landmark sequence_, which is a sequence of _landmarks_.
+   A CA that issues landmark-relative certificates MUST additionally
+   maintain a _landmark sequence_. A landmark sequence is a sequence of
+   _landmarks_, defined below:
 
    Each landmark consists of a number, used as an identifier for the
    landmark, and a tree size, used as a common point of reference across

current-log-number/draft-ietf-plants-merkle-tree-certs.txt

@@ -40,14 +40,6 @@ <h2>Preview for branch <a href="link-rel-bikeshed">link-rel-bikeshed</a></h2>
         <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/link-rel-bikeshed/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="link-rel-enhancement">link-rel-enhancement</a></h2>
-    <table id="branch-link-rel-enhancement">
-      <tr>
-        <td><a href="link-rel-enhancement/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="link-rel-enhancement/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/link-rel-enhancement/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="demo-update">demo-update</a></h2>
     <table id="branch-demo-update">
       <tr>
@@ -56,14 +48,6 @@ <h2>Preview for branch <a href="demo-update">demo-update</a></h2>
         <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/demo-update/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="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><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="publishing-logs-editorial">publishing-logs-editorial</a></h2>
     <table id="branch-publishing-logs-editorial">
       <tr>
@@ -170,14 +154,6 @@ <h2>Preview for branch <a href="bas/timestamp-tai">bas/timestamp-tai</a></h2>
         <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/bas/timestamp-tai/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="log-number-security-considerations">log-number-security-considerations</a></h2>
-    <table id="branch-log-number-security-considerations">
-      <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>
-      </tr>
-    </table>
     <h2>Preview for branch <a href="cite-9846">cite-9846</a></h2>
     <table id="branch-cite-9846">
       <tr>