Script updating gh-pages from d95ec71. [ci skip]

christian-review-v21/draft-ietf-core-oscore-groupcomm.html

@@ -28,7 +28,7 @@
     pycountry 22.3.5
     PyYAML 6.0.1
     requests 2.32.3
-    setuptools 69.5.1
+    setuptools 70.3.0
     wcwidth 0.2.13
 -->
 <link href="draft-ietf-core-oscore-groupcomm.xml" rel="alternate" type="application/rfc+xml">
@@ -1028,11 +1028,11 @@
 <thead><tr>
 <td class="left">Internet-Draft</td>
 <td class="center">Group OSCORE</td>
-<td class="right">July 2024</td>
+<td class="right">August 2024</td>
 </tr></thead>
 <tfoot><tr>
 <td class="left">Tiloca, et al.</td>
-<td class="center">Expires 29 January 2025</td>
+<td class="center">Expires 27 February 2025</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
 </table>
@@ -1045,12 +1045,12 @@
 <dd class="internet-draft">draft-ietf-core-oscore-groupcomm-latest</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2024-07-28" class="published">28 July 2024</time>
+<time datetime="2024-08-26" class="published">26 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-01-29">29 January 2025</time></dd>
+<dd class="expires"><time datetime="2025-02-27">27 February 2025</time></dd>
 <dt class="label-authors">Authors:</dt>
 <dd class="authors">
 <div class="author">
@@ -1115,7 +1115,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 29 January 2025.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+        This Internet-Draft will expire on 27 February 2025.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="copyright">
@@ -3228,7 +3228,7 @@ <h2 id="name-message-processing-in-pairw">
 <p id="section-9-4">In order to use the pairwise mode in a group where the group mode is also used (i.e., Group Encryption Algorithm and Signature Algorithm in the Security Context are set), the signature scheme of the group mode <span class="bcp14">MUST</span> support a combined signature and encryption scheme. For example, this can rely on signing operations using ECDSA, and encryption operations using AES-CCM with keying material derived through ECDH.<a href="#section-9-4" class="pilcrow">¶</a></p>
 <p id="section-9-5">The pairwise mode does not support external verifiers of source authentication and message integrity like the group mode does (see <a href="#sec-processing-signature-checker" class="auto internal xref">Section 8.5</a>).<a href="#section-9-5" class="pilcrow">¶</a></p>
 <p id="section-9-6">An endpoint implementing only a silent server does not support the pairwise mode.<a href="#section-9-6" class="pilcrow">¶</a></p>
-<p id="section-9-7">Endpoints using the CoAP Echo Option <span>[<a href="#RFC9175" class="cite xref">RFC9175</a>]</span> in a group where the AEAD Algorithm and Pairwise Key Agreement Algorithm are set <span class="bcp14">MUST</span> support the pairwise mode. This prevents the attack described in Section 13.9, which leverages requests sent over unicast to a single group member and protected in group mode.<a href="#section-9-7" class="pilcrow">¶</a></p>
+<p id="section-9-7">Endpoints using the CoAP Echo Option <span>[<a href="#RFC9175" class="cite xref">RFC9175</a>]</span> in a group where the AEAD Algorithm and Pairwise Key Agreement Algorithm are set <span class="bcp14">MUST</span> support the pairwise mode. This prevents the attack described in <a href="#ssec-unicast-requests" class="auto internal xref">Section 13.9</a>, which leverages requests sent over unicast to a single group member and protected in group mode.<a href="#section-9-7" class="pilcrow">¶</a></p>
 <p id="section-9-8">The pairwise mode cannot be used to protect messages intended for multiple recipients. In fact, the keying material used for the pairwise mode is shared only between two endpoints.<a href="#section-9-8" class="pilcrow">¶</a></p>
 <p id="section-9-9">However, a sender can use the pairwise mode to protect a message sent to (but not intended for) multiple recipients, if interested in a response from only one of them. For instance, this is useful to support the address discovery service defined in <a href="#ssec-pre-conditions" class="auto internal xref">Section 9.1</a>, when a single 'kid' value is indicated in the payload of a request sent to multiple recipients, e.g., over multicast.<a href="#section-9-9" class="pilcrow">¶</a></p>
 <div id="ssec-pre-conditions">

christian-review-v21/draft-ietf-core-oscore-groupcomm.txt

@@ -5,12 +5,12 @@
 CoRE Working Group                                             M. Tiloca
 Internet-Draft                                                   RISE AB
 Intended status: Standards Track                             G. Selander
-Expires: 29 January 2025                                    F. Palombini
+Expires: 27 February 2025                                   F. Palombini
                                                              J. Mattsson
                                                              Ericsson AB
                                                               R. Höglund
                                                                  RISE AB
-                                                            28 July 2024
+                                                          26 August 2024
 
 
    Group Object Security for Constrained RESTful Environments (Group
@@ -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 29 January 2025.
+   This Internet-Draft will expire on 27 February 2025.
 
 Copyright Notice