Normalizing references to sections in RFC9497

draft-irtf-cfrg-opaque.md

@@ -369,7 +369,7 @@ in {{!RFC4086}}, or pseudorandom function. For convenience, we define `nil` as a
 lack of value.
 
 All protocol messages and structures defined in this document use the syntax from
-{{?RFC8446, Section 3}}.
+Section 3 of {{?RFC8446}}.
 
 # Cryptographic Dependencies {#dependencies}
 
@@ -394,7 +394,7 @@ and the input to the function is provided by the client.  The client does not
 learn anything about the PRF other than the obtained output and the server
 learns nothing about the client's input or the function output.
 This specification depends on the prime-order OPRF construction specified
-in {{RFC9497}}, using the OPRF mode (0x00) from {{RFC9497, Section 3.1}}.
+as `modeOPRF` (`0x00`) from Section 3.1 of {{RFC9497}}.
 
 The following OPRF client APIs are used:
 
@@ -408,15 +408,15 @@ Moreover, the following OPRF server APIs are used:
 
 - BlindEvaluate(k, blinded_element): Evaluate blinded input element `blinded_element` using
   input key `k`, yielding output element `evaluated_element`. This is equivalent to
-  the BlindEvaluate function described in {{RFC9497, Section 3.3.1}}, where `k` is the private key parameter.
+  the BlindEvaluate function described in Section 3.3.1 of {{RFC9497}}, where `k` is the private key parameter.
 - DeriveKeyPair(seed, info): Create and output (`sk`, `pk`), consisting of a private and public key derived
-  deterministically from a `seed` and `info` parameter, as described in {{RFC9497, Section 3.2}}.
+  deterministically from a `seed` and `info` parameter, as described in Section 3.2 of {{RFC9497}}.
 
 Finally, this specification makes use of the following shared APIs and parameters:
 
 - SerializeElement(element): Map input `element` to a fixed-length byte array.
 - DeserializeElement(buf): Attempt to map input byte array `buf` to an OPRF group element.
-  This function can raise a DeserializeError upon failure; see {{RFC9497, Section 2.1}}
+  This function can raise a DeserializeError upon failure; see Section 2.1 of {{RFC9497}}
   for more details.
 - Noe: The size of a serialized OPRF group element output from SerializeElement.
 - Nok: The size of an OPRF private key as output from DeriveKeyPair.
@@ -1512,13 +1512,13 @@ as defined in {{?RISTRETTO=I-D.irtf-cfrg-ristretto255-decaf448}}.
 
 - DeriveDiffieHellmanKeyPair(seed): This function is implemented as
   DeriveKeyPair(seed, "OPAQUE-DeriveDiffieHellmanKeyPair"), where DeriveKeyPair is
-  as specified in {{RFC9497, Section 3.2}}. The public value from DeriveKeyPair
-  is encoded using SerializeElement from {{Section 2.1 of RFC9497}}.
+  as specified in Section 3.2 of {{RFC9497}}. The public value from DeriveKeyPair
+  is encoded using SerializeElement from Section 2.1 of {{RFC9497}}.
 - DiffieHellman(k, B): Implemented as scalar multiplication as described in
   {{Section 4 of RISTRETTO}} after decoding `B` from its encoded input using
   the Decode function in {{Section 4.3.1 of RISTRETTO}}. The output is then
   encoded using the SerializeElement function of the OPRF group described in
-  {{RFC9497, Section 2.1}}.
+  Section 2.1 of {{RFC9497}}.
 
 #### 3DH P-256
 
@@ -1527,13 +1527,13 @@ as defined in {{?NISTCurves=DOI.10.6028/NIST.FIPS.186-4}}.
 
 - DeriveDiffieHellmanKeyPair(seed): This function is implemented as
   DeriveKeyPair(seed, "OPAQUE-DeriveDiffieHellmanKeyPair"), where DeriveKeyPair is
-  as specified in {{RFC9497, Section 3.2}}. The public value from DeriveKeyPair
-  is encoded using SerializeElement from {{Section 2.1 of RFC9497}}.
+  as specified in Section 3.2 of {{RFC9497}}. The public value from DeriveKeyPair
+  is encoded using SerializeElement from Section 2.1 of {{RFC9497}}.
 - DiffieHellman(k, B): Implemented as scalar multiplication as described in
   {{NISTCurves}}, after decoding `B` from its encoded input using
   the compressed Octet-String-to-Elliptic-Curve-Point method according to {{NISTCurves}}.
   The output is then encoded using the SerializeElement function of the OPRF
-  group described in {{RFC9497, Section 2.1}}.
+  group described in Section 2.1 of {{RFC9497}}.
 
 #### 3DH Curve25519
 
@@ -1813,9 +1813,9 @@ def AuthServerFinalize(ke3):
 An OPAQUE-3DH configuration is a tuple (OPRF, KDF, MAC, Hash, KSF, Group, Context)
 such that the following conditions are met:
 
-- The OPRF protocol uses the "base mode" variant of {{RFC9497}} and implements
-  the interface in {{dependencies}}. Examples include ristretto255-SHA512 and
-  P256-SHA256.
+- The OPRF protocol uses the `modeOPRF` configuration of Section 3.1 of {{RFC9497}} and
+  implements the interface in {{dependencies}}. Examples include ristretto255-SHA512
+  and P256-SHA256.
 - The KDF, MAC, and Hash functions implement the interfaces in {{dependencies}}.
   Examples include HKDF {{RFC5869}} for the KDF, HMAC {{!RFC2104}} for the MAC,
   and SHA-256 and SHA-512 for the Hash functions. If an extensible output function
@@ -2097,15 +2097,15 @@ suitable for interoperable implementations.
   and includes necessary prime-order subgroup checks when receiving attacker-controlled
   values over the wire. This specification instantiates the prime-order group used for
   3DH using prime-order groups based on elliptic curves, as described in
-  {{RFC9497, Section 2.1}}. This specification also delegates OPRF group
-  choice and operations to {{!RFC9497}}. As such, the prime-order group as used
+  Section 2.1 of {{RFC9497}}. This specification also delegates OPRF group
+  choice and operations to Section 4 of {{RFC9497}}. As such, the prime-order group as used
   in the OPRF and 3DH as specified in this document both adhere to the requirements as
   {{JKX18}}.
 - {{JKX18}} specified DH-OPRF (see Appendix B) to instantiate
   the OPRF functionality in the protocol. A critical part of DH-OPRF is the
   hash-to-group operation, which was not instantiated in the original analysis.
   However, the requirements for this operation were included. This specification
-  instantiates the OPRF functionality based on the {{RFC9497}}, which
+  instantiates the OPRF functionality based on Section 3.3.1 of {{RFC9497}}, which
   is identical to the DH-OPRF functionality in {{JKX18}} and, concretely, uses
   the hash-to-curve functions in {{?RFC9380}}. All hash-to-curve
   methods in {{RFC9380}} are compliant with the requirement
@@ -2230,7 +2230,7 @@ order of computing discrete logarithms or solving Diffie-Hellman, Brown and
 Gallant {{BG04}} and Cheon {{Cheon06}} show an attack that slightly improves
 on generic attacks. For typical curves, the attack requires an infeasible
 number of calls to the OPRF or results in insignificant security loss;
-see {{RFC9497}} for more information. For OPAQUE, these attacks
+see Section 7.2.3 of {{RFC9497}} for more information. For OPAQUE, these attacks
 are particularly impractical as they translate into an infeasible number of
 failed authentication attempts directed at individual users.
 
@@ -2501,10 +2501,9 @@ outputs computed during the authentication of an unknown or unregistered user. N
 
 All values are encoded in hexadecimal strings. The configuration information
 includes the (OPRF, Hash, KSF, KDF, MAC, Group, Context) tuple, where the Group
-matches that which is used in the OPRF. These test vectors were generated using
-{{RFC9497}}. The KSF used for each test vector is the identity function
-(denoted Identity), which returns as output the input message supplied to the function
-without any modification, i.e., msg = Stretch(msg).
+matches that which is used in the OPRF. The KSF used for each test vector is the
+identity function (denoted Identity), which returns as output the input message
+supplied to the function without any modification, i.e., msg = Stretch(msg).
 
 ## Real Test Vectors {#real-vectors}