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

draft-irtf-cfrg-cpace.html

@@ -1156,7 +1156,7 @@ <h2 id="name-copyright-notice">
                 <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="auto internal xref">3.1</a>.  <a href="#name-optional-cpace-inputs" class="internal xref">Optional CPace inputs</a></p>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2">
-                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="auto internal xref">3.2</a>.  <a href="#name-optional-cpace-output" class="internal xref">Optional CPace output</a></p>
+                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="auto internal xref">3.2</a>.  <a href="#name-optional-cpace-outputs" class="internal xref">Optional CPace outputs</a></p>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3">
                 <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="auto internal xref">3.3</a>.  <a href="#name-responsibilities-of-the-app" class="internal xref">Responsibilities of the application layer</a></p>
@@ -1751,13 +1751,13 @@ <h3 id="name-optional-cpace-inputs">
         </ul>
 </section>
 </div>
-<div id="optional-cpace-output">
+<div id="optional-cpace-outputs">
 <section id="section-3.2">
-        <h3 id="name-optional-cpace-output">
-<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-optional-cpace-output" class="section-name selfRef">Optional CPace output</a>
+        <h3 id="name-optional-cpace-outputs">
+<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-optional-cpace-outputs" class="section-name selfRef">Optional CPace outputs</a>
         </h3>
 <p id="section-3.2-1">If a session identifier is not available as input at protocol start CPace can optionally produce a session identifier sid_output
-as output that might be helpful for the application for actions subsequent to the CPace protocol step (see <a href="#sec-sid-output" class="auto internal xref">Section 9.6</a>).<a href="#section-3.2-1" class="pilcrow">¶</a></p>
+as output that might be helpful for the application for actions subsequent to the CPace protocol step (see <a href="#sec-sid-output" class="auto internal xref">Section 9.6</a>, <span>[<a href="#BGHJ24" class="cite xref">BGHJ24</a>]</span>).<a href="#section-3.2-1" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="responsibilities-of-the-application-layer">
@@ -1778,8 +1778,8 @@ <h3 id="name-responsibilities-of-the-app">
 </li>
           <li class="normal" id="section-3.3-2.3">
             <p id="section-3.3-2.3.1">The application needs to settle whether CPace is used in the initiator-responder or the symmetric setting, as in the symmetric
-setting transcripts and concatenation of party identity strings as part of the channel identifier CI
-must be generated using ordered string concatenation.
+setting transcripts ordered string concatenation must be used for generating protocol transcripts and when integrating
+the identity strings A and B into the channel identifier CI.
 In this document we will provide test vectors for both, initiator-responder and symmetric settings.<a href="#section-3.3-2.3.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
@@ -2478,27 +2478,26 @@ <h3 id="name-key-confirmation">
         <h3 id="name-integrating-cpace-in-higher">
 <a href="#section-9.5" class="section-number selfRef">9.5. </a><a href="#name-integrating-cpace-in-higher" class="section-name selfRef">Integrating CPace in higher-level protocols such as TLS1.3</a>
         </h3>
-<p id="section-9.5-1">When integrating CPace into a higher-level protocol such as TLS1.3 <span>[<a href="#RFC8446" class="cite xref">RFC8446</a>]</span> it is recommended to let the intermediate key ISK
-take over the role of the shared secret that for other cipher suites
-might be generated by Diffie-Hellman key exchange. Note that unlike a Diffie-Hellman shared secret ISK will also
-mutually authenticate the protocol partners.
+<p id="section-9.5-1">When integrating CPace into a higher-level protocol such as TLS1.3 <span>[<a href="#RFC8446" class="cite xref">RFC8446</a>]</span> it is recommended to use ISK
+as shared secret (which might otherwise be generated as part of a Diffie-Hellman key exchange output for other cipher suites).<a href="#section-9.5-1" class="pilcrow">¶</a></p>
+<p id="section-9.5-2">Note that unlike the shared secret of a Diffie-Hellman protocol run, ISK will also provide mutual implicit authentication of the protocol partners.
 For providing explicit authentication, it is recommended to add a key confirmation round along the lines in <a href="#sec-key-confirmation" class="auto internal xref">Section 9.4</a>,
-such as e.g. done in the "Finished" messages in TLS1.3.<a href="#section-9.5-1" class="pilcrow">¶</a></p>
-<p id="section-9.5-2">If an embedding protocol uses more than two messages (e.g. four message TLS1.3 <span>[<a href="#RFC8446" class="cite xref">RFC8446</a>]</span> flows involving
+such as e.g. done in the "Finished" messages in TLS1.3 <span>[<a href="#RFC8446" class="cite xref">RFC8446</a>]</span>.<a href="#section-9.5-2" class="pilcrow">¶</a></p>
+<p id="section-9.5-3">If an embedding protocol uses more than two messages (e.g. four message TLS1.3 <span>[<a href="#RFC8446" class="cite xref">RFC8446</a>]</span> flows involving
 a hello-retry message and a repeated client-hello message) it is suggested
 that the CPace layer only considers the two messages used for the CPace run. I.e. it is suggested that
 authenticating the full message sequence involving also the additional messages that might preceed the two CPace messages
-is done under the responsibiity of the embedding protocol.
-This could be done by integrating the full protocol transcript as part of a final explicit key confirmation round (as commonly done by TLS 1.3).
-Alternatively information on communication rounds preceeding the CPace flows can also be integrated as part of the CI field, as this will authenticate
-the information and will not require both communication partners to keep state information regarding preceeding messages until after the CPace run.<a href="#section-9.5-2" class="pilcrow">¶</a></p>
-<p id="section-9.5-3">In case of TLS 1.3 it is suggested to integrate Ya into the client-hello message and Yb into the server-hello message. Also party identifiers
-may be added to the client-hello and server-hello messages as part of extension fields.
+is done under the responsibiity of the embedding application protocol.
+This could be done by integrating the full protocol transcript as part of a final explicit key confirmation round (as commonly done by TLS 1.3 as part of the "Finished" messages).
+Alternatively, information on communication rounds preceeding the CPace flows can also be integrated as part of the CI field, as this will authenticate
+the information and will not require both communication partners to keep state information regarding preceeding messages in memory until after the CPace run.<a href="#section-9.5-3" class="pilcrow">¶</a></p>
+<p id="section-9.5-4">In case of TLS 1.3 <span>[<a href="#RFC8446" class="cite xref">RFC8446</a>]</span> it is suggested to integrate Ya into the client-hello message and Yb into the server-hello message. Also party identifiers
+might best be added to the client-hello and server-hello messages as part of extension fields.
 It is recommended to use the full octet stream encoding of the
-client-hello message as parameter ADa. Likewise the encoding of the server-hello would be used for the parameter ADb.
-This approach has the drawback that the public points Ya and Yb might show up duplicated in the hashing operation for
+client-hello message as parameter ADa. Likewise it is recommended to use the encoding of the server-hello message for the parameter ADb.
+This approach has the drawback that the public points Ya and Yb might show up redundantly duplicated in the hashing operation for
 CPace's transcript strings but has the advantage of simplicity and the advantage that all meta-information in the extension fields within the
-client- and server hello fields will become authenticated as part of the ISK.<a href="#section-9.5-3" class="pilcrow">¶</a></p>
+client- and server hello fields will always become authenticated as part of the ISK.<a href="#section-9.5-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="sec-sid-output">

draft-irtf-cfrg-cpace.txt

@@ -71,7 +71,7 @@ Table of Contents
    2.  Requirements Notation
    3.  High-level application perspective
      3.1.  Optional CPace inputs
-     3.2.  Optional CPace output
+     3.2.  Optional CPace outputs
      3.3.  Responsibilities of the application layer
    4.  CPace cipher suites
    5.  Definitions and notation
@@ -380,12 +380,12 @@ Table of Contents
       security advantages and will bind the CPace run to this
       communication session (see Section 9).
 
-3.2.  Optional CPace output
+3.2.  Optional CPace outputs
 
    If a session identifier is not available as input at protocol start
    CPace can optionally produce a session identifier sid_output as
    output that might be helpful for the application for actions
-   subsequent to the CPace protocol step (see Section 9.6).
+   subsequent to the CPace protocol step (see Section 9.6, [BGHJ24]).
 
 3.3.  Responsibilities of the application layer
 
@@ -404,10 +404,11 @@ Table of Contents
 
    *  The application needs to settle whether CPace is used in the
       initiator-responder or the symmetric setting, as in the symmetric
-      setting transcripts and concatenation of party identity strings as
-      part of the channel identifier CI must be generated using ordered
-      string concatenation.  In this document we will provide test
-      vectors for both, initiator-responder and symmetric settings.
+      setting transcripts ordered string concatenation must be used for
+      generating protocol transcripts and when integrating the identity
+      strings A and B into the channel identifier CI.  In this document
+      we will provide test vectors for both, initiator-responder and
+      symmetric settings.
 
 4.  CPace cipher suites
 
@@ -1121,41 +1122,44 @@ Table of Contents
 9.5.  Integrating CPace in higher-level protocols such as TLS1.3
 
    When integrating CPace into a higher-level protocol such as TLS1.3
-   [RFC8446] it is recommended to let the intermediate key ISK take over
-   the role of the shared secret that for other cipher suites might be
-   generated by Diffie-Hellman key exchange.  Note that unlike a Diffie-
-   Hellman shared secret ISK will also mutually authenticate the
-   protocol partners.  For providing explicit authentication, it is
-   recommended to add a key confirmation round along the lines in
-   Section 9.4, such as e.g. done in the "Finished" messages in TLS1.3.
+   [RFC8446] it is recommended to use ISK as shared secret (which might
+   otherwise be generated as part of a Diffie-Hellman key exchange
+   output for other cipher suites).
+
+   Note that unlike the shared secret of a Diffie-Hellman protocol run,
+   ISK will also provide mutual implicit authentication of the protocol
+   partners.  For providing explicit authentication, it is recommended
+   to add a key confirmation round along the lines in Section 9.4, such
+   as e.g. done in the "Finished" messages in TLS1.3 [RFC8446].
 
    If an embedding protocol uses more than two messages (e.g. four
    message TLS1.3 [RFC8446] flows involving a hello-retry message and a
    repeated client-hello message) it is suggested that the CPace layer
    only considers the two messages used for the CPace run.  I.e. it is
    suggested that authenticating the full message sequence involving
    also the additional messages that might preceed the two CPace
-   messages is done under the responsibiity of the embedding protocol.
-   This could be done by integrating the full protocol transcript as
-   part of a final explicit key confirmation round (as commonly done by
-   TLS 1.3).  Alternatively information on communication rounds
-   preceeding the CPace flows can also be integrated as part of the CI
-   field, as this will authenticate the information and will not require
-   both communication partners to keep state information regarding
-   preceeding messages until after the CPace run.
-
-   In case of TLS 1.3 it is suggested to integrate Ya into the client-
-   hello message and Yb into the server-hello message.  Also party
-   identifiers may be added to the client-hello and server-hello
-   messages as part of extension fields.  It is recommended to use the
-   full octet stream encoding of the client-hello message as parameter
-   ADa.  Likewise the encoding of the server-hello would be used for the
-   parameter ADb.  This approach has the drawback that the public points
-   Ya and Yb might show up duplicated in the hashing operation for
-   CPace's transcript strings but has the advantage of simplicity and
-   the advantage that all meta-information in the extension fields
-   within the client- and server hello fields will become authenticated
-   as part of the ISK.
+   messages is done under the responsibiity of the embedding application
+   protocol.  This could be done by integrating the full protocol
+   transcript as part of a final explicit key confirmation round (as
+   commonly done by TLS 1.3 as part of the "Finished" messages).
+   Alternatively, information on communication rounds preceeding the
+   CPace flows can also be integrated as part of the CI field, as this
+   will authenticate the information and will not require both
+   communication partners to keep state information regarding preceeding
+   messages in memory until after the CPace run.
+
+   In case of TLS 1.3 [RFC8446] it is suggested to integrate Ya into the
+   client-hello message and Yb into the server-hello message.  Also
+   party identifiers might best be added to the client-hello and server-
+   hello messages as part of extension fields.  It is recommended to use
+   the full octet stream encoding of the client-hello message as
+   parameter ADa.  Likewise it is recommended to use the encoding of the
+   server-hello message for the parameter ADb.  This approach has the
+   drawback that the public points Ya and Yb might show up redundantly
+   duplicated in the hashing operation for CPace's transcript strings
+   but has the advantage of simplicity and the advantage that all meta-
+   information in the extension fields within the client- and server
+   hello fields will always become authenticated as part of the ISK.
 
 9.6.  Calculating a session identifier alongside with the CPace run