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

Author: ID Bot

fix-missing-yang-references/draft-ietf-anima-rfc8366bis.html

@@ -38,7 +38,7 @@
     pycountry 24.6.1
     PyYAML 6.0.3
     requests 2.33.1
-    wcwidth 0.8.1
+    wcwidth 0.8.2
 -->
 <link href="draft-ietf-anima-rfc8366bis.xml" rel="alternate" type="application/rfc+xml">
 <link href="#copyright" rel="license">
@@ -1057,11 +1057,11 @@
 <thead><tr>
 <td class="left">Internet-Draft</td>
 <td class="center">Voucher Artifact</td>
-<td class="right">June 2026</td>
+<td class="right">July 2026</td>
 </tr></thead>
 <tfoot><tr>
 <td class="left">Watsen, et al.</td>
-<td class="center">Expires 30 December 2026</td>
+<td class="center">Expires 6 January 2027</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
 </table>
@@ -1080,12 +1080,12 @@
 <a href="https://www.rfc-editor.org/rfc/rfc8995" class="eref">8995</a> (if approved)</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2026-06-28" class="published">28 June 2026</time>
+<time datetime="2026-07-05" class="published">5 July 2026</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="2026-12-30">30 December 2026</time></dd>
+<dd class="expires"><time datetime="2027-01-06">6 January 2027</time></dd>
 <dt class="label-authors">Authors:</dt>
 <dd class="authors">
 <div class="author">
@@ -1160,7 +1160,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 30 December 2026.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+        This Internet-Draft will expire on 6 January 2027.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="copyright">
@@ -1953,12 +1953,12 @@ <h2 id="name-voucher-artifact">
 <p id="section-8-6">Only the format of Voucher that is expected is signaled in the form of a (MIME) media
 type in the HTTP "Accept" header <span>[<a href="#RFC9110" class="cite xref">RFC9110</a>]</span>.<a href="#section-8-6" class="pilcrow">¶</a></p>
 <p id="section-8-7">For Vouchers stored/transferred via methods like a USB storage device (USB key), the Voucher format is usually signaled by a filename extension.<a href="#section-8-7" class="pilcrow">¶</a></p>
-<p id="section-8-8">In the constrained versions of the voucher and voucher-request (as used by <span>[<a href="#cBRSKI" class="cite xref">cBRSKI</a>]</span>), the fields <code>pinned-domain-pubk</code> (<code>proximity-registrar-pubk</code> for requests) and <code>pinned-domain-pubk-sha256</code> (<code>proximity-registrar-pubk-sha256</code> for requests) can be used to pin the raw public key, or just the SHA256 hash of the raw public key.
+<p id="section-8-8">In the constrained versions of the voucher and voucher-request (as used by <span>[<a href="#cBRSKI" class="cite xref">cBRSKI</a>]</span>), the attributes <code>pinned-domain-pubk</code> (<code>proximity-registrar-pubk</code> for requests) and <code>pinned-domain-pubk-sha256</code> (<code>proximity-registrar-pubk-sha256</code> for requests) are involved in the process of pinning a raw public key.
 The public keys are to be encoded according to <span>[<a href="#RFC7250" class="cite xref">RFC7250</a>], <a href="https://rfc-editor.org/rfc/rfc7250#section-3" class="relref">Section 3</a></span> for RSA and EcDSA keys, noting that <span>[<a href="#RFC8032" class="cite xref">RFC8032</a>]</span> extends this to include an OID for EdDSA.
 The old (1024-bit) DSA algorithm is not supported.<a href="#section-8-8" class="pilcrow">¶</a></p>
 <p id="section-8-9">When EcDSA is supported, curves secp256r1 and secp384r1 <span class="bcp14">SHOULD</span> be supported.
 When EdDSA is supported, curves Ed25519 and Ed448 <span class="bcp14">SHOULD</span> be supported.
-When RSA is supported by an implementation, it <span class="bcp14">SHOULD</span> support key lengths between 2048 and 4096 bits, and <span class="bcp14">MAY</span> support longer keys.<a href="#section-8-9" class="pilcrow">¶</a></p>
+When RSA is supported by an implementation, it <span class="bcp14">SHOULD</span> support key lengths between 2048 and 4096 bits.<a href="#section-8-9" class="pilcrow">¶</a></p>
 <p id="section-8-10">Of the above, EcDSA <span class="bcp14">SHOULD</span> be supported by all implementations, until some quantum-safe variant is standardized.<a href="#section-8-10" class="pilcrow">¶</a></p>
 <p id="section-8-11">Should SHA256 need to be replaced, then a new YANG module will be published with a new leaf, obsoleting <code>pinned-domain-pubk-sha256</code> and <code>proximity-registrar-pubk-sha256</code>.<a href="#section-8-11" class="pilcrow">¶</a></p>
 <div id="voucher-tree-diagram">

fix-missing-yang-references/draft-ietf-anima-rfc8366bis.txt

@@ -7,12 +7,12 @@ Internet-Draft                                           Watsen Networks
 Obsoletes: 8366 (if approved)                         M. Richardson, Ed.
 Updates: 8995 (if approved)                           Sandelman Software
 Intended status: Standards Track                                 E. Dijk
-Expires: 30 December 2026                              IoTconsultancy.nl
+Expires: 6 January 2027                                IoTconsultancy.nl
                                                                T. Eckert
                                              Futurewei Technologies Inc.
                                                                    Q. Ma
                                                                   Huawei
-                                                            28 June 2026
+                                                             5 July 2026
 
 
              A Voucher Artifact for Bootstrapping Protocols
@@ -68,7 +68,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 30 December 2026.
+   This Internet-Draft will expire on 6 January 2027.
 
 Copyright Notice
 
@@ -705,19 +705,18 @@ Table of Contents
    extension.
 
    In the constrained versions of the voucher and voucher-request (as
-   used by [cBRSKI]), the fields pinned-domain-pubk (proximity-
+   used by [cBRSKI]), the attributes pinned-domain-pubk (proximity-
    registrar-pubk for requests) and pinned-domain-pubk-sha256
-   (proximity-registrar-pubk-sha256 for requests) can be used to pin the
-   raw public key, or just the SHA256 hash of the raw public key.  The
-   public keys are to be encoded according to [RFC7250], Section 3 for
-   RSA and EcDSA keys, noting that [RFC8032] extends this to include an
-   OID for EdDSA.  The old (1024-bit) DSA algorithm is not supported.
+   (proximity-registrar-pubk-sha256 for requests) are involved in the
+   process of pinning a raw public key.  The public keys are to be
+   encoded according to [RFC7250], Section 3 for RSA and EcDSA keys,
+   noting that [RFC8032] extends this to include an OID for EdDSA.  The
+   old (1024-bit) DSA algorithm is not supported.
 
    When EcDSA is supported, curves secp256r1 and secp384r1 SHOULD be
    supported.  When EdDSA is supported, curves Ed25519 and Ed448 SHOULD
    be supported.  When RSA is supported by an implementation, it SHOULD
-   support key lengths between 2048 and 4096 bits, and MAY support
-   longer keys.
+   support key lengths between 2048 and 4096 bits.
 
    Of the above, EcDSA SHOULD be supported by all implementations, until
    some quantum-safe variant is standardized.