5. 数据结构和计算 (Data Structures and Computations)
本节规定前三节中指定的基于 ECC 的 key mechanism 所使用的数据结构和计算. 此处使用的表示语言与 TLS 中使用的语言相同. 由于本规范扩展 TLS, 这些描述应与 TLS 规范以及任何其他扩展 TLS 的规范中的描述合并. 这意味着 enum type 可能不会指定所有可能值, 而通过 select() 子句选择多种格式的 structure 也可能不会指出所有可能情况.
5.1. Client Hello Extension
本节规定两个可按 [RFC4366] 所述包含在 ClientHello message 中的 TLS extension: Supported Elliptic Curves Extension 和 Supported Point Formats Extension.
这些 extension 的发送时机:
任何提出 ECC cipher suite 的 ClientHello message 都 SHOULD 同时发送这些 extension.
这些 extension 的含义:
这些 extension 允许 client 枚举其支持的 elliptic curve 和/或能够解析的 point format.
这些 extension 的结构:
TLS extension 的一般结构在 [RFC4366] 中描述, 本规范向 ExtensionType 添加两个类型.
enum {
elliptic_curves(10),
ec_point_formats(11)
} ExtensionType;
-
elliptic_curves (Supported Elliptic Curves Extension): 表示 client 支持的 elliptic curve 集合. 对于该 extension, opaque extension_data 字段包含 NamedCurveList. 详情见第 5.1.1 节.
-
ec_point_formats (Supported Point Formats Extension): 表示 client 能够解析的 point format 集合. 对于该 extension, opaque extension_data 字段包含 ECPointFormatList. 详情见第 5.1.2 节.
发送方行为:
在 ClientHello message 中提出 ECC cipher suite 的 client 会附加这些 extension (以及任何其他 extension), 枚举其支持的 curve 和能够解析的 point format. client SHOULD 同时发送 Supported Elliptic Curves Extension 和 Supported Point Formats Extension. 如果确实发送 Supported Point Formats Extension, 它 MUST 在 point format 列表中包含值 0 (uncompressed).
接收方行为:
收到包含其中一个或两个 extension 的 ClientHello 的 server MUST 使用 client 枚举的能力来指导其选择适当的 cipher suite. 只有当 server 能够使用 client 支持的 curve 和 point format 成功完成 handshake 时, 才能协商所提出 ECC cipher suite 之一 (参见第 5.3 节和第 5.4 节).
注意: 参与 ECDHE_ECDSA key exchange 的 server 可以为其 certificate 中的 ECDSA 或 EdDSA key 与 ServerKeyExchange message 中的 ephemeral ECDH key 使用不同 curve. server MUST 在这两种情况下都考虑这些 extension.
如果 server 不理解 Supported Elliptic Curves Extension, 不理解 Supported Point Formats Extension, 或无法在限制自己使用所枚举 curve 和 point format 的情况下完成 ECC handshake, 则它 MUST NOT 协商使用 ECC cipher suite. 取决于 client 提出的其他 cipher suite 以及 server 支持的 cipher suite, 这可能因缺少共同 cipher suite 而导致 fatal handshake failure alert.
5.1.1. Supported Elliptic Curves Extension
RFC 4492 在 NamedCurve registry (现在重命名为 "TLS Supported Groups" registry, 尽管下面的枚举仍名为 NamedCurve) 中定义了 25 条不同 curve 供 TLS 使用. 其中只有三条得到较多使用. 本规范弃用其余 curve (编号 1-22). 本规范还弃用标识符为 0xFF01 和 0xFF02 的 explicit curve. 同时, 它添加 [RFC7748] 中定义的新 curve. 最终结果如下:
enum {
deprecated(1..22),
secp256r1 (23), secp384r1 (24), secp521r1 (25),
x25519(29), x448(30),
reserved (0xFE00..0xFEFF),
deprecated(0xFF01..0xFF02),
(0xFFFF)
} NamedCurve;
注意, 后续其他规范已向该枚举添加其他值. 其中一些值根本不是 curve, 而是 finite field group. 参见 [RFC7919].
secp256r1 等: 表示支持对应 named curve 或 group. named curve secp256r1、secp384r1 和 secp521r1 在 SEC 2 [SECG-SEC2] 中规定. ANSI X9.62 [ANSI.X9-62.2005] 和 FIPS 186-4 [FIPS.186-4] 也推荐这些 curve. 本文档其余部分将这三条 curve 称为 "NIST curves", 因为它们最初由 National Institute of Standards and Technology 标准化. curve x25519 和 x448 在 [RFC7748] 中定义. 值 0xFE00 到 0xFEFF 保留给 private use.
本文档的前身还支持显式定义的 prime curve 和 char2 curve, 但本规范弃用它们.
NamedCurve name space (现题为 "TLS Supported Groups") 由 IANA 维护. 关于如何添加新的 value assignment, 参见第 9 节.
struct {
NamedCurve named_curve_list<2..2^16-1>
} NamedCurveList;
named_curve_list 中的项目按 client 偏好排序 (最偏好的选择在前).
例如, 只支持 secp256r1 (又名 NIST P-256; 值 23 = 0x0017) 和 secp384r1 (又名 NIST P-384; 值 24 = 0x0018), 且偏好使用 secp256r1 的 client, 会包含由以下 octet 组成的 TLS extension. 注意, 前两个 octet 表示 extension type (Supported Elliptic Curves Extension):
00 0A 00 06 00 04 00 17 00 18
5.1.2. Supported Point Formats Extension
enum {
uncompressed (0),
deprecated (1..2),
reserved (248..255)
} ECPointFormat;
struct {
ECPointFormat ec_point_format_list<1..2^8-1>
} ECPointFormatList;
上面的 ECPointFormat 定义中包含三种 point format. 本规范弃用除 uncompressed point format 之外的所有格式. 本文档的实现 MUST 对其所有支持的 curve 支持 uncompressed format, 并且 MUST NOT 对本规范定义的 curve 支持其他格式. 出于向后兼容目的, point format list extension MAY 仍然包含, 并且只包含一个值: uncompressed point format (0). RFC 4492 规定, 如果缺少该 extension, 则表示仅支持 uncompressed point format, 因此与支持 uncompressed format 的实现进行互操作时, 无论有无该 extension 都应可工作.
如果 client 发送该 extension, 但 extension 不包含 uncompressed point format, 且 client 已使用 Supported Groups extension 表示支持本规范定义的任一 curve, 则 server MUST 中止 handshake 并返回 illegal_parameter alert.
ECPointFormat name space (现题为 "TLS EC Point Formats") 由 IANA 维护. 关于如何添加新的 value assignment, 参见第 9 节.
符合本规范且不支持其他 curve 的 client MUST 发送以下 octet; 注意前两个 octet 表示 extension type (Supported Point Formats Extension):
00 0B 00 02 01 00
5.1.3. signature_algorithms Extension 和 EdDSA
[RFC5246] 第 7.4.1.4.1 节定义的 signature_algorithms extension 会公告 client 支持的 signature algorithm 与 hash function 组合. EdDSA 的纯形式 (non-prehashed) 在签名数据之前不对数据进行 hash. 因此, 在该 extension 中将它们与 hash function 组合没有意义.
为了实现 bits-on-the-wire 层面与 TLS 1.3 的兼容性, 我们在 "TLS HashAlgorithm" registry 中定义一个新的 dummy value, 称为 "Intrinsic" (值 8), 表示 hashing 是 signature algorithm 的内在组成部分.
在 signature_algorithms extension 中表示 ed25519 和 ed448 时, 其值应分别为 (8,7) 和 (8,8).
5.2. Server Hello Extension
本节规定一个可按 [RFC4366] 所述包含在 ServerHello message 中的 TLS extension, 即 Supported Point Formats Extension.
该 extension 的发送时机:
协商 ECC cipher suite 时, 如果 ClientHello message 包含 Supported Point Formats Extension, 则 ServerHello message 中会包含 Supported Point Formats Extension 作为响应.
该 extension 的含义:
该 extension 允许 server 枚举它能够解析的 point format (用于使用 ECDHE_ECDSA、ECDHE_RSA 或 ECDH_anon key exchange algorithm 时将在 ServerKeyExchange message 中出现的 curve).
该 extension 的结构:
server 的 Supported Point Formats Extension 与 client 的 Supported Point Formats Extension 具有相同结构 (参见第 5.1.2 节). 此处 ec_point_format_list 中的项目按 server 偏好排序 (最偏好的选择在前). 注意, server MAY 包含 client 列表中没有的项目. 然而, 在没有 extension 的情况下, 本规范只允许一种 point format, 因此实际上没有不匹配的机会.
发送方行为:
server 在响应包含 Supported Point Formats Extension 的 ClientHello message 时, 如果选择了 ECC cipher suite, 会将该 extension (以及其他 extension) 附加到其 ServerHello message, 枚举它能够解析的 point format. 使用 Supported Point Formats Extension 时, 它 MUST 在 point format 列表中包含值 0 (uncompressed).
接收方行为:
收到包含 Supported Point Formats Extension 的 ServerHello message 的 client MUST 在 handshake 期间遵守 server 对 point format 的选择 (参见第 5.6 节和第 5.7 节). 如果 ServerHello 中没有收到 Supported Point Formats Extension, 则等同于一个只允许 uncompressed point format 的 extension.
5.3. Server Certificate
该 message 的发送时机:
该 message 在所有非匿名、基于 ECC 的 key exchange algorithm 中发送.
该 message 的含义:
该 message 用于以可认证方式将 server 的 static public key 传递给 client. 下表显示适用于每种 key exchange algorithm 的 server certificate type. ECC public key MUST 按第 5.9 节所述编码在 certificate 中.
注意: server 的 Certificate message 能够携带 certificate chain. 表 2 中提到的限制只适用于 server certificate (chain 中第一个 certificate).
| Algorithm | Server Certificate Type |
|---|---|
| ECDHE_ECDSA | Certificate MUST 包含可用于 ECDSA 或 EdDSA 的 public key. |
| ECDHE_RSA | Certificate MUST 包含 RSA public key. |
表 2: Server Certificate Type
该 message 的结构:
与 TLS Certificate format 相同.
发送方行为:
server 构造适当的 certificate chain, 并在 Certificate message 中将其传递给 client. 如果 client 已使用 Supported Elliptic Curves Extension, 则 server certificate 中的 public key MUST 遵守 client 对 elliptic curve 的选择. 无法满足该要求的 server MUST NOT 在其 ServerHello message 中选择 ECC cipher suite.)
接收方行为:
client 验证 certificate chain, 提取 server 的 public key, 并检查 key type 是否适合协商出的 key exchange algorithm. (fatal handshake failure 的一个可能原因是超出了 client 处理 elliptic curve 和 point format 的能力; 参见第 5.1 节.)
5.4. Server Key Exchange
该 message 的发送时机:
使用 ECDHE_ECDSA、ECDHE_RSA 和 ECDH_anon key exchange algorithm 时发送该 message.
该 message 的含义:
该 message 用于将 server 的 ephemeral ECDH public key (以及对应的 elliptic curve domain parameter) 传递给 client.
ECCurveType enum 过去包含 explicit prime curve 和 explicit char2 curve 的值. 这些值现在已弃用, 因此只剩一个值:
该 message 的结构:
enum {
deprecated (1..2),
named_curve (3),
reserved(248..255)
} ECCurveType;
值 named_curve 表示使用 named curve. 该选项现在是唯一剩余格式.
值 248 到 255 保留给 private use.
ECCurveType name space (现题为 "TLS EC Curve Types") 由 IANA 维护. 关于如何添加新的 value assignment, 参见第 9 节.
RFC 4492 曾规定 ECCurve structure 和 ECBasisType structure. 这两者现在都被省略, 因为它们只用于现在已弃用的 explicit curve.
struct {
opaque point <1..2^8-1>;
} ECPoint;
point: 这是 elliptic curve point 的 byte string 表示, 遵循 [ANSI.X9-62.2005] 第 4.3.6 节中的转换例程. 该 byte string 可以用 uncompressed、compressed 或 hybrid format 表示 elliptic curve point, 但本规范弃用除 uncompressed format 之外的所有格式. 为方便起见, 第 5.4.1 节重复给出 NIST curve 的格式. 对于 X25519 和 X448 curve, 唯一有效表示是 [RFC7748] 中规定的表示, 即 point 的 u 值的 32-octet 或 56-octet 表示. 该 structure MUST NOT 与 Ed25519 和 Ed448 public key 一起使用.
struct {
ECCurveType curve_type;
select (curve_type) {
case named_curve:
NamedCurve namedcurve;
};
} ECParameters;
curve_type: 标识 elliptic curve domain parameter 的类型.
namedCurve: 指定一组推荐的 elliptic curve domain parameter. NamedCurve 中凡是指向能够执行 Diffie-Hellman 的 curve 的值都被允许. 随着 explicit curve 被弃用, 现在这包括所有 NamedCurve 值.
struct {
ECParameters curve_params;
ECPoint public;
} ServerECDHParams;
curve_params: 指定与 ECDH public key 关联的 elliptic curve domain parameter.
public: ephemeral ECDH public key.
ServerKeyExchange message 按如下方式扩展.
enum {
ec_diffie_hellman
} KeyExchangeAlgorithm;
- ec_diffie_hellman: 表示 ServerKeyExchange message 包含 ECDH public key.
select (KeyExchangeAlgorithm) {
case ec_diffie_hellman:
ServerECDHParams params;
Signature signed_params;
} ServerKeyExchange;
-
params: 指定 ECDH public key 及其关联 domain parameter.
-
signed_params: 对 params 的 hash, 并应用适合该 hash 的 signature. 签名使用与 server 的 Certificate message 中 certified public key 对应的 private key.
enum {
ecdsa(3),
ed25519(7)
ed448(8)
} SignatureAlgorithm;
select (SignatureAlgorithm) {
case ecdsa:
digitally-signed struct {
opaque sha_hash[sha_size];
};
case ed25519,ed448:
digitally-signed struct {
opaque rawdata[rawdata_size];
};
} Signature;
ServerKeyExchange.signed_params.sha_hash
SHA(ClientHello.random + ServerHello.random +
ServerKeyExchange.params);
ServerKeyExchange.signed_params.rawdata
ClientHello.random + ServerHello.random +
ServerKeyExchange.params;
注意: 对于 ECDHE_RSA key exchange algorithm, SignatureAlgorithm 为 "rsa"; 对于 ECDH_anon, SignatureAlgorithm 为 "anonymous". 这些情况在 TLS 中定义. 对于 ECDHE_ECDSA, SignatureAlgorithm 为 "ecdsa" 或 "eddsa".
ECDSA signature 按第 5.10 节所述生成和验证. 在上述 sha_hash 模板中, SHA 可以表示 SHA-1 以外的 hash algorithm. 根据 ANSI X9.62, ECDSA signature 由一对整数 r 和 s 组成. digitally-signed 元素编码为 opaque vector <0..2^16-1>, 其内容是与以下 ASN.1 记法对应的 DER encoding.
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
协议中以及符合 [RFC8410] 的 certificate 中的 EdDSA signature 均按 [RFC8032] 生成和验证. digitally-signed 元素编码为 opaque vector <0..2^16-1>, 其内容包含 EdDSA signing algorithm 输出的 octet string.
发送方行为:
server 根据 IEEE 1363 [IEEE.P1363] 中的 ECKAS-DH1 scheme, 选择 elliptic curve domain parameter 以及与这些参数对应的 ephemeral ECDH public key. 它使用上面定义的格式, 在 ServerKeyExchange message 中将这些信息传递给 client.
接收方行为:
client 验证 signature (如果存在), 并从 ServerKeyExchange message 中取得 server 的 elliptic curve domain parameter 和 ephemeral ECDH public key. (fatal handshake failure 的一个可能原因是超出了 client 处理 elliptic curve 和 point format 的能力; 参见第 5.1 节.)
5.4.1. NIST Curve 的 Uncompressed Point Format
以下表示 ServerKeyExchange record 中表示 ECPoint 的 wire format. 该表示的第一个 octet 指示形式, 可能是 compressed、uncompressed 或 hybrid. 对这些 curve, 本规范仅支持 uncompressed format. 其后是 X 值的 binary representation, 使用 "big-endian" 或 "network" 格式; 再后是 Y 值的 binary representation, 同样使用 "big-endian" 或 "network" 格式. 其中没有内部 length marker, 因此每个数字表示所占 octet 数由 curve parameter 隐含确定. 对 P-256, 这意味着 X 和 Y 各使用 32 个 octet, 必要时左侧以零填充. 对 P-384, 它们各使用 48 个 octet; 对 P-521, 各使用 66 个 octet.
更形式化的表示如下:
enum {
uncompressed(4),
(255)
} PointConversionForm;
struct {
PointConversionForm form;
opaque X[coordinate_length];
opaque Y[coordinate_length];
} UncompressedPointRepresentation;
5.5. Certificate Request
该 message 的发送时机:
请求 client authentication 时发送该 message.
该 message 的含义:
server 使用该 message 建议可接受的 client authentication method.
该 message 的结构:
TLS CertificateRequest message 按如下方式扩展.
enum {
ecdsa_sign(64),
deprecated1(65), /* was rsa_fixed_ecdh */
deprecated2(66), /* was ecdsa_fixed_ecdh */
(255)
} ClientCertificateType;
- ecdsa_sign: 表示 server 希望使用第 3 节中规定的对应 client authentication method.
注意, RFC 4492 还定义了包含 fixed ECDH public key 的 RSA 和 ECDSA certificate. 这些机制几乎没有实现, 因此本规范弃用它们.
发送方行为:
server 决定希望使用哪些 client authentication method, 并使用上面定义的格式将这些信息传递给 client.
接收方行为:
client 确定自己是否拥有适用于所请求任一 method 的合适 certificate, 以及是否继续执行 client authentication.
5.6. Client Certificate
该 message 的发送时机:
当 client 拥有合适 certificate 并决定继续执行 client authentication 时, 该 message 作为对 CertificateRequest 的响应发送. (注意, 如果 server 已使用 Supported Point Formats Extension, 则只有当 certificate 中指定的 public key point 为 uncompressed 时, 该 certificate 才能被认为适合与 ECDSA_sign authentication method 一起使用, 因为这是唯一仍被支持的 point format.)
该 message 的含义:
该 message 用于以可认证方式将 client 的 static public key 传递给 server. ECC public key 必须按第 5.9 节所述编码在 certificate 中. certificate MUST 包含可用于 ECDSA 或 EdDSA 的 public key.
注意: client 的 Certificate message 能够携带 certificate chain. 上述限制只适用于 client certificate (chain 中第一个 certificate).
该 message 的结构:
与 TLS client Certificate format 相同.
发送方行为:
client 构造适当的 certificate chain, 并在 Certificate message 中将其传递给 server.
接收方行为:
TLS server 验证 certificate chain, 提取 client 的 public key, 并检查 key type 是否适合 client authentication method.
5.7. Client Key Exchange
该 message 的发送时机:
该 message 在所有 key exchange algorithm 中发送. 它包含 client 的 ephemeral ECDH public key.
该 message 的含义:
该 message 用于传递属于 client 的 key exchange 相关 ephemeral data (例如其 ephemeral ECDH public key).
该 message 的结构:
TLS ClientKeyExchange message 按如下方式扩展.
enum {
implicit,
explicit
} PublicValueEncoding;
- implicit, explicit: 对 ECC cipher suite, 这表示 client 的 ECDH public key 是位于 client certificate 中 ("implicit"), 还是作为 ephemeral ECDH public key 在 ClientKeyExchange message 中提供 ("explicit"). implicit encoding 已弃用, 此处仅为向后兼容而保留.
struct {
ECPoint ecdh_Yc;
} ClientECDiffieHellmanPublic;
ecdh_Yc: 包含 client 的 ephemeral ECDH public key, 形式为 byte string ECPoint.point, 它可以用 uncompressed format 表示 elliptic curve point.
struct {
select (KeyExchangeAlgorithm) {
case ec_diffie_hellman: ClientECDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
发送方行为:
client 选择与其从 server 收到的参数对应的 ephemeral ECDH public key. 格式与第 5.4 节相同.
接收方行为:
server 从 ClientKeyExchange message 中取得 client 的 ephemeral ECDH public key, 并检查它是否位于与 server 的 ECDH key 相同的 elliptic curve 上.
5.8. Certificate Verify
该 message 的发送时机:
当 client 发送包含可用于 digital signature 的 public key 的 client certificate 时, 会发送该 message.
该 message 的含义:
该 message 包含一个 signature, 用于证明拥有与 client 的 Certificate message 中 public key 对应的 private key.
该 message 的结构:
TLS CertificateVerify message 及底层 signature type 在 TLS 基础规范中定义, 后者在本文档第 5.4 节中扩展. 对于 "ecdsa" 和 "eddsa" 情况, CertificateVerify message 中的 signature 字段分别包含对目前为止已交换 handshake message 计算出的 ECDSA 或 EdDSA signature, 这与使用其他 signing algorithm 的 CertificateVerify 完全类似:
CertificateVerify.signature.sha_hash
SHA(handshake_messages);
CertificateVerify.signature.rawdata
handshake_messages;
ECDSA signature 按第 5.10 节所述计算, 上述 sha_hash 模板中的 SHA 因而可以表示 SHA-1 以外的 hash algorithm. 根据 ANSI X9.62, ECDSA signature 由一对整数 r 和 s 组成. digitally-signed 元素编码为 opaque vector <0..2^16-1>, 其内容是与以下 ASN.1 记法 [X.680] 对应的 DER encoding [X.690].
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
EdDSA signature 按 [RFC8032] 生成和验证. digitally-signed 元素编码为 opaque vector <0..2^16-1>, 其内容包含 EdDSA signing algorithm 输出的 octet string.
发送方行为:
client 对从 client hello 开始到但不包括该 message 为止发送或接收的所有 handshake message 计算其 signature. 它使用与其 certified public key 对应的 private key 计算 signature, 并以上面定义的格式传递.
接收方行为:
server 从 CertificateVerify message 中提取 client 的 signature, 并使用它在 client 的 Certificate message 中收到的 public key 验证该 signature.
5.9. Elliptic Curve Certificate
包含 ECC public key 或使用 ECDSA 签名的 X.509 certificate MUST 符合 [RFC3279] 或替代/扩展它的其他 RFC. 包含 ECC public key 或使用 EdDSA 签名的 X.509 certificate MUST 符合 [RFC8410]. client SHOULD 使用 ANSI X9.62、FIPS 186-4 和 SEC 2 [SECG-SEC2] 中推荐的 elliptic curve domain parameter, 或使用 [RFC8032] 中推荐的参数.
使用 Ed25519 algorithm 的 EdDSA key MUST 使用 ed25519 signature algorithm, Ed448 key MUST 使用 ed448 signature algorithm. 本文档不定义 Ed25519ph 和 Ed448ph key 与 TLS 的配合使用. Ed25519、Ed25519ph、Ed448 和 Ed448ph key MUST NOT 与 ECDSA 一起使用.
5.10. ECDH、ECDSA 和 RSA 计算
NIST curve 的所有 ECDH 计算 (包括 parameter 和 key generation, 以及 shared secret calculation) 都按 [IEEE.P1363] 执行, 使用 ECKAS-DH1 scheme, 并以 identity map 作为 Key Derivation Function (KDF), 使 premaster secret 成为 ECDH shared secret elliptic curve point 的 x-coordinate, 表示为 octet string. 注意, FE2OSP (Field Element to Octet String Conversion Primitive) 输出的该 octet string (IEEE 1363 术语中的 Z) 对任何给定 field 都具有固定长度; 该 octet string 中出现的前导零 MUST NOT 被截断.
(注意, 使用 identity KDF 是一个技术细节. 完整情况是, ECDH 实际上与非平凡 KDF 一起使用, 因为 TLS 除计算 master secret 外不会直接使用 premaster secret. 在 TLS 1.0 和 1.1 中, 这意味着基于 MD5 和 SHA-1 的 TLS Pseudorandom Function (PRF) 充当 KDF; 在 TLS 1.2 中, KDF 由 ciphersuite 决定, 而未来 TLS 版本或未来引入的新 TLS extension 可能改变这一计算.)
使用 X25519 (curve x25519) 的 ECDHE key exchange 如下: (1) 每一方均匀随机选择 secret key d, 并计算对应 public key x = X25519(d, G); (2) 各方交换其 public key, 并计算 shared secret x_S = X25519(d, x_peer); (3) 如果任一方得到全零 x_S, 它 MUST 中止 handshake (这是 X25519 和 X448 定义所要求的). X448 的 ECDHE 工作方式类似, 只是将 X25519 替换为 X448, 将 x25519 替换为 x448. 派生出的 shared secret 直接用作 premaster secret; 使用 X25519 的 ECDHE 时它始终正好是 32 字节, 使用 X448 的 ECDHE 时始终正好是 56 字节.
所有 ECDSA 计算 MUST 按 ANSI X9.62 或其后续版本执行. 待签名/验证的数据先进行 hash, 结果直接送入 ECDSA algorithm, 不再额外 hash. MUST 使用 [FIPS.180-4] 中的安全 hash function, 如 SHA-256、SHA-384 或 SHA-512.
所有 EdDSA 计算 MUST 按 [RFC8032] 或其后续版本执行. 待签名/验证的数据直接送入 EdDSA algorithm, 不进行 hash (EdDSA 会在内部通过 "prehash" function PH 处理数据). Ed448 的 context parameter MUST 设置为空字符串.
RFC 4492 曾预期会标准化一种在 certificate 中指定所需 hash function 的机制, 可能是在 subjectPublicKeyInfo 的 parameters 字段中. 这种标准化从未发生, 因此 TLS 1.1 及更早版本使用 SHA-1 (EdDSA 除外, 它使用 identity function). TLS 1.2 向 DigitallySigned struct 添加 SignatureAndHashAlgorithm parameter, 从而允许灵活选择 signature hash. EdDSA signature 的 HashAlgorithm MUST 为 8 (Intrinsic).
所有 RSA signature 必须按 [RFC8017] 第 7.2 节生成和验证.
5.11. Public Key Validation
使用 NIST curve 时, 每一方 MUST 验证其 peer 在 ClientKeyExchange 和 ServerKeyExchange message 中发送的 public key. 接收方 MUST 检查 peer public value 中的 x 和 y 参数是否满足 curve equation: y^2 = x^3 + ax + b mod p. 详情见 [Menezes] 第 2.3 节. 如果不这样做, 攻击者就能获取 private key 相关信息; 如果该 key 并非真正 ephemeral, 攻击者可能只需几个 request 就恢复整个 private key.
使用 X25519 和 X448 时, 接收方 MUST 检查计算出的 premaster secret 是否为全零值, 如果是, 则按 [RFC7748] 第 6 节所述中止 handshake.
Ed25519 和 Ed448 在内部将 public key validation 作为 signature verification 的一部分执行.