Script updating gh-pages from 924308c. [ci skip]

ace-wg · Oct 26, 2023 · 17b22b3 · 17b22b3
1 parent 7e89aa5
commit 17b22b3
Show file tree

Hide file tree

Showing 2 changed files with 17 additions and 11 deletions.
diff --git a/draft-ietf-ace-key-groupcomm.html b/draft-ietf-ace-key-groupcomm.html
@@ -2616,7 +2616,7 @@ <h4 id="name-post-handler">
 <a href="#name-example-of-pop-input-to-comp" class="selfRef">Example of PoP input to compute 'kdc_cred_verify' using CBOR encoding</a>
             </figcaption></figure>
 </div>
-<p id="section-4.3.1-41">After sending the Join Response, the KDC MUST store the N_C value specified in the 'cnonce' parameter of the Join Request, as a 'clientchallenge' value associated with the Client. If, as a group member, the Client later sends a GET request to the /ace-group/GROUPNAME/kdc-cred resource for retrieving the latest KDC's authentication credential (see <a href="#kdc-pub-key-get" class="auto internal xref">Section 4.5.1</a>), then the KDC is able to use the stored 'clientchallenge' for computing a PoP evidence to include in the response sent to the Client, hence proving the possession of its own private key.<a href="#section-4.3.1-41" class="pilcrow">¶</a></p>
+<p id="section-4.3.1-41">After sending the Join Response, if the KDC has an associated authentication credential, the KDC MUST store the N_C value specified in the 'cnonce' parameter of the Join Request, as a ‘clientchallenge’ value associated with the Client. If, as a group member, the Client later sends a GET request to the /ace-group/GROUPNAME/kdc-cred resource for retrieving the latest KDC's authentication credential (see <a href="#kdc-pub-key-get" class="auto internal xref">Section 4.5.1</a>), then the KDC is able to use the stored 'clientchallenge' for computing a PoP evidence to include in the response sent to the Client, hence proving the possession of its own private key.<a href="#section-4.3.1-41" class="pilcrow">¶</a></p>
 <p id="section-4.3.1-42">If the Join Response includes the 'kdc_cred_verify' parameter, the Client verifies the conveyed PoP evidence and considers the group joining unsuccessful in case of failed verification. Application profiles of this specification MUST specify the exact approaches used by the Client to verify the PoP evidence in 'kdc_cred_verify', and MUST specify which of those approaches is used in which case (REQ21).<a href="#section-4.3.1-42" class="pilcrow">¶</a></p>
 <p id="section-4.3.1-43">Specific application profiles that build on this document MUST specify the communication protocol that members of the group use to communicate with each other (REQ22) and how exactly the keying material is used to protect the group communication (REQ23).<a href="#section-4.3.1-43" class="pilcrow">¶</a></p>
 <div id="ssec-key-distribution-exchange">
@@ -4833,7 +4833,10 @@ <h3 id="name-version-17-to-18">
             <p id="appendix-C.1-1.2.1">Consistency fix: Clients always support the 'cnonce' parameter.<a href="#appendix-C.1-1.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-C.1-1.3">
-            <p id="appendix-C.1-1.3.1">Fixes and editorial improvements.<a href="#appendix-C.1-1.3.1" class="pilcrow">¶</a></p>
+            <p id="appendix-C.1-1.3.1">The KDC might not have to store the 'cnonce' from a Join Request.<a href="#appendix-C.1-1.3.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-C.1-1.4">
+            <p id="appendix-C.1-1.4.1">Fixes and editorial improvements.<a href="#appendix-C.1-1.4.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 </section>

diff --git a/draft-ietf-ace-key-groupcomm.txt b/draft-ietf-ace-key-groupcomm.txt
@@ -1954,15 +1954,16 @@ Table of Contents
         Figure 14: Example of PoP input to compute 'kdc_cred_verify'
                             using CBOR encoding
 
-   After sending the Join Response, the KDC MUST store the N_C value
-   specified in the 'cnonce' parameter of the Join Request, as a
-   'clientchallenge' value associated with the Client.  If, as a group
-   member, the Client later sends a GET request to the /ace-
-   group/GROUPNAME/kdc-cred resource for retrieving the latest KDC's
-   authentication credential (see Section 4.5.1), then the KDC is able
-   to use the stored 'clientchallenge' for computing a PoP evidence to
-   include in the response sent to the Client, hence proving the
-   possession of its own private key.
+   After sending the Join Response, if the KDC has an associated
+   authentication credential, the KDC MUST store the N_C value specified
+   in the 'cnonce' parameter of the Join Request, as a ‘clientchallenge’
+   value associated with the Client.  If, as a group member, the Client
+   later sends a GET request to the /ace-group/GROUPNAME/kdc-cred
+   resource for retrieving the latest KDC's authentication credential
+   (see Section 4.5.1), then the KDC is able to use the stored
+   'clientchallenge' for computing a PoP evidence to include in the
+   response sent to the Client, hence proving the possession of its own
+   private key.
 
    If the Join Response includes the 'kdc_cred_verify' parameter, the
    Client verifies the conveyed PoP evidence and considers the group
@@ -4956,6 +4957,8 @@ C.1.  Version -17 to -18
 
    *  Consistency fix: Clients always support the 'cnonce' parameter.
 
+   *  The KDC might not have to store the 'cnonce' from a Join Request.
+
    *  Fixes and editorial improvements.
 
 C.2.  Version -16 to -17