インターネット技術タスクフォース (IETF)

M. Thomson

Request for Comments: 8188

Mozilla

カテゴリ: Standards Track

2017年6月

ISSN: 2070-1721

HTTP 向け暗号化コンテンツエンコーディング

概要

本メモは、メッセージペイロードを暗号化できる HTTP 向けのコンテンツコーディングを導入します。

このメモの状態

これはインターネット標準トラック文書です。

本書はインターネット技術タスクフォース (IETF) の成果物です。IETF コミュニティの合意を示しており、公開審査を経て Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準に関する詳細は RFC 7841 のセクション 2 を参照してください。

この文書の現行の状態、訂正情報（errata）、およびフィードバックの方法については http://www.rfc-editor.org/info/rfc8188 を参照してください。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. 導入
- 1.1. 要件言語
2. "aes128gcm" HTTP コンテンツコーディング
3. 例
- 3.1. レスポンスの暗号化
- 3.2. 複数レコードによる暗号化
4. セキュリティ考慮事項
5. IANA に関する考慮事項
- 5.1. "aes128gcm" HTTP コンテンツコーディング
6. 参考文献
- 6.1. ノルマティブ参考文献
- 6.2. インフォマティブ参考文献
付録 A. JWE マッピング
謝辞
著者の連絡先

1. 導入

HTTP メッセージ（リクエストまたはレスポンス）の内容を暗号化して、ペイロードが保存された場合（例：HTTP PUT）に適切な鍵を持つ者だけが内容を読めるようにすることが望ましい場合があります。

例えば、サーバー上にファイルを保存するがその内容を当該サーバーに知られたくない場合があります。さらに、その同じファイルは他のサーバーへ複製され（サーバーやネットワーク障害への耐性向上のため）、クライアントにダウンロードされ（オフライン利用のため）等が行われても、内容を露出させたくないことがあります。

これらの用途は、クライアントとサーバー間のチャネルのみを暗号化する Transport Layer Security (TLS) [RFC5246] の使用では満たされません。

本書は、これらやその他のユースケースに対応するための HTTP 用コンテンツコーディング（RFC7231 セクション 3.1.2 を参照）を規定します。

このコンテンツコーディングは、[RFC4880]、[RFC5652]、[RFC7516]、および [XMLENC] のようなメッセージベースの暗号化フォーマットの直接的な適応ではありません。これらのフォーマットはストリーム処理には向かないため、HTTP に必要なストリーム処理に適しません。本仕様のフォーマットは、[RFC5116] に記載された低レベルの構成要素により近い形式に従います。

メッセージベースの暗号化フォーマットが同じプリミティブを使用する範囲で、本フォーマットは特定のプロファイルを持つ暗号化メッセージの列と見なせます。付録 A（JWE マッピング）では、本フォーマットが固定ヘッダを持つ JSON Web Encryption 値の列とどのように整合するかを説明します。

このメカニズムは、コンテンツ暗号化を利用するより大きな設計の一部に過ぎない可能性があります。クライアントとサーバーが鍵を取得・識別する方法はユースケースに依存します。特に鍵管理システムは本書では記述しません。

1.1. 要件言語

本書で使われるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、BCP 14 の定義（[RFC2119]、および [RFC8174]）に従って、大文字で示される場合に限り解釈されます。

2. "aes128gcm" HTTP コンテンツコーディング

"aes128gcm" HTTP コンテンツコーディングは、Advanced Encryption Standard (AES) の Galois/Counter Mode (GCM) を用いてペイロードが暗号化されていることを示します（AEAD_AES_128_GCM として [RFC5116] に記載、Section 5.1 参照）。AEAD_AES_128_GCM アルゴリズムは 128 ビットの content-encryption key を使用します。

このコンテンツコーディングを使用するには鍵の知識が必要です。鍵の取得方法は本書では定めません。

"aes128gcm" は単一の固定セットの暗号プリミティブを使用します。暗号アルゴリズムの切り替えは新しいコンテンツコーディングスキームを定義することで達成します。これにより暗号化の使用交渉には Accept-Encoding ヘッダーフィールドだけで十分になります。

"aes128gcm" コンテンツコーディングは固定レコードサイズを使います。最終的なエンコーディングはヘッダー（Section 2.1 参照）と、0 個以上の固定長暗号化レコードで構成されます。最終レコードはレコードサイズより小さくなることがあります。

レコードサイズは暗号化される平文の各部分の長さを決定します。レコードサイズ ("rs") はコンテンツコーディングヘッダーに含まれます（Section 2.1 参照）。

+-----------+             content
|   data    |             any length up to rs-17 octets
+-----------+
     |
     v
+-----------+-----+       add a delimiter octet (0x01 or 0x02)
|   data    | pad |       then 0x00-valued octets to rs-16
+-----------+-----+       (or less on the last record)
         |
         v
+--------------------+    encrypt with AEAD_AES_128_GCM;
|    ciphertext      |    final size is rs;
+--------------------+    the last record can be smaller

AEAD_AES_128_GCM は平文よりも 16 オクテット長い暗号文を生成します。したがって各レコードの未暗号化コンテンツはレコードサイズより 16 オクテット短くなります。有効なレコードは常に少なくともパディング区切りオクテットと 16 オクテットの認証タグを含みます。

各レコードは単一のパディング区切りオクテットとそれに続く任意数のゼロオクテットを含みます。最後のレコードのパディング区切りオクテットは値 2 に設定され、その他のレコードは値 1 になります。

復号時、パディング区切りはレコードの最後の非ゼロオクテットとして扱われます。レコードに非ゼロオクテットが存在しない場合、復号器は失敗しなければなりません。最後のレコードが値 2 以外のパディング区切りを含む場合、または最後以外のレコードが値 1 以外のパディング区切りを含む場合、復号器は失敗しなければなりません。

各レコードの nonce はレコードのシーケンス番号と input-keying material から構成される 96 ビット値です。nonce 導出は Section 2.3 で扱います。

AEAD_AES_128_GCM に渡される additional data は長さゼロのオクテット列です。

このレコード構造の結果、範囲リクエスト（[RFC7233]）や暗号化ペイロード本体へのランダムアクセスはレコードサイズ単位の粒度で可能になります。範囲の端の部分レコードは復号できません。したがって、範囲リクエストはレコード境界で開始および終了するのが望ましいです。ただし、パディングの存在によって特定部分へのランダムアクセスが妨げられる可能性がある点に注意してください。

適切なレコードサイズの選択はトレードオフを伴います。小さいレコードサイズは復号済みオクテットをより速く解放でき、応答性が重要なアプリケーションに適しています。小さいレコードは暗号文に対するランダムアクセスが必要な場合の追加データも減らします。

ストリーミング、ランダムアクセス、任意のパディングに依存しないアプリケーションは大きなレコード、あるいは単一レコードを使えます。大きなレコードサイズは処理およびデータのオーバヘッドを削減します。

2.1. 暗号化コンテンツコーディングヘッダー

このコンテンツコーディングは、コンテンツの復号に必要なすべてのパラメータ（鍵を除く）を含むヘッダーブロックを使用します。ヘッダーブロックはレコード列の先頭にメッセージ本文中に置かれます。

+-----------+--------+-----------+---------------+
| salt (16) | rs (4) | idlen (1) | keyid (idlen) |
+-----------+--------+-----------+---------------+

salt:: "salt" パラメータは "aes128gcm" コンテンツコーディングヘッダーの最初の 16 オクテットで構成されます。同じ input-keying material と異なる payload bodies に対して同じ "salt" 値を再利用してはなりません。各適用でランダムな salt を生成すれば content-encryption key の再利用が極めて起こりにくくなります。
rs:: "rs"（record size）パラメータはネットワークバイトオーダーの符号なし 32 ビット整数で、レコードサイズ（オクテット単位）を表します。したがって AEAD_AES_128_GCM に対する平文入力の 2^36-31 上限を超えることは不可能になります。18 未満の値は無効です。
idlen:: "idlen" パラメータは "keyid" パラメータの長さを定義する符号なし 8 ビット整数です。
keyid:: "keyid" パラメータは使用される鍵素材を識別するために使えます。このフィールドは "idlen" によって決まる長さです。メッセージを受け取る受信者は鍵を取得する方法を知っていることが期待されます；"keyid" はその処理の入力になり得ます。"keyid" は識別子をテキスト表示する必要がある場合に備え、UTF-8 エンコードされた文字列であることが SHOULD 推奨されます（[RFC3629] 参照）。

2.2. コンテンツ暗号鍵導出

複数の異なる HTTP メッセージで鍵素材を再利用できるように、各メッセージごとに content-encryption key を導出します。content-encryption key は "salt" パラメータから HMAC ベースの鍵導出関数（HKDF、[RFC5869]）を用いて、SHA-256 ハッシュ（[FIPS180-4]）で導出されます。

"salt" パラメータの値は HKDF の salt 入力です。"keyid" パラメータで識別される鍵素材は HKDF への input-keying material (IKM) です。IKM は受信者に別途提供されることが期待されます。したがって HKDF の extract フェーズは擬似乱数鍵 (PRK) を次のように生成します：

   PRK = HMAC-SHA-256 (salt, IKM)

HKDF への info パラメータは ASCII エンコードの文字列 "Content-Encoding: aes128gcm" と単一のゼロオクテットに設定されます：

   cek_info = "Content-Encoding: aes128gcm" || 0x00

Note(1):: オクテット列の連結は || 演算子で表されます。
Note(2):: ここで使用される文字列および Section 2.3 で使用される文字列は、いくつかのプログラミング言語で使われる終端 0x00 オクテットを含みません。

AEAD_AES_128_GCM は 16 オクテット（128 ビット）の CEK を必要とするため、HKDF の長さ (L) は 16 です。したがって HKDF の第二ステップは単一の HMAC の最初の 16 オクテットに単純化できます：

   CEK = HMAC-SHA-256(PRK, cek_info || 0x01)

2.3. ノンス導出

AEAD_AES_128_GCM への nonce 入力は各レコードごとに構築されます。各レコードの nonce は 12 オクテット（96 ビット）値で、レコードシーケンス番号、input-keying material、および "salt" パラメータから導出されます。

input-keying material と "salt" は、異なる info と長さ (L) パラメータで HKDF に入力されます。

長さ (L) パラメータは 12 オクテットです。nonce の info パラメータは ASCII エンコードの文字列 "Content-Encoding: nonce" で、単一のゼロオクテットで終端されます：

   nonce_info = "Content-Encoding: nonce" || 0x00

その結果はレコードシーケンス番号と排他的論理和（XOR）で結合されて nonce を生成します。レコードシーケンス番号（SEQ）はネットワークバイトオーダーの 96 ビット符号なし整数で、0 から始まります。

したがって各レコードの最終 nonce は 12 オクテット値です：

   NONCE = HMAC-SHA-256(PRK, nonce_info || 0x01) XOR SEQ

この nonce 構成は、レコードの削除や並べ替えを防ぎます。

3. 例

このセクションでは encrypted-content コーディングのいくつかの例を示します。

注：この節の例におけるすべてのバイナリ値は URL/ファイル名安全なアルファベットを用いた base64 エンコーディングです（[RFC4648]）。これはリクエスト本文も含みます。書式上の制約に合わせて空白や改行を挿入しています。

3.1. レスポンスの暗号化

ここでは、成功した HTTP GET レスポンスが暗号化されています。レコードサイズは 4096 オクテットでパディングは行わず（単一オクテットのパディング区切りのみ）、したがって部分レコードのみが存在します。input-keying material は空文字列で識別されます（ヘッダー中の "keyid" フィールド長はゼロオクテット）。

この例での暗号化データは UTF-8 エンコードの文字列 "I am the walrus" です。input-keying material は base64url 表現 "yqdlZ-tYemfogSmv7Ws5PQ" です。54 オクテットのコンテンツ本文は単一レコードを含み、表示上の都合で 71 文字の base64url で示されています。

HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 54
Content-Encoding: aes128gcm

I1BsxtFttlv3u_Oo94xnmwAAEAAA-NAVub2qFgBEuQKRapoZu-IxkIva3MEB1PD-
ly8Thjg

メディアタイプはコンテンツについての情報漏洩を避けるため "application/octet-stream" に変更されていることに注意してください。代替として（同等に）Content-Type ヘッダーフィールドを省略しても構いません。

この例の中間値（すべて base64url 表記）：

salt (from header) = I1BsxtFttlv3u_Oo94xnmw
PRK = zyeH5phsIsgUyd4oiSEIy35x-gIi4aM7y0hCF8mwn9g
CEK = _wniytB-ofscZDh4tbSjHw
NONCE = Bcs8gkIRKLI8GeI8
unencrypted data = SSBhbSB0aGUgd2FscnVzAg

3.2. 複数レコードによる暗号化

この例は input-keying material が "BO3ZVPxUlnLORbVGMpbT1Q" の場合を示します。この例では平文が 25 オクテットごとのレコードに分割されます（ヘッダーの "rs" フィールドは 25）。最初のレコードには 1 バイトの 0x00 パディングオクテットが含まれます。これは最初のレコードに 7 オクテット、二番目に 8 オクテットのメッセージが含まれることを意味します。ヘッダーには UTF-8 エンコード文字列 "a1" の key identifier も含まれます。

HTTP/1.1 200 OK
Content-Length: 73
Content-Encoding: aes128gcm

uNCkWiNYzKTnBN9ji3-qWAAAABkCYTHOG8chz_gnvgOqdGYovxyjuqRyJFjEDyoF
1Fvkj6hQPdPHI51OEUKEpgz3SsLWIqS_uA

4. セキュリティ考慮事項

このメカニズムは、有効な送信者と受信者間で鍵の配布を管理する鍵管理フレームワークの存在を前提とします。鍵管理の定義は、このメカニズムを大きなアプリケーションやプロトコル、フレームワークに組み込む際の一部です。

暗号の実装（特に鍵管理）は困難になり得ます。例えば、実装は処理にかかる時間のようなサイドチャネルで鍵素材が露出する可能性に注意する必要があります。暗号アルゴリズムの良好な実装要件は時間とともに変化します。

4.1. 自動復号

コンテンツコーディングとして、"aes128gcm" コンテンツコーディングは受信者によって自動的に除去され、メッセージの最終的な利用者に明示されない方法で扱われる可能性があります。本メカニズムを使用してコンテンツ起源認証に依存する受信者は、"aes128gcm" コンテンツコーディングを含まないメッセージを拒否しなければなりません。

4.2. メッセージの切り捨て

このコンテンツエンコーディングは大きなメッセージの逐次処理を許容するよう設計されています。また限定的に平文へのランダムアクセスを許します。コンテンツエンコーディングは受信者がメッセージが切り詰められたかどうかを検出できるようにします。

部分的に配信されたメッセージをあたかも完全に配信されたかのように処理してはなりません。例えば、部分配信されたメッセージを完全なものとしてキャッシュしてはなりません。

攻撃者が部分メッセージ処理を悪用して受信者を特定の中間状態に留める可能性があります。部分メッセージで処理を行う実装は、任意の中間処理状態が攻撃者に有利にならないことを保証する必要があります。

4.3. 鍵とノンスの再利用

AES-GCM では同じ content-encryption key と nonce を用いて異なる平文を暗号化することは安全ではありません（[RFC5116] 参照）。本仕様は固定的に進行する nonce 値を使います。したがってコンテンツコーディングの各適用に対して新しい content-encryption key が必要です。input-keying material は再利用可能なため、content-encryption key が再利用されないように一意の "salt" パラメータが必要です。

もし content-encryption key が再利用される（つまり input-keying material と "salt" が再利用される）と、平文や認証鍵が露出し、暗号による保護が無効化される可能性があります。したがって同じ input-keying material を再利用する場合、"salt" パラメータは毎回一意でなければなりません。実装は各メッセージでランダムな "salt" を生成することを SHOULD 推奨します。

4.4. データ暗号化の限界

AEAD_AES_128_GCM が暗号化できるデータには制限があります。record size の最大値はヘッダー中の "rs" フィールドの大きさによって制約され（Section 2.1 参照）、単一の AEAD_AES_128_GCM 適用で 2^36-31 の制限に達しないようにします（[RFC5116] 参照）。同一の input-keying material と salt から導出された鍵で暗号化できる平文の総量は、選択平文攻撃下での区別不能性（IND-CPA）を 2^-40 に保つために 2^44.5 ブロック（16 オクテットブロック）未満でなければなりません（[AEBounds] 参照）。

もしレコードサイズが 16 オクテットの倍数であれば、パディングとオーバーヘッドを含めても約 398 テラバイトを安全に暗号化できます。しかしレコードサイズが 16 の倍数でない場合、部分的な AES ブロックが暗号化されるため安全に暗号化できる総量は減少します。最悪ケースはレコードサイズ 18 オクテットで、この場合最大 74 テラバイトの平文しか安全に暗号化できず、そのうち少なくとも半分はパディングになります。

4.5. コンテンツ整合性

このメカニズムはコンテンツ起源認証のみを提供します。認証タグは content-encryption key にアクセスできるエンティティが暗号化データを生成したことを保証します。

したがって、content-encryption key を持つ任意のエンティティが有効なコンテンツを生成でき、同じ HTTP メッセージを受け取るすべての受信者に対して有効と見なされます。

さらに、Content-Encoding ヘッダーフィールドおよび HTTP メッセージ本文の両方を改変できるエンティティは内容を置換できます。content-encryption key や input-keying material を持たない者はペイロード本文の一部を改変・置換することはできません。

4.6. ヘッダーフィールドにおける情報漏洩

ペイロード本文のみが暗号化されるため、ヘッダーフィールドに露出する情報は HTTP メッセージを読める者に見えてしまいます。これはサイドチャネル情報を露出する可能性があります。

例えば Content-Type ヘッダーフィールドはペイロード本文に関する情報を漏らし得ます。

この脅威を軽減するための戦略はいくつかあり、アプリケーションの脅威モデルや利用者の情報漏洩許容度によります：

問題とならないと判断する。例えば保存されるすべてのコンテンツが "application/json" など非常に一般的なメディアタイプであることが期待される場合、Content-Type を露出することは許容されるリスクかもしれません。
機密情報と判断され、他手段で（アウトオブバンド、他の表現のヒント等）伝達可能な場合は、該当ヘッダーを省略・正規化します。Content-Type の場合は常に Content-Type: application/octet-stream を送る（最も一般的なメディアタイプ）か、あるいは Content-Type 自体を送らないなどが考えられます。
機密情報であり他に伝えられない場合は、application/http メディアタイプで HTTP メッセージをカプセル化し（RFC7230 Section 8.3.2 参照）、その "外側" メッセージのペイロードとして暗号化します。

4.7. ストレージの汚染

このメカニズムはデータ起源認証のみを提供し、メッセージ作成者の認証や認可を行いません。そのため、（例：HTTP 認証 [RFC7235] による）追加の認証・認可が必要な場合があります。

特に、サーバーがペイロードを復号せずに HTTP PUT リクエストを受け入れると、リクエストが認証されていない場合に第三者がサービス拒否やストアの汚染を行う可能性が出てきます。

4.8. サイズおよびタイミング攻撃

本メカニズムを使うアプリケーションは、暗号化メッセージのサイズやそれらのタイミング、HTTP メソッド、URI 等が機密情報を漏らす可能性があることに注意する必要があります。例として [NETFLIX] や [CLINIC] を参照してください。

このリスクは本メカニズムが提供するパディングを用いることで軽減できます。あるいはコンテンツをセグメントに分割して別々に保管することで露出を減らすこともできます。HTTP/2 [RFC7540] と TLS [RFC5246] の組み合わせは個々のメッセージサイズを隠すのに役立つかもしれません。

パディング戦略を策定することは困難です。良いパディング戦略は文脈に依存します。一般的な戦略には少数の固定長へパディングする、ある値の倍数へパディングする、または 2 の累乗へパディングするなどがあります。優れた戦略でも受信者の処理活動が観察されるとサイズ情報が漏れることがあります。特にメッセージの末尾レコードがパディングのみで構成される場合は要注意です。サイズ情報漏洩を避けるには非パディングデータをレコードに分散することを推奨します。

5. IANA に関する考慮事項

5.1. "aes128gcm" HTTP コンテンツコーディング

本メモは "HTTP Content Coding Registry" に "aes128gcm" HTTP コンテンツコーディングを登録します。詳細は Section 2 を参照してください。

Name: aes128gcm
Description: 128 ビットの content-encryption key を用いた AES-GCM 暗号化
Reference: 本仕様書

6. 参考文献

6.1. ノルマティブ参考文献

[FIPS180-4]: National Institute of Standards and Technology, “Secure Hash Standard (SHS)”, FIPS PUB 180-4, August 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf>.
[RFC2119]: Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3629]: Yergeau, F., “UTF-8, a transformation format of ISO 10646”, RFC 3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC5116]: McGrew, D., “An Interface and Algorithms for Authenticated Encryption”, RFC 5116, January 2008, <https://www.rfc-editor.org/info/rfc5116>.
[RFC5869]: Krawczyk, H. and P. Eronen, “HMAC-based Extract-and-Expand Key Derivation Function (HKDF)”, RFC 5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.
[RFC7230]: Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7231]: Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”, RFC 7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC8174]: Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

6.2. インフォマティブ参考文献

[AEBounds]: Luykx, A. and K. Paterson, “Limits on Authenticated Encryption Use in TLS”, March 2016, <http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[CLINIC]: Miller, B., Huang, L., Joseph, A., and J. Tygar, “I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis”, March 2014, <https://arxiv.org/abs/1403.0297>.
[NETFLIX]: Reed, A. and M. Kranch, “Identifying HTTPS-Protected Netflix Videos in Real-Time”, CODASPY '17, 2017.
[RFC4648]: Josefsson, S., “The Base16, Base32, and Base64 Data Encodings”, RFC 4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4880]: Callas, J., ほか, “OpenPGP Message Format”, RFC 4880, November 2007, <https://www.rfc-editor.org/info/rfc4880>.
[RFC5246]: Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5652]: Housley, R., “Cryptographic Message Syntax (CMS)”, RFC 5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC7233]: Fielding, R., ほか, “Hypertext Transfer Protocol (HTTP/1.1): Range Requests”, RFC 7233, June 2014, <https://www.rfc-editor.org/info/rfc7233>.
[RFC7235]: Fielding, R., ほか, “Hypertext Transfer Protocol (HTTP/1.1): Authentication”, RFC 7235, June 2014, <https://www.rfc-editor.org/info/rfc7235>.
[RFC7516]: Jones, M. and J. Hildebrand, “JSON Web Encryption (JWE)”, RFC 7516, May 2015, <https://www.rfc-editor.org/info/rfc7516>.
[RFC7540]: Belshe, M., ほか, “Hypertext Transfer Protocol Version 2 (HTTP/2)”, RFC 7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[XMLENC]: Eastlake, D., ほか, “XML Encryption Syntax and Processing Version 1.1”, W3C REC, April 2013, <http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411>.

付録 A. JWE マッピング

"aes128gcm" コンテンツコーディングは、各固定長レコード（後続パディングを含む）に対応する JSON Web Encryption (JWE) [RFC7516] オブジェクトの列と見なせます。JWE Compact Serialization で表現されうる JWE オブジェクトに次の変換が適用されます：

JWE Protected Header は { "alg": "dir", "enc": "A128GCM" } に固定され、direct encryption による AES-GCM（128 ビット CEK）を記述します。このヘッダーは送信されず、Content-Encoding ヘッダーフィールドの値で暗黙的に示されます。
JWE Encrypted Key は direct 暗号化の規定に従い空です。
各レコードの JWE Initialization Vector ("iv") は 96 ビットのレコードシーケンス番号（0 から始まる）と input-keying material から導出される値の XOR に設定されます（Section 2.3 参照）。この値も送信されません。
最終的な値はヘッダー、JWE Ciphertext、JWE Authentication Tag を連結したもので、すべて base64url エンコードは行わずに表現します。これらフィールド間の "." 区切りは省略されます（フィールド長が既知であるため）。

したがって Section 3.1 の例は JWE Compact Serialization を用いて次のように表せます：

eyAiYWxnIjogImRpciIsICJlbmMiOiAiQTEyOEdDTSIgfQ..Bcs8gkIRKLI8GeI8.
-NAVub2qFgBEuQKRapoZuw.4jGQi9rcwQHU8P6XLxOGOA

ここで第一行は固定された JWE Protected Header、空の JWE Encrypted Key、アルゴリズム的に決定された JWE Initialization Vector を表し、第二行はエンコード済み本文（JWE Ciphertext と JWE Authentication Tag に分割）を含みます。

謝辞

Mark Nottingham は本書の初期著者の一人です。

以下の人々が有益な意見を提供しました：Richard Barnes, David Benjamin, Peter Beverloo, JR Conlin, Mike Jones, Stephen Farrell, Adam Langley, James Manger, John Mattsson, Julian Reschke, Eric Rescorla, Jim Schaad, Magnus Westerlund。

著者の連絡先

Martin Thomson
Mozilla
EMail: martin.thomson@gmail.com