[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]
PROPOSED STANDARD
Updated by: 9864 Errata ExistInternet Engineering Task Force (IETF) M. Jones
Request for Comments: 7518 Microsoft
Category: Standards Track May 2015
ISSN: 2070-1721
JSON Web アルゴリズム (JWA)
概要
本仕様は、JSON Web Signature (JWS)、JSON Web Encryption
(JWE)、および JSON Web Key (JWK) の各仕様とともに使用される
暗号アルゴリズムおよび識別子を登録するものである。また、
これらの識別子のために複数の IANA レジストリを定義する。
本メモの位置付け
本文書は、インターネット標準化トラック文書である。
本文書は、Internet Engineering Task Force
(IETF) による成果物である。これは IETF コミュニティの
合意を表している。公開レビューを受け、Internet Engineering
Steering Group (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 Standards Track [Page 1]
RFC 7518 JSON Web Algorithms (JWA) May 2015
目次
1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. 表記規則 . . . . . . . . . . . . . . . . . . . . . 4
2. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. 電子署名およびMAC用暗号アルゴリズム . . . . . . . . 6
3.1. JWSの"alg"（アルゴリズム）ヘッダパラメータ値 . 6
3.2. HMACとSHA-2関数 . . . . . . . . . . . . . . . . . 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. 楕円曲線ディフィー・ヘルマン
エフェメラル静的（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 Salt Input）ヘッダパラメータ . 21
4.8.1.2. "p2c"（PBES2 Count）ヘッダパラメータ . . . 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 Standards Track [Page 2]
RFC 7518 JSON Web Algorithms (JWA) May 2015
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"（第1CRT係数）パラメータ . . . . . . 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 Encryption圧縮アルゴリズムレジストリ 43
7.3.1. 登録テンプレート . . . . . . . . . . . . . . . 43
7.3.2. 初期レジストリ内容 . . . . . . . . . . . . . 44
7.4. JSON Web Keyタイプレジストリ . . . . . . . . . . 44
7.4.1. 登録テンプレート . . . . . . . . . . . . . . . 44
7.4.2. 初期レジストリ内容 . . . . . . . . . . . . . 45
7.5. JSON Web Keyパラメータ登録 . . . . . . . . . . . 45
7.5.1. レジストリ内容 . . . . . . . . . . . . . . . 46
7.6. JSON Web Key楕円曲線レジストリ . . . . . . . . 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 Standards Track [Page 3]
RFC 7518 JSON Web Algorithms (JWA) May 2015
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仕様が変更されても本書の変更を不要とするためでもある。
本仕様で定義される名称は短い。これは生成される表現が
コンパクトとなることを基本目標としているためである。
1.1. 表記規則
本書で用いられる "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、
"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、"OPTIONAL"
のキーワードの解釈は、「RFCにおける要件レベルを示すキーワードの使用法」
[RFC2119]に従う。
Jones Standards Track [Page 4]
RFC 7518 JSON Web Algorithms (JWA) May 2015
これらのキーワードの解釈は、全て大文字で用いられた場合のみ適用される。
BASE64URL(OCTETS)は、[JWS]セクション2に従い、OCTETS
をbase64urlエンコーディングしたものを示す。
UTF8(STRING)は、STRINGが0個以上のUnicode
[UNICODE]文字からなる列である場合、STRING
のUTF-8[RFC3629]表現のオクテット列を示す。
ASCII(STRING)は、STRINGが0個以上のASCII
文字からなる列である場合、STRING
のASCII[RFC20]表現のオクテット列を示す。
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"という用語は
"Internet Security Glossary, Version 2"[RFC4949]で定義されている。
本仕様で定義される用語は以下である：
Base64urlUInt
正またはゼロの整数値の表現方法とし、その値を符号なし
ビッグエンディアンオクテット列として表現し、それを
base64urlエンコードしたもの。オクテット列は
最小の長さのものを使用しなければならない。
ゼロはBASE64URL（ゼロ値の1オクテット）、すなわち"AA"で表される。
Jones Standards Track [Page 5]
RFC 7518 JSON Web Algorithms (JWA) May 2015
3. デジタル署名およびMACのための暗号アルゴリズム
JWSは、JWS保護ヘッダーおよびJWSペイロードの内容に
デジタル署名またはMACを作成するために暗号アルゴリズムを使用します。
3.1. JWS用 "alg" (アルゴリズム) ヘッダーパラメータ値
下表は、この仕様でJWSに使用するために定義された "alg"（アルゴリズム）
ヘッダーパラメータ値のセットであり、それぞれについて次節以降で
詳しく説明します。
+--------------+-------------------------------+--------------------+
| "alg" パラメータ | デジタル署名またはMAC | 実装要件 |
| 値 | アルゴリズム | |
+--------------+-------------------------------+--------------------+
| HS256 | SHA-256を用いたHMAC | 必須 |
| HS384 | SHA-384を用いたHMAC | オプション |
| HS512 | SHA-512を用いたHMAC | オプション |
| RS256 | RSASSA-PKCS1-v1_5（SHA-256） | 推奨 |
| RS384 | RSASSA-PKCS1-v1_5（SHA-384） | オプション |
| RS512 | RSASSA-PKCS1-v1_5（SHA-512） | オプション |
| ES256 | P-256およびSHA-256を用いたECDSA| 推奨＋ |
| ES384 | P-384およびSHA-384を用いたECDSA| オプション |
| ES512 | P-521およびSHA-512を用いたECDSA| オプション |
| PS256 | SHA-256およびMGF1(SHA-256)を | オプション |
| | 用いたRSASSA-PSS | |
| PS384 | SHA-384およびMGF1(SHA-384)を | オプション |
| | 用いたRSASSA-PSS | |
| PS512 | SHA-512およびMGF1(SHA-512)を | オプション |
| | 用いたRSASSA-PSS | |
| none | デジタル署名またはMACなし | オプション |
| | | |
+--------------+-------------------------------+--------------------+
実装要件欄に "+" が付いている場合、将来の
仕様バージョンで要件強度が引き上げられる
可能性があることを示します。
本仕様で定義されたJWSデジタル署名・MACの “alg” パラメータ値と、
他の標準およびソフトウェアパッケージで使われる同等識別子との
対応表については付録A.1を参照してください。
Jones Standards Track [Page 6]
RFC 7518 JSON Web Algorithms (JWA) May 2015
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署名入力を"text"として、共有鍵を用いて生成します。
HMACの出力値がJWS署名となります。
次の “alg”（アルゴリズム）ヘッダーパラメータ値は、
JWS署名が対応するアルゴリズムで計算された
HMAC値であることを示します：
+-------------------+--------------------+
| "alg" パラメータ値 | MACアルゴリズム |
+-------------------+--------------------+
| HS256 | SHA-256を用いたHMAC |
| HS384 | SHA-384を用いたHMAC |
| HS512 | SHA-512を用いたHMAC |
+-------------------+--------------------+
JWS用のHMAC SHA-256 MACはRFC 2104に従って計算し、
SHA-256をハッシュアルゴリズム"H"、受信したJWS署名入力を"text"、
共有鍵を用いてHMAC値を算出します。この値と
受信したエンコード済JWS署名値のbase64urlデコード
結果を比較します。
HMAC値とJWS署名値の比較は、タイミング攻撃を防ぐために
必ず一定時間で実施しなければなりません。
また、算出HMAC値をbase64urlエンコードし、受信した署名値と
一定時間で比較しても同一結果が得られます。
いずれの場合も値が一致すれば、HMACは検証済みとなります。
Jones Standards Track [Page 7]
RFC 7518 JSON Web Algorithms (JWA) May 2015
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デジタル署名は以下の通り生成されます：
JWS署名入力に対してRSASSA-PKCS1-v1_5-SIGNおよび
SHA-256ハッシュ関数を用い、目的の秘密鍵でデジタル署名を生成します。
これがJWS署名値です。
次の “alg” ヘッダーパラメータ値は、
対応するアルゴリズムで計算したデジタル署名値で
あることを示します：
+-------------------+---------------------------------+
| "alg" パラメータ値 | デジタル署名アルゴリズム |
+-------------------+---------------------------------+
| RS256 | RSASSA-PKCS1-v1_5（SHA-256） |
| RS384 | RSASSA-PKCS1-v1_5（SHA-384） |
| RS512 | RSASSA-PKCS1-v1_5（SHA-512） |
+-------------------+---------------------------------+
JWS用のRSASSA-PKCS1-v1_5 SHA-256
デジタル署名の検証は以下の通りです：
JWS署名入力、JWS署名、署名者が用いた秘密鍵に
対応する公開鍵をRSASSA-PKCS1-v1_5-VERIFY
アルゴリズムにSHA-256をハッシュ関数として渡します。
RSASSA-PKCS1-v1_5 SHA-384およびRSASSA-PKCS1-v1_5 SHA-512
による署名・検証は、SHA-256の場合と同様に、
それぞれ対応するハッシュアルゴリズムを使用します。
本アルゴリズムを用いた例は[JWS]の付録A.2を参照。
Jones Standards Track [Page 8]
RFC 7518 JSON Web Algorithms (JWA) May 2015
3.4. ECDSAによるデジタル署名
楕円曲線デジタル署名アルゴリズム（ECDSA）[DSS]は
楕円曲線暗号を利用し、RSA暗号と同等の
セキュリティをより短い鍵長で提供し、
多くの処理でより高速な動作が可能です。
これにより、ECDSA署名は同等強度のRSA署名より
署名長が大幅に短くなります。
本仕様では、P-256曲線＋SHA-256、P-384曲線＋SHA-384、
P-521曲線＋SHA-512を使うECDSAの利用を定義しています。
P-256, P-384, P-521曲線は[DSS]で
定義されています。
ECDSA P-256 SHA-256 デジタル署名の生成手順は以下の通りです：
1. ECDSA P-256 SHA-256を用いてJWS署名入力に
秘密鍵でデジタル署名を生成します。出力は(R, S)のペアで、
各R, Sは256ビット符号なし整数です。
2. R, Sをビッグエンディアン順でオクテット列へ変換し、
各配列は32オクテット長とします。この変換時、
値に含まれるリーディングゼロオクテットは
省略せずそのままにする必要があります。
3. 2つのオクテット列をR、Sの順で連結します。
（多くのECDSA実装ではこの連結をそのまま出力します。）
4. この64オクテット列がJWS署名値となります。
次の "alg" ヘッダーパラメータ値は、
対応アルゴリズムで計算されたデジタル署名値
であることを示します：
+-------------------+-------------------------------+
| "alg" パラメータ値 | デジタル署名アルゴリズム |
+-------------------+-------------------------------+
| ES256 | P-256+SHA-256を用いたECDSA |
| ES384 | P-384+SHA-384を用いたECDSA |
| ES512 | P-521+SHA-512を用いたECDSA |
+-------------------+-------------------------------+
Jones Standards Track [Page 9]
RFC 7518 JSON Web Algorithms (JWA) May 2015
JWS用ECDSA P-256 SHA-256デジタル署名の検証手順は以下の通りです：
1. JWS署名値は必ず64オクテット列でなければなりません。
そうでなければ検証失敗です。
2. 64オクテット列を2つの32オクテット列で分割し、
1つ目がR、2つ目がSとなります。R, Sは
SEC1の2.3.7節 [SEC1]
で定義される整数→オクテット文字列変換で表現します
（ビッグエンディアン順）。
3. JWS署名入力、R、S、および公開鍵(x, y)を
ECDSA P-256 SHA-256バリデータへ渡します。
ECDSA P-384 SHA-384, ECDSA P-521 SHA-512による署名・検証は
P-256 SHA-256の場合と同様ですが、出力の結果値がそれぞれ
より大きくなります。ECDSA P-384 SHA-384ではR, Sは384ビット（96オクテット）、
ECDSA P-521 SHA-512ではR, Sは521ビット（132オクテット）です。
（SEC1の2.3.7節の整数→オクテット変換は
必要時0値上位パディングを付与し、8ビット単位へ切り上げるため
521ビット整数は528ビット＝66オクテットで表される点に注意）
これらアルゴリズムの利用例は[JWS]付録A.3、A.4に掲載。
3.5. RSASSA-PSSによるデジタル署名
本節では、RFC 3447の8.1節 [RFC3447]
で定義される信号アルゴリズムRSASSA-PSSの利用を定義し、
MGF1マスク生成関数およびSHA-2ハッシュ関数を併用し、
必ず両者に同一ハッシュ関数を用います。ソルト値サイズは
ハッシュ関数出力サイズと同じです。その他パラメータは
RFC 3447付録A.2.3の
デフォルト値を使用します。
2048ビット以上の鍵サイズの使用が必須です。
RSASSA-PSS SHA-256署名は以下の通り生成：
JWS署名入力に対しRSASSA-PSS-SIGN、SHA-256、MGF1（SHA-256）、
所望の秘密鍵を用いてデジタル署名を生成します。
これがJWS署名値です。
Jones Standards Track [Page 10]
RFC 7518 JSON Web Algorithms (JWA) May 2015
次の "alg" ヘッダーパラメータ値は、JWS署名が対応アルゴリズムで
計算したデジタル署名値であることを示します：
+-------------------+-----------------------------------------------+
| "alg" パラメータ値 | デジタル署名アルゴリズム |
+-------------------+-----------------------------------------------+
| PS256 | SHA-256かつMGF1(SHA-256)を用いたRSASSA-PSS |
| PS384 | SHA-384かつMGF1(SHA-384)を用いたRSASSA-PSS |
| PS512 | SHA-512かつMGF1(SHA-512)を用いたRSASSA-PSS |
+-------------------+-----------------------------------------------+
JWSのRSASSA-PSS SHA-256署名は次の通り検証します：
JWS署名入力、JWS署名、署名者の秘密鍵に対応する公開鍵を
RSASSA-PSS-VERIFYアルゴリズムにSHA-256およびMGF1(SHA-256)を用いて入力。
RSASSA-PSS SHA-384、RSASSA-PSS SHA-512の署名・検証も
SHA-256の場合と同様ですが、それぞれ別種のハッシュ関数を
両方の役割に利用します。
3.6. アルゴリズム“none”の利用
JWSは完全性保護を提供しない形式で作成することも可能です。
このようなJWSは「Unsecured JWS」と呼ばれます。
Unsecured JWSは"alg"値"none"を使い、他のJWSと同じ
形式ですが、JWS署名値として空のオクテット列を
必ず使用します。受信側はJWS署名値が空の
オクテット列であることを検証しなければなりません。
Unsecured JWSをサポートする実装は、アプリケーションで
個別に明示許可されない限り、そのオブジェクトを
有効とみなしてはなりません。デフォルトで
Unsecured JWSを受け入れてはなりません。ダウングレード攻撃を
緩和するために、グローバルレベルで受け入れを
シグナルせず、オブジェクト毎にシグナルするべきです。
このアルゴリズム利用のセキュリティ考慮事項は8.5節参照。
4. 鍵管理用暗号アルゴリズム
JWEはコンテンツ暗号鍵（CEK）を暗号化あるいは
決定するための暗号アルゴリズムを用います。
Jones Standards Track [Page 11]
RFC 7518 JSON Web Algorithms (JWA) May 2015
4.1. JWE用 "alg" (アルゴリズム) ヘッダーパラメータ値
下表はJWEで使用するために本仕様で定義される
"alg"（アルゴリズム）ヘッダーパラメータ値の一覧です。
これらのアルゴリズムはCEKの暗号化（JWE暗号化鍵を生成）、
または鍵合意によるCEKの合意に使われます。
+--------------------+--------------------+--------+----------------+
| "alg"パラメータ値 | 鍵管理アルゴリズム | 追加ヘッダー | 実装要件 |
| | | パラメータ | |
+--------------------+--------------------+--------+----------------+
| RSA1_5 | RSAES-PKCS1-v1_5 | (なし) | 推奨- |
| RSA-OAEP | デフォルトパラメータ| (なし) | 推奨＋ |
| | のRSAES OAEP | | |
| RSA-OAEP-256 | SHA-256+MGF1(SHA-256) のRSAES OAEP | (なし) | オプション |
| A128KW | 128ビット鍵による | (なし) | 推奨 |
| | 初期値付きのAES Key | | |
| | Wrap | | |
| A192KW | 192ビット鍵による | (なし) | オプション |
| | AES Key Wrap | | |
| A256KW | 256ビット鍵による | (なし) | 推奨 |
| | AES Key Wrap | | |
| dir | 共有対称鍵を | (なし) | 推奨 |
| | CEKとして直接使用 | | |
| ECDH-ES | 楕円曲線Diffie-Hellman| "epk", | 推奨＋ |
| | Ephemeral Static | "apu", | |
| | キー合意＋Concat KDF| "apv" | |
| ECDH-ES+A128KW | ECDH-ES+Concat KDF | "epk", | 推奨 |
| |＋A128KWによるCEKラップ| "apu", | |
| | | "apv" | |
| ECDH-ES+A192KW | ECDH-ES+Concat KDF | "epk", | オプション |
| |＋A192KWによるCEKラップ| "apu", | |
| | | "apv" | |
Jones Standards Track [Page 12]
RFC 7518 JSON Web Algorithms (JWA) May 2015
| ECDH-ES+A256KW | ECDH-ES+Concat KDF | "epk", | 推奨 |
| |＋A256KWによるCEKラップ| "apu", | |
| | | "apv" | |
| A128GCMKW | 128ビット鍵による | "iv", | オプション |
| | AES GCM Key Wrap | "tag" | |
| A192GCMKW | 192ビット鍵による | "iv", | オプション |
| | AES GCM Key Wrap | "tag" | |
| A256GCMKW | 256ビット鍵による | "iv", | オプション |
| | AES GCM Key Wrap | "tag" | |
| PBES2-HS256+A128KW | HMAC SHA-256＋ | "p2s", | オプション |
| | "A128KW"ラッピング | "p2c" | |
| PBES2-HS384+A192KW | HMAC SHA-384＋ | "p2s", | オプション |
| | "A192KW"ラッピング | "p2c" | |
| PBES2-HS512+A256KW | HMAC SHA-512＋ | "p2s", | オプション |
| | "A256KW"ラッピング | "p2c" | |
+--------------------+--------------------+--------+----------------+
追加ヘッダーパラメータ欄は、各アルゴリズムが
"alg" 以外に使用するヘッダーパラメータを示しています。
"dir"と"ECDH-ES"を除く全ては、JWE暗号化鍵値も生成します。
実装要件欄の"+"記号は将来の仕様で要件強度が
引き上げられる可能性、"-"は引き下げられる可能性を示します。
本仕様で定義された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 Standards Track [Page 13]
RFC 7518 JSON Web Algorithms (JWA) May 2015
4.3. RSAES OAEPによる鍵暗号化
このセクションでは、最適非対称暗号化パディング（OAEP）[RFC3447]を使用して
JWE CEKをRSAESで暗号化する具体的な仕様を定義します。OAEPを使用するための2組のパラメータセットが定義されており、
それぞれ異なるハッシュ関数を利用します。最初の場合、RFC3447の付録A.2.1
で指定されているデフォルトパラメータ（SHA-1ハッシュ関数およびSHA-1のMGF1マスク生成関数）
が使用されます。二番目の場合は、SHA-256ハッシュ関数とSHA-256のMGF1マスク生成関数が使われます。
JWE暗号化鍵が、対応するアルゴリズムを使ってCEKを暗号化した結果であることを示すために、
以下の"alg"（アルゴリズム）ヘッダパラメータ値が使用されます。
+-------------------+-----------------------------------------------+
| "alg" Param Value | 鍵管理アルゴリズム |
+-------------------+-----------------------------------------------+
| RSA-OAEP | デフォルトパラメータを用いたRSAES OAEP |
| RSA-OAEP-256 | SHA-256およびSHA-256のMGF1を用いたRSAES OAEP |
+-------------------+-----------------------------------------------+
これらのアルゴリズムでは、2048ビット以上の鍵を使用しなければなりません。
（この要件は、NIST SP 800-57[NIST.800-57]の表4（セキュリティ強度の期間）と
表2（同等強度）に基づき、RSA2048ビット鍵が112ビットのセキュリティを提供するとされています。）
デフォルトパラメータを用いたRSAES OAEPの例は、[JWE付録A.1]に示されています。
4.4. AES鍵ラップによる鍵包絡
このセクションでは、高度暗号化標準(AES)鍵ラップアルゴリズム[RFC3394]を
用いて、JWE CEKを暗号化する具体的な仕様を定義します。その際、該当ドキュメントの
セクション2.2.3.1で指定されたデフォルト初期値を使用します。
Jones Standards Track [Page 14]
RFC 7518 JSON Web Algorithms (JWA) May 2015
JWE暗号化鍵が対応アルゴリズムと鍵サイズによりCEKを暗号化した結果であることを示すために、
以下の"alg"（アルゴリズム）ヘッダパラメータ値が使われます：
+-----------------+-------------------------------------------------+
| "alg" Param | 鍵管理アルゴリズム |
| Value | |
+-----------------+-------------------------------------------------+
| A128KW | デフォルト初期値および128ビット鍵を用いたAES鍵ラップ|
| A192KW | デフォルト初期値および192ビット鍵を用いたAES鍵ラップ|
| A256KW | デフォルト初期値および256ビット鍵を用いたAES鍵ラップ|
+-----------------+-------------------------------------------------+
このアルゴリズムを用いた例は[JWE付録A.3]に示されています。
4.5. 共有対称鍵による直接暗号化
このセクションは、鍵ラップ工程を行わず、直接対称鍵暗号を実施する仕様を定義します。
この場合、共有対称鍵は"enc"アルゴリズムのためのコンテンツ暗号鍵（CEK）値として
直接利用されます。JWE暗号化鍵の値としては空オクテット列が使用されます。
この場合、"alg"（アルゴリズム）ヘッダパラメータ値は"dir"になります。
直接暗号化を利用する際は、セクション8.2の鍵の有効期間および
セクション8.4のAES GCMに関するセキュリティ考慮事項を参照してください。
4.6. 楕円曲線Diffie-Hellman Ephemeral Static（ECDH-ES）による鍵合意
(ECDH-ES)
このセクションでは、楕円曲線Diffie-Hellman Ephemeral Static[RFC6090]、
およびSection 5.8.1のConcat KDF[NIST.800-56A]と組み合わせた
鍵合意の仕様を定義します。鍵合意の結果の利用方法は2通りあります：
1. Direct Key Agreementモードでは、"enc"アルゴリズム用のCEKとして
直接利用する
2. Key Agreement with Key Wrappingモードでは、合意した対称鍵で
"A128KW"、"A192KW"、"A256KW"いずれかのアルゴリズムでCEKをラップする
各鍵合意処理ごとに新しい一時公開鍵を必ず生成しなければなりません。
Jones Standards Track [Page 15]
RFC 7518 JSON Web Algorithms (JWA) May 2015
Direct Key Agreementモードでは、Concat KDFの出力は"enc"アルゴリズムと同じ
長さの鍵でなければなりません。この場合、JWE暗号化鍵値は空オクテット列です。
"alg"（アルゴリズム）ヘッダパラメータ値"ECDH-ES"がDirect Key Agreement
モードで使用されます。
Key Agreement with Key Wrappingモードでは、Concat KDFの出力は
指定の鍵ラップアルゴリズムで必要な鍵長でなければなりません。この場合、
JWE暗号化鍵は、合意した鍵でラップされたCEKとなります。
JWE暗号化鍵が鍵合意アルゴリズムの結果を用いて、指定の鍵ラップアルゴリズムの
鍵暗号鍵としてCEKを暗号化した結果であることを示すため、以下の
"alg"（アルゴリズム）ヘッダパラメータ値が使われます：
+-----------------+-------------------------------------------------+
| "alg" Param | 鍵管理アルゴリズム |
| Value | |
+-----------------+-------------------------------------------------+
| ECDH-ES+A128KW | Concat KDFを用い、CEKを"A128KW"でラップ |
| ECDH-ES+A192KW | Concat KDFを用い、CEKを"A192KW"でラップ |
| ECDH-ES+A256KW | Concat KDFを用い、CEKを"A256KW"でラップ |
+-----------------+-------------------------------------------------+
4.6.1. ECDH鍵合意で使われるヘッダパラメータ
以下のヘッダパラメータ名が、鍵合意のために定義されています。
4.6.1.1. "epk"（一時公開鍵）ヘッダパラメータ
"epk"（一時公開鍵）は発信者が鍵合意アルゴリズムで使用するために作成した鍵の値です。
この鍵はJSON Web Key[JWK]公開鍵値として表現されます。
公開鍵パラメータのみを含み、必要最小限のJWKパラメータだけを持つべきです。
その他のパラメータは整合性確認などのために含めることも可能ですが、無視されても構いません。
これらアルゴリズムを利用する際、このヘッダパラメータは必須であり、
実装は理解した上で処理しなければなりません。
Jones Standards Track [Page 16]
RFC 7518 JSON Web Algorithms (JWA) May 2015
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鍵合意のための鍵導出
鍵導出処理は、ECDHアルゴリズムによって確立された共有秘密Zから
合意された鍵を導出します（[NIST.800-56A]セクション6.2.2.2）。
鍵導出には、[NIST.800-56A]セクション5.8.1で定義された
Concat KDF（ダイジェスト方式はSHA-256）が使われます。
Concat KDFのパラメータは以下の通りです：
Z
ECDHアルゴリズムで得た共有秘密Zをオクテット列で設定します。
keydatalen
望む出力鍵のビット長を設定します。 "ECDH-ES"の場合は"enc"アルゴリズムの鍵長、
"ECDH-ES+A128KW"、"ECDH-ES+A192KW"、"ECDH-ES+A256KW"の場合はそれぞれ
128、192、256になります。
AlgorithmID
AlgorithmID値はDatalen||Dataの形で、Dataは可変長オクテット列、
DatalenはDataの長さ（オクテット数）を示す32ビット固定長ビッグエンディアンカウンタです。
Direct Key Agreementの場合、Dataは"enc"ヘッダパラメータ値のASCII表現のオクテット列、
Key Agreement with Key Wrappingの場合は"alg"ヘッダパラメータ値です。
Jones Standards Track [Page 17]
RFC 7518 JSON Web Algorithms (JWA) May 2015
PartyUInfo
PartyUInfo値はDatalen||Dataの形で、Dataは可変長オクテット列、
DatalenはDataの長さ（オクテット数）を示す32ビット固定長ビッグエンディアンカウンタです。
"apu"ヘッダパラメータが存在する場合、Dataは"apu"値をbase64urlデコードした結果、
DatalenはDataのオクテット数です。未指定ならDatalenは0でDataは空オクテット列となります。
PartyVInfo
PartyVInfo値もDatalen||Dataの形式で、Dataは可変長オクテット列、
Datalenはそのオクテット数を表す32ビットビッグエンディアン整数です。
"apv"ヘッダパラメータが存在する場合、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"は省略するかエフェメラル・スタティックモードのPartyAInfo相当512ビット乱数値として、
"apv"は原則指定すべきではありません。
この手法を用いた鍵合意計算例は付録Cを参照ください。
4.7. AES GCMによる鍵暗号化
このセクションは、AESのGalois/Counter Mode（GCM）([AES] および
[NIST.800-38D])を使用してJWEコンテンツ暗号化鍵（CEK）を暗号化する
具体仕様を定めます。
Jones Standards Track [Page 18]
RFC 7518 JSON Web Algorithms (JWA) May 2015
このアルゴリズムでは、96ビット長の初期化ベクトル（IV）の利用が必須です。
IVは、"iv"（初期化ベクトル）ヘッダパラメータ値としてbase64urlエンコードされた形で表現されます。
Additional Authenticated Data値は空のオクテット列を使います。
認証タグ出力の要求サイズは鍵長に関わらず128ビットでなければなりません。
JWE暗号化鍵値は暗号操作の暗号文出力です。
認証タグ出力は"tag"（認証タグ）ヘッダパラメータ値としてbase64urlエンコードされて表現されます。
対応する鍵管理アルゴリズムでCEKを暗号化した結果としてJWE暗号化鍵となる場合、
以下の"alg"（アルゴリズム）ヘッダ値が使われます：
+-------------------+---------------------------------------------+
| "alg" Param Value | 鍵管理アルゴリズム |
+-------------------+---------------------------------------------+
| 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"（初期化ベクトル）ヘッダパラメータ値は鍵暗号操作に用いる96ビットIV値を
base64urlエンコードしたものです。これらアルゴリズムを使う際、この
ヘッダパラメータは必須であり、実装は理解の上で処理しなければなりません。
4.7.1.2. "tag"（認証タグ）ヘッダパラメータ
"tag"（認証タグ）ヘッダパラメータ値は鍵暗号操作の結果得られる
128ビット認証タグ値をbase64urlエンコードしたものです。
このヘッダパラメータも必須であり、実装は必ず理解し処理しなければなりません。
Jones Standards Track [Page 19]
RFC 7518 JSON Web Algorithms (JWA) May 2015
4.8. PBES2による鍵暗号化
このセクションでは、JWE CEK（Content Encryption Key）のパスワードベース暗号化の
具体的な仕様を定義します。まず、[RFC2898]セクション6.2で規定されたPBES2方式を用いて
利用者が入力したパスワードから鍵暗号鍵を導出し、その派生鍵でJWE CEKを暗号化します。
これらのアルゴリズムは、PBKDF2による鍵導出のためにHMAC SHA-2アルゴリズムを
疑似乱数関数（PRF）として利用し、暗号方式としてAES Key Wrap
[RFC3394]を使用します。PBES2へのパスワード入力はオクテット列です。
テキスト文字列を使う場合は、必ずUTF-8でエンコードしオクテット列として用いる必要があります。
saltパラメータは下記"p2s"定義通り、"p2s"（PBES2 salt input）ヘッダパラメータ値と
"alg"（アルゴリズム）ヘッダパラメータ値から計算しなければなりません。反復回数パラメータは
"p2c"（PBES2 count）ヘッダパラメータ値として指定しなければなりません。
アルゴリズムはそれぞれ、PRFにHMAC SHA-256・HMAC SHA-384・HMAC SHA-512を用い、
AES Key Wrap鍵には128、192、256ビットを利用します。
派生鍵の長さはそれぞれ16、24、32オクテットです。
JWE暗号化鍵が、該当パスワードベース暗号化アルゴリズムの結果によって
CEKを暗号化し鍵ラップアルゴリズムの鍵暗号鍵として利用したものである場合、
以下の"alg"（アルゴリズム）ヘッダパラメータ値が用いられます：
+--------------------+----------------------------------------------+
| "alg" Param Value | 鍵管理アルゴリズム |
+--------------------+----------------------------------------------+
| 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 Standards Track [Page 20]
RFC 7518 JSON Web Algorithms (JWA) May 2015
4.8.1.1. "p2s"（PBES2 Salt Input）ヘッダパラメータ
"p2s"（PBES2 salt input）ヘッダパラメータは、Salt Input値をエンコードしたものであり、
PBKDF2のsalt値の一部として使われます。"p2s"値はBASE64URL(Salt Input)です。
これらアルゴリズムを使用する際、このヘッダパラメータは必須であり、実装は必ず理解し処理
しなければなりません。
saltは、与えられたパスワードから導出可能な鍵の範囲を広げます。
Salt Inputは8オクテット以上を必ず用いる必要があります。
新しいSalt Input値は暗号化ごとにランダムに生成されなければなりません（乱数生成については
RFC 4086 [RFC4086]参照）。salt値は(UTF8(Alg) || 0x00 || Salt Input)
という形式で用いられ、Algは"alg"（アルゴリズム）ヘッダ値です。
4.8.1.2. "p2c"（PBES2 Count）ヘッダパラメータ
"p2c"（PBES2 count）ヘッダパラメータは、PBKDF2の反復回数を表す正のJSON整数です。
このヘッダパラメータも必須であり、実装は必ず理解して処理しなければなりません。
反復回数は計算コストを増加させ、saltによる鍵空間の広がりと複合的に安全性を高めます。
最小反復回数として1000以上を推奨します。
5. コンテンツ暗号化用暗号アルゴリズム
JWEは、プレーンテキストの暗号化および完全性保護、
さらに追加認証データの完全性保護のために暗号アルゴリズムを利用します。
Jones Standards Track [Page 21]
RFC 7518 JSON Web Algorithms (JWA) May 2015
5.1. JWEの"enc"（暗号化アルゴリズム）ヘッダ値
下表は、この仕様でJWEに利用するために定義された
"enc"（暗号化アルゴリズム）ヘッダパラメータ値です。
+---------------+----------------------------------+----------------+
| "enc" Param | コンテンツ暗号化アルゴリズム | 実装要件 |
| Value | | |
+---------------+----------------------------------+----------------+
| 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 | AES GCM （128ビット鍵） | 推奨 |
| A192GCM | AES GCM （192ビット鍵） | オプション |
| A256GCM | AES GCM （256ビット鍵） | 推奨 |
+---------------+----------------------------------+----------------+
すべてJWE初期化ベクトル値を用い、JWE暗号文およびJWE認証タグ値を生成します。
本仕様で定義されたJWE "enc"値と、他標準・ソフトウェアで用いられる
同等識別子を対応付ける表は付録A.3参照。
5.2. AES_CBC_HMAC_SHA2アルゴリズム
本セクションでは、AES [AES]を、
Cipher Block Chaining（CBC）モード[NIST.800-38A]と
PKCS #7パディング（[RFC5652]セクション6.3参照）、
およびHMAC（[RFC2104]・[SHS]）
を組み合わせた認証付き暗号化アルゴリズムファミリーを定義します。
このアルゴリズムファミリーをAES_CBC_HMAC_SHA2と呼びます。
128ビットCBC鍵＋HMAC SHA-256、192ビットCBC鍵＋HMAC SHA-384、
256ビットCBC鍵＋HMAC SHA-512の3つの実インスタンスを定義します。
テストケースは付録B参照。
Jones Standards Track [Page 22]
RFC 7518 JSON Web Algorithms (JWA) May 2015
これらのアルゴリズムは「Authenticated Encryption with AES-
CBC and HMAC-SHA」[AEAD-CBC-SHA]に基づいています。
同じ暗号計算を実施しますが、初期化ベクトル（IV）および
認証タグの値は暗号文に連結されず別々に出力されます。
この選択肢については該当仕様の付録Bで議論されています。
このアルゴリズムファミリーは
[AEAD-CBC-SHA]の一般化であり、それらのアルゴリズムの実装にも利用できます。
5.2.1. AES_CBC_HMAC_SHA2定義に用いる記法
以下の記法を使用します。
CBC-PKCS7-ENC(X, P)は、鍵Xを使って平文Pを
PKCS#7パディング付きでAES-CBC暗号化することを示します。
MAC(Y, M)は、鍵YによりメッセージMにMACを適用することを示します。
5.2.2. 汎用AES_CBC_HMAC_SHA2アルゴリズム
本セクションでは、AES_CBC_HMAC_SHA2を
AES-CBC鍵サイズやハッシュ関数に依存しない形で定義します。
5.2.2.1および5.2.2.2で汎用的な暗号化と復号アルゴリズムを、
5.2.3～5.2.5で具体的なアルゴリズムインスタンスを規定します。
5.2.2.1. AES_CBC_HMAC_SHA2暗号化
認証付き暗号化アルゴリズムは、4つのオクテット列を入力とします：
秘密鍵K、平文P、追加認証データA、および初期化ベクトルIVです。
認証付き暗号文Eと認証タグTが出力されます。
平文のデータは暗号化および認証され、
追加認証データは認証のみされ暗号化はされません。
暗号化プロセスは下記または同等の手順となります：
1. 副次鍵MAC_KEYとENC_KEYを入力鍵Kから次のように生成します。
それぞれの鍵はオクテット列です。
MAC_KEYはKの先頭MAC_KEY_LENオクテットで構成されます。
ENC_KEYはKの末尾ENC_KEY_LENオクテットで構成されます。
Jones Standards Track [Page 23]
RFC 7518 JSON Web Algorithms (JWA) May 2015
入力鍵Kのオクテット数はMAC_KEY_LENとENC_KEY_LENの合計でなければなりません。
これらパラメータの値は、5.2.3～5.2.5の認証付き暗号化アルゴリズムで規定されます。
MAC鍵は入力鍵Kの先に、暗号鍵は後ろに並んでいることに注意してください。
（これは識別子"AES_CBC_HMAC_SHA2"内では逆順になっています。）
2. IVとして128ビットの値をランダムまたは疑似乱数で生成し暗号操作に用います。
3. 平文はENC_KEYとIVを使ってPKCS#7パディング付きAES-CBCで暗号化されます。
このステップの暗号文出力をEと表します。
4. オクテット列ALは、追加認証データAのビット数を
64ビット符号なしビッグエンディアン整数で表したものです。
5. HMAC[RFC2104]を下記順番で適用し
認証タグTを計算します：
追加認証データA
初期化ベクトルIV
上記ステップで得た暗号文E
上で定義したオクテット列AL
MAC_KEYをMAC鍵として使用します。
このステップで求めたMAC出力をMとし、
その先頭T_LENオクテットをTとします。
6. 暗号文Eと認証タグTを認証付き暗号化の出力として返します。
暗号化処理のフローは以下の通りです。ここでK、P、A、IV、Eは
それぞれ鍵、平文、追加認証データ、初期化ベクトル、暗号文を表します。
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 Standards Track [Page 24]
RFC 7518 JSON Web Algorithms (JWA) May 2015
5.2.2.2. AES_CBC_HMAC_SHA2復号
この認証付き復号操作はK、A、IV、E、Tの5つを入力（上記の定義通り）とします。
出力は、平文Pまたは入力の認証が失敗したことを示す特別な記号FAILのみです。
復号アルゴリズムは以下または同等手順です：
1. 副次鍵MAC_KEYとENC_KEYを、5.2.2.1で述べたStep1と同様に
入力鍵Kから生成します。
2. AおよびEの完全性・認証性は、5.2.2.1のStep5のHMAC計算と同様に
入力を用いて確認します。前ステップで得たTと、HMAC出力の先頭
MAC_KEY長ビットを比較します。一致していればA・Eは有効とみなし処理継続、
不一致ならMAC検証用データすべてを破棄し、失敗を示して処理を中断します。
（タイミング攻撃回避のセキュリティ考慮は
[JWE]セクション11.5参照）
3. Eで与えられた値を復号し、PKCS #7パディングを検証・除去します。
IVは初期化ベクトル、ENC_KEYは復号鍵として利用します。
4. 平文値を返します。
5.2.3. AES_128_CBC_HMAC_SHA_256
このアルゴリズムは、先述の汎用AES_CBC_HMAC_SHA2アルゴリズムの
具体化です。メッセージ認証用にHMAC [RFC2104]と
SHA-256ハッシュ関数[SHS]を利用し、
HMAC出力は128ビットに切り詰めて（[RFC4868]で定義される
HMAC-SHA-256-128アルゴリズムに相当）、暗号化には
[NIST.800-38A]セクション6.2定義のAES CBCモード、
PKCS #7パディング、128ビットIVを使用します。
AES_128_CBC_HMAC_SHA_256用のパラメータ：
入力鍵Kは32オクテット長
ENC_KEY_LENは16オクテット
MAC_KEY_LENは16オクテット
HMACはSHA-256を使用
HMAC-SHA-256出力はT_LEN=16オクテット（末尾16オクテット切り捨て）
Jones Standards Track [Page 25]
RFC 7518 JSON Web Algorithms (JWA) May 2015
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値はT_LEN=16オクテットではなく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値はT_LEN=16オクテットではなく32オクテットに切り詰められます。
5.2.6. AES_CBC_HMAC_SHA2によるコンテンツ暗号化
このセクションではAES_CBC_HMAC_SHA2アルゴリズムによる認証付き暗号化の
具体的仕様を定義します。
CEKは秘密鍵Kとして使用されます。
JWE暗号文およびJWE認証タグ値が対応するアルゴリズムで計算されたことを示すため、
以下の"enc"（暗号化アルゴリズム）ヘッダ値が利用されます：
+---------------+---------------------------------------------------+
| "enc" Param | コンテンツ暗号化アルゴリズム |
| Value | |
+---------------+---------------------------------------------------+
| A128CBC-HS256 | セクション 5.2.3で定義されるAES_128_CBC_HMAC_SHA_256認証付き暗号化 |
| A192CBC-HS384 | セクション 5.2.4で定義されるAES_192_CBC_HMAC_SHA_384認証付き暗号化 |
| A256CBC-HS512 | セクション 5.2.5で定義されるAES_256_CBC_HMAC_SHA_512認証付き暗号化 |
+---------------+---------------------------------------------------+
Jones Standards Track [Page 26]
RFC 7518 JSON Web Algorithms (JWA) May 2015
5.3. AES GCMによるコンテンツ暗号化
このセクションでは、Galois/Counter Mode (GCM)([AES] および
[NIST.800-38D])でのAES認証付き暗号化の具体仕様を定義します。
CEKは暗号鍵として利用されます。
このアルゴリズムでは96ビット長のIVの利用が必須です。
認証タグ出力の要求サイズは鍵長によらず128ビットでなければなりません。
JWE暗号文および認証タグ値が対応するアルゴリズム・鍵長で計算されたことを示すため、
下記"enc"（暗号化アルゴリズム）ヘッダ値を利用します：
+-------------------+------------------------------+
| "enc" Param Value | コンテンツ暗号化アルゴリズム |
+-------------------+------------------------------+
| A128GCM | 128ビット鍵によるAES GCM |
| A192GCM | 192ビット鍵によるAES GCM |
| A256GCM | 256ビット鍵によるAES GCM |
+-------------------+------------------------------+
このアルゴリズムの利用例は[JWE付録A.1]に記載されています。
6. 鍵用の暗号アルゴリズム
JSON Web Key (JWK) [JWK]は暗号鍵を表現する
JSONデータ構造です。これらの鍵は非対称鍵でも対称鍵でも構いません。
鍵に関する公開情報および秘密情報の保持も可能です。
このセクションでは本仕様で規定されるアルゴリズムで使用する鍵のパラメータを定義します。
Jones Standards Track [Page 27]
RFC 7518 JSON Web Algorithms (JWA) May 2015
6.1. "kty"（鍵タイプ）パラメータ値
下表は、本仕様でJWK内で利用するために定義された"kty"（鍵タイプ）パラメータ値です。
+-------------+--------------------------------+--------------------+
| "kty" Param | Key Type | Implementation |
| Value | | Requirements |
+-------------+--------------------------------+--------------------+
| EC | 楕円曲線 [DSS] | 推奨+ |
| RSA | RSA [RFC3447] | 必須 |
| oct | オクテット列（対称鍵表現などに使用） | 必須 |
+-------------+--------------------------------+--------------------+
実装要件欄の"+"記号は、将来仕様改訂で要件強度が引き上げられる可能性を意味します。
6.2. 楕円曲線鍵のパラメータ
JWKは楕円曲線 [DSS] 鍵を表現できます。この場合、"kty"メンバー値は"EC"です。
6.2.1. 楕円曲線公開鍵のパラメータ
楕円曲線公開鍵は、有限体上の座標ペアで表され、その組み合わせで楕円曲線上の点を定義します。
すべての楕円曲線公開鍵には以下のメンバが必須です：
o "crv"
o "x"
次のメンバも、次セクションで定義される3曲線の公開鍵では必須です：
o "y"
6.2.1.1. "crv"（曲線）パラメータ
"crv"（曲線）パラメータは、鍵で使用される暗号曲線を指定します。
本仕様で利用される[DSS]由来の曲線値は：
o "P-256"
o "P-384"
o "P-521"
Jones Standards Track [Page 28]
RFC 7518 JSON Web Algorithms (JWA) May 2015
これらの値はセクション 7.6で定義される
IANA「JSON Web Key Elliptic Curve」レジストリで登録されています。
他の仕様が追加の"crv"値を登録することも可能です。
登録仕様は、その曲線の鍵パラメータの内容を定義しなければなりません。
"crv"値は大文字小文字を区別する文字列です。
SEC1[SEC1]での座標圧縮（point compression）はこれら3曲線すべて未対応です。
6.2.1.2. "x"（X座標）パラメータ
"x"（X座標）パラメータは、楕円曲線上の点のX座標値を持ちます。
これは、座標値のオクテット列表現をbase64urlでエンコードしたもので、
SEC1セクション2.3.5[SEC1]で定義されています。
オクテット列の長さは、"crv"パラメータで指定された曲線の座標フルサイズでなければなりません。
例えば"crv"値が"P-521"の場合、オクテット列は66オクテットで表現されます。
6.2.1.3. "y"（Y座標）パラメータ
"y"（Y座標）パラメータは、楕円曲線点のY座標値を持ちます。
これは座標値オクテット列表現をbase64urlでエンコードしたもので、
SEC1セクション2.3.5[SEC1]で定義されています。
オクテット列長は"crv"値で指定された曲線の座標フルサイズでなければなりません。
例えば"crv"値が"P-521"の場合、オクテット列は66オクテットとします。
6.2.2. 楕円曲線秘密鍵のパラメータ
楕円曲線公開鍵を表現するためのメンバーに加え、
楕円曲線秘密鍵表現では次のメンバーが必須です。
6.2.2.1. "d"（ECC秘密鍵）パラメータ
"d"（ECC秘密鍵）パラメータは楕円曲線の秘密鍵値を持ちます。
これは秘密鍵値のオクテット列表現をbase64urlでエンコードしたもので、
SEC1セクション2.3.7[SEC1]で定義されています。
オクテット列長はceiling(log-base-2(n)/8)オクテット（nは曲線の位数）でなければなりません。
Jones Standards Track [Page 29]
RFC 7518 JSON Web Algorithms (JWA) May 2015
6.3. RSA鍵のパラメータ
JWKはRSA [RFC3447]鍵を表現できます。この場合"kty"値は"RSA"です。
下記で定義されるパラメータの意味は、3.1および3.2、
RFC 3447本文と同じです。
6.3.1. RSA公開鍵のパラメータ
RSA公開鍵には下記のメンバが必須です。
6.3.1.1. "n"（法）パラメータ
"n"（法）パラメータはRSA公開鍵の法値を持ちます。Base64urlUIntエンコード値として表現されます。
実装者によると、一部暗号ライブラリは法表現の先頭に余分なゼロ値オクテットを付加する場合が
あり（例：2048ビット鍵で256オクテットでなく257オクテット返す等）、
そうしたライブラリを使う場合、base64urlエンコーディングの際は余分なオクテットを
省く必要があります。
6.3.1.2. "e"（指数）パラメータ
"e"（指数）パラメータはRSA公開鍵の指数値を持ち、Base64urlUIntエンコード値として表現されます。
例えば65537を表す際、base64urlエンコード対象オクテット列は[1,0,1]の三つで、
その表現は"AQAB"となります。
6.3.2. RSA秘密鍵のパラメータ
RSA公開鍵を表現するメンバーに加え、RSA秘密鍵表現に使うメンバーを以下に示します。
パラメータ"d"はRSA秘密鍵で必須です。
その他のパラメータは最適化用途であり、RSA秘密鍵値を持つJWKを生成する際は、
それらも含めることが推奨されます。いずれかを含める場合は"oth"を除きすべてが
必ず存在しなければなりません。"oth"は素因数が2より多い場合のみ必須です。
6.3.2.1. "d"（秘密指数）パラメータ
"d"（秘密指数）パラメータはRSA秘密鍵の秘密指数値です。Base64urlUIntエンコード値で表します。
Jones Standards Track [Page 30]
RFC 7518 JSON Web Algorithms (JWA) May 2015
6.3.2.2. "p"（第1素因数）パラメータ
"p"（第1素因数）パラメータは第1素因数を持ちます。Base64urlUIntエンコード値で表します。
6.3.2.3. "q"（第2素因数）パラメータ
"q"（第2素因数）パラメータは第2素因数を持ちます。Base64urlUIntエンコード値で表します。
6.3.2.4. "dp"（第1因数CRT指数）パラメータ
"dp"（第1因数CRT指数）パラメータは第1因数の中国剰余定理（CRT）指数を持ち、
Base64urlUIntエンコード値で表します。
6.3.2.5. "dq"（第2因数CRT指数）パラメータ
"dq"（第2因数CRT指数）パラメータは第2因数のCRT指数を持ち、
Base64urlUIntエンコード値で表します。
6.3.2.6. "qi"（第1CRT係数）パラメータ
"qi"（第1CRT係数）パラメータは第2因数のCRT係数を持ち、Base64urlUIntエンコード値で表します。
6.3.2.7. "oth"（追加素因数情報）パラメータ
"oth"（追加素因数情報）パラメータは3個目以降の素因数情報配列を持ちます。
通常は素因数が2で、このパラメータは省略します。3個以上の素因数が使われた場合は、
配列要素数は素因数数から2引いた数とします。
詳細はRFC3447付録A.1.2[RFC3447]のOtherPrimeInfo説明を参照。
JWK利用側が2素因数より多い秘密鍵未対応の場合、"oth"が存在するなら鍵使用禁止です。
各配列要素は以下のメンバーを持つオブジェクトでなければなりません。
6.3.2.7.1. "r"（素因数）
"oth"配列要素内の"r"（素因数）パラメータは追加の素因数値を表し、
Base64urlUIntエンコード値で表されます。
Jones Standards Track [Page 31]
RFC 7518 JSON Web Algorithms (JWA) May 2015
6.3.2.7.2. "d"（因数CRT指数）
"oth"配列要素内の"d"（因数CRT指数）パラメータは対応する素因数のCRT指数値を表し、
Base64urlUIntエンコード値で表されます。
6.3.2.7.3. "t"（因数CRT係数）
"oth"配列要素内の"t"（因数CRT係数）パラメータは対応する素因数のCRT係数値を表し、
Base64urlUIntエンコード値で表されます。
6.4. 対称鍵のパラメータ
JWKの"kty"値が"oct"（オクテット列）の場合、"k"（セクション6.4.1参照）で
対称鍵または単一値オクテット列である鍵を表します。
用いるアルゴリズムがアプリケーションで他に決まっていなければ、鍵と共に"alg"メンバー
も記述してアルゴリズムを特定すべきです。
6.4.1. "k"（鍵値）パラメータ
"k"（鍵値）パラメータは、対称鍵（またはその他単一値鍵）の値を持ちます。
これは鍵値オクテット列のbase64urlエンコードで表されます。
7. IANA考慮事項
本仕様で設ける各レジストリへの登録手順は次の通りです。
値の登録手順は「Specification Required」[RFC5226]であり、
jose-reg-review@ietf.orgメーリングリストで3週間レビュー後、
1名以上の指定専門家(Designated Experts)の助言で可能です。
発行前の値の確保が必要な場合、指定専門家が出版見込みに納得した場合には
早期登録も可能です。
レビュー申請は、件名を適切（例："Request to register algorithm: example"）にして
当該メーリングリストへ送信してください。
指定専門家はレビュー期間中に申請の認可または拒否を
レビューリスト及びIANAへ通知します。拒否時は理由と
必要に応じて成功させるための提案を含めるべきです。
Jones Standards Track [Page 32]
RFC 7518 JSON Web Algorithms (JWA) May 2015
21日以上結論の出ない登録申請は、iesg@ietf.orgメーリングリストを通じて
IESGに取り上げることができます。
指定専門家が適用すべき基準には、提案登録が既存機能の重複でないか、
一般的有用性があるか単一用途のみか、記述が明確かなどが含まれます。
IANAは指定専門家からのみレジストリ更新を受け付け、
すべての登録申請はレビューリストに誘導すべきです。
本仕様で使用するアプリケーションの多様な観点から幅広い判断を期待するため、
複数の指定専門家を任命しておくことを推奨します。
特定専門家が利害相反となる案件の場合、その専門家は他の専門家の判断に委ねるべきです。
7.1. JSON Web Signature and Encryption Algorithms Registry
本仕様は、JWSおよびJWEの"alg"（アルゴリズム）および"enc"（暗号化アルゴリズム）ヘッダ
パラメータ値のためのIANA「JSON Web Signature and Encryption Algorithms」レジストリを設けます。
このレジストリは、アルゴリズム名、説明、使用箇所、実装要件、変更管理者、仕様参照を記録します。
使用箇所の組が異なれば同じアルゴリズム名の重複登録も許容されます。
鍵長が異なるアルゴリズムのバリエーションを複数登録する場合や、
各バリエーションで鍵長が固定される場合（例:鍵導出関数を介する場合）には、
アルゴリズム名に鍵長を含めることを推奨します。
こうすることでJSONテキストを読む利用者がより容易にセキュリティ判断を下せます。
指定専門家は登録アルゴリズムが暗号的に信頼しうるか
（またはDeprecated/Prohibitedとして登録されているか）について合理的な調査を行うべきです。
Jones Standards Track [Page 33]
RFC 7518 JSON Web Algorithms (JWA) May 2015
暗号界の進展に伴い、アルゴリズムの実装要件が将来的に
DeprecatedやRecommended+やRequiredへの変更となることもあり得ます。
実装要件レベルの変更は、指定専門家によるレビュー及び新仕様規定を経た
「Specification Required」方式でのみ許されます。
7.1.1. 登録テンプレート
Algorithm Name:
要求される名前（例："HS256"）。ASCII大文字小文字区別の文字列。
Designated Expertsが特別に理由を認めない限り、他登録済み名との
大文字小文字無視一致は不可。
Algorithm Description:
アルゴリズムの簡単な説明（例："HMAC using SHA-256"）。
Algorithm Usage Location(s):
アルゴリズム利用箇所。JWSやJWE用途は"alg"または"enc"のいずれか・複数が必須。
JWK専用用途（JWS/JWEでの利用なし）は"JWK"を指定（例：認証なし暗号）。
その他用途追加は指定専門家承認で可能。
JOSE Implementation Requirements:
JWSおよびJWE用途での実装要件。Required、Recommended、Optional、Deprecated、
Prohibitedいずれかの語を用いる。語末に"+"または"-"を付記できる。
"+"は将来要件強度引き上げ可能性、"-"は引き下げ可能性を示唆。
認証なし暗号などJWS/JWE用途に不適切な識別子登録は必ず"Prohibited"指定。
Change Controller:
Standards Track RFCの場合"IESG"を記載。他は責任者名を記載。
追加で住所・メールアドレス・WebページURI等も可。
Jones Standards Track [Page 34]
RFC 7518 JSON Web Algorithms (JWA) May 2015
Specification Document(s):
パラメータを定義する文書（URI添付推奨）への参照。該当セクション指定も任意で可。
Algorithm Analysis Documents(s):
著名な暗号会議や標準機関・権威ある情報源による
アルゴリズムの安全性分析文献。指定専門家は新規アルゴリズムの安全性を
説得力ある証拠提出を求める場合があります（Deprecated/Prohibited登録除く）。
本文書の初期登録分はWG/IETFレビュー済みのため提出不要。
7.1.2. 初期レジストリ内容
o アルゴリズム名: "HS256"
o アルゴリズム説明: SHA-256を用いたHMAC
o アルゴリズム利用箇所: "alg"
o JOSE実装要件: 必須
o 変更管理者: IESG
o 仕様文書: RFC 7518のセクション3.2
o アルゴリズム解析文書: n/a
o アルゴリズム名: "HS384"
o アルゴリズム説明: SHA-384を用いたHMAC
o アルゴリズム利用箇所: "alg"
o JOSE実装要件: オプション
o 変更管理者: IESG
o 仕様文書: RFC 7518のセクション3.2
o アルゴリズム解析文書: n/a
o アルゴリズム名: "HS512"
o アルゴリズム説明: SHA-512を用いたHMAC
o アルゴリズム利用箇所: "alg"
o JOSE実装要件: オプション
o 変更管理者: IESG
o 仕様文書: RFC 7518のセクション3.2
o アルゴリズム解析文書: n/a
Jones Standards Track [Page 35]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o アルゴリズム名: "RS256"
o アルゴリズム説明: RSASSA-PKCS1-v1_5（SHA-256 使用）
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: 推奨
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 3.3
o アルゴリズム解析文書: n/a
o アルゴリズム名: "RS384"
o アルゴリズム説明: RSASSA-PKCS1-v1_5（SHA-384 使用）
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: オプション
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 3.3
o アルゴリズム解析文書: n/a
o アルゴリズム名: "RS512"
o アルゴリズム説明: RSASSA-PKCS1-v1_5（SHA-512 使用）
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: オプション
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 3.3
o アルゴリズム解析文書: n/a
o アルゴリズム名: "ES256"
o アルゴリズム説明: P-256 と SHA-256 を使用する ECDSA
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: 推奨+
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 3.4
o アルゴリズム解析文書: n/a
o アルゴリズム名: "ES384"
o アルゴリズム説明: P-384 と SHA-384 を使用する ECDSA
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: オプション
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 3.4
o アルゴリズム解析文書: n/a
o アルゴリズム名: "ES512"
o アルゴリズム説明: P-521 と SHA-512 を使用する ECDSA
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: オプション
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 3.4
o アルゴリズム解析文書: n/a
Jones Standards Track [Page 36]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o アルゴリズム名: "PS256"
o アルゴリズム説明: RSASSA-PSS（SHA-256 および MGF1 with SHA-256 使用）
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: オプション
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 3.5
o アルゴリズム解析文書: n/a
o アルゴリズム名: "PS384"
o アルゴリズム説明: RSASSA-PSS（SHA-384 および MGF1 with SHA-384 使用）
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: オプション
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 3.5
o アルゴリズム解析文書: n/a
o アルゴリズム名: "PS512"
o アルゴリズム説明: RSASSA-PSS（SHA-512 および MGF1 with SHA-512 使用）
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: オプション
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 3.5
o アルゴリズム解析文書: n/a
o アルゴリズム名: "none"
o アルゴリズム説明: デジタル署名または MAC を実行しない
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: オプション
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 3.6
o アルゴリズム解析文書: n/a
o アルゴリズム名: "RSA1_5"
o アルゴリズム説明: RSAES-PKCS1-v1_5
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: 推奨-
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 4.2
o アルゴリズム解析文書: n/a
Jones Standards Track [Page 37]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o アルゴリズム名: "RSA-OAEP"
o アルゴリズム説明: デフォルトパラメータを使用した RSAES OAEP
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: 推奨+
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 4.3
o アルゴリズム解析文書: n/a
o アルゴリズム名: "RSA-OAEP-256"
o アルゴリズム説明: SHA-256 および MGF1 with SHA-256 を使用する RSAES OAEP
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: オプション
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 4.3
o アルゴリズム解析文書: n/a
o アルゴリズム名: "A128KW"
o アルゴリズム説明: 128ビット鍵を使用する AES 鍵ラップ
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: 推奨
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 4.4
o アルゴリズム解析文書: n/a
o アルゴリズム名: "A192KW"
o アルゴリズム説明: 192ビット鍵を使用する AES 鍵ラップ
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: オプション
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 4.4
o アルゴリズム解析文書: n/a
o アルゴリズム名: "A256KW"
o アルゴリズム説明: 256ビット鍵を使用する AES 鍵ラップ
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: 推奨
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 4.4
o アルゴリズム解析文書: n/a
o アルゴリズム名: "dir"
o アルゴリズム説明: 共有対称鍵の直接使用
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: 推奨
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 4.5
o アルゴリズム解析文書: n/a
Jones Standards Track [Page 38]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o アルゴリズム名: "ECDH-ES"
o アルゴリズム説明: Concat KDF を使用する ECDH-ES
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: 推奨+
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 4.6
o アルゴリズム解析文書: n/a
o アルゴリズム名: "ECDH-ES+A128KW"
o アルゴリズム説明: Concat KDF と "A128KW" ラップを使用する ECDH-ES
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: 推奨
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 4.6
o アルゴリズム解析文書: n/a
o アルゴリズム名: "ECDH-ES+A192KW"
o アルゴリズム説明: Concat KDF と "A192KW" ラップを使用する ECDH-ES
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: オプション
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 4.6
o アルゴリズム解析文書: n/a
o アルゴリズム名: "ECDH-ES+A256KW"
o アルゴリズム説明: Concat KDF と "A256KW" ラップを使用する ECDH-ES
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: 推奨
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 4.6
o アルゴリズム解析文書: n/a
o アルゴリズム名: "A128GCMKW"
o アルゴリズム説明: 128ビット鍵を使用する AES GCM 鍵ラップ
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: オプション
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 4.7
o アルゴリズム解析文書: n/a
Jones Standards Track [Page 39]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o アルゴリズム名: "A192GCMKW"
o アルゴリズム説明: 192ビット鍵を使用する AES GCM 鍵ラップ
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: オプション
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 4.7
o アルゴリズム解析文書: n/a
o アルゴリズム名: "A256GCMKW"
o アルゴリズム説明: 256ビット鍵を使用する AES GCM 鍵ラップ
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: オプション
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 4.7
o アルゴリズム解析文書: n/a
o アルゴリズム名: "PBES2-HS256+A128KW"
o アルゴリズム説明: HMAC SHA-256 と "A128KW" ラップを用いる PBES2
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: オプション
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 4.8
o アルゴリズム解析文書: n/a
o アルゴリズム名: "PBES2-HS384+A192KW"
o アルゴリズム説明: HMAC SHA-384 と "A192KW" ラップを用いる PBES2
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: オプション
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 4.8
o アルゴリズム解析文書: n/a
o アルゴリズム名: "PBES2-HS512+A256KW"
o アルゴリズム説明: HMAC SHA-512 と "A256KW" ラップを用いる PBES2
o アルゴリズム使用場所: "alg"
o JOSE 実装要件: オプション
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 4.8
o アルゴリズム解析文書: n/a
Jones Standards Track [Page 40]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o アルゴリズム名: "A128CBC-HS256"
o アルゴリズム説明: AES_128_CBC_HMAC_SHA_256 認証付き暗号化アルゴリズム
o アルゴリズム使用場所: "enc"
o JOSE 実装要件: 必須
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 5.2.3
o アルゴリズム解析文書: n/a
o アルゴリズム名: "A192CBC-HS384"
o アルゴリズム説明: AES_192_CBC_HMAC_SHA_384 認証付き暗号化アルゴリズム
o アルゴリズム使用場所: "enc"
o JOSE 実装要件: オプション
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 5.2.4
o アルゴリズム解析文書: n/a
o アルゴリズム名: "A256CBC-HS512"
o アルゴリズム説明: AES_256_CBC_HMAC_SHA_512 認証付き暗号化アルゴリズム
o アルゴリズム使用場所: "enc"
o JOSE 実装要件: 必須
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 5.2.5
o アルゴリズム解析文書: n/a
o アルゴリズム名: "A128GCM"
o アルゴリズム説明: 128ビット鍵を使用する AES GCM
o アルゴリズム使用場所: "enc"
o JOSE 実装要件: 推奨
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 5.3
o アルゴリズム解析文書: n/a
o アルゴリズム名: "A192GCM"
o アルゴリズム説明: 192ビット鍵を使用する AES GCM
o アルゴリズム使用場所: "enc"
o JOSE 実装要件: オプション
o 変更管理者: IESG
o 仕様書: RFC 7518 の Section 5.3
o アルゴリズム解析文書: n/a
Jones Standards Track [Page 41]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o Algorithm Name: "A256GCM"
o Algorithm Description: 256ビット鍵を使用する AES GCM
o Algorithm Usage Location(s): "enc"
o JOSE Implementation Requirements: 推奨
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 5.3
o Algorithm Analysis Documents(s): 該当なし
7.2. ヘッダパラメータ名の登録
このセクションは、本仕様のセクション 4.6.1、4.7.1、および 4.8.1 で定義されたヘッダパラメータ名を、[JWS] によって確立された IANA の「JSON Web Signature and Encryption Header Parameters」レジストリに登録します。
7.2.1. 登録内容
o Header Parameter Name: "epk"
o Header Parameter Description: 一時的公開鍵
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 4.6.1.1
o Header Parameter Name: "apu"
o Header Parameter Description: 合意当事者 U 情報
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 4.6.1.2
o Header Parameter Name: "apv"
o Header Parameter Description: 合意当事者 V 情報
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 4.6.1.3
o Header Parameter Name: "iv"
o Header Parameter Description: 初期化ベクトル
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 4.7.1.1
o Header Parameter Name: "tag"
o Header Parameter Description: 認証タグ
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 4.7.1.2
Jones Standards Track [Page 42]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o Header Parameter Name: "p2s"
o Header Parameter Description: PBES2 ソルト入力
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 4.8.1.1
o Header Parameter Name: "p2c"
o Header Parameter Description: PBES2 カウント
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 4.8.1.2
7.3. JSON Web Encryption 圧縮アルゴリズム レジストリ
本仕様は、JWE の "zip" メンバ値のために IANA の「JSON Web Encryption Compression Algorithms」レジストリを確立します。レジストリには圧縮アルゴリズムの値と、それを定義する仕様への参照が記録されます。
7.3.1. 登録テンプレート
Compression Algorithm Value:
要求される名前（例："DEF"）。 本仕様の主要目的の一つは生成される表現をコンパクトにすることであるため、名前は短いことが推奨されます -- 正当な理由がない限り 8 文字を超えないこと。 この名前は大文字小文字を区別します。 指定された専門家が例外を認める正当な理由があると述べない限り、名前は大文字小文字を区別しない方法で他の登録済みの名前と一致してはなりません。
Compression Algorithm Description:
圧縮アルゴリズムの簡潔な説明（例："DEFLATE"）。
Change Controller:
Standards Track RFC の場合は "IESG" を記載します。その他の場合は責任ある当事者の名前を記載します。その他の詳細（例：郵便住所、電子メールアドレス、ホームページ URI）も含めることができます。
Specification Document(s):
パラメータを規定する文書への参照。可能であれば文書を取得するための URI を含めることを推奨します。関連する節の示しも任意で含められます。
Jones Standards Track [Page 43]
RFC 7518 JSON Web Algorithms (JWA) May 2015
7.3.2. 初期レジストリ内容
o Compression Algorithm Value: "DEF"
o Compression Algorithm Description: DEFLATE
o Change Controller: IESG
o Specification Document(s): JSON Web Encryption (JWE) [JWE]
7.4. JSON Web Key タイプ レジストリ
本仕様は、JWK の "kty"（鍵タイプ）パラメータの値のための IANA の「JSON Web Key Types」レジストリを確立します。レジストリは "kty" 値、実装要件、およびそれを定義する仕様への参照を記録します。
鍵タイプの実装要件は、暗号の状況に応じて将来変更されることがあります。例えば、鍵タイプの状態を非推奨（Deprecated）に変更したり、Optional から Recommended+ または Required に変更することなどです。実装要件の変更は、指定された専門家によるレビューの後に Specification Required の基準でのみ許可され、新しい仕様が改訂された実装要件レベルを定義します。
7.4.1. 登録テンプレート
"kty" Parameter Value:
要求される名前（例："EC"）。 本仕様の主要な目的の一つは表現をコンパクトにすることであるため、名前は短いことが推奨されます -- 正当な理由がない限り 8 文字を超えないこと。 この名前は大文字小文字を区別します。指定された専門家が例外を認める正当な理由があると述べない限り、名前は大文字小文字を区別しない方法で他の登録済みの名前と一致してはなりません。
Key Type Description:
鍵タイプの簡潔な説明（例："楕円曲線"）。
Change Controller:
Standards Track RFC の場合は "IESG" を記載します。その他の場合は責任ある当事者の名前を記載します。その他の詳細（例：郵便住所、電子メールアドレス、ホームページ URI）も含めることができます。
Jones Standards Track [Page 44]
RFC 7518 JSON Web Algorithms (JWA) May 2015
JOSE Implementation Requirements:
JWS および JWE に対する鍵タイプの実装要件で、"Required"、"Recommended"、"Optional"、"Deprecated"、または "Prohibited" のいずれかでなければなりません。省略可能で、語の後に "+" または "-" を付けることができます。"+" の使用は将来の仕様で要件強度が上がる可能性を示し、"-" の使用は将来の仕様で要件強度が下がる可能性を示します。
Specification Document(s):
パラメータを規定する文書への参照。可能であれば文書を取得するための URI を含めることを推奨します。関連する節の示しも任意で含められます。
7.4.2. 初期レジストリ内容
このセクションは、セクション 6.1 で定義された値を登録します。
o "kty" Parameter Value: "EC"
o Key Type Description: 楕円曲線
o JOSE Implementation Requirements: 推奨+
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 6.2
o "kty" Parameter Value: "RSA"
o Key Type Description: RSA
o JOSE Implementation Requirements: 必須
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 6.3
o "kty" Parameter Value: "oct"
o Key Type Description: オクテット列
o JOSE Implementation Requirements: 必須
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 6.4
7.5. JSON Web Key パラメータの登録
このセクションは、本仕様のセクション 6.2、6.3、および 6.4 で定義されたパラメータ名を、[JWK] によって確立された IANA の「JSON Web Key Parameters」レジストリに登録します。
Jones Standards Track [Page 45]
RFC 7518 JSON Web Algorithms (JWA) May 2015
7.5.1. 登録内容
o Parameter Name: "crv"
o Parameter Description: 曲線
o Used with "kty" Value(s): "EC"
o Parameter Information Class: 公開
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 6.2.1.1
o Parameter Name: "x"
o Parameter Description: X座標
o Used with "kty" Value(s): "EC"
o Parameter Information Class: 公開
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 6.2.1.2
o Parameter Name: "y"
o Parameter Description: Y座標
o Used with "kty" Value(s): "EC"
o Parameter Information Class: 公開
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 6.2.1.3
o Parameter Name: "d"
o Parameter Description: ECC 秘密鍵
o Used with "kty" Value(s): "EC"
o Parameter Information Class: 非公開
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 6.2.2.1
o Parameter Name: "n"
o Parameter Description: モジュラス
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: 公開
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 6.3.1.1
o Parameter Name: "e"
o Parameter Description: 指数
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: 公開
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 6.3.1.2
Jones Standards Track [Page 46]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o Parameter Name: "d"
o Parameter Description: 秘密指数
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: 非公開
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 6.3.2.1
o Parameter Name: "p"
o Parameter Description: 第1素因数
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: 非公開
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 6.3.2.2
o Parameter Name: "q"
o Parameter Description: 第2素因数
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: 非公開
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 6.3.2.3
o Parameter Name: "dp"
o Parameter Description: 第1因子 CRT 指数
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: 非公開
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 6.3.2.4
o Parameter Name: "dq"
o Parameter Description: 第2因子 CRT 指数
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: 非公開
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 6.3.2.5
o Parameter Name: "qi"
o Parameter Description: 第1 CRT 係数
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: 非公開
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 6.3.2.6
Jones Standards Track [Page 47]
RFC 7518 JSON Web Algorithms (JWA) May 2015
o Parameter Name: "oth"
o Parameter Description: その他の素数情報
o Used with "kty" Value(s): "RSA"
o Parameter Information Class: 非公開
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 6.3.2.7
o Parameter Name: "k"
o Parameter Description: 鍵値
o Used with "kty" Value(s): "oct"
o Parameter Information Class: 非公開
o Change Controller: IESG
o Specification Document(s): RFC 7518 のセクション 6.4.1
7.6. JSON Web Key 楕円曲線 レジストリ
本セクションは、JWK "crv" メンバ値のための IANA の「JSON Web Key Elliptic Curve」レジストリを確立します。レジストリは曲線名、実装要件、およびそれを定義する仕様への参照を記録します。本仕様はセクション 6.2.1.1 で定義されたパラメータ名を登録します。
曲線の実装要件は、暗号の状況に応じて将来変更されることがあります。例えば、曲線の状態を非推奨にする、あるいは Optional から Recommended+ または Required に変更することなどです。実装要件の変更は、指定された専門家によるレビューの後に Specification Required の基準でのみ許可され、新しい仕様が改訂された実装要件レベルを定義します。
7.6.1. 登録テンプレート
Curve Name:
要求される名前（例："P-256"）。 本仕様の主要目的の一つは表現をコンパクトにすることであるため、名前は短いことが推奨されます -- 正当な理由がない限り 8 文字を超えないこと。 この名前は大文字小文字を区別します。指定された専門家が例外を認める正当な理由があると述べない限り、名前は大文字小文字を区別しない方法で他の登録済みの名前と一致してはなりません。
Curve Description:
曲線の簡潔な説明（例："P-256 曲線"）。
JOSE Implementation Requirements:
JWS および JWE に対する曲線の実装要件で、"Required"、"Recommended"、"Optional"、"Deprecated"、または "Prohibited" のいずれかでなければなりません。省略可能で、語の後に "+" または "-" を付けることができます。
Jones Standards Track [Page 48]
RFC 7518 JSON Web Algorithms (JWA) May 2015
「+」の使用は、仕様の将来のバージョンで要件の強さが増加する可能性が高いことを示します。 「-」の使用は、仕様の将来のバージョンで要件の強さが減少する可能性が高いことを示します。
Change Controller:
Standards Track の RFC では "IESG" と記載します。 その他の場合は、責任のある団体または個人の名前を記載します。 その他の詳細（例：郵便住所、電子メールアドレス、ホームページの URI）を含めることもできます。
Specification Document(s):
パラメータを指定する文書または文書群への参照。 文書のコピーを取得するために使用できる URI を含めることが望ましいです。 関連するセクションの表示を含めてもよいですが、必須ではありません。
7.6.2. Initial Registry Contents
o Curve Name: "P-256"
o Curve Description: P-256 Curve
o JOSE Implementation Requirements: Recommended+
o Change Controller: IESG
o Specification Document(s): Section 6.2.1.1 of RFC 7518
o Curve Name: "P-384"
o Curve Description: P-384 Curve
o JOSE Implementation Requirements: Optional
o Change Controller: IESG
o Specification Document(s): Section 6.2.1.1 of RFC 7518
o Curve Name: "P-521"
o Curve Description: P-521 Curve
o JOSE Implementation Requirements: Optional
o Change Controller: IESG
o Specification Document(s): Section 6.2.1.1 of RFC 7518
8. Security Considerations
暗号アプリケーションに関係するすべてのセキュリティ問題は、JWS/JWE/JWK エージェントによって対処されなければなりません。 これらの問題には、ユーザーの非対称秘密鍵や対称秘密鍵の保護、およびさまざまな攻撃に対する対策の実施が含まれます。
[AES]、 [DSS]、 [JWE]、 [JWK]、 [JWS]、
[NIST.800-38D]、 [NIST.800-56A]、 [NIST.800-107]、 [RFC2104]、 [RFC3394]、
[RFC3447]、 [RFC5116]、 [RFC6090]、 および [SHS] に記載されたセキュリティ考慮事項は、本仕様に適用されます。
Jones Standards Track [Page 49]
RFC 7518 JSON Web Algorithms (JWA) May 2015
8.1. Cryptographic Agility
実装者は暗号アルゴリズムが時間経過とともに弱くなることに注意すべきです。 新たな暗号解析手法が開発され、計算性能が向上するにつれて、特定の暗号アルゴリズムを破るための作業量は低下します。 したがって、実装者および導入者はサポートされ使用されるアルゴリズムの集合が時間とともに変化することに備える必要があります。 このため、暗号アルゴリズム実装はモジュラーであるべきで、新しいアルゴリズムを容易に挿入できるようにするべきです。
8.2. Key Lifetimes
多くのアルゴリズムには、鍵の寿命や鍵を使用できる回数に関連するセキュリティ上の考慮事項があります。 これらのセキュリティ考慮事項は、JOSE データ構造でこれらのアルゴリズムを使用する際にも引き続き適用されます。 鍵の寿命に関する具体的なガイダンスについては、NIST SP 800-57 [NIST.800-57] を参照してください。
8.3. RSAES-PKCS1-v1_5 Security Considerations
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" の セクション 3 に記載されているような、低い公開鍵指数値を持つ鍵は使用してはなりません [Boneh99]。
8.4. AES GCM Security Considerations
AES GCM に使用される鍵は [NIST.800-38D] のセクション 8.3 の制約に従う必要があります。そこには「認証付き暗号化関数の呼び出し総数は、すべての IV 長と与えられた鍵での認証付き暗号化関数のすべてのインスタンスを含めて 2^32 を超えてはならない」と記載されています。 この規則に従い、AES GCM は同一の鍵値で 2^32 回を超えて使用してはなりません。
IV 値は同じ AES GCM 鍵で複数回使用してはなりません。 これを防ぐ一つの方法は、鍵と共にカウンタを保存し、使用ごとにインクリメントすることです。 そのカウンタは上記の 2^32 の制限を超えないようにするためにも使用できます。
このセキュリティに関する考慮事項は、複合 AES-CBC HMAC SHA-2 または AES Key Wrap アルゴリズムには適用されません。
Jones Standards Track [Page 50]
RFC 7518 JSON Web Algorithms (JWA) May 2015
8.5. Unsecured JWS Security Considerations
Unsecured JWS（"alg" 値が "none" を使用する JWS）は整合性保護を提供しません。 したがって、ペイロードがデジタル署名や MAC 値とは別の手段で保護されている文脈、または保護が不要な文脈でのみ使用されなければなりません。
デフォルトで Unsecured JWS の受け入れを防ぐ一例として、仮想的な JWS ソフトウェアライブラリの "verify" メソッドにブール型の "acceptUnsecured" パラメータを持たせ、"none" が許容される "alg" 値であることを示す方法があります。 別の例として、"verify" メソッドがアプリケーションで許容されるアルゴリズムのリストをパラメータとして受け取り、そのリストに "none" が含まれていない場合は Unsecured JWS 値を拒否する、という方法があります。
次の例は、グローバルレベルで Unsecured JWS を受け入れない理由を示しています。 あるアプリケーションが 2 つのチャネル、(1) HTTP と (2) クライアント認証付き HTTPS を通じて JWS を受け入れるとします。 HTTP 経由で受け取るオブジェクトについては JWS 署名を要求しますが、HTTPS 経由では Unsecured JWS を受け入れます。 もしアプリケーションがグローバルに "none" を許容すると示した場合、攻撃者は HTTP 経由で Unsecured JWS を提供してもそのオブジェクトが有効と見なされてしまう可能性があります。 代わりに、アプリケーションは HTTPS 経由で受け取る各オブジェクトについて "none" の受け入れを示す必要があります（例：上記の仮想的な JWS ソフトウェアライブラリの "acceptUnsecured" を "true" に設定する等）。 しかし HTTP 経由で受け取る各オブジェクトについては示す必要はありません。
8.6. Denial-of-Service Attacks
署名を検証する受信エージェントやメッセージを暗号化する送信エージェントは、署名の検証や仕様で規定されるより大きな鍵を使用したメッセージの暗号化時の暗号処理の使用量に注意する必要があります。 攻撃者は、過度の暗号処理を引き起こすような鍵（例えば、本仕様で規定されるものより大きな鍵）を用いてコンテンツを提供する可能性があります。 実装は受け入れる鍵サイズに上限を設定し、それを強制するべきです。 NIST SP 800-57 の セクション 5.6.1（Comparable Algorithm Strengths）には適用可能な最大承認鍵サイズに関する記述があります [NIST.800-57]。
8.7. Reusing Key Material when Encrypting Keys
複数の JWK または JWK Set オブジェクトを暗号化するため、または同じ JWK または JWK Set オブジェクトを複数回暗号化するために、同一の完全な鍵素材セット（Key Encryption Key、Content Encryption Key、Initialization Vector 等）を再利用することは推奨されません。 これを防ぐための一案としては、各暗号化操作ごとに少なくとも一つの新しい鍵素材（例：新しい Content Encryption Key、新しい IV、および/または新しい PBES2 Salt）を常に生成することが挙げられます。 これは本書および RFC 4086 に記載された考慮事項に基づく提案です。
Jones Standards Track [Page 51]
RFC 7518 JSON Web Algorithms (JWA) May 2015
再利用を防ぐための提案は、各暗号化操作ごとに少なくとも一つの新しい鍵素材（例：新しい Content Encryption Key、新しい IV、および/または新しい PBES2 Salt）を常に生成することです。 これは本書に記載された考慮事項および RFC 4086 の考慮に基づくものです [RFC4086]。
8.8. Password Considerations
パスワードは多数の攻撃に対して脆弱です。 これらの制限のいくつかを軽減するために、本ドキュメントはユーザー提供のパスワードから暗号鍵を導出するために RFC 2898 の原則を適用します。
しかしながら、パスワードの強度は依然として重要な影響を持ちます。 高エントロピーのパスワードは辞書攻撃に対する耐性が高くなります。 パスワードのエントロピー推定に関するガイドラインは [NIST.800-63-2] に記載されており、アプリケーションやユーザーがより強力なパスワードを生成するのに役立ちます。
理想的なパスワードは派生鍵長と同等かそれ以上の長さです。 しかしながら、あるアルゴリズム固有のサイズより大きいパスワードは最初にハッシュされ、攻撃者の有効な探索空間がハッシュアルゴリズムの長さに制限されることになります。 "PBES2-HS256+A128KW" に使用されるパスワードは 16 オクテット以上 128 オクテット以下、"PBES2-HS512+A256KW" に使用されるパスワードは 32 オクテット以上 128 オクテット以下であることが推奨されます。
それでも、パスワードベースの暗号化をどこでどのように使用するかには注意が必要です。 これらのアルゴリズムは、反復回数が小さすぎると辞書ベースの攻撃に対して依然として脆弱であり得ます。 特に、ファイルシステムに保存された保護されたデータのように、攻撃者が無制限に試行できるデータを保護するためにこれらのアルゴリズムが使用される場合は問題となります。
8.9. Key Entropy and Random Values
鍵エントロピーおよび乱数に関するセキュリティ考慮事項については、[JWS] のセクション 10.1 を参照してください。
8.10. Differences between Digital Signatures and MACs
デジタル署名と MAC の違いに関するセキュリティ考慮事項については、[JWS] のセクション 10.5 を参照してください。
Jones Standards Track [Page 52]
RFC 7518 JSON Web Algorithms (JWA) May 2015
8.11. Using Matching Algorithm Strengths
マッチングするアルゴリズム強度の使用に関するセキュリティ考慮事項については、[JWE] のセクション 11.3 を参照してください。
8.12. Adaptive Chosen-Ciphertext Attacks
適応選択暗号文攻撃に関するセキュリティ考慮事項については、[JWE] のセクション 11.4 を参照してください。
8.13. Timing Attacks
タイミング攻撃に関するセキュリティ考慮事項については、[JWS] のセクション 10.9 および [JWE] の セクション 11.5 を参照してください。
8.14. RSA Private Key Representations and Blinding
RSA の秘密鍵表現とブラインディングに関するセキュリティ考慮事項については、[JWK] のセクション 9.3 を参照してください。
9. Internationalization Considerations
ユーザーから取得したパスワードは、異なる入力デバイスやロケールなどによって生成されるオクテット列の違いに対応するために、準備や正規化が必要になる可能性があります。 ユーザーが直接提供したパスワードを鍵導出および暗号化を行う前に準備するために、アプリケーションは [PRECIS] に記載された手順を実行することが推奨されます。
10. References
10.1. Normative References
[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>.
[Boneh99] "Twenty Years of Attacks on the RSA Cryptosystem", 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 Standards Track [Page 53]
RFC 7518 JSON Web Algorithms (JWA) May 2015
[DSS] National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", FIPS PUB 186-4, July
2013, <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, May 2015,
<http://www.rfc-editor.org/info/rfc7516>.
[JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<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, May
2015, <http://www.rfc-editor.org/info/rfc7515>.
[NIST.800-38A]
National Institute of Standards and Technology (NIST),
"Recommendation for Block Cipher Modes of Operation", NIST
Special Publication 800-38A, December 2001,
<http://csrc.nist.gov/publications/nistpubs/800-38a/
sp800-38a.pdf>.
[NIST.800-38D]
National Institute of Standards and Technology (NIST),
"Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC", NIST Special
Publication 800-38D, December 2001,
<http://csrc.nist.gov/publications/nistpubs/800-38D/
SP-800-38D.pdf>.
[NIST.800-56A]
National Institute of Standards and Technology (NIST),
"Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography", NIST Special
Publication 800-56A, Revision 2, May 2013,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Ar2.pdf>.
[NIST.800-57]
National Institute of Standards and Technology (NIST),
"Recommendation for Key Management - Part 1: General
(Revision 3)", NIST Special Publication 800-57, Part 1,
Revision 3, July 2012, <http://csrc.nist.gov/publications/
nistpubs/800-57/sp800-57_part1_rev3_general.pdf>.
Jones Standards Track [Page 54]
RFC 7518 JSON Web Algorithms (JWA) May 2015
[RFC20] Cerf, V., "ASCII format for Network Interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<http://www.rfc-editor.org/info/rfc20>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898,
DOI 10.17487/RFC2898, September 2000,
<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,
September 2002, <http://www.rfc-editor.org/info/rfc3394>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256,
HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007,
<http://www.rfc-editor.org/info/rfc4868>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>.
Jones Standards Track [Page 55]
RFC 7518 JSON Web Algorithms (JWA) May 2015
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090,
DOI 10.17487/RFC6090, February 2011,
<http://www.rfc-editor.org/info/rfc6090>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>.
[SEC1] Standards for Efficient Cryptography Group, "SEC 1:
Elliptic Curve Cryptography", Version 2.0, May 2009,
<http://www.secg.org/sec1-v2.pdf>.
[SHS] National Institute of Standards and Technology (NIST),
"Secure Hash Standard (SHS)", FIPS PUB 180-4, March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>.
[UNICODE] The Unicode Consortium, "The Unicode Standard",
<http://www.unicode.org/versions/latest/>.
10.2. Informative References
[AEAD-CBC-SHA]
McGrew, D., Foley, J., and K. Paterson, "Authenticated
Encryption with AES-CBC and HMAC-SHA", Work in Progress,
draft-mcgrew-aead-aes-cbc-hmac-sha2-05, July 2014.
[CanvasApp]
Facebook, "Canvas Applications", 2010,
<http://developers.facebook.com/docs/authentication/
canvas>.
[JCA] Oracle, "Java Cryptography Architecture (JCA) Reference
Guide", 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", 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, March 2011.
[JSS] Bradley, J. and N. Sakimura, Ed., "JSON Simple Sign 1.0",
Draft 01, September 2010, <http://jsonenc.info/jss/1.0/>.
Jones Standards Track [Page 56]
RFC 7518 JSON Web Algorithms (JWA) May 2015
[JWE-JWK] Miller, M., "Using JavaScript Object Notation (JSON) Web
Encryption (JWE) for Protecting JSON Web Key (JWK)
Objects", Work in Progress,
draft-miller-jose-jwe-protected-jwk-02, June 2013.
[MagicSignatures]
Panzer, J., Ed., Laurie, B., and D. Balfanz, "Magic
Signatures", January 2011,
<http://salmon-protocol.googlecode.com/svn/trunk/
draft-panzer-magicsig-01.html>.
[NIST.800-107]
National Institute of Standards and Technology (NIST),
"Recommendation for Applications Using Approved Hash
Algorithms", NIST Special Publication 800-107, Revision 1,
August 2012, <http://csrc.nist.gov/publications/
nistpubs/800-107-rev1/sp800-107-rev1.pdf>.
[NIST.800-63-2]
National Institute of Standards and Technology (NIST),
"Electronic Authentication Guideline", NIST Special
Publication 800-63-2, August 2013,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-63-2.pdf>.
[PRECIS] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", Work in Progress,
draft-ietf-precis-saslprepbis-16, April 2015.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, DOI 10.17487/RFC2631, June 1999,
<http://www.rfc-editor.org/info/rfc2631>.
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible
Markup Language) XML-Signature Syntax and Processing",
RFC 3275, DOI 10.17487/RFC3275, March 2002,
<http://www.rfc-editor.org/info/rfc3275>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<http://www.rfc-editor.org/info/rfc5116>.
Jones Standards Track [Page 57]
RFC 7518 JSON Web Algorithms (JWA) May 2015
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<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 Signature
Syntax and Processing Version 2.0", World Wide Web
Consortium Note NOTE-xmldsig-core2-20130411, April 2013,
<http://www.w3.org/TR/2013/NOTE-xmldsig-core2-20130411/>.
[W3C.REC-xmlenc-core-20021210]
Eastlake, D. and J. Reagle, "XML Encryption Syntax and
Processing", World Wide Web Consortium Recommendation REC-
xmlenc-core-20021210, December 2002,
<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 Encryption Syntax and Processing Version 1.1", World
Wide Web Consortium Recommendation REC-xmlenc-
core1-20130411, April 2013,
<http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/>.
Jones Standards Track [Page 58]
RFC 7518 JSON Web Algorithms (JWA) May 2015
Appendix A. Algorithm Identifier Cross-Reference
This appendix contains tables cross-referencing the cryptographic
algorithm identifier values defined in this specification with the
equivalent identifiers used by other standards and software packages.
See 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], and Java Cryptography Architecture
[JCA] for more information about the names defined by those
documents.
Jones Standards Track [Page 59]
RFC 7518 JSON Web Algorithms (JWA) May 2015
A.1. Digital Signature/MAC Algorithm Identifier Cross-Reference
This section contains a table cross-referencing the JWS digital
signature and MAC "alg" (algorithm) values defined in this
specification with the equivalent identifiers used by other standards
and software packages.
+-------------------------------------------------------------------+
| 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 Standards Track [Page 60]
RFC 7518 JSON Web Algorithms (JWA) May 2015
A.2. Key Management Algorithm Identifier Cross-Reference
This section contains a table cross-referencing the JWE "alg"
(algorithm) values defined in this specification with the equivalent
identifiers used by other standards and software packages.
+-------------------------------------------------------------------+
| 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 Standards Track [Page 61]
RFC 7518 JSON Web Algorithms (JWA) May 2015
A.3. Content Encryption Algorithm Identifier Cross-Reference
This section contains a table cross-referencing the JWE "enc"
(encryption algorithm) values defined in this specification with the
equivalent identifiers used by other standards and software packages.
For the composite algorithms "A128CBC-HS256", "A192CBC-HS384", and
"A256CBC-HS512", the corresponding AES-CBC algorithm identifiers are
listed.
+-------------------------------------------------------------------+
| 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 |
+-------------------------------------------------------------------+
Appendix B. Test Cases for AES_CBC_HMAC_SHA2 Algorithms
The following test cases can be used to validate implementations of
the AES_CBC_HMAC_SHA2 algorithms defined in Section 5.2. They are
also intended to correspond to test cases that may appear in a future
version of [AEAD-CBC-SHA], demonstrating that the cryptographic
computations performed are the same.
The variable names are those defined in Section 5.2. All values are
hexadecimal.
Jones Standards Track [Page 62]
RFC 7518 JSON Web Algorithms (JWA) May 2015
B.1. Test Cases for 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 Standards Track [Page 63]
RFC 7518 JSON Web Algorithms (JWA) May 2015
B.2. Test Cases for 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 Standards Track [Page 64]
RFC 7518 JSON Web Algorithms (JWA) May 2015
B.3. Test Cases for 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 Standards Track [Page 65]
RFC 7518 JSON Web Algorithms (JWA) May 2015
Appendix C. Example ECDH-ES Key Agreement Computation
This example uses ECDH-ES Key Agreement and the Concat KDF to derive
the CEK in the manner described in Section 4.6. In this example, the
ECDH-ES Direct Key Agreement mode ("alg" value "ECDH-ES") is used to
produce an agreed-upon key for AES GCM with a 128-bit key ("enc"
value "A128GCM").
In this example, a producer Alice is encrypting content to a consumer
Bob. The producer (Alice) generates an ephemeral key for the key
agreement computation. Alice's ephemeral key (in JWK format) used
for the key agreement computation in this example (including the
private part) is:
{"kty":"EC",
"crv":"P-256",
"x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
"y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps",
"d":"0_NxaRPUMQoAJt50Gz8YiTr8gRTwyEaCumd-MToTmIo"
}
The consumer's (Bob's) key (in JWK format) used for the key agreement
computation in this example (including the private part) is:
{"kty":"EC",
"crv":"P-256",
"x":"weNJy2HscCSM6AEDTDg04biOvhFhyyWvOHQfeF_PxMQ",
"y":"e8lnCO-AlStT-NJVX-crhB7QRYhiix03illJOVAOyck",
"d":"VEmDZpDXXK8p8N0Cndsxs924q6nS1RXFASRl6BfUqdw"
}
Header Parameter values used in this example are as follows. The
"apu" (agreement PartyUInfo) Header Parameter value is the base64url
encoding of the UTF-8 string "Alice" and the "apv" (agreement
PartyVInfo) Header Parameter value is the base64url encoding of the
UTF-8 string "Bob". The "epk" (ephemeral public key) Header
Parameter is used to communicate the producer's (Alice's) ephemeral
public key value to the consumer (Bob).
Jones Standards Track [Page 66]
RFC 7518 JSON Web Algorithms (JWA) May 2015
{"alg":"ECDH-ES",
"enc":"A128GCM",
"apu":"QWxpY2U",
"apv":"Qm9i",
"epk":
{"kty":"EC",
"crv":"P-256",
"x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
"y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps"
}
}
The resulting Concat KDF [NIST.800-56A] parameter values are:
Z
This is set to the ECDH-ES key agreement output. (This value is
often not directly exposed by libraries, due to NIST security
requirements, and only serves as an input to a KDF.) In this
example, Z is following the octet sequence (using JSON array
notation):
[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
This value is 128 - the number of bits in the desired output key
(because "A128GCM" uses a 128-bit key).
AlgorithmID
This is set to the octets representing the 32-bit big-endian value
7 - [0, 0, 0, 7] - the number of octets in the AlgorithmID content
"A128GCM", followed, by the octets representing the ASCII string
"A128GCM" - [65, 49, 50, 56, 71, 67, 77].
PartyUInfo
This is set to the octets representing the 32-bit big-endian value
5 - [0, 0, 0, 5] - the number of octets in the PartyUInfo content
"Alice", followed, by the octets representing the UTF-8 string
"Alice" - [65, 108, 105, 99, 101].
PartyVInfo
This is set to the octets representing the 32-bit big-endian value
3 - [0, 0, 0, 3] - the number of octets in the PartyUInfo content
"Bob", followed, by the octets representing the UTF-8 string "Bob"
- [66, 111, 98].
Jones Standards Track [Page 67]
RFC 7518 JSON Web Algorithms (JWA) May 2015
SuppPubInfo
This is set to the octets representing the 32-bit big-endian value
128 - [0, 0, 0, 128] - the keydatalen value.
SuppPrivInfo
This is set to the empty octet sequence.
Concatenating the parameters AlgorithmID through SuppPubInfo results
in an OtherInfo value of:
[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]
Concatenating the round number 1 ([0, 0, 0, 1]), Z, and the OtherInfo
value results in the Concat KDF round 1 hash input of:
[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]
The resulting derived key, which is the first 128 bits of the round 1
hash output is:
[86, 170, 141, 234, 248, 35, 109, 32, 92, 34, 40, 205, 113, 167, 16,
26]
The base64url-encoded representation of this derived key is:
VqqN6vgjbSBcIijNcacQGg
Jones Standards Track [Page 68]
RFC 7518 JSON Web Algorithms (JWA) May 2015
Acknowledgements
Solutions for signing and encrypting JSON content were previously
explored by "Magic Signatures" [MagicSignatures], "JSON Simple Sign
1.0" [JSS], "Canvas Applications" [CanvasApp], "JSON Simple
Encryption" [JSE], and "JavaScript Message Security Format" [JSMS],
all of which influenced this document.
The "Authenticated Encryption with AES-CBC and HMAC-SHA"
[AEAD-CBC-SHA] specification, upon which the AES_CBC_HMAC_SHA2
algorithms are based, was written by David A. McGrew and Kenny
Paterson. The test cases for AES_CBC_HMAC_SHA2 are based upon those
for [AEAD-CBC-SHA] by John Foley.
Matt Miller wrote "Using JavaScript Object Notation (JSON) Web
Encryption (JWE) for Protecting JSON Web Key (JWK) Objects"
[JWE-JWK], upon which the password-based encryption content of this
document is based.
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:
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 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.
Author's Address
Michael B. Jones
Microsoft
EMail: mbj@microsoft.com
URI: http://self-issued.info/
Jones Standards Track [Page 69]