Script updating gh-pages from 8beef73. [ci skip]

christian-review-v08/draft-ietf-core-oscore-key-update.html

@@ -1660,7 +1660,7 @@ <h3 id="name-key-update-with-forward-sec">
           <h4 id="name-nonces-and-x-bytes">
 <a href="#section-4.3.1" class="section-number selfRef">4.3.1. </a><a href="#name-nonces-and-x-bytes" class="section-name selfRef">Nonces and X Bytes</a>
           </h4>
-<p id="section-4.3.1-1">When running KUDOS, each peer contributes by generating a nonce value N1 or N2, and providing it to the other peer. The size of the nonces N1 and N2 is application specific, and the use of 8 byte nonce values is <span class="bcp14">RECOMMENDED</span>. The nonces N1 and N2 <span class="bcp14">SHOULD</span> be random values. An exception is described later in <a href="#key-material-handling" class="auto internal xref">Section 4.5.1</a>.<a href="#section-4.3.1-1" class="pilcrow">¶</a></p>
+<p id="section-4.3.1-1">When running KUDOS, each peer contributes by generating a nonce value N1 or N2, and providing it to the other peer. The size of the nonces N1 and N2 is application specific, and the use of 8 byte nonce values is <span class="bcp14">RECOMMENDED</span>. The nonces N1 and N2 <span class="bcp14">MUST</span> be random values, with the possible exception described later in <a href="#key-material-handling" class="auto internal xref">Section 4.5.1</a>. Note that a good amount of randomness is important for the nonce generation. <span>[<a href="#RFC4086" class="cite xref">RFC4086</a>]</span> provides guidance on the generation of random values.<a href="#section-4.3.1-1" class="pilcrow">¶</a></p>
 <p id="section-4.3.1-2">Furthermore, X1 and X2 are the value of the 'x' byte specified in the OSCORE Option of the first and second KUDOS message, respectively. The X1 and X2 values are calculated by the sender peer based on: the length of nonce N1 and N2, specified in the 'nonce' field of the OSCORE Option of the first and second KUDOS message, respectively; as well as on the specific settings the peer wishes to run KUDOS with. As defined in <a href="#ssec-derive-ctx-client-init" class="auto internal xref">Section 4.3.5</a>, these values are used by the peers to build the input N and X to the updateCtx() function, in order to derive a new OSCORE Security Context. As for any new OSCORE Security Context, the Sender Sequence Number and the Replay Window are re-initialized accordingly (see <span><a href="https://rfc-editor.org/rfc/rfc8613#section-3.2.2" class="relref">Section 3.2.2</a> of [<a href="#RFC8613" class="cite xref">RFC8613</a>]</span>).<a href="#section-4.3.1-2" class="pilcrow">¶</a></p>
 <p id="section-4.3.1-3">After a peer has generated or received the value N1, and after a peer has calculated or received the value X1, it shall retain these in memory until it has received and processed the second KUDOS message.<a href="#section-4.3.1-3" class="pilcrow">¶</a></p>
 </section>
@@ -3112,6 +3112,10 @@ <h3 id="name-informative-references">
         <dd>
 <span class="refAuthor">Open Mobile Alliance</span>, <span class="refTitle">"Lightweight Machine to Machine Technical Specification - Transport Bindings, Approved Version 1.2, OMA-TS-LightweightM2M_Transport-V1_2-20201110-A"</span>, <time datetime="2020-11" class="refDate">November 2020</time>, <span>&lt;<a href="http://www.openmobilealliance.org/release/LightweightM2M/V1_2-20201110-A/OMA-TS-LightweightM2M_Transport-V1_2-20201110-A.pdf">http://www.openmobilealliance.org/release/LightweightM2M/V1_2-20201110-A/OMA-TS-LightweightM2M_Transport-V1_2-20201110-A.pdf</a>&gt;</span>. </dd>
 <dd class="break"></dd>
+<dt id="RFC4086">[RFC4086]</dt>
+        <dd>
+<span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refAuthor">Schiller, J.</span>, and <span class="refAuthor">S. Crocker</span>, <span class="refTitle">"Randomness Requirements for Security"</span>, <span class="seriesInfo">BCP 106</span>, <span class="seriesInfo">RFC 4086</span>, <span class="seriesInfo">DOI 10.17487/RFC4086</span>, <time datetime="2005-06" class="refDate">June 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc4086">https://www.rfc-editor.org/rfc/rfc4086</a>&gt;</span>. </dd>
+<dd class="break"></dd>
 <dt id="RFC7554">[RFC7554]</dt>
         <dd>
 <span class="refAuthor">Watteyne, T., Ed.</span>, <span class="refAuthor">Palattella, M.</span>, and <span class="refAuthor">L. Grieco</span>, <span class="refTitle">"Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement"</span>, <span class="seriesInfo">RFC 7554</span>, <span class="seriesInfo">DOI 10.17487/RFC7554</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc7554">https://www.rfc-editor.org/rfc/rfc7554</a>&gt;</span>. </dd>

christian-review-v08/draft-ietf-core-oscore-key-update.txt

@@ -677,8 +677,10 @@ Table of Contents
    When running KUDOS, each peer contributes by generating a nonce value
    N1 or N2, and providing it to the other peer.  The size of the nonces
    N1 and N2 is application specific, and the use of 8 byte nonce values
-   is RECOMMENDED.  The nonces N1 and N2 SHOULD be random values.  An
-   exception is described later in Section 4.5.1.
+   is RECOMMENDED.  The nonces N1 and N2 MUST be random values, with the
+   possible exception described later in Section 4.5.1.  Note that a
+   good amount of randomness is important for the nonce generation.
+   [RFC4086] provides guidance on the generation of random values.
 
    Furthermore, X1 and X2 are the value of the 'x' byte specified in the
    OSCORE Option of the first and second KUDOS message, respectively.
@@ -2333,6 +2335,11 @@ Table of Contents
               V1_2-20201110-A/OMA-TS-LightweightM2M_Transport-
               V1_2-20201110-A.pdf>.
 
+   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
+              "Randomness Requirements for Security", BCP 106, RFC 4086,
+              DOI 10.17487/RFC4086, June 2005,
+              <https://www.rfc-editor.org/rfc/rfc4086>.
+
    [RFC7554]  Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
               IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
               Internet of Things (IoT): Problem Statement", RFC 7554,