From afe2308fa0602ab07a734b499e03d9bd47bb768f Mon Sep 17 00:00:00 2001
From: ID Bot <idbot@example.com>
Date: Thu, 5 Oct 2023 21:23:21 +0000
Subject: [PATCH] Script updating gh-pages from 1260203. [ci skip]

---
 draft-irtf-cfrg-opaque.html | 5 +++--
 draft-irtf-cfrg-opaque.txt  | 6 ++++--
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/draft-irtf-cfrg-opaque.html b/draft-irtf-cfrg-opaque.html
index 13d36233..9c3f2dcd 100644
--- a/draft-irtf-cfrg-opaque.html
+++ b/draft-irtf-cfrg-opaque.html
@@ -3327,7 +3327,7 @@ <h3 id="name-implementation-safeguards">
 the client password as input to the OPRF for registration and authentication.
 However, if <code>client_identity</code> can be bound to the client's registration record
 (in that the identity will not change during the lifetime of the record),
-then an implementation can incorporate <code>client_identity</code> alongside the
+then an implementation SHOULD incorporate <code>client_identity</code> alongside the
 password as input to the OPRF. This provides additional client-side entropy
 which can supplement the entropy that should be introduced by the server during
 an honest execution of the protocol. This also provides domain separation
@@ -3699,7 +3699,8 @@ <h3 id="name-random-key-robust-macs">
 key-robustness, whereas HMAC with a collision-resistant hash function does
 satisfy key-robustness.<a href="#section-10.7-1" class="pilcrow">¶</a></p>
 <p id="section-10.7-2">An application can choose to use a non-key-robust MAC within the AKE portion of
-the protocol described in <a href="#protocol-3dh" class="auto internal xref">Section 6.4</a>.<a href="#section-10.7-2" class="pilcrow">¶</a></p>
+the protocol described in <a href="#protocol-3dh" class="auto internal xref">Section 6.4</a>, but it MUST use a key-robust MAC
+for the creation of the <code>auth_tag</code> parameter in <a href="#envelope-creation" class="auto internal xref">Section 4.1.2</a>.<a href="#section-10.7-2" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="validation">
diff --git a/draft-irtf-cfrg-opaque.txt b/draft-irtf-cfrg-opaque.txt
index 554b8298..2ca32ac8 100644
--- a/draft-irtf-cfrg-opaque.txt
+++ b/draft-irtf-cfrg-opaque.txt
@@ -1788,7 +1788,7 @@ def AuthServerRespond(cleartext_credentials, server_private_key, client_public_k
    client password as input to the OPRF for registration and
    authentication.  However, if client_identity can be bound to the
    client's registration record (in that the identity will not change
-   during the lifetime of the record), then an implementation can
+   during the lifetime of the record), then an implementation SHOULD
    incorporate client_identity alongside the password as input to the
    OPRF.  This provides additional client-side entropy which can
    supplement the entropy that should be introduced by the server during
@@ -2163,7 +2163,9 @@ def AuthServerRespond(cleartext_credentials, server_private_key, client_public_k
    resistant hash function does satisfy key-robustness.
 
    An application can choose to use a non-key-robust MAC within the AKE
-   portion of the protocol described in Section 6.4.
+   portion of the protocol described in Section 6.4, but it MUST use a
+   key-robust MAC for the creation of the auth_tag parameter in
+   Section 4.1.2.
 
 10.8.  Input Validation