[RFC ホーム] [テキスト|PDF|HTML] [トラッカー] [IPR] [正誤表] [情報ページ]
標準化提案
更新: 9864
正誤表あり
インターネット技術タスクフォース (IETF) M. Jones
Request for Comments: 7518 Microsoft
カテゴリ: 標準化過程 2015年5月
ISSN: 2070-1721
JSON Web アルゴリズム (JWA)
概要
この仕様は、JSON Web Signature (JWS)、JSON Web Encryption
(JWE)、および JSON Web Key (JWK) 仕様で使用される暗号アルゴリズムと識別子を
登録するものである。また、これらの識別子のための複数の
IANA レジストリを定義する。
このメモの位置付け
この文書は、インターネット標準化過程の文書である。
この文書は、インターネット技術タスクフォース
(IETF) の成果物である。これは IETF コミュニティの合意を
表している。公開レビューを受け、インターネット技術運営グループ
(IESG) によって公開が承認されている。インターネット標準に関する詳細情報は、
RFC 5741 のセクション 2で入手できる。
この文書の現在の状態、正誤表、
およびフィードバックの提供方法に関する情報は、
http://www.rfc-editor.org/info/rfc7518で入手できる。
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 標準化過程 [2ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
目次
1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. 表記規則 . . . . . . . . . . . . . . . . . . . . . . . 4
2. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. デジタル署名および MAC のための暗号アルゴリズム . . . . . . 6
3.1. JWS の "alg" (アルゴリズム) ヘッダーパラメーター値 . . . 6
3.2. SHA-2 関数を使用する HMAC . . . . . . . . . . . . . . . . 7
3.3. RSASSA-PKCS1-v1_5 によるデジタル署名 . . . . . . . . . 8
3.4. ECDSA によるデジタル署名 . . . . . . . . . . . . . . . 9
3.5. RSASSA-PSS によるデジタル署名 . . . . . . . . . . . . 10
3.6. アルゴリズム "none" の使用 . . . . . . . . . . . . . . 11
4. 鍵管理のための暗号アルゴリズム . . . . . . . . . . . . . . 11
4.1. JWE の "alg" (アルゴリズム) ヘッダーパラメーター値 . . 12
4.2. RSAES-PKCS1-v1_5 による鍵暗号化 . . . . . . . . . . . 13
4.3. RSAES OAEP による鍵暗号化 . . . . . . . . . . . . . . 14
4.4. AES Key Wrap による鍵ラッピング . . . . . . . . . . . 14
4.5. 共有対称鍵による直接暗号化 . . . . . . . . . . . . . . 15
4.6. 楕円曲線 Diffie-Hellman Ephemeral Static
(ECDH-ES) による鍵合意 . . . . . . . . . . . . . . . . . . . 15
4.6.1. ECDH 鍵合意で使用されるヘッダーパラメーター . . . 16
4.6.1.1. "epk" (一時公開鍵) ヘッダーパラメーター . . . 16
4.6.1.2. "apu" (Agreement PartyUInfo) ヘッダーパラメーター . . 17
4.6.1.3. "apv" (Agreement PartyVInfo) ヘッダーパラメーター . . 17
4.6.2. ECDH 鍵合意のための鍵導出 . . . . . . . . . . . . 17
4.7. AES GCM による鍵暗号化 . . . . . . . . . . . . . . . . 18
4.7.1. AES GCM 鍵暗号化で使用されるヘッダーパラメーター . 19
4.7.1.1. "iv" (初期化ベクトル) ヘッダーパラメーター . . 19
4.7.1.2. "tag" (認証タグ) ヘッダーパラメーター . . . . 19
4.8. PBES2 による鍵暗号化 . . . . . . . . . . . . . . . . . 20
4.8.1. PBES2 鍵暗号化で使用されるヘッダーパラメーター . . 20
4.8.1.1. "p2s" (PBES2 ソルト入力) ヘッダーパラメーター . 21
4.8.1.2. "p2c" (PBES2 回数) ヘッダーパラメーター . . . 21
5. コンテンツ暗号化のための暗号アルゴリズム . . . . . . . . 21
5.1. JWE の "enc" (暗号化アルゴリズム) ヘッダーパラメーター値
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. AES_CBC_HMAC_SHA2 アルゴリズム . . . . . . . . . . . . 22
5.2.1. AES_CBC_HMAC_SHA2 の定義で使用する規則 . . . . . 23
5.2.2. 汎用 AES_CBC_HMAC_SHA2 アルゴリズム . . . . . . . 23
5.2.2.1. AES_CBC_HMAC_SHA2 暗号化 . . . . . . . . . . . 23
5.2.2.2. AES_CBC_HMAC_SHA2 復号 . . . . . . . . . . . . 25
5.2.3. AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . 25
5.2.4. AES_192_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . 26
5.2.5. AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . . 26
5.2.6. AES_CBC_HMAC_SHA2 によるコンテンツ暗号化 . . . . . 26
5.3. AES GCM によるコンテンツ暗号化 . . . . . . . . . . . . 27
6. 鍵のための暗号アルゴリズム . . . . . . . . . . . . . . . 27
6.1. "kty" (鍵タイプ) パラメーター値 . . . . . . . . . . . 28
Jones 標準化過程 [2ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
6.2. 楕円曲線鍵のパラメーター . . . . . . . . . . . . . . . 28
6.2.1. 楕円曲線公開鍵のパラメーター . . . . . . . . . . 28
6.2.1.1. "crv" (曲線) パラメーター . . . . . . . . . . . 28
6.2.1.2. "x" (X 座標) パラメーター . . . . . . . . . . 29
6.2.1.3. "y" (Y 座標) パラメーター . . . . . . . . . . 29
6.2.2. 楕円曲線秘密鍵のパラメーター . . . . . . . . . . 29
6.2.2.1. "d" (ECC 秘密鍵) パラメーター . . . . . . . . 29
6.3. RSA 鍵のパラメーター . . . . . . . . . . . . . . . . . 30
6.3.1. RSA 公開鍵のパラメーター . . . . . . . . . . . . 30
6.3.1.1. "n" (法) パラメーター . . . . . . . . . . . . . 30
6.3.1.2. "e" (指数) パラメーター . . . . . . . . . . . 30
6.3.2. RSA 秘密鍵のパラメーター . . . . . . . . . . . . 30
6.3.2.1. "d" (秘密指数) パラメーター . . . . . . . . . 30
6.3.2.2. "p" (第1素因数) パラメーター . . . . . . . . 31
6.3.2.3. "q" (第2素因数) パラメーター . . . . . . . . 31
6.3.2.4. "dp" (第1因数 CRT 指数) パラメーター . . . . 31
6.3.2.5. "dq" (第2因数 CRT 指数) パラメーター . . . . 31
6.3.2.6. "qi" (第1 CRT 係数) パラメーター . . . . . . 31
6.3.2.7. "oth" (その他の素数情報) パラメーター . . . . 31
6.4. 対称鍵のパラメーター . . . . . . . . . . . . . . . . . 32
6.4.1. "k" (鍵値) パラメーター . . . . . . . . . . . . . 32
7. IANA に関する考慮事項 . . . . . . . . . . . . . . . . . . . 32
7.1. JSON Web 署名および暗号化アルゴリズムレジストリ . . . 33
7.1.1. 登録テンプレート . . . . . . . . . . . . . . . . . 34
7.1.2. 初期レジストリ内容 . . . . . . . . . . . . . . . . 35
7.2. ヘッダーパラメーター名の登録 . . . . . . . . . . . . 42
7.2.1. レジストリ内容 . . . . . . . . . . . . . . . . . . 42
7.3. JSON Web 暗号化圧縮アルゴリズムレジストリ . . . . . . 43
7.3.1. 登録テンプレート . . . . . . . . . . . . . . . . . 43
7.3.2. 初期レジストリ内容 . . . . . . . . . . . . . . . . 44
7.4. JSON Web 鍵タイプレジストリ . . . . . . . . . . . . . 44
7.4.1. 登録テンプレート . . . . . . . . . . . . . . . . . 44
7.4.2. 初期レジストリ内容 . . . . . . . . . . . . . . . . 45
7.5. JSON Web 鍵パラメーターの登録 . . . . . . . . . . . 45
7.5.1. レジストリ内容 . . . . . . . . . . . . . . . . . . 46
7.6. JSON Web 鍵楕円曲線レジストリ . . . . . . . . . . . 48
7.6.1. 登録テンプレート . . . . . . . . . . . . . . . . . 48
7.6.2. 初期レジストリ内容 . . . . . . . . . . . . . . . . 49
8. セキュリティに関する考慮事項 . . . . . . . . . . . . . . 49
8.1. 暗号アジリティ . . . . . . . . . . . . . . . . . . . . 50
8.2. 鍵の有効期間 . . . . . . . . . . . . . . . . . . . . . 50
8.3. RSAES-PKCS1-v1_5 のセキュリティに関する考慮事項 . . 50
8.4. AES GCM のセキュリティに関する考慮事項 . . . . . . . 50
8.5. セキュリティ保護されていない JWS の考慮事項 . . . . 51
8.6. サービス拒否攻撃 . . . . . . . . . . . . . . . . . . . 51
8.7. 鍵暗号化時の鍵素材の再利用 . . . . . . . . . . . . . 51
8.8. パスワードに関する考慮事項 . . . . . . . . . . . . . 52
8.9. 鍵エントロピーとランダム値 . . . . . . . . . . . . . 52
Jones 標準化過程 [3ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
8.10. デジタル署名と MAC の違い . . . . . . . . . . . . . 52
8.11. 強度が一致するアルゴリズムの使用 . . . . . . . . . 53
8.12. 適応的選択暗号文攻撃 . . . . . . . . . . . . . . . . 53
8.13. タイミング攻撃 . . . . . . . . . . . . . . . . . . . 53
8.14. RSA 秘密鍵の表現とブラインディング . . . . . . . . 53
9. 国際化に関する考慮事項 . . . . . . . . . . . . . . . . . 53
10. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . 53
10.1. 規範的参考文献 . . . . . . . . . . . . . . . . . . . . 53
10.2. 参考情報 . . . . . . . . . . . . . . . . . . . . . . . 56
付録 A. アルゴリズム識別子相互参照 . . . . . . . . . . . . 59
A.1. デジタル署名/MAC アルゴリズム識別子相互
参照 . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A.2. 鍵管理アルゴリズム識別子相互参照 . . . . . . . . . 61
A.3. コンテンツ暗号化アルゴリズム識別子相互参照 . . . . . . . 62
付録 B. AES_CBC_HMAC_SHA2 アルゴリズムのテストケース . 62
B.1. AES_128_CBC_HMAC_SHA_256 のテストケース . . . . . . . 63
B.2. AES_192_CBC_HMAC_SHA_384 のテストケース . . . . . . . 64
B.3. AES_256_CBC_HMAC_SHA_512 のテストケース . . . . . . . 65
付録 C. ECDH-ES 鍵合意計算の例 . . . . . . . . . . . . . 66
謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . . 69
1. はじめに
この仕様は、JSON Web Signature (JWS) [JWS]、JSON Web
Encryption (JWE) [JWE]、および JSON Web Key (JWK) [JWK] 仕様で
使用される暗号アルゴリズムと識別子を登録する。
また、これらの識別子のための複数の IANA レジストリを定義する。これらの
仕様はすべて JSON ベースの [RFC7159] データ構造を利用する。この
仕様は、これらのアルゴリズムと鍵タイプに固有の意味論および操作についても
説明する。
アルゴリズムと識別子を JWS、JWE、JWK 仕様ではなくここで登録することは、
必須、推奨、任意、非推奨とされるアルゴリズムの集合が
時間の経過とともに変更されても、これらの仕様を変更せずに
維持できるようにすることを意図している。これにより、この文書を変更せずに
JWS、JWE、JWK 仕様を変更することもできる。
この仕様で定義される名前が短いのは、結果として得られる表現を
コンパクトにすることが主要な目標だからである。
1.1. 表記規則
この文書におけるキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、
"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、および
"OPTIONAL" は、
「RFC で要求レベルを示すために使用するキーワード」[RFC2119] に記載されているとおりに解釈する。
Jones 標準化過程 [4ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
この解釈は、これらの用語が
すべて大文字で記述されている場合にのみ適用すべきである。
BASE64URL(OCTETS) は、[JWS] のセクション 2 に従った
OCTETS の base64url エンコーディングを表す。
UTF8(STRING) は STRING の UTF-8 [RFC3629] 表現のオクテットを表す。
ここで STRING は、0 個以上の Unicode
[UNICODE] 文字のシーケンスである。
ASCII(STRING) は STRING の ASCII [RFC20] 表現のオクテットを表す。
ここで STRING は、0 個以上の ASCII
文字のシーケンスである。
2 つの値 A と B の連結は A || B と表記する。
2. 用語
"JSON Web Signature (JWS)"、"Base64url Encoding"、"Header
Parameter"、"JOSE Header"、"JWS Payload"、"JWS Protected Header"、
"JWS Signature"、"JWS Signing Input"、および "Unsecured JWS" という用語は、
JWS 仕様 [JWS] で定義される。
"JSON Web Encryption (JWE)"、"Additional Authenticated Data
(AAD)"、"Authentication Tag"、"Content Encryption Key (CEK)"、"Direct
Encryption"、"Direct Key Agreement"、"JWE Authentication Tag"、"JWE
Ciphertext"、"JWE Encrypted Key"、"JWE Initialization Vector"、"JWE
Protected Header"、"Key Agreement with Key Wrapping"、"Key
Encryption"、"Key Management Mode"、および "Key Wrapping" という用語は、
JWE 仕様 [JWE] で定義される。
"JSON Web Key (JWK)" および "JWK Set" という用語は、JWK
仕様 [JWK] で定義される。
"Ciphertext"、"Digital Signature"、"Initialization Vector"、
"Message Authentication Code (MAC)"、および "Plaintext" という用語は、
「インターネットセキュリティ用語集、バージョン 2」[RFC4949] で定義される。
この仕様では、次の用語を定義する。
Base64urlUInt
正またはゼロの整数値を、その値の符号なしビッグエンディアン
表現をオクテットシーケンスとしたものに対する
base64url エンコーディングとして表現したもの。オクテットシーケンスは、
値を表現するために必要な最小数のオクテットを使用しなければならない。
ゼロは BASE64URL(値がゼロの単一
オクテット)、すなわち "AA" として表現される。
Jones 標準化過程 [5ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
3. デジタル署名および MAC のための暗号アルゴリズム
JWS は、JWS Protected Header と JWS Payload の内容にデジタル署名するか、
または MAC を作成するために暗号アルゴリズムを使用する。
3.1. JWS の "alg" (アルゴリズム) ヘッダーパラメーター値
次の表は、この仕様で JWS 用として定義する "alg" (アルゴリズム)
ヘッダーパラメーター値の集合であり、それぞれについて
後続のセクションでより詳細に説明する。
+--------------+-------------------------------+--------------------+
| "alg" パラメーター | デジタル署名または MAC | 実装要件 |
| 値 | アルゴリズム | |
+--------------+-------------------------------+--------------------+
| HS256 | SHA-256 を使用する HMAC | 必須 |
| HS384 | SHA-384 を使用する HMAC | 任意 |
| HS512 | SHA-512 を使用する HMAC | 任意 |
| RS256 | SHA-256 を使用する | 推奨 |
| | RSASSA-PKCS1-v1_5 | |
| RS384 | SHA-384 を使用する | 任意 |
| | RSASSA-PKCS1-v1_5 | |
| RS512 | SHA-512 を使用する | 任意 |
| | RSASSA-PKCS1-v1_5 | |
| ES256 | P-256 と SHA-256 を使用する ECDSA | 推奨+ |
| ES384 | P-384 と SHA-384 を使用する ECDSA | 任意 |
| ES512 | P-521 と SHA-512 を使用する ECDSA | 任意 |
| PS256 | SHA-256 および | 任意 |
| | SHA-256 を使用する MGF1 による RSASSA-PSS | |
| PS384 | SHA-384 および | 任意 |
| | SHA-384 を使用する MGF1 による RSASSA-PSS | |
| PS512 | SHA-512 および | 任意 |
| | SHA-512 を使用する MGF1 による RSASSA-PSS | |
| none | デジタル署名または MAC を | 任意 |
| | 実行しない | |
+--------------+-------------------------------+--------------------+
実装要件列での "+" の使用は、
将来の仕様バージョンで要件の強度が引き上げられる可能性が高いことを
示す。
この仕様で定義する JWS デジタル
署名および MAC の "alg" (アルゴリズム) 値と、他の標準や
ソフトウェアパッケージで使用される同等の識別子との相互参照表については、
付録 A.1 を参照すること。
Jones 標準化過程 [6ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
3.2. SHA-2 関数を使用する HMAC
ハッシュベースのメッセージ認証コード (HMAC) により、
秘密値と暗号学的ハッシュ関数を使用して MAC を生成できる。
これは、MAC を生成した者が
MAC 鍵を所持していたことを示すために使用できる。HMAC の実装および
検証アルゴリズムは RFC 2104 [RFC2104] で規定されている。
このアルゴリズムでは、ハッシュ出力と同じサイズ
(たとえば "HS256" の場合は 256 ビット) 以上の鍵を使用しなければならない。
(この要件は NIST SP 800-117 [NIST.800-107] の
セクション 5.3.4 (HMAC
鍵のセキュリティ効果) に基づく。同文書では、実効セキュリティ強度は
鍵のセキュリティ強度と内部ハッシュ値のサイズの 2 倍の
小さい方であると述べている。)
HMAC SHA-256 MAC は、RFC 2104 に従って生成され、SHA-256 を
ハッシュアルゴリズム "H" として、JWS Signing Input を "text" 値として、
共有鍵を使用する。HMAC 出力値が JWS
Signature となる。
次の "alg" (アルゴリズム) ヘッダーパラメーター値は、
JWS Signature が対応するアルゴリズムを使用して計算された
HMAC 値であることを示すために使用される。
+-------------------+--------------------+
| "alg" パラメーター値 | MAC アルゴリズム |
+-------------------+--------------------+
| HS256 | SHA-256 を使用する HMAC |
| HS384 | SHA-384 を使用する HMAC |
| HS512 | SHA-512 を使用する HMAC |
+-------------------+--------------------+
JWS の HMAC SHA-256 MAC は、RFC 2104 に従って HMAC
値を計算することで検証される。SHA-256 をハッシュアルゴリズム "H" として、
受信した JWS Signing Input を "text" 値として、共有鍵を使用する。
その後、計算された HMAC 値を、受信したエンコード済み JWS Signature 値を
base64url デコードした結果と比較する。タイミング攻撃を防ぐため、
計算された HMAC 値と JWS Signature 値との比較は
定数時間で実行しなければならない。
代わりに、計算された HMAC 値を base64url エンコードし、
受信したエンコード済み JWS Signature 値と比較することもできる
(これも定数時間で行う)。この比較は、エンコードされていない値を
比較する場合と同じ結果を生成するためである。いずれの場合も、値が一致すれば、
HMAC は検証されたことになる。
Jones 標準化過程 [7ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
HMAC SHA-384 および HMAC
SHA-512 アルゴリズムによるコンテンツの保護と検証は、HMAC
SHA-256 の手順と同一であり、対応するハッシュアルゴリズムを
使用し、対応してより大きな最小鍵サイズと結果値を使用するだけである。
HMAC SHA-384 ではそれぞれ 384 ビット、HMAC SHA-512 ではそれぞれ 512 ビットである。
このアルゴリズムを使用する例は [JWS] の 付録 A.1 に示されている。
3.3. RSASSA-PKCS1-v1_5 によるデジタル署名
このセクションでは、RFC 3447 のセクション 8.2 [RFC3447]
(一般に PKCS #1 として知られる) で定義された RSASSA-PKCS1-v1_5 デジタル
署名アルゴリズムを、SHA-2 [SHS] ハッシュ関数とともに使用する方法を定義する。
これらのアルゴリズムでは、2048 ビット以上のサイズの鍵を使用しなければならない。
RSASSA-PKCS1-v1_5 SHA-256 デジタル署名は、次のように生成する。
目的の秘密鍵を使用し、RSASSA-PKCS1-v1_5-SIGN と SHA-256 ハッシュ関数によって
JWS Signing Input のデジタル署名を生成する。
これが JWS Signature 値となる。
次の "alg" (アルゴリズム) ヘッダーパラメーター値は、
JWS Signature が対応するアルゴリズムを使用して計算された
デジタル署名値であることを示すために使用される。
+-------------------+---------------------------------+
| "alg" パラメーター値 | デジタル署名アルゴリズム |
+-------------------+---------------------------------+
| RS256 | SHA-256 を使用する RSASSA-PKCS1-v1_5 |
| RS384 | SHA-384 を使用する RSASSA-PKCS1-v1_5 |
| RS512 | SHA-512 を使用する RSASSA-PKCS1-v1_5 |
+-------------------+---------------------------------+
JWS の RSASSA-PKCS1-v1_5 SHA-256 デジタル署名は、
次のように検証する。JWS Signing Input、JWS
Signature、および署名者が使用した秘密鍵に対応する公開鍵を、
SHA-256 をハッシュ関数として使用する
RSASSA-PKCS1-v1_5-VERIFY アルゴリズムに渡す。
RSASSA-PKCS1-v1_5 SHA-384 および RSASSA-
PKCS1-v1_5 SHA-512 アルゴリズムによる署名と検証は、
RSASSA-PKCS1-v1_5 SHA-256 の手順と同一であり、
SHA-256 の代わりに対応するハッシュアルゴリズムを使用するだけである。
このアルゴリズムを使用する例は [JWS] の 付録 A.2 に示されている。
Jones 標準化過程 [8ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
3.4. ECDSA によるデジタル署名
楕円曲線デジタル署名アルゴリズム (ECDSA) [DSS] は、
RSA 暗号と同等のセキュリティを、より短い鍵サイズで、
多くの操作においてより高速な処理速度で提供できる
楕円曲線暗号の使用を可能にする。これは、
同等の強度を持つ RSA デジタル署名と比べて、ECDSA デジタル署名の
長さが大幅に短くなることを意味する。
この仕様では、P-256 曲線と SHA-256 暗号学的ハッシュ関数を使用する ECDSA、
P-384 曲線と SHA-384 ハッシュ関数を使用する ECDSA、
および P-521 曲線と SHA-512 ハッシュ関数を使用する ECDSA を定義する。
P-256、P-384、P-521 曲線は
[DSS] で定義されている。
ECDSA P-256 SHA-256 デジタル署名は、次のように生成する。
1. 目的の秘密鍵を使用して、ECDSA
P-256 SHA-256 により JWS Signing Input のデジタル署名を生成する。出力は
ペア (R, S) となり、R と S は 256 ビットの符号なし整数である。
2. R と S をビッグエンディアン順のオクテットシーケンスに変換し、
各配列の長さを 32 オクテットとする。値に含まれる先頭のゼロ
オクテットを省略するために、オクテットシーケンス表現を
短縮してはならない。
3. 2 つのオクテットシーケンスを R、次に S の順で連結する。
(多くの ECDSA 実装では、この連結を
出力として直接生成することに注意。)
4. 結果として得られる 64 オクテットのシーケンスが JWS Signature 値となる。
次の "alg" (アルゴリズム) ヘッダーパラメーター値は、
JWS Signature が対応するアルゴリズムを使用して計算された
デジタル署名値であることを示すために使用される。
+-------------------+-------------------------------+
| "alg" パラメーター値 | デジタル署名アルゴリズム |
+-------------------+-------------------------------+
| ES256 | P-256 と SHA-256 を使用する ECDSA |
| ES384 | P-384 と SHA-384 を使用する ECDSA |
| ES512 | P-521 と SHA-512 を使用する ECDSA |
+-------------------+-------------------------------+
Jones 標準化過程 [9ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
JWS の ECDSA P-256 SHA-256 デジタル署名は、
次のように検証する。
1. JWS Signature 値は 64 オクテットのシーケンスでなければならない。
64 オクテットのシーケンスでない場合、検証は失敗する。
2. 64 オクテットのシーケンスを 2 つの 32 オクテットのシーケンスに分割する。
最初のオクテットシーケンスは R を表し、2 番目は S を表す。値 R
と S は、SEC1 [SEC1] の セクション 2.3.7 で定義されている Integer-to-
OctetString Conversion を使用してオクテットシーケンスとして表現する
(ビッグエンディアンのオクテット順)。
3. JWS Signing Input、R、S、および公開鍵 (x, y) を
ECDSA P-256 SHA-256 検証器に渡す。
ECDSA P-384 SHA-384 および ECDSA P-521
SHA-512 アルゴリズムによる署名と検証は、
ECDSA P-256 SHA-256 の手順と同一であり、対応するハッシュアルゴリズムを
使用し、対応してより大きな結果値を使用するだけである。ECDSA P-384 SHA-384 では、
R と S はそれぞれ 384 ビットとなり、96 オクテットのシーケンスになる。
ECDSA P-521 SHA-512 では、R と S はそれぞれ 521 ビットとなり、
132 オクテットのシーケンスになる。(R と S を
オクテットシーケンスとして表現するために使用される SEC1 [SEC1] の
セクション 2.3.7 で定義された Integer-to-OctetString Conversion は、
必要に応じてサイズを 8 ビットの倍数に切り上げるため、
上位にゼロ値のパディングビットを追加する。そのため、各 521 ビットの
整数は 66 オクテット、528 ビットを使用して表現される。)
これらのアルゴリズムを使用する例は [JWS] の
付録 A.3 および A.4 に示されている。
3.5. RSASSA-PSS によるデジタル署名
このセクションでは、RFC 3447 のセクション 8.1 [RFC3447] で定義された
RSASSA-PSS デジタル署名アルゴリズムを、
MGF1 マスク生成関数および SHA-2 ハッシュ関数とともに使用する方法を定義する。
RSASSA-PSS ハッシュ関数と MGF1 ハッシュ関数の両方で、
常に同じハッシュ関数を使用する。ソルト値のサイズは
ハッシュ関数の出力サイズと同じである。その他すべてのアルゴリズムパラメーターは、
RFC 3447 の付録 A.2.3 で指定された既定値を使用する。
このアルゴリズムでは、2048 ビット以上のサイズの鍵を使用しなければならない。
RSASSA-PSS SHA-256 デジタル署名は、次のように生成する。
目的の秘密鍵を使用し、RSASSA-
PSS-SIGN、SHA-256 ハッシュ関数、および SHA-256 を使用する MGF1 マスク生成
関数によって JWS Signing Input のデジタル署名を生成する。これが JWS
Signature 値となる。
Jones 標準化過程 [10ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
次の "alg" (アルゴリズム) ヘッダーパラメーター値は、
JWS Signature が対応するアルゴリズムを使用して計算された
デジタル署名値であることを示すために使用される。
+-------------------+-----------------------------------------------+
| "alg" パラメーター値 | デジタル署名アルゴリズム |
+-------------------+-----------------------------------------------+
| PS256 | SHA-256 および SHA-256 を使用する MGF1 による |
| | RSASSA-PSS |
| PS384 | SHA-384 および SHA-384 を使用する MGF1 による |
| | RSASSA-PSS |
| PS512 | SHA-512 および SHA-512 を使用する MGF1 による |
| | RSASSA-PSS |
+-------------------+-----------------------------------------------+
JWS の RSASSA-PSS SHA-256 デジタル署名は、
次のように検証する。JWS Signing Input、JWS Signature、および
署名者が使用した秘密鍵に対応する公開鍵を、
SHA-256 をハッシュ関数として使用し、
SHA-256 を使用する MGF1 をマスク生成関数として使用する
RSASSA-PSS-VERIFY アルゴリズムに渡す。
RSASSA-PSS SHA-384 および RSASSA-PSS
SHA-512 アルゴリズムによる署名と検証は、
RSASSA-PSS SHA-256 の手順と同一であり、
両方の役割で代替ハッシュアルゴリズムを使用するだけである。
3.6. アルゴリズム "none" の使用
完全性保護を提供しない JWS を作成してもよい。
このような JWS は Unsecured JWS と呼ばれる。Unsecured JWS は
"alg" 値 "none" を使用し、他の JWS と同じ形式であるが、
JWS Signature 値として空のオクテットシーケンスを使用しなければならない。
受信者は、JWS Signature 値が空の
オクテットシーケンスであることを検証しなければならない。
Unsecured JWS をサポートする実装は、
特定のオブジェクトが完全性保護されていなくても許容可能であることを
アプリケーションが指定しない限り、そのようなオブジェクトを有効として
受け入れてはならない。実装は既定で Unsecured JWS を
受け入れてはならない。ダウングレード攻撃を軽減するため、
アプリケーションは Unsecured JWS の受け入れをグローバルレベルで
通知してはならず、オブジェクトごとに受け入れを
通知すべきである。このアルゴリズムの使用に関連するセキュリティ上の
考慮事項については、セクション 8.5 を参照すること。
4. 鍵管理のための暗号アルゴリズム
JWE は、Content
Encryption Key (CEK) を暗号化または決定するために暗号アルゴリズムを使用する。
Jones 標準化過程 [11ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
4.1. JWE の "alg" (アルゴリズム) ヘッダーパラメーター値
次の表は、この仕様で JWE 用として定義する
"alg" (アルゴリズム) ヘッダーパラメーター値の集合である。
これらのアルゴリズムは CEK を暗号化して JWE
Encrypted Key を生成するか、または鍵合意によって CEK を合意するために使用される。
+--------------------+--------------------+--------+----------------+
| "alg" パラメーター値 | 鍵管理 | 追加 | 実装 |
| | アルゴリズム | ヘッダー | 要件 |
| | | パラメーター | |
+--------------------+--------------------+--------+----------------+
| RSA1_5 | RSAES-PKCS1-v1_5 | (なし) | 推奨- |
| RSA-OAEP | 既定パラメーターを | (なし) | 推奨+ |
| | 使用する RSAES OAEP | | |
| RSA-OAEP-256 | SHA-256 と | (なし) | 任意 |
| | SHA-256 を使用する MGF1 | | |
| | を使用する RSAES OAEP | | |
| A128KW | 既定の初期値と | (なし) | 推奨 |
| | 128 ビット鍵を使用する | | |
| | AES Key Wrap | | |
| A192KW | 既定の初期値と | (なし) | 任意 |
| | 192 ビット鍵を使用する | | |
| | AES Key Wrap | | |
| A256KW | 既定の初期値と | (なし) | 推奨 |
| | 256 ビット鍵を使用する | | |
| | AES Key Wrap | | |
| dir | 共有対称鍵を | (なし) | 推奨 |
| | CEK として直接 | | |
| | 使用 | | |
| ECDH-ES | Elliptic Curve | "epk", | 推奨+ |
| | Diffie-Hellman | "apu", | |
| | Ephemeral Static | "apv" | |
| | 鍵合意 | | |
| | Concat KDF を使用 | | |
| ECDH-ES+A128KW | Concat KDF を使用する | "epk", | 推奨 |
| | ECDH-ES と、 | "apu", | |
| | "A128KW" でラップした | "apv" | |
| | CEK | | |
| ECDH-ES+A192KW | Concat KDF を使用する | "epk", | 任意 |
| | ECDH-ES と、 | "apu", | |
| | "A192KW" でラップした | "apv" | |
| | CEK | | |
Jones 標準化過程 [12ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
| ECDH-ES+A256KW | Concat KDF を使用する | "epk", | 推奨 |
| | ECDH-ES と、 | "apu", | |
| | "A256KW" でラップした | "apv" | |
| | CEK | | |
| A128GCMKW | 128 ビット鍵を使用する | "iv", | 任意 |
| | AES GCM による | "tag" | |
| | 鍵ラッピング | | |
| A192GCMKW | 192 ビット鍵を使用する | "iv", | 任意 |
| | AES GCM による | "tag" | |
| | 鍵ラッピング | | |
| A256GCMKW | 256 ビット鍵を使用する | "iv", | 任意 |
| | AES GCM による | "tag" | |
| | 鍵ラッピング | | |
| PBES2-HS256+A128KW | HMAC SHA-256 と | "p2s", | 任意 |
| | "A128KW" ラッピングを | "p2c" | |
| | 使用する PBES2 | | |
| PBES2-HS384+A192KW | HMAC SHA-384 と | "p2s", | 任意 |
| | "A192KW" ラッピングを | "p2c" | |
| | 使用する PBES2 | | |
| PBES2-HS512+A256KW | HMAC SHA-512 と | "p2s", | 任意 |
| | "A256KW" ラッピングを | "p2c" | |
| | 使用する PBES2 | | |
+--------------------+--------------------+--------+----------------+
追加ヘッダーパラメーター列は、すべてが使用する "alg" に加えて、
アルゴリズムが使用する追加のヘッダーパラメーターを示す。
"dir" と "ECDH-ES" を除くすべては、JWE Encrypted Key 値も生成する。
実装要件列での "+" の使用は、
将来の仕様バージョンで要件の強度が引き上げられる可能性が高いことを
示す。"-" の使用は、
将来の仕様バージョンで要件の強度が引き下げられる可能性が高いことを
示す。
この仕様で定義される JWE "alg"
(アルゴリズム) 値と、他の標準およびソフトウェアパッケージで使用される
同等の識別子との相互参照表については、付録 A.2 を参照すること。
4.2. RSAES-PKCS1-v1_5 による鍵暗号化
このセクションでは、RSAES-PKCS1-v1_5 [RFC3447] を使用して
JWE CEK を暗号化する詳細を定義する。このアルゴリズムには
"alg" (アルゴリズム) ヘッダーパラメーター値 "RSA1_5" を使用する。
このアルゴリズムでは、2048 ビット以上のサイズの鍵を使用しなければならない。
このアルゴリズムを使用する例は [JWE] の 付録 A.2 に示されている。
Jones 標準化過程 [13ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
4.3. RSAES OAEP による鍵暗号化
このセクションでは、Optimal Asymmetric Encryption Padding (OAEP)
[RFC3447] を使用する RSAES によって JWE CEK を暗号化する詳細を定義する。
OAEP を使用するための 2 組のパラメーターを定義し、それぞれ異なる
ハッシュ関数を使用する。最初の場合は、
RFC 3447 の付録 A.2.1 で指定された既定パラメーターを使用する。
(これらの既定パラメーターは SHA-1 ハッシュ関数と、
SHA-1 を使用する MGF1 マスク生成関数である。)
2 番目の場合は、SHA-256 ハッシュ関数と、
SHA-256 を使用する MGF1 マスク生成関数を使用する。
次の "alg" (アルゴリズム) ヘッダーパラメーター値は、
JWE Encrypted Key が対応するアルゴリズムを使用して CEK を
暗号化した結果であることを示すために使用される。
+-------------------+-----------------------------------------------+
| "alg" パラメーター値 | 鍵管理アルゴリズム |
+-------------------+-----------------------------------------------+
| RSA-OAEP | 既定パラメーターを使用する RSAES OAEP |
| RSA-OAEP-256 | SHA-256 と SHA-256 を使用する MGF1 を用いる |
| | RSAES OAEP |
+-------------------+-----------------------------------------------+
これらのアルゴリズムでは、2048 ビット以上のサイズの鍵を使用しなければならない。
(この要件は、NIST SP 800-57 [NIST.800-57] の表 4
(セキュリティ強度の時間枠) に基づいている。これは新規利用に
112 ビットのセキュリティを要求し、同文書の表 2 (同等の強度) では、
2048 ビット RSA 鍵が 112 ビットのセキュリティを提供すると
述べている。)
既定パラメーターで RSAES OAEP を使用する例は、
[JWE] の 付録 A.1 に示されている。
4.4. AES Key Wrap による鍵ラッピング
このセクションでは、Advanced Encryption Standard (AES) Key Wrap Algorithm
[RFC3394] を使用して JWE CEK を暗号化する詳細を定義し、
同文書の セクション 2.2.3.1 で指定された
既定の初期値を使用する。
Jones 標準化過程 [14ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
次の "alg" (アルゴリズム) ヘッダーパラメーター値は、
JWE Encrypted Key が対応するアルゴリズムと鍵サイズを使用して
CEK を暗号化した結果であることを示すために使用される。
+-----------------+-------------------------------------------------+
| "alg" パラメーター | 鍵管理アルゴリズム |
| 値 | |
+-----------------+-------------------------------------------------+
| A128KW | 既定の初期値と 128 ビット鍵を使用する AES Key Wrap |
| A192KW | 既定の初期値と 192 ビット鍵を使用する AES Key Wrap |
| A256KW | 既定の初期値と 256 ビット鍵を使用する AES Key Wrap |
+-----------------+-------------------------------------------------+
このアルゴリズムを使用する例は [JWE] の 付録 A.3 に示されている。
4.5. 共有対称鍵による直接暗号化
このセクションでは、鍵ラッピング手順を実行せずに
対称鍵暗号化を直接行う詳細を定義する。この場合、
共有対称鍵を "enc" アルゴリズムの Content Encryption
Key (CEK) 値として直接使用する。JWE Encrypted Key 値としては
空のオクテットシーケンスを使用する。この場合、
"alg" (アルゴリズム) ヘッダーパラメーター値 "dir" を使用する。
直接暗号化の使用を検討する場合は、セクション 8.2 の鍵の有効期間と、
セクション 8.4 の AES GCM に関するセキュリティ上の考慮事項を
参照すること。
4.6. 楕円曲線 Diffie-Hellman Ephemeral Static による鍵合意
(ECDH-ES)
このセクションでは、Elliptic
Curve Diffie-Hellman Ephemeral Static [RFC6090] による鍵合意を、
[NIST.800-56A] のセクション 5.8.1 で定義される Concat KDF と
組み合わせて使用する詳細を定義する。
鍵合意の結果は、次の 2 つの方法のいずれかで使用できる。
1. Direct Key Agreement モードで、"enc"
アルゴリズムの Content Encryption Key (CEK) として直接使用する、または
2. Key Agreement with Key
Wrapping モードで、"A128KW"、"A192KW"、または "A256KW"
アルゴリズムにより CEK をラップするための対称鍵として使用する。
各鍵合意操作ごとに、新しい一時公開鍵値を
生成しなければならない。
Jones 標準化過程 [15ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
Direct Key Agreement モードでは、Concat KDF の出力は
"enc" アルゴリズムで使用される鍵と同じ長さの鍵でなければならない。
この場合、JWE Encrypted Key 値として空のオクテットシーケンスを
使用する。Direct Key Agreement モードでは、
"alg" (アルゴリズム) ヘッダーパラメーター値 "ECDH-ES" を使用する。
Key Agreement with Key Wrapping モードでは、Concat KDF の出力は、
指定された鍵ラッピングアルゴリズムに必要な長さの鍵でなければならない。
この場合、JWE Encrypted Key は、合意された鍵で
ラップされた CEK である。
次の "alg" (アルゴリズム) ヘッダーパラメーター値は、
JWE Encrypted Key が、鍵合意アルゴリズムの結果を
対応する鍵ラッピングアルゴリズムの鍵暗号化鍵として使用して
CEK を暗号化した結果であることを示すために使用される。
+-----------------+-------------------------------------------------+
| "alg" パラメーター | 鍵管理アルゴリズム |
| 値 | |
+-----------------+-------------------------------------------------+
| ECDH-ES+A128KW | Concat KDF を使用する ECDH-ES と、"A128KW" で |
| | ラップされた CEK |
| ECDH-ES+A192KW | Concat KDF を使用する ECDH-ES と、"A192KW" で |
| | ラップされた CEK |
| ECDH-ES+A256KW | Concat KDF を使用する ECDH-ES と、"A256KW" で |
| | ラップされた CEK |
+-----------------+-------------------------------------------------+
4.6.1. ECDH 鍵合意で使用されるヘッダーパラメーター
鍵合意には、以下で定義する次のヘッダーパラメーター名を
使用する。
4.6.1.1. "epk" (一時公開鍵) ヘッダーパラメーター
鍵合意アルゴリズムで使用するために生成元が作成する
"epk" (一時公開鍵) 値。この鍵は、
JSON Web Key [JWK] の公開鍵値として表現される。これには公開鍵
パラメーターのみを含めなければならず、鍵を表現するために
必要な最小限の JWK パラメーターのみを含めるべきである。
含まれるその他の JWK パラメーターについては、整合性を確認して尊重してもよく、
または無視してもよい。これらのアルゴリズムを使用する場合、
このヘッダーパラメーターは存在しなければならず、
実装によって理解され処理されなければならない。
Jones 標準化過程 [16ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
4.6.1.2. "apu" (Agreement PartyUInfo) ヘッダーパラメーター
"apu" (agreement PartyUInfo) 値は、これを使用する鍵合意アルゴリズム
("ECDH-ES" など) のための値であり、base64url でエンコードされた
文字列として表現される。使用する場合、PartyUInfo 値には
生成者に関する情報が含まれる。このヘッダーパラメーターの使用は任意である。
これらのアルゴリズムを使用する場合、このヘッダーパラメーターは
実装によって理解され、処理されなければならない。
4.6.1.3. "apv" (Agreement PartyVInfo) ヘッダーパラメーター
"apv" (agreement PartyVInfo) 値は、これを使用する鍵合意アルゴリズム
("ECDH-ES" など) のための値であり、base64url でエンコードされた
文字列として表現される。使用する場合、PartyVInfo 値には
受信者に関する情報が含まれる。このヘッダーパラメーターの使用は任意である。
これらのアルゴリズムを使用する場合、このヘッダーパラメーターは
実装によって理解され、処理されなければならない。
4.6.2. ECDH 鍵合意のための鍵導出
鍵導出処理は、[NIST.800-56A] の
セクション 6.2.2.2 に従って、ECDH アルゴリズムによって確立された
共有秘密 Z から合意済み鍵を導出する。
鍵導出は、[NIST.800-56A] の
セクション 5.8.1 で定義されている Concat KDF を使用して実行し、
Digest Method は SHA-256 とする。
Concat KDF パラメーターは次のように設定する。
Z
これは共有秘密 Z をオクテットシーケンスとして
表現したものに設定する。
keydatalen
これは、目的の出力鍵のビット数に設定する。
"ECDH-ES" の場合、これは "enc" アルゴリズムが使用する鍵の長さである。
"ECDH-ES+A128KW"、"ECDH-ES+A192KW"、"ECDH-ES+A256KW" の場合は、
それぞれ 128、192、256 である。
AlgorithmID
AlgorithmID 値は Datalen || Data の形式であり、Data は
0 個以上のオクテットからなる可変長文字列、Datalen は
Data の長さ (オクテット単位) を示す
固定長ビッグエンディアン 32 ビットカウンターである。
Direct Key Agreement の場合、Data は "enc"
ヘッダーパラメーター値の ASCII 表現のオクテットに設定する。
Key Agreement with Key Wrapping の場合、Data は
"alg" (アルゴリズム) ヘッダーパラメーター値の ASCII 表現の
オクテットに設定する。
Jones 標準化過程 [17ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
PartyUInfo
PartyUInfo 値は Datalen || Data の形式であり、Data は
0 個以上のオクテットからなる可変長文字列、Datalen は
Data の長さ (オクテット単位) を示す固定長のビッグエンディアン
32 ビットカウンターである。"apu" (agreement PartyUInfo) ヘッダー
パラメーターが存在する場合、Data は "apu" 値を
base64url デコードした結果に設定し、Datalen は
Data のオクテット数に設定する。それ以外の場合、
Datalen は 0 に設定し、Data は空のオクテットシーケンスに設定する。
PartyVInfo
PartyVInfo 値は Datalen || Data の形式であり、Data は
0 個以上のオクテットからなる可変長文字列、Datalen は
Data の長さ (オクテット単位) を示す固定長のビッグエンディアン
32 ビットカウンターである。"apv" (agreement PartyVInfo) ヘッダー
パラメーターが存在する場合、Data は "apv" 値を
base64url デコードした結果に設定し、Datalen は
Data のオクテット数に設定する。それ以外の場合、
Datalen は 0 に設定し、Data は空のオクテットシーケンスに設定する。
SuppPubInfo
これは、keydatalen を 32 ビットのビッグエンディアン
整数として表現したものに設定する。
SuppPrivInfo
これは空のオクテットシーケンスに設定する。
アプリケーションは、そのアプリケーションで "apu" および "apv" ヘッダー
パラメーターをどのように使用するかを指定する必要がある。"apu" と "apv" の値は、
使用する場合、互いに異ならなければならない。[NIST.800-56A] に
適合しようとするアプリケーションは、たとえば生成者と消費者を
識別する値を使用するなど、その文書の要件を満たす値を提供する必要がある。
代わりに、アプリケーションは "Diffie-Hellman Key Agreement Method"
[RFC2631] と同様の方法で鍵導出を実行してもよい。
その場合、"apu" パラメーターは省略してもよく、またはランダムな
512 ビット値 (RFC 2631 の Ephemeral-Static
モードにおける PartyAInfo に相当) を表してもよく、"apv" パラメーターは
存在すべきではない。
この方法を使用した鍵合意計算の例については、付録 C を参照すること。
4.7. AES GCM による鍵暗号化
このセクションでは、Galois/Counter Mode (GCM) の
Advanced Encryption Standard (AES) ([AES] および [NIST.800-38D]) を使用して
JWE Content Encryption Key (CEK) を暗号化する詳細を定義する。
Jones 標準化過程 [18ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
このアルゴリズムでは、サイズ 96 ビットの Initialization Vector (IV) の
使用が必須である。IV は base64url エンコード形式で
"iv" (initialization vector) ヘッダーパラメーター値として表現する。
使用する Additional Authenticated Data 値は、空の
オクテット文字列である。
要求する Authentication Tag 出力のサイズは、
鍵サイズにかかわらず 128 ビットでなければならない。
JWE Encrypted Key 値は暗号文出力である。
Authentication Tag 出力は、base64url エンコード形式で
"tag" (authentication tag) ヘッダーパラメーター値として表現する。
次の "alg" (アルゴリズム) ヘッダーパラメーター値は、
JWE Encrypted Key が対応するアルゴリズムと鍵サイズを使用して
CEK を暗号化した結果であることを示すために使用される。
+-------------------+---------------------------------------------+
| "alg" パラメーター値 | 鍵管理アルゴリズム |
+-------------------+---------------------------------------------+
| A128GCMKW | 128 ビット鍵を使用する AES GCM 鍵ラッピング |
| A192GCMKW | 192 ビット鍵を使用する AES GCM 鍵ラッピング |
| A256GCMKW | 256 ビット鍵を使用する AES GCM 鍵ラッピング |
+-------------------+---------------------------------------------+
4.7.1. AES GCM 鍵暗号化で使用されるヘッダーパラメーター
AES GCM 鍵暗号化には、次のヘッダーパラメーターを使用する。
4.7.1.1. "iv" (初期化ベクトル) ヘッダーパラメーター
"iv" (initialization vector) ヘッダーパラメーター値は、
鍵暗号化操作で使用される 96 ビット IV 値の
base64url エンコード表現である。このヘッダーパラメーターは存在しなければならず、
これらのアルゴリズムを使用する場合、実装によって
理解され処理されなければならない。
4.7.1.2. "tag" (認証タグ) ヘッダーパラメーター
"tag" (authentication tag) ヘッダーパラメーター値は、
鍵暗号化操作の結果として得られる 128 ビット Authentication Tag
値の base64url エンコード表現である。このヘッダーパラメーターは存在しなければならず、
これらのアルゴリズムを使用する場合、実装によって
理解され処理されなければならない。
Jones 標準化過程 [19ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
4.8. PBES2 による鍵暗号化
このセクションでは、まず
[RFC2898] のセクション 6.2 で指定された PBES2 方式を使用して、
ユーザーが提供したパスワードから鍵暗号化鍵を導出し、
その後、導出された鍵を使用して JWE CEK を暗号化することによって、
JWE CEK のパスワードベース暗号化を実行する詳細を定義する。
これらのアルゴリズムでは、PBKDF2 鍵導出の擬似乱数関数 (PRF) として
HMAC SHA-2 アルゴリズムを、暗号化方式として
AES Key Wrap [RFC3394] を使用する。PBES2 のパスワード入力は
オクテットシーケンスである。使用するパスワードがオクテットシーケンスではなく
テキスト文字列として表現される場合、そのテキスト文字列の UTF-8
エンコーディングをオクテットシーケンスとして使用しなければならない。
ソルトパラメーターは、以下の "p2s" 定義で指定されているとおり、
"p2s" (PBES2 salt input) ヘッダーパラメーター値と
"alg" (アルゴリズム) ヘッダーパラメーター値から計算しなければならない。
反復回数パラメーターは、"p2c" (PBES2 count) ヘッダーパラメーター値として
提供しなければならない。各アルゴリズムはそれぞれ
HMAC SHA-256、HMAC SHA-384、HMAC SHA-512 を PRF として使用し、
128、192、256 ビットの AES Key Wrap 鍵を使用する。
導出鍵の長さはそれぞれ 16、24、32 オクテットである。
次の "alg" (アルゴリズム) ヘッダーパラメーター値は、
JWE Encrypted Key が、対応するパスワードベース暗号化
アルゴリズムの結果を、対応する鍵
ラッピングアルゴリズム用の鍵暗号化鍵として使用して
CEK を暗号化した結果であることを示すために使用される。
+--------------------+----------------------------------------------+
| "alg" パラメーター値 | 鍵管理アルゴリズム |
+--------------------+----------------------------------------------+
| PBES2-HS256+A128KW | HMAC SHA-256 と "A128KW" ラッピングを使用する |
| | PBES2 |
| PBES2-HS384+A192KW | HMAC SHA-384 と "A192KW" ラッピングを使用する |
| | PBES2 |
| PBES2-HS512+A256KW | HMAC SHA-512 と "A256KW" ラッピングを使用する |
| | PBES2 |
+--------------------+----------------------------------------------+
"PBES2-HS256+A128KW" を使用した鍵暗号化計算の例については、
JWK 仕様 [JWK] の 付録 C を参照すること。
4.8.1. PBES2 鍵暗号化で使用されるヘッダーパラメーター
PBES2 による鍵暗号化には、次のヘッダーパラメーターを使用する。
Jones 標準化過程 [20ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
4.8.1.1. "p2s" (PBES2 ソルト入力) ヘッダーパラメーター
"p2s" (PBES2 salt input) ヘッダーパラメーターは、
PBKDF2 ソルト値の一部として使用される Salt Input 値をエンコードする。
"p2s" 値は BASE64URL(Salt Input) である。このヘッダーパラメーターは
存在しなければならず、これらのアルゴリズムを使用する場合、
実装によって理解され処理されなければならない。
ソルトは、あるパスワードから導出できる可能性のある鍵を増加させる。
8 オクテット以上を含む Salt Input 値を
使用しなければならない。暗号化操作ごとに、新しい Salt Input 値を
ランダムに生成しなければならない。ランダム値の生成に関する考慮事項については、
RFC 4086 [RFC4086] を参照すること。
使用するソルト値は (UTF8(Alg) || 0x00
|| Salt Input) であり、ここで Alg は "alg" (アルゴリズム) ヘッダーパラメーター
値である。
4.8.1.2. "p2c" (PBES2 回数) ヘッダーパラメーター
"p2c" (PBES2 count) ヘッダーパラメーターには、
正の JSON 整数として表される PBKDF2
反復回数が含まれる。このヘッダーパラメーターは存在しなければならず、
これらのアルゴリズムを使用する場合、実装によって理解され処理されなければならない。
反復回数は計算コストを追加し、理想的にはソルトによって
導入される可能な鍵の範囲と相乗して効果を発揮する。
最小反復回数として 1000 を使用することを推奨する。
5. コンテンツ暗号化のための暗号アルゴリズム
JWE は暗号アルゴリズムを使用して平文を暗号化し、
その完全性を保護するとともに、Additional Authenticated
Data の完全性も保護する。
Jones 標準化過程 [21ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
5.1. JWE の "enc" (暗号化アルゴリズム) ヘッダーパラメーター値
次の表は、この仕様で JWE 用として定義する
"enc" (暗号化アルゴリズム) ヘッダーパラメーター値の集合である。
+---------------+----------------------------------+----------------+
| "enc" パラメーター | コンテンツ暗号化アルゴリズム | 実装要件 |
| 値 | | |
+---------------+----------------------------------+----------------+
| A128CBC-HS256 | AES_128_CBC_HMAC_SHA_256 | 必須 |
| | 認証付き暗号化 | |
| | アルゴリズム、セクション | |
| | 5.2.3 で定義 | |
| A192CBC-HS384 | AES_192_CBC_HMAC_SHA_384 | 任意 |
| | 認証付き暗号化 | |
| | アルゴリズム、セクション | |
| | 5.2.4 で定義 | |
| A256CBC-HS512 | AES_256_CBC_HMAC_SHA_512 | 必須 |
| | 認証付き暗号化 | |
| | アルゴリズム、セクション | |
| | 5.2.5 で定義 | |
| A128GCM | 128 ビット鍵を使用する AES GCM | 推奨 |
| A192GCM | 192 ビット鍵を使用する AES GCM | 任意 |
| A256GCM | 256 ビット鍵を使用する AES GCM | 推奨 |
+---------------+----------------------------------+----------------+
これらはすべて JWE Initialization Vector 値も使用し、
JWE Ciphertext および JWE Authentication Tag 値を生成する。
この仕様で定義する JWE "enc"
(暗号化アルゴリズム) 値と、他の標準およびソフトウェアパッケージで使用される
同等の識別子との相互参照表については、付録 A.3 を参照すること。
5.2. AES_CBC_HMAC_SHA2 アルゴリズム
このセクションでは、Cipher Block Chaining (CBC)
モード [NIST.800-38A] の AES [AES] と、
[RFC5652] のセクション 6.3 に従った PKCS #7 パディング操作、
および HMAC ([RFC2104] および [SHS]) 操作を組み合わせて構築される
認証付き暗号化アルゴリズムのファミリーを定義する。
このアルゴリズムファミリーを AES_CBC_HMAC_SHA2 と呼ぶ。また、このファミリーの
3 つのインスタンスも定義する。1 つ目は 128 ビット CBC 鍵と HMAC
SHA-256、2 つ目は 192 ビット CBC 鍵と HMAC SHA-384、
3 つ目は 256 ビット CBC 鍵と HMAC SHA-512 を使用する。これらの
アルゴリズムのテストケースは 付録 B にある。
Jones 標準化過程 [22ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
これらのアルゴリズムは "Authenticated Encryption with AES-
CBC and HMAC-SHA" [AEAD-CBC-SHA] に基づき、同じ暗号計算を
実行するが、出力表現において Initialization Vector (IV) と
Authentication Tag 値を暗号文値と連結せず、
個別に保持する。この選択肢については、同仕様の
付録 B で説明されている。この
アルゴリズムファミリーは [AEAD-CBC-SHA] のアルゴリズムファミリーを一般化したものであり、
それらのアルゴリズムを実装するために使用できる。
5.2.1. AES_CBC_HMAC_SHA2 の定義で使用する規則
次の表記規則を使用する。
CBC-PKCS7-ENC(X, P) は、鍵 X を持つ暗号を使用し、
PKCS #7 パディングを適用して P を AES-CBC 暗号化することを表す。
MAC(Y, M) は、鍵 Y を使用してメッセージ M に
MAC を適用することを表す。
5.2.2. 汎用 AES_CBC_HMAC_SHA2 アルゴリズム
このセクションでは、使用する AES-CBC 鍵サイズやハッシュ関数に
依存しない形で AES_CBC_HMAC_SHA2 を定義する。
セクション 5.2.2.1 および 5.2.2.2 では、汎用の暗号化および
復号アルゴリズムを定義する。セクション 5.2.3 から 5.2.5 では、
これらの詳細を指定する AES_CBC_HMAC_SHA2 のインスタンスを定義する。
5.2.2.1. AES_CBC_HMAC_SHA2 暗号化
認証付き暗号化アルゴリズムは、4 つのオクテット文字列、
秘密鍵 K、平文 P、Additional Authenticated Data
A、および Initialization Vector IV を入力として受け取る。
認証付き暗号文値 E と Authentication Tag 値 T を出力する。
平文内のデータは暗号化および認証され、
Additional Authenticated Data は認証されるが暗号化されない。
暗号化処理は次のとおりである。または、これと同等の一連の
手順を使用する。
1. 補助鍵 MAC_KEY および ENC_KEY を、
入力鍵 K から次のように生成する。これら 2 つの鍵はそれぞれ
オクテット文字列である。
MAC_KEY は K の先頭 MAC_KEY_LEN オクテットから、
順序どおりに構成する。
ENC_KEY は K の末尾 ENC_KEY_LEN オクテットから、
順序どおりに構成する。
Jones 標準化過程 [23ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
入力鍵 K のオクテット数は、
MAC_KEY_LEN と ENC_KEY_LEN の合計でなければならない。
これらのパラメーターの値は、セクション
5.2.3 から 5.2.5 の Authenticated Encryption アルゴリズムによって指定される。
入力鍵 K では MAC 鍵が暗号化鍵より前にあることに注意。
これは識別子 "AES_CBC_HMAC_SHA2" における
アルゴリズム名の順序とは逆である。
2. 使用する IV は、暗号で使用するためにランダムまたは
擬似ランダムに生成された 128 ビット値である。
3. ENC_KEY を鍵、IV を Initialization Vector として、
PKCS #7 パディングを使用して平文を CBC 暗号化する。
この手順から得られる暗号文出力を E と表記する。
4. オクテット文字列 AL は、Additional Authenticated Data A の
ビット数を 64 ビット符号なし
ビッグエンディアン整数として表したものに等しい。
5. 次のデータに順番どおり HMAC
[RFC2104] を適用して、メッセージ Authentication Tag T を計算する。
Additional Authenticated Data A、
Initialization Vector IV、
前の手順で計算した暗号文 E、および
上で定義したオクテット文字列 AL。
文字列 MAC_KEY を MAC 鍵として使用する。この手順で
計算された MAC の出力を M と表記する。M の先頭 T_LEN オクテットを
T として使用する。
6. 暗号文 E と Authentication Tag T を、
認証付き暗号化の出力として返す。
暗号化処理は次のように示すことができる。ここで K、P、A、
IV、E はそれぞれ鍵、平文、Additional Authenticated Data、
Initialization Vector、暗号文を表す。
MAC_KEY = K の先頭 MAC_KEY_LEN オクテット,
ENC_KEY = K の末尾 ENC_KEY_LEN オクテット,
E = CBC-PKCS7-ENC(ENC_KEY, P),
M = MAC(MAC_KEY, A || IV || E || AL),
T = M の先頭 T_LEN オクテット。
Jones 標準化過程 [24ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
5.2.2.2. AES_CBC_HMAC_SHA2 復号
認証付き復号操作には、上で定義した K、A、IV、E、
T の 5 つの入力がある。出力は 1 つだけであり、
平文値 P または入力が真正でないことを示す
特別なシンボル FAIL のいずれかである。認証付き復号アルゴリズムは
次のとおりである。または、これと同等の一連の手順を使用する。
1. 補助鍵 MAC_KEY および ENC_KEY を、
セクション 5.2.2.1 の手順 1 と同様に入力鍵 K から生成する。
2. セクション 5.2.2.1 の手順 5 と同じ入力を使用して
HMAC を計算し、A と E の完全性と真正性を確認する。
前の手順の値 T を、
HMAC 出力の先頭 MAC_KEY 長ビットと比較する。
これらの値が同一であれば、A と E は有効とみなし、
処理を継続する。それ以外の場合、MAC 検証に使用した
すべてのデータを破棄し、認証付き
復号操作は失敗したことを示す結果を返して、
操作を停止する。(ただし、タイミング攻撃を防ぐためのセキュリティ上の
考慮事項については [JWE] のセクション 11.5 を参照。)
3. 値 E を復号し、PKCS #7 パディングを検証して
除去する。値 IV を Initialization Vector として使用する。
値 ENC_KEY を復号鍵として使用する。
4. 平文値を返す。
5.2.3. AES_128_CBC_HMAC_SHA_256
このアルゴリズムは、上記の汎用
AES_CBC_HMAC_SHA2 アルゴリズムの具体的なインスタンスである。
SHA-256 ハッシュ関数 [SHS] と HMAC メッセージ
認証コード [RFC2104] を使用してメッセージ認証を提供し、
HMAC 出力を 128 ビットに切り詰める。これは
[RFC4868] で定義される HMAC-SHA-256-128 アルゴリズムに対応する。
暗号化には、[NIST.800-38A] のセクション 6.2 で定義された
CBC モードの AES を、PKCS #7 パディングおよび
128 ビット IV 値とともに使用する。
AES_128_CBC_HMAC_SHA_256 に固有の AES_CBC_HMAC_SHA2 パラメーター
は次のとおりである。
入力鍵 K の長さは 32 オクテットである。
ENC_KEY_LEN は 16 オクテットである。
MAC_KEY_LEN は 16 オクテットである。
HMAC には SHA-256 ハッシュアルゴリズムを使用する。
HMAC-SHA-256 出力は、末尾 16 オクテットを
除去することで T_LEN=16 オクテットに切り詰める。
Jones 標準化過程 [25ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
5.2.4. AES_192_CBC_HMAC_SHA_384
AES_192_CBC_HMAC_SHA_384 は AES_128_CBC_HMAC_SHA_256 に基づくが、
次の相違点がある。
入力鍵 K の長さは 32 ではなく 48 オクテットである。
ENC_KEY_LEN は 16 ではなく 24 オクテットである。
MAC_KEY_LEN は 16 ではなく 24 オクテットである。
HMAC には SHA-256 ではなく SHA-384 を使用する。
HMAC SHA-384 値は、16 ではなく
T_LEN=24 オクテットに切り詰める。
5.2.5. AES_256_CBC_HMAC_SHA_512
AES_256_CBC_HMAC_SHA_512 は AES_128_CBC_HMAC_SHA_256 に基づくが、
次の相違点がある。
入力鍵 K の長さは 32 ではなく 64 オクテットである。
ENC_KEY_LEN は 16 ではなく 32 オクテットである。
MAC_KEY_LEN は 16 ではなく 32 オクテットである。
HMAC には SHA-256 ではなく SHA-512 を使用する。
HMAC SHA-512 値は、16 ではなく
T_LEN=32 オクテットに切り詰める。
5.2.6. AES_CBC_HMAC_SHA2 によるコンテンツ暗号化
このセクションでは、AES_CBC_HMAC_SHA2 アルゴリズムを使用して
認証付き暗号化を実行する詳細を定義する。
CEK を秘密鍵 K として使用する。
次の "enc" (暗号化アルゴリズム) ヘッダーパラメーター値は、
JWE Ciphertext および JWE Authentication
Tag 値が対応するアルゴリズムを使用して計算されたことを示すために使用される。
+---------------+---------------------------------------------------+
| "enc" パラメーター | コンテンツ暗号化アルゴリズム |
| 値 | |
+---------------+---------------------------------------------------+
| A128CBC-HS256 | AES_128_CBC_HMAC_SHA_256 認証付き暗号化アルゴリズム |
| | セクション 5.2.3 で定義 |
| A192CBC-HS384 | AES_192_CBC_HMAC_SHA_384 認証付き暗号化アルゴリズム |
| | セクション 5.2.4 で定義 |
| A256CBC-HS512 | AES_256_CBC_HMAC_SHA_512 認証付き暗号化アルゴリズム |
| | セクション 5.2.5 で定義 |
+---------------+---------------------------------------------------+
Jones 標準化過程 [26ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
5.3. AES GCM によるコンテンツ暗号化
このセクションでは、Galois/Counter Mode (GCM) の AES
([AES] および
[NIST.800-38D]) を使用して認証付き暗号化を実行する詳細を定義する。
CEK を暗号化鍵として使用する。
このアルゴリズムでは、サイズ 96 ビットの IV の使用が必須である。
要求する Authentication Tag 出力のサイズは、
鍵サイズにかかわらず 128 ビットでなければならない。
次の "enc" (暗号化アルゴリズム) ヘッダーパラメーター値は、
JWE Ciphertext および JWE Authentication
Tag 値が対応するアルゴリズムと
鍵サイズを使用して計算されたことを示すために使用される。
+-------------------+------------------------------+
| "enc" パラメーター値 | コンテンツ暗号化アルゴリズム |
+-------------------+------------------------------+
| A128GCM | 128 ビット鍵を使用する AES GCM |
| A192GCM | 192 ビット鍵を使用する AES GCM |
| A256GCM | 256 ビット鍵を使用する AES GCM |
+-------------------+------------------------------+
このアルゴリズムを使用する例は [JWE] の 付録 A.1 に示されている。
6. 鍵のための暗号アルゴリズム
JSON Web Key (JWK) [JWK] は、暗号鍵を表現する JSON データ構造である。
これらの鍵は非対称または対称のいずれでもよい。
鍵に関する公開情報と秘密情報の両方を保持できる。
このセクションでは、この文書で指定するアルゴリズムを使用する
鍵のパラメーターを定義する。
Jones 標準化過程 [27ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
6.1. "kty" (鍵タイプ) パラメーター値
次の表は、この仕様で JWK 用として定義する
"kty" (鍵タイプ) パラメーター値の集合である。
+-------------+--------------------------------+--------------------+
| "kty" パラメーター | 鍵タイプ | 実装要件 |
| 値 | | |
+-------------+--------------------------------+--------------------+
| EC | 楕円曲線 [DSS] | 推奨+ |
| RSA | RSA [RFC3447] | 必須 |
| oct | オクテットシーケンス | 必須 |
| | (対称鍵の表現に使用) | |
+-------------+--------------------------------+--------------------+
実装要件列での "+" の使用は、
将来の仕様バージョンで要件の強度が引き上げられる可能性が高いことを
示す。
6.2. 楕円曲線鍵のパラメーター
JWK は楕円曲線 [DSS] 鍵を表現できる。この場合、
"kty" メンバー値は "EC" である。
6.2.1. 楕円曲線公開鍵のパラメーター
楕円曲線公開鍵は、有限体から取得した一対の座標によって
表現され、この 2 つの座標が一緒になって
楕円曲線上の点を定義する。すべての
楕円曲線公開鍵には、次のメンバーが存在しなければならない。
o "crv"
o "x"
次のセクションで定義する 3 つの曲線の楕円曲線公開鍵には、
次のメンバーも存在しなければならない。
o "y"
6.2.1.1. "crv" (曲線) パラメーター
"crv" (curve) パラメーターは、その鍵で使用される暗号曲線を識別する。
この仕様で使用される [DSS] の曲線値
は次のとおりである。
o "P-256"
o "P-384"
o "P-521"
Jones 標準化過程 [28ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
これらの値は、セクション 7.6 で定義する IANA
"JSON Web Key Elliptic Curve" レジストリに登録される。
追加の "crv" 値は他の仕様によって登録できる。
追加の曲線を登録する仕様は、登録する曲線の鍵を表現するために
どのパラメーターを使用するかを定義しなければならない。
"crv" 値は大文字と小文字を区別する文字列である。
SEC1 [SEC1] の点圧縮は、これら 3 つの
曲線のいずれについてもサポートされない。
6.2.1.2. "x" (X 座標) パラメーター
"x" (x coordinate) パラメーターには、
楕円曲線上の点の x 座標が含まれる。これは、SEC1 [SEC1] の
セクション 2.3.5 で定義される座標のオクテット文字列表現を
base64url エンコードしたものとして表現される。このオクテット文字列の長さは、
"crv" パラメーターで指定された曲線の座標の
完全なサイズでなければならない。たとえば、"crv" の値が "P-521" の場合、
オクテット文字列の長さは 66 オクテットでなければならない。
6.2.1.3. "y" (Y 座標) パラメーター
"y" (y coordinate) パラメーターには、
楕円曲線上の点の y 座標が含まれる。これは、SEC1 [SEC1] の
セクション 2.3.5 で定義される座標のオクテット文字列表現を
base64url エンコードしたものとして表現される。このオクテット文字列の長さは、
"crv" パラメーターで指定された曲線の座標の
完全なサイズでなければならない。たとえば、"crv" の値が "P-521" の場合、
オクテット文字列の長さは 66 オクテットでなければならない。
6.2.2. 楕円曲線秘密鍵のパラメーター
楕円曲線公開鍵を表現するために使用されるメンバーに加えて、
楕円曲線秘密鍵を表現するためには、次のメンバーが
存在しなければならない。
6.2.2.1. "d" (ECC 秘密鍵) パラメーター
"d" (ECC private key) パラメーターには、楕円曲線
秘密鍵値が含まれる。これは、SEC1 [SEC1] の
セクション 2.3.7 で定義される秘密鍵値のオクテット文字列表現を
base64url エンコードしたものとして表現される。このオクテット文字列の長さは、
ceiling(log-base-2(n)/8) オクテットでなければならない
(ここで n は曲線の位数である)。
Jones 標準化過程 [29ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
6.3. RSA 鍵のパラメーター
JWK は RSA [RFC3447] 鍵を表現できる。この場合、
"kty" メンバー値は "RSA" である。以下で定義するパラメーターの意味論は、
RFC 3447 のセクション 3.1 および 3.2 で定義されるものと同じである。
6.3.1. RSA 公開鍵のパラメーター
RSA 公開鍵には、次のメンバーが存在しなければならない。
6.3.1.1. "n" (法) パラメーター
"n" (modulus) パラメーターには、RSA
公開鍵の法の値が含まれる。これは Base64urlUInt エンコード値として表現される。
一部の暗号ライブラリは、返す法の表現の先頭に
値がゼロの余分なオクテットを付加することが実装者によって確認されている。
たとえば、2048 ビット鍵について 256 ではなく
257 オクテットを返す。このようなライブラリを使用する実装は、
base64url エンコード表現から余分なオクテットを
省略するよう注意する必要がある。
6.3.1.2. "e" (指数) パラメーター
"e" (exponent) パラメーターには、RSA
公開鍵の指数値が含まれる。これは Base64urlUInt エンコード値として表現される。
たとえば、値 65537 を表現する場合、base64url エンコードする
オクテットシーケンスは 3 つのオクテット [1, 0, 1] で構成されなければならず、
この値の結果の表現は "AQAB" となる。
6.3.2. RSA 秘密鍵のパラメーター
RSA 公開鍵を表現するために使用されるメンバーに加えて、
RSA 秘密鍵を表現するために次のメンバーを使用する。
パラメーター "d" は RSA 秘密鍵では必須である。その他は
最適化を可能にするものであり、RSA 秘密鍵を表現する JWK の
生成者は含めるべきである。生成者が他の
秘密鍵パラメーターのいずれかを含める場合、他のすべても存在しなければならない。
ただし "oth" は例外であり、2 つを超える
素因数が使用された場合にのみ存在しなければならない。
6.3.2.1. "d" (秘密指数) パラメーター
"d" (private exponent) パラメーターには、RSA 秘密鍵の
秘密指数値が含まれる。これは Base64urlUInt
エンコード値として表現される。
Jones 標準化過程 [30ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
6.3.2.2. "p" (第1素因数) パラメーター
"p" (first prime factor) パラメーターには、第1
素因数が含まれる。これは Base64urlUInt エンコード値として表現される。
6.3.2.3. "q" (第2素因数) パラメーター
"q" (second prime factor) パラメーターには、第2
素因数が含まれる。これは Base64urlUInt エンコード値として表現される。
6.3.2.4. "dp" (第1因数 CRT 指数) パラメーター
"dp" (first factor CRT exponent) パラメーターには、第1因数の
中国剰余定理 (CRT) 指数が含まれる。これは
Base64urlUInt エンコード値として表現される。
6.3.2.5. "dq" (第2因数 CRT 指数) パラメーター
"dq" (second factor CRT exponent) パラメーターには、第2因数の
CRT 指数が含まれる。これは Base64urlUInt
エンコード値として表現される。
6.3.2.6. "qi" (第1 CRT 係数) パラメーター
"qi" (first CRT coefficient) パラメーターには、第2因数の
CRT 係数が含まれる。これは
Base64urlUInt エンコード値として表現される。
6.3.2.7. "oth" (その他の素数情報) パラメーター
"oth" (other primes info) パラメーターには、
存在する場合、第3以降の素数に関する情報の配列が含まれる。
2 つの素数のみが使用された場合 (通常の場合)、このパラメーターは
省略しなければならない。3 つ以上の素数が使用された場合、
配列要素数は使用された素数の数から 2 を引いた数でなければならない。
この場合の詳細については、RFC 3447 の付録 A.1.2 [RFC3447] の
OtherPrimeInfo パラメーターの説明を参照すること。
以下のパラメーターはこれをモデルとしている。JWK の消費者が
2 つを超える素数を持つ秘密鍵をサポートしておらず、
"oth" パラメーターを含む秘密鍵に遭遇した場合、その鍵を
使用してはならない。各配列要素は、次の
メンバーを持つオブジェクトでなければならない。
6.3.2.7.1. "r" (素因数)
"oth" 配列メンバー内の "r" (prime factor) パラメーターは、
後続の素因数の値を表す。これは
Base64urlUInt エンコード値として表現される。
Jones 標準化過程 [31ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
6.3.2.7.2. "d" (因数 CRT 指数)
"oth" 配列メンバー内の "d" (factor CRT exponent) パラメーターは、
対応する素因数の CRT 指数を表す。これは
Base64urlUInt エンコード値として表現される。
6.3.2.7.3. "t" (因数 CRT 係数)
"oth" 配列メンバー内の "t" (factor CRT coefficient) パラメーターは、
対応する素因数の CRT 係数を表す。これは
Base64urlUInt エンコード値として表現される。
6.4. 対称鍵のパラメーター
JWK の "kty" メンバー値が "oct" (オクテットシーケンス) の場合、
メンバー "k" (セクション 6.4.1 を参照) を使用して対称鍵
(または値が単一のオクテットシーケンスである別の鍵) を表現する。
アプリケーションが使用するアルゴリズムを決定するために
別の手段または規約を使用しない限り、その鍵で使用することを意図した
アルゴリズムを識別する "alg" メンバーも存在すべきである。
6.4.1. "k" (鍵値) パラメーター
"k" (key value) パラメーターには、対称鍵
(またはその他の単一値の鍵) の値が含まれる。これは鍵値を含む
オクテットシーケンスの base64url
エンコーディングとして表現される。
7. IANA に関する考慮事項
この仕様で確立されるすべてのレジストリでは、
次の登録手順を使用する。
値の登録手順は、jose-reg-review@ietf.org メーリングリストでの
3 週間のレビュー期間の後、1 名以上の
Designated Expert の助言に基づく Specification Required
[RFC5226] である。ただし、公開前に値を割り当てられるようにするため、
Designated Expert は、その仕様が公開されると
確信した時点で登録を承認してもよい。
レビューのためにメーリングリストへ送信する登録要求には、
適切な件名 (たとえば "アルゴリズム登録要求:
example") を使用すべきである。
レビュー期間中、Designated Expert は登録要求を承認または
拒否し、その決定をレビューリストおよび IANA に通知する。
拒否には説明を含め、該当する場合は
要求を成功させる方法についての提案も含めるべきである。
Jones 標準化過程 [32ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
21 日を超えて未決定のままの登録要求は、
解決のため IESG に通知できる
(iesg@ietf.org メーリングリストを使用する)。
Designated Expert が適用すべき基準には、
提案された登録が既存の機能を重複していないか、
一般的に適用される可能性があるか、それとも単一のアプリケーションにのみ
有用であるか、登録の説明が明確であるかを
判断することが含まれる。
IANA は Designated Expert からのレジストリ更新のみを受け入れなければならず、
すべての登録要求をレビュー用メーリング
リストへ案内すべきである。
この仕様を使用する異なるアプリケーションの観点を
代表できる複数の Designated Expert を任命し、
登録に関する判断について幅広い情報に基づいたレビューを可能にすることが
推奨される。ある登録判断が特定の
Expert に利益相反を生じさせると見なされる可能性がある場合、
その Expert は他の Expert の判断に
委ねるべきである。
7.1. JSON Web 署名および暗号化アルゴリズムレジストリ
この仕様は、JWS および JWE の "alg"
(アルゴリズム) および "enc" (暗号化アルゴリズム) ヘッダーパラメーター値のための
IANA "JSON Web Signature and Encryption Algorithms" レジストリを
確立する。このレジストリには、アルゴリズム名、アルゴリズムの説明、
アルゴリズムの使用箇所、実装要件、
変更管理者、およびそのアルゴリズムを定義する仕様への
参照を記録する。同じアルゴリズム名は、
使用箇所の集合が互いに重複しない場合、複数回登録できる。
異なる長さの鍵を使用するアルゴリズムの複数のバリエーションを
登録し、各鍵長を固定する必要がある場合
(たとえば、鍵導出関数によって作成されるため)、
鍵の長さをアルゴリズム名に含めることが推奨される。
これにより JSON テキストの読者は、
セキュリティ上の判断をより容易に行える。
Designated Expert は、登録されるアルゴリズムが
現時点で暗号学的に信頼できるとみなされているか、
または Deprecated もしくは Prohibited として登録されていることについて、
合理的なデューデリジェンスを実施すべきである。
Jones 標準化過程 [33ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
暗号技術を取り巻く状況の変化に伴い、アルゴリズムの実装要件は
時間の経過とともに変更されることがある。たとえば、アルゴリズムの
状態を非推奨に変更したり、アルゴリズムの状態を
任意から推奨+または必須に変更したりする場合である。
実装要件の変更は、指定専門家によるレビューの後、
改訂された実装要件レベルを定義する新しい仕様に基づき、
仕様必須の手続きによってのみ許可される。
7.1.1. 登録テンプレート
アルゴリズム名:
要求する名前 (例: "HS256")。この名前は大文字と小文字を区別する
ASCII 文字列である。指定専門家が例外を許可する説得力のある理由が
あると判断しない限り、大文字と小文字を区別しない比較で
他の登録済みの名前と一致してはならない。
アルゴリズムの説明:
アルゴリズムの簡単な説明 (例: "SHA-256 を使用する HMAC")。
アルゴリズムの使用箇所:
アルゴリズムの使用箇所。アルゴリズムを JWS または
JWE で使用する場合、これは "alg" または "enc" の
1 つ以上の値でなければならない。アルゴリズム識別子を
JWK の "alg" メンバー値として使用するが、JWS または
JWE では使用しない場合は、値 "JWK" を使用する。
これは、たとえば認証なし暗号化アルゴリズムの場合に該当し得る。
指定専門家の承認を得て、他の値を使用してもよい。
JOSE 実装要件:
JWS および JWE のアルゴリズム実装要件であり、
必須、推奨、任意、非推奨、禁止のいずれかの語でなければならない。
必要に応じて、その語の後に "+" または
"-" を付けることができる。"+" の使用は、
将来の仕様バージョンで要件の強度が
引き上げられる可能性が高いことを示す。
"-" の使用は、将来の仕様バージョンで要件の強度が
引き下げられる可能性が高いことを示す。
認証なし暗号化アルゴリズム、または JWS や JWE
アルゴリズムとして直接使用することが不適切なその他のアルゴリズムとして
登録される識別子は、"禁止" として登録しなければならない。
変更管理者:
標準化過程 RFC の場合は "IESG" を記載する。それ以外の場合は、
責任を負う当事者の名前を記載する。その他の詳細
(例: 郵便住所、電子メールアドレス、ホームページ URI) を
含めてもよい。
Jones 標準化過程 [34ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
仕様文書:
パラメーターを規定する文書への参照。文書のコピーを取得するために
使用できる URI を含めることが望ましい。
関連するセクションを示してもよいが、必須ではない。
アルゴリズム分析文書:
登録するアルゴリズムの暗号学的健全性を分析した、
著名な暗号学会議、国家標準化機関、
またはその他の権威ある情報源による刊行物への参照。
アルゴリズムが非推奨または禁止として登録される場合を除き、
指定専門家は、新しいアルゴリズムの暗号学的健全性について
説得力のある証拠を登録要求とともに提供することを
要求してもよい。ワーキンググループおよび IETF のレビューを
経ているため、この文書による初期登録については、
この情報を提供する必要はない。
7.1.2. 初期レジストリ内容
o アルゴリズム名: "HS256"
o アルゴリズムの説明: SHA-256 を使用する HMAC
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 必須
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 3.2
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "HS384"
o アルゴリズムの説明: SHA-384 を使用する HMAC
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 3.2
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "HS512"
o アルゴリズムの説明: SHA-512 を使用する HMAC
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 3.2
o アルゴリズム分析文書: 該当なし
Jones 標準化過程 [35ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
o アルゴリズム名: "RS256"
o アルゴリズムの説明: SHA-256 を使用する RSASSA-PKCS1-v1_5
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 推奨
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 3.3
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "RS384"
o アルゴリズムの説明: SHA-384 を使用する RSASSA-PKCS1-v1_5
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 3.3
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "RS512"
o アルゴリズムの説明: SHA-512 を使用する RSASSA-PKCS1-v1_5
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 3.3
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "ES256"
o アルゴリズムの説明: P-256 と SHA-256 を使用する ECDSA
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 推奨+
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 3.4
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "ES384"
o アルゴリズムの説明: P-384 と SHA-384 を使用する ECDSA
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 3.4
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "ES512"
o アルゴリズムの説明: P-521 と SHA-512 を使用する ECDSA
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 3.4
o アルゴリズム分析文書: 該当なし
Jones 標準化過程 [36ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
o アルゴリズム名: "PS256"
o アルゴリズムの説明: SHA-256 および SHA-256 を使用する MGF1 による
RSASSA-PSS
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 3.5
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "PS384"
o アルゴリズムの説明: SHA-384 および SHA-384 を使用する MGF1 による
RSASSA-PSS
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 3.5
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "PS512"
o アルゴリズムの説明: SHA-512 および SHA-512 を使用する MGF1 による
RSASSA-PSS
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 3.5
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "none"
o アルゴリズムの説明: デジタル署名または MAC を実行しない
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 3.6
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "RSA1_5"
o アルゴリズムの説明: RSAES-PKCS1-v1_5
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 推奨-
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.2
o アルゴリズム分析文書: 該当なし
Jones 標準化過程 [37ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
o アルゴリズム名: "RSA-OAEP"
o アルゴリズムの説明: 既定のパラメーターを使用する RSAES OAEP
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 推奨+
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.3
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "RSA-OAEP-256"
o アルゴリズムの説明: SHA-256 および SHA-256 を使用する MGF1 による
RSAES OAEP
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.3
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "A128KW"
o アルゴリズムの説明: 128 ビット鍵を使用する AES Key Wrap
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 推奨
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.4
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "A192KW"
o アルゴリズムの説明: 192 ビット鍵を使用する AES Key Wrap
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.4
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "A256KW"
o アルゴリズムの説明: 256 ビット鍵を使用する AES Key Wrap
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 推奨
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.4
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "dir"
o アルゴリズムの説明: 共有対称鍵の直接使用
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 推奨
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.5
o アルゴリズム分析文書: 該当なし
Jones 標準化過程 [38ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
o アルゴリズム名: "ECDH-ES"
o アルゴリズムの説明: Concat KDF を使用する ECDH-ES
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 推奨+
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.6
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "ECDH-ES+A128KW"
o アルゴリズムの説明: Concat KDF と "A128KW"
ラッピングを使用する ECDH-ES
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 推奨
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.6
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "ECDH-ES+A192KW"
o アルゴリズムの説明: Concat KDF と "A192KW"
ラッピングを使用する ECDH-ES
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.6
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "ECDH-ES+A256KW"
o アルゴリズムの説明: Concat KDF と "A256KW"
ラッピングを使用する ECDH-ES
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 推奨
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.6
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "A128GCMKW"
o アルゴリズムの説明: 128 ビット鍵を使用する AES GCM による鍵ラッピング
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.7
o アルゴリズム分析文書: 該当なし
Jones 標準化過程 [39ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
o アルゴリズム名: "A192GCMKW"
o アルゴリズムの説明: 192 ビット鍵を使用する AES GCM による鍵ラッピング
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.7
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "A256GCMKW"
o アルゴリズムの説明: 256 ビット鍵を使用する AES GCM による鍵ラッピング
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.7
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "PBES2-HS256+A128KW"
o アルゴリズムの説明: HMAC SHA-256 と "A128KW"
ラッピングを使用する PBES2
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.8
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "PBES2-HS384+A192KW"
o アルゴリズムの説明: HMAC SHA-384 と "A192KW"
ラッピングを使用する PBES2
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.8
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "PBES2-HS512+A256KW"
o アルゴリズムの説明: HMAC SHA-512 と "A256KW"
ラッピングを使用する PBES2
o アルゴリズムの使用箇所: "alg"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.8
o アルゴリズム分析文書: 該当なし
Jones 標準化過程 [40ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
o アルゴリズム名: "A128CBC-HS256"
o アルゴリズムの説明: AES_128_CBC_HMAC_SHA_256 認証付き
暗号化アルゴリズム
o アルゴリズムの使用箇所: "enc"
o JOSE 実装要件: 必須
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 5.2.3
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "A192CBC-HS384"
o アルゴリズムの説明: AES_192_CBC_HMAC_SHA_384 認証付き
暗号化アルゴリズム
o アルゴリズムの使用箇所: "enc"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 5.2.4
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "A256CBC-HS512"
o アルゴリズムの説明: AES_256_CBC_HMAC_SHA_512 認証付き
暗号化アルゴリズム
o アルゴリズムの使用箇所: "enc"
o JOSE 実装要件: 必須
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 5.2.5
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "A128GCM"
o アルゴリズムの説明: 128 ビット鍵を使用する AES GCM
o アルゴリズムの使用箇所: "enc"
o JOSE 実装要件: 推奨
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 5.3
o アルゴリズム分析文書: 該当なし
o アルゴリズム名: "A192GCM"
o アルゴリズムの説明: 192 ビット鍵を使用する AES GCM
o アルゴリズムの使用箇所: "enc"
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 5.3
o アルゴリズム分析文書: 該当なし
Jones 標準化過程 [41ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
o アルゴリズム名: "A256GCM"
o アルゴリズムの説明: 256 ビット鍵を使用する AES GCM
o アルゴリズムの使用箇所: "enc"
o JOSE 実装要件: 推奨
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 5.3
o アルゴリズム分析文書: 該当なし
7.2. ヘッダーパラメーター名の登録
このセクションでは、この仕様のセクション
4.6.1、4.7.1、および 4.8.1 で定義されたヘッダーパラメーター名を、
[JWS] によって確立された IANA "JSON Web
Signature and Encryption Header Parameters" レジストリに登録する。
7.2.1. レジストリ内容
o ヘッダーパラメーター名: "epk"
o ヘッダーパラメーターの説明: 一時公開鍵
o ヘッダーパラメーターの使用箇所: JWE
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.6.1.1
o ヘッダーパラメーター名: "apu"
o ヘッダーパラメーターの説明: Agreement PartyUInfo
o ヘッダーパラメーターの使用箇所: JWE
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.6.1.2
o ヘッダーパラメーター名: "apv"
o ヘッダーパラメーターの説明: Agreement PartyVInfo
o ヘッダーパラメーターの使用箇所: JWE
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.6.1.3
o ヘッダーパラメーター名: "iv"
o ヘッダーパラメーターの説明: 初期化ベクトル
o ヘッダーパラメーターの使用箇所: JWE
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.7.1.1
o ヘッダーパラメーター名: "tag"
o ヘッダーパラメーターの説明: 認証タグ
o ヘッダーパラメーターの使用箇所: JWE
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.7.1.2
Jones 標準化過程 [42ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
o ヘッダーパラメーター名: "p2s"
o ヘッダーパラメーターの説明: PBES2 ソルト入力
o ヘッダーパラメーターの使用箇所: JWE
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.8.1.1
o ヘッダーパラメーター名: "p2c"
o ヘッダーパラメーターの説明: PBES2 回数
o ヘッダーパラメーターの使用箇所: JWE
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 4.8.1.2
7.3. JSON Web Encryption 圧縮アルゴリズムレジストリ
この仕様は、JWE の "zip" メンバー値のための IANA
"JSON Web Encryption Compression Algorithms" レジストリを確立する。
このレジストリには圧縮アルゴリズム値と、
それを定義する仕様への参照を記録する。
7.3.1. 登録テンプレート
圧縮アルゴリズム値:
要求する名前 (例: "DEF")。この仕様の主要な目標の 1 つは
結果として得られる表現をコンパクトにすることであるため、
説得力のある理由がない限り、名前は短く、
8 文字を超えないことを推奨する。この名前は
大文字と小文字を区別する。指定専門家が例外を許可する
説得力のある理由があると判断しない限り、大文字と小文字を区別しない比較で
他の登録済みの名前と一致してはならない。
圧縮アルゴリズムの説明:
圧縮アルゴリズムの簡単な説明 (例: "DEFLATE")。
変更管理者:
標準化過程 RFC の場合は "IESG" を記載する。それ以外の場合は、
責任を負う当事者の名前を記載する。その他の詳細
(例: 郵便住所、電子メールアドレス、ホームページ URI) を
含めてもよい。
仕様文書:
パラメーターを規定する文書への参照。文書のコピーを取得するために
使用できる URI を含めることが望ましい。
関連するセクションを示してもよいが、必須ではない。
Jones 標準化過程 [43ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
7.3.2. 初期レジストリ内容
o 圧縮アルゴリズム値: "DEF"
o 圧縮アルゴリズムの説明: DEFLATE
o 変更管理者: IESG
o 仕様文書: JSON Web Encryption (JWE) [JWE]
7.4. JSON Web Key タイプレジストリ
この仕様は、JWK の "kty" (鍵タイプ) パラメーター値のための
IANA "JSON Web Key Types" レジストリを確立する。
このレジストリには "kty" 値、実装要件、
およびそれを定義する仕様への参照を記録する。
暗号技術を取り巻く状況の変化に伴い、鍵タイプの実装要件は
時間の経過とともに変更されることがある。たとえば、鍵タイプの
状態を非推奨に変更したり、鍵タイプの状態を
任意から推奨+または必須に変更したりする場合である。
実装要件の変更は、指定専門家によるレビューの後、
改訂された実装要件レベルを定義する新しい仕様に基づき、
仕様必須の手続きによってのみ許可される。
7.4.1. 登録テンプレート
"kty" パラメーター値:
要求する名前 (例: "EC")。この仕様の主要な目標の 1 つは
結果として得られる表現をコンパクトにすることであるため、
説得力のある理由がない限り、名前は短く、
8 文字を超えないことを推奨する。この名前は
大文字と小文字を区別する。指定専門家が例外を許可する
説得力のある理由があると判断しない限り、大文字と小文字を区別しない比較で
他の登録済みの名前と一致してはならない。
鍵タイプの説明:
鍵タイプの簡単な説明 (例: "楕円曲線")。
変更管理者:
標準化過程 RFC の場合は "IESG" を記載する。それ以外の場合は、
責任を負う当事者の名前を記載する。その他の詳細
(例: 郵便住所、電子メールアドレス、ホームページ URI) を
含めてもよい。
Jones 標準化過程 [44ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
JOSE 実装要件:
JWS および JWE の鍵タイプ実装要件であり、
必須、推奨、任意、非推奨、禁止のいずれかの語でなければならない。
必要に応じて、その語の後に "+" または
"-" を付けることができる。"+" の使用は、
将来の仕様バージョンで要件の強度が
引き上げられる可能性が高いことを示す。
"-" の使用は、将来の仕様バージョンで要件の強度が
引き下げられる可能性が高いことを示す。
仕様文書:
パラメーターを規定する文書への参照。文書のコピーを取得するために
使用できる URI を含めることが望ましい。
関連するセクションを示してもよいが、必須ではない。
7.4.2. 初期レジストリ内容
このセクションでは、セクション 6.1 で定義した値を登録する。
o "kty" パラメーター値: "EC"
o 鍵タイプの説明: 楕円曲線
o JOSE 実装要件: 推奨+
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 6.2
o "kty" パラメーター値: "RSA"
o 鍵タイプの説明: RSA
o JOSE 実装要件: 必須
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 6.3
o "kty" パラメーター値: "oct"
o 鍵タイプの説明: オクテットシーケンス
o JOSE 実装要件: 必須
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 6.4
7.5. JSON Web Key パラメーターの登録
このセクションでは、この仕様のセクション 6.2、
6.3、および 6.4 で定義したパラメーター名を、
[JWK] によって確立された IANA "JSON Web Key
Parameters" レジストリに登録する。
Jones 標準化過程 [45ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
7.5.1. レジストリ内容
o パラメーター名: "crv"
o パラメーターの説明: 曲線
o 使用する "kty" 値: "EC"
o パラメーター情報クラス: 公開
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 6.2.1.1
o パラメーター名: "x"
o パラメーターの説明: X 座標
o 使用する "kty" 値: "EC"
o パラメーター情報クラス: 公開
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 6.2.1.2
o パラメーター名: "y"
o パラメーターの説明: Y 座標
o 使用する "kty" 値: "EC"
o パラメーター情報クラス: 公開
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 6.2.1.3
o パラメーター名: "d"
o パラメーターの説明: ECC 秘密鍵
o 使用する "kty" 値: "EC"
o パラメーター情報クラス: 秘密
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 6.2.2.1
o パラメーター名: "n"
o パラメーターの説明: 法
o 使用する "kty" 値: "RSA"
o パラメーター情報クラス: 公開
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 6.3.1.1
o パラメーター名: "e"
o パラメーターの説明: 指数
o 使用する "kty" 値: "RSA"
o パラメーター情報クラス: 公開
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 6.3.1.2
Jones 標準化過程 [46ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
o パラメーター名: "d"
o パラメーターの説明: 秘密指数
o 使用する "kty" 値: "RSA"
o パラメーター情報クラス: 秘密
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 6.3.2.1
o パラメーター名: "p"
o パラメーターの説明: 第1素因数
o 使用する "kty" 値: "RSA"
o パラメーター情報クラス: 秘密
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 6.3.2.2
o パラメーター名: "q"
o パラメーターの説明: 第2素因数
o 使用する "kty" 値: "RSA"
o パラメーター情報クラス: 秘密
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 6.3.2.3
o パラメーター名: "dp"
o パラメーターの説明: 第1因数 CRT 指数
o 使用する "kty" 値: "RSA"
o パラメーター情報クラス: 秘密
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 6.3.2.4
o パラメーター名: "dq"
o パラメーターの説明: 第2因数 CRT 指数
o 使用する "kty" 値: "RSA"
o パラメーター情報クラス: 秘密
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 6.3.2.5
o パラメーター名: "qi"
o パラメーターの説明: 第1 CRT 係数
o 使用する "kty" 値: "RSA"
o パラメーター情報クラス: 秘密
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 6.3.2.6
Jones 標準化過程 [47ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
o パラメーター名: "oth"
o パラメーターの説明: その他の素数情報
o 使用する "kty" 値: "RSA"
o パラメーター情報クラス: 秘密
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 6.3.2.7
o パラメーター名: "k"
o パラメーターの説明: 鍵値
o 使用する "kty" 値: "oct"
o パラメーター情報クラス: 秘密
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 6.4.1
7.6. JSON Web Key 楕円曲線レジストリ
このセクションでは、JWK の "crv" メンバー値のための
IANA "JSON Web Key Elliptic Curve" レジストリを確立する。
このレジストリには、曲線名、実装要件、および
それを定義する仕様への参照を記録する。この仕様は、
セクション 6.2.1.1 で定義したパラメーター名を登録する。
暗号技術を取り巻く状況の変化に伴い、曲線の実装要件は
時間の経過とともに変更されることがある。たとえば、曲線の
状態を非推奨に変更したり、曲線の状態を
任意から推奨+または必須に変更したりする場合である。
実装要件の変更は、指定専門家によるレビューの後、
改訂された実装要件レベルを定義する新しい仕様に基づき、
仕様必須の手続きによってのみ許可される。
7.6.1. 登録テンプレート
曲線名:
要求する名前 (例: "P-256")。この仕様の主要な目標の 1 つは
結果として得られる表現をコンパクトにすることであるため、
説得力のある理由がない限り、名前は短く、
8 文字を超えないことを推奨する。この名前は
大文字と小文字を区別する。指定専門家が例外を許可する
説得力のある理由があると判断しない限り、大文字と小文字を区別しない比較で
他の登録済みの名前と一致してはならない。
曲線の説明:
曲線の簡単な説明 (例: "P-256 曲線")。
JOSE 実装要件:
JWS および JWE の曲線実装要件であり、
必須、推奨、任意、非推奨、禁止のいずれかの語でなければならない。
必要に応じて、その語の後に "+" または "-" を付けることができる。
Jones 標準化過程 [48ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
"+" の使用は、将来の仕様バージョンで要件の強度が
引き上げられる可能性が高いことを示す。
"-" の使用は、将来の仕様バージョンで要件の強度が
引き下げられる可能性が高いことを示す。
変更管理者:
標準化過程 RFC の場合は "IESG" を記載する。それ以外の場合は、
責任を負う当事者の名前を記載する。その他の詳細
(例: 郵便住所、電子メールアドレス、ホームページ URI) を
含めてもよい。
仕様文書:
パラメーターを規定する文書への参照。文書のコピーを取得するために
使用できる URI を含めることが望ましい。
関連するセクションを示してもよいが、必須ではない。
7.6.2. 初期レジストリ内容
o 曲線名: "P-256"
o 曲線の説明: P-256 曲線
o JOSE 実装要件: 推奨+
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 6.2.1.1
o 曲線名: "P-384"
o 曲線の説明: P-384 曲線
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 6.2.1.1
o 曲線名: "P-521"
o 曲線の説明: P-521 曲線
o JOSE 実装要件: 任意
o 変更管理者: IESG
o 仕様文書: RFC 7518 のセクション 6.2.1.1
8. セキュリティに関する考慮事項
暗号アプリケーションに関連するすべてのセキュリティ問題は、
JWS/JWE/JWK エージェントによって対処されなければならない。
これらの問題には、ユーザーの非対称秘密鍵および対称秘密鍵の保護や、
さまざまな攻撃に対する対策の採用が含まれる。
[AES]、[DSS]、[JWE]、[JWK]、[JWS]、
[NIST.800-38D]、[NIST.800-56A]、[NIST.800-107]、[RFC2104]、[RFC3394]、
[RFC3447]、[RFC5116]、[RFC6090]、および [SHS] の
セキュリティに関する考慮事項が、この仕様に適用される。
Jones 標準化過程 [49ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
8.1. 暗号アジリティ
実装者は、暗号アルゴリズムが時間の経過とともに
弱くなることを認識すべきである。新しい暗号解析技法が開発され、
計算性能が向上するにつれて、特定の暗号アルゴリズムを破るために
必要な作業量は減少する。そのため、実装者および配備環境は、
サポートおよび使用するアルゴリズムの集合が
時間の経過とともに変化することに備えなければならない。
したがって、暗号アルゴリズムの実装はモジュール式とし、
新しいアルゴリズムを容易に追加できるようにすべきである。
8.2. 鍵の有効期間
多くのアルゴリズムには、鍵の有効期間や、
鍵を使用できる回数に関連するセキュリティ上の考慮事項がある。
これらのセキュリティ上の考慮事項は、JOSE データ構造で
それらのアルゴリズムを使用する場合にも引き続き適用される。
鍵の有効期間に関する具体的なガイダンスについては、NIST SP 800-57
[NIST.800-57] を参照すること。
8.3. RSAES-PKCS1-v1_5 のセキュリティに関する考慮事項
RFC 3447 のセクション 8 [RFC3447] では、
新しいアプリケーションに RSASSA-PKCS1-v1_5 を採用せず、
代わりに RSASSA-PSS へ移行することを明示的に求めているが、
RSASSA-PKCS1-v1_5 は広く実装されているため、
相互運用性上の理由からこの仕様には含まれている。
RSAES-PKCS1-v1_5 で使用する鍵は、
RFC 3447 のセクション 7.2 の制約に従わなければならない。
また、"Twenty Years of Attacks on the
RSA Cryptosystem" [Boneh99] の セクション 3 で説明されているような、
公開鍵指数値が小さい鍵を使用してはならない。
8.4. AES GCM のセキュリティに関する考慮事項
AES GCM で使用する鍵は、[NIST.800-38D] のセクション 8.3 の
制約に従わなければならない。そこでは、
「指定された鍵について、すべての IV 長および認証付き暗号化関数の
すべてのインスタンスを含め、認証付き暗号化関数の総呼び出し回数は
2^32 を超えてはならない」とされている。この規則に従い、
AES GCM は同じ鍵値で 2^32 回を超えて使用してはならない。
IV 値は、同じ AES
GCM 鍵で複数回使用してはならない。これを防ぐ方法の 1 つは、
鍵とともにカウンターを保存し、使用するたびに
インクリメントすることである。このカウンターは、
上記の 2^32 の制限を超えることを防ぐためにも使用できる。
このセキュリティ上の考慮事項は、複合 AES-CBC
HMAC SHA-2 または AES Key Wrap アルゴリズムには適用されない。
Jones 標準化過程 [50ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
8.5. セキュリティ保護されていない JWS に関する考慮事項
セキュリティ保護されていない JWS ("alg" 値 "none" を使用する JWS) は、
完全性保護を提供しない。したがって、ペイロードが
デジタル署名または MAC 値以外の手段によって保護されている場合、
または保護する必要がない場合にのみ使用しなければならない。
セキュリティ保護されていない JWS を既定で受け入れることを防ぐ方法の例として、
仮想的な JWS ソフトウェアライブラリの "verify" メソッドに、
"none" が許容可能な "alg" 値であることを示す
Boolean 型の "acceptUnsecured" パラメーターを持たせる方法がある。
別の例として、"verify" メソッドが、
アプリケーションに許容されるアルゴリズムのリストを
パラメーターとして受け取り、そのリストに "none" が含まれていなければ
セキュリティ保護されていない JWS 値を拒否する方法もある。
次の例は、セキュリティ保護されていない JWS を
グローバルレベルで受け入れない理由を示す。
あるアプリケーションが、(1) HTTP と (2) クライアント
認証付き HTTPS の 2 つのチャネルで JWS を受け入れるとする。
HTTP 経由で受信したオブジェクトには JWS Signature を要求するが、
HTTPS 経由ではセキュリティ保護されていない JWS を受け入れる。
アプリケーションが "none" を許容するとグローバルに指定した場合、
攻撃者は HTTP 経由でセキュリティ保護されていない JWS を提供し、
そのオブジェクトを正常に検証させることができる。
代わりに、アプリケーションは HTTPS 経由で受信する各オブジェクトについて
"none" の受け入れを指定する必要がある
(例: 上記の最初の仮想的な JWS ソフトウェアライブラリで
"acceptUnsecured" を "true" に設定する) が、
HTTP 経由で受信する各オブジェクトについては指定してはならない。
8.6. サービス拒否攻撃
署名を検証する受信エージェントおよびメッセージを暗号化する送信エージェントは、
この仕様で義務付けられているより大きな鍵を使用して
署名の検証やメッセージの暗号化を行う際の暗号処理の使用量に
注意する必要がある。攻撃者は、たとえばこの仕様で義務付けられたものより
大きな鍵など、過大な暗号処理を引き起こす鍵を使用する
コンテンツを提供する可能性がある。実装は、受け入れる
鍵サイズに上限を設定し、それを強制すべきである。NIST SP 800-57
[NIST.800-57] の セクション 5.6.1
(同等のアルゴリズム強度) には、適用可能な
承認済み最大鍵サイズに関する記述がある。
8.7. 鍵暗号化時の鍵素材の再利用
複数の JWK または JWK Set オブジェクトを暗号化したり、
同じ JWK または JWK Set オブジェクトを複数回暗号化したりするために、
同じ鍵素材一式
(Key Encryption Key、Content Encryption Key、Initialization Vector
など) を再利用することは推奨されない。その再利用を
Jones 標準化過程 [51ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
防ぐ方法の 1 つは、この文書および RFC 4086
[RFC4086] に記載された考慮事項に基づき、
各暗号化操作ごとに少なくとも 1 つの新しい鍵素材
(例: 新しい Content Encryption Key、新しい IV、
および/または新しい PBES2 Salt) を必ず生成することである。
8.8. パスワードに関する考慮事項
パスワードは多くの攻撃に対して脆弱である。
これらの制約の一部を軽減するため、この文書では、
ユーザーが提供したパスワードから暗号鍵を導出するために
RFC
2898 [RFC2898] の原則を適用する。
ただし、パスワードの強度は依然として大きな影響を及ぼす。
高エントロピーのパスワードは辞書攻撃に対する耐性が高い。
[NIST.800-63-2] にはパスワードエントロピーを推定するためのガイドラインがあり、
アプリケーションとユーザーがより強いパスワードを生成する際に役立つ。
理想的なパスワードは、導出鍵の長さと同じ
(またはそれ以上) の長さを持つものである。ただし、特定の
アルゴリズム固有サイズより大きなパスワードは最初にハッシュされるため、
攻撃者の実効的な探索空間はハッシュアルゴリズムの長さまで縮小される。
"PBES2-HS256+A128KW" に使用するパスワードは
16 オクテット以上 128 オクテット以下とし、
"PBES2-HS512+A256KW" に使用するパスワードは
32 オクテット以上 128 オクテット以下とすることを推奨する。
それでも、パスワードベース暗号化をどこでどのように
使用するかには注意が必要である。反復回数が少なすぎる場合、
これらのアルゴリズムは依然として辞書ベースの攻撃を受ける可能性がある。
ファイルシステムに保存された保護対象データのように、
攻撃者が保護の突破を無制限に試行できるデータを
これらのアルゴリズムで保護する場合は、特に問題となる。
8.9. 鍵エントロピーとランダム値
鍵エントロピーおよびランダム値に関するセキュリティ上の考慮事項については、
[JWS] のセクション 10.1 を参照すること。
8.10. デジタル署名と MAC の違い
デジタル署名と MAC の違いに関するセキュリティ上の考慮事項については、
[JWS] のセクション 10.5 を参照すること。
Jones 標準化過程 [52ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
8.11. 強度が一致するアルゴリズムの使用
強度が一致するアルゴリズムの使用に関するセキュリティ上の考慮事項については、
[JWE] のセクション 11.3 を参照すること。
8.12. 適応的選択暗号文攻撃
適応的選択暗号文攻撃に関するセキュリティ上の考慮事項については、
[JWE] のセクション 11.4 を参照すること。
8.13. タイミング攻撃
タイミング攻撃に関するセキュリティ上の考慮事項については、
[JWS] のセクション 10.9 および
[JWE] の セクション 11.5 を参照すること。
8.14. RSA 秘密鍵の表現とブラインディング
RSA 秘密鍵の表現とブラインディングに関するセキュリティ上の考慮事項については、
[JWK] のセクション 9.3 を参照すること。
9. 国際化に関する考慮事項
ユーザーから取得したパスワードは、異なる入力デバイスやロケールなどによって
生成されるオクテットシーケンスの違いを考慮するため、
準備および正規化を必要とする可能性が高い。
アプリケーションは、ユーザーから直接提供されたパスワードについて、
鍵導出および暗号化を実行する前に、
[PRECIS] で示されている手順を実行することを推奨する。
10. 参考文献
10.1. 規範的参考文献
[AES] 米国国立標準技術研究所 (NIST),
"Advanced Encryption Standard (AES)", FIPS PUB 197,
2001年11月, <http://csrc.nist.gov/publications/
fips/fips197/fips-197.pdf>.
[Boneh99] "RSA 暗号システムに対する 20 年間の攻撃", Notices
of the American Mathematical Society (AMS), Vol. 46,
No. 2, pp. 203-213, 1999, <http://crypto.stanford.edu/
~dabo/pubs/papers/RSA-survey.pdf>.
Jones 標準化過程 [53ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
[DSS] 米国国立標準技術研究所 (NIST),
"デジタル署名標準 (DSS)", FIPS PUB 186-4, 2013年7月,
<http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>.
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, 2015年5月,
<http://www.rfc-editor.org/info/rfc7516>.
[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>.
[NIST.800-38A]
米国国立標準技術研究所 (NIST),
"ブロック暗号の動作モードに関する推奨事項", NIST
Special Publication 800-38A, 2001年12月,
<http://csrc.nist.gov/publications/nistpubs/800-38a/
sp800-38a.pdf>.
[NIST.800-38D]
米国国立標準技術研究所 (NIST),
"ブロック暗号の動作モードに関する推奨事項:
Galois/Counter Mode (GCM) および GMAC", NIST Special
Publication 800-38D, 2001年12月,
<http://csrc.nist.gov/publications/nistpubs/800-38D/
SP-800-38D.pdf>.
[NIST.800-56A]
米国国立標準技術研究所 (NIST),
"離散対数暗号を使用するペア単位の鍵確立方式に関する推奨事項",
NIST Special Publication 800-56A, Revision 2, 2013年5月,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Ar2.pdf>.
[NIST.800-57]
米国国立標準技術研究所 (NIST),
"鍵管理に関する推奨事項 - パート 1: 一般
(改訂 3)", NIST Special Publication 800-57, Part 1,
Revision 3, 2012年7月, <http://csrc.nist.gov/publications/
nistpubs/800-57/sp800-57_part1_rev3_general.pdf>.
Jones 標準化過程 [54ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
[RFC20] Cerf, V., "ネットワーク交換用 ASCII 形式", STD 80,
RFC 20, DOI 10.17487/RFC0020, 1969年10月,
<http://www.rfc-editor.org/info/rfc20>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
メッセージ認証のための鍵付きハッシュ", RFC 2104,
DOI 10.17487/RFC2104, 1997年2月,
<http://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "RFC で要求レベルを示すために使用する
キーワード", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, 1997年3月,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2898] Kaliski, B., "PKCS #5: パスワードベース暗号
仕様バージョン 2.0", RFC 2898,
DOI 10.17487/RFC2898, 2000年9月,
<http://www.rfc-editor.org/info/rfc2898>.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
2002年9月, <http://www.rfc-editor.org/info/rfc3394>.
[RFC3447] Jonsson, J. and B. Kaliski, "公開鍵暗号
標準 (PKCS) #1: RSA 暗号仕様
バージョン 2.1", RFC 3447, DOI 10.17487/RFC3447, 2003年2月,
<http://www.rfc-editor.org/info/rfc3447>.
[RFC3629] Yergeau, F., "UTF-8、ISO
10646 の変換形式", STD 63, RFC 3629, DOI 10.17487/RFC3629, 2003年11月,
<http://www.rfc-editor.org/info/rfc3629>.
[RFC4868] Kelly, S. and S. Frankel, "IPsec での HMAC-SHA-256、
HMAC-SHA-384、および HMAC-SHA-512 の使用", RFC 4868,
DOI 10.17487/RFC4868, 2007年5月,
<http://www.rfc-editor.org/info/rfc4868>.
[RFC4949] Shirey, R., "インターネットセキュリティ用語集、バージョン 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, 2007年8月,
<http://www.rfc-editor.org/info/rfc4949>.
[RFC5652] Housley, R., "暗号メッセージ構文 (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, 2009年9月,
<http://www.rfc-editor.org/info/rfc5652>.
Jones 標準化過程 [55ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "基本的な楕円曲線
暗号アルゴリズム", RFC 6090,
DOI 10.17487/RFC6090, 2011年2月,
<http://www.rfc-editor.org/info/rfc6090>.
[RFC7159] Bray, T., Ed., "JavaScript Object Notation (JSON) データ
交換形式", RFC 7159, DOI 10.17487/RFC7159, 2014年3月,
<http://www.rfc-editor.org/info/rfc7159>.
[SEC1] Standards for Efficient Cryptography Group, "SEC 1:
楕円曲線暗号", Version 2.0, 2009年5月,
<http://www.secg.org/sec1-v2.pdf>.
[SHS] 米国国立標準技術研究所 (NIST),
"セキュアハッシュ標準 (SHS)", FIPS PUB 180-4, 2012年3月,
<http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>.
[UNICODE] The Unicode Consortium, "Unicode 標準",
<http://www.unicode.org/versions/latest/>.
10.2. 参考情報
[AEAD-CBC-SHA]
McGrew, D., Foley, J., and K. Paterson, "AES-CBC と
HMAC-SHA による認証付き暗号化", 作業中,
draft-mcgrew-aead-aes-cbc-hmac-sha2-05, 2014年7月.
[CanvasApp]
Facebook, "Canvas アプリケーション", 2010,
<http://developers.facebook.com/docs/authentication/
canvas>.
[JCA] Oracle, "Java Cryptography Architecture (JCA) リファレンス
ガイド", 2014, <http://docs.oracle.com/javase/8/docs/techno
tes/guides/security/crypto/CryptoSpec.html>.
[JSE] Bradley, J. and N. Sakimura (editor), "JSON Simple
Encryption", 2010年9月,
<http://jsonenc.info/enc/1.0/>.
[JSMS] Rescorla, E. and J. Hildebrand, "JavaScript メッセージ
セキュリティ形式", 作業中,
draft-rescorla-jsms-00, 2011年3月.
[JSS] Bradley, J. and N. Sakimura, Ed., "JSON Simple Sign 1.0",
Draft 01, 2010年9月, <http://jsonenc.info/jss/1.0/>.
Jones 標準化過程 [56ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
[JWE-JWK] Miller, M., "JSON Web Key (JWK)
オブジェクトを保護するための JavaScript Object Notation (JSON) Web
Encryption (JWE) の使用", 作業中,
draft-miller-jose-jwe-protected-jwk-02, 2013年6月.
[MagicSignatures]
Panzer, J., Ed., Laurie, B., and D. Balfanz, "Magic
Signatures", 2011年1月,
<http://salmon-protocol.googlecode.com/svn/trunk/
draft-panzer-magicsig-01.html>.
[NIST.800-107]
米国国立標準技術研究所 (NIST),
"承認済みハッシュアルゴリズムを使用するアプリケーションに関する推奨事項",
NIST Special Publication 800-107, Revision 1,
2012年8月, <http://csrc.nist.gov/publications/
nistpubs/800-107-rev1/sp800-107-rev1.pdf>.
[NIST.800-63-2]
米国国立標準技術研究所 (NIST),
"電子認証ガイドライン", NIST Special
Publication 800-63-2, 2013年8月,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-63-2.pdf>.
[PRECIS] Saint-Andre, P. and A. Melnikov, "ユーザー名とパスワードを
表す国際化文字列の準備、強制、および比較", 作業中,
draft-ietf-precis-saslprepbis-16, 2015年4月.
[RFC2631] Rescorla, E., "Diffie-Hellman 鍵合意方式",
RFC 2631, DOI 10.17487/RFC2631, 1999年6月,
<http://www.rfc-editor.org/info/rfc2631>.
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible
Markup Language) XML 署名の構文と処理",
RFC 3275, DOI 10.17487/RFC3275, 2002年3月,
<http://www.rfc-editor.org/info/rfc3275>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"セキュリティのためのランダム性要件", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, 2005年6月,
<http://www.rfc-editor.org/info/rfc4086>.
[RFC5116] McGrew, D., "認証付き暗号化のインターフェイスとアルゴリズム",
RFC 5116, DOI 10.17487/RFC5116, 2008年1月,
<http://www.rfc-editor.org/info/rfc5116>.
Jones 標準化過程 [57ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
[RFC5226] Narten, T. and H. Alvestrand, "RFC の
IANA に関する考慮事項セクションを記述するためのガイドライン", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, 2008年5月,
<http://www.rfc-editor.org/info/rfc5226>.
[W3C.NOTE-xmldsig-core2-20130411]
Eastlake, D., Reagle, J., Solo, D., Hirsch, F., Roessler,
T., Yiu, K., Datta, P., and S. Cantor, "XML 署名の
構文と処理バージョン 2.0", World Wide Web
Consortium Note NOTE-xmldsig-core2-20130411, 2013年4月,
<http://www.w3.org/TR/2013/NOTE-xmldsig-core2-20130411/>.
[W3C.REC-xmlenc-core-20021210]
Eastlake, D. and J. Reagle, "XML 暗号化の構文と
処理", World Wide Web Consortium Recommendation REC-
xmlenc-core-20021210, 2002年12月,
<http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>.
[W3C.REC-xmlenc-core1-20130411]
Eastlake, D., Reagle, J., Hirsch, F., and T. Roessler,
"XML 暗号化の構文と処理バージョン 1.1", World
Wide Web Consortium Recommendation REC-xmlenc-
core1-20130411, 2013年4月,
<http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/>.
Jones 標準化過程 [58ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
付録 A. アルゴリズム識別子相互参照
この付録には、この仕様で定義される暗号アルゴリズム識別子値と、
他の標準およびソフトウェアパッケージで使用される
同等の識別子との相互参照表を示す。
これらの文書で定義される名前の詳細については、
XML DSIG [RFC3275]、XML DSIG 2.0
[W3C.NOTE-xmldsig-core2-20130411]、XML Encryption
[W3C.REC-xmlenc-core-20021210]、XML Encryption 1.1
[W3C.REC-xmlenc-core1-20130411]、および Java Cryptography Architecture
[JCA] を参照すること。
Jones 標準化過程 [59ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
A.1. デジタル署名/MAC アルゴリズム識別子相互参照
このセクションには、この仕様で定義する JWS デジタル
署名および MAC の "alg" (アルゴリズム) 値と、
他の標準およびソフトウェアパッケージで使用される
同等の識別子との相互参照表を示す。
+-------------------------------------------------------------------+
| JWS | XML DSIG |
| | JCA | OID |
+-------------------------------------------------------------------+
| HS256 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 |
| | HmacSHA256 | 1.2.840.113549.2.9 |
+-------------------------------------------------------------------+
| HS384 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha384 |
| | HmacSHA384 | 1.2.840.113549.2.10 |
+-------------------------------------------------------------------+
| HS512 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha512 |
| | HmacSHA512 | 1.2.840.113549.2.11 |
+-------------------------------------------------------------------+
| RS256 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 |
| | SHA256withRSA | 1.2.840.113549.1.1.11 |
+-------------------------------------------------------------------+
| RS384 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha384 |
| | SHA384withRSA | 1.2.840.113549.1.1.12 |
+-------------------------------------------------------------------+
| RS512 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 |
| | SHA512withRSA | 1.2.840.113549.1.1.13 |
+-------------------------------------------------------------------+
| ES256 | http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256 |
| | SHA256withECDSA | 1.2.840.10045.4.3.2 |
+-------------------------------------------------------------------+
| ES384 | http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384 |
| | SHA384withECDSA | 1.2.840.10045.4.3.3 |
+-------------------------------------------------------------------+
| ES512 | http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512 |
| | SHA512withECDSA | 1.2.840.10045.4.3.4 |
+-------------------------------------------------------------------+
| PS256 | http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1 |
| | SHA256withRSAandMGF1 | 1.2.840.113549.1.1.10 |
+-------------------------------------------------------------------+
| PS384 | http://www.w3.org/2007/05/xmldsig-more#sha384-rsa-MGF1 |
| | SHA384withRSAandMGF1 | 1.2.840.113549.1.1.10 |
+-------------------------------------------------------------------+
| PS512 | http://www.w3.org/2007/05/xmldsig-more#sha512-rsa-MGF1 |
| | SHA512withRSAandMGF1 | 1.2.840.113549.1.1.10 |
+-------------------------------------------------------------------+
Jones 標準化過程 [60ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
A.2. 鍵管理アルゴリズム識別子相互参照
このセクションには、この仕様で定義する JWE "alg"
(アルゴリズム) 値と、他の標準およびソフトウェアパッケージで
使用される同等の識別子との相互参照表を示す。
+-------------------------------------------------------------------+
| JWE | XML ENC |
| | JCA | OID |
+-------------------------------------------------------------------+
| RSA1_5 | http://www.w3.org/2001/04/xmlenc#rsa-1_5 |
| | RSA/ECB/PKCS1Padding | 1.2.840.113549.1.1.1 |
+-------------------------------------------------------------------+
| RSA-OAEP | http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p |
| | RSA/ECB/OAEPWithSHA-1AndMGF1Padding | 1.2.840.113549.1.1.7 |
+-------------------------------------------------------------------+
| RSA-OAEP-256 | http://www.w3.org/2009/xmlenc11#rsa-oaep |
| | & http://www.w3.org/2009/xmlenc11#mgf1sha256 |
| | RSA/ECB/OAEPWithSHA-256AndMGF1Padding | |
| | & MGF1ParameterSpec.SHA256 | 1.2.840.113549.1.1.7 |
+-------------------------------------------------------------------+
| ECDH-ES | http://www.w3.org/2009/xmlenc11#ECDH-ES |
| | ECDH | 1.3.132.1.12 |
+-------------------------------------------------------------------+
| A128KW | http://www.w3.org/2001/04/xmlenc#kw-aes128 |
| | AESWrap | 2.16.840.1.101.3.4.1.5 |
+-------------------------------------------------------------------+
| A192KW | http://www.w3.org/2001/04/xmlenc#kw-aes192 |
| | AESWrap | 2.16.840.1.101.3.4.1.25 |
+-------------------------------------------------------------------+
| A256KW | http://www.w3.org/2001/04/xmlenc#kw-aes256 |
| | AESWrap | 2.16.840.1.101.3.4.1.45 |
+-------------------------------------------------------------------+
Jones 標準化過程 [61ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
A.3. コンテンツ暗号化アルゴリズム識別子相互参照
このセクションには、この仕様で定義する JWE "enc"
(暗号化アルゴリズム) 値と、他の標準およびソフトウェアパッケージで
使用される同等の識別子との相互参照表を示す。
複合アルゴリズム "A128CBC-HS256"、"A192CBC-HS384"、
"A256CBC-HS512" については、対応する AES-CBC アルゴリズム識別子を
記載する。
+-------------------------------------------------------------------+
| JWE | XML ENC |
| | JCA | OID |
+-------------------------------------------------------------------+
| A128CBC-HS256 | http://www.w3.org/2001/04/xmlenc#aes128-cbc |
| | AES/CBC/PKCS5Padding | 2.16.840.1.101.3.4.1.2 |
+-------------------------------------------------------------------+
| A192CBC-HS384 | http://www.w3.org/2001/04/xmlenc#aes192-cbc |
| | AES/CBC/PKCS5Padding | 2.16.840.1.101.3.4.1.22 |
+-------------------------------------------------------------------+
| A256CBC-HS512 | http://www.w3.org/2001/04/xmlenc#aes256-cbc |
| | AES/CBC/PKCS5Padding | 2.16.840.1.101.3.4.1.42 |
+-------------------------------------------------------------------+
| A128GCM | http://www.w3.org/2009/xmlenc11#aes128-gcm |
| | AES/GCM/NoPadding | 2.16.840.1.101.3.4.1.6 |
+-------------------------------------------------------------------+
| A192GCM | http://www.w3.org/2009/xmlenc11#aes192-gcm |
| | AES/GCM/NoPadding | 2.16.840.1.101.3.4.1.26 |
+-------------------------------------------------------------------+
| A256GCM | http://www.w3.org/2009/xmlenc11#aes256-gcm |
| | AES/GCM/NoPadding | 2.16.840.1.101.3.4.1.46 |
+-------------------------------------------------------------------+
付録 B. AES_CBC_HMAC_SHA2 アルゴリズムのテストケース
次のテストケースは、セクション 5.2 で定義する
AES_CBC_HMAC_SHA2 アルゴリズムの実装を検証するために使用できる。
また、[AEAD-CBC-SHA] の将来のバージョンに現れる可能性のある
テストケースにも対応することを意図しており、
実行される暗号計算が同じであることを示す。
変数名は セクション 5.2 で定義したものである。
すべての値は 16 進数である。
Jones 標準化過程 [62ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
B.1. AES_128_CBC_HMAC_SHA_256 のテストケース
AES_128_CBC_HMAC_SHA_256
K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
ENC_KEY = 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20
6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75
69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65
74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62
65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69
6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66
20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f
75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65
IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63
69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20
4b 65 72 63 6b 68 6f 66 66 73
AL = 00 00 00 00 00 00 01 50
E = c8 0e df a3 2d df 39 d5 ef 00 c0 b4 68 83 42 79
a2 e4 6a 1b 80 49 f7 92 f7 6b fe 54 b9 03 a9 c9
a9 4a c9 b4 7a d2 65 5c 5f 10 f9 ae f7 14 27 e2
fc 6f 9b 3f 39 9a 22 14 89 f1 63 62 c7 03 23 36
09 d4 5a c6 98 64 e3 32 1c f8 29 35 ac 40 96 c8
6e 13 33 14 c5 40 19 e8 ca 79 80 df a4 b9 cf 1b
38 4c 48 6f 3a 54 c5 10 78 15 8e e5 d7 9d e5 9f
bd 34 d8 48 b3 d6 95 50 a6 76 46 34 44 27 ad e5
4b 88 51 ff b5 98 f7 f8 00 74 b9 47 3c 82 e2 db
M = 65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4
e6 e5 45 82 47 65 15 f0 ad 9f 75 a2 b7 1c 73 ef
T = 65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4
Jones 標準化過程 [63ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
B.2. AES_192_CBC_HMAC_SHA_384 のテストケース
K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17
ENC_KEY = 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27
28 29 2a 2b 2c 2d 2e 2f
P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20
6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75
69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65
74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62
65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69
6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66
20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f
75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65
IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63
69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20
4b 65 72 63 6b 68 6f 66 66 73
AL = 00 00 00 00 00 00 01 50
E = ea 65 da 6b 59 e6 1e db 41 9b e6 2d 19 71 2a e5
d3 03 ee b5 00 52 d0 df d6 69 7f 77 22 4c 8e db
00 0d 27 9b dc 14 c1 07 26 54 bd 30 94 42 30 c6
57 be d4 ca 0c 9f 4a 84 66 f2 2b 22 6d 17 46 21
4b f8 cf c2 40 0a dd 9f 51 26 e4 79 66 3f c9 0b
3b ed 78 7a 2f 0f fc bf 39 04 be 2a 64 1d 5c 21
05 bf e5 91 ba e2 3b 1d 74 49 e5 32 ee f6 0a 9a
c8 bb 6c 6b 01 d3 5d 49 78 7b cd 57 ef 48 49 27
f2 80 ad c9 1a c0 c4 e7 9c 7b 11 ef c6 00 54 e3
M = 84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20
75 16 80 39 cc c7 33 d7 45 94 f8 86 b3 fa af d4
86 f2 5c 71 31 e3 28 1e 36 c7 a2 d1 30 af de 57
T = 84 90 ac 0e 58 94 9b fe 51 87 5d 73 3f 93 ac 20
75 16 80 39 cc c7 33 d7
Jones 標準化過程 [64ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
B.3. AES_256_CBC_HMAC_SHA_512 のテストケース
K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
ENC_KEY = 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20
6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75
69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65
74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62
65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69
6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66
20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f
75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65
IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04
A = 54 68 65 20 73 65 63 6f 6e 64 20 70 72 69 6e 63
69 70 6c 65 20 6f 66 20 41 75 67 75 73 74 65 20
4b 65 72 63 6b 68 6f 66 66 73
AL = 00 00 00 00 00 00 01 50
E = 4a ff aa ad b7 8c 31 c5 da 4b 1b 59 0d 10 ff bd
3d d8 d5 d3 02 42 35 26 91 2d a0 37 ec bc c7 bd
82 2c 30 1d d6 7c 37 3b cc b5 84 ad 3e 92 79 c2
e6 d1 2a 13 74 b7 7f 07 75 53 df 82 94 10 44 6b
36 eb d9 70 66 29 6a e6 42 7e a7 5c 2e 08 46 a1
1a 09 cc f5 37 0d c8 0b fe cb ad 28 c7 3f 09 b3
a3 b7 5e 66 2a 25 94 41 0a e4 96 b2 e2 e6 60 9e
31 e6 e0 2c c8 37 f0 53 d2 1f 37 ff 4f 51 95 0b
be 26 38 d0 9d d7 a4 93 09 30 80 6d 07 03 b1 f6
M = 4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf
2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5
fd 30 a5 65 c6 16 ff b2 f3 64 ba ec e6 8f c4 07
53 bc fc 02 5d de 36 93 75 4a a1 f5 c3 37 3b 9c
T = 4d d3 b4 c0 88 a7 f4 5c 21 68 39 64 5b 20 12 bf
2e 62 69 a8 c5 6a 81 6d bc 1b 26 77 61 95 5b c5
Jones 標準化過程 [65ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
付録 C. ECDH-ES 鍵合意計算の例
この例では、セクション 4.6 で説明した方法で CEK を導出するため、
ECDH-ES 鍵合意と Concat KDF を使用する。この例では、
ECDH-ES Direct Key Agreement モード ("alg" 値 "ECDH-ES") を使用して、
128 ビット鍵を使用する AES GCM ("enc"
値 "A128GCM") の合意済み鍵を生成する。
この例では、生成者 Alice が消費者
Bob にコンテンツを暗号化している。生成者 (Alice) は、鍵
合意計算のために一時鍵を生成する。この例の
鍵合意計算で使用する Alice の一時鍵
(JWK 形式、秘密部分を含む) は次のとおりである。
{"kty":"EC",
"crv":"P-256",
"x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
"y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps",
"d":"0_NxaRPUMQoAJt50Gz8YiTr8gRTwyEaCumd-MToTmIo"
}
この例の鍵合意計算で使用する消費者 (Bob) の鍵
(JWK 形式、秘密部分を含む) は次のとおりである。
{"kty":"EC",
"crv":"P-256",
"x":"weNJy2HscCSM6AEDTDg04biOvhFhyyWvOHQfeF_PxMQ",
"y":"e8lnCO-AlStT-NJVX-crhB7QRYhiix03illJOVAOyck",
"d":"VEmDZpDXXK8p8N0Cndsxs924q6nS1RXFASRl6BfUqdw"
}
この例で使用するヘッダーパラメーター値は次のとおりである。
"apu" (agreement PartyUInfo) ヘッダーパラメーター値は
UTF-8 文字列 "Alice" の base64url エンコーディングであり、
"apv" (agreement PartyVInfo) ヘッダーパラメーター値は
UTF-8 文字列 "Bob" の base64url エンコーディングである。
"epk" (一時公開鍵) ヘッダーパラメーターは、
生成者 (Alice) の一時公開鍵値を
消費者 (Bob) に伝達するために使用する。
Jones 標準化過程 [66ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
{"alg":"ECDH-ES",
"enc":"A128GCM",
"apu":"QWxpY2U",
"apv":"Qm9i",
"epk":
{"kty":"EC",
"crv":"P-256",
"x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
"y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps"
}
}
結果として得られる Concat KDF [NIST.800-56A] パラメーター値は次のとおりである。
Z
これは ECDH-ES 鍵合意の出力に設定する。
(この値は NIST のセキュリティ要件により、
ライブラリから直接公開されないことが多く、
KDF への入力としてのみ使用される。)
この例で Z は、次のオクテットシーケンスである
(JSON 配列表記を使用)。
[158, 86, 217, 29, 129, 113, 53, 211, 114, 131, 66, 131, 191, 132,
38, 156, 251, 49, 110, 163, 218, 128, 106, 72, 246, 218, 167, 121,
140, 254, 144, 196].
keydatalen
この値は 128 である。これは目的の出力鍵のビット数である
("A128GCM" は 128 ビット鍵を使用するため)。
AlgorithmID
これは、AlgorithmID の内容
"A128GCM" のオクテット数である 32 ビットビッグエンディアン値
7 を表すオクテット [0, 0, 0, 7] に設定し、その後に
ASCII 文字列 "A128GCM" を表すオクテット
[65, 49, 50, 56, 71, 67, 77] を続ける。
PartyUInfo
これは、PartyUInfo の内容
"Alice" のオクテット数である 32 ビットビッグエンディアン値
5 を表すオクテット [0, 0, 0, 5] に設定し、その後に
UTF-8 文字列 "Alice" を表すオクテット
[65, 108, 105, 99, 101] を続ける。
PartyVInfo
これは、PartyUInfo の内容
"Bob" のオクテット数である 32 ビットビッグエンディアン値
3 を表すオクテット [0, 0, 0, 3] に設定し、その後に
UTF-8 文字列 "Bob" を表すオクテット
[66, 111, 98] を続ける。
Jones 標準化過程 [67ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
SuppPubInfo
これは、keydatalen 値である
32 ビットビッグエンディアン値 128 を表すオクテット
[0, 0, 0, 128] に設定する。
SuppPrivInfo
これは空のオクテットシーケンスに設定する。
AlgorithmID から SuppPubInfo までのパラメーターを連結すると、
次の OtherInfo 値になる。
[0, 0, 0, 7, 65, 49, 50, 56, 71, 67, 77, 0, 0, 0, 5, 65, 108, 105,
99, 101, 0, 0, 0, 3, 66, 111, 98, 0, 0, 0, 128]
ラウンド番号 1 ([0, 0, 0, 1])、Z、および OtherInfo
値を連結すると、Concat KDF ラウンド 1 のハッシュ入力は次のようになる。
[0, 0, 0, 1,
158, 86, 217, 29, 129, 113, 53, 211, 114, 131, 66, 131, 191, 132, 38,
156, 251, 49, 110, 163, 218, 128, 106, 72, 246, 218, 167, 121, 140,
254, 144, 196,
0, 0, 0, 7, 65, 49, 50, 56, 71, 67, 77, 0, 0, 0, 5, 65, 108, 105, 99,
101, 0, 0, 0, 3, 66, 111, 98, 0, 0, 0, 128]
結果として得られる導出鍵は、ラウンド 1
ハッシュ出力の先頭 128 ビットであり、次のとおりである。
[86, 170, 141, 234, 248, 35, 109, 32, 92, 34, 40, 205, 113, 167, 16,
26]
この導出鍵の base64url エンコード表現は次のとおりである。
VqqN6vgjbSBcIijNcacQGg
Jones 標準化過程 [68ページ]
RFC 7518 JSON Web アルゴリズム (JWA) 2015年5月
謝辞
JSON コンテンツに署名および暗号化するための解決策は、以前に
"Magic Signatures" [MagicSignatures]、"JSON Simple Sign
1.0" [JSS]、"Canvas Applications" [CanvasApp]、"JSON Simple
Encryption" [JSE]、および "JavaScript Message Security Format" [JSMS]
によって検討されており、これらすべてがこの文書に影響を与えた。
AES_CBC_HMAC_SHA2 アルゴリズムの基礎となった
"Authenticated Encryption with AES-CBC and HMAC-SHA"
[AEAD-CBC-SHA] 仕様は、David A. McGrew と Kenny
Paterson によって執筆された。AES_CBC_HMAC_SHA2 のテストケースは、
John Foley による [AEAD-CBC-SHA] のテストケースに基づいている。
Matt Miller は、"Using JavaScript Object Notation (JSON) Web
Encryption (JWE) for Protecting JSON Web Key (JWK) Objects"
[JWE-JWK] を執筆し、
この文書のパスワードベース暗号化に関する内容はこれに基づいている。
この仕様は JOSE ワーキンググループの成果であり、
数十名の積極的で献身的な参加者が含まれている。特に、
次の人々が、この仕様に影響を与えたアイデア、
フィードバック、および文言を提供した。
Dirk Balfanz, Richard Barnes, Carsten Bormann, John Bradley, Brian
Campbell, Alissa Cooper, Breno de Medeiros, Vladimir Dzhuvinov, Roni
Even, Stephen Farrell, Yaron Y. Goland, Dick Hardt, Joe Hildebrand,
Jeff Hodges, Edmund Jay, Charlie Kaufman, Barry Leiba, James Manger,
Matt Miller, Kathleen Moriarty, Tony Nadalin, Axel Nennker, John
Panzer, Emmanuel Raviart, Eric Rescorla, Pete Resnick, Nat Sakimura,
Jim Schaad, Hannes Tschofenig, and Sean Turner.
Jim Schaad と Karen O'Donoghue は JOSE ワーキンググループの議長を務め、
Sean Turner、Stephen Farrell、および Kathleen Moriarty は、
この仕様の作成期間中に
セキュリティ領域ディレクターを務めた。
著者の連絡先
Michael B. Jones
Microsoft
電子メール: mbj@microsoft.com
URI: http://self-issued.info/
Jones 標準化過程 [69ページ]