Draft: draft-ietf-tls-rfc8446bis

Commentary: FIPS 186 - 4 is obsolete Curve definitions have moved to the new NIST SP 800 - 186 ANSI X9.62 is behind a paywall and should be avoided if possible . References behind paywall can not be accessed by most readers . This makes it harder to implement and to evaluate the security of the protocol . FIPS 186 - 5 removed the dependency on ANSI X9.62 and defines ECDSA itself . Point validation is defined in the new NIST SP 800 - 186 .
Paragraph (version A):
Authentication: The server side of the channel is always
authenticated; the client side is optionally authenticated.
Authentication can happen via asymmetric cryptography (e.g., RSA
RSA, the Elliptic Curve Digital Signature Algorithm (ECDSA) ECDSA,
or the Edwards-Curve Digital Signature Algorithm (EdDSA) RFC8032)
or a symmetric pre-shared key (PSK).
Paragraph (version B):
Authentication: The server side of the channel is always
authenticated; the client side is optionally authenticated.
Authentication can happen via asymmetric cryptography (e.g., RSA
RSA, the Elliptic Curve Digital Signature Algorithm (ECDSA) DSS,
or the Edwards-Curve Digital Signature Algorithm (EdDSA) RFC8032)
or a symmetric pre-shared key (PSK).
Paragraph (version A):
Indicates a signature algorithm using ECDSA ECDSA, the
corresponding curve as defined in ANSI X9.62 ECDSA and FIPS 186-4
DSS, and the corresponding hash algorithm as defined in SHS.  The
signature is represented as a DER-encoded X690 ECDSA-Sig-Value
structure as defined in RFC4492.
Paragraph (version B):
Indicates a signature algorithm using ECDSA DSS, the corresponding
curve as defined in NIST SP 800-186 ECDP, and the corresponding
hash algorithm as defined in SHS.  The signature is represented as
a DER-encoded X690 ECDSA-Sig-Value structure as defined in
RFC4492.
Paragraph (version A):
Indicates support for the corresponding named curve, defined in
either FIPS 186-4 DSS or in RFC7748.  Values 0xFE00 through 0xFEFF
are reserved for Private Use RFC8126.
Paragraph (version B):
Indicates support for the corresponding named curve, defined in
either NIST SP 800-186 ECDP or in RFC7748.  Values 0xFE00 through
0xFEFF are reserved for Private Use RFC8126.
Paragraph (version A):
For the curves secp256r1, secp384r1, and secp521r1, peers MUST
validate each other's public value Q by ensuring that the point is a
valid point on the elliptic curve.  The appropriate validation
procedures are defined in Section 4.3.7 of ECDSA and alternatively in
Section 5.6.2.3 of KEYAGREEMENT.  This process consists of three
steps: (1) verify that Q is not the point at infinity (O), (2) verify
that for Q = (x, y) both integers x and y are in the correct
interval, and (3) ensure that (x, y) is a correct solution to the
elliptic curve equation.  For these curves, implementors do not need
to verify membership in the correct subgroup.
Paragraph (version B):
For the curves secp256r1, secp384r1, and secp521r1, peers MUST
validate each other's public value Q by ensuring that the point is a
valid point on the elliptic curve.  The appropriate validation
procedures are defined in Appendix D.1 of ECDP and alternatively in
Section 5.6.2.3 of KEYAGREEMENT.  This process consists of three
steps: (1) verify that Q is not the point at infinity (O), (2) verify
that for Q = (x, y) both integers x and y are in the correct
interval, and (3) ensure that (x, y) is a correct solution to the
elliptic curve equation.  For these curves, implementors do not need
to verify membership in the correct subgroup.