5. データ構造と計算

本セクションでは、前の3つのセクションで指定された ECC ベースの鍵メカニズムで使用されるデータ構造と計算について規定する。ここで使用される記述言語は、TLS で使用されるものと同じである。本仕様は TLS を拡張するため、これらの記述は TLS 仕様および TLS を拡張するその他の仕様の記述と統合されるべきである。これは、enum 型がすべての可能な値を指定しない場合があり、select() 句で選択される複数の形式を持つ構造体がすべての可能なケースを示さない場合があることを意味する。

5.1. Client Hello 拡張

本セクションでは、[RFC4366] で記述されているように ClientHello メッセージに含めることができる2つの TLS 拡張を指定する：Supported Elliptic Curves Extension と Supported Point Formats Extension である。

これらの拡張が送信される場合：

これらの拡張は、ECC 暗号スイートを提案する任意の ClientHello メッセージと共に送信されるべきである (SHOULD)。

これらの拡張の意味：

これらの拡張により、クライアントはサポートする楕円曲線および/または解析可能なポイント形式を列挙できる。

これらの拡張の構造：

TLS 拡張の一般的な構造は [RFC4366] で記述されており、本仕様では ExtensionType に2つのタイプを追加する。

   enum {
       elliptic_curves(10),
       ec_point_formats(11)
   } ExtensionType;

• elliptic_curves (Supported Elliptic Curves Extension): クライアントがサポートする楕円曲線のセットを示す。この拡張の場合、不透明な extension_data フィールドには NamedCurveList が含まれる。詳細はセクション 5.1.1 を参照。

• ec_point_formats (Supported Point Formats Extension): クライアントが解析可能なポイント形式のセットを示す。この拡張の場合、不透明な extension_data フィールドには ECPointFormatList が含まれる。詳細はセクション 5.1.2 を参照。

送信者の動作：

ClientHello メッセージで ECC 暗号スイートを提案するクライアントは、これらの拡張を（他の拡張と共に）追加し、サポートする曲線と解析可能なポイント形式を列挙する。クライアントは、Supported Elliptic Curves Extension と Supported Point Formats Extension の両方を送信すべきである (SHOULD)。Supported Point Formats Extension が実際に送信される場合、それはポイント形式のリストの項目の1つとして値0（非圧縮）を含まなければならない (MUST)。

受信者の動作：

これらの拡張の一方または両方を含む ClientHello を受信したサーバは、適切な暗号スイートの選択を導くために、クライアントが列挙した機能を使用しなければならない (MUST)。サーバは、クライアントがサポートする曲線とポイント形式を使用しながらハンドシェイクを正常に完了できる場合にのみ、提案された ECC 暗号スイートの1つを交渉しなければならない（cf. セクション 5.3 および 5.4）。

注：ECDHE_ECDSA 鍵交換に参加するサーバは、証明書内の ECDSA または EdDSA 鍵と、ServerKeyExchange メッセージ内の一時 ECDH 鍵に対して異なる曲線を使用してもよい。サーバは、両方のケースで拡張を考慮しなければならない (MUST)。

サーバが Supported Elliptic Curves Extension を理解しない、Supported Point Formats Extension を理解しない、または列挙された曲線とポイント形式に制限しながら ECC ハンドシェイクを完了できない場合、ECC 暗号スイートの使用を交渉してはならない (MUST NOT)。クライアントによって提案され、サーバによってサポートされる他の暗号スイートによっては、これにより共通の暗号スイートがないために致命的なハンドシェイク失敗アラートが発生する可能性がある。

5.1.1. Supported Elliptic Curves Extension

RFC 4492 は、TLS で使用するために NamedCurve レジストリ（現在は「TLS Supported Groups」レジストリと改名されたが、以下の列挙は依然として NamedCurve という名前である）に25の異なる曲線を定義した。広く使用されているのは3つだけである。本仕様では、残りの（番号1-22）を廃止 (deprecating) する。本仕様はまた、識別子 0xFF01 および 0xFF02 を持つ明示的な曲線も廃止する。また、[RFC7748] で定義された新しい曲線を追加する。最終的な結果は以下の通りである：

        enum {
            deprecated(1..22),
            secp256r1 (23), secp384r1 (24), secp521r1 (25),
            x25519(29), x448(30),
            reserved (0xFE00..0xFEFF),
            deprecated(0xFF01..0xFF02),
            (0xFFFF)
        } NamedCurve;

他の仕様がその後、この列挙に他の値を追加していることに注意すること。それらの値の中には、曲線ではなく有限体群であるものもある。[RFC7919] を参照。

secp256r1 など: 対応する名前付き曲線またはグループのサポートを示す。名前付き曲線 secp256r1、secp384r1、および secp521r1 は SEC 2 [SECG-SEC2] で指定されている。これらの曲線は、ANSI X9.62 [ANSI.X9-62.2005] および FIPS 186-4 [FIPS.186-4] でも推奨されている。本文書の残りの部分では、これら3つの曲線を「NIST 曲線」と呼ぶ。これらは元々、米国国立標準技術研究所 (NIST) によって標準化されたためである。曲線 x25519 および x448 は [RFC7748] で定義されている。値 0xFE00 から 0xFEFF は私用 (Private Use) のために予約されている。

本文書の前身では、明示的に定義された素数および char2 曲線もサポートしていたが、これらは本仕様によって廃止される。

NamedCurve 名前空間（現在は "TLS Supported Groups" というタイトル）は IANA によって維持されている。新しい値の割り当てがどのように追加されるかについては、セクション9を参照のこと。

        struct {
            NamedCurve named_curve_list<2..2^16-1>
        } NamedCurveList;

named_curve_list 内の項目は、クライアントの好み（最も好ましい選択が最初）に従って順序付けられる。

例として、secp256r1 (別名 NIST P-256; 値 23 = 0x0017) と secp384r1 (別名 NIST P-384; 値 24 = 0x0018) のみをサポートし、secp256r1 の使用を好むクライアントは、以下のオクテットで構成される TLS 拡張を含めることになる。最初の2オクテットは拡張タイプ（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 の定義には3つのポイント形式が含まれていた。本仕様では、非圧縮ポイント形式以外のすべてを廃止する。本文書の実装は、サポートされているすべての曲線に対して非圧縮形式をサポートしなければならず (MUST)、本仕様で定義されている曲線に対して他の形式をサポートしてはならない (MUST NOT)。後方互換性のために、ポイント形式リスト拡張は依然として含まれてもよいが (MAY)、値として非圧縮ポイント形式 (0) の1つだけを含むことができる。RFC 4492 は、この拡張がない場合、非圧縮ポイント形式のみがサポートされることを意味すると規定していたため、非圧縮形式をサポートする実装との相互運用性は、拡張の有無にかかわらず機能するはずである。

クライアントが拡張を送信し、拡張に非圧縮ポイント形式が含まれておらず、クライアントが Supported Groups 拡張を使用して本仕様で定義されている曲線のいずれかのサポートを示している場合、サーバはハンドシェイクを中止し、illegal_parameter アラートを返さなければならない (MUST)。

ECPointFormat 名前空間（現在は "TLS EC Point Formats" というタイトル）は IANA によって維持されている。新しい値の割り当てがどのように追加されるかについては、セクション9を参照のこと。

他の曲線をサポートしない、本仕様に準拠したクライアントは、以下のオクテットを送信しなければならない (MUST)；最初の2オクテットは拡張タイプ（Supported Point Formats Extension）を示していることに注意：

        00 0B 00 02 01 00

5.1.3. signature_algorithms 拡張と EdDSA

[RFC5246] のセクション 7.4.1.4.1 で定義されている signature_algorithms 拡張は、クライアントがサポートする署名アルゴリズムとハッシュ関数の組み合わせを通知する。EdDSA の純粋な（非プレハッシュ）形式は、データを署名する前にハッシュしない。このため、拡張でそれらをハッシュ関数と組み合わせることには意味がない。

TLS 1.3 とのビットレベルの互換性のために、「TLS HashAlgorithm」レジストリに「Intrinsic（本質的）」（値8）と呼ばれる新しいダミー値を定義する。これは、ハッシュが署名アルゴリズムに本質的に含まれていることを意味する。

signature_algorithms 拡張で ed25519 と ed448 を表現するために、値はそれぞれ (8,7) および (8,8) となる。

5.2. Server Hello 拡張

本セクションでは、[RFC4366] で記述されているように ServerHello メッセージに含めることができる TLS 拡張、Supported Point Formats Extension を指定する。

この拡張が送信される場合：

Supported Point Formats Extension は、ECC 暗号スイートを交渉する際に、Supported Point Formats Extension を含む ClientHello メッセージへの応答として ServerHello メッセージに含まれる。

この拡張の意味：

この拡張により、サーバは解析可能なポイント形式を列挙できる（ECDHE_ECDSA、ECDHE_RSA、または ECDH_anon 鍵交換アルゴリズムを使用する場合に ServerKeyExchange メッセージに表示される曲線に対して）。

この拡張の構造：

サーバの Supported Point Formats Extension は、クライアントの Supported Point Formats Extension と同じ構造を持つ（セクション 5.1.2 を参照）。ここでの ec_point_format_list の項目は、サーバの好みに従って順序付けられる（最も好ましい選択が最初）。サーバは、クライアントのリストに見つからなかった項目を含めてもよい (MAY) ことに注意すること。しかし、拡張がなければ、本仕様では許可されるポイント形式は厳密に1つだけなので、実際には不一致の機会はない。

送信者の動作：

Supported Point Formats Extension を含む ClientHello メッセージに応答して ECC 暗号スイートを選択したサーバは、この拡張を（他の拡張と共に）ServerHello メッセージに追加し、解析可能なポイント形式を列挙する。Supported Point Formats Extension が使用される場合、それはポイント形式のリストの項目の1つとして値0（非圧縮）を含まなければならない (MUST)。

受信者の動作：

Supported Point Formats Extension を含む ServerHello メッセージを受信したクライアントは、ハンドシェイク中にサーバのポイント形式の選択を尊重しなければならない (MUST)（cf. セクション 5.6 および 5.7）。ServerHello に Supported Point Formats Extension が含まれていない場合、これは非圧縮ポイント形式のみを許可する拡張と同等である。

5.3. サーバ証明書

このメッセージが送信される場合：

このメッセージは、すべての非匿名、ECC ベースの鍵交換アルゴリズムで送信される。

このメッセージの意味：

このメッセージは、サーバの静的公開鍵をクライアントに真正に伝達するために使用される。以下の表は、各鍵交換アルゴリズムに適したサーバ証明書タイプを示している。ECC 公開鍵は、セクション5.9に記述されているように証明書でエンコードされなければならない (MUST)。

注：サーバの Certificate メッセージは、証明書のチェーンを運ぶことができる。表2に記載されている制限は、サーバの証明書（チェーンの最初）にのみ適用される。

アルゴリズム	サーバ証明書タイプ
ECDHE_ECDSA	証明書は ECDSA または EdDSA 能力を持つ公開鍵を含まなければならない (MUST)。
ECDHE_RSA	証明書は RSA 公開鍵を含まなければならない (MUST)。

表 2: サーバ証明書タイプ

このメッセージの構造：

TLS Certificate 形式と同一である。

送信者の動作：

サーバは適切な証明書チェーンを構築し、Certificate メッセージでそれをクライアントに伝達する。クライアントが Supported Elliptic Curves Extension を使用している場合、サーバの証明書内の公開鍵は、クライアントの楕円曲線の選択を尊重しなければならない (MUST)。この要件を満たすことができないサーバは、ServerHello メッセージで ECC 暗号スイートを選択してはならない (MUST NOT)。

受信者の動作：

クライアントは証明書チェーンを検証し、サーバの公開鍵を抽出し、鍵のタイプが交渉された鍵交換アルゴリズムに適していることを確認する。（致命的なハンドシェイク失敗の考えられる理由は、クライアントの楕円曲線とポイント形式を処理する能力が超過していることである；cf. セクション 5.1）

5.4. サーバ鍵交換

このメッセージが送信される場合：

このメッセージは、ECDHE_ECDSA、ECDHE_RSA、および ECDH_anon 鍵交換アルゴリズムを使用する場合に送信される。

このメッセージの意味：

このメッセージは、サーバの一時 ECDH 公開鍵（および対応する楕円曲線ドメインパラメータ）をクライアントに伝達するために使用される。

ECCurveType enum には、以前は明示的な素数および明示的な char2 曲線の値があった。それらの値は現在廃止されているため、1つの値のみが残っている：

このメッセージの構造：

        enum {
            deprecated (1..2),
            named_curve (3),
            reserved(248..255)
        } ECCurveType;

値 named_curve は、名前付き曲線が使用されることを示している。このオプションは現在、唯一残っている形式である。

値 248 から 255 は私用 (private use) のために予約されている。

ECCurveType 名前空間（現在は "TLS EC Curve Types" というタイトル）は IANA によって維持されている。新しい値の割り当てがどのように追加されるかについては、セクション9を参照のこと。

RFC 4492 には ECCurve 構造と ECBasisType 構造の仕様があった。これらは両方とも、現在廃止された明示的な曲線でのみ使用されていたため、現在は省略されている。

        struct {
            opaque point <1..2^8-1>;
        } ECPoint;

point: これは、[ANSI.X9-62.2005] のセクション 4.3.6 の変換ルーチンに従った楕円曲線点のバイト文字列表現である。このバイト文字列は、非圧縮、圧縮、またはハイブリッド形式の楕円曲線点を表すことができるが、本仕様では非圧縮形式以外のすべてを廃止する。NIST 曲線の場合、便宜上、セクション 5.4.1 で形式が繰り返されている。X25519 および X448 曲線の場合、唯一有効な表現は [RFC7748] で指定されたものであり、点の u 値の 32 または 56 オクテットの表現である。この構造は、Ed25519 および Ed448 公開鍵と共に使用してはならない (MUST NOT)。

        struct {
            ECCurveType    curve_type;
            select (curve_type) {
                case named_curve:
                    NamedCurve namedcurve;
            };
        } ECParameters;

curve_type: これは、楕円曲線ドメインパラメータのタイプを識別する。

namedCurve: 推奨される楕円曲線ドメインパラメータのセットを指定する。Diffie-Hellman が可能な曲線を指す NamedCurve のすべての値が許可される。明示的な曲線の廃止により、これには現在すべての NamedCurve 値が含まれる。

        struct {
            ECParameters    curve_params;
            ECPoint         public;
        } ServerECDHParams;

curve_params: ECDH 公開鍵に関連付けられた楕円曲線ドメインパラメータを指定する。

public: 一時 ECDH 公開鍵。

ServerKeyExchange メッセージは以下のように拡張される。

        enum {
            ec_diffie_hellman
        } KeyExchangeAlgorithm;

• ec_diffie_hellman: ServerKeyExchange メッセージが ECDH 公開鍵を含むことを示す。

      select (KeyExchangeAlgorithm) {
          case ec_diffie_hellman:
              ServerECDHParams    params;
              Signature           signed_params;
      } ServerKeyExchange;

• params: ECDH 公開鍵および関連するドメインパラメータを指定する。

• signed_params: params のハッシュであり、そのハッシュに適した署名が適用される。署名には、サーバの Certificate メッセージに含まれる認証済み公開鍵に対応する秘密鍵が使用される。

        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;

注：SignatureAlgorithm は、ECDHE_RSA 鍵交換アルゴリズムの場合は "rsa"、ECDH_anon の場合は "anonymous" である。これらのケースは TLS で定義されている。ECDHE_ECDSA の場合、SignatureAlgorithm は "ecdsa" または "eddsa" である。

ECDSA 署名はセクション 5.10 に記載されているように生成および検証される。上記の sha_hash のテンプレート内の SHA は、SHA-1 以外のハッシュアルゴリズムを示す場合がある。ANSI X9.62 に従い、ECDSA 署名は整数のペア r と s で構成される。digitally-signed 要素は、不透明なベクトル <0..2^16-1> としてエンコードされ、その内容は以下の ASN.1 表記に対応する DER エンコーディングである。

              Ecdsa-Sig-Value ::= SEQUENCE {
                  r       INTEGER,
                  s       INTEGER
              }

[RFC8410] に準拠するプロトコルおよび証明書内の EdDSA 署名は、[RFC8032] に従って生成および検証される。digitally-signed 要素は、不透明なベクトル <0..2^16-1> としてエンコードされ、その内容には EdDSA 署名アルゴリズムのオクテット文字列出力が含まれる。

送信者の動作：

サーバは、IEEE 1363 [IEEE.P1363] の ECKAS-DH1 スキームに従って、楕円曲線ドメインパラメータと、これらのパラメータに対応する一時 ECDH 公開鍵を選択する。サーバは、上記で定義された形式を使用して、ServerKeyExchange メッセージでこの情報をクライアントに伝達する。

受信者の動作：

クライアントは、署名（存在する場合）を検証し、ServerKeyExchange メッセージからサーバの楕円曲線ドメインパラメータと一時 ECDH 公開鍵を取得する。（致命的なハンドシェイク失敗の考えられる理由は、クライアントの楕円曲線とポイント形式を処理する能力が超過していることである；cf. セクション 5.1）

5.4.1. NIST 曲線の非圧縮ポイント形式

以下は、ServerKeyExchange レコードで ECPoint を表現するためのワイヤ形式を表している。表現の最初のオクテットは形式を示し、圧縮、非圧縮、またはハイブリッドのいずれかである。本仕様では、これらの曲線に対して非圧縮形式のみをサポートする。これに続いて、X 値のバイナリ表現が「ビッグエンディアン」または「ネットワーク」形式で続き、その後に Y 値のバイナリ表現が「ビッグエンディアン」または「ネットワーク」形式で続く。内部的な長さマーカーはないため、各数値表現は曲線パラメータによって暗示される数のオクテットを占有する。P-256 の場合、これは X と Y のそれぞれが32オクテットを使用することを意味し、必要に応じて左側がゼロでパディングされる。P-384 の場合、それぞれ48オクテットを要し、P-521 の場合、それぞれ66オクテットを要する。

以下はより正式な表現である：

             enum {
                 uncompressed(4),
                 (255)
               } PointConversionForm;

             struct {
                 PointConversionForm  form;
                 opaque               X[coordinate_length];
                 opaque               Y[coordinate_length];
             } UncompressedPointRepresentation;

5.5. 証明書リクエスト

このメッセージが送信される場合：

このメッセージは、クライアント認証を要求するときに送信される。

このメッセージの意味：

サーバは、このメッセージを使用して、受け入れ可能なクライアント認証方法を提案する。

このメッセージの構造：

TLS CertificateRequest メッセージは以下のように拡張される。

           enum {
               ecdsa_sign(64),
               deprecated1(65),  /* was rsa_fixed_ecdh */
               deprecated2(66),  /* was ecdsa_fixed_ecdh */
               (255)
           } ClientCertificateType;

• ecdsa_sign: サーバがセクション3で指定された対応するクライアント認証方法を使用したいことを示す。

RFC 4492 では、固定 ECDH 公開鍵を含む RSA および ECDSA 証明書も定義されていたことに注意すること。これらのメカニズムは実装が非常に少なかったため、本仕様では廃止している。

送信者の動作：

サーバは、使用したいクライアント認証方法を決定し、上記で定義された形式を使用してこの情報をクライアントに伝達する。

受信者の動作：

クライアントは、要求された方法のいずれかで使用するのに適した証明書を持っているかどうか、およびクライアント認証を進めるかどうかを決定する。

5.6. クライアント証明書

このメッセージが送信される場合：

このメッセージは、クライアントが適切な証明書を持っており、クライアント認証を進めることを決定した場合に、CertificateRequest への応答として送信される。（注：サーバが Supported Point Formats Extension を使用している場合、証明書が ECDSA_sign 認証方法での使用に適していると見なされるのは、そこで指定されている公開鍵ポイントが非圧縮である場合のみである。なぜなら、それが唯一サポートされているポイント形式だからである。

このメッセージの意味：

このメッセージは、クライアントの静的公開鍵をサーバに真正に伝達するために使用される。ECC 公開鍵は、セクション5.9に記述されているように証明書でエンコードされなければならない。証明書は、ECDSA または EdDSA 能力を持つ公開鍵を含まなければならない (MUST)。

注：クライアントの Certificate メッセージは、証明書のチェーンを運ぶことができる。上記の制限は、クライアントの証明書（チェーンの最初）にのみ適用される。

このメッセージの構造：

TLS クライアント Certificate 形式と同一である。

送信者の動作：

クライアントは適切な証明書チェーンを構築し、Certificate メッセージでそれをサーバに伝達する。

受信者の動作：

TLS サーバは証明書チェーンを検証し、クライアントの公開鍵を抽出し、鍵のタイプがクライアント認証方法に適していることを確認する。

5.7. クライアント鍵交換

このメッセージが送信される場合：

このメッセージは、すべての鍵交換アルゴリズムで送信される。これにはクライアントの一時 ECDH 公開鍵が含まれる。

このメッセージの意味：

このメッセージは、クライアントに属する鍵交換に関連する一時的なデータ（一時 ECDH 公開鍵など）を伝達するために使用される。

このメッセージの構造：

TLS ClientKeyExchange メッセージは以下のように拡張される。

           enum {
               implicit,
               explicit
           } PublicValueEncoding;

• implicit, explicit: ECC 暗号スイートの場合、これはクライアントの ECDH 公開鍵がクライアントの証明書内にあるか（"implicit"）、または ClientKeyExchange メッセージ内で一時 ECDH 公開鍵として提供されるか（"explicit"）を示す。implicit エンコーディングは廃止されており、後方互換性のためだけにここに残されている。

           struct {
               ECPoint ecdh_Yc;
           } ClientECDiffieHellmanPublic;

ecdh_Yc: クライアントの一時 ECDH 公開鍵をバイト文字列 ECPoint.point として含む。これは楕円曲線点を非圧縮形式で表すことができる。

           struct {
               select (KeyExchangeAlgorithm) {
                   case ec_diffie_hellman: ClientECDiffieHellmanPublic;
               } exchange_keys;
           } ClientKeyExchange;

送信者の動作：

クライアントは、サーバから受信したパラメータに対応する一時 ECDH 公開鍵を選択する。形式はセクション5.4と同じである。

受信者の動作：

サーバは、ClientKeyExchange メッセージからクライアントの一時 ECDH 公開鍵を取得し、それがサーバの ECDH 鍵と同じ楕円曲線上にあることを確認する。

5.8. 証明書検証

このメッセージが送信される場合：

このメッセージは、クライアントがデジタル署名に使用可能な公開鍵を含むクライアント証明書を送信した場合に送信される。

このメッセージの意味：

このメッセージには、クライアントの Certificate メッセージ内の公開鍵に対応する秘密鍵の所有を証明する署名が含まれている。

このメッセージの構造：

TLS CertificateVerify メッセージと基礎となる署名タイプは TLS 基本仕様で定義されており、後者はセクション5.4でここで拡張されている。"ecdsa" および "eddsa" のケースでは、CertificateVerify メッセージ内の署名フィールドには、これまでに交換されたハンドシェイクメッセージに対して計算された ECDSA または EdDSA（それぞれ）署名が含まれており、他の署名アルゴリズムを使用した CertificateVerify と完全に同様である：

           CertificateVerify.signature.sha_hash
               SHA(handshake_messages);
           CertificateVerify.signature.rawdata
               handshake_messages;

ECDSA 署名はセクション 5.10 に記述されているように計算され、上記の sha_hash テンプレート内の SHA はそれに応じて SHA-1 以外のハッシュアルゴリズムを示す場合がある。ANSI X9.62 に従い、ECDSA 署名は整数のペア r と s で構成される。digitally-signed 要素は、不透明なベクトル <0..2^16-1> としてエンコードされ、その内容は以下の ASN.1 表記 [X.680] に対応する DER エンコーディング [X.690] である。

           Ecdsa-Sig-Value ::= SEQUENCE {
               r       INTEGER,
               s       INTEGER
           }

EdDSA 署名は [RFC8032] に従って生成および検証される。digitally-signed 要素は、不透明なベクトル <0..2^16-1> としてエンコードされ、その内容には EdDSA 署名アルゴリズムのオクテット文字列出力が含まれる。

送信者の動作：

クライアントは、client hello から始まりこのメッセージを含まないまでに送信または受信されたすべてのハンドシェイクメッセージに対して署名を計算する。クライアントは、認証された公開鍵に対応する秘密鍵を使用して署名を計算し、上記で定義された形式で伝達される。

受信者の動作：

サーバは、CertificateVerify メッセージからクライアントの署名を抽出し、クライアントの Certificate メッセージで受信した公開鍵を使用して署名を検証する。

5.9. 楕円曲線証明書

ECC 公開鍵を含む、または ECDSA を使用して署名された X.509 証明書は、[RFC3279] またはそれを置き換えるか拡張する別の RFC に準拠しなければならない (MUST)。ECC 公開鍵を含む、または EdDSA を使用して署名された X.509 証明書は、[RFC8410] に準拠しなければならない (MUST)。クライアントは、ANSI X9.62、FIPS 186-4、SEC 2 [SECG-SEC2]、または [RFC8032] で推奨されている楕円曲線ドメインパラメータを使用すべきである (SHOULD)。

Ed25519 アルゴリズムを使用する EdDSA 鍵は ed25519 署名アルゴリズムを使用しなければならず (MUST)、Ed448 鍵は ed448 署名アルゴリズムを使用しなければならない (MUST)。本文書では、TLS での Ed25519ph および Ed448ph 鍵の使用は定義していない。Ed25519、Ed25519ph、Ed448、および Ed448ph 鍵は ECDSA と共に使用してはならない (MUST NOT)。

5.10. ECDH、ECDSA、および RSA 計算

NIST 曲線のすべての ECDH 計算（パラメータと鍵の生成、および共有シークレットの計算を含む）は、[IEEE.P1363] に従って ECKAS-DH1 スキームを使用して実行される。ここで、恒等写像を鍵導出関数 (KDF) として使用することで、プリマスターシークレットは、オクテット文字列として表現された ECDH 共有シークレットの楕円曲線点の x 座標となる。このオクテット文字列（IEEE 1363 用語で Z）は、FE2OSP（フィールド要素からオクテット文字列への変換プリミティブ）によって出力されるものであり、任意の所定のフィールドに対して一定の長さを有することに注意すること。このオクテット文字列に見られる先行ゼロは切り捨てられてはならない (MUST NOT)。

（注：恒等 KDF のこの使用は技術的な詳細である。全体像としては、TLS はマスターシークレットを計算する以外の目的でプリマスターシークレットを直接使用しないため、ECDH は非自明な KDF と共に採用されている。TLS 1.0 および 1.1 では、これは MD5 および SHA-1 ベースの TLS 疑似ランダム関数 (PRF) が KDF として機能することを意味する；TLS 1.2 では、KDF は暗号スイートによって決定され、将来の TLS バージョンや将来導入される新しい TLS 拡張がこの計算を変更する可能性がある。）

X25519（曲線 x25519）を使用する ECDHE 鍵交換は次のようになる：(1) 各当事者は秘密鍵 d を一様にランダムに選び、対応する公開鍵 x = X25519(d, G) を計算する；(2) 当事者は公開鍵を交換し、共有シークレットを x_S = X25519(d, x_peer) として計算する；および (3) いずれかの当事者が全ゼロの x_S を取得した場合、ハンドシェイクを中止しなければならない (MUST)（X25519 および X448 の定義によって要求される通り）。X448 の ECDHE も同様に機能し、X25519 を X448 に、x25519 を x448 に置き換える。導出された共有シークレットはプリマスターシークレットとして直接使用され、ECDHE と X25519 が使用される場合は常に正確に32バイト、ECDHE と X448 が使用される場合は56バイトである。

すべての ECDSA 計算は、ANSI X9.62 またはその後継に従って実行されなければならない (MUST)。署名/検証されるデータはハッシュされ、結果は追加のハッシュなしで直接 ECDSA アルゴリズムに通される。[FIPS.180-4] からの SHA-256、SHA-384、または SHA-512 などの安全なハッシュ関数を使用しなければならない (MUST)。

すべての EdDSA 計算は、[RFC8032] またはその後継に従って実行されなければならない (MUST)。署名/検証されるデータは、ハッシュなしで EdDSA アルゴリズムに通される（EdDSA は内部的にデータを「プレハッシュ」関数 PH に通す）。Ed448 のコンテキストパラメータは空の文字列に設定されなければならない (MUST)。

RFC 4492 は、証明書で必要なハッシュ関数を指定するメカニズムの標準化を予想していた（おそらく subjectPublicKeyInfo の parameters フィールドで）。そのような標準化は行われず、その結果、TLS 1.1 以前では SHA-1 が使用されている（恒等関数を使用する EdDSA を除く）。TLS 1.2 は DigitallySigned 構造体に SignatureAndHashAlgorithm パラメータを追加し、署名ハッシュの選択に柔軟性を持たせた。EdDSA 署名は HashAlgorithm が 8 (Intrinsic) でなければならない (MUST)。

すべての RSA 署名は、[RFC8017] のセクション 7.2 に従って生成および検証されなければならない。

5.11. 公開鍵検証

NIST 曲線では、各当事者は ClientKeyExchange および ServerKeyExchange メッセージでピアによって送信された公開鍵を検証しなければならない (MUST)。受信当事者は、ピアの公開値からの x および y パラメータが曲線方程式 y^2 = x^3 + ax + b mod p を満たすことを確認しなければならない (MUST)。詳細は [Menezes] のセクション2.3を参照のこと。これを行わないと、攻撃者が秘密鍵に関する情報を取得し、その鍵が真に一時的でない場合に数回のリクエストで秘密鍵全体を復元できる可能性がある。

X25519 および X448 では、受信当事者は計算されたプリマスターシークレットが全ゼロ値であるかどうかを確認し、そうである場合はハンドシェイクを中止しなければならない (MUST)（[RFC7748]のセクション6に記載されている通り）。

Ed25519 および Ed448 は、署名検証の一部として内部的に公開鍵検証を行う。