Script updating gh-pages from 9e71356. [ci skip]

draft-ietf-cose-merkle-tree-proofs.html

@@ -1035,7 +1035,7 @@
 </tr></thead>
 <tfoot><tr>
 <td class="left">Steele, et al.</td>
-<td class="center">Expires 7 February 2025</td>
+<td class="center">Expires 10 February 2025</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
 </table>
@@ -1048,12 +1048,12 @@
 <dd class="internet-draft">draft-ietf-cose-merkle-tree-proofs-latest</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2024-08-06" class="published">6 August 2024</time>
+<time datetime="2024-08-09" class="published">9 August 2024</time>
     </dd>
 <dt class="label-intended-status">Intended Status:</dt>
 <dd class="intended-status">Standards Track</dd>
 <dt class="label-expires">Expires:</dt>
-<dd class="expires"><time datetime="2025-02-07">7 February 2025</time></dd>
+<dd class="expires"><time datetime="2025-02-10">10 February 2025</time></dd>
 <dt class="label-authors">Authors:</dt>
 <dd class="authors">
 <div class="author">
@@ -1114,7 +1114,7 @@ <h2 id="name-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."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
 <p id="section-boilerplate.1-4">
-        This Internet-Draft will expire on 7 February 2025.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+        This Internet-Draft will expire on 10 February 2025.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="copyright">
@@ -1775,7 +1775,7 @@ <h3 id="name-inclusion-proof">
           <h4 id="name-receipt-of-inclusion">
 <a href="#section-5.2.1" class="section-number selfRef">5.2.1. </a><a href="#name-receipt-of-inclusion" class="section-name selfRef">Receipt of Inclusion</a>
           </h4>
-<p id="section-5.2.1-1">In a signed inclusion proof, the previous merkle tree root, maps to tree-size-1, and is a detached payload.
+<p id="section-5.2.1-1">In a signed inclusion proof, the payload is the merkle tree root which corresponds to the log at size <code>tree-size</code>.
 Specifications are encouraged to make payloads detached when possible, forcing validation-time comparison.
 Profiles of proof signatures are encouraged to make additional protected header parameters mandatory, to ensure that claims are processed with their intended semantics.
 One way to include this information in the COSE structure is use of the typ (type) Header Parameter, see <span>[<a href="#I-D.ietf-cose-typ-header-parameter" class="cite xref">I-D.ietf-cose-typ-header-parameter</a>]</span> and the similar guidance provided in <span>[<a href="#I-D.ietf-cose-cwt-claims-in-headers" class="cite xref">I-D.ietf-cose-cwt-claims-in-headers</a>]</span>.
@@ -1832,9 +1832,9 @@ <h4 id="name-receipt-of-inclusion">
               <p id="section-5.2.1-6.2.1">inclusion-proof (label: -1): <span class="bcp14">REQUIRED</span>. Inclusion proofs. Value type: Array of bstr.<a href="#section-5.2.1-6.2.1" class="pilcrow">¶</a></p>
 </li>
           </ul>
-<p id="section-5.2.1-7">The payload of an RFC9162_SHA256 inclusion proof signature is the previous Merkle tree hash as defined in <span>[<a href="#RFC9162" class="cite xref">RFC9162</a>]</span>.
+<p id="section-5.2.1-7">The payload of an RFC9162_SHA256 inclusion proof signature is the Merkle tree hash as defined in <span>[<a href="#RFC9162" class="cite xref">RFC9162</a>]</span>.
 The payload <span class="bcp14">MUST</span> be detached.
-Detaching the payload forces verifiers to recompute the root from the inclusion proof signature, this protects against implementation errors where the signature is verified but the merkle root does not match the inclusion proof.
+Detaching the payload forces verifiers to recompute the root from the inclusion proof, this protects against implementation errors where the signature is verified but the merkle root does not match the inclusion proof.
 The EDN for a Receipt containing an inclusion proof for RFC9162_SHA256 is:<a href="#section-5.2.1-7" class="pilcrow">¶</a></p>
 <span id="name-example-inclusion-receipt"></span><div id="rfc9162_sha256_inclusion_receipt">
 <figure id="figure-6">
@@ -1923,13 +1923,13 @@ <h3 id="name-consistency-proof">
 <pre>
 consistency-proof =  bstr .cbor [
 
-    ; previous merkle root tree size
+    ; older merkle root tree size
     tree-size-1: uint
 
-    ; latest merkle root tree size
+    ; newer merkle root tree size
     tree-size-2: uint
 
-    ; path from previous merkle root to latest merkle root.
+    ; path from older merkle root to newer merkle root.
     consistency-path: [ + bstr ]
 
 ]
@@ -1945,7 +1945,7 @@ <h3 id="name-consistency-proof">
           <h4 id="name-receipt-of-consistency">
 <a href="#section-5.3.1" class="section-number selfRef">5.3.1. </a><a href="#name-receipt-of-consistency" class="section-name selfRef">Receipt of Consistency</a>
           </h4>
-<p id="section-5.3.1-1">In a signed consistency proof, the latest merkle tree root, maps to tree-size-2, and is an attached payload.<a href="#section-5.3.1-1" class="pilcrow">¶</a></p>
+<p id="section-5.3.1-1">In a signed consistency proof, the newer merkle tree root (proven to be consistent with an older merkle tree root) is an attached payload and corresponds to the log at size tree-size-2.<a href="#section-5.3.1-1" class="pilcrow">¶</a></p>
 <p id="section-5.3.1-2">The protected header for an RFC9162_SHA256 consistency proof signature is:<a href="#section-5.3.1-2" class="pilcrow">¶</a></p>
 <span id="name-protected-header-for-a-recei"></span><div id="vds-in-consistency-receipt-protected-header">
 <figure id="figure-10">
@@ -1994,7 +1994,7 @@ <h4 id="name-receipt-of-consistency">
 </li>
           </ul>
 <p id="section-5.3.1-8">The payload of an RFC9162_SHA256 consistency proof signature is:
-The latest Merkle tree hash as defined in <span>[<a href="#RFC9162" class="cite xref">RFC9162</a>]</span>.
+The newer Merkle tree hash as defined in <span>[<a href="#RFC9162" class="cite xref">RFC9162</a>]</span>.
 The payload <span class="bcp14">MUST</span> be attached.<a href="#section-5.3.1-8" class="pilcrow">¶</a></p>
 <p id="section-5.3.1-9">The EDN for a Receipt containing a consistency proof for RFC9162_SHA256 is:<a href="#section-5.3.1-9" class="pilcrow">¶</a></p>
 <span id="name-example-consistency-receipt"></span><div id="rfc9162_sha256_consistency_receipt">

draft-ietf-cose-merkle-tree-proofs.txt

@@ -5,11 +5,11 @@
 COSE                                                           O. Steele
 Internet-Draft                                                 Transmute
 Intended status: Standards Track                             H. Birkholz
-Expires: 7 February 2025                                  Fraunhofer SIT
+Expires: 10 February 2025                                 Fraunhofer SIT
                                                       A. Delignat-Lavaud
                                                               C. Fournet
                                                                Microsoft
-                                                           6 August 2024
+                                                           9 August 2024
 
 
                              COSE Receipts
@@ -54,7 +54,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 7 February 2025.
+   This Internet-Draft will expire on 10 February 2025.
 
 Copyright Notice
 
@@ -460,8 +460,8 @@ Table of Contents
 
 5.2.1.  Receipt of Inclusion
 
-   In a signed inclusion proof, the previous merkle tree root, maps to
-   tree-size-1, and is a detached payload.  Specifications are
+   In a signed inclusion proof, the payload is the merkle tree root
+   which corresponds to the log at size tree-size.  Specifications are
    encouraged to make payloads detached when possible, forcing
    validation-time comparison.  Profiles of proof signatures are
    encouraged to make additional protected header parameters mandatory,
@@ -509,12 +509,12 @@ Table of Contents
       type: Array of bstr.
 
    The payload of an RFC9162_SHA256 inclusion proof signature is the
-   previous Merkle tree hash as defined in [RFC9162].  The payload MUST
-   be detached.  Detaching the payload forces verifiers to recompute the
-   root from the inclusion proof signature, this protects against
-   implementation errors where the signature is verified but the merkle
-   root does not match the inclusion proof.  The EDN for a Receipt
-   containing an inclusion proof for RFC9162_SHA256 is:
+   Merkle tree hash as defined in [RFC9162].  The payload MUST be
+   detached.  Detaching the payload forces verifiers to recompute the
+   root from the inclusion proof, this protects against implementation
+   errors where the signature is verified but the merkle root does not
+   match the inclusion proof.  The EDN for a Receipt containing an
+   inclusion proof for RFC9162_SHA256 is:
 
    18(                                 / COSE Sign 1                   /
        [
@@ -585,13 +585,13 @@ Table of Contents
 
    consistency-proof =  bstr .cbor [
 
-       ; previous merkle root tree size
+       ; older merkle root tree size
        tree-size-1: uint
 
-       ; latest merkle root tree size
+       ; newer merkle root tree size
        tree-size-2: uint
 
-       ; path from previous merkle root to latest merkle root.
+       ; path from older merkle root to newer merkle root.
        consistency-path: [ + bstr ]
 
    ]
@@ -603,8 +603,9 @@ Table of Contents
 
 5.3.1.  Receipt of Consistency
 
-   In a signed consistency proof, the latest merkle tree root, maps to
-   tree-size-2, and is an attached payload.
+   In a signed consistency proof, the newer merkle tree root (proven to
+   be consistent with an older merkle tree root) is an attached payload
+   and corresponds to the log at size tree-size-2.
 
    The protected header for an RFC9162_SHA256 consistency proof
    signature is:
@@ -644,7 +645,7 @@ Table of Contents
       Value type: Array of bstr.
 
    The payload of an RFC9162_SHA256 consistency proof signature is: The
-   latest Merkle tree hash as defined in [RFC9162].  The payload MUST be
+   newer Merkle tree hash as defined in [RFC9162].  The payload MUST be
    attached.
 
    The EDN for a Receipt containing a consistency proof for