[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]
PROPOSED STANDARD
Errata ExistInternet Engineering Task Force (IETF) M. Jones
Request for Comments: 7516 Microsoft
Category: Standards Track J. Hildebrand
ISSN: 2070-1721 Cisco
May 2015
JSON Web Encryption (JWE)
概要
JSON Web Encryption (JWE) は、JSON ベースのデータ構造を使用して
暗号化されたコンテンツを表現する。 本仕様で使用される暗号アルゴリズム
および識別子については、別仕様である JSON Web Algorithms (JWA) 仕様書
および当該仕様で定義されている IANA レジストリに記載されている。
関連するデジタル署名およびメッセージ認証コード (MAC) の機能については、
別仕様である JSON Web Signature (JWS) 仕様書に記載されている。
このメモの位置付け
本文書は Internet Standards Track 文書である。
本文書は Internet Engineering Task Force (IETF) の成果物である。
IETF コミュニティの合意を反映している。 公開レビューを受け、
Internet Engineering Steering Group (IESG) により
公開が承認された。 Internet 標準に関する詳細については
RFC 5741 のセクション 2 を参照されたい。
本文書の現在の状態、正誤表、およびフィードバックの提供方法に関する情報は、
http://www.rfc-editor.org/info/rfc7516
から入手できる。
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Jones & Hildebrand Standards Track [Page 1]
RFC 7516 JSON Web Encryption (JWE) May 2015
目次
1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. 表記上の規約 . . . . . . . . . . . . . . . . . . . . . . 4
2. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. JSON Web Encryption (JWE) の概要 . . . . . . . . . . . . . 8
3.1. JWE コンパクト直列化の概要 . . . . . . . . . . . . . . 8
3.2. JWE JSON 直列化の概要 . . . . . . . . . . . . . . . . . . 9
3.3. JWE の例 . . . . . . . . . . . . . . . . . . . . . . . . 10
4. JOSE ヘッダ . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. 登録済みヘッダパラメータ名 . . . . . . . . . . . . . . 11
4.1.1. "alg"（アルゴリズム）ヘッダパラメータ . . . . . . . . 12
4.1.2. "enc"（暗号化アルゴリズム）ヘッダパラメータ . . . . 12
4.1.3. "zip"（圧縮アルゴリズム）ヘッダパラメータ . . . . 12
4.1.4. "jku"（JWK セット URL）ヘッダパラメータ . . . . . . 13
4.1.5. "jwk"（JSON Web Key）ヘッダパラメータ . . . . . . . . 13
4.1.6. "kid"（キー ID）ヘッダパラメータ . . . . . . . . . . . 13
4.1.7. "x5u"（X.509 URL）ヘッダパラメータ . . . . . . . . . 13
4.1.8. "x5c"（X.509 証明書チェーン）ヘッダパラメータ . . 13
4.1.9. "x5t"（X.509 証明書 SHA-1 サムプリント）ヘッダ
パラメータ . . . . . . . . . . . . . . . . . . . . . . 14
4.1.10. "x5t#S256"（X.509 証明書 SHA-256 サムプリント）
ヘッダパラメータ . . . . . . . . . . . . . . . . . . 14
4.1.11. "typ"（型）ヘッダパラメータ . . . . . . . . . . . . 14
4.1.12. "cty"（コンテンツ型）ヘッダパラメータ . . . . . . . 14
4.1.13. "crit"（クリティカル）ヘッダパラメータ . . . . . . 14
4.2. 公開ヘッダパラメータ名 . . . . . . . . . . . . . . . . 14
4.3. 非公開ヘッダパラメータ名 . . . . . . . . . . . . . . . 15
5. JWE の生成および消費 . . . . . . . . . . . . . . . . . . 15
5.1. メッセージ暗号化 . . . . . . . . . . . . . . . . . . . 15
5.2. メッセージ復号 . . . . . . . . . . . . . . . . . . . . 17
5.3. 文字列比較規則 . . . . . . . . . . . . . . . . . . . . 20
6. キー識別 . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. 直列化 . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. JWE コンパクト直列化 . . . . . . . . . . . . . . . . . 20
7.2. JWE JSON 直列化 . . . . . . . . . . . . . . . . . . . . 20
7.2.1. 一般 JWE JSON 直列化構文 . . . . . . . . . . . . . . 21
7.2.2. フラット化 JWE JSON 直列化構文 . . . . . . . . . . . 23
8. TLS 要件 . . . . . . . . . . . . . . . . . . . . . . . . . 24
9. JWS オブジェクトと JWE オブジェクトの識別 . . . . . . . . 24
10. IANA に関する考慮事項 . . . . . . . . . . . . . . . . . . 25
10.1. JSON Web Signature および Encryption ヘッダパラメータの
登録 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1.1. レジストリ内容 . . . . . . . . . . . . . . . . . . 25
11. セキュリティに関する考慮事項 . . . . . . . . . . . . . . . 27
11.1. キーエントロピーおよび乱数値 . . . . . . . . . . . . 27
11.2. キー保護 . . . . . . . . . . . . . . . . . . . . . . . 27
11.3. 一致するアルゴリズム強度の使用 . . . . . . . . . . . 28
Jones & Hildebrand Standards Track [Page 2]
RFC 7516 JSON Web Encryption (JWE) May 2015
11.4. 適応的選択暗号文攻撃 . . . . . . . . . . . . . . . . . 28
11.5. タイミング攻撃 . . . . . . . . . . . . . . . . . . . . 28
12. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. 規範的参照 . . . . . . . . . . . . . . . . . . . . . . 29
12.2. 参考情報的参照 . . . . . . . . . . . . . . . . . . . . 30
付録 A. JWE の例 . . . . . . . . . . . . . . . . . . . . . . . . 32
A.1. RSAES-OAEP および AES GCM を用いた JWE の例 . . . . . 32
A.1.1. JOSE ヘッダ . . . . . . . . . . . . . . . . . . . . . 32
A.1.2. コンテンツ暗号化キー（CEK） . . . . . . . . . . . . 32
A.1.3. キー暗号化 . . . . . . . . . . . . . . . . . . . . . 33
A.1.4. 初期化ベクトル . . . . . . . . . . . . . . . . . . . 34
A.1.5. 追加認証データ . . . . . . . . . . . . . . . . . . . 35
A.1.6. コンテンツ暗号化 . . . . . . . . . . . . . . . . . . 35
A.1.7. 完全な表現 . . . . . . . . . . . . . . . . . . . . . 36
A.1.8. 検証 . . . . . . . . . . . . . . . . . . . . . . . . 36
A.2. RSAES-PKCS1-v1_5 および
AES_128_CBC_HMAC_SHA_256 を用いた JWE の例 . . . . . 36
A.2.1. JOSE ヘッダ . . . . . . . . . . . . . . . . . . . . . 37
A.2.2. コンテンツ暗号化キー（CEK） . . . . . . . . . . . . 37
A.2.3. キー暗号化 . . . . . . . . . . . . . . . . . . . . . 38
A.2.4. 初期化ベクトル . . . . . . . . . . . . . . . . . . . 39
A.2.5. 追加認証データ . . . . . . . . . . . . . . . . . . . 40
A.2.6. コンテンツ暗号化 . . . . . . . . . . . . . . . . . . 40
A.2.7. 完全な表現 . . . . . . . . . . . . . . . . . . . . . 40
A.2.8. 検証 . . . . . . . . . . . . . . . . . . . . . . . . 41
A.3. AES キーラップおよび
AES_128_CBC_HMAC_SHA_256 を用いた JWE の例 . . . . . 41
A.3.1. JOSE ヘッダ . . . . . . . . . . . . . . . . . . . . . 41
A.3.2. コンテンツ暗号化キー（CEK） . . . . . . . . . . . . 42
A.3.3. キー暗号化 . . . . . . . . . . . . . . . . . . . . . 42
A.3.4. 初期化ベクトル . . . . . . . . . . . . . . . . . . . 42
A.3.5. 追加認証データ . . . . . . . . . . . . . . . . . . . 43
A.3.6. コンテンツ暗号化 . . . . . . . . . . . . . . . . . . 43
A.3.7. 完全な表現 . . . . . . . . . . . . . . . . . . . . . 43
A.3.8. 検証 . . . . . . . . . . . . . . . . . . . . . . . . 44
A.4. 一般 JWE JSON 直列化を用いた JWE の例 . . . . . . . . 44
A.4.1. 受信者ごとの非保護ヘッダ . . . . . . . . . . . . . 45
A.4.2. JWE 保護ヘッダ . . . . . . . . . . . . . . . . . . . 45
A.4.3. JWE 共有非保護ヘッダ . . . . . . . . . . . . . . . . 45
A.4.4. 完全な JOSE ヘッダ値 . . . . . . . . . . . . . . . . 45
A.4.5. 追加認証データ . . . . . . . . . . . . . . . . . . . 46
A.4.6. コンテンツ暗号化 . . . . . . . . . . . . . . . . . . 46
A.4.7. 完全な JWE JSON 直列化表現 . . . . . . . . . . . . 47
A.5. フラット化 JWE JSON 直列化を用いた JWE の例 . . . . . 47
付録 B. AES_128_CBC_HMAC_SHA_256 の計算例 . . . . . . . . . . . 48
B.1. キーから MAC_KEY および ENC_KEY を抽出 . . . . . . . 48
B.2. 平文を暗号化して暗号文を作成 . . . . . . . . . . . . . 49
B.3. AAD 長の 64 ビットビッグエンディアン表現 . . . . . . 49
Jones & Hildebrand Standards Track [Page 3]
RFC 7516 JSON Web Encryption (JWE) May 2015
B.4. 初期化ベクトル値 . . . . . . . . . . . . . . . . . . . . 49
B.5. HMAC 計算への入力を作成 . . . . . . . . . . . . . . . . 50
B.6. HMAC 値を計算 . . . . . . . . . . . . . . . . . . . . . 50
B.7. HMAC 値を切り詰めて認証タグを作成 . . . . . . . . . . 50
謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . 51
1. はじめに
JSON Web Encryption (JWE) は、JSON ベースのデータ構造
[RFC7159] を用いて暗号化されたコンテンツを表現する。
JWE の暗号化メカニズムは、任意のオクテット列に対して暗号化を行い、
完全性保護を提供する。
JWE には、密接に関連する 2 種類の直列化が定義されている。
JWE コンパクト直列化は、HTTP Authorization ヘッダや URI
クエリパラメータなどの空間制約のある環境を対象とした、
コンパクトで URL セーフな表現である。
JWE JSON 直列化は、JWE を JSON オブジェクトとして表現し、
同一のコンテンツを複数の相手に対して暗号化できるようにする。
いずれも同一の暗号学的基盤を共有している。
本仕様で使用される暗号アルゴリズムおよび識別子は、別仕様である
JSON Web Algorithms (JWA)
[JWA] に記述され、
同仕様で定義される IANA レジストリに登録されている。
関連するデジタル署名および MAC の機能については、
別仕様である JSON Web Signature (JWS)
[JWS] に記述されている。
本仕様で定義される名前は、結果として得られる表現を
コンパクトにするという中核的な目標のため、短く定義されている。
1.1. 表記上の規約
本文書中のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"NOT RECOMMENDED", "MAY", および "OPTIONAL" は、
「RFC における要件レベルを示すためのキーワード」
[RFC2119] に記載されているとおりに解釈される。
これらの解釈は、用語がすべて大文字で記載されている場合にのみ適用される。
BASE64URL(OCTETS) は、[JWS] の
セクション 2 に従った、OCTETS の base64url エンコードを表す。
UTF8(STRING) は、STRING の UTF-8
[RFC3629] 表現の
オクテット列を表す。ここで STRING は、0 個以上の Unicode
[UNICODE] 文字からなる並びである。
Jones & Hildebrand Standards Track [Page 4]
RFC 7516 JSON Web Encryption (JWE) May 2015
ASCII(STRING) は、STRING の ASCII
[RFC20] 表現の
オクテット列を表す。ここで STRING は、0 個以上の ASCII 文字からなる。
2 つの値 A および B の連結は、A || B と表記する。
2. 用語
「JSON Web Signature (JWS)」、「Base64url Encoding」、
「Collision-Resistant Name」、「Header Parameter」、
「JOSE Header」、および「StringOrURI」は、
JWS 仕様 [JWS] で定義されている。
「Ciphertext」、「Digital Signature」、「Initialization Vector
(IV)」、「Message Authentication Code (MAC)」、および「Plaintext」は、
「Internet Security Glossary, Version 2」
[RFC4949] で定義されている。
以下の用語は本仕様で定義される。
JSON Web Encryption (JWE)
暗号化され、完全性保護されたメッセージを表すデータ構造。
追加認証データ付き認証暗号（AEAD）
AEAD アルゴリズムは、平文を暗号化し、追加認証データを指定でき、
暗号文および追加認証データに対する統合された完全性検査を提供する。
AEAD アルゴリズムは、平文と追加認証データという 2 つの入力を受け取り、
暗号文と認証タグ値という 2 つの出力を生成する。
AES Galois/Counter Mode (GCM) は、そのようなアルゴリズムの 1 つである。
追加認証データ（AAD）
完全性保護はされるが暗号化はされない、AEAD 操作への入力。
認証タグ
AEAD 操作の出力であり、暗号文および追加認証データの完全性を保証する。
なお、一部のアルゴリズムでは認証タグを使用しない場合があり、
その場合、この値は空のオクテット列となる。
コンテンツ暗号化キー（CEK）
平文を暗号化して暗号文および認証タグを生成するために使用される
AEAD アルゴリズム用の対称鍵。
Jones & Hildebrand Standards Track [Page 5]
RFC 7516 JSON Web Encryption (JWE) May 2015
JWE 暗号化キー
暗号化されたコンテンツ暗号化キーの値。
一部のアルゴリズムでは、JWE 暗号化キー値は
空のオクテット列として指定される点に注意すること。
JWE 初期化ベクトル
平文を暗号化する際に使用される初期化ベクトルの値。
一部のアルゴリズムでは初期化ベクトルを使用しない場合があり、
その場合、この値は空のオクテット列となる。
JWE AAD
認証暗号操作によって完全性保護される追加の値。
これは JWE JSON 直列化を使用する場合にのみ存在できる。
（なお、JWE コンパクト直列化または JWE JSON 直列化のいずれを
使用する場合でも、AAD 値を完全性保護されたヘッダパラメータ値として
含めることで同等のことは可能であるが、その場合、値は二重に
base64url エンコードされるという代償がある。）
JWE 暗号文
追加認証データ付きで平文を認証暗号化した結果として得られる暗号文の値。
JWE 認証タグ
追加認証データ付きで平文を認証暗号化した結果として得られる
認証タグの値。
JWE 保護ヘッダ
認証暗号操作によって完全性保護されるヘッダパラメータを含む JSON
オブジェクト。これらのパラメータは、JWE のすべての受信者に適用される。
JWE コンパクト直列化では、これは JOSE ヘッダ全体を構成する。
JWE JSON 直列化では、これは JOSE ヘッダの 1 つの構成要素である。
JWE 共有非保護ヘッダ
JWE のすべての受信者に適用されるが、完全性保護されない
ヘッダパラメータを含む JSON オブジェクト。
これは JWE JSON 直列化を使用する場合にのみ存在できる。
JWE 受信者ごとの非保護ヘッダ
JWE の単一の受信者に適用されるヘッダパラメータを含む JSON
オブジェクト。これらのヘッダパラメータ値は完全性保護されない。
これは JWE JSON 直列化を使用する場合にのみ存在できる。
JWE コンパクト直列化
JWE をコンパクトで URL セーフな文字列として表現したもの。
Jones & Hildebrand Standards Track [Page 6]
RFC 7516 JSON Web Encryption (JWE) May 2015
JWE JSON 直列化
JWE を JSON オブジェクトとして表現したもの。
JWE JSON 直列化は、同一のコンテンツを複数の相手に暗号化することを
可能にする。この表現は、コンパクトさや URL セーフ性については
最適化されていない。
鍵管理モード
使用するコンテンツ暗号化キー値を決定する方法。
CEK 値を決定するために使用される各アルゴリズムは、
特定の鍵管理モードを使用する。
本仕様で用いられる鍵管理モードには、キー暗号化、
キーラップ、直接鍵合意、キーラップ付き鍵合意、
および直接暗号化がある。
キー暗号化
非対称暗号アルゴリズムを用いて、意図された受信者に対して
CEK 値を暗号化する鍵管理モード。
キーラップ
対称鍵ラップアルゴリズムを用いて、意図された受信者に対して
CEK 値を暗号化する鍵管理モード。
直接鍵合意
鍵合意アルゴリズムを用いて CEK 値について合意する鍵管理モード。
キーラップ付き鍵合意
鍵合意アルゴリズムを用いて対称鍵について合意し、
その対称鍵を用いて CEK 値を暗号化する鍵管理モード。
直接暗号化
当事者間で共有される秘密の対称鍵値を CEK 値として使用する
鍵管理モード。
Jones & Hildebrand Standards Track [Page 7]
RFC 7516 JSON Web Encryption (JWE) May 2015
3. JSON Web Encryption (JWE) の概要
JWE は、JSON データ構造および base64url エンコーディングを使用して
暗号化されたコンテンツを表現する。これらの JSON データ構造は、
RFC 7159 の Section 2
[RFC7159] に従い、
任意の JSON 値または構造文字の前後に空白および／または改行を
含んでもよい。JWE は、以下の論理値（それぞれ
Section 2 で定義されている）を表す。
o JOSE ヘッダー
o JWE 暗号化キー
o JWE 初期化ベクトル
o JWE AAD
o JWE 暗号文
o JWE 認証タグ
JWE において、JOSE ヘッダーのメンバーは、以下の値
（それぞれ Section 2 で定義されている）
のメンバーの和集合である。
o JWE 保護ヘッダー
o JWE 共有非保護ヘッダー
o JWE 受信者別非保護ヘッダー
JWE は、認証付き暗号化を利用して、平文の機密性および完全性、
ならびに JWE 保護ヘッダーおよび JWE AAD の完全性を保証する。
本文書では、JWE の 2 つのシリアライゼーションを定義する。1 つは、
JWE コンパクトシリアライゼーションと呼ばれる、URL セーフな
コンパクトなシリアライゼーションであり、もう 1 つは、
JWE JSON シリアライゼーションと呼ばれる JSON シリアライゼーションである。
いずれのシリアライゼーションにおいても、JWE 保護ヘッダー、
JWE 暗号化キー、JWE 初期化ベクトル、JWE 暗号文、
および JWE 認証タグは、JSON には任意のオクテット列を
直接表現する方法がないため、base64url エンコードされる。
存在する場合、JWE AAD も同様に base64url エンコードされる。
3.1. JWE コンパクトシリアライゼーションの概要
JWE コンパクトシリアライゼーションでは、JWE 共有非保護ヘッダー
および JWE 受信者別非保護ヘッダーは使用されない。この場合、
JOSE ヘッダーと JWE 保護ヘッダーは同一である。
Jones & Hildebrand Standards Track [Page 8]
RFC 7516 JSON Web Encryption (JWE) May 2015
JWE コンパクトシリアライゼーションでは、JWE は次の連結として
表現される。
BASE64URL(UTF8(JWE 保護ヘッダー)) || '.' ||
BASE64URL(JWE 暗号化キー) || '.' ||
BASE64URL(JWE 初期化ベクトル) || '.' ||
BASE64URL(JWE 暗号文) || '.' ||
BASE64URL(JWE 認証タグ)
JWE コンパクトシリアライゼーションの詳細については
Section 7.1 を参照のこと。
3.2. JWE JSON シリアライゼーションの概要
JWE JSON シリアライゼーションでは、JWE 保護ヘッダー、
JWE 共有非保護ヘッダー、および JWE 受信者別非保護ヘッダーの
うち 1 つ以上が存在しなければならない。この場合、JOSE ヘッダーの
メンバーは、存在する JWE 保護ヘッダー、
JWE 共有非保護ヘッダー、および
JWE 受信者別非保護ヘッダーの値のメンバーの和集合である。
JWE JSON シリアライゼーションでは、JWE は、以下の 8 つの
メンバーの一部またはすべてを含む JSON オブジェクトとして
表現される。
"protected", BASE64URL(UTF8(JWE 保護ヘッダー)) の値
"unprotected", JWE 共有非保護ヘッダーの値
"header", JWE 受信者別非保護ヘッダーの値
"encrypted_key", BASE64URL(JWE 暗号化キー) の値
"iv", BASE64URL(JWE 初期化ベクトル) の値
"ciphertext", BASE64URL(JWE 暗号文) の値
"tag", BASE64URL(JWE 認証タグ) の値
"aad", BASE64URL(JWE AAD) の値
6 つの base64url エンコードされた結果文字列と、
2 つの非保護 JSON オブジェクト値は、
JSON オブジェクト内のメンバーとして表現される。
これらの値の一部の包含は OPTIONAL である。
JWE JSON シリアライゼーションは、
平文を複数の受信者に対して暗号化することもできる。
詳細については Section 7.2 を参照のこと。
Jones & Hildebrand Standards Track [Page 9]
RFC 7516 JSON Web Encryption (JWE) May 2015
3.3. JWE の例
この例では、平文
"The true sign of intelligence is not knowledge but imagination."
を受信者向けに暗号化する。
次の例の JWE 保護ヘッダーは、以下を宣言している。
o コンテンツ暗号化キーは、RSAES-OAEP
[RFC3447]
アルゴリズムを使用して受信者向けに暗号化され、
JWE 暗号化キーが生成される。
o 認証付き暗号化は、256 ビット鍵を用いた AES GCM
[AES]
[NIST.800-38D]
アルゴリズムを使用して平文に対して実行され、
暗号文および認証タグが生成される。
{"alg":"RSA-OAEP","enc":"A256GCM"}
この JWE 保護ヘッダーを
BASE64URL(UTF8(JWE 保護ヘッダー)) としてエンコードすると、
次の値が得られる。
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ
この JWE を完成させるための残りの手順は次のとおりである。
o ランダムなコンテンツ暗号化キー (CEK) を生成する。
o RSAES-OAEP アルゴリズムを使用して、
受信者の公開鍵で CEK を暗号化し、
JWE 暗号化キーを生成する。
o JWE 暗号化キーを base64url エンコードする。
o ランダムな JWE 初期化ベクトルを生成する。
o JWE 初期化ベクトルを base64url エンコードする。
o 追加認証データ暗号化パラメータを
ASCII(BASE64URL(UTF8(JWE 保護ヘッダー))) とする。
o AES GCM アルゴリズムを使用し、CEK を暗号化キー、
JWE 初期化ベクトルおよび追加認証データ値として、
平文に対して認証付き暗号化を実行し、
128 ビットの認証タグ出力を要求する。
o 暗号文を base64url エンコードする。
o 認証タグを base64url エンコードする。
Jones & Hildebrand Standards Track [Page 10]
RFC 7516 JSON Web Encryption (JWE) May 2015
o 最終的な表現を組み立てる。この結果のコンパクト
シリアライゼーションは、文字列
BASE64URL(UTF8(JWE 保護ヘッダー)) ||
'.' || BASE64URL(JWE 暗号化キー) ||
'.' || BASE64URL(JWE 初期化ベクトル) ||
'.' || BASE64URL(JWE 暗号文) ||
'.' || BASE64URL(JWE 認証タグ)
となる。
この例における最終結果（表示目的のみの改行付き）は次のとおりである。
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.
OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe
ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb
Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV
mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8
1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi
6UklfCpIMfIjf7iGdXKHzg.
48V1_ALb6US04U3b.
5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji
SdiwkIr3ajwQzaBtQD_A.
XFBoMYUZodetZdvTiFvSkQ
この JWE の計算に関する完全な詳細については
Appendix A.1 を参照のこと。
JWE JSON シリアライゼーションを使用した例を含む追加の例については、
Sections A.4 および A.5 を含む Appendix A を参照のこと。
4. JOSE ヘッダー
JWE において、JOSE ヘッダーを表す JSON オブジェクトの
メンバーは、平文に適用される暗号化および、
オプションで JWE の追加プロパティを記述する。
JOSE ヘッダー内のヘッダーパラメータ名は、
[JWS] の Section 4 に記載されているとおり、
一意でなければならない。
実装が理解できないヘッダーパラメータの取り扱いに関する規則も同様である。
ヘッダーパラメータ名のクラスも同様である。
4.1. 登録済みヘッダーパラメータ名
JWE で使用する以下のヘッダーパラメータ名は、
[JWS] により確立された
IANA「JSON Web Signature and Encryption Header Parameters」
レジストリに登録されており、その意味は以下に定義される。
共通レジストリで示されているとおり、
JWS と JWE は共通のヘッダーパラメータ空間を共有する。
パラメータが両方の仕様で使用される場合、
その使用方法は仕様間で互換でなければならない。
Jones & Hildebrand Standards Track [Page 11]
RFC 7516 JSON Web Encryption (JWE) May 2015
4.1.1. 「alg」（アルゴリズム）ヘッダーパラメータ
このパラメータは、[JWS] の
Section 4.1.1 で定義されている「alg」ヘッダーパラメータと
同じ意味、構文、および処理規則を持つが、
ヘッダーパラメータは、CEK の値を暗号化または決定するために
使用される暗号アルゴリズムを識別する点が異なる。
「alg」値がサポートされていないアルゴリズムを表す場合、
または受信者がそのアルゴリズムで使用できる鍵を
持っていない場合、暗号化されたコンテンツは使用できない。
この用途のために定義された「alg」値の一覧は、
[JWA] により確立された
IANA「JSON Web Signature and Encryption Algorithms」
レジストリに掲載されている。このレジストリの初期内容は、
[JWA] の Section 4.1 で
定義された値である。
4.1.2. 「enc」（暗号化アルゴリズム）ヘッダーパラメータ
「enc」（暗号化アルゴリズム）ヘッダーパラメータは、
平文に対して認証付き暗号化を実行し、
暗号文および認証タグを生成するために使用される
コンテンツ暗号化アルゴリズムを識別する。
このアルゴリズムは、指定された鍵長を持つ
AEAD アルゴリズムでなければならない。
「enc」値がサポートされていないアルゴリズムを
表す場合、暗号化されたコンテンツは使用できない。
「enc」値は、[JWA] により確立された
IANA「JSON Web Signature and Encryption Algorithms」
レジストリに登録されるか、または
衝突耐性名を含む値であるべきである。
「enc」値は、大文字小文字を区別する ASCII 文字列であり、
StringOrURI 値を含む。
このヘッダーパラメータは MUST で存在し、
実装によって理解および処理されなければならない。
この用途のために定義された「enc」値の一覧は、
[JWA] により確立された
IANA「JSON Web Signature and Encryption Algorithms」
レジストリに掲載されている。このレジストリの初期内容は、
[JWA] の Section 5.1 で
定義された値である。
4.1.3. 「zip」（圧縮アルゴリズム）ヘッダーパラメータ
暗号化前に平文へ適用される圧縮アルゴリズム（存在する場合）。
本仕様で定義される「zip」値は次のとおりである。
o 「DEF」 - DEFLATE
[RFC1951]
アルゴリズムによる圧縮
他の値も使用してよい。圧縮アルゴリズム値は、
[JWA] により確立された
IANA「JSON Web Encryption Compression Algorithms」
レジストリに登録できる。
「zip」値は大文字小文字を区別する文字列である。
「zip」パラメータが存在しない場合、
暗号化前に平文へ圧縮は適用されない。
使用される場合、このヘッダーパラメータは
完全性保護されなければならない。
したがって、これは JWE 保護ヘッダー内にのみ
出現しなければならない。
このヘッダーパラメータの使用は OPTIONAL である。
このヘッダーパラメータは、
実装によって理解および処理されなければならない。
Jones & Hildebrand Standards Track [Page 12]
RFC 7516 JSON Web Encryption (JWE) May 2015
4.1.4. 「jku」（JWK セット URL）ヘッダーパラメータ
このパラメータは、[JWS] の
Section 4.1.2 で定義されている「jku」ヘッダーパラメータと
同じ意味、構文、および処理規則を持つが、
JWK セットリソースが、JWE が暗号化された
公開鍵を含む点が異なる。これにより、
JWE を復号するために必要な秘密鍵を
判断することができる。
4.1.5. 「jwk」（JSON Web Key）ヘッダーパラメータ
このパラメータは、[JWS] の
Section 4.1.3 で定義されている「jwk」ヘッダーパラメータと
同じ意味、構文、および処理規則を持つが、
鍵が、JWE が暗号化された公開鍵である点が異なる。
これにより、JWE を復号するために必要な
秘密鍵を判断することができる。
4.1.6. 「kid」（キー ID）ヘッダーパラメータ
このパラメータは、[JWS] の
Section 4.1.4 で定義されている「kid」ヘッダーパラメータと
同じ意味、構文、および処理規則を持つが、
キーのヒントが、JWE が暗号化された
公開鍵を参照する点が異なる。
これにより、JWE を復号するために必要な
秘密鍵を判断することができる。
このパラメータは、JWE の送信者が
受信者に対して鍵の変更を明示的に通知することを可能にする。
4.1.7. 「x5u」（X.509 URL）ヘッダーパラメータ
このパラメータは、[JWS] の
Section 4.1.5 で定義されている「x5u」ヘッダーパラメータと
同じ意味、構文、および処理規則を持つが、
X.509 公開鍵証明書または証明書チェーン
[RFC5280]
が、JWE が暗号化された公開鍵を含む点が異なる。
これにより、JWE を復号するために必要な
秘密鍵を判断することができる。
4.1.8. 「x5c」（X.509 証明書チェーン）ヘッダーパラメータ
このパラメータは、[JWS] の
Section 4.1.6 で定義されている「x5c」ヘッダーパラメータと
同じ意味、構文、および処理規則を持つが、
X.509 公開鍵証明書または証明書チェーン
[RFC5280]
が、JWE が暗号化された公開鍵を含む点が異なる。
これにより、JWE を復号するために必要な
秘密鍵を判断することができる。
「x5c」値の例については、
[JWS] の
Appendix B を参照のこと。
Jones & Hildebrand Standards Track [Page 13]
RFC 7516 JSON Web Encryption (JWE) May 2015
4.1.9. 「x5t」（X.509 証明書 SHA-1 サムプリント）ヘッダーパラメータ
このパラメータは、[JWS] の
Section 4.1.7 で定義されている「x5t」ヘッダーパラメータと
同じ意味、構文、および処理規則を持つが、
サムプリントによって参照される証明書が、
JWE が暗号化された公開鍵を含む点が異なる。
これにより、JWE を復号するために必要な
秘密鍵を判断することができる。
証明書サムプリントは、
証明書フィンガープリントと呼ばれることもある。
4.1.10. 「x5t#S256」（X.509 証明書 SHA-256 サムプリント）ヘッダー
パラメータ
このパラメータは、[JWS] の
Section 4.1.8 で定義されている「x5t#S256」ヘッダーパラメータと
同じ意味、構文、および処理規則を持つが、
サムプリントによって参照される証明書が、
JWE が暗号化された公開鍵を含む点が異なる。
これにより、JWE を復号するために必要な
秘密鍵を判断することができる。
証明書サムプリントは、
証明書フィンガープリントと呼ばれることもある。
4.1.11. 「typ」（型）ヘッダーパラメータ
このパラメータは、[JWS] の
Section 4.1.9 で定義されている「typ」ヘッダーパラメータと
同じ意味、構文、および処理規則を持つが、
型が、この完全な JWE のものである点が異なる。
4.1.12. 「cty」（コンテンツ型）ヘッダーパラメータ
このパラメータは、[JWS] の
Section 4.1.10 で定義されている「cty」ヘッダーパラメータと
同じ意味、構文、および処理規則を持つが、
型が、保護されるコンテンツ（平文）のものである点が異なる。
4.1.13. 「crit」（重要）ヘッダーパラメータ
このパラメータは、[JWS] の
Section 4.1.11 で定義されている「crit」ヘッダーパラメータと
同じ意味、構文、および処理規則を持つが、
JWS のヘッダーパラメータではなく、
JWE のヘッダーパラメータを参照する点が異なる。
4.2. 公開ヘッダーパラメータ名
追加のヘッダーパラメータ名は、
JWE を使用する者によって定義することができる。
しかし、衝突を防止するために、
新しいヘッダーパラメータ名は、
[JWS] により確立された
IANA「JSON Web Signature and Encryption Header Parameters」
レジストリに登録されるか、
または公開名、すなわち
衝突耐性名を含む値であるべきである。
いずれの場合においても、
その名前または値の定義者は、
合理的な配慮を行う必要がある。
Jones & Hildebrand Standards Track [Page 14]
RFC 7516 JSON Web Encryption (JWE) 2015年5月
名前空間の一部を制御していることを確認するための予防措置。
新しいヘッダーパラメータは慎重に導入する必要があり、これにより互換性のないJWEが生成される可能性があります。
4.3. プライベートヘッダーパラメータ名
JWEの生産者と消費者は、プライベート名を使用することに同意する場合があります。これは登録されたヘッダーパラメータ名（セクション4.1）
や公開ヘッダーパラメータ名（セクション4.2）ではない名前です。
公開ヘッダーパラメータ名とは異なり、プライベートヘッダーパラメータ名は衝突の可能性があるため、慎重に使用する必要があります。
5. JWEsの生成と消費
5.1. メッセージの暗号化
メッセージ暗号化のプロセスは以下の通りです。ステップ間に依存関係がない場合、ステップの順序は重要ではありません。
1. コンテンツ暗号化キー（CEK）値を決定するために使用されるアルゴリズムによって採用されたキー管理モードを決定します。
（これは、結果として得られるJWEの「alg」（アルゴリズム）ヘッダーパラメータに記録されたアルゴリズムです。）
2. キーラッピング、キー暗号化、またはキーラッピングを伴うキー合意が使用される場合、ランダムなCEK値を生成します。
ランダム値の生成に関する考慮事項についてはRFC
4086 [RFC4086]を参照してください。
CEKの長さは、コンテンツ暗号化アルゴリズムに必要な長さと一致する必要があります。
3. 直接的なキー合意またはキーラッピングを伴うキー合意が使用される場合、キー合意アルゴリズムを使用して合意されたキーの値を計算します。
直接的なキー合意が使用される場合、CEKは合意されたキーとします。キーラッピングを伴うキー合意が使用される場合、合意されたキーはCEKをラップするために使用されます。
4. キーラッピング、キー暗号化、またはキーラッピングを伴うキー合意が使用される場合、CEKを受信者に暗号化し、その結果をJWE暗号化キーとします。
5. 直接的なキー合意または直接的な暗号化が使用される場合、JWE暗号化キーは空のオクテットシーケンスとします。
Jones & Hildebrand Standards Track [Page 15]
RFC 7516 JSON Web Encryption (JWE) 2015年5月
6. 直接暗号化が使用される場合、CEKは共有された対称鍵とします。
7. エンコードされたキー値BASE64URL（JWE暗号化キー）を計算します。
8. JWE JSONシリアル化が使用される場合、このプロセス（ステップ1～7）を各受信者に対して繰り返します。
9. コンテンツ暗号化アルゴリズムに対して正しいサイズのランダムなJWE初期化ベクトルを生成します（アルゴリズムで必要な場合）。
それ以外の場合、JWE初期化ベクトルは空のオクテットシーケンスとします。
10. エンコードされた初期化ベクトル値BASE64URL（JWE初期化ベクトル）を計算します。
11. 「zip」パラメータが含まれている場合、指定された圧縮アルゴリズムを使用してプレーンテキストを圧縮し、Mを圧縮されたプレーンテキストを表すオクテットシーケンスとします。
それ以外の場合、Mをプレーンテキストを表すオクテットシーケンスとします。
12. 必要なヘッダーパラメータのセットを含むJSONオブジェクトを作成し、これらがJOSEヘッダーを構成します。
JWE保護ヘッダー、JWE共有されていないヘッダー、JWE受信者ごとの非保護ヘッダーの1つ以上です。
13. エンコードされた保護されたヘッダー値BASE64URL（UTF8（JWE保護ヘッダー））を計算します。
JWE保護ヘッダーが存在しない場合（これはJWE JSONシリアル化を使用し、「protected」メンバーが存在しない場合にのみ発生する可能性があります）、
この値は空の文字列とします。
14. 追加認証データ暗号化パラメータをASCII（エンコードされた保護されたヘッダー）とします。
ただし、JWE AAD値が存在する場合（これはJWE JSONシリアル化を使用する場合のみ可能です）、
代わりに、追加認証データ暗号化パラメータはASCII（エンコードされた保護されたヘッダー || '.' || BASE64URL（JWE AAD））とします。
15. MをCEK、JWE初期化ベクトル、および追加認証データ値を使用して、指定されたコンテンツ暗号化アルゴリズムで暗号化し、JWE暗号文値とJWE認証タグ（これは暗号化操作からの認証タグ出力）を作成します。
16. エンコードされた暗号文値BASE64URL（JWE暗号文）を計算します。
Jones & Hildebrand Standards Track [Page 16]
RFC 7516 JSON Web Encryption (JWE) 2015年5月
17. エンコードされた認証タグ値BASE64URL（JWE認証タグ）を計算します。
18. JWE AAD値が存在する場合、エンコードされたAAD値BASE64URL（JWE AAD）を計算します。
19. 必要なシリアライズされた出力を作成します。この結果のコンパクトシリアル化は文字列BASE64URL（UTF8（JWE保護ヘッダー）） || '.' || BASE64URL（JWE暗号化キー） || '.' ||
BASE64URL（JWE初期化ベクトル） || '.' || BASE64URL（JWE暗号文） || '.' || BASE64URL（JWE認証タグ）です。
JWE JSONシリアル化はセクション7.2で説明されています。
5.2. メッセージの復号
メッセージの復号プロセスは暗号化プロセスの逆である。
ステップ間の入出力に依存関係がない場合、ステップの順序は重要ではない。
これらのステップのいずれかが失敗した場合、暗号化された内容を
検証することはできない。
複数の受信者が存在する場合、どの受信者の暗号化された内容が成功裏に
検証される必要があるかはアプリケーションの判断による。一部のケースでは、
全ての受信者の暗号化内容が成功裏に検証される必要がある場合もあり、
そうでない場合、JWE は無効とみなされる。他のケースでは、単一の受信者の
暗号化内容が成功裏に検証されるだけで十分となる場合もある。しかし、全ての
ケースにおいて、少なくとも1人の受信者の暗号化された内容が成功裏に
検証されなければならず（MUST）、そうでなければJWE は無効とみなされる（MUST）。
1. JWE 表現を解析して、JWE コンポーネントの直列化された値を
抽出する。JWE Compact Serialization を使用する場合、
これらのコンポーネントは JWE Protected Header、JWE Encrypted
Key、JWE Initialization Vector、JWE Ciphertext、および
JWE Authentication Tag の base64url エンコードされた構成要素の
表現であり、JWE JSON Serialization を使用した場合には、
これらの構成要素に加えて JWE AAD の base64url エンコード表現と
エンコードされていない JWE Shared Unprotected Header や
JWE Per-Recipient Unprotected Header 値も含まれる。JWE Compact
Serialization を使用する場合、JWE Protected Header、
JWE Encrypted Key、JWE Initialization Vector、
JWE Ciphertext、および JWE Authentication Tag は
その順序で base64url エンコードされた値で表現され、それぞれの
値は単一のピリオド('.')文字で区切られ、結果として正確に4つの
区切りピリオド文字が使用される。JWE JSON Serialization に
関する説明はSection 7.2を参照。
Jones & Hildebrand Standards Track [Page 17]
RFC 7516 JSON Web Encryption (JWE) May 2015
2. JWE Protected Header、JWE Encrypted Key、JWE Initialization
Vector、JWE Ciphertext、JWE Authentication Tag、および
JWE AAD のエンコードされた表現を base64url デコードする。
改行や空白、その他の追加文字が使用されていない制約に従う。
3. デコードされた JWE Protected Header のオクテット列が完全に有効な
JSON オブジェクトであり、RFC 7159に準拠して
UTF-8エンコードされていることを検証する。そのJSONオブジェクトを
JWE Protected Header とする。
4. JWE Compact Serialization を使用する場合、JOSE Header を
JWE Protected Header とする。そうでない場合、JWE JSON
Serialization を使用する際には、JOSE Header は JWE Protected
Header、JWE Shared Unprotected Header、そして対応する JWE
Per-Recipient Unprotected Header のメンバーの和集合とする。
このステップでは、得られた JOSE Header に重複したヘッダーパラメータ
名が含まれていないことを確認する。JWE JSON Serialization を
使用する場合、この制約は、JOSE Header を構成する異なる JSON
オブジェクト値に重複するヘッダパラメータ名が存在していない
ことを含む。
5. 実装がこの仕様、使用されているアルゴリズム、あるいは
"crit" ヘッダパラメータ値によって求められる全てのフィールドを
認識し、処理でき、これらのパラメータ値も理解され、サポートされて
いるかを確認する。
6. "alg"（アルゴリズム）ヘッダーパラメータで指定されたアルゴリズムが
使用する鍵管理モードを特定する。
7. JWE が受信者の既知の鍵を使用しているかどうか検証する。
8. Direct Key Agreement または Key Agreement with Key Wrapping
が使用されている場合、鍵合意アルゴリズムを使用して、合意された
鍵の値を計算する。Direct Key Agreement が使用されている場合、
CEK を合意鍵とする。Key Agreement with Key Wrapping を使用
している場合、合意された鍵は JWE Encrypted Key を復号するため
に使用される。
9. Key Wrapping、Key Encryption、または Key Agreement with Key
Wrapping が使用されている場合、JWE Encrypted Key を復号して
CEK を生成する。CEK の長さはコンテント暗号アルゴリズムで要求
される長さに等しい必要がある（MUST）。受信者が複数いる場合、
それぞれの受信者はその受信者が所有する鍵に対して暗号化された
JWE Encrypted Key 値を復号するため、通常、1つの受信者が復号を
試みる対象となる per-recipient JWE Encrypted Key 値は1つのみで
ある。また、タイミング攻撃を緩和するためのセキュリティ
上の考慮については、Section 11.5を
参照。
10. Direct Key Agreement または Direct Encryption が使用されている
場合、JWE Encrypted Key 値が空のオクテット列であることを検証する。
11. Direct Encryption が使用されている場合、CEK を共有の対称鍵とする。
12. この受信者に対して CEK を特定できたかどうか記録する。
13. JWE JSON Serialization を使用している場合、このプロセス
（ステップ4-12）を、表現に含まれる各受信者に繰り返す。
14. Encoded Protected Header 値を計算する：BASE64URL(UTF8(JWE
Protected Header))。JWE Protected Header が存在しない場合
（JWE JSON Serialization を使用し、"protected" メンバが存在
しない場合に限る）、この値を空文字列とする。
15. Additional Authenticated Data 暗号化パラメータを
ASCII(Encoded Protected Header) とする。ただし、
JWE AAD 値が存在する場合（JWE JSON Serialization を使用
している場合に限る）、代わりに Additional Authenticated Data
暗号化パラメータを ASCII(Encoded Protected Header || '.' ||
BASE64URL(JWE AAD)) とする。
16. 指定されたコンテンツ暗号化アルゴリズムを使用して
CEK・JWE Initialization Vector・Additional Authenticated Data
値・JWE Authentication Tag （これは計算への認証タグ入力）を
用いて JWE Ciphertext を復号し、アルゴリズムで指定された方式
に従って JWE Authentication Tag を検証する。認証タグが
正しくない場合、復号データを何も出力せず入力を拒否する。
17. "zip" パラメータが含まれていた場合、指定された圧縮アルゴリズム
に従い復号された平文を解凍する。
18. 全ての復号処理が成功した受信者が存在しない場合は JWE を無効と
みなす（MUST）。それ以外の場合は平文を出力する。
JWE JSON Serialization の場合、どの受信者の復号が成功
したか、また失敗したかをアプリケーションに報告する結果も
返す。
Jones & Hildebrand Standards Track [Page 19]
RFC 7516 JSON Web Encryption (JWE) May 2015
最後に、どのアルゴリズムが特定のコンテキストで使用されるかは
アプリケーションの判断であることに留意すること。JWE が正常に復号
可能であったとしても、JWE で使用されているアルゴリズムがアプリ
ケーションで許容可能なものでない限り、それを無効とみなすべきである
（SHOULD）。
5.3. 文字列比較規則
本仕様における文字列比較規則は、
[JWS] のセクション5.3で
定義されているものと同一です。
6. キー識別
本仕様でのキー識別方法は、
[JWS] のセクション6で
定義されているものと同じですが、識別される
キーはJWEが暗号化された公開鍵である点が
異なります。
7. シリアライズ
JWEは2つのシリアライズ方法のうちいずれかを
使用します：JWEコンパクトシリアライズまたは
JWE JSONシリアライズ。本仕様を利用するアプリ
ケーションは、そのアプリケーションで使用する
シリアライズ方法および機能を指定する必要があり
ます。たとえば、JWE JSONシリアライズのみを使用
する、単一受信者向けのJWE JSONシリアライズのみ
サポートする、または複数受信者のサポートを含める
ことを指定する場合があります。JWE実装は、設計
されたアプリケーションが必要とする機能のみを
実装すればよいです。
7.1. JWEコンパクトシリアライズ
JWEコンパクトシリアライズは、暗号化された内容を
コンパクトかつURLセーフな文字列として表現します。
この文字列は以下の通りです：
BASE64URL(UTF8(JWE Protected Header)) || '.' ||
BASE64URL(JWE Encrypted Key) || '.' ||
BASE64URL(JWE Initialization Vector) || '.' ||
BASE64URL(JWE Ciphertext) || '.' ||
BASE64URL(JWE Authentication Tag)
JWEコンパクトシリアライズがサポートする
受信者は1人のみであり、JWE共有非保護ヘッダー、
JWE受信者別非保護ヘッダー、またはJWE AAD値
を表現する構文はありません。
7.2. JWE JSONシリアライズ
JWE JSONシリアライズは、暗号化された内容を
JSONオブジェクトとして表現します。この表現は
コンパクト性のために最適化されておらず、
URLセーフでもありません。
Jones & Hildebrand Standards Track [Page 20]
RFC 7516 JSON Web Encryption (JWE) May 2015
JWE JSONシリアライズには、密接に関連する2つの
構文が定義されています：複数の受信者に内容を
暗号化できる完全な一般的構文と、単一受信者向けに
最適化されたフラット構文です。
7.2.1. 一般的JWE JSONシリアライズ構文
完全な一般的JWE JSONシリアライズ構文で使用
されるトップレベルJSONオブジェクトには、以下の
メンバーが定義されます：
protected
JWE Protected Headerの値が空でない場合、
"protected" メンバーは必ず存在し、値は
BASE64URL(UTF8(JWE Protected Header))に
しなければなりません。そうでない場合は省略
しなければなりません。これらのヘッダー
パラメータは完全性保護されます。
unprotected
JWE Shared Unprotected Headerの値が空で
ない場合、"unprotected"メンバーは必ず存在し
その値はJWE Shared Unprotected Headerで
なければなりません。この値は文字列ではなく
エンコードされていないJSONオブジェクトで表現
されます。これらのヘッダーパラメータは完全性
保護されません。
iv
JWE Initialization Vectorの値が空でない場合、
"iv"メンバーは必ず存在し、その値は
BASE64URL(JWE Initialization Vector)
でなければなりません。そうでない場合は
省略しなければなりません。
aad
JWE AAD値が空でない場合、"aad"メンバーは
必ず存在し、その値はBASE64URL(JWE AAD)で
なければなりません。そうでない場合は省略
しなければなりません。JWE AAD値は、base64url
エンコードされた値で、完全性保護はされるが
暗号化はされていない値を含めるために使えます。
ciphertext
"ciphertext"メンバーは必ず存在し、その値は
BASE64URL(JWE Ciphertext)でなければなりません。
tag
JWE Authentication Tagの値が空でない場合、
"tag"メンバーは必ず存在し、その値は
BASE64URL(JWE Authentication Tag)で
なければなりません。そうでない場合は省略
しなければなりません。
recipients
"recipients"メンバー値は必ずJSONオブジェクト
の配列でなければなりません。各オブジェクトは
単一受信者に固有の情報を含みます。このメンバー
は受信者ごとに正確に1つの配列要素が必要です
Jones & Hildebrand Standards Track [Page 21]
RFC 7516 JSON Web Encryption (JWE) May 2015
recipientについては、配列要素の一部またはすべての値が
空のJSONオブジェクト "{}" であっても存在します（これは、
すべてのHeader Parameter値がすべてのrecipient間で共有され、
かつ暗号化キーが使用されない、例えばDirect Encryptionの場合など
に発生します）。
次のメンバーは "recipients" 配列の要素である
JSONオブジェクトで使用するために定義されています。
header
"header" メンバーは、JWE Per-Recipient Unprotected Headerの値が空
でない場合には必ず存在しその値を含まなければなりません。
そうでない場合は省略しなければなりません。この値は
文字列としてではなく、そのままのJSONオブジェクトとして
表現されます。これらのHeader Parameter値は
完全性の保護を受けません。
encrypted_key
"encrypted_key" メンバーは、JWE Encrypted Keyの値が非空の場合には
必ず存在し、値BASE64URL(JWE Encrypted Key)を含めなければなりません。
そうでない場合は省略しなければなりません。
"header"、"protected"、"unprotected" のうち少なくとも1つのメンバー
が存在しなければならず、各recipientの計算のために "alg" および
"enc" Header Parameter値が伝達されます。
上記で定義されたJSONオブジェクトには追加のメンバーを含める
ことができます。もし実装がそれらを理解できなくても、
無視されなければなりません。
一部のHeader Parameter（"alg"パラメータなど）は全recipient処理で
共有できます。JWE Protected HeaderおよびJWE Shared Unprotected
Header内のHeader Parameterは全recipientで共有されます。
recipientごとに暗号文や認証タグを生成または検証する際に使われる
ヘッダーパラメータ値は、(1) "protected" メンバーで表されるJWE
Protected Header、(2) "unprotected" メンバーで表されるJWE Shared
Unprotected Header、(3) recipient配列要素の "header" メンバーで
表されるJWE Per-Recipient Unprotected Header、の3つのセットの
ユニオン（和集合）です。これらを合わせてJOSE Headerと呼びます。
この3箇所におけるHeader Parameter名は互いに重複してはなりません。
各JWE Encrypted Key値は対応するJOSE Header値のパラメータを使い
JWE Compact Serializationと同様の方法で計算されます。
これにより "recipients" 配列の各JWE Encrypted Key値が、同じ
パラメータに対するJWE Compact Serializationで計算される値と
一致するという好ましい特性が得られます。
Jones & Hildebrand Standards Track [Page 22]
RFC 7516 JSON Web Encryption (JWE) May 2015
同様に、JWE CiphertextとJWE Authentication Tagの値も、
JWE Protected Header値（完全性保護されたHeader Parameter値）が
JWE Compact Serializationで使われたものと一致するならば、
Compact Serializationで生成されたものと一致します。
すべてのrecipientは、JWE Protected Header、JWE Initialization
Vector、JWE Ciphertext、JWE Authentication Tag（存在する場合）を
共通で使用します。メッセージが大きい場合は大きな
スペース節約となり得ます。そのため、平文の扱いに関する
すべてのHeader Parameterはすべてのrecipientで同じで
なければなりません。具体的には各recipientのJOSE Headerにある
"enc"（暗号化アルゴリズム）Header Parameter値およびそのパラメータは
全員で同一でなければなりません。
要約すると、一般的なJWE JSON Serializationを用いたJWEの構文は
次の通りです：
{
"protected":"<完全性保護済み共有ヘッダー内容>",
"unprotected":<完全性保護されない共有ヘッダー内容>,
"recipients":[
{"header":<recipientごとの非保護ヘッダー1内容>,
"encrypted_key":"<暗号化キー1内容>"},
...
{"header":<recipientごとの非保護ヘッダーN内容>,
"encrypted_key":"<暗号化キーN内容>"}],
"aad":"<付加認証データ内容>",
"iv":"<初期化ベクター内容>",
"ciphertext":"<暗号文内容>",
"tag":"<認証タグ内容>"
}
一般的なJWE JSON Serialization構文で記述されたJWEの例については
Appendix A.4 を参照してください。
7.2.2. Flattened JWE JSON Serialization Syntax
Flattened JWE JSON Serialization構文は、一般構文を基にしていま
すが、単一recipientケース向けに最適化し、"recipients"メンバーを
削除して配列で使われていた"header"や"encrypted_key"メンバーを
( "ciphertext" メンバーと同じレベルで ) 最上位JSONオブジェクトに
移します。
Jones & Hildebrand Standards Track [Page 23]
RFC 7516 JSON Web Encryption (JWE) May 2015
この構文を使用する場合、"recipients" メンバーは
含めてはなりません。この構文上の違い以外、flat構文を使う
JWE JSON Serializationオブジェクトは、一般構文のものと
同様に処理されます。
要約すると、flattened JWE JSON Serializationを用いたJWEの
構文は以下の通りです：
{
"protected":"<完全性保護済みヘッダー内容>",
"unprotected":<完全性保護されないヘッダー内容>,
"header":<さらに非保護のヘッダー内容>,
"encrypted_key":"<暗号化キー内容>",
"aad":"<付加認証データ内容>",
"iv":"<初期化ベクター内容>",
"ciphertext":"<暗号文内容>",
"tag":"<認証タグ内容>"
}
flatten構文利用時も、一般構文の場合と同様に、どの非保護
ヘッダーパラメータ値も "unprotected"メンバーまたは"header"
メンバー、あるいは両方に存在できます。
flatten JWE JSON Serialization構文の例については
Appendix A.5 を参照してください。
8. TLS Requirements
この仕様のTransport Layer Security (TLS)要件は
[JWS] の セクション8と同じです。
9. Distinguishing between JWS and JWE Objects
オブジェクトがJWSかJWEかを区別する方法はいくつかあります。
これらの方法は、すべての正しい入力値に対して同じ結果を返し、
不正な入力で異なる結果になる場合があります。
o オブジェクトがJWS Compact SerializationまたはJWE
Compact Serializationを使用している場合、ピリオド('.')で
区切られたbase64urlエンコードセグメントの数が
JWSとJWEで異なります。JWSは2つのピリオド('.')で区切られた
3つのセグメントを持ち、JWEは4つのピリオド('.')で
区切られた5つのセグメントを持ちます。
o オブジェクトがJWS JSON SerializationまたはJWE JSON
Serializationを使っている場合、利用されるメンバーが
異なります。JWSは"payload"メンバーを持ちJWEは持ちません。
JWEは"ciphertext"メンバーを持ちJWSは持ちません。
Jones & Hildebrand Standards Track [Page 24]
RFC 7516 JSON Web Encryption (JWE) May 2015
o JWSのJOSEヘッダーは"alg"（アルゴリズム）ヘッダーパラメータ値を調べることでJWEのJOSEヘッダーと区別できる。
その値がデジタル署名またはMACアルゴリズム、もしくは値"none"であればJWS用である。
それが鍵暗号化、鍵ラッピング、直接鍵合意、鍵ラッピングを伴う鍵合意、または直接暗号化アルゴリズムの場合はJWE用となる。
（"alg"値の抽出はJWSコンパクトシリアライゼーションやJWEコンパクトシリアライゼーションでは容易であり、
JWS JSONシリアライゼーションやJWE JSONシリアライゼーションの場合はより難しくなる場合がある。）
o また、JWSのJOSEヘッダーは"enc"（暗号化アルゴリズム）メンバーの有無によってもJWEのJOSEヘッダーと区別できる。
"enc"メンバーが存在する場合はJWE、それ以外はJWSである。
10. IANAに関する考慮事項
10.1. JSON Web署名および暗号ヘッダーパラメータ登録
本節では4.1節で定義されるヘッダーパラメータ名を
IANAによって設立された「JSON Web Signature and Encryption Header Parameters」レジストリに登録する
（[JWS]）。
10.1.1. レジストリ内容
o ヘッダーパラメータ名: "alg"
o ヘッダーパラメータ説明: アルゴリズム
o ヘッダーパラメータ使用場所: JWE
o 変更管理者: IESG
o 仕様書: RFC 7516 第4.1.1節
o ヘッダーパラメータ名: "enc"
o ヘッダーパラメータ説明: 暗号化アルゴリズム
o ヘッダーパラメータ使用場所: JWE
o 変更管理者: IESG
o 仕様書: RFC 7516 第4.1.2節
o ヘッダーパラメータ名: "zip"
o ヘッダーパラメータ説明: 圧縮アルゴリズム
o ヘッダーパラメータ使用場所: JWE
o 変更管理者: IESG
o 仕様書: RFC 7516 第4.1.3節
Jones & Hildebrand Standards Track [Page 25]
RFC 7516 JSON Web Encryption (JWE) May 2015
o ヘッダーパラメータ名: "jku"
o ヘッダーパラメータ説明: JWKセットURL
o ヘッダーパラメータ使用場所: JWE
o 変更管理者: IESG
o 仕様書: RFC 7516 第4.1.4節
o ヘッダーパラメータ名: "jwk"
o ヘッダーパラメータ説明: JSON Web Key
o ヘッダーパラメータ使用場所: JWE
o 変更管理者: IESG
o 仕様書: RFC 7516 第4.1.5節
o ヘッダーパラメータ名: "kid"
o ヘッダーパラメータ説明: 鍵ID
o ヘッダーパラメータ使用場所: JWE
o 変更管理者: IESG
o 仕様書: RFC 7516 第4.1.6節
o ヘッダーパラメータ名: "x5u"
o ヘッダーパラメータ説明: X.509 URL
o ヘッダーパラメータ使用場所: JWE
o 変更管理者: IESG
o 仕様書: RFC 7516 第4.1.7節
o ヘッダーパラメータ名: "x5c"
o ヘッダーパラメータ説明: X.509証明書チェーン
o ヘッダーパラメータ使用場所: JWE
o 変更管理者: IESG
o 仕様書: RFC 7516 第4.1.8節
o ヘッダーパラメータ名: "x5t"
o ヘッダーパラメータ説明: X.509証明書SHA-1サムプリント
o ヘッダーパラメータ使用場所: JWE
o 変更管理者: IESG
o 仕様書: RFC 7516 第4.1.9節
o ヘッダーパラメータ名: "x5t#S256"
o ヘッダーパラメータ説明: X.509証明書SHA-256サムプリント
o ヘッダーパラメータ使用場所: JWE
o 変更管理者: IESG
o 仕様書: RFC 7516 第4.1.10節
o ヘッダーパラメータ名: "typ"
o ヘッダーパラメータ説明: タイプ
o ヘッダーパラメータ使用場所: JWE
o 変更管理者: IESG
o 仕様書: RFC 7516 第4.1.11節
Jones & Hildebrand Standards Track [Page 26]
RFC 7516 JSON Web Encryption (JWE) May 2015
o ヘッダーパラメータ名: "cty"
o ヘッダーパラメータ説明: コンテントタイプ
o ヘッダーパラメータ使用場所: JWE
o 変更管理者: IESG
o 仕様書: RFC 7516 第4.1.12節
o ヘッダーパラメータ名: "crit"
o ヘッダーパラメータ説明: クリティカル
o ヘッダーパラメータ使用場所: JWE
o 変更管理者: IESG
o 仕様書: RFC 7516 第4.1.13節
11. セキュリティに関する考慮事項
いかなる暗号アプリケーションに関係するすべてのセキュリティ課題はJWS/JWE/JWKエージェントによって対処されなければならない。
これらの課題には、利用者の非対称秘密鍵および共通鍵シークレットの保護や、多様な攻撃への対策が含まれる。
JWS仕様に記載されているすべてのセキュリティ考慮事項は、この仕様にも該当する。
同様に、XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411]におけるすべてのセキュリティ考慮事項も、XML固有の場合を除き適用される。
11.1. 鍵エントロピーとランダム値
鍵エントロピーとランダム値に関するセキュリティの考慮事項は[JWS]の10.1節を参照のこと。
そこで挙げられている用途に加えて、暗号処理中にはコンテンツ暗号鍵（CEK）や初期化ベクトル（IV）にもランダム値が使用されることに注意。
11.2. 鍵の保護
鍵の保護に関するセキュリティ考慮事項は[JWS]の10.2節を参照のこと。
そこで挙げられている鍵に加え、暗号を実施する実装では鍵暗号化鍵およびコンテンツ暗号鍵も保護しなければならない。
鍵暗号化鍵が漏洩すると、その鍵で保護されたすべての内容が漏えいする危険がある。
同様に、コンテンツ暗号鍵の漏洩は関連する暗号化されたコンテンツの漏洩につながる。
Jones & Hildebrand Standards Track [Page 27]
RFC 7516 JSON Web Encryption (JWE) May 2015
11.3. アルゴリズム強度の一致利用
可能な限り、同等の強度を持つアルゴリズムを組み合わせて使用するべきです。例えば、AESキーラップに特定の鍵サイズを使用している場合、
AES GCMでも同じ鍵サイズを使用することが推奨されます。鍵暗号化アルゴリズムとコンテンツ暗号化アルゴリズムが異なる場合、
実効的なセキュリティ強度はその二つのうち弱い方によって決まります。
また、公開鍵による対称鍵交換の強度判定に関する詳細はRFC 3766
[RFC3766]を参照のこと。
11.4. 適応型選択暗号文攻撃
復号時に、JWE受信者がメッセージ復号のオラクルとして利用されることのないよう、特に注意を払う必要がある。
RFC 3218 [RFC3218]で
RSAES-PKCS1-v1_5に対する攻撃への具体的対策が記載されているので参照のこと。
攻撃者は"alg"ヘッダーパラメータを"RSA-OAEP"から"RSA1_5"へ変更し、CEKの回復に利用できる書式エラーを発生させる可能性がある（たとえCEKがRSAES-OAEPで暗号化されていても）。
したがって、暗号化内容の拒否時には、CEK・追加認証データ・暗号文いずれの書式エラーも必ず一括のエラーとして通知することが重要である。
さらに、この種の攻撃は鍵の利用を特定のアルゴリズム、通常はひとつに限定することで防ぐことができる。
すなわち、鍵が"RSA-OAEP"専用とマークされている場合、その鍵で"RSA1_5"アルゴリズムを使ってメッセージを復号しようとした場合は
即座に無効利用として失敗しなければならない。
11.5. タイミング攻撃
RFC 3218 [RFC3218]で述べられている
攻撃を緩和するために、受信者は暗号鍵の書式・パディング・長さエラーを区別してはならない。
不正なフォーマットの鍵を受信した場合には、ランダム生成したCEKで次のステップへ進めることが強く推奨される。これはタイミング攻撃の緩和のためである。
Jones & Hildebrand Standards Track [Page 28]
RFC 7516 JSON Web Encryption (JWE) May 2015
12. 参考文献
12.1. 規範的参照
[JWA] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, 2015年5月,
<http://www.rfc-editor.org/info/rfc7518>.
[JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, 2015年5月,
<http://www.rfc-editor.org/info/rfc7517>.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, 2015年5月,
<http://www.rfc-editor.org/info/rfc7515>.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, DOI 10.17487/RFC1951, 1996年5月,
<http://www.rfc-editor.org/info/rfc1951>.
[RFC20] Cerf, V., "ASCII format for Network Interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, 1969年10月,
<http://www.rfc-editor.org/info/rfc20>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, 1997年3月,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, 2003年11月,
<http://www.rfc-editor.org/info/rfc3629>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, 2007年8月,
<http://www.rfc-editor.org/info/rfc4949>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, 2008年5月,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, 2014年3月,
<http://www.rfc-editor.org/info/rfc7159>.
Jones & Hildebrand Standards Track [Page 29]
RFC 7516 JSON Web Encryption (JWE) May 2015
[UNICODE] The Unicode Consortium, "The Unicode Standard",
<http://www.unicode.org/versions/latest/>.
12.2. 情報的参照
[AES] National Institute of Standards and Technology (NIST),
"Advanced Encryption Standard (AES)", FIPS PUB 197,
November 2001, <http://csrc.nist.gov/publications/
fips/fips197/fips-197.pdf>.
[JSE] Bradley, J. and N. Sakimura (editor), "JSON Simple
Encryption", September 2010,
<http://jsonenc.info/enc/1.0/>.
[JSMS] Rescorla, E. and J. Hildebrand, "JavaScript Message
Security Format", Work in Progress,
draft-rescorla-jsms-00, 2011年3月.
[NIST.800-38D]
National Institute of Standards and Technology (NIST),
"Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC", NIST PUB 800-38D,
2007年11月, <http://csrc.nist.gov/publications/
nistpubs/800-38D/SP-800-38D.pdf>.
[RFC3218] Rescorla, E., "Preventing the Million Message Attack on
Cryptographic Message Syntax", RFC 3218,
DOI 10.17487/RFC3218, 2002年1月,
<http://www.rfc-editor.org/info/rfc3218>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, DOI 10.17487/RFC3447, 2003年2月,
<http://www.rfc-editor.org/info/rfc3447>.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, DOI 10.17487/RFC3766, 2004年4月,
<http://www.rfc-editor.org/info/rfc3766>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, 2005年6月,
<http://www.rfc-editor.org/info/rfc4086>.
Jones & Hildebrand Standards Track [Page 30]
RFC 7516 JSON Web Encryption (JWE) May 2015
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, 2009年9月,
<http://www.rfc-editor.org/info/rfc5652>.
[W3C.REC-xmlenc-core1-20130411]
Eastlake, D., Reagle, J., Hirsch, F., and T. Roessler,
"XML Encryption Syntax and Processing Version 1.1", World
Wide Web Consortium Recommendation
REC-xmlenc-core1-20130411, 2013年4月,
<http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/>.
Jones & Hildebrand Standards Track [Page 31]
RFC 7516 JSON Web Encryption (JWE) May 2015
Appendix A. JWEの例
本節ではJWE計算の例を示します。
A.1. RSAES-OAEPとAES GCMを用いたJWEの例
この例では、平文 "The true sign of intelligence is
not knowledge but imagination." を受信者へ暗号化します。鍵暗号化にはRSAES-OAEPを、
コンテンツ暗号化にはAES GCMを使用します。平文の表現（JSON配列表記）は次の通りです：
[84, 104, 101, 32, 116, 114, 117, 101, 32, 115, 105, 103, 110, 32,
111, 102, 32, 105, 110, 116, 101, 108, 108, 105, 103, 101, 110, 99,
101, 32, 105, 115, 32, 110, 111, 116, 32, 107, 110, 111, 119, 108,
101, 100, 103, 101, 32, 98, 117, 116, 32, 105, 109, 97, 103, 105,
110, 97, 116, 105, 111, 110, 46]
A.1.1. JOSE ヘッダー
以下の例のJWE保護ヘッダーは次のことを宣言しています：
o コンテンツ暗号鍵（CEK）はRSAES-OAEPアルゴリズムを用いて受信者に暗号化され、JWE暗号化鍵が生成される。
o 平文に対して認証付き暗号化がAES GCMアルゴリズム（256ビット鍵）で行われ、暗号文と認証タグが生成される。
{"alg":"RSA-OAEP","enc":"A256GCM"}
このJWE保護ヘッダーをBASE64URL(UTF8(JWE Protected
Header))としてエンコードすると次の値になります：
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ
A.1.2. コンテンツ暗号鍵（CEK）
256ビットのランダムなCEKを生成します。本例では値（JSON配列表記）は次の通りです：
[177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154,
212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122,
234, 64, 252]
Jones & Hildebrand Standards Track [Page 32]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.1.3. 鍵の暗号化
受信者の公開鍵を用いてRSAES-OAEPアルゴリズムでCEKを暗号化し、JWE暗号化鍵を生成します。本例では以下のJSON Web Key [JWK]形式のRSA鍵を使用します（表示上の都合で値の途中に改行があります）：
{"kty":"RSA",
"n":"oahUIoWw0K0usKNuOR6H4wkf4oBUXHTxRvgb48E-BVvxkeDNjbC4he8rUW
cJoZmds2h7M70imEVhRU5djINXtqllXI4DFqcI1DgjT9LewND8MW2Krf3S
psk_ZkoFnilakGygTwpZ3uesH-PFABNIUYpOiN15dsQRkgr0vEhxN92i2a
sbOenSZeyaxziK72UwxrrKoExv6kc5twXTq4h-QChLOln0_mtUZwfsRaMS
tPs6mS6XrgxnxbWhojf663tuEQueGC-FCMfra36C9knDFGzKsNa7LZK2dj
YgyD3JR_MB_4NUJW_TqOQtwHYbxevoJArm-L5StowjzGy-_bq6Gw",
"e":"AQAB",
"d":"kLdtIj6GbDks_ApCSTYQtelcNttlKiOyPzMrXHeI-yk1F7-kpDxY4-WY5N
WV5KntaEeXS1j82E375xxhWMHXyvjYecPT9fpwR_M9gV8n9Hrh2anTpTD9
3Dt62ypW3yDsJzBnTnrYu1iwWRgBKrEYY46qAZIrA2xAwnm2X7uGR1hghk
qDp0Vqj3kbSCz1XyfCs6_LehBwtxHIyh8Ripy40p24moOAbgxVw3rxT_vl
t3UVe4WO3JkJOzlpUf-KTVI2Ptgm-dARxTEtE-id-4OJr0h-K-VFs3VSnd
VTIznSxfyrj8ILL6MG_Uv8YAu7VILSB3lOW085-4qE3DzgrTjgyQ",
"p":"1r52Xk46c-LsfB5P442p7atdPUrxQSy4mti_tZI3Mgf2EuFVbUoDBvaRQ-
SWxkbkmoEzL7JXroSBjSrK3YIQgYdMgyAEPTPjXv_hI2_1eTSPVZfzL0lf
fNn03IXqWF5MDFuoUYE0hzb2vhrlN_rKrbfDIwUbTrjjgieRbwC6Cl0",
"q":"wLb35x7hmQWZsWJmB_vle87ihgZ19S8lBEROLIsZG4ayZVe9Hi9gDVCOBm
UDdaDYVTSNx_8Fyw1YYa9XGrGnDew00J28cRUoeBB_jKI1oma0Orv1T9aX
IWxKwd4gvxFImOWr3QRL9KEBRzk2RatUBnmDZJTIAfwTs0g68UZHvtc",
"dp":"ZK-YwE7diUh0qR1tR7w8WHtolDx3MZ_OTowiFvgfeQ3SiresXjm9gZ5KL
hMXvo-uz-KUJWDxS5pFQ_M0evdo1dKiRTjVw_x4NyqyXPM5nULPkcpU827
rnpZzAJKpdhWAgqrXGKAECQH0Xt4taznjnd_zVpAmZZq60WPMBMfKcuE",
"dq":"Dq0gfgJ1DdFGXiLvQEZnuKEN0UUmsJBxkjydc3j4ZYdBiMRAy86x0vHCj
ywcMlYYg4yoC4YZa9hNVcsjqA3FeiL19rk8g6Qn29Tt0cj8qqyFpz9vNDB
UfCAiJVeESOjJDZPYHdHY8v1b-o-Z2X5tvLx-TCekf7oxyeKDUqKWjis",
"qi":"VIMpMYbPf47dT1w_zDUXfPimsSegnMOA1zTaX7aGk_8urY6R8-ZW1FxU7
AlWAyLWybqq6t16VFd7hQd0y6flUK4SlOydB61gwanOsXGOAOv82cHq0E3
eL4HrtZkUuKvnPrMnsUUFlfUdybVzxyjz9JF_XyaY14ardLSjf4L_FNY"
}
Jones & Hildebrand Standards Track [Page 33]
RFC 7516 JSON Web Encryption (JWE) May 2015
結果として得られるJWE暗号化鍵の値は次の通りです：
[56, 163, 154, 192, 58, 53, 222, 4, 105, 218, 136, 218, 29, 94, 203,
22, 150, 92, 129, 94, 211, 232, 53, 89, 41, 60, 138, 56, 196, 216,
82, 98, 168, 76, 37, 73, 70, 7, 36, 8, 191, 100, 136, 196, 244, 220,
145, 158, 138, 155, 4, 117, 141, 230, 199, 247, 173, 45, 182, 214,
74, 177, 107, 211, 153, 11, 205, 196, 171, 226, 162, 128, 171, 182,
13, 237, 239, 99, 193, 4, 91, 219, 121, 223, 107, 167, 61, 119, 228,
173, 156, 137, 134, 200, 80, 219, 74, 253, 56, 185, 91, 177, 34, 158,
89, 154, 205, 96, 55, 18, 138, 43, 96, 218, 215, 128, 124, 75, 138,
243, 85, 25, 109, 117, 140, 26, 155, 249, 67, 167, 149, 231, 100, 6,
41, 65, 214, 251, 232, 87, 72, 40, 182, 149, 154, 168, 31, 193, 126,
215, 89, 28, 111, 219, 125, 182, 139, 235, 195, 197, 23, 234, 55, 58,
63, 180, 68, 202, 206, 149, 75, 205, 248, 176, 67, 39, 178, 60, 98,
193, 32, 238, 122, 96, 158, 222, 57, 183, 111, 210, 55, 188, 215,
206, 180, 166, 150, 166, 106, 250, 55, 229, 72, 40, 69, 214, 216,
104, 23, 40, 135, 212, 28, 127, 41, 80, 175, 174, 168, 115, 171, 197,
89, 116, 92, 103, 246, 83, 216, 182, 176, 84, 37, 147, 35, 45, 219,
172, 99, 226, 233, 73, 37, 124, 42, 72, 49, 242, 35, 127, 184, 134,
117, 114, 135, 206]
このJWE暗号化鍵をBASE64URL(JWE Encrypted Key)としてエンコードすると（表示のために改行あり）次の値になります：
OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe
ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb
Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV
mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8
1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi
6UklfCpIMfIjf7iGdXKHzg
A.1.4. 初期化ベクトル
96ビットのランダムなJWE初期化ベクトルを生成します。本例の値は次の通りです：
[227, 197, 117, 252, 2, 219, 233, 68, 180, 225, 77, 219]
このJWE初期化ベクトルをBASE64URL(JWE
Initialization Vector)としてエンコードすると次の値になります：
48V1_ALb6US04U3b
Jones & Hildebrand Standards Track [Page 34]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.1.5. 追加認証データ
追加認証データ（Additional Authenticated Data）暗号化パラメータを
ASCII(BASE64URL(UTF8(JWE Protected Header)))とします。この値は次の通りです：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69,
116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73,
54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 102, 81]
A.1.6. コンテンツ暗号化
CEKを暗号化鍵として、JWE初期化ベクトルおよび上記の追加認証データを用い、
AES GCMアルゴリズムで平文に対して認証付き暗号化を行い、128ビットの認証タグを要求します。得られた暗号文は次の通りです：
[229, 236, 166, 241, 53, 191, 115, 196, 174, 43, 73, 109, 39, 122,
233, 96, 140, 206, 120, 52, 51, 237, 48, 11, 190, 219, 186, 80, 111,
104, 50, 142, 47, 167, 59, 61, 181, 127, 196, 21, 40, 82, 242, 32,
123, 143, 168, 226, 73, 216, 176, 144, 138, 247, 106, 60, 16, 205,
160, 109, 64, 63, 192]
得られた認証タグの値は次の通りです：
[92, 80, 104, 49, 133, 25, 161, 215, 173, 101, 219, 211, 136, 91,
210, 145]
このJWE暗号文をBASE64URL(JWE Ciphertext)としてエンコードすると（表示のために改行あり）次の値になります：
5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji
SdiwkIr3ajwQzaBtQD_A
このJWE認証タグをBASE64URL(JWE Authentication
Tag)としてエンコードすると次の値になります：
XFBoMYUZodetZdvTiFvSkQ
Jones & Hildebrand Standards Track [Page 35]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.1.7. 完全な表現
最終表現を組み立てます：この結果のコンパクト・シリアライゼーションは文字列
BASE64URL(UTF8(JWE Protected Header)) || '.' ||
BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization
Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE
Authentication Tag) です。
本例の最終結果（表示のために改行あり）は次の通りです：
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.
OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe
ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb
Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV
mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8
1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi
6UklfCpIMfIjf7iGdXKHzg.
48V1_ALb6US04U3b.
5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji
SdiwkIr3ajwQzaBtQD_A.
XFBoMYUZodetZdvTiFvSkQ
A.1.8. 検証
この例は、鍵暗号化にRSAES-OAEP、コンテンツ暗号化にAES GCMを用いてJWEを作成する過程を示しています。
これらの結果は、これらのアルゴリズムを用いたJWE復号の実装を検証するために使用できます。RSAES-OAEPの計算にはランダム値が含まれるため、上記の暗号化結果は完全に再現可能ではないことに注意してください。
しかし、AES GCMの計算は決定的であるため、これらの入力を用いて行われるすべての暗号化に対してJWE暗号化された暗号文の値は同一になります。
A.2. RSAES-PKCS1-v1_5とAES_128_CBC_HMAC_SHA_256を用いたJWEの例
この例では、平文 "Live long and prosper." を受信者へ暗号化します。鍵暗号化にはRSAES-PKCS1-v1_5を、
コンテンツ暗号化にはAES_128_CBC_HMAC_SHA_256を使用します。平文の表現（JSON配列表記）は次の通りです：
[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32,
112, 114, 111, 115, 112, 101, 114, 46]
Jones & Hildebrand Standards Track [Page 36]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.2.1. JOSE ヘッダー
以下の例のJWE保護ヘッダーは次のことを宣言しています：
o コンテンツ暗号鍵（CEK）はRSAES-PKCS1-v1_5アルゴリズムを用いて受信者に暗号化され、JWE暗号化鍵が生成される。
o 平文に対して認証付き暗号化がAES_128_CBC_HMAC_SHA_256アルゴリズムで行われ、暗号文と認証タグが生成される。
{"alg":"RSA1_5","enc":"A128CBC-HS256"}
このJWE保護ヘッダーをBASE64URL(UTF8(JWE Protected
Header))としてエンコードすると次の値になります：
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
A.2.2. コンテンツ暗号鍵（CEK）
256ビットのランダムなCEKを生成します。本例の鍵値は次の通りです：
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106,
206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156,
44, 207]
Jones & Hildebrand Standards Track [Page 37]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.2.3. 鍵の暗号化
受信者の公開鍵を使用してCEKを
RSAES-PKCS1-v1_5アルゴリズムで暗号化し、JWE暗号化鍵を生成します。 この
例では、以下のJSON Web Key [JWK]形式で表されたRSA鍵を使用します（表示の便宜上、値の途中に改行があります）:
{"kty":"RSA",
"n":"sXchDaQebHnPiGvyDOAT4saGEUetSyo9MKLOoWFsueri23bOdgWp4Dy1Wl
UzewbgBHod5pcM9H95GQRV3JDXboIRROSBigeC5yjU1hGzHHyXss8UDpre
cbAYxknTcQkhslANGRUZmdTOQ5qTRsLAt6BTYuyvVRdhS8exSZEy_c4gs_
7svlJJQ4H9_NxsiIoLwAEk7-Q3UXERGYw_75IDrGA84-lA_-Ct4eTlXHBI
Y2EaV7t7LjJaynVJCpkv4LKjTTAumiGUIuQhrNhZLuF_RJLqHpM2kgWFLU
7-VTdL1VbC2tejvcI2BlMkEpk1BzBZI0KQB0GaDWFLN-aEAw3vRw",
"e":"AQAB",
"d":"VFCWOqXr8nvZNyaaJLXdnNPXZKRaWCjkU5Q2egQQpTBMwhprMzWzpR8Sxq
1OPThh_J6MUD8Z35wky9b8eEO0pwNS8xlh1lOFRRBoNqDIKVOku0aZb-ry
nq8cxjDTLZQ6Fz7jSjR1Klop-YKaUHc9GsEofQqYruPhzSA-QgajZGPbE_
0ZaVDJHfyd7UUBUKunFMScbflYAAOYJqVIVwaYR5zWEEceUjNnTNo_CVSj
-VvXLO5VZfCUAVLgW4dpf1SrtZjSt34YLsRarSb127reG_DUwg9Ch-Kyvj
T1SkHgUWRVGcyly7uvVGRSDwsXypdrNinPA4jlhoNdizK2zF2CWQ",
"p":"9gY2w6I6S6L0juEKsbeDAwpd9WMfgqFoeA9vEyEUuk4kLwBKcoe1x4HG68
ik918hdDSE9vDQSccA3xXHOAFOPJ8R9EeIAbTi1VwBYnbTp87X-xcPWlEP
krdoUKW60tgs1aNd_Nnc9LEVVPMS390zbFxt8TN_biaBgelNgbC95sM",
"q":"uKlCKvKv_ZJMVcdIs5vVSU_6cPtYI1ljWytExV_skstvRSNi9r66jdd9-y
BhVfuG4shsp2j7rGnIio901RBeHo6TPKWVVykPu1iYhQXw1jIABfw-MVsN
-3bQ76WLdt2SDxsHs7q7zPyUyHXmps7ycZ5c72wGkUwNOjYelmkiNS0",
"dp":"w0kZbV63cVRvVX6yk3C8cMxo2qCM4Y8nsq1lmMSYhG4EcL6FWbX5h9yuv
ngs4iLEFk6eALoUS4vIWEwcL4txw9LsWH_zKI-hwoReoP77cOdSL4AVcra
Hawlkpyd2TWjE5evgbhWtOxnZee3cXJBkAi64Ik6jZxbvk-RR3pEhnCs",
"dq":"o_8V14SezckO6CNLKs_btPdFiO9_kC1DsuUTd2LAfIIVeMZ7jn1Gus_Ff
7B7IVx3p5KuBGOVF8L-qifLb6nQnLysgHDh132NDioZkhH7mI7hPG-PYE_
odApKdnqECHWw0J-F0JWnUd6D2B_1TvF9mXA2Qx-iGYn8OVV1Bsmp6qU",
"qi":"eNho5yRBEBxhGBtQRww9QirZsB66TrfFReG_CcteI1aCneT0ELGhYlRlC
tUkTRclIfuEPmNsNDPbLoLqqCVznFbvdB7x-Tl-m0l_eFTj2KiqwGqE9PZ
B9nNTwMVvH3VRRSLWACvPnSiwP8N5Usy-WRXS-V7TbpxIhvepTfE0NNo"
}
Jones & Hildebrand Standards Track [Page 38]
RFC 7516 JSON Web Encryption (JWE) May 2015
結果として得られるJWE暗号化鍵の値は次の通りです：
[80, 104, 72, 58, 11, 130, 236, 139, 132, 189, 255, 205, 61, 86, 151,
176, 99, 40, 44, 233, 176, 189, 205, 70, 202, 169, 72, 40, 226, 181,
156, 223, 120, 156, 115, 232, 150, 209, 145, 133, 104, 112, 237, 156,
116, 250, 65, 102, 212, 210, 103, 240, 177, 61, 93, 40, 71, 231, 223,
226, 240, 157, 15, 31, 150, 89, 200, 215, 198, 203, 108, 70, 117, 66,
212, 238, 193, 205, 23, 161, 169, 218, 243, 203, 128, 214, 127, 253,
215, 139, 43, 17, 135, 103, 179, 220, 28, 2, 212, 206, 131, 158, 128,
66, 62, 240, 78, 186, 141, 125, 132, 227, 60, 137, 43, 31, 152, 199,
54, 72, 34, 212, 115, 11, 152, 101, 70, 42, 219, 233, 142, 66, 151,
250, 126, 146, 141, 216, 190, 73, 50, 177, 146, 5, 52, 247, 28, 197,
21, 59, 170, 247, 181, 89, 131, 241, 169, 182, 246, 99, 15, 36, 102,
166, 182, 172, 197, 136, 230, 120, 60, 58, 219, 243, 149, 94, 222,
150, 154, 194, 110, 227, 225, 112, 39, 89, 233, 112, 207, 211, 241,
124, 174, 69, 221, 179, 107, 196, 225, 127, 167, 112, 226, 12, 242,
16, 24, 28, 120, 182, 244, 213, 244, 153, 194, 162, 69, 160, 244,
248, 63, 165, 141, 4, 207, 249, 193, 79, 131, 0, 169, 233, 127, 167,
101, 151, 125, 56, 112, 111, 248, 29, 232, 90, 29, 147, 110, 169,
146, 114, 165, 204, 71, 136, 41, 252]
このJWE暗号化鍵をBASE64URL(JWE Encrypted Key)としてエンコードすると（表示のために改行あり）次の値になります：
UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-kFm
1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKxGHZ7Pc
HALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3YvkkysZIF
NPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPhcCdZ6XDP0_F8
rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPgwCp6X-nZZd9OHBv
-B3oWh2TbqmScqXMR4gp_A
A.2.4. 初期化ベクトル
128ビットのランダムなJWE初期化ベクトルを生成します。 この
例では、値は次の通りです：
[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104,
101]
このJWE初期化ベクトルをBASE64URL(JWE
Initialization Vector)としてエンコードすると次の値になります：
AxY8DCtDaGlsbGljb3RoZQ
Jones & Hildebrand Standards Track [Page 39]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.2.5. 追加認証データ
追加認証データ（Additional Authenticated Data）暗号化パラメータを
ASCII(BASE64URL(UTF8(JWE Protected Header))). この値は次の通りです：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69,
120, 88, 122, 85, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105,
74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85,
50, 73, 110, 48]
A.2.6. コンテンツ暗号化
CEKを暗号化鍵として、JWE初期化ベクトルおよび上記の追加認証データを用い、
AES_128_CBC_HMAC_SHA_256アルゴリズムで平文に対して認証付き暗号化を行います。
Appendix A.3の値を用いてこれを行う手順はAppendix Bに詳述されています。 得られた暗号文は次の通りです：
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6,
75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143,
112, 56, 102]
得られた認証タグの値は次の通りです：
[246, 17, 244, 190, 04, 95, 98, 03, 231, 00, 115, 157, 242, 203, 100,
191]
このJWE暗号文をBASE64URL(JWE Ciphertext)としてエンコードすると次の値になります：
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
このJWE認証タグをBASE64URL(JWE Authentication
Tag)としてエンコードすると次の値になります：
9hH0vgRfYgPnAHOd8stkvw
A.2.7. 完全な表現
最終表現を組み立てます：この結果のコンパクト・シリアライゼーションは文字列
BASE64URL(UTF8(JWE Protected Header)) || '.' ||
BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization
Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE
Authentication Tag) です。
Jones & Hildebrand Standards Track [Page 40]
RFC 7516 JSON Web Encryption (JWE) May 2015
本例の最終結果（表示のために改行あり）は次の通りです：
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.
UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-kFm
1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKxGHZ7Pc
HALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3YvkkysZIF
NPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPhcCdZ6XDP0_F8
rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPgwCp6X-nZZd9OHBv
-B3oWh2TbqmScqXMR4gp_A.
AxY8DCtDaGlsbGljb3RoZQ.
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.
9hH0vgRfYgPnAHOd8stkvw
A.2.8. 検証
この例は、鍵暗号化にRSAES-PKCS1-v1_5を、コンテンツ暗号化にAES_CBC_HMAC_SHA2を用いてJWEを作成する過程を示しています。
これらの結果は、これらのアルゴリズムを用いたJWE復号の実装を検証するために使用できます。RSAES-PKCS1-v1_5の計算にはランダム値が含まれるため、上記の暗号化結果は完全に再現可能ではないことに注意してください。
ただし、AES-CBCの計算は決定的であるため、これらの入力を用いて行われるすべての暗号化に対してJWE暗号化された暗号文の値は同一になります。
A.3. AES Key WrapとAES_128_CBC_HMAC_SHA_256を用いたJWEの例
この例では、平文 "Live long and prosper." を受信者へ暗号化します。鍵暗号化にはAES Key Wrapを、
コンテンツ暗号化にはAES_128_CBC_HMAC_SHA_256を使用します。平文の表現（JSON配列表記）は次の通りです：
[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32,
112, 114, 111, 115, 112, 101, 114, 46]
A.3.1. JOSE ヘッダー
以下の例のJWE保護ヘッダーは次のことを宣言しています：
o コンテンツ暗号鍵（CEK）はAES Key Wrapアルゴリズムを128ビット鍵で用いて受信者に暗号化され、JWE暗号化鍵が生成される。
o 平文に対して認証付き暗号化がAES_128_CBC_HMAC_SHA_256アルゴリズムで行われ、暗号文と認証タグが生成される。
{"alg":"A128KW","enc":"A128CBC-HS256"}
Jones & Hildebrand Standards Track [Page 41]
RFC 7516 JSON Web Encryption (JWE) May 2015
このJWE保護ヘッダーをBASE64URL(UTF8(JWE Protected
Header))としてエンコードすると次の値になります：
eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
A.3.2. コンテンツ暗号鍵（CEK）
256ビットのランダムなCEKを生成します。本例では、値は次の通りです：
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106,
206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156,
44, 207]
A.3.3. 鍵の暗号化
共有の対称鍵を用いてCEKをAES Key Wrapアルゴリズムで暗号化し、JWE暗号化鍵を生成します。本例では以下のJSON Web Key [JWK]形式の対称鍵を使用します：
{"kty":"oct",
"k":"GawgguFyGrWKav7AX4VKUg"
}
結果として得られるJWE暗号化鍵の値は次の通りです：
[232, 160, 123, 211, 183, 76, 245, 132, 200, 128, 123, 75, 190, 216,
22, 67, 201, 138, 193, 186, 9, 91, 122, 31, 246, 90, 28, 139, 57, 3,
76, 124, 193, 11, 98, 37, 173, 61, 104, 57]
このJWE暗号化鍵をBASE64URL(JWE Encrypted Key)としてエンコードすると次の値になります：
6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ
A.3.4. 初期化ベクトル
128ビットのランダムなJWE初期化ベクトルを生成します。 この
例では、値は次の通りです：
[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104,
101]
このJWE初期化ベクトルをBASE64URL(JWE
Initialization Vector)としてエンコードすると次の値になります：
AxY8DCtDaGlsbGljb3RoZQ
Jones & Hildebrand Standards Track [Page 42]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.3.5. 追加認証データ
追加認証データ（Additional Authenticated Data）暗号化パラメータを
ASCII(BASE64URL(UTF8(JWE Protected Header))). この値は次の通りです：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52,
83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66,
77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73,
110, 48]
A.3.6. コンテンツ暗号化
CEKを暗号化鍵として、JWE初期化ベクトルおよび上記の追加認証データを用い、
AES_128_CBC_HMAC_SHA_256アルゴリズムで平文に対して認証付き暗号化を行います。 この例の値を用いてこれを行う手順はAppendix Bに詳述されています。 得られた暗号文は次の通りです：
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6,
75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143,
112, 56, 102]
得られた認証タグの値は次の通りです：
[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38,
194, 85]
このJWE暗号文をBASE64URL(JWE Ciphertext)としてエンコードすると次の値になります：
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
このJWE認証タグをBASE64URL(JWE Authentication
Tag)としてエンコードすると次の値になります：
U0m_YmjN04DJvceFICbCVQ
A.3.7. 完全な表現
最終表現を組み立てます：この結果のコンパクト・シリアライゼーションは文字列
BASE64URL(UTF8(JWE Protected Header)) || '.' ||
BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization
Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE
Authentication Tag) です。
Jones & Hildebrand Standards Track [Page 43]
RFC 7516 JSON Web Encryption (JWE) May 2015
本例の最終結果（表示のために改行あり）は次の通りです：
eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.
6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ.
AxY8DCtDaGlsbGljb3RoZQ.
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.
U0m_YmjN04DJvceFICbCVQ
A.3.8. 検証
この例は、鍵暗号化にAES Key Wrapを、コンテンツ暗号化にAES GCMを用いてJWEを作成する過程を示しています。
これらの結果は、これらのアルゴリズムを用いたJWE復号の実装を検証するために使用できます。また、AES Key WrapとAES GCMの計算はどちらも決定的であるため、これらの入力を用いて行われるすべての暗号化に対して得られるJWE値は同一になります。計算が再現可能であるため、これらの結果はこれらのアルゴリズムのJWE暗号化実装を検証するためにも使用できます。
A.4. 一般的なJWE JSONシリアライゼーションを用いたJWEの例
この節には一般的なJWE JSONシリアライゼーション構文を用いた例が含まれます。この例は同一の平文を複数の受信者へ暗号化する機能を示しています。
この例には2つの受信者が存在します。最初の受信者に使用されるアルゴリズムと鍵はAppendix A.2で使用されたものと同じです。2番目の受信者に使用されるアルゴリズムと鍵はAppendix A.3で使用されたものと同じです。したがって、結果として得られるJWE暗号化鍵の値は同じであり、それらの計算はここでは繰り返されません。
平文、CEK、JWE初期化ベクトル、およびJWE保護ヘッダーはすべての受信者で共有されます（暗号文と認証タグも共有されるため、これが必須です）。
Jones & Hildebrand Standards Track [Page 44]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.4.1. JWE Per-Recipient Unprotected Headers
最初の受信者はCEKを暗号化するためにRSAES-PKCS1-v1_5アルゴリズムを使用します。
2番目の受信者はCEKを暗号化するためにAES Key Wrapを使用します。 どちらの鍵にも
Key ID 値が付与されています。 これらのアルゴリズムと鍵IDを表すために使用される
2つのJWE受信者ごとの非保護ヘッダー値は次のとおりです:
{"alg":"RSA1_5","kid":"2011-04-29"}
and
{"alg":"A128KW","kid":"7"}
A.4.2. JWE Protected Header
平文に対して認証付き暗号化がAES_128_CBC_HMAC_SHA_256アルゴリズムを用いて行われ、
共通のJWE暗号文およびJWE認証タグ値が生成されます。 これを表すJWE保護ヘッダー値は次の通りです：
{"enc":"A128CBC-HS256"}
このJWE保護ヘッダーをBASE64URL(UTF8(JWE Protected
Header))としてエンコードすると次の値になります：
eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
A.4.3. JWE Shared Unprotected Header
このJWEはJWKセットを参照するために"jku"ヘッダーパラメータを使用します。
これは次のJWE共有非保護ヘッダー値で表されます：
{"jku":"https://server.example.com/keys.jwks"}
A.4.4. Complete JOSE Header Values
JWE受信者ごとの非保護ヘッダー、JWE保護ヘッダー、およびJWE共有非保護ヘッダーの値を
組み合わせると、最初の受信者および2番目の受信者に使用されるJOSEヘッダー値はそれぞれ次のとおりです：
{"alg":"RSA1_5",
"kid":"2011-04-29",
"enc":"A128CBC-HS256",
"jku":"https://server.example.com/keys.jwks"}
Jones & Hildebrand Standards Track [Page 45]
RFC 7516 JSON Web Encryption (JWE) May 2015
and
{"alg":"A128KW",
"kid":"7",
"enc":"A128CBC-HS256",
"jku":"https://server.example.com/keys.jwks"}
A.4.5. Additional Authenticated Data
追加認証データ暗号化パラメータをASCII(BASE64URL(UTF8(JWE Protected Header)))とします。
この値は次の通りです：
[101, 121, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73,
52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48]
A.4.6. Content Encryption
CEKを暗号鍵として、JWE初期化ベクトルおよび上記の追加認証データを用いて
AES_128_CBC_HMAC_SHA_256アルゴリズムで平文に対して認証付き暗号化を行います。
Appendix A.3の値を用いてこれを行う手順は
Appendix Bに詳述されています。 得られた暗号文は次の通りです：
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6,
75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143,
112, 56, 102]
得られた認証タグの値は次の通りです：
[51, 63, 149, 60, 252, 148, 225, 25, 92, 185, 139, 245, 35, 2, 47,
207]
このJWE暗号文をBASE64URL(JWE Ciphertext)としてエンコードすると次の値になります：
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
このJWE認証タグをBASE64URL(JWE Authentication
Tag)としてエンコードすると次の値になります：
Mz-VPPyU4RlcuYv1IwIvzw
Jones & Hildebrand Standards Track [Page 46]
RFC 7516 JSON Web Encryption (JWE) May 2015
A.4.7. Complete JWE JSON Serialization Representation
これらの値の完全なJWE JSONシリアライゼーションは次のとおりです
（値内の改行は表示目的のみにあります）:
{
"protected":
"eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
"unprotected":
{"jku":"https://server.example.com/keys.jwks"},
"recipients":[
{"header":
{"alg":"RSA1_5","kid":"2011-04-29"},
"encrypted_key":
"UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-
kFm1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKx
GHZ7PcHALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3
YvkkysZIFNPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPh
cCdZ6XDP0_F8rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPg
wCp6X-nZZd9OHBv-B3oWh2TbqmScqXMR4gp_A"},
{"header":
{"alg":"A128KW","kid":"7"},
"encrypted_key":
"6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ"}],
"iv":
"AxY8DCtDaGlsbGljb3RoZQ",
"ciphertext":
"KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY",
"tag":
"Mz-VPPyU4RlcuYv1IwIvzw"
}
A.5. Example JWE Using Flattened JWE JSON Serialization
この節には、flattened JWE JSON シリアライゼーション構文を用いた例が含まれます。
この例は、平文を単一受信者に対して平坦化されたJSON構造で暗号化する機能を示しています。
この例の値は、Appendix A.4の前の例の2番目の受信者の
値と同じです。
Jones & Hildebrand Standards Track [Page 47]
RFC 7516 JSON Web Encryption (JWE) May 2015
The complete JWE JSON Serialization for these values is as follows
(with line breaks within values for display purposes only):
{
"protected":
"eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
"unprotected":
{"jku":"https://server.example.com/keys.jwks"},
"header":
{"alg":"A128KW","kid":"7"},
"encrypted_key":
"6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ",
"iv":
"AxY8DCtDaGlsbGljb3RoZQ",
"ciphertext":
"KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY",
"tag":
"Mz-VPPyU4RlcuYv1IwIvzw"
}
Appendix B. Example AES_128_CBC_HMAC_SHA_256 Computation
この例は、Appendix A.3の例の値を使用した
AES_128_CBC_HMAC_SHA_256 認証付き暗号化計算の手順を示します。JWAの
5.2節および5.2.3節で
このアルゴリズムが定義されているように、AES_CBC_HMAC_SHA2ファミリは
暗号化を行うためにパディング付きのブロック暗号モード（AES-CBC）を使用し、
整合性計算のためにHMAC SHA-2関数（ここではHMAC SHA-256）を使用して実装されます。
B.1. Extract MAC_KEY and ENC_KEY from Key
この例で使用される256ビットのAES_128_CBC_HMAC_SHA_256鍵K（JSON配列表記）は次の通りです:
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106,
206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156,
44, 207]
この鍵の最初の128ビットをHMAC SHA-256鍵であるMAC_KEYとして使用します。
それは次の通りです：
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106,
206]
Jones & Hildebrand Standards Track [Page 48]
RFC 7516 JSON Web Encryption (JWE) May 2015
この鍵の後半の128ビットをAES-CBC鍵であるENC_KEYとして使用します。それは次の通りです：
[107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44,
207]
MAC鍵は入力鍵Kの先頭に位置し、これは識別子"AES_128_CBC_HMAC_SHA_256"や
"A128CBC-HS256"におけるアルゴリズム名の順序とは逆の順序であることに注意してください。
B.2. Encrypt Plaintext to Create Ciphertext
上記のENC_KEYを用いてPKCS #7パディングを施したAES CBCモードで平文を暗号化します。
この例の平文は次の通りです：
[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32,
112, 114, 111, 115, 112, 101, 114, 46]
暗号化の結果は次の通りで、これが暗号文出力です：
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6,
75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143,
112, 56, 102]
B.3. 64-Bit Big-Endian Representation of AAD Length
この例の追加認証データ（AAD）は次の通りです：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52,
83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66,
77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73,
110, 48]
このAADは51バイト長、すなわち408ビット長です。AADのビット数をビッグエンディアンの
64ビット符号なし整数として表したオクテット列ALは次の通りです：
[0, 0, 0, 0, 0, 0, 1, 152]
B.4. Initialization Vector Value
この例で使用される初期化ベクトルの値は次の通りです：
[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104,
101]
Jones & Hildebrand Standards Track [Page 49]
RFC 7516 JSON Web Encryption (JWE) May 2015
B.5. Create Input to HMAC Computation
AAD、初期化ベクトル、暗号文、AL値を連結してHMAC計算への入力を作成します。
この連結の結果は次の通りです：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52,
83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66,
77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73,
110, 48, 3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111,
116, 104, 101, 40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24,
152, 230, 6, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215,
104, 143, 112, 56, 102, 0, 0, 0, 0, 0, 0, 1, 152]
B.6. Compute HMAC Value
上記の連結値のHMAC SHA-256を計算します。結果Mは次の通りです：
[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38,
194, 85, 9, 84, 229, 201, 219, 135, 44, 252, 145, 102, 179, 140, 105,
86, 229, 116]
B.7. Truncate HMAC Value to Create Authentication Tag
HMAC出力Mの最初の半分（128ビット）を認証タグ出力Tとして使用します。
この切り詰めた値は次の通りです：
[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38,
194, 85]
Acknowledgements
JSONコンテンツの暗号化に関する解法は "JSON Simple Encryption"
[JSE] および
"JavaScript Message Security Format" [JSMS] に
よっても検討され、本書書類に大きな影響を与えました。 本書はXML Encryption 1.1
[W3C.REC-xmlenc-core1-20130411] および
RFC 5652 [RFC5652] の関連概念を可能な限り明示的に再利用しつつ、
シンプルでコンパクトなJSONベースのデータ構造を利用することを試みています。
本仕様の内容を形成する議論に貢献した John Bradley、Eric Rescorla、Nat
Sakimura に特別な謝意を表します。また、[JSMS]からの文
章再利用を許可してくれた Eric Rescorla および Joe Hildebrand に感謝します。さらに
本仕様の多くの草案を共著した Eric Rescorla にも感謝します。
また、本仕様の例を検証してくれた Axel Nennker、Emmanuel Raviart、Brian Campbell、
Edmund Jay に感謝します。
Jones & Hildebrand Standards Track [Page 50]
RFC 7516 JSON Web Encryption (JWE) May 2015
This specification is the work of the JOSE working group, which
includes dozens of active and dedicated participants. In particular,
the following individuals contributed ideas, feedback, and wording
that influenced this specification:
Richard Barnes, John Bradley, Brian Campbell, Alissa Cooper, Breno de
Medeiros, Stephen Farrell, Dick Hardt, Jeff Hodges, Russ Housley,
Edmund Jay, Scott Kelly, Stephen Kent, Barry Leiba, James Manger,
Matt Miller, Kathleen Moriarty, Tony Nadalin, Hideki Nara, Axel
Nennker, Ray Polk, Emmanuel Raviart, Eric Rescorla, Pete Resnick, Nat
Sakimura, Jim Schaad, Hannes Tschofenig, and Sean Turner.
Jim Schaad and Karen O'Donoghue chaired the JOSE working group and
Sean Turner, Stephen Farrell, and Kathleen Moriarty served as
Security Area Directors during the creation of this specification.
Authors' Addresses
Michael B. Jones
Microsoft
EMail: mbj@microsoft.com
URI: http://self-issued.info/
Joe Hildebrand
Cisco Systems, Inc.
EMail: jhildebr@cisco.com
Jones & Hildebrand Standards Track [Page 51]