TLSチャンネルID 翻訳 - 5. Channel ID Extension
TLSチャンネルIDの翻訳シリーズの第4回です。「5. Channel ID Extension」の翻訳結果を投稿します。
シリーズの過去の記事は、 以下を参照ください。
* 第1回：「TLSチャンネルID 翻訳 - 1. introduction」
* 第2回：「TLSチャンネルID 翻訳 - 2. Why not client certificates」
* 第3回：「TLSチャンネルID 翻訳 - 3. Requirements Notation / 4. Channel ID Client Keys」
5. チャンネルID拡張
5. Channel ID Extension
A new extension type ("channel_id(TBD)") is defined and MAY be included by the client in its "ClientHello" message. If, and only if, the server sees this extension in the "ClientHello", it MAY choose to echo the extension in its "ServerHello". In both cases, the "extension_data" field MUST be empty.
新たな拡張形式("channel_id(TBD)")が定義され、クライアントによって、"ClientHello"メッセージに含められてもよい(MAY)。サーバーが"ClientHello"メッセージ中にこの拡張を見つけた場合に限り、"ServerHello"メッセージにおいて拡張を送り返すことを選択してもよい(MAY)。どちらのケースにおいても、"extension_data"フィールドは空でなくてはならない(MUST)。
（リストの訳は省略）
A new handshake message type ("encrypted_extensions(TBD)") is defined. If the server included a "channel_id" extension in its "ServerHello" message, the client MUST verify that the selected cipher suite is sufficiently strong. If the cipher suite provides < 80-bits of security, the client MUST abort the handshake with a fatal "illegal_parameter" alert. Otherwise, the client MUST send an "EncryptedExtensions" message after its "ChangeCipherSpec" and before its "Finished" message.
新たなハンドシェイクメッセージ形式("encrypted_extensions(TBD)")が定義される。もしサーバーが"channnel_id"拡張を"ServerHello"メッセージ中に含めていた場合、クライントは選択された暗号スイートが十分に強力であることを検証しなければならない(MUST)。もし暗号スイートの強度が80bitを下回る場合、クライアントは、fatalの"illegal parameter"警告と共にハンドシェイクを中止しなければならない(MUST)。そうでなければ、クライアントは”ChangeCipherSpec"メッセージの後でかつ、"Finished"メッセージの前に、"EncryptedExtensions"メッセージを送らなければならない(MUST)。
（リストの訳は省略）
Therefore a full handshake with "EncryptedExtensions" has the following flow (contrast with section 7.3 of RFC 5246 [RFC5246]):
したがって、"EncryptedExtensions"を伴うハンドシェイクの全体は、（RFC 5246 [RFC5246]の、section 7.3に対し、)以下の様なフローを持つ:
Client Server
ClientHello (ChannelID extension) -------->
ServerHello
(ChannelID extension)
Certificate
ServerKeyExchange
CertificateRequest
<-------- ServerHelloDone
Certificate
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
EncryptedExtensions
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
（図の訳は省略）
An abbreviated handshake with "EncryptedExtensions" has the following flow:
"EncryptedExtensions"を伴う、簡略化されたハンドシェイクは以下のとおりである
Client Server
ClientHello (ChannelID extension) -------->
ServerHello
(ChannelID extension)
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
EncryptedExtensions
Finished -------->
Application Data <-------> Application Data
（図の訳は省略）
The "EncryptedExtensions" message contains a series of "Extension" structures (see section 7.4.1.4 of RFC 5246 [RFC5246]
"EncryptedExtensions"メッセージは一連の"Extension"の構造を持つ（RFC 5246 [RFC5246]の、section 7.4.1.4を参照）
If the server included a "channel_id" extension in its "ServerHello" message, the client MUST include, within an EncryptedExtensions message, an "Extension" with "extension_type" equal to "channel_id(TBD)". The "extension_data" of which has the following
もしサーバーが"chanell_id"拡張を"ServerHello"メッセージ中に含めていた場合、クライアントは、"EncryptedExtensions"*1メッセージ中に、"extension_type"が"channel_id(TBD)"の"Extension"を含めなければならない(MUST)。そのときの"extension_data"は、以下の形式を持つ。
format:
struct {
opaque x[32];
opaque y[32];
opaque r[32];
opaque s[32];
} ChannelIDExtension;
（リストの訳は省略）
The contents of each of "x", "y", "r" and "s" is a 32-byte, big-endian number. The "x" and "y" fields contain the affine coordinates of the client's Channel ID Q (i.e., a P-256 [DSS curve point). The "r" and "s" fields contain an ECDSA [DSS] signature by the corresponding private key over this US-ASCII strong (not including quotes, and where "\x00" represents an octet containing all zero bits):
"x","y","r"及び"s"の内容は、32-byteのビッグエンディアンである。"x"と"y"のフィールドにはクライアントのチャンネルID Qのアフィン変換が含まれる(i.e., a P-256 [DSS]curve point)。"r"と"s"のフィールドには、以下のUS-ASCIIの文字列*2（クォートを含まず、"¥x00"はすべて0のビットの8バイトを表す）で始まる*3対応する秘密鍵によるECDSA[DSS]署名が含まれる。
"TLS Channel ID signature\x00"
（リストの訳は省略）
followed by hashes of both the client-sent and server-sent handshake messages, as seen by the client, prior to the "EncryptedExtensions" message.
この後に、クライアントから見ると"EncryptedExtensions"メッセージよりも先に、クライアントとサーバーが送ったハンドシェイクメッセージのハッシュ値が続く。
Unlike many other TLS extensions, this extension does not establish properties of the session, only of the connection. When session resumption or session tickets [RFC5077] are used, the previous contents of this extension are irrelevant and only the values in the new handshake messages are considered.
他の多くのTLS拡張と異なり、この拡張は、セッションではなく、コネクションだけのプロパティを確立する。session resuptionまたはsession tickets[RFC5077]が使われる際には、この拡張のそれ以前の内容は無効になり、新たなハンドシェイクメッセージの値のみが考慮される。
