RFC 7518: JSON Web Algorithms (JWA)（日本語訳）

3. Cryptographic Algorithms for Digital Signatures and MACs

3. デジタル署名およびMACのための暗号アルゴリズム

JWS uses cryptographic algorithms to digitally sign or create a MAC of the contents of the JWS Protected Header and the JWS Payload.

JWSは、JWS Protected HeaderとJWS Payloadの内容をデジタル署名またはMACの作成に使用する暗号アルゴリズムを使用します。

3.1. "alg" (Algorithm) Header Parameter Values for JWS

3.1. "alg" (アルゴリズム) JWS のヘッダーパラメーター値

The table below is the set of "alg" (algorithm) Header Parameter values defined by this specification for use with JWS, each of which is explained in more detail in the following sections:

以下の表は、JWSで使用するためにこの仕様で定義された「alg」（アルゴリズム）ヘッダーパラメーター値のセットであり、それぞれについては以下のセクションで詳しく説明されています。

"alg" Param Value	Digital Signature or MAC Algorithm	Implementation Requirements
HS256	HMAC using SHA-256	Required
HS384	HMAC using SHA-384	Optional
HS512	HMAC using SHA-512	Optional
RS256	RSASSA-PKCS1-v1_5 using SHA-256	Recommended
RS384	RSASSA-PKCS1-v1_5 using SHA-384	Optional
RS512	RSASSA-PKCS1-v1_5 using SHA-512	Optional
ES256	ECDSA using P-256 and SHA-256	Recommended+
ES384	ECDSA using P-384 and SHA-384	Optional
ES512	ECDSA using P-521 and SHA-512	Optional
PS256	RSASSA-PSS using SHA-256 and MGF1 with SHA-256	Optional
PS384	RSASSA-PSS using SHA-384 and MGF1 with SHA-384	Optional
PS512	RSASSA-PSS using SHA-512 and MGF1 with SHA-512	Optional
none	No digital signature or MAC performed	Optional

"alg" Param Value	Digital Signature or MAC Algorithm	Implementation Requirements
HS256	HMAC using SHA-256	Required
HS384	HMAC using SHA-384	Optional
HS512	HMAC using SHA-512	Optional
RS256	RSASSA-PKCS1-v1_5 using SHA-256	Recommended
RS384	RSASSA-PKCS1-v1_5 using SHA-384	Optional
RS512	RSASSA-PKCS1-v1_5 using SHA-512	Optional
ES256	ECDSA using P-256 and SHA-256	Recommended+
ES384	ECDSA using P-384 and SHA-384	Optional
ES512	ECDSA using P-521 and SHA-512	Optional
PS256	RSASSA-PSS using SHA-256 and MGF1 with SHA-256	Optional
PS384	RSASSA-PSS using SHA-384 and MGF1 with SHA-384	Optional
PS512	RSASSA-PSS using SHA-512 and MGF1 with SHA-512	Optional
none	No digital signature or MAC performed	Optional

The use of "+" in the Implementation Requirements column indicates that the requirement strength is likely to be increased in a future version of the specification.

実装要件列での「+」の使用は、要件の強度が将来のバージョンで高められる可能性があることを示しています。

See Appendix A.1 for 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デジタル署名およびMAC「alg」（アルゴリズム）値を他の標準およびソフトウェアパッケージで使用される同等の識別子と相互参照する表については、付録A.1を参照してください。

3.2. HMAC with SHA-2 Functions

3.2. SHA-2 関数を用いた HMAC

Hash-based Message Authentication Codes (HMACs) enable one to use a secret plus a cryptographic hash function to generate a MAC. This can be used to demonstrate that whoever generated the MAC was in possession of the MAC key. The algorithm for implementing and validating HMACs is provided in RFC 2104 [RFC2104].

ハッシュベースのメッセージ認証コード（HMAC）を使用すると、秘密鍵と暗号ハッシュ関数を使用してMACを生成できます。これにより、MACを生成した人物がMACキーを所有していたことを示すことができます。 HMACを実装および検証するためのアルゴリズムは、RFC 2104[RFC2104]で提供されています。

A key of the same size as the hash output (for instance, 256 bits for "HS256") or larger MUST be used with this algorithm. (This requirement is based on Section 5.3.4 (Security Effect of the HMAC Key) of NIST SP 800-117 [NIST.800-107], which states that the effective security strength is the minimum of the security strength of the key and two times the size of the internal hash value.)

このアルゴリズムでは、ハッシュ出力と同じサイズのキー（たとえば、「HS256」の場合は256ビット）またはそれ以上のキーを使用しなければなりません（MUST）。これは、NIST SP 800-117[NIST.800-107]のセクション5.3.4（HMACキーのセキュリティー効果）に基づく要件であり、このセクションは、効果的なセキュリティー強度が、キーのセキュリティー強度と内部ハッシュ値の2倍のサイズの最小値であることを示しています。

The HMAC SHA-256 MAC is generated per RFC 2104, using SHA-256 as the hash algorithm "H", using the JWS Signing Input as the "text" value, and using the shared key. The HMAC output value is the JWS Signature.

HMAC SHA-256 MACは、RFC 2104にしたがって生成されます。ハッシュアルゴリズム「H」としてSHA-256を使用し、「text」値としてJWS Signing Inputを使用し、共有キーを使用します。 HMAC出力値はJWS Signatureです。

The following "alg" (algorithm) Header Parameter values are used to indicate that the JWS Signature is an HMAC value computed using the corresponding algorithm:

次の「alg」（アルゴリズム）ヘッダーパラメーター値は、対応するアルゴリズムを使用してJWS SignatureがHMAC値であることを示すために使用されます。

"alg" Param Value	MAC Algorithm
HS256	HMAC using SHA-256
HS384	HMAC using SHA-384
HS512	HMAC using SHA-512

"alg" パラメーター値	MAC アルゴリズム
HS256	SHA-256 を使用した HMAC
HS384	SHA-384 を使用した HMAC
HS512	SHA-512 を使用した HMAC

The HMAC SHA-256 MAC for a JWS is validated by computing an HMAC value per RFC 2104, using SHA-256 as the hash algorithm "H", using the received JWS Signing Input as the "text" value, and using the shared key. This computed HMAC value is then compared to the result of base64url decoding the received encoded JWS Signature value. The comparison of the computed HMAC value to the JWS Signature value MUST be done in a constant-time manner to thwart timing attacks. Alternatively, the computed HMAC value can be base64url encoded and compared to the received encoded JWS Signature value (also in a constant-time manner), as this comparison produces the same result as comparing the unencoded values. In either case, if the values match, the HMAC has been validated.

JWSのHMAC SHA-256 MACは、RFC 2104にしたがって、ハッシュアルゴリズム「H」としてSHA-256を使用し、受信したJWS Signing Inputを「text」値として使用し、共有キーを使用してHMAC値を計算することによって検証されます。この計算されたHMAC値は、受信したエンコードされたJWS Signature値をbase64urlデコードした結果と比較されます。タイミング攻撃を防ぐために、計算されたHMAC値とJWS Signature値の比較は定数時間で行われる必要があります（MUST）。値が一致する場合、HMACは検証されたことになります。また、計算されたHMAC値をbase64urlエンコードして、受信したエンコードされたJWS Signature値と比較することもできます（これも定数時間で行われます）。この比較は、エンコードされていない値を比較する場合と同じ結果を生み出します。いずれの場合でも、値が一致する場合、HMACは検証されたことになります。

Securing content and validation with the HMAC SHA-384 and HMAC SHA-512 algorithms is performed identically to the procedure for HMAC SHA-256 -- just using the corresponding hash algorithms with correspondingly larger minimum key sizes and result values: 384 bits each for HMAC SHA-384 and 512 bits each for HMAC SHA-512.

HMAC SHA-384およびHMAC SHA-512アルゴリズムを使用してコンテンツを保護し、検証する手順は、HMAC SHA-256の手順と同様に実行されます。ただし、対応するハッシュアルゴリズムを使用し、それに応じて大きな最小キーサイズと結果値を使用します。HMAC SHA-384の場合は384ビット、HMAC SHA-512の場合は512ビットです。

An example using this algorithm is shown in Appendix A.1 of [JWS].

このアルゴリズムを使用した例については、[JWS]の付録A.1に示されています。

3.3. Digital Signature with RSASSA-PKCS1-v1_5

3.3. RSASSA-PKCS1-v1_5 によるデジタル署名

This section defines the use of the RSASSA-PKCS1-v1_5 digital signature algorithm as defined in Section 8.2 of RFC 3447 [RFC3447] (commonly known as PKCS #1), using SHA-2 [SHS] hash functions.

このセクションでは、RFC 3447[RFC3447]のセクション8.2で定義されているRSASSA-PKCS1-v1_5デジタル署名アルゴリズム（一般的にはPKCS＃1として知られています）を、SHA-2[SHS]ハッシュ関数を使用して定義します。

A key of size 2048 bits or larger MUST be used with these algorithms.

これらのアルゴリズムには、2048ビット以上の鍵を使用しなければなりません（MUST）。

The RSASSA-PKCS1-v1_5 SHA-256 digital signature is generated as follows: generate a digital signature of the JWS Signing Input using RSASSA-PKCS1-v1_5-SIGN and the SHA-256 hash function with the desired private key. This is the JWS Signature value.

RSASSA-PKCS1-v1_5 SHA-256デジタル署名は、次のように生成されます。所望の秘密鍵を使用して、RSASSA-PKCS1-v1_5-SIGNおよびSHA-256ハッシュ関数を使用して、JWS Signing Inputのデジタル署名を生成します。これがJWS Signature値です。

The following "alg" (algorithm) Header Parameter values are used to indicate that the JWS Signature is a digital signature value computed using the corresponding algorithm:

次の「alg」（アルゴリズム）ヘッダーパラメーター値は、対応するアルゴリズムを使用してJWS Signatureがデジタル署名値であることを示すために使用されます。

"alg" Param Value	Digital Signature Algorithm
RS256	RSASSA-PKCS1-v1_5 using SHA-256
RS384	RSASSA-PKCS1-v1_5 using SHA-384
RS512	RSASSA-PKCS1-v1_5 using SHA-512

"alg" パラメーターの値	デジタル署名アルゴリズム
RS256	RSASSA-PKCS1-v1_5（SHA-256 を使用）
RS384	RSASSA-PKCS1-v1_5（SHA-384 を使用）
RS512	RSASSA-PKCS1-v1_5（SHA-512 を使用）

The RSASSA-PKCS1-v1_5 SHA-256 digital signature for a JWS is validated as follows: submit the JWS Signing Input, the JWS Signature, and the public key corresponding to the private key used by the signer to the RSASSA-PKCS1-v1_5-VERIFY algorithm using SHA-256 as the hash function.

JWSのRSASSA-PKCS1-v1_5 SHA-256デジタル署名は、次のように検証されます。JWS Signing Input、JWS Signature、および署名者が使用した秘密鍵に対応する公開鍵を、SHA-256をハッシュ関数として使用して、RSASSA-PKCS1-v1_5-VERIFYアルゴリズムに提出します。

Signing and validation with the RSASSA-PKCS1-v1_5 SHA-384 and RSASSA- PKCS1-v1_5 SHA-512 algorithms is performed identically to the procedure for RSASSA-PKCS1-v1_5 SHA-256 -- just using the corresponding hash algorithms instead of SHA-256.

RSASSA-PKCS1-v1_5 SHA-384およびRSASSA-PKCS1-v1_5 SHA-512アルゴリズムを使用した署名および検証は、RSASSA-PKCS1-v1_5 SHA-256の手順とまったく同じ方法で実行されます。ただし、SHA-256の代わりに対応するハッシュアルゴリズムが使用されます。

An example using this algorithm is shown in Appendix A.2 of [JWS].

このアルゴリズムを使用した例については、[JWS]の付録A.2に示されています。

3.4. Digital Signature with ECDSA

3.4. ECDSA によるデジタル署名

The Elliptic Curve Digital Signature Algorithm (ECDSA) [DSS] provides for the use of Elliptic Curve Cryptography, which is able to provide equivalent security to RSA cryptography but using shorter key sizes and with greater processing speed for many operations. This means that ECDSA digital signatures will be substantially smaller in terms of length than equivalently strong RSA digital signatures.

楕円曲線デジタル署名アルゴリズム（ECDSA）[DSS]は、楕円曲線暗号を使用することを提供し、RSA暗号と同等のセキュリティーを提供できますが、より短い鍵サイズを使用し、多くの操作に対して処理速度が高速です。これは、ECDSAデジタル署名が、同等に強力なRSAデジタル署名に比べて、長さが大幅に小さくなることを意味します。

This specification defines the use of ECDSA with the P-256 curve and the SHA-256 cryptographic hash function, ECDSA with the P-384 curve and the SHA-384 hash function, and ECDSA with the P-521 curve and the SHA-512 hash function. The P-256, P-384, and P-521 curves are defined in [DSS].

この仕様では、P-256曲線とSHA-256暗号ハッシュ関数、P-384曲線とSHA-384ハッシュ関数、およびP-521曲線とSHA-512ハッシュ関数を使用したECDSAの使用を定義しています。P-256、P-384、およびP-521曲線は、[DSS]で定義されています。

The ECDSA P-256 SHA-256 digital signature is generated as follows:

ECDSA P-256 SHA-256デジタル署名は、次のように生成されます。

1. Generate a digital signature of the JWS Signing Input using ECDSA P-256 SHA-256 with the desired private key. The output will be the pair (R, S), where R and S are 256-bit unsigned integers.

1. 所望の秘密鍵を使用して、ECDSA P-256 SHA-256を使用してJWS Signing Inputのデジタル署名を生成します。出力は、RとSのペアであり、RとSは256ビットの符号なし整数です。

2. Turn R and S into octet sequences in big-endian order, with each array being be 32 octets long. The octet sequence representations MUST NOT be shortened to omit any leading zero octets contained in the values.

2. RとSをビッグエンディアン順序のオクテットシーケンスに変換します。各配列は32オクテットの長さになります。オクテットシーケンスの表現には、値に含まれる先頭のゼロオクテットを省略してはなりません（MUST NOT）。

3. Concatenate the two octet sequences in the order R and then S. (Note that many ECDSA implementations will directly produce this concatenation as their output.)

3. RとSの順序で2つのオクテットシーケンスを連結します。（多くのECDSA実装は、直接この連結を出力として生成します。）

4. The resulting 64-octet sequence is the JWS Signature value.

4. 結果の64オクテットシーケンスがJWS Signature値です。

The following "alg" (algorithm) Header Parameter values are used to indicate that the JWS Signature is a digital signature value computed using the corresponding algorithm:

"alg" Param Value	Digital Signature Algorithm
ES256	ECDSA using P-256 and SHA-256
ES384	ECDSA using P-384 and SHA-384
ES512	ECDSA using P-521 and SHA-512

"alg" パラメーターの値	デジタル署名アルゴリズム
ES256	P-256 および SHA-256 を使用した ECDSA
ES384	P-384 および SHA-384 を使用した ECDSA
ES512	P-521 および SHA-512 を使用した ECDSA

The ECDSA P-256 SHA-256 digital signature for a JWS is validated as follows:

JWSのECDSA P-256 SHA-256デジタル署名は、次のように検証されます。

1. The JWS Signature value MUST be a 64-octet sequence. If it is not a 64-octet sequence, the validation has failed.

1. JWSの署名値は、64オクテットのシーケンスである必要があります。もし64オクテットのシーケンスでない場合、検証は失敗します。

2. Split the 64-octet sequence into two 32-octet sequences. The first octet sequence represents R and the second S. The values R and S are represented as octet sequences using the Integer-to- OctetString Conversion defined in Section 2.3.7 of SEC1 [SEC1] (in big-endian octet order).

2. 64オクテットのシーケンスを2つの32オクテットのシーケンスに分割します。最初のオクテットシーケンスはRを表し、2番目のシーケンスはSを表します。値RとSは、SEC1のセクション2.3.7で定義されたInteger-to-OctetString Conversionを使用して、ビッグエンディアンのオクテット順で表されるオクテットシーケンスとして表されます。[SEC1]

3. Submit the JWS Signing Input, R, S, and the public key (x, y) to the ECDSA P-256 SHA-256 validator.

3. JWSの署名入力、R、S、および公開鍵（x、y）をECDSA P-256 SHA-256バリデータに提出します。

Signing and validation with the ECDSA P-384 SHA-384 and ECDSA P-521 SHA-512 algorithms is performed identically to the procedure for ECDSA P-256 SHA-256 -- just using the corresponding hash algorithms with correspondingly larger result values. For ECDSA P-384 SHA-384, R and S will be 384 bits each, resulting in a 96-octet sequence. For ECDSA P-521 SHA-512, R and S will be 521 bits each, resulting in a 132-octet sequence. (Note that the Integer-to-OctetString Conversion defined in Section 2.3.7 of SEC1 [SEC1] used to represent R and S as octet sequences adds zero-valued high-order padding bits when needed to round the size up to a multiple of 8 bits; thus, each 521-bit integer is represented using 528 bits in 66 octets.)

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のセクション2.3.7で定義されたInteger-to-OctetString Conversionは、必要に応じてサイズを8ビットの倍数に切り上げるためのゼロ値の高位パディングビットを追加します。したがって、各521ビットの整数は、66オクテットの528ビットを使用して表されます。）

Examples using these algorithms are shown in Appendices A.3 and A.4 of [JWS].

これらのアルゴリズムを使用した例については、[JWS]の付録A.3およびA.4を参照してください。

3.5. Digital Signature with RSASSA-PSS

3.5. RSASSA-PSS によるデジタル署名

This section defines the use of the RSASSA-PSS digital signature algorithm as defined in Section 8.1 of RFC 3447 [RFC3447] with the MGF1 mask generation function and SHA-2 hash functions, always using the same hash function for both the RSASSA-PSS hash function and the MGF1 hash function. The size of the salt value is the same size as the hash function output. All other algorithm parameters use the defaults specified in Appendix A.2.3 of RFC 3447.

このセクションでは、MGF1マスク生成関数とSHA-2ハッシュ関数を使用し、常にRSASSA-PSSハッシュ関数とMGF1ハッシュ関数に同じハッシュ関数を使用する、RFC 3447 [RFC3447]のセクション8.1で定義されたRSASSA-PSSデジタル署名アルゴリズムの使用を定義します。ソルト値のサイズは、ハッシュ関数の出力と同じサイズです。その他のアルゴリズムパラメーターは、RFC 3447の付録A.2.3で指定されたデフォルト値を使用します。

A key of size 2048 bits or larger MUST be used with this algorithm.

このアルゴリズムでは、2048ビット以上の鍵を使用しなければなりません（MUST）。

The RSASSA-PSS SHA-256 digital signature is generated as follows: generate a digital signature of the JWS Signing Input using RSASSA- PSS-SIGN, the SHA-256 hash function, and the MGF1 mask generation function with SHA-256 with the desired private key. This is the JWS Signature value.

RSASSA-PSS SHA-256デジタル署名は、次のように生成されます。所望の秘密鍵を使用して、RSASSA-PSS-SIGN、SHA-256ハッシュ関数、およびMGF1マスク生成関数を使用して、JWS Signing Inputのデジタル署名を生成します。これがJWS Signature値です。

The following "alg" (algorithm) Header Parameter values are used to indicate that the JWS Signature is a digital signature value computed using the corresponding algorithm:

"alg" Param Value	Digital Signature Algorithm
PS256	RSASSA-PSS using SHA-256 and MGF1 with SHA-256
PS384	RSASSA-PSS using SHA-384 and MGF1 with SHA-384
PS512	RSASSA-PSS using SHA-512 and MGF1 with SHA-512

"alg" パラメーターの値	デジタル署名アルゴリズム
PS256	SHA-256 および MGF1 を使用した RSASSA-PSS
PS384	SHA-384 および MGF1 を使用した RSASSA-PSS
PS512	SHA-512 および MGF1 を使用した RSASSA-PSS

The RSASSA-PSS SHA-256 digital signature for a JWS is validated as follows: submit the JWS Signing Input, the JWS Signature, and the public key corresponding to the private key used by the signer to the RSASSA-PSS-VERIFY algorithm using SHA-256 as the hash function and using MGF1 as the mask generation function with SHA-256.

JWSのRSASSA-PSS SHA-256デジタル署名は、次のように検証されます。JWS Signing Input、JWS Signature、および署名者が使用した秘密鍵に対応する公開鍵を、SHA-256をハッシュ関数として使用して、MGF1をマスク生成関数として使用するRSASSA-PSS-VERIFYアルゴリズムに提出します。

Signing and validation with the RSASSA-PSS SHA-384 and RSASSA-PSS SHA-512 algorithms is performed identically to the procedure for RSASSA-PSS SHA-256 -- just using the alternative hash algorithm in both roles.

RSASSA-PSS SHA-384およびRSASSA-PSS SHA-512アルゴリズムを使用した署名および検証は、RSASSA-PSS SHA-256の手順とまったく同じ方法で実行されます。ただし、両方の役割で代替ハッシュアルゴリズムを使用するだけです。

3.6. Using the Algorithm "none"

3.6. アルゴリズム "none" の使用

JWSs MAY also be created that do not provide integrity protection. Such a JWS is called an Unsecured JWS. An Unsecured JWS uses the "alg" value "none" and is formatted identically to other JWSs, but MUST use the empty octet sequence as its JWS Signature value. Recipients MUST verify that the JWS Signature value is the empty octet sequence.

JWSには、整合性保護を提供しないものも作成できます。このようなJWSは、Unsecured JWSと呼ばれます。Unsecured JWSは「alg」値「none」を使用し、他のJWSと同じ形式でフォーマットされますが、JWS Signature値として空のオクテットシーケンスを使用しなければなりません（MUST）。受信者は、JWS Signature値が空のオクテットシーケンスであることを確認しなければなりません（MUST）。

Implementations that support Unsecured JWSs MUST NOT accept such objects as valid unless the application specifies that it is acceptable for a specific object to not be integrity protected. Implementations MUST NOT accept Unsecured JWSs by default. In order to mitigate downgrade attacks, applications MUST NOT signal acceptance of Unsecured JWSs at a global level, and SHOULD signal acceptance on a per-object basis. See Section 8.5 for security considerations associated with using this algorithm.

Unsecured JWSをサポートする実装は、アプリケーションが特定のオブジェクトが整合性保護されていないことを受け入れ可能であると指定していない限り、そのようなオブジェクトを有効なものとして受け入れてはなりません（MUST NOT）。実装は、デフォルトでUnsecured JWSを受け入れてはなりません（MUST NOT）。ダウングレード攻撃を緩和するために、アプリケーションは、Unsecured JWSの受け入れをグローバルレベルでシグナルしてはなりません（MUST NOT）。また、オブジェクトごとに受け入れをシグナルすべきです（SHOULD）。このアルゴリズムを使用する際のセキュリティーに関連する考慮事項については、セクション8.5を参照してください。

4. Cryptographic Algorithms for Key Management

4. 鍵管理のための暗号アルゴリズム

JWE uses cryptographic algorithms to encrypt or determine the Content Encryption Key (CEK).

JWEは、暗号化アルゴリズムを使用してContent Encryption Key（CEK）を暗号化または決定します。

4.1. "alg" (Algorithm) Header Parameter Values for JWE

4.1. JWE のための "alg" (Algorithm) ヘッダーパラメーターの値

The table below is the set of "alg" (algorithm) Header Parameter values that are defined by this specification for use with JWE. These algorithms are used to encrypt the CEK, producing the JWE Encrypted Key, or to use key agreement to agree upon the CEK.

以下の表は、この仕様で定義されたJWEで使用するための「alg」（アルゴリズム）ヘッダーパラメーター値のセットです。これらのアルゴリズムは、CEKを暗号化してJWE Encrypted Keyを生成するために使用されるか、または鍵合意を使用してCEKに同意するために使用されます。

"alg" Param Value	Key Management Algorithm	More Header Params	Implementation Requirements
RSA1_5	RSAES-PKCS1-v1_5	(none)	Recommended-
RSA-OAEP	RSAES OAEP using default parameters	(none)	Recommended+
RSA-OAEP-256	RSAES OAEP using SHA-256 and MGF1 with SHA-256	(none)	Optional
A128KW	AES Key Wrap with default initial value using 128-bit key	(none)	Recommended
A192KW	AES Key Wrap with default initial value using 192-bit key	(none)	Optional
A256KW	AES Key Wrap with default initial value using 256-bit key	(none)	Recommended
dir	Direct use of a shared symmetric key as the CEK	(none)	Recommended
ECDH-ES	Elliptic Curve Diffie-Hellman Ephemeral Static key agreement using Concat KDF	"epk", "apu", "apv"	Recommended+
ECDH-ES+A128KW	ECDH-ES using Concat KDF and CEK wrapped with "A128KW"	"epk", "apu", "apv"	Recommended
ECDH-ES+A192KW	ECDH-ES using Concat KDF and CEK wrapped with "A192KW"	"epk", "apu", "apv"	Optional
ECDH-ES+A256KW	ECDH-ES using Concat KDF and CEK wrapped with "A256KW"	"epk", "apu", "apv"	Recommended
A128GCMKW	Key wrapping with AES GCM using 128-bit key	"iv", "tag"	Optional
A192GCMKW	Key wrapping with AES GCM using 192-bit key	"iv", "tag"	Optional
A256GCMKW	Key wrapping with AES GCM using 256-bit key	"iv", "tag"	Optional
PBES2-HS256+A128KW	PBES2 with HMAC SHA-256 and "A128KW" wrapping	"p2s", "p2c"	Optional
PBES2-HS384+A192KW	PBES2 with HMAC SHA-384 and "A192KW" wrapping	"p2s", "p2c"	Optional
PBES2-HS512+A256KW	PBES2 with HMAC SHA-512 and "A256KW" wrapping	"p2s", "p2c"	Optional

"alg" パラメーターの値	鍵管理アルゴリズム	その他のヘッダーパラメーター	実装要件
RSA1_5	RSAES-PKCS1-v1_5	(なし)	推奨
RSA-OAEP	RSAES OAEP（デフォルトパラメーターを使用）	(なし)	推奨+
RSA-OAEP-256	RSAES OAEP（SHA-256 および MGF1 with SHA-256 を使用）	(なし)	オプション
A128KW	AES Key Wrap（デフォルト初期値を使用、128-bit キー）	(なし)	推奨
A192KW	AES Key Wrap（デフォルト初期値を使用、192-bit キー）	(なし)	オプション
A256KW	AES Key Wrap（デフォルト初期値を使用、256-bit キー）	(なし)	推奨
dir	共有対称鍵を直接使用	(なし)	推奨
ECDH-ES	楕円曲線 Diffie-Hellman Ephemeral Static 鍵合意（Concat KDF を使用）	"epk"、「apu」、「apv」	推奨+
ECDH-ES+A128KW	ECDH-ES（Concat KDF を使用）および "A128KW" で CEK をラップ	"epk"、「apu」、「apv」	推奨
ECDH-ES+A192KW	ECDH-ES（Concat KDF を使用）および "A192KW" で CEK をラップ	"epk"、「apu」、「apv」	オプション
ECDH-ES+A256KW	ECDH-ES（Concat KDF を使用）および "A256KW" で CEK をラップ	"epk"、「apu」、「apv」	推奨
A128GCMKW	AES GCM でのキーラップ（128-bit キー）	"iv"、「tag」	オプション
A192GCMKW	AES GCM でのキーラップ（192-bit キー）	"iv"、「tag」	オプション
A256GCMKW	AES GCM でのキーラップ（256-bit キー）	"iv"、「tag」	オプション
PBES2-HS256+A128KW	PBES2（HMAC SHA-256 を使用）および "A128KW" でラップ	"p2s"、「p2c」	オプション
PBES2-HS384+A192KW	PBES2（HMAC SHA-384 を使用）および "A192KW" でラップ	"p2s"、「p2c」	オプション
PBES2-HS512+A256KW	PBES2（HMAC SHA-512 を使用）および "A256KW" でラップ	"p2s"、「p2c」	オプション

The More Header Params column indicates what additional Header Parameters are used by the algorithm, beyond "alg", which all use. All but "dir" and "ECDH-ES" also produce a JWE Encrypted Key value.

More Header Params列は、すべてのアルゴリズムが使用する「alg」以外の追加のヘッダーパラメーターを示します。「dir」と「ECDH-ES」以外のすべてのアルゴリズムは、JWE Encrypted Key値を生成します。

The use of "+" in the Implementation Requirements column indicates that the requirement strength is likely to be increased in a future version of the specification. The use of "-" indicates that the requirement strength is likely to be decreased in a future version of the specification.

実装要件列での「+」の使用は、要件の強度が将来の仕様のバージョンで高められる可能性があることを示します。「-」の使用は、要件の強度が将来の仕様のバージョンで低下する可能性があることを示します。

See Appendix A.2 for 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「alg」（アルゴリズム）値と、他の標準やソフトウェアパッケージで使用される同等の識別子との対応表については、付録A.2を参照してください。

4.2. Key Encryption with RSAES-PKCS1-v1_5

4.2. RSAES-PKCS1-v1_5 による鍵の暗号化

This section defines the specifics of encrypting a JWE CEK with RSAES-PKCS1-v1_5 [RFC3447]. The "alg" (algorithm) Header Parameter value "RSA1_5" is used for this algorithm.

このセクションでは、RSAES-PKCS1-v1_5 [RFC3447]を使用してJWE CEKを暗号化する方法について定義します。「alg」（アルゴリズム）ヘッダーパラメーター値「RSA1_5」がこのアルゴリズムに使用されます。

A key of size 2048 bits or larger MUST be used with this algorithm.

このアルゴリズムでは、2048ビット以上の鍵を使用しなければなりません（MUST）。

An example using this algorithm is shown in Appendix A.2 of [JWE].

このアルゴリズムを使用した例については、[JWE]の付録A.2を参照してください。

4.3. Key Encryption with RSAES OAEP

4.3. RSAES OAEP による鍵の暗号化

This section defines the specifics of encrypting a JWE CEK with RSAES using Optimal Asymmetric Encryption Padding (OAEP) [RFC3447]. Two sets of parameters for using OAEP are defined, which use different hash functions. In the first case, the default parameters specified in Appendix A.2.1 of RFC 3447 are used. (Those default parameters are the SHA-1 hash function and the MGF1 with SHA-1 mask generation function.) In the second case, the SHA-256 hash function and the MGF1 with SHA-256 mask generation function are used.

このセクションでは、Optimal Asymmetric Encryption Padding（OAEP）[RFC3447]を使用してJWE CEKを暗号化する方法の詳細を定義します。OAEPを使用するために定義された2つのパラメーターセットがあり、それぞれ異なるハッシュ関数を使用します。最初の場合、RFC 3447の付録A.2.1で指定されたデフォルトパラメーターが使用されます（これらのデフォルトパラメーターは、SHA-1ハッシュ関数とSHA-1マスク生成関数を使用するMGF1です）。2番目の場合、SHA-256ハッシュ関数とSHA-256マスク生成関数を使用します。

The following "alg" (algorithm) Header Parameter values are used to indicate that the JWE Encrypted Key is the result of encrypting the CEK using the corresponding algorithm:

次の「alg」（アルゴリズム）ヘッダーパラメーター値が使用され、対応するアルゴリズムを使用してJWE Encrypted KeyがCEKを暗号化した結果であることを示します。

"alg" Param Value	Key Management Algorithm
RSA-OAEP	RSAES OAEP using default parameters
RSA-OAEP-256	RSAES OAEP using SHA-256 and MGF1 with SHA-256

"alg" パラメーターの値	鍵管理アルゴリズム
RSA-OAEP	RSAES OAEP（デフォルトパラメーターを使用）
RSA-OAEP-256	RSAES OAEP（SHA-256 および MGF1 with SHA-256 を使用）

A key of size 2048 bits or larger MUST be used with these algorithms. (This requirement is based on Table 4 (Security-strength time frames) of NIST SP 800-57 [NIST.800-57], which requires 112 bits of security for new uses, and Table 2 (Comparable strengths) of the same, which states that 2048-bit RSA keys provide 112 bits of security.)

これらのアルゴリズムを使用する場合、2048ビット以上の鍵を使用しなければなりません（MUST）。（この要件は、NIST SP 800-57の表4（セキュリティー強度の時間枠）に基づいています。新しい用途には112ビットのセキュリティーが必要であり、同じ表の表2（同等の強度）では、2048ビットのRSA鍵が112ビットのセキュリティーを提供すると述べています。）

An example using RSAES OAEP with the default parameters is shown in Appendix A.1 of [JWE].

デフォルトパラメーターを使用したRSAES OAEPを使用した例については、[JWE]の付録A.1を参照してください。

4.4. Key Wrapping with AES Key Wrap

4.4. AES キー Wrap による鍵のラッピング

This section defines the specifics of encrypting a JWE CEK with the Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] using the default initial value specified in Section 2.2.3.1 of that document.

このセクションでは、Advanced Encryption Standard（AES）Key Wrap Algorithm [RFC3394]を使用してJWE CEKを暗号化する方法の詳細を定義します。このドキュメントのセクション2.2.3.1で指定されたデフォルトの初期値を使用します。

The following "alg" (algorithm) Header Parameter values are used to indicate that the JWE Encrypted Key is the result of encrypting the CEK using the corresponding algorithm and key size:

次の「alg」（アルゴリズム）ヘッダーパラメーター値が使用され、対応するアルゴリズムと鍵サイズを使用して、JWE Encrypted KeyがCEKを暗号化した結果であることを示します。

"alg" Param Value	Key Management Algorithm
A128KW	AES Key Wrap with default initial value using 128-bit key
A192KW	AES Key Wrap with default initial value using 192-bit key
A256KW	AES Key Wrap with default initial value using 256-bit key

"alg" パラメーターの値	鍵管理アルゴリズム
A128KW	デフォルト初期値を使用した AES Key Wrap（128-bit キー）
A192KW	デフォルト初期値を使用した AES Key Wrap（192-bit キー）
A256KW	デフォルト初期値を使用した AES Key Wrap（256-bit キー）

An example using this algorithm is shown in Appendix A.3 of [JWE].

このアルゴリズムを使用した例については、[JWE]の付録A.3を参照してください。

4.5. Direct Encryption with a Shared Symmetric Key

4.5. 共有対称鍵による直接暗号化

This section defines the specifics of directly performing symmetric key encryption without performing a key wrapping step. In this case, the shared symmetric key is used directly as the Content Encryption Key (CEK) value for the "enc" algorithm. An empty octet sequence is used as the JWE Encrypted Key value. The "alg" (algorithm) Header Parameter value "dir" is used in this case.

このセクションでは、キーのラッピングステップを実行せずに直接対称鍵暗号化を実行する方法の詳細を定義します。この場合、共有対称鍵はContent Encryption Key（CEK）値として直接使用されます。「JWE Encrypted Key」値として空のオクテットシーケンスが使用されます。「alg」（アルゴリズム）ヘッダーパラメーター値「dir」がこの場合に使用されます。

Refer to the security considerations on key lifetimes in Section 8.2 and AES GCM in Section 8.4 when considering utilizing direct encryption.

直接暗号化を利用する場合は、セクション8.2のキーライフタイムに関するセキュリティー上の考慮事項と、セクション8.4のAES GCMに関する考慮事項を参照してください。

4.6. Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static

(ECDH-ES)

This section defines the specifics of key agreement with Elliptic Curve Diffie-Hellman Ephemeral Static [RFC6090], in combination with the Concat KDF, as defined in Section 5.8.1 of [NIST.800-56A]. The key agreement result can be used in one of two ways:

このセクションでは、Elliptic Curve Diffie-Hellman Ephemeral Static [RFC6090]と組み合わせて、Concat KDF（セクション5.8.1 of [NIST.800-56A]で定義）を使用した鍵合意の詳細を定義します。鍵合意の結果は、次の2つの方法のいずれかで使用できます。

1. directly as the Content Encryption Key (CEK) for the "enc" algorithm, in the Direct Key Agreement mode, or

1. 直接的に「enc」アルゴリズムのContent Encryption Key（CEK）として使用する場合は、Direct Key Agreementモードで使用します。

2. as a symmetric key used to wrap the CEK with the "A128KW", "A192KW", or "A256KW" algorithms, in the Key Agreement with Key Wrapping mode.

2. 「A128KW」、「A192KW」、または「A256KW」アルゴリズムを使用してCEKをラップするために使用される対称鍵として使用する場合は、Key Agreement with Key Wrappingモードで使用します。

A new ephemeral public key value MUST be generated for each key agreement operation.

鍵合意操作ごとに新しいエフェメラル公開鍵値を生成しなければなりません（MUST）。

In Direct Key Agreement mode, the output of the Concat KDF MUST be a key of the same length as that used by the "enc" algorithm. In this case, the empty octet sequence is used as the JWE Encrypted Key value. The "alg" (algorithm) Header Parameter value "ECDH-ES" is used in the Direct Key Agreement mode.

Direct Key Agreementモードでは、Concat KDFの出力は「enc」アルゴリズムで使用される鍵と同じ長さの鍵である必要があります（MUST）。この場合、空のオクテットシーケンスがJWE Encrypted Keyの値として使用されます。「alg」（アルゴリズム）ヘッダーパラメーター値「ECDH-ES」がDirect Key Agreementモードで使用されます。

In Key Agreement with Key Wrapping mode, the output of the Concat KDF MUST be a key of the length needed for the specified key wrapping algorithm. In this case, the JWE Encrypted Key is the CEK wrapped with the agreed-upon key.

Key Agreement with Key Wrappingモードでは、Concat KDFの出力は、指定されたキーラッピングアルゴリズムに必要な長さの鍵である必要があります（MUST）。この場合、JWE Encrypted Keyは、合意された鍵でCEKがラップされたものです。

The following "alg" (algorithm) Header Parameter values are used to indicate that the JWE Encrypted Key is the result of encrypting the CEK using the result of the key agreement algorithm as the key encryption key for the corresponding key wrapping algorithm:

次の「alg」（アルゴリズム）ヘッダーパラメーター値は、鍵合意アルゴリズムの結果を対応するキーラッピングアルゴリズムの鍵暗号化キーとして使用してCEKを暗号化した結果がJWE Encrypted Keyであることを示すために使用されます。

"alg" Param Value	Key Management Algorithm
ECDH-ES+A128KW	ECDH-ES using Concat KDF and CEK wrapped with "A128KW"
ECDH-ES+A192KW	ECDH-ES using Concat KDF and CEK wrapped with "A192KW"
ECDH-ES+A256KW	ECDH-ES using Concat KDF and CEK wrapped with "A256KW"

"alg" パラメーターの値	鍵管理アルゴリズム
ECDH-ES+A128KW	ECDH-ES（Concat KDF を使用）および CEK を "A128KW" でラップ
ECDH-ES+A192KW	ECDH-ES（Concat KDF を使用）および CEK を "A192KW" でラップ
ECDH-ES+A256KW	ECDH-ES（Concat KDF を使用）および CEK を "A256KW" でラップ

4.6.1. Header Parameters Used for ECDH Key Agreement

4.6.1. ECDH 鍵共有に使用されるヘッダーパラメーター

The following Header Parameter names are used for key agreement as defined below.

以下のヘッダーパラメーター名は、以下で定義される鍵合意に使用されます。

4.6.1.1. "epk" (Ephemeral Public Key) Header Parameter

4.6.1.1. "epk" (Ephemeral Public Key) ヘッダーパラメーター

The "epk" (ephemeral public key) value created by the originator for the use in key agreement algorithms. This key is represented as a JSON Web Key [JWK] public key value. It MUST contain only public key parameters and SHOULD contain only the minimum JWK parameters necessary to represent the key; other JWK parameters included can be checked for consistency and honored, or they can be ignored. This Header Parameter MUST be present and MUST be understood and processed by implementations when these algorithms are used.

鍵合意アルゴリズムで使用するために、送信者が作成した「epk」（エフェメラル公開鍵）値です。このキーは、JSON Web Key [JWK]の公開鍵値として表されます。このキーには、公開鍵パラメーターのみを含め、キーを表現するために必要な最小限のJWKパラメーターのみを含める必要があります（MUST）。他のJWKパラメーターが含まれている場合は、整合性を確認して採用するか、無視することができます。このヘッダーパラメーターは必ず存在しなければなりません（MUST）。これらのアルゴリズムが使用される場合、このヘッダーパラメーターは理解され処理される必要があります（MUST）。

4.6.1.2. "apu" (Agreement PartyUInfo) Header Parameter

4.6.1.2. "apu" (Agreement PartyUInfo) ヘッダーパラメーター

The "apu" (agreement PartyUInfo) value for key agreement algorithms using it (such as "ECDH-ES"), represented as a base64url-encoded string. When used, the PartyUInfo value contains information about the producer. Use of this Header Parameter is OPTIONAL. This Header Parameter MUST be understood and processed by implementations when these algorithms are used.

鍵合意アルゴリズム（「ECDH-ES」など）で使用する「apu」（agreement PartyUInfo）値は、base64urlエンコードされた文字列として表されます。使用される場合、PartyUInfo値にはプロデューサーに関する情報が含まれます。このヘッダーパラメーターの使用は選択できます（OPTIONAL）。これらのアルゴリズムが使用される場合、このヘッダーパラメーターは理解され処理される必要があります（MUST）。

4.6.1.3. "apv" (Agreement PartyVInfo) Header Parameter

4.6.1.3. "apv" (Agreement PartyVInfo) ヘッダーパラメーター

The "apv" (agreement PartyVInfo) value for key agreement algorithms using it (such as "ECDH-ES"), represented as a base64url encoded string. When used, the PartyVInfo value contains information about the recipient. Use of this Header Parameter is OPTIONAL. This Header Parameter MUST be understood and processed by implementations when these algorithms are used.

鍵合意アルゴリズム（「ECDH-ES」など）で使用する「apv」（agreement PartyVInfo）値は、base64urlエンコードされた文字列として表されます。使用される場合、PartyVInfo値には受信者に関する情報が含まれます。このヘッダーパラメーターの使用は選択できます（OPTIONAL）。これらのアルゴリズムが使用される場合、このヘッダーパラメーターは理解され処理される必要があります（MUST）。

4.6.2. Key Derivation for ECDH Key Agreement

4.6.2. ECDH 鍵共有のための鍵導出

The key derivation process derives the agreed-upon key from the shared secret Z established through the ECDH algorithm, per Section 6.2.2.2 of [NIST.800-56A].

鍵派生プロセスは、[NIST.800-56A]のセクション6.2.2.2にしたがって確立された共有シークレットZから合意された鍵を派生します。

Key derivation is performed using the Concat KDF, as defined in Section 5.8.1 of [NIST.800-56A], where the Digest Method is SHA-256. The Concat KDF parameters are set as follows:

鍵派生は、SHA-256がDigest Methodとして設定されたConcat KDFを使用して実行されます。Concat KDFパラメーターは、次のように設定されます。

Z This is set to the representation of the shared secret Z as an octet sequence.

Z これは、共有シークレットZの表現をオクテットシーケンスとして設定します。

keydatalen This is set to the number of bits in the desired output key. For "ECDH-ES", this is length of the key used by the "enc" algorithm. For "ECDH-ES+A128KW", "ECDH-ES+A192KW", and "ECDH-ES+A256KW", this is 128, 192, and 256, respectively.

keydatalen これは、出力鍵のビット数に設定されます。「ECDH-ES」の場合、これは「enc」アルゴリズムで使用される鍵の長さです。「ECDH-ES+A128KW」、「ECDH-ES+A192KW」、および「ECDH-ES+A256KW」の場合、それぞれ128、192、256です。

AlgorithmID The AlgorithmID value is of the form Datalen || Data, where Data is a variable-length string of zero or more octets, and Datalen is a fixed-length, big-endian 32-bit counter that indicates the length (in octets) of Data. In the Direct Key Agreement case, Data is set to the octets of the ASCII representation of the "enc" Header Parameter value. In the Key Agreement with Key Wrapping case, Data is set to the octets of the ASCII representation of the "alg" (algorithm) Header Parameter value.

AlgorithmID AlgorithmID値は、Datalen || Dataの形式であり、Dataは0個以上のオクテットの可変長文字列であり、DatalenはDataの長さ（オクテット単位）を示す固定長のビッグエンディアン32ビットカウンタです。直接鍵合意の場合、Dataは「enc」ヘッダーパラメーター値のASCII表現のオクテットに設定されます。鍵合意と鍵ラッピングの場合、Dataは「alg」（アルゴリズム）ヘッダーパラメーター値のASCII表現のオクテットに設定されます。

PartyUInfo The PartyUInfo value is of the form Datalen || Data, where Data is a variable-length string of zero or more octets, and Datalen is a fixed-length, big-endian 32-bit counter that indicates the length (in octets) of Data. If an "apu" (agreement PartyUInfo) Header Parameter is present, Data is set to the result of base64url decoding the "apu" value and Datalen is set to the number of octets in Data. Otherwise, Datalen is set to 0 and Data is set to the empty octet sequence.

PartyUInfo PartyUInfo値は、Datalen || Dataの形式であり、Dataは0個以上のオクテットの可変長文字列であり、DatalenはDataの長さ（オクテット単位）を示す固定長のビッグエンディアン32ビットカウンタです。ヘッダーパラメーター「apu」（agreement PartyUInfo）が存在する場合、Dataは「apu」値をbase64urlデコードした結果に設定され、DatalenはDataのオクテット数に設定されます。それ以外の場合、Datalenは0に設定され、Dataは空のオクテットシーケンスに設定されます。

PartyVInfo The PartyVInfo value is of the form Datalen || Data, where Data is a variable-length string of zero or more octets, and Datalen is a fixed-length, big-endian 32-bit counter that indicates the length (in octets) of Data. If an "apv" (agreement PartyVInfo) Header Parameter is present, Data is set to the result of base64url decoding the "apv" value and Datalen is set to the number of octets in Data. Otherwise, Datalen is set to 0 and Data is set to the empty octet sequence.

PartyVInfo PartyVInfo値は、Datalen || Dataの形式であり、Dataは0個以上のオクテットの可変長文字列であり、DatalenはDataの長さ（オクテット単位）を示す固定長のビッグエンディアン32ビットカウンタです。ヘッダーパラメーター「apv」（agreement PartyVInfo）が存在する場合、Dataは「apv」値をbase64urlデコードした結果に設定され、DatalenはDataのオクテット数に設定されます。それ以外の場合、Datalenは0に設定され、Dataは空のオクテットシーケンスに設定されます。

SuppPubInfo This is set to the keydatalen represented as a 32-bit big-endian integer.

SuppPubInfo これは、32ビットビッグエンディアン整数として表されるkeydatalenに設定されます。

SuppPrivInfo This is set to the empty octet sequence.

SuppPrivInfo これは、空のオクテットシーケンスに設定されます。

Applications need to specify how the "apu" and "apv" Header Parameters are used for that application. The "apu" and "apv" values MUST be distinct, when used. Applications wishing to conform to [NIST.800-56A] need to provide values that meet the requirements of that document, e.g., by using values that identify the producer and consumer. Alternatively, applications MAY conduct key derivation in a manner similar to "Diffie-Hellman Key Agreement Method" [RFC2631]: in that case, the "apu" parameter MAY either be omitted or represent a random 512-bit value (analogous to PartyAInfo in Ephemeral-Static mode in RFC 2631) and the "apv" parameter SHOULD NOT be present.

アプリケーションは、「apu」および「apv」ヘッダーパラメーターがそのアプリケーションでどのように使用されるかを指定する必要があります。「apu」と「apv」の値は、使用する場合には必ず異なる必要があります（MUST）。NIST.800-56Aに準拠するアプリケーションは、プロデューサーとコンシューマーを識別する値を使用することによって、そのドキュメントの要件を満たす値を提供する必要があります。また、アプリケーションは、Diffie-Hellman Key Agreement Methodに類似した方法で鍵派生を実行することもできます（RFC 2631のEphemeral-StaticモードのPartyAInfoに類似した）：その場合、「apu」パラメーターは省略されるか、ランダムな512ビット値を表すことができます。「apv」パラメーターは存在すべきではありません（SHOULD NOT）。

See Appendix C for an example key agreement computation using this method.

この方法を使用した鍵合意計算の例については、付録Cを参照してください。

4.7. Key Encryption with AES GCM

4.7. AES GCM による鍵の暗号化

This section defines the specifics of encrypting a JWE Content Encryption Key (CEK) with Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) ([AES] and [NIST.800-38D]).

このセクションでは、Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) ([AES] および [NIST.800-38D]) を使用して、JWE Content Encryption Key (CEK) を暗号化する方法について定義します。

Use of an Initialization Vector (IV) of size 96 bits is REQUIRED with this algorithm. The IV is represented in base64url-encoded form as the "iv" (initialization vector) Header Parameter value.

このアルゴリズムでは、サイズが96ビットの初期化ベクトル（IV）の使用が要求されています（REQUIRED）。IVは、base64urlエンコードされた形式で「iv」（初期化ベクトル）ヘッダーパラメーター値として表されます。

The Additional Authenticated Data value used is the empty octet string.

使用される追加認証データ値は、空のオクテット文字列です。

The requested size of the Authentication Tag output MUST be 128 bits, regardless of the key size.

要求される認証タグ出力のサイズは、鍵のサイズに関係なく、128ビットである必要があります（MUST）。

The JWE Encrypted Key value is the ciphertext output.

JWE Encrypted Key値は、暗号文の出力です。

The Authentication Tag output is represented in base64url-encoded form as the "tag" (authentication tag) Header Parameter value.

認証タグ出力は、base64urlエンコードされた形式で「tag」（認証タグ）ヘッダーパラメーター値として表されます。

The following "alg" (algorithm) Header Parameter values are used to indicate that the JWE Encrypted Key is the result of encrypting the CEK using the corresponding algorithm and key size:

次の「alg」（アルゴリズム）ヘッダーパラメーター値は、JWE Encrypted Keyが対応するアルゴリズムと鍵サイズを使用してCEKを暗号化した結果であることを示すために使用されます。

"alg" Param Value	Key Management Algorithm
A128GCMKW	Key wrapping with AES GCM using 128-bit key
A192GCMKW	Key wrapping with AES GCM using 192-bit key
A256GCMKW	Key wrapping with AES GCM using 256-bit key

"alg" パラメーターの値	鍵管理アルゴリズム
A128GCMKW	128-bit キーを使用した AES GCM による鍵ラップ
A192GCMKW	192-bit キーを使用した AES GCM による鍵ラップ
A256GCMKW	256-bit キーを使用した AES GCM による鍵ラップ

4.7.1. Header Parameters Used for AES GCM Key Encryption

4.7.1. AES GCM 鍵暗号化に使用されるヘッダーパラメーター

The following Header Parameters are used for AES GCM key encryption.

AES GCM鍵暗号化には、次のヘッダーパラメーターが使用されます。

4.7.1.1. "iv" (Initialization Vector) Header Parameter

4.7.1.1. "iv" (Initialization Vector) ヘッダーパラメーター

The "iv" (initialization vector) Header Parameter value is the base64url-encoded representation of the 96-bit IV value used for the key encryption operation. This Header Parameter MUST be present and MUST be understood and processed by implementations when these algorithms are used.

「iv」（初期化ベクトル）ヘッダーパラメーター値は、鍵暗号化操作に使用される96ビットIV値のbase64urlエンコードされた表現です。このヘッダーパラメーターは必ず存在しなければなりません（MUST）。これらのアルゴリズムが使用される場合、実装によって理解され処理される必要があります（MUST）。

4.7.1.2. "tag" (Authentication Tag) Header Parameter

4.7.1.2. "tag" (Authentication Tag) ヘッダーパラメーター

The "tag" (authentication tag) Header Parameter value is the base64url-encoded representation of the 128-bit Authentication Tag value resulting from the key encryption operation. This Header Parameter MUST be present and MUST be understood and processed by implementations when these algorithms are used.

「tag」（認証タグ）ヘッダーパラメーター値は、鍵暗号化操作から得られた128ビットの認証タグ値のbase64urlエンコードされた表現です。このヘッダーパラメーターは必ず存在しなければなりません（MUST）。これらのアルゴリズムが使用される場合、実装によって理解され、処理される必要があります（MUST）。

4.8. Key Encryption with PBES2

4.8. PBES2 による鍵の暗号化

This section defines the specifics of performing password-based encryption of a JWE CEK, by first deriving a key encryption key from a user-supplied password using PBES2 schemes as specified in Section 6.2 of [RFC2898], then by encrypting the JWE CEK using the derived key.

このセクションでは、PBES2スキームを使用して、ユーザー提供のパスワードからキー暗号化キーを導出し、そのキーを使用してJWE CEKを暗号化することによるJWE CEKのパスワードベースの暗号化の具体的な定義が行われます。PBES2スキームは、[RFC2898]のSection 6.2で指定されています。JWE CEKは、導出されたキーを使用して暗号化されます。

These algorithms use HMAC SHA-2 algorithms as the Pseudorandom Function (PRF) for the PBKDF2 key derivation and AES Key Wrap [RFC3394] for the encryption scheme. The PBES2 password input is an octet sequence; if the password to be used is represented as a text string rather than an octet sequence, the UTF-8 encoding of the text string MUST be used as the octet sequence. The salt parameter MUST be computed from the "p2s" (PBES2 salt input) Header Parameter value and the "alg" (algorithm) Header Parameter value as specified in the "p2s" definition below. The iteration count parameter MUST be provided as the "p2c" (PBES2 count) Header Parameter value. The algorithms respectively use HMAC SHA-256, HMAC SHA-384, and HMAC SHA-512 as the PRF and use 128-, 192-, and 256-bit AES Key Wrap keys. Their derived-key lengths respectively are 16, 24, and 32 octets.

これらのアルゴリズムでは、PBKDF2キー導出の疑似ランダム関数（PRF）としてHMAC SHA-2アルゴリズムを使用し、暗号化スキームとしてAES Key Wrap[RFC3394]を使用します。PBES2パスワード入力はオクテットシーケンスである必要があります。パスワードがオクテットシーケンスではなくテキスト文字列として表される場合、テキスト文字列のUTF-8エンコーディングをオクテットシーケンスとして使用しなければなりません（MUST）。saltパラメーターは、"p2s"（PBES2 salt input）ヘッダーパラメーター値と"alg"（algorithm）ヘッダーパラメーター値から計算され、以下の"p2s"定義で指定されます。反復回数パラメーターは、"p2c"（PBES2 count）ヘッダーパラメーター値として提供しなければなりません（MUST）。これらのアルゴリズムは、それぞれ、128ビット、192ビット、256ビットのAES Key Wrapキーを使用し、HMAC SHA-256、HMAC SHA-384、HMAC SHA-512をPRFとして使用します。それらの導出キーの長さは、それぞれ16、24、32オクテットです。

The following "alg" (algorithm) Header Parameter values are used to indicate that the JWE Encrypted Key is the result of encrypting the CEK using the result of the corresponding password-based encryption algorithm as the key encryption key for the corresponding key wrapping algorithm:

次の"alg"（アルゴリズム）ヘッダーパラメーター値は、対応するキー包装アルゴリズムのキー暗号化キーとして、対応するパスワードベースの暗号化アルゴリズムの結果を使用してCEKを暗号化したJWE Encrypted Keyであることを示すために使用されます。

"alg" Param Value	Key Management Algorithm
PBES2-HS256+A128KW	PBES2 with HMAC SHA-256 and "A128KW" wrapping
PBES2-HS384+A192KW	PBES2 with HMAC SHA-384 and "A192KW" wrapping
PBES2-HS512+A256KW	PBES2 with HMAC SHA-512 and "A256KW" wrapping

"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

See Appendix C of the JWK specification [JWK] for an example key encryption computation using "PBES2-HS256+A128KW".

「PBES2-HS256+A128KW」を使用した例のキー暗号化計算については、JWK仕様書の付録Cを参照してください。[JWK]

4.8.1. Header Parameters Used for PBES2 Key Encryption

4.8.1. PBES2 鍵暗号化に使用されるヘッダーパラメーター

The following Header Parameters are used for Key Encryption with PBES2.

PBES2によるキー暗号化には、以下のヘッダーパラメーターが使用されます。

4.8.1.1. "p2s" (PBES2 Salt Input) Header Parameter

4.8.1.1. "p2s" (PBES2 Salt Input) ヘッダーパラメーター

The "p2s" (PBES2 salt input) Header Parameter encodes a Salt Input value, which is used as part of the PBKDF2 salt value. The "p2s" value is BASE64URL(Salt Input). This Header Parameter MUST be present and MUST be understood and processed by implementations when these algorithms are used.

「p2s」（PBES2 salt input）ヘッダーパラメーター値は、PBKDF2 salt値の一部として使用されるSalt Input値をエンコードします。「p2s」の値はBASE64URL（Salt Input）です。このヘッダーパラメーターは必ず存在しなければなりません（MUST）。これらのアルゴリズムが使用される場合、実装によって理解され、処理される必要があります（MUST）。

The salt expands the possible keys that can be derived from a given password. A Salt Input value containing 8 or more octets MUST be used. A new Salt Input value MUST be generated randomly for every encryption operation; see RFC 4086 [RFC4086] for considerations on generating random values. The salt value used is (UTF8(Alg) || 0x00 || Salt Input), where Alg is the "alg" (algorithm) Header Parameter value.

Saltは、与えられたパスワードから導出できる可能性のあるキーを拡張します。8オクテット以上のSalt Input値を含む必要があります。必ず新しいSalt Input値を生成し、暗号化操作ごとにランダムに生成する必要があります（MUST）。ランダム値の生成に関する考慮事項については、RFC 4086を参照してください。使用されるsalt値は（UTF8（Alg）|| 0x00 || Salt Input）であり、Algは「alg」（アルゴリズム）ヘッダーパラメーター値です。

4.8.1.2. "p2c" (PBES2 Count) Header Parameter

4.8.1.2. "p2c" (PBES2 Count) ヘッダーパラメーター

The "p2c" (PBES2 count) Header Parameter contains the PBKDF2 iteration count, represented as a positive JSON integer. This Header Parameter MUST be present and MUST be understood and processed by implementations when these algorithms are used.

「p2c」（PBES2 count）ヘッダーパラメーター値には、正のJSON整数として表されるPBKDF2反復回数が含まれます。このヘッダーパラメーターは必ず存在しなければなりません（MUST）。これらのアルゴリズムが使用される場合、実装によって理解され、処理される必要があります（MUST）。

The iteration count adds computational expense, ideally compounded by the possible range of keys introduced by the salt. A minimum iteration count of 1000 is RECOMMENDED.

反復回数は、saltによって導入される可能性のあるキーの範囲によって理想的に複合化される計算負荷を追加します。反復回数の最小値は1000が推奨されます（RECOMMENDED）。

5. Cryptographic Algorithms for Content Encryption

5. コンテンツ暗号化のための暗号アルゴリズム

JWE uses cryptographic algorithms to encrypt and integrity-protect the plaintext and to integrity-protect the Additional Authenticated Data.

JWEは、暗号化アルゴリズムを使用して平文を暗号化し、整合性を保護し、追加認証データの整合性を保護します。

5.1. "enc" (Encryption Algorithm) Header Parameter Values for JWE

5.1. JWEの"enc" (Encryption Algorithm)ヘッダーパラメーター値

The table below is the set of "enc" (encryption algorithm) Header Parameter values that are defined by this specification for use with JWE.

以下の表は、JWEで使用するためにこの仕様で定義された「enc」（暗号化アルゴリズム）ヘッダーパラメーター値のセットです。

"enc" Param Value	Content Encryption Algorithm	Implementation Requirements
A128CBC-HS256	AES_128_CBC_HMAC_SHA_256 authenticated encryption algorithm, as defined in Section 5.2.3	Required
A192CBC-HS384	AES_192_CBC_HMAC_SHA_384 authenticated encryption algorithm, as defined in Section 5.2.4	Optional
A256CBC-HS512	AES_256_CBC_HMAC_SHA_512 authenticated encryption algorithm, as defined in Section 5.2.5	Required
A128GCM	AES GCM using 128-bit key	Recommended
A192GCM	AES GCM using 192-bit key	Optional
A256GCM	AES GCM using 256-bit key	Recommended

"enc" パラメーターの値	コンテンツ暗号化アルゴリズム	実装要件
A128CBC-HS256	AES_128_CBC_HMAC_SHA_256 認証付き暗号化アルゴリズム（Section 5.2.3 で定義）	必須
A192CBC-HS384	AES_192_CBC_HMAC_SHA_384 認証付き暗号化アルゴリズム（Section 5.2.4 で定義）	オプション
A256CBC-HS512	AES_256_CBC_HMAC_SHA_512 認証付き暗号化アルゴリズム（Section 5.2.5 で定義）	必須
A128GCM	128-bit キーを使用した AES GCM	推奨
A192GCM	192-bit キーを使用した AES GCM	オプション
A256GCM	256-bit キーを使用した AES GCM	推奨

All also use a JWE Initialization Vector value and produce JWE Ciphertext and JWE Authentication Tag values.

すべてのアルゴリズムは、JWE初期化ベクトル値を使用し、JWE暗号文とJWE認証タグ値を生成します。

See Appendix A.3 for 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.

この仕様で定義されたJWE「enc」（暗号化アルゴリズム）値を他の標準やソフトウェアパッケージで使用される同等の識別子と相互参照する表については、付録A.3を参照してください。

5.2. AES_CBC_HMAC_SHA2 Algorithms

5.2. AES_CBC_HMAC_SHA2 アルゴリズム

This section defines a family of authenticated encryption algorithms built using a composition of AES [AES] in Cipher Block Chaining (CBC) mode [NIST.800-38A] with PKCS #7 padding operations per Section 6.3 of [RFC5652] and HMAC ([RFC2104] and [SHS]) operations. This algorithm family is called AES_CBC_HMAC_SHA2. It also defines three instances of this family: the first using 128-bit CBC keys and HMAC SHA-256, the second using 192-bit CBC keys and HMAC SHA-384, and the third using 256-bit CBC keys and HMAC SHA-512. Test cases for these algorithms can be found in Appendix B.

このセクションでは、AES [AES]をCipher Block Chaining（CBC）モード[NIST.800-38A]とPKCS #7パディング操作を使用して構築された認証付き暗号化アルゴリズムファミリを定義します。HMAC（[RFC2104]および[SHS]）操作も使用されます。このアルゴリズムファミリはAES_CBC_HMAC_SHA2と呼ばれます。また、このファミリの3つのインスタンスを定義します。最初のインスタンスは128ビットCBCキーとHMAC SHA-256を使用し、2番目のインスタンスは192ビットCBCキーとHMAC SHA-384を使用し、3番目のインスタンスは256ビットCBCキーとHMAC SHA-512を使用します。これらのアルゴリズムのテストケースは付録Bにあります。

These algorithms are based upon "Authenticated Encryption with AES- CBC and HMAC-SHA" [AEAD-CBC-SHA], performing the same cryptographic computations, but with the Initialization Vector (IV) and Authentication Tag values remaining separate, rather than being concatenated with the ciphertext value in the output representation. This option is discussed in Appendix B of that specification. This algorithm family is a generalization of the algorithm family in [AEAD-CBC-SHA] and can be used to implement those algorithms.

これらのアルゴリズムは、「Authenticated Encryption with AES-CBC and HMAC-SHA」[AEAD-CBC-SHA]に基づいており、同じ暗号計算を実行しますが、初期化ベクトル（IV）と認証タグ値は、出力表現の暗号文値と連結されずに別々に保持されます。このオプションについては、その仕様書の付録Bで説明されています。このアルゴリズムファミリは、[AEAD-CBC-SHA]のアルゴリズムファミリの一般化であり、これらのアルゴリズムを実装するために使用できます。

5.2.1. Conventions Used in Defining AES_CBC_HMAC_SHA2

5.2.1. AES_CBC_HMAC_SHA2 の定義に使用される規約

We use the following notational conventions.

以下の表記法を使用します。

   CBC-PKCS7-ENC(X, P) denotes the AES-CBC encryption of P using PKCS
   #7 padding utilizing the cipher with the key X.
   MAC(Y, M) denotes the application of the MAC to the message M
   using the key Y.

   CBC-PKCS7-ENC(X, P) は、キーXを使用して暗号化を行うAES-CBC暗号を使用し、PKCS #7パディングを使用してPを暗号化します。
   MAC(Y, M) は、キーYを使用してメッセージMにMACを適用します。

5.2.2. Generic AES_CBC_HMAC_SHA2 Algorithm

5.2.2. 一般的な AES_CBC_HMAC_SHA2 アルゴリズム

This section defines AES_CBC_HMAC_SHA2 in a manner that is independent of the AES-CBC key size or hash function to be used. Sections 5.2.2.1 and 5.2.2.2 define the generic encryption and decryption algorithms. Sections 5.2.3 through 5.2.5 define instances of AES_CBC_HMAC_SHA2 that specify those details.

このセクションでは、使用する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 Encryption

5.2.2.1. AES_CBC_HMAC_SHA2 暗号化

The authenticated encryption algorithm takes as input four octet strings: a secret key K, a plaintext P, Additional Authenticated Data A, and an Initialization Vector IV. The authenticated ciphertext value E and the Authentication Tag value T are provided as outputs. The data in the plaintext are encrypted and authenticated, and the Additional Authenticated Data are authenticated, but not encrypted.

認証付き暗号化アルゴリズムは、秘密鍵K、平文P、追加認証データA、および初期化ベクトルIVの4つのオクテット文字列を入力として受け取ります。認証付き暗号文値Eと認証タグ値Tが出力されます。平文のデータは暗号化および認証され、追加認証データは認証されますが、暗号化されません。

The encryption process is as follows, or uses an equivalent set of steps:

暗号化プロセスは、以下の手順にしたがいます。

1. The secondary keys MAC_KEY and ENC_KEY are generated from the input key K as follows. Each of these two keys is an octet string.

1. 2つのセカンダリキーMAC_KEYおよびENC_KEYは、入力キーKから以下のように生成されます。これらの2つのキーのそれぞれはオクテット文字列です。

       MAC_KEY consists of the initial MAC_KEY_LEN octets of K, in
       order.
       ENC_KEY consists of the final ENC_KEY_LEN octets of K, in
       order.

       MAC_KEY consists of the initial MAC_KEY_LEN octets of K, in
       order.
       ENC_KEY consists of the final ENC_KEY_LEN octets of K, in
       order.

    The number of octets in the input key K MUST be the sum of
    MAC_KEY_LEN and ENC_KEY_LEN.  The values of these parameters are
    specified by the Authenticated Encryption algorithms in Sections
    5.2.3 through 5.2.5.  Note that the MAC key comes before the
    encryption key in the input key K; this is in the opposite order
    of the algorithm names in the identifier "AES_CBC_HMAC_SHA2".

    The number of octets in the input key K MUST be the sum of
    MAC_KEY_LEN and ENC_KEY_LEN.  The values of these parameters are
    specified by the Authenticated Encryption algorithms in Sections
    5.2.3 through 5.2.5.  Note that the MAC key comes before the
    encryption key in the input key K; this is in the opposite order
    of the algorithm names in the identifier "AES_CBC_HMAC_SHA2".

2. The IV used is a 128-bit value generated randomly or pseudorandomly for use in the cipher.

2. 使用されるIVは、暗号に使用するためにランダムまたは疑似ランダムに生成された128ビットの値です。

3. The plaintext is CBC encrypted using PKCS #7 padding using ENC_KEY as the key and the IV. We denote the ciphertext output from this step as E.

3. 平文は、ENC_KEYをキーとして、IVを使用してPKCS #7パディングを使用してCBCで暗号化されます。このステップからの暗号文出力をEと表記します。

4. The octet string AL is equal to the number of bits in the Additional Authenticated Data A expressed as a 64-bit unsigned big-endian integer.

4. オクテット文字列ALは、追加認証データAのビット数を64ビットの符号なしビッグエンディアン整数として表したものです。

5. A message Authentication Tag T is computed by applying HMAC [RFC2104] to the following data, in order:

5. HMAC [RFC2104]を以下のデータに順番に適用して、メッセージ認証タグTを計算します。

       the Additional Authenticated Data A,
       the Initialization Vector IV,
       the ciphertext E computed in the previous step, and
       the octet string AL defined above.

       the Additional Authenticated Data A,
       the Initialization Vector IV,
       the ciphertext E computed in the previous step, and
       the octet string AL defined above.

    The string MAC_KEY is used as the MAC key.  We denote the output
    of the MAC computed in this step as M.  The first T_LEN octets of
    M are used as T.

    The string MAC_KEY is used as the MAC key.  We denote the output
    of the MAC computed in this step as M.  The first T_LEN octets of
    M are used as T.

6. The ciphertext E and the Authentication Tag T are returned as the outputs of the authenticated encryption.

6. 暗号文Eと認証タグTは、認証付き暗号化の出力として返されます。

The encryption process can be illustrated as follows. Here K, P, A, IV, and E denote the key, plaintext, Additional Authenticated Data, Initialization Vector, and ciphertext, respectively.

暗号化プロセスは、以下のように表すことができます。ここで、K、P、A、IV、およびEは、それぞれキー、平文、追加認証データ、初期化ベクトル、および暗号文を表します。

   MAC_KEY = initial MAC_KEY_LEN octets of K,
   ENC_KEY = final ENC_KEY_LEN octets of K,
   E = CBC-PKCS7-ENC(ENC_KEY, P),
   M = MAC(MAC_KEY, A || IV || E || AL),
   T = initial T_LEN octets of M.

   MAC_KEY = initial MAC_KEY_LEN octets of K,
   ENC_KEY = final ENC_KEY_LEN octets of K,
   E = CBC-PKCS7-ENC(ENC_KEY, P),
   M = MAC(MAC_KEY, A || IV || E || AL),
   T = initial T_LEN octets of M.

5.2.2.2. AES_CBC_HMAC_SHA2 Decryption

5.2.2.2. AES_CBC_HMAC_SHA2 復号化

The authenticated decryption operation has five inputs: K, A, IV, E, and T as defined above. It has only a single output: either a plaintext value P or a special symbol FAIL that indicates that the inputs are not authentic. The authenticated decryption algorithm is as follows, or uses an equivalent set of steps:

認証付き復号化操作には、K、A、IV、E、および上記で定義されたTの5つの入力があります。出力は単一であり、平文値Pまたは入力が正当でないことを示す特別な記号FAILのいずれかです。認証付き復号化アルゴリズムは、以下のようになります。

1. The secondary keys MAC_KEY and ENC_KEY are generated from the input key K as in Step 1 of Section 5.2.2.1.

1. セカンダリキーMAC_KEYおよびENC_KEYは、セクション5.2.2.1のステップ1と同様に、入力キーKから生成されます。

2. The integrity and authenticity of A and E are checked by computing an HMAC with the inputs as in Step 5 of Section 5.2.2.1. The value T, from the previous step, is compared to the first MAC_KEY length bits of the HMAC output. If those values are identical, then A and E are considered valid, and processing is continued. Otherwise, all of the data used in the MAC validation are discarded, and the authenticated decryption operation returns an indication that it failed, and the operation halts. (But see Section 11.5 of [JWE] for security considerations on thwarting timing attacks.)

2. AおよびEの整合性と認証は、セクション5.2.2.1のステップ5と同様に、入力を使用してHMACを計算することによってチェックされます。前のステップからの値Tは、HMAC出力の最初のMAC_KEY長ビットと比較されます。これらの値が同一である場合、AおよびEは有効と見なされ、処理が続行されます。それ以外の場合、MAC検証で使用されたすべてのデータが破棄され、認証付き復号化操作は失敗したことを示す指示を返し、操作が停止します。（ただし、タイミング攻撃を防止するためのセキュリティーに関する考慮事項については、[JWE]のセクション11.5を参照してください。）

3. The value E is decrypted and the PKCS #7 padding is checked and removed. The value IV is used as the Initialization Vector. The value ENC_KEY is used as the decryption key.

3. 値Eは復号化され、PKCS #7パディングがチェックされ、削除されます。値IVは初期化ベクトルとして使用されます。値ENC_KEYは復号化キーとして使用されます。

4. The plaintext value is returned.

4. 平文値が返されます。

5.2.3. AES_128_CBC_HMAC_SHA_256

This algorithm is a concrete instantiation of the generic AES_CBC_HMAC_SHA2 algorithm above. It uses the HMAC message authentication code [RFC2104] with the SHA-256 hash function [SHS] to provide message authentication, with the HMAC output truncated to 128 bits, corresponding to the HMAC-SHA-256-128 algorithm defined in [RFC4868]. For encryption, it uses AES in the CBC mode of operation as defined in Section 6.2 of [NIST.800-38A], with PKCS #7 padding and a 128-bit IV value.

このアルゴリズムは、上記の一般的なAES_CBC_HMAC_SHA2アルゴリズムの具体的な実装です。SHA-256ハッシュ関数[SHS]を使用したHMACメッセージ認証コード[RFC2104]を使用してメッセージ認証を提供し、HMAC出力は128ビットに切り捨てられます。これは、[RFC4868]で定義されているHMAC-SHA-256-128アルゴリズムに対応します。暗号化には、PKCS #7パディングと128ビットのIV値を使用して、[NIST.800-38A]のセクション6.2で定義されているCBCモードでAESが使用されます。

The AES_CBC_HMAC_SHA2 parameters specific to AES_128_CBC_HMAC_SHA_256 are:

AES_128_CBC_HMAC_SHA_256に固有のAES_CBC_HMAC_SHA2パラメーターは以下のとおりです。

   The input key K is 32 octets long.
   ENC_KEY_LEN is 16 octets.
   MAC_KEY_LEN is 16 octets.
   The SHA-256 hash algorithm is used for the HMAC.
   The HMAC-SHA-256 output is truncated to T_LEN=16 octets, by
   stripping off the final 16 octets.

   The input key K is 32 octets long.
   ENC_KEY_LEN is 16 octets.
   MAC_KEY_LEN is 16 octets.
   The SHA-256 hash algorithm is used for the HMAC.
   The HMAC-SHA-256 output is truncated to T_LEN=16 octets, by
   stripping off the final 16 octets.

5.2.4. AES_192_CBC_HMAC_SHA_384

AES_192_CBC_HMAC_SHA_384 is based on AES_128_CBC_HMAC_SHA_256, but with the following differences:

AES_192_CBC_HMAC_SHA_384は、AES_128_CBC_HMAC_SHA_256に基づいていますが、以下の点が異なります。

   The input key K is 48 octets long instead of 32.
   ENC_KEY_LEN is 24 octets instead of 16.
   MAC_KEY_LEN is 24 octets instead of 16.
   SHA-384 is used for the HMAC instead of SHA-256.
   The HMAC SHA-384 value is truncated to T_LEN=24 octets instead of
   16.

   The input key K is 48 octets long instead of 32.
   ENC_KEY_LEN is 24 octets instead of 16.
   MAC_KEY_LEN is 24 octets instead of 16.
   SHA-384 is used for the HMAC instead of SHA-256.
   The HMAC SHA-384 value is truncated to T_LEN=24 octets instead of
   16.

5.2.5. AES_256_CBC_HMAC_SHA_512

AES_256_CBC_HMAC_SHA_512 is based on AES_128_CBC_HMAC_SHA_256, but with the following differences:

AES_256_CBC_HMAC_SHA_512は、AES_128_CBC_HMAC_SHA_256に基づいていますが、以下の点が異なります。

   The input key K is 64 octets long instead of 32.
   ENC_KEY_LEN is 32 octets instead of 16.
   MAC_KEY_LEN is 32 octets instead of 16.
   SHA-512 is used for the HMAC instead of SHA-256.
   The HMAC SHA-512 value is truncated to T_LEN=32 octets instead of
   16.

   The input key K is 64 octets long instead of 32.
   ENC_KEY_LEN is 32 octets instead of 16.
   MAC_KEY_LEN is 32 octets instead of 16.
   SHA-512 is used for the HMAC instead of SHA-256.
   The HMAC SHA-512 value is truncated to T_LEN=32 octets instead of
   16.

5.2.6. Content Encryption with AES_CBC_HMAC_SHA2

5.2.6. AES_CBC_HMAC_SHA2 によるコンテンツ暗号化

This section defines the specifics of performing authenticated encryption with the AES_CBC_HMAC_SHA2 algorithms.

このセクションでは、AES_CBC_HMAC_SHA2アルゴリズムを使用した認証付き暗号化の具体的な実行方法が定義されています。

The CEK is used as the secret key K.

CEKは秘密鍵Kとして使用されます。

The following "enc" (encryption algorithm) Header Parameter values are used to indicate that the JWE Ciphertext and JWE Authentication Tag values have been computed using the corresponding algorithm:

以下の「enc」（暗号化アルゴリズム）ヘッダーパラメーター値は、対応するアルゴリズムを使用してJWE暗号文およびJWE認証タグ値が計算されたことを示すために使用されます。

"enc" Param Value	Content Encryption Algorithm
A128CBC-HS256	AES_128_CBC_HMAC_SHA_256 authenticated encryption algorithm, as defined in Section 5.2.3
A192CBC-HS384	AES_192_CBC_HMAC_SHA_384 authenticated encryption algorithm, as defined in Section 5.2.4
A256CBC-HS512	AES_256_CBC_HMAC_SHA_512 authenticated encryption algorithm, as defined in Section 5.2.5

"enc" パラメーターの値	コンテンツ暗号化アルゴリズム
A128CBC-HS256	Section 5.2.3 で定義された認証付き暗号化アルゴリズム AES_128_CBC_HMAC_SHA_256
A192CBC-HS384	Section 5.2.4 で定義された認証付き暗号化アルゴリズム AES_192_CBC_HMAC_SHA_384
A256CBC-HS512	Section 5.2.5 で定義された認証付き暗号化アルゴリズム AES_256_CBC_HMAC_SHA_512

5.3. Content Encryption with AES GCM

5.3. AES GCM によるコンテンツ暗号化

This section defines the specifics of performing authenticated encryption with AES in Galois/Counter Mode (GCM) ([AES] and [NIST.800-38D]).

このセクションでは、AES in Galois/Counter Mode (GCM) ([AES]および[NIST.800-38D])を使用した認証付き暗号化の具体的な実行方法が定義されています。

The CEK is used as the encryption key.

CEKは暗号化キーとして使用されます。

Use of an IV of size 96 bits is REQUIRED with this algorithm.

このアルゴリズムでは、IVのサイズは96ビットであることが要求されています（REQUIRED）。

The requested size of the Authentication Tag output MUST be 128 bits, regardless of the key size.

認証タグ出力の要求されたサイズは、キーのサイズに関係なく、128ビットである必要があります（MUST）。

The following "enc" (encryption algorithm) Header Parameter values are used to indicate that the JWE Ciphertext and JWE Authentication Tag values have been computed using the corresponding algorithm and key size:

以下の「enc」（暗号化アルゴリズム）ヘッダーパラメーター値は、対応するアルゴリズムとキーサイズを使用してJWE暗号文およびJWE認証タグ値が計算されたことを示すために使用されます。

"enc" Param Value	Content Encryption Algorithm
A128GCM	AES GCM using 128-bit key
A192GCM	AES GCM using 192-bit key
A256GCM	AES GCM using 256-bit key

"enc" パラメーターの値	コンテンツ暗号化アルゴリズム
A128GCM	128-bit キーを使用した AES GCM
A192GCM	192-bit キーを使用した AES GCM
A256GCM	256-bit キーを使用した AES GCM

An example using this algorithm is shown in Appendix A.1 of [JWE].

このアルゴリズムを使用した例は、[JWE]の付録A.1に示されています。

6. Cryptographic Algorithms for Keys

6. 鍵のための暗号アルゴリズム

A JSON Web Key (JWK) [JWK] is a JSON data structure that represents a cryptographic key. These keys can be either asymmetric or symmetric. They can hold both public and private information about the key. This section defines the parameters for keys using the algorithms specified by this document.

JSON Web Key (JWK) [JWK]は、暗号鍵を表すJSONデータ構造です。これらの鍵は非対称鍵または対称鍵のいずれかであることができます。鍵に関する公開情報と秘密情報の両方を保持することができます。このセクションでは、このドキュメントで指定されたアルゴリズムを使用する鍵のパラメーターが定義されています。

6.1. "kty" (Key Type) Parameter Values

6.1. "kty" (Key Type) パラメーター値

The table below is the set of "kty" (key type) parameter values that are defined by this specification for use in JWKs.

以下の表は、JWKで使用するためにこの仕様で定義されている「kty」（キーの種類）パラメーター値のセットです。

"kty" Param Value	Key Type	Implementation Requirements
EC	Elliptic Curve [DSS]	Recommended+
RSA	RSA [RFC3447]	Required
oct	Octet sequence (used to represent symmetric keys)	Required

"kty" パラメーターの値	キーの種類	実装要件
EC	楕円曲線[DSS]	推奨+
RSA	RSA [RFC3447]	必須
oct	オクテットシーケンス（対称キーを表すために使用）	必須

The use of "+" in the Implementation Requirements column indicates that the requirement strength is likely to be increased in a future version of the specification.

実装要件列での「+」の使用は、要件の強度が将来の仕様のバージョンで高められる可能性があることを示しています。

6.2. Parameters for Elliptic Curve Keys

6.2. 楕円曲線鍵のパラメーター

JWKs can represent Elliptic Curve [DSS] keys. In this case, the "kty" member value is "EC".

JWKは楕円曲線[DSS]鍵を表すことができます。この場合、「kty」メンバーの値は「EC」です。

6.2.1. Parameters for Elliptic Curve Public Keys

An Elliptic Curve public key is represented by a pair of coordinates drawn from a finite field, which together define a point on an Elliptic Curve. The following members MUST be present for all Elliptic Curve public keys:

楕円曲線公開鍵は、有限体から引かれた座標のペアで表され、一緒に楕円曲線上の点を定義します。すべての楕円曲線公開鍵には、以下のメンバーがMUST存在する必要があります。

"crv"
"x"

"crv"
"x"

The following member MUST also be present for Elliptic Curve public keys for the three curves defined in the following section:

以下のメンバーは、以下のセクションで定義された3つの曲線の楕円曲線公開鍵にもMUST存在する必要があります。

6.2.1.1. "crv" (Curve) Parameter

The "crv" (curve) parameter identifies the cryptographic curve used with the key. Curve values from [DSS] used by this specification are:

"crv"（曲線）パラメーターは、鍵で使用される暗号曲線を識別します。この仕様で使用される[DSS]の曲線値は次のとおりです。

"P-256"
"P-384"
"P-521" These values are registered in the IANA "JSON Web Key Elliptic Curve" registry defined in Section 7.6. Additional "crv" values can be registered by other specifications. Specifications registering additional curves must define what parameters are used to represent keys for the curves registered. The "crv" value is a case-sensitive string.

"P-256"
"P-384"
"P-521" これらの値は、セクション7.6で定義されたIANA「JSON Web Key Elliptic Curve」レジストリに登録されています。他の仕様によって追加の「crv」値が登録されることがあります。追加の曲線を登録する仕様は、登録された曲線のキーを表すためにどのパラメーターが使用されるかを定義する必要があります。「crv」値は大文字と小文字を区別する文字列です。

SEC1 [SEC1] point compression is not supported for any of these three curves.

これらの3つの曲線のいずれについても、SEC1 [SEC1]ポイント圧縮はサポートされていません。

6.2.1.2. "x" (X Coordinate) Parameter

6.2.1.2. "x" (X Coordinate) パラメーター

The "x" (x coordinate) parameter contains the x coordinate for the Elliptic Curve point. It is represented as the base64url encoding of the octet string representation of the coordinate, as defined in Section 2.3.5 of SEC1 [SEC1]. The length of this octet string MUST be the full size of a coordinate for the curve specified in the "crv" parameter. For example, if the value of "crv" is "P-521", the octet string must be 66 octets long.

"x"（X Coordinate）パラメーターには、楕円曲線の点のx座標が含まれます。これは、SEC1 [SEC1]のセクション2.3.5で定義されているように、座標のオクテット文字列表現のbase64urlエンコーディングとして表されます。「crv」パラメーターで指定された曲線の座標の完全なサイズである必要があります（MUST）。たとえば、「crv」の値が「P-521」の場合、オクテット文字列の長さは66オクテットでなければなりません。

6.2.1.3. "y" (Y Coordinate) Parameter

6.2.1.3. "y" (Y Coordinate) パラメーター

The "y" (y coordinate) parameter contains the y coordinate for the Elliptic Curve point. It is represented as the base64url encoding of the octet string representation of the coordinate, as defined in Section 2.3.5 of SEC1 [SEC1]. The length of this octet string MUST be the full size of a coordinate for the curve specified in the "crv" parameter. For example, if the value of "crv" is "P-521", the octet string must be 66 octets long.

"y"（Y Coordinate）パラメーターには、楕円曲線の点のy座標が含まれます。これは、SEC1 [SEC1]のセクション2.3.5で定義されているように、座標のオクテット文字列表現のbase64urlエンコーディングとして表されます。「crv」パラメーターで指定された曲線の座標の完全なサイズである必要があります（MUST）。たとえば、「crv」の値が「P-521」の場合、オクテット文字列の長さは66オクテットでなければなりません。

6.2.2. Parameters for Elliptic Curve Private Keys

6.2.2. 楕円曲線秘密鍵のパラメーター

In addition to the members used to represent Elliptic Curve public keys, the following member MUST be present to represent Elliptic Curve private keys.

楕円曲線公開鍵を表すために使用されるメンバーに加えて、楕円曲線秘密鍵を表すために必須の以下のメンバーが存在しなければなりません（MUST）。

6.2.2.1. "d" (ECC Private Key) Parameter

6.2.2.1. "d"（ECC private key）パラメーター

The "d" (ECC private key) parameter contains the Elliptic Curve private key value. It is represented as the base64url encoding of the octet string representation of the private key value, as defined in Section 2.3.7 of SEC1 [SEC1]. The length of this octet string MUST be ceiling(log-base-2(n)/8) octets (where n is the order of the curve).

"d"（ECC private key）パラメーターには、楕円曲線の秘密鍵値が含まれます。これは、SEC1 [SEC1]のセクション2.3.7で定義されているように、秘密鍵値のオクテット文字列表現のbase64urlエンコーディングとして表されます。このオクテット文字列の長さは、ceiling(log-base-2(n)/8)オクテットである必要があります（MUST）（nは曲線の次数）。

6.3. Parameters for RSA Keys

6.3. RSA鍵のパラメーター

JWKs can represent RSA [RFC3447] keys. In this case, the "kty" member value is "RSA". The semantics of the parameters defined below are the same as those defined in Sections 3.1 and 3.2 of RFC 3447.

JWKはRSA [RFC3447]鍵を表すことができます。この場合、「kty」メンバーの値は「RSA」です。以下で定義されたパラメーターの意味は、RFC 3447のセクション3.1および3.2で定義されているものと同じです。

6.3.1. Parameters for RSA Public Keys

6.3.1. RSA公開鍵のパラメーター

The following members MUST be present for RSA public keys.

RSA公開鍵には、以下のメンバーが存在しなければなりません（MUST）。

6.3.1.1. "n" (Modulus) Parameter

6.3.1.1. "n" (Modulus) パラメーター

The "n" (modulus) parameter contains the modulus value for the RSA public key. It is represented as a Base64urlUInt-encoded value.

「n」（Modulus）パラメーターには、RSA公開鍵のモジュラス値が含まれます。これは、Base64urlUIntでエンコードされた値として表されます。

Note that implementers have found that some cryptographic libraries prefix an extra zero-valued octet to the modulus representations they return, for instance, returning 257 octets for a 2048-bit key, rather than 256. Implementations using such libraries will need to take care to omit the extra octet from the base64url-encoded representation.

実装者は、一部の暗号ライブラリが、たとえば2048ビットのキーに対して256ではなく257オクテットを返すように、モジュラス表現に余分なゼロ値のオクテットを前置することがあることを発見しています。そのようなライブラリを使用する実装では、base64urlエンコードされた表現から余分なオクテットを省略する必要があります。

6.3.1.2. "e" (Exponent) Parameter

6.3.1.2. "e" (Exponent) パラメーター

The "e" (exponent) parameter contains the exponent value for the RSA public key. It is represented as a Base64urlUInt-encoded value.

「e」（指数）パラメーターには、RSA公開鍵の指数値が含まれます。これは、Base64urlUIntでエンコードされた値として表されます。

For instance, when representing the value 65537, the octet sequence to be base64url-encoded MUST consist of the three octets [1, 0, 1]; the resulting representation for this value is "AQAB".

たとえば、値65537を表す場合、base64urlエンコードするためのオクテットシーケンスは[1、0、1]である必要があります。この値の結果として得られる表現は「AQAB」です。

6.3.2. Parameters for RSA Private Keys

6.3.2. RSA秘密鍵のパラメーター

In addition to the members used to represent RSA public keys, the following members are used to represent RSA private keys. The parameter "d" is REQUIRED for RSA private keys. The others enable optimizations and SHOULD be included by producers of JWKs representing RSA private keys. If the producer includes any of the other private key parameters, then all of the others MUST be present, with the exception of "oth", which MUST only be present when more than two prime factors were used.

RSAプライベートキーを表すために使用されるメンバーに加えて、以下のメンバーがRSAプライベートキーを表すJWKを生成するプロデューサによって含まれることがあります。パラメーター「d」はRSAプライベートキーに必須です。他のパラメーターは最適化を可能にし、RSAプライベートキーを表すJWKを生成するプロデューサによって含まれることが推奨されます。プロデューサが他のプライベートキーのパラメーターのいずれかを含める場合、他のすべてのパラメーターが存在する必要があります。ただし、「oth」は、2つ以上の素因数が使用された場合にのみ存在する必要があります。

6.3.2.1. "d" (Private Exponent) Parameter

6.3.2.1. "d" (Private Exponent) パラメーター

The "d" (private exponent) parameter contains the private exponent value for the RSA private key. It is represented as a Base64urlUInt- encoded value.

「d」（秘密指数）パラメーターには、RSAプライベートキーの秘密指数値が含まれます。これは、Base64urlUIntでエンコードされた値として表されます。

6.3.2.2. "p" (First Prime Factor) Parameter

6.3.2.2. "p" (First Prime Factor) パラメーター

The "p" (first prime factor) parameter contains the first prime factor. It is represented as a Base64urlUInt-encoded value.

「p」（最初の素因数）パラメーターには、RSAプライベートキーの最初の素因数が含まれます。これは、Base64urlUIntでエンコードされた値として表されます。

6.3.2.3. "q" (Second Prime Factor) Parameter

6.3.2.3. "q" (Second Prime Factor) パラメーター

The "q" (second prime factor) parameter contains the second prime factor. It is represented as a Base64urlUInt-encoded value.

「q」（2番目の素因数）パラメーターには、RSAプライベートキーの2番目の素因数が含まれます。これは、Base64urlUIntでエンコードされた値として表されます。

6.3.2.4. "dp" (First Factor CRT Exponent) Parameter

6.3.2.4. "dp" (First Factor CRT Exponent) パラメーター

The "dp" (first factor CRT exponent) parameter contains the Chinese Remainder Theorem (CRT) exponent of the first factor. It is represented as a Base64urlUInt-encoded value.

「dp」（最初の素因数CRT指数）パラメーターには、最初の素因数の中国剰余定理（CRT）指数が含まれます。これは、Base64urlUIntでエンコードされた値として表されます。

6.3.2.5. "dq" (Second Factor CRT Exponent) Parameter

6.3.2.5. "dq" (Second Factor CRT Exponent) パラメーター

The "dq" (second factor CRT exponent) parameter contains the CRT exponent of the second factor. It is represented as a Base64urlUInt- encoded value.

「dq」（2番目の素因数CRT指数）パラメーターには、2番目の素因数の中国剰余定理（CRT）指数が含まれます。これは、Base64urlUIntでエンコードされた値として表されます。

6.3.2.6. "qi" (First CRT Coefficient) Parameter

6.3.2.6. "qi" (First CRT Coefficient) パラメーター

The "qi" (first CRT coefficient) parameter contains the CRT coefficient of the second factor. It is represented as a Base64urlUInt-encoded value.

「qi」（最初のCRT係数）パラメーターには、2番目の素因数のCRT係数が含まれます。これは、Base64urlUIntでエンコードされた値として表されます。

6.3.2.7. "oth" (Other Primes Info) Parameter

6.3.2.7. "oth" (Other Primes Info) パラメーター

The "oth" (other primes info) parameter contains an array of information about any third and subsequent primes, should they exist. When only two primes have been used (the normal case), this parameter MUST be omitted. When three or more primes have been used, the number of array elements MUST be the number of primes used minus two. For more information on this case, see the description of the OtherPrimeInfo parameters in Appendix A.1.2 of RFC 3447 [RFC3447], upon which the following parameters are modeled. If the consumer of a JWK does not support private keys with more than two primes and it encounters a private key that includes the "oth" parameter, then it MUST NOT use the key. Each array element MUST be an object with the following members.

「oth」（Other Primes Info）パラメーターには、第3およびそれ以降の素数に関する情報の配列が含まれます。2つの素数だけ使用する場合（通常は2つだけです）、このパラメーターは省略しなければなりません（MUST）。3つ以上の素数が使用される場合、配列要素の数は使用される素数の数から2を引いた数である必要があります（MUST）。この場合の詳細については、RFC 3447の付録A.1.2のOtherPrimeInfoパラメーターの説明を参照してください。以下のパラメーターは、RFC 3447のモデルとなっています。JWKのコンシューマが3つ以上の素数を持つプライベートキーをサポートしていない場合、および「oth」パラメーターを含むプライベートキーに遭遇したとき、そのキーを使用してはなりません（MUST NOT）。各配列要素は、次のメンバーを持つオブジェクトである必要があります（MUST）。

6.3.2.7.1. "r" (Prime Factor)

The "r" (prime factor) parameter within an "oth" array member represents the value of a subsequent prime factor. It is represented as a Base64urlUInt-encoded value.

"oth"配列メンバー内の「r」（Prime Factor）パラメーターは、その後の素因数の値を表します。これは、Base64urlUIntでエンコードされた値として表されます。

6.3.2.7.2. "d" (Factor CRT Exponent)

The "d" (factor CRT exponent) parameter within an "oth" array member represents the CRT exponent of the corresponding prime factor. It is represented as a Base64urlUInt-encoded value.

"oth"配列メンバー内の「d」（Factor CRT Exponent）パラメーターは、対応する素因数のCRT指数を表します。これは、Base64urlUIntでエンコードされた値として表されます。

6.3.2.7.3. "t" (Factor CRT Coefficient)

The "t" (factor CRT coefficient) parameter within an "oth" array member represents the CRT coefficient of the corresponding prime factor. It is represented as a Base64urlUInt-encoded value.

"oth"配列メンバー内の「t」（Factor CRT Coefficient）パラメーターは、対応する素因数のCRT係数を表します。これは、Base64urlUIntでエンコードされた値として表されます。

6.4. Parameters for Symmetric Keys

6.4. 対称鍵のパラメーター

When the JWK "kty" member value is "oct" (octet sequence), the member "k" (see Section 6.4.1) is used to represent a symmetric key (or another key whose value is a single octet sequence). An "alg" member SHOULD also be present to identify the algorithm intended to be used with the key, unless the application uses another means or convention to determine the algorithm used.

JWKの「kty」メンバー値が「oct」（octet sequence）の場合、「k」メンバー（セクション6.4.1を参照）は、対称鍵（または値が単一のオクテットシーケンスである他の鍵）を表すために使用されます。「alg」メンバーも存在すべきです（SHOULD）。これは、アプリケーションが他の手段または規約を使用してアルゴリズムを決定しない限り、キーで使用するアルゴリズムを識別するために使用されます。

6.4.1. "k" (Key Value) Parameter

6.4.1. "k" (Key Value) パラメーター

The "k" (key value) parameter contains the value of the symmetric (or other single-valued) key. It is represented as the base64url encoding of the octet sequence containing the key value.

"k"（Key Value）パラメーターには、対称鍵（または値が単一のオクテットシーケンスである他の鍵）の値が含まれます。これは、鍵値を含むオクテットシーケンスのbase64urlエンコーディングとして表されます。

7. IANA Considerations

7. IANA の考慮事項

The following registration procedure is used for all the registries established by this specification.

この仕様で設立されたすべてのレジストリに対して、次の登録手順が使用されます。

The registration procedure for values is Specification Required [RFC5226] after a three-week review period on the jose-reg-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published.

値の登録手順は、RFC 5226にしたがって、jose-reg-review@ietf.orgメーリングリストでの3週間のレビュー期間後、1人以上の指定専門家の助言に基づいて、仕様が必要です。ただし、公開前に値を割り当てるために、指定専門家は、そのような仕様が公開されることを確信した場合に、登録を承認することができます。

Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register algorithm: example").

レビュー用に送信された登録リクエストは、適切な件名（例：「アルゴリズムの登録リクエスト：example」）を使用する必要があります。

Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.

レビュー期間中、指定専門家は、登録リクエストを承認または拒否し、この決定をレビューリストとIANAに通知します。拒否は説明と、必要に応じて、リクエストを成功させるための提案を含める必要があります。

Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution.

21日間以上未決定の登録リクエストは、解決のためにIESG（iesg@ietf.orgメーリングリストを使用）の注意を引くことができます。

Criteria that should be applied by the Designated Experts include determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or useful only for a single application, and whether the registration description is clear.

指定専門家が適用すべき基準には、提案された登録が既存の機能と重複しているかどうか、一般的に適用可能か、または単一のアプリケーションにのみ有用か、登録の説明が明確かどうかが含まれます。

IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list.

IANAは、指定専門家からのレジストリの更新のみを受け入れ、すべての登録リクエストをレビューメーリングリストに送信する必要があります。

It is suggested that multiple Designated Experts be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly informed review of registration decisions. In cases where a registration decision could be perceived as creating a conflict of interest for a particular Expert, that Expert should defer to the judgment of the other Experts.

この仕様を使用するさまざまなアプリケーションの視点を代表できる複数の指定専門家が任命されることが提案されており、登録の決定を広く情報化されたレビューを可能にするためです。登録の決定が特定の専門家にとって利益相反を引き起こす可能性がある場合、その専門家は他の専門家の判断にしたがう必要があります。

7.1. JSON Web Signature and Encryption Algorithms Registry

This specification establishes the IANA "JSON Web Signature and Encryption Algorithms" registry for values of the JWS and JWE "alg" (algorithm) and "enc" (encryption algorithm) Header Parameters. The registry records the algorithm name, the algorithm description, the algorithm usage locations, the implementation requirements, the change controller, and a reference to the specification that defines it. The same algorithm name can be registered multiple times, provided that the sets of usage locations are disjoint.

この仕様では、JWSおよびJWEの「alg」（アルゴリズム）および「enc」（暗号化アルゴリズム）ヘッダーパラメーターの値のためのIANA「JSON Web Signature and Encryption Algorithms」レジストリが設立されます。レジストリには、アルゴリズム名、アルゴリズムの説明、アルゴリズムの使用場所、実装要件、変更管理者、およびそれを定義する仕様への参照が記録されます。同じアルゴリズム名は、使用場所の集合が交差しない場合に複数回登録できます。

It is suggested that the length of the key be included in the algorithm name when multiple variations of algorithms are being registered that use keys of different lengths and the key lengths for each need to be fixed (for instance, because they will be created by key derivation functions). This allows readers of the JSON text to more easily make security decisions.

異なる長さのキーを使用する複数のアルゴリズムのバリエーションが登録され、各キーの長さが固定される必要がある場合（たとえば、キー派生関数によって作成される場合）、アルゴリズム名にキーの長さを含めることが提案されています。これにより、JSONテキストの読者がより簡単にセキュリティー上の決定を行うことができます。

The Designated Experts should perform reasonable due diligence that algorithms being registered either are currently considered cryptographically credible or are being registered as Deprecated or Prohibited.

指定専門家は、登録されるアルゴリズムが現在暗号的に信頼できると考えられているか、またはDeprecatedまたはProhibitedとして登録されていることを合理的な注意を払って確認する必要があります。

The implementation requirements of an algorithm may be changed over time as the cryptographic landscape evolves, for instance, to change the status of an algorithm to Deprecated or to change the status of an algorithm from Optional to Recommended+ or Required. Changes of implementation requirements are only permitted on a Specification Required basis after review by the Designated Experts, with the new specification defining the revised implementation requirements level.

アルゴリズムの実装要件は、暗号技術の状況が変化するにつれて変更される場合があります。たとえば、アルゴリズムの状態をDeprecatedに変更するために、またはアルゴリズムの状態をOptionalからRecommended+またはRequiredに変更するために、実装要件を変更することができます。実装要件の変更は、指定専門家によるレビュー後、Specification Requiredの基準に基づいてのみ許可され、新しい仕様によって改訂された実装要件レベルが定義されます。

7.1.1. Registration Template

7.1.1. 登録テンプレート

Algorithm Name: The name requested (e.g., "HS256"). This name is a case-sensitive ASCII string. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception.

アルゴリズム名：要求された名前（例：「HS256」）。この名前は大文字小文字を区別するASCII文字列です。指定専門家が例外を許可する理由がある場合を除き、他の登録済みの名前と大文字小文字を区別しない場合があります。

Algorithm Description: Brief description of the algorithm (e.g., "HMAC using SHA-256").

アルゴリズムの説明：アルゴリズムの簡単な説明（例：「SHA-256を使用したHMAC」）。

Algorithm Usage Location(s): The algorithm usage locations. This must be one or more of the values "alg" or "enc" if the algorithm is to be used with JWS or JWE. The value "JWK" is used if the algorithm identifier will be used as a JWK "alg" member value, but will not be used with JWS or JWE; this could be the case, for instance, for non-authenticated encryption algorithms. Other values may be used with the approval of a Designated Expert.

アルゴリズムの使用場所：アルゴリズムの使用場所。JWSまたはJWEでアルゴリズムを使用する場合、これは「alg」または「enc」の1つ以上である必要があります。「JWK」の値は、アルゴリズム識別子がJWSまたはJWEとは使用されないが、JWKの「alg」メンバー値として使用される場合に使用されます。これは、認証されていない暗号化アルゴリズムの場合に発生する可能性があります。指定専門家の承認を得て、他の値を使用できます。

JOSE Implementation Requirements: The algorithm implementation requirements for JWS and JWE, which must be one the words Required, Recommended, Optional, Deprecated, or Prohibited. Optionally, the word can be followed by a "+" or "-". The use of "+" indicates that the requirement strength is likely to be increased in a future version of the specification. The use of "-" indicates that the requirement strength is likely to be decreased in a future version of the specification. Any identifiers registered for non-authenticated encryption algorithms or other algorithms that are otherwise unsuitable for direct use as JWS or JWE algorithms must be registered as "Prohibited".

JOSE実装要件： JWSおよびJWEのアルゴリズム実装要件であり、必須、推奨、オプション、非推奨、または禁止のいずれかの単語である必要があります。オプションで、単語の後に「+」または「-」が続く場合があります。「+」の使用は、要件の強度が将来の仕様のバージョンで増加する可能性が高いことを示します。「-」の使用は、要件の強度が将来の仕様のバージョンで減少する可能性が高いことを示します。JWSまたはJWEアルゴリズムとして直接使用することが適さない非認証暗号化アルゴリズムまたはその他のアルゴリズムのために登録された識別子は、「禁止」として登録する必要があります。

Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.

変更管理者：標準トラックRFCの場合、「IESG」をリストします。その他の場合は、責任者の名前を記載します。その他の詳細（例：郵便番号、電子メールアドレス、ホームページURI）も含めることができます。

Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.

仕様書：パラメーターを指定する文書または文書への参照。文書のコピーを取得するために使用できるURIを含めることが望ましいです。関連するセクションの指示を含めることもできますが、必須ではありません。

Algorithm Analysis Documents(s): References to a publication or publications in well-known cryptographic conferences, by national standards bodies, or by other authoritative sources analyzing the cryptographic soundness of the algorithm to be registered. The Designated Experts may require convincing evidence of the cryptographic soundness of a new algorithm to be provided with the registration request unless the algorithm is being registered as Deprecated or Prohibited. Having gone through working group and IETF review, the initial registrations made by this document are exempt from the need to provide this information.

アルゴリズム分析文書：登録されるアルゴリズムの暗号的な信頼性を分析する、よく知られた暗号会議、国家標準機関、またはその他の権威ある情報源による出版物への参照。指定専門家は、新しいアルゴリズムの暗号的な信頼性の説得力のある証拠が登録リクエストとともに提供される必要がある場合があります（アルゴリズムがDeprecatedまたはProhibitedとして登録されている場合を除く）。ワーキンググループおよびIETFのレビューを経て、このドキュメントによって行われた最初の登録は、この情報を提供する必要がありません。

7.1.2. Initial Registry Contents

7.1.2. 初期レジストリの内容

Algorithm Name: "HS256"
Algorithm Description: HMAC using SHA-256
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Required
Change Controller: IESG
Specification Document(s): Section 3.2 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "HS256"
アルゴリズムの説明: SHA-256を使用したHMAC
アルゴリズムの使用場所: "alg"
JOSE実装要件: 必須
変更管理者: IESG
仕様書: RFC 7518のセクション3.2
アルゴリズム分析文書: なし

Algorithm Name: "HS384"
Algorithm Description: HMAC using SHA-384
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 3.2 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "HS384"
アルゴリズムの説明: SHA-384を使用したHMAC
アルゴリズムの使用場所: "alg"
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション3.2
アルゴリズム分析文書: なし

Algorithm Name: "HS512"
Algorithm Description: HMAC using SHA-512
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 3.2 of RFC 7518
Algorithm Analysis Documents(s): n/a

Algorithm Name: "HS512"
Algorithm Description: HMAC using SHA-512
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 3.2 of RFC 7518
Algorithm Analysis Documents(s): n/a

Algorithm Name: "RS256"
Algorithm Description: RSASSA-PKCS1-v1_5 using SHA-256
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Recommended
Change Controller: IESG
Specification Document(s): Section 3.3 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "RS256"
アルゴリズムの説明: SHA-256を使用したRSASSA-PKCS1-v1_5
アルゴリズムの使用場所: "alg"
JOSE実装要件: 推奨
変更管理者: IESG
仕様書: RFC 7518のセクション3.3
アルゴリズム分析文書: なし

Algorithm Name: "RS384"
Algorithm Description: RSASSA-PKCS1-v1_5 using SHA-384
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 3.3 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "RS384"
アルゴリズムの説明: SHA-384を使用したRSASSA-PKCS1-v1_5
アルゴリズムの使用場所: "alg"
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション3.3
アルゴリズム分析文書: なし

Algorithm Name: "RS512"
Algorithm Description: RSASSA-PKCS1-v1_5 using SHA-512
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 3.3 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "RS512"
アルゴリズムの説明: SHA-512を使用したRSASSA-PKCS1-v1_5
アルゴリズムの使用場所: "alg"
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション3.3
アルゴリズム分析文書: なし

Algorithm Name: "ES256"
Algorithm Description: ECDSA using P-256 and SHA-256
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Recommended+
Change Controller: IESG
Specification Document(s): Section 3.4 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "ES256"
アルゴリズムの説明: ECDSA using P-256 and SHA-256
アルゴリズムの使用場所: "alg"
JOSE実装要件: 推奨+
変更管理者: IESG
仕様書: RFC 7518のセクション3.4
アルゴリズム解析文書: n/a

Algorithm Name: "ES384"
Algorithm Description: ECDSA using P-384 and SHA-384
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 3.4 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "ES384"
アルゴリズムの説明: ECDSA using P-384 and SHA-384
アルゴリズムの使用場所: "alg"
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション3.4
アルゴリズム解析文書: n/a

Algorithm Name: "ES512"
Algorithm Description: ECDSA using P-521 and SHA-512
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 3.4 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "ES512"
アルゴリズムの説明: ECDSA using P-521 and SHA-512
アルゴリズムの使用場所: "alg"
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション3.4
アルゴリズム解析文書: n/a

Algorithm Name: "PS256"
Algorithm Description: RSASSA-PSS using SHA-256 and MGF1 with SHA-256
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 3.5 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "PS256"
アルゴリズムの説明: SHA-256およびMGF1を使用したRSASSA-PSS
アルゴリズムの使用場所: "alg"
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション3.5
アルゴリズム分析文書: なし

Algorithm Name: "PS384"
Algorithm Description: RSASSA-PSS using SHA-384 and MGF1 with SHA-384
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 3.5 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "PS384"
アルゴリズムの説明: SHA-384およびMGF1を使用したRSASSA-PSS
アルゴリズムの使用場所: "alg"
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション3.5
アルゴリズム分析文書: なし

Algorithm Name: "PS512"
Algorithm Description: RSASSA-PSS using SHA-512 and MGF1 with SHA-512
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 3.5 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "PS512"
アルゴリズムの説明: SHA-512およびMGF1を使用したRSASSA-PSS
アルゴリズムの使用場所: "alg"
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション3.5
アルゴリズム分析文書: なし

Algorithm Name: "none"
Algorithm Description: No digital signature or MAC performed
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 3.6 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "none"
アルゴリズムの説明: デジタル署名やMACが行われない
アルゴリズムの使用場所: "alg"
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション3.6
アルゴリズム分析文書: なし

Algorithm Name: "RSA1_5"
Algorithm Description: RSAES-PKCS1-v1_5
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Recommended-
Change Controller: IESG
Specification Document(s): Section 4.2 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "RSA1_5"
アルゴリズムの説明: RSAES-PKCS1-v1_5
アルゴリズムの使用場所: "alg"
JOSE実装要件: 推奨
変更管理者: IESG
仕様書: RFC 7518のセクション4.2
アルゴリズム分析文書: なし

Algorithm Name: "RSA-OAEP"
Algorithm Description: RSAES OAEP using default parameters
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Recommended+
Change Controller: IESG
Specification Document(s): Section 4.3 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "RSA-OAEP"
アルゴリズムの説明: デフォルトパラメーターを使用したRSAES OAEP
アルゴリズムの使用場所: "alg"
JOSE実装要件: 推奨以上
変更管理者: IESG
仕様書: RFC 7518のセクション4.3
アルゴリズム分析文書: なし

Algorithm Name: "RSA-OAEP-256"
Algorithm Description: RSAES OAEP using SHA-256 and MGF1 with SHA-256
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 4.3 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "RSA-OAEP-256"
アルゴリズムの説明: SHA-256およびMGF1を使用したRSAES OAEP
アルゴリズムの使用場所: "alg"
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション4.3
アルゴリズム分析文書: なし

Algorithm Name: "A128KW"
Algorithm Description: AES Key Wrap using 128-bit key
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Recommended
Change Controller: IESG
Specification Document(s): Section 4.4 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "A128KW"
アルゴリズムの説明: 128ビットキーを使用したAESキーラップ
アルゴリズムの使用場所: "alg"
JOSE実装要件: 推奨
変更管理者: IESG
仕様書: RFC 7518のセクション4.4
アルゴリズム分析文書: なし

Algorithm Name: "A192KW"
Algorithm Description: AES Key Wrap using 192-bit key
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 4.4 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "A192KW"
アルゴリズムの説明: 192ビットキーを使用したAESキーラップ
アルゴリズムの使用場所: "alg"
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション4.4
アルゴリズム分析文書: なし

Algorithm Name: "A256KW"
Algorithm Description: AES Key Wrap using 256-bit key
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Recommended
Change Controller: IESG
Specification Document(s): Section 4.4 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "A256KW"
アルゴリズムの説明: 256ビットキーを使用したAESキーラップ
アルゴリズムの使用場所: "alg"
JOSE実装要件: 推奨
変更管理者: IESG
仕様書: RFC 7518のセクション4.4
アルゴリズム分析文書: なし

Algorithm Name: "dir"
Algorithm Description: Direct use of a shared symmetric key
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Recommended
Change Controller: IESG
Specification Document(s): Section 4.5 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "dir"
アルゴリズムの説明: 共有対称鍵の直接使用
アルゴリズムの使用場所: "alg"
JOSE実装要件: 推奨
変更管理者: IESG
仕様書: RFC 7518のセクション4.5
アルゴリズム分析文書: なし

Algorithm Name: "ECDH-ES"
Algorithm Description: ECDH-ES using Concat KDF
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Recommended+
Change Controller: IESG
Specification Document(s): Section 4.6 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "ECDH-ES"
アルゴリズムの説明: Concat KDFを使用したECDH-ES
アルゴリズムの使用場所: "alg"
JOSE実装要件: 推奨以上
変更管理者: IESG
仕様書: RFC 7518のセクション4.6
アルゴリズム分析文書: なし

Algorithm Name: "ECDH-ES+A128KW"
Algorithm Description: ECDH-ES using Concat KDF and "A128KW" wrapping
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Recommended
Change Controller: IESG
Specification Document(s): Section 4.6 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "ECDH-ES+A128KW"
アルゴリズムの説明: Concat KDFを使用したECDH-ESおよび"A128KW"のラッピング
アルゴリズムの使用場所: "alg"
JOSE実装要件: 推奨
変更管理者: IESG
仕様書: RFC 7518のセクション4.6
アルゴリズム分析文書: なし

Algorithm Name: "ECDH-ES+A192KW"
Algorithm Description: ECDH-ES using Concat KDF and "A192KW" wrapping
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 4.6 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "ECDH-ES+A192KW"
アルゴリズムの説明: Concat KDFを使用したECDH-ESおよび"A192KW"のラッピング
アルゴリズムの使用場所: "alg"
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション4.6
アルゴリズム分析文書: なし

Algorithm Name: "ECDH-ES+A256KW"
Algorithm Description: ECDH-ES using Concat KDF and "A256KW" wrapping
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Recommended
Change Controller: IESG
Specification Document(s): Section 4.6 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "ECDH-ES+A256KW"
アルゴリズムの説明: Concat KDFを使用したECDH-ESおよび"A256KW"のラッピング
アルゴリズムの使用場所: "alg"
JOSE実装要件: 推奨
変更管理者: IESG
仕様書: RFC 7518のセクション4.6
アルゴリズム分析文書: なし

Algorithm Name: "A128GCMKW"
Algorithm Description: Key wrapping with AES GCM using 128-bit key
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 4.7 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "A128GCMKW"
アルゴリズムの説明: 128ビットキーを使用したAES GCMによるキーのラッピング
アルゴリズムの使用場所: "alg"
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション4.7
アルゴリズム分析文書: なし

Algorithm Name: "A192GCMKW"
Algorithm Description: Key wrapping with AES GCM using 192-bit key
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 4.7 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "A192GCMKW"
アルゴリズムの説明: 192ビットキーを使用したAES GCMによるキーのラッピング
アルゴリズムの使用場所: "alg"
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション4.7
アルゴリズム分析文書: なし

Algorithm Name: "A256GCMKW"
Algorithm Description: Key wrapping with AES GCM using 256-bit key
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 4.7 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "A256GCMKW"
アルゴリズムの説明: 256ビットキーを使用したAES GCMによるキーのラッピング
アルゴリズムの使用場所: "alg"
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション4.7
アルゴリズム分析文書: なし

Algorithm Name: "PBES2-HS256+A128KW"
Algorithm Description: PBES2 with HMAC SHA-256 and "A128KW" wrapping
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 4.8 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "PBES2-HS256+A128KW"
アルゴリズムの説明: HMAC SHA-256と"A128KW"によるPBES2のラッピング
アルゴリズムの使用場所: "alg"
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション4.8
アルゴリズム分析文書: なし

Algorithm Name: "PBES2-HS384+A192KW"
Algorithm Description: PBES2 with HMAC SHA-384 and "A192KW" wrapping
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 4.8 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "PBES2-HS384+A192KW"
アルゴリズムの説明: HMAC SHA-384と"A192KW"によるPBES2のラッピング
アルゴリズムの使用場所: "alg"
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション4.8
アルゴリズム分析文書: なし

Algorithm Name: "PBES2-HS512+A256KW"
Algorithm Description: PBES2 with HMAC SHA-512 and "A256KW" wrapping
Algorithm Usage Location(s): "alg"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 4.8 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "PBES2-HS512+A256KW"
アルゴリズムの説明: HMAC SHA-512と"A256KW"によるPBES2のラッピング
アルゴリズムの使用場所: "alg"
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション4.8
アルゴリズム分析文書: なし

Algorithm Name: "A128CBC-HS256"
Algorithm Description: AES_128_CBC_HMAC_SHA_256 authenticated encryption algorithm
Algorithm Usage Location(s): "enc"
JOSE Implementation Requirements: Required
Change Controller: IESG
Specification Document(s): Section 5.2.3 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "A128CBC-HS256"
アルゴリズムの説明: AES_128_CBC_HMAC_SHA_256による認証付き暗号化アルゴリズム
アルゴリズムの使用場所: "enc"
JOSE実装要件: 必須
変更管理者: IESG
仕様書: RFC 7518のセクション5.2.3
アルゴリズム分析文書: なし

Algorithm Name: "A192CBC-HS384"
Algorithm Description: AES_192_CBC_HMAC_SHA_384 authenticated encryption algorithm
Algorithm Usage Location(s): "enc"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 5.2.4 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "A192CBC-HS384"
アルゴリズムの説明: AES_192_CBC_HMAC_SHA_384による認証付き暗号化アルゴリズム
アルゴリズムの使用場所: "enc"
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション5.2.4
アルゴリズム分析文書: なし

Algorithm Name: "A256CBC-HS512"
Algorithm Description: AES_256_CBC_HMAC_SHA_512 authenticated encryption algorithm
Algorithm Usage Location(s): "enc"
JOSE Implementation Requirements: Required
Change Controller: IESG
Specification Document(s): Section 5.2.5 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "A256CBC-HS512"
アルゴリズムの説明: AES_256_CBC_HMAC_SHA_512による認証付き暗号化アルゴリズム
アルゴリズムの使用場所: "enc"
JOSE実装要件: 必須
変更管理者: IESG
仕様書: RFC 7518のセクション5.2.5
アルゴリズム分析文書: なし

Algorithm Name: "A128GCM"
Algorithm Description: AES GCM using 128-bit key
Algorithm Usage Location(s): "enc"
JOSE Implementation Requirements: Recommended
Change Controller: IESG
Specification Document(s): Section 5.3 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "A128GCM"
アルゴリズムの説明: 128ビットキーを使用したAES GCM
アルゴリズムの使用場所: "enc"
JOSE実装要件: 推奨
変更管理者: IESG
仕様書: RFC 7518のセクション5.3
アルゴリズム分析文書: なし

Algorithm Name: "A192GCM"
Algorithm Description: AES GCM using 192-bit key
Algorithm Usage Location(s): "enc"
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 5.3 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "A192GCM"
アルゴリズムの説明: 192ビットキーを使用したAES GCM
アルゴリズムの使用場所: "enc"
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション5.3
アルゴリズム分析文書: なし

Algorithm Name: "A256GCM"
Algorithm Description: AES GCM using 256-bit key
Algorithm Usage Location(s): "enc"
JOSE Implementation Requirements: Recommended
Change Controller: IESG
Specification Document(s): Section 5.3 of RFC 7518
Algorithm Analysis Documents(s): n/a

アルゴリズム名: "A256GCM"
アルゴリズムの説明: 256ビットキーを使用したAES GCM
アルゴリズムの使用場所: "enc"
JOSE実装要件: 推奨
変更管理者: IESG
仕様書: RFC 7518のセクション5.3
アルゴリズム分析文書: なし

7.2. Header Parameter Names Registration

This section registers the Header Parameter names defined in Sections 4.6.1, 4.7.1, and 4.8.1 of this specification in the IANA "JSON Web Signature and Encryption Header Parameters" registry established by [JWS].

このセクションでは、本仕様書のセクション4.6.1、4.7.1、および4.8.1で定義されたヘッダーパラメーター名を、 [JWS]によって確立されたIANA「JSON Web Signature and Encryption Header Parameters」レジストリに登録します。

7.2.1. Registry Contents

7.2.1. レジストリの内容

Header Parameter Name: "epk"
Header Parameter Description: Ephemeral Public Key
Header Parameter Usage Location(s): JWE
Change Controller: IESG
Specification Document(s): Section 4.6.1.1 of RFC 7518

ヘッダーパラメーター名: "epk"
ヘッダーパラメーターの説明: 一時的な公開鍵
ヘッダーパラメーターの使用場所: JWE
変更管理者: IESG
仕様書: RFC 7518のセクション4.6.1.1

Header Parameter Name: "apu"
Header Parameter Description: Agreement PartyUInfo
Header Parameter Usage Location(s): JWE
Change Controller: IESG
Specification Document(s): Section 4.6.1.2 of RFC 7518

ヘッダーパラメーター名: "apu"
ヘッダーパラメーターの説明: Agreement PartyUInfo
ヘッダーパラメーターの使用場所: JWE
変更管理者: IESG
仕様書: RFC 7518のセクション4.6.1.2

Header Parameter Name: "apv"
Header Parameter Description: Agreement PartyVInfo
Header Parameter Usage Location(s): JWE
Change Controller: IESG
Specification Document(s): Section 4.6.1.3 of RFC 7518

ヘッダーパラメーター名: "apv"
ヘッダーパラメーターの説明: Agreement PartyVInfo
ヘッダーパラメーターの使用場所: JWE
変更管理者: IESG
仕様書: RFC 7518のセクション4.6.1.3

Header Parameter Name: "iv"
Header Parameter Description: Initialization Vector
Header Parameter Usage Location(s): JWE
Change Controller: IESG
Specification Document(s): Section 4.7.1.1 of RFC 7518

ヘッダーパラメーター名: "iv"
ヘッダーパラメーターの説明: Initialization Vector
ヘッダーパラメーターの使用場所: JWE
変更管理者: IESG
仕様書: RFC 7518のセクション4.7.1.1

Header Parameter Name: "tag"
Header Parameter Description: Authentication Tag
Header Parameter Usage Location(s): JWE
Change Controller: IESG
Specification Document(s): Section 4.7.1.2 of RFC 7518

ヘッダーパラメーター名: "tag"
ヘッダーパラメーターの説明: 認証タグ
ヘッダーパラメーターの使用場所: JWE
変更管理者: IESG
仕様書: RFC 7518のセクション4.7.1.2

Header Parameter Name: "p2s"
Header Parameter Description: PBES2 Salt Input
Header Parameter Usage Location(s): JWE
Change Controller: IESG
Specification Document(s): Section 4.8.1.1 of RFC 7518

ヘッダーパラメーター名: "p2s"
ヘッダーパラメーターの説明: PBES2ソルト入力
ヘッダーパラメーターの使用場所: JWE
変更管理者: IESG
仕様書: RFC 7518のセクション4.8.1.1

Header Parameter Name: "p2c"
Header Parameter Description: PBES2 Count
Header Parameter Usage Location(s): JWE
Change Controller: IESG
Specification Document(s): Section 4.8.1.2 of RFC 7518

ヘッダーパラメーター名: "p2c"
ヘッダーパラメーターの説明: PBES2カウント
ヘッダーパラメーターの使用場所: JWE
変更管理者: IESG
仕様書: RFC 7518のセクション4.8.1.2

7.3. JSON Web Encryption Compression Algorithms Registry

This specification establishes the IANA "JSON Web Encryption Compression Algorithms" registry for JWE "zip" member values. The registry records the compression algorithm value and a reference to the specification that defines it.

この仕様書は、JWEの"zip"メンバー値のためのIANA「JSON Web Encryption Compression Algorithms」レジストリを確立します。レジストリには、圧縮アルゴリズム値と、それを定義する仕様書への参照が記録されます。

7.3.1. Registration Template

7.3.1. 登録テンプレート

Compression Algorithm Value: The name requested (e.g., "DEF"). Because a core goal of this specification is for the resulting representations to be compact, it is RECOMMENDED that the name be short -- not to exceed 8 characters without a compelling reason to do so. This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception.

圧縮アルゴリズム値：要求される名前（例：「DEF」）。この仕様書の主要な目標の1つは、生成された表現がコンパクトであることです。そのため、名前が短くなることが推奨されます（RECOMMENDED）。強い理由がない限り、8文字を超えないようにしてください。この名前は大文字と小文字を区別します。指定専門家が例外を許可する理由がある場合を除き、他の登録された名前と大文字と小文字を区別しないでください。

Compression Algorithm Description: Brief description of the compression algorithm (e.g., "DEFLATE").

圧縮アルゴリズムの説明：圧縮アルゴリズムの簡単な説明（例：「DEFLATE」）。

Change Controller: For Standards Track RFCs, list "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.

変更管理者：標準トラックRFCの場合、「IESG」をリストします。その他の場合は、責任者の名前を記載してください。その他の詳細（例：郵便番号、電子メールアドレス、ホームページURI）も含めることができます。

仕様書：パラメーターを指定する文書または文書への参照。文書のコピーを取得するために使用できるURIを含めることが望ましいです。関連するセクションの指示も含めることができますが、必須ではありません。

7.3.2. Initial Registry Contents

7.3.2. 初期レジストリの内容

Compression Algorithm Value: "DEF"
Compression Algorithm Description: DEFLATE
Change Controller: IESG
Specification Document(s): JSON Web Encryption (JWE) [JWE]

圧縮アルゴリズム値: "DEF"
圧縮アルゴリズムの説明: DEFLATE
変更管理者: IESG
仕様書: JSON Web Encryption (JWE) [JWE]

7.4. JSON Web Key Types Registry

This specification establishes the IANA "JSON Web Key Types" registry for values of the JWK "kty" (key type) parameter. The registry records the "kty" value, implementation requirements, and a reference to the specification that defines it.

この仕様書は、JWKの"kty"（鍵タイプ）パラメーターの値のためのIANA「JSON Web Key Types」レジストリを確立します。レジストリには、「kty」値、実装要件、およびそれを定義する仕様書への参照が記録されます。

The implementation requirements of a key type may be changed over time as the cryptographic landscape evolves, for instance, to change the status of a key type to Deprecated or to change the status of a key type from Optional to Recommended+ or Required. Changes of implementation requirements are only permitted on a Specification Required basis after review by the Designated Experts, with the new specification defining the revised implementation requirements level.

鍵タイプの実装要件は、暗号技術の進化に伴い、時間の経過とともに変更される場合があります。たとえば、鍵タイプのステータスを「非推奨」に変更したり、「オプション」から「推奨+」または「必須」に変更したりすることができます。実装要件の変更は、指定専門家によるレビューを経て、仕様書によって定義された仕様要件レベルを改訂することができます。

7.4.1. Registration Template

7.4.1. 登録テンプレート

"kty" Parameter Value: The name requested (e.g., "EC"). Because a core goal of this specification is for the resulting representations to be compact, it is RECOMMENDED that the name be short -- not to exceed 8 characters without a compelling reason to do so. This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception.

「kty」パラメーター値：要求される名前（例：「EC」）。この仕様書の主要な目標の1つは、生成された表現がコンパクトであることです。そのため、名前が短くなることが推奨されます（RECOMMENDED）。強い理由がない限り、8文字を超えないようにしてください。この名前は大文字と小文字を区別します。指定専門家が例外を許可する理由がある場合を除き、他の登録された名前と大文字と小文字を区別しないでください。

Key Type Description: Brief description of the Key Type (e.g., "Elliptic Curve").

鍵タイプの説明：鍵タイプの簡単な説明（例：「楕円曲線」）。

Change Controller: For Standards Track RFCs, list "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.

JOSE Implementation Requirements: The key type implementation requirements for JWS and JWE, which must be one the words Required, Recommended, Optional, Deprecated, or Prohibited. Optionally, the word can be followed by a "+" or "-". The use of "+" indicates that the requirement strength is likely to be increased in a future version of the specification. The use of "-" indicates that the requirement strength is likely to be decreased in a future version of the specification.

JOSE実装要件： JWSおよびJWEの鍵タイプ実装要件で、必須、推奨、オプション、非推奨、または禁止のいずれかの単語である必要があります。オプションで、単語の後に「+」または「-」を付けることができます。「+」の使用は、要件の強度が将来の仕様のバージョンで増加する可能性があることを示します。「-」の使用は、要件の強度が将来の仕様のバージョンで減少する可能性があることを示します。

7.4.2. Initial Registry Contents

7.4.2. 初期レジストリの内容

This section registers the values defined in Section 6.1.

このセクションでは、セクション6.1で定義された値を登録します。

"kty" Parameter Value: "EC"
Key Type Description: Elliptic Curve
JOSE Implementation Requirements: Recommended+
Change Controller: IESG
Specification Document(s): Section 6.2 of RFC 7518

"kty"パラメーター値: "EC"
キータイプの説明: 楕円曲線
JOSE実装要件: 推奨+
変更管理者: IESG
仕様書: RFC 7518のセクション6.2

"kty" Parameter Value: "RSA"
Key Type Description: RSA
JOSE Implementation Requirements: Required
Change Controller: IESG
Specification Document(s): Section 6.3 of RFC 7518

"kty"パラメーター値: "RSA"
キータイプの説明: RSA
JOSE実装要件: 必須
変更管理者: IESG
仕様書: RFC 7518のセクション6.3

"kty" Parameter Value: "oct"
Key Type Description: Octet Sequence
JOSE Implementation Requirements: Required
Change Controller: IESG
Specification Document(s): Section 6.4 of RFC 7518

"kty"パラメーター値: "oct"
キータイプの説明: オクテットシーケンス
JOSE実装要件: 必須
変更管理者: IESG
仕様書: RFC 7518のセクション6.4

7.5. JSON Web Key Parameters Registration

This section registers the parameter names defined in Sections 6.2, 6.3, and 6.4 of this specification in the IANA "JSON Web Key Parameters" registry established by [JWK].

このセクションでは、この仕様書のセクション6.2、6.3、および6.4で定義されたパラメーター名を、[JWK]によって確立されたIANA「JSON Web Key Parameters」レジストリに登録します。

7.5.1. Registry Contents

7.5.1. レジストリの内容

Parameter Name: "crv"
Parameter Description: Curve
Used with "kty" Value(s): "EC"
Parameter Information Class: Public
Change Controller: IESG
Specification Document(s): Section 6.2.1.1 of RFC 7518

パラメーター名: "crv"
パラメーターの説明: 曲線
"kty"パラメーター値: "EC"
パラメーター情報クラス: 公開
変更管理者: IESG
仕様書: RFC 7518のセクション6.2.1.1

Parameter Name: "x"
Parameter Description: X Coordinate
Used with "kty" Value(s): "EC"
Parameter Information Class: Public
Change Controller: IESG
Specification Document(s): Section 6.2.1.2 of RFC 7518

パラメーター名: "x"
パラメーターの説明: X座標
"kty"パラメーター値: "EC"
パラメーター情報クラス: 公開
変更管理者: IESG
仕様書: RFC 7518のセクション6.2.1.2

Parameter Name: "y"
Parameter Description: Y Coordinate
Used with "kty" Value(s): "EC"
Parameter Information Class: Public
Change Controller: IESG
Specification Document(s): Section 6.2.1.3 of RFC 7518

パラメーター名: "y"
パラメーターの説明: Y座標
"kty"パラメーター値: "EC"
パラメーター情報クラス: 公開
変更管理者: IESG
仕様書: RFC 7518のセクション6.2.1.3

Parameter Name: "d"
Parameter Description: ECC Private Key
Used with "kty" Value(s): "EC"
Parameter Information Class: Private
Change Controller: IESG
Specification Document(s): Section 6.2.2.1 of RFC 7518

パラメーター名: "d"
パラメーターの説明: ECCプライベートキー
"kty"パラメーター値: "EC"
パラメーター情報クラス: プライベート
変更管理者: IESG
仕様書: RFC 7518のセクション6.2.2.1

Parameter Name: "n"
Parameter Description: Modulus
Used with "kty" Value(s): "RSA"
Parameter Information Class: Public
Change Controller: IESG
Specification Document(s): Section 6.3.1.1 of RFC 7518

パラメーター名: "n"
パラメーターの説明: モジュラス
"kty"パラメーター値: "RSA"
パラメーター情報クラス: 公開
変更管理者: IESG
仕様書: RFC 7518のセクション6.3.1.1

Parameter Name: "e"
Parameter Description: Exponent
Used with "kty" Value(s): "RSA"
Parameter Information Class: Public
Change Controller: IESG
Specification Document(s): Section 6.3.1.2 of RFC 7518

パラメーター名: "e"
パラメーターの説明: 指数
"kty"値との使用: "RSA"
パラメーター情報クラス: 公開
変更管理者: IESG
仕様書: RFC 7518のセクション6.3.1.2

Parameter Name: "d"
Parameter Description: Private Exponent
Used with "kty" Value(s): "RSA"
Parameter Information Class: Private
Change Controller: IESG
Specification Document(s): Section 6.3.2.1 of RFC 7518

パラメーター名: "d"
パラメーターの説明: 秘密指数
"kty"値との使用: "RSA"
パラメーター情報クラス: 秘密
変更管理者: IESG
仕様書: RFC 7518のセクション6.3.2.1

Parameter Name: "p"
Parameter Description: First Prime Factor
Used with "kty" Value(s): "RSA"
Parameter Information Class: Private
Change Controller: IESG
Specification Document(s): Section 6.3.2.2 of RFC 7518

パラメーター名: "p"
パラメーターの説明: 最初の素因数
"kty"値との使用: "RSA"
パラメーター情報クラス: 秘密
変更管理者: IESG
仕様書: RFC 7518のセクション6.3.2.2

Parameter Name: "q"
Parameter Description: Second Prime Factor
Used with "kty" Value(s): "RSA"
Parameter Information Class: Private
Change Controller: IESG
Specification Document(s): Section 6.3.2.3 of RFC 7518

パラメーター名: "q"
パラメーターの説明: 2番目の素因数
"kty"値との使用: "RSA"
パラメーター情報クラス: 秘密
変更管理者: IESG
仕様書: RFC 7518のセクション6.3.2.3

Parameter Name: "dp"
Parameter Description: First Factor CRT Exponent
Used with "kty" Value(s): "RSA"
Parameter Information Class: Private
Change Controller: IESG
Specification Document(s): Section 6.3.2.4 of RFC 7518

パラメーター名: "dp"
パラメーターの説明: 最初の素因数CRT指数
"kty"値との使用: "RSA"
パラメーター情報クラス: 秘密
変更管理者: IESG
仕様書: RFC 7518のセクション6.3.2.4

Parameter Name: "dq"
Parameter Description: Second Factor CRT Exponent
Used with "kty" Value(s): "RSA"
Parameter Information Class: Private
Change Controller: IESG
Specification Document(s): Section 6.3.2.5 of RFC 7518

パラメーター名: "dq"
パラメーターの説明: 2番目の素因数CRT指数
"kty"値との使用: "RSA"
パラメーター情報クラス: 秘密
変更管理者: IESG
仕様書: RFC 7518のセクション6.3.2.5

Parameter Name: "qi"
Parameter Description: First CRT Coefficient
Used with "kty" Value(s): "RSA"
Parameter Information Class: Private
Change Controller: IESG
Specification Document(s): Section 6.3.2.6 of RFC 7518

パラメーター名: "qi"
パラメーターの説明: 2番目の素因数CRT係数
"kty"値との使用: "RSA"
パラメーター情報クラス: 秘密
変更管理者: IESG
仕様書: RFC 7518のセクション6.3.2.6

Parameter Name: "oth"
Parameter Description: Other Primes Info
Used with "kty" Value(s): "RSA"
Parameter Information Class: Private
Change Controller: IESG
Specification Document(s): Section 6.3.2.7 of RFC 7518

パラメーター名: "oth"
パラメーターの説明: その他の素数情報
"kty"値との使用: "RSA"
パラメーター情報クラス: 秘密
変更管理者: IESG
仕様書: RFC 7518のセクション6.3.2.7

Parameter Name: "k"
Parameter Description: Key Value
Used with "kty" Value(s): "oct"
Parameter Information Class: Private
Change Controller: IESG
Specification Document(s): Section 6.4.1 of RFC 7518

パラメーター名: "k"
パラメーターの説明: キー値
"kty"値との使用: "oct"
パラメーター情報クラス: 秘密
変更管理者: IESG
仕様書: RFC 7518のセクション6.4.1

7.6. JSON Web Key Elliptic Curve Registry

This section establishes the IANA "JSON Web Key Elliptic Curve" registry for JWK "crv" member values. The registry records the curve name, implementation requirements, and a reference to the specification that defines it. This specification registers the parameter names defined in Section 6.2.1.1.

このセクションでは、JWKの「crv」メンバー値のためのIANA「JSON Web Key Elliptic Curve」レジストリを確立します。レジストリには、曲線名、実装要件、およびそれを定義する仕様書への参照が記録されます。この仕様書では、セクション6.2.1.1で定義されたパラメーター名を登録します。

The implementation requirements of a curve may be changed over time as the cryptographic landscape evolves, for instance, to change the status of a curve to Deprecated or to change the status of a curve from Optional to Recommended+ or Required. Changes of implementation requirements are only permitted on a Specification Required basis after review by the Designated Experts, with the new specification defining the revised implementation requirements level.

曲線の実装要件は、暗号技術の進化に伴い、Deprecatedのステータスを変更したり、OptionalからRecommended+またはRequiredに変更したりするなど、時間の経過とともに変更される場合があります。実装要件の変更は、指定された専門家によるレビューを経て、仕様書によって新しい実装要件レベルが定義された場合にのみ、仕様書が必要とされる基準で許可されます。

7.6.1. Registration Template

7.6.1. 登録テンプレート

Curve Name: The name requested (e.g., "P-256"). Because a core goal of this specification is for the resulting representations to be compact, it is RECOMMENDED that the name be short -- not to exceed 8 characters without a compelling reason to do so. This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception.

曲線名: 要求された名前（例：「P-256」）。この仕様書の主要な目標は、生成された表現がコンパクトであることであるため、名前が短くなることが推奨されます（RECOMMENDED）。強い理由がない限り、8文字を超えないようにしてください。この名前は大文字小文字を区別します。登録された他の名前と大文字小文字を区別しない場合は、指定された専門家が例外を許可する理由がある場合を除き、許可されません。

Curve Description: Brief description of the curve (e.g., "P-256 Curve").

曲線の説明: 曲線の簡単な説明（例：「P-256曲線」）。

JOSE Implementation Requirements: The curve implementation requirements for JWS and JWE, which must be one the words Required, Recommended, Optional, Deprecated, or Prohibited. Optionally, the word can be followed by a "+" or "-".

JOSE実装要件: JWSおよびJWEの曲線実装要件であり、必須、推奨、オプション、非推奨、または禁止のいずれかの単語である必要があります。オプションで、単語の後に「+」または「-」を付けることができます。

   The use of "+" indicates that the requirement strength is likely
   to be increased in a future version of the specification.  The use
   of "-" indicates that the requirement strength is likely to be
   decreased in a future version of the specification.

   The use of "+" indicates that the requirement strength is likely
   to be increased in a future version of the specification.  The use
   of "-" indicates that the requirement strength is likely to be
   decreased in a future version of the specification.

Change Controller: For Standards Track RFCs, list "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.

変更管理者: 標準トラックRFCの場合、「IESG」をリストします。その他の場合は、責任者の名前を指定します。その他の詳細（郵便番号、電子メールアドレス、ホームページURIなど）も含めることができます。

仕様書: パラメーターを指定するドキュメントへの参照。できれば、ドキュメントのコピーを取得するために使用できるURIを含めることが望ましいです。関連するセクションの指示も含めることができますが、必須ではありません。

7.6.2. Initial Registry Contents

7.6.2. 初期レジストリの内容

Curve Name: "P-256"
Curve Description: P-256 Curve
JOSE Implementation Requirements: Recommended+
Change Controller: IESG
Specification Document(s): Section 6.2.1.1 of RFC 7518

曲線名: "P-256"
曲線の説明: P-256曲線
JOSE実装要件: 推奨+
変更管理者: IESG
仕様書: RFC 7518のセクション6.2.1.1

Curve Name: "P-384"
Curve Description: P-384 Curve
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 6.2.1.1 of RFC 7518

曲線名: "P-384"
曲線の説明: P-384曲線
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション6.2.1.1

Curve Name: "P-521"
Curve Description: P-521 Curve
JOSE Implementation Requirements: Optional
Change Controller: IESG
Specification Document(s): Section 6.2.1.1 of RFC 7518

曲線名: "P-521"
曲線の説明: P-521曲線
JOSE実装要件: オプション
変更管理者: IESG
仕様書: RFC 7518のセクション6.2.1.1

8. Security Considerations

8. セキュリティーに関する考慮事項

All of the security issues that are pertinent to any cryptographic application must be addressed by JWS/JWE/JWK agents. Among these issues are protecting the user's asymmetric private and symmetric secret keys and employing countermeasures to various attacks.

JWS/JWE/JWKエージェントは、暗号化アプリケーションに関連するすべてのセキュリティー問題に対処する必要があります。これらの問題の中には、ユーザーの非対称秘密鍵と対称秘密鍵を保護すること、およびさまざまな攻撃に対する対策を講じることが含まれます。

The security considerations in [AES], [DSS], [JWE], [JWK], [JWS], [NIST.800-38D], [NIST.800-56A], [NIST.800-107], [RFC2104], [RFC3394], [RFC3447], [RFC5116], [RFC6090], and [SHS] apply to this specification.

この仕様書には、[AES]、[DSS]、[JWE]、[JWK]、[JWS]、[NIST.800-38D]、[NIST.800-56A]、[NIST.800-107]、[RFC2104]、[RFC3394]、[RFC3447]、[RFC5116]、[RFC6090]、および[SHS]のセキュリティーに関する考慮事項が適用されます。

8.1. Cryptographic Agility

8.1. 暗号アジリティ

Implementers should be aware that cryptographic algorithms become weaker with time. As new cryptanalysis techniques are developed and computing performance improves, the work factor to break a particular cryptographic algorithm will be reduced. Therefore, implementers and deployments must be prepared for the set of algorithms that are supported and used to change over time. Thus, cryptographic algorithm implementations should be modular, allowing new algorithms to be readily inserted.

実装者は、暗号アルゴリズムが時間とともに弱くなることを認識する必要があります。新しい暗号解読技術が開発され、コンピューティング性能が向上するにつれて、特定の暗号アルゴリズムを破るための作業量が減少します。したがって、実装者と展開は、サポートされるアルゴリズムのセットと使用されるアルゴリズムが時間とともに変化することに備える必要があります。したがって、暗号アルゴリズムの実装はモジュール化されており、新しいアルゴリズムを簡単に挿入できるようにする必要があります。

8.2. Key Lifetimes

8.2. 鍵の有効期間

Many algorithms have associated security considerations related to key lifetimes and/or the number of times that a key may be used. Those security considerations continue to apply when using those algorithms with JOSE data structures. See NIST SP 800-57 [NIST.800-57] for specific guidance on key lifetimes.

多くのアルゴリズムには、キーの寿命と/またはキーが使用できる回数の数に関連するセキュリティー上の考慮事項があります。これらのセキュリティー上の考慮事項は、JOSEデータ構造を使用する場合にも適用されます。キーの寿命に関する具体的なガイダンスについては、NIST SP 800-57[NIST.800-57]を参照してください。

8.3. RSAES-PKCS1-v1_5 Security Considerations

8.3. RSAES-PKCS1-v1_5 セキュリティーに関する考慮事項

While Section 8 of RFC 3447 [RFC3447] explicitly calls for people not to adopt RSASSA-PKCS1-v1_5 for new applications and instead requests that people transition to RSASSA-PSS, this specification does include RSASSA-PKCS1-v1_5, for interoperability reasons, because it is commonly implemented.

RFC 3447のセクション8は、新しいアプリケーションでRSASSA-PKCS1-v1_5を採用しないように明示的に指示し、代わりにRSASSA-PSSへの移行を要求していますが、相互運用性のために、一般的に実装されているため、この仕様書にはRSASSA-PKCS1-v1_5が含まれています。

Keys used with RSAES-PKCS1-v1_5 must follow the constraints in Section 7.2 of RFC 3447. Also, keys with a low public key exponent value, as described in Section 3 of "Twenty Years of Attacks on the RSA Cryptosystem" [Boneh99], must not be used.

RSAES-PKCS1-v1_5で使用されるキーは、RFC 3447のセクション7.2の制約にしたがう必要があります。また、「RSA暗号システムに対する20年間の攻撃」[Boneh99]のセクション3で説明されているように、公開鍵指数の値が低いキーは使用しないでください。

8.4. AES GCM Security Considerations

8.4. AES GCM セキュリティーに関する考慮事項

Keys used with AES GCM must follow the constraints in Section 8.3 of [NIST.800-38D], which states: "The total number of invocations of the authenticated encryption function shall not exceed 2^32, including all IV lengths and all instances of the authenticated encryption function with the given key". In accordance with this rule, AES GCM MUST NOT be used with the same key value more than 2^32 times.

AES GCMで使用されるキーは、[NIST.800-38D]のセクション8.3の制約にしたがう必要があります。この制約には、「与えられたキーでのすべてのIV長と認証暗号化関数のすべてのインスタンスを含め、認証暗号化関数の総呼び出し回数は2^32を超えてはならない」と記載されています。このルールにしたがい、AES GCMは同じキー値で2^32回以上使用してはなりません（MUST NOT）。

An IV value MUST NOT ever be used multiple times with the same AES GCM key. One way to prevent this is to store a counter with the key and increment it with every use. The counter can also be used to prevent exceeding the 2^32 limit above.

AES GCMキーで複数回同じIV値を使用してはなりません（MUST NOT）。これを防ぐ方法の1つは、キーとカウンタを保存し、使用するたびにカウンタをインクリメントすることです。カウンタは、上記の2^32の制限を超えないようにするためにも使用できます。

This security consideration does not apply to the composite AES-CBC HMAC SHA-2 or AES Key Wrap algorithms.

このセキュリティー上の考慮事項は、複合AES-CBC HMAC SHA-2またはAES Key Wrapアルゴリズムには適用されません。

8.5. Unsecured JWS Security Considerations

8.5. Unsecured JWS セキュリティーに関する考慮事項

Unsecured JWSs (JWSs that use the "alg" value "none") provide no integrity protection. Thus, they must only be used in contexts in which the payload is secured by means other than a digital signature or MAC value, or they need not be secured.

「alg」値が「none」であるJWS（「Unsecured JWS」と呼ばれる）は整合性保護を提供しません。したがって、ペイロードがデジタル署名またはMAC値以外の手段で保護されている場合、または保護する必要がない場合にのみ使用する必要があります。

An example means of preventing accepting Unsecured JWSs by default is for the "verify" method of a hypothetical JWS software library to have a Boolean "acceptUnsecured" parameter that indicates "none" is an acceptable "alg" value. As another example, the "verify" method might take a list of algorithms that are acceptable to the application as a parameter and would reject Unsecured JWS values if "none" is not in that list.

デフォルトでUnsecured JWSを受け入れないようにするための例として、仮想JWSソフトウェアライブラリの「verify」メソッドには、Boolean型の「acceptUnsecured」パラメーターがあり、「none」が許容される「alg」値であることを示します。別の例として、「verify」メソッドは、アプリケーションで許容されるアルゴリズムのリストをパラメーターとして受け取り、そのリストに「none」が含まれていない場合、Unsecured JWS値を拒否します。

The following example illustrates the reasons for not accepting Unsecured JWSs at a global level. Suppose an application accepts JWSs over two channels, (1) HTTP and (2) HTTPS with client authentication. It requires a JWS Signature on objects received over HTTP, but accepts Unsecured JWSs over HTTPS. If the application were to globally indicate that "none" is acceptable, then an attacker could provide it with an Unsecured JWS over HTTP and still have that object successfully validate. Instead, the application needs to indicate acceptance of "none" for each object received over HTTPS (e.g., by setting "acceptUnsecured" to "true" for the first hypothetical JWS software library above), but not for each object received over HTTP.

次の例は、グローバルレベルでUnsecured JWSを受け入れない理由を示しています。アプリケーションが2つのチャネル、すなわち（1）HTTPと（2）クライアント認証付きHTTPSでJWSを受け入れる場合を考えます。HTTPで受信したオブジェクトにはJWS Signatureが必要ですが、HTTPSでUnsecured JWSを受け入れます。アプリケーションが「none」が許容されることをグローバルに示す場合、攻撃者はHTTP経由でUnsecured JWSを提供し、そのオブジェクトを正常に検証できます。代わりに、アプリケーションはHTTPSで受信した各オブジェクトについて「none」を許容することを示す必要があります（たとえば、上記の仮想JWSソフトウェアライブラリの最初の例で「acceptUnsecured」を「true」に設定することによって）、ただしHTTPで受信した各オブジェクトについては許容しないでください。

8.6. Denial-of-Service Attacks

8.6. サービス拒否攻撃

Receiving agents that validate signatures and sending agents that encrypt messages need to be cautious of cryptographic processing usage when validating signatures and encrypting messages using keys larger than those mandated in this specification. An attacker could supply content using keys that would result in excessive cryptographic processing, for example, keys larger than those mandated in this specification. Implementations should set and enforce upper limits on the key sizes they accept. Section 5.6.1 (Comparable Algorithm Strengths) of NIST SP 800-57 [NIST.800-57] contains statements on largest approved key sizes that may be applicable.

署名を検証する受信エージェントとメッセージを暗号化する送信エージェントは、この仕様書で規定されているものよりも大きな鍵を使用して署名を検証およびメッセージを暗号化する場合には、暗号処理の使用に注意する必要があります。攻撃者は、この仕様書で規定されているものよりも大きな鍵を使用してコンテンツを提供でき、たとえば、この仕様書で規定されているものよりも大きな鍵を使用できます。実装者は、受け入れる鍵サイズの上限を設定し、強制する必要があります。NIST SP 800-57 [NIST.800-57] の5.6.1節（同等のアルゴリズム強度）には、適用可能な最大承認鍵サイズに関する記述が含まれています。

8.7. Reusing Key Material when Encrypting Keys

8.7. 鍵を暗号化する際の鍵素材の再利用

It is NOT RECOMMENDED to reuse the same entire set of key material (Key Encryption Key, Content Encryption Key, Initialization Vector, etc.) to encrypt multiple JWK or JWK Set objects, or to encrypt the same JWK or JWK Set object multiple times. One suggestion for preventing reuse is to always generate at least one new piece of key material for each encryption operation (e.g., a new Content Encryption Key, a new IV, and/or a new PBES2 Salt), based on the considerations noted in this document as well as from RFC 4086 [RFC4086].

同じ鍵素材のセット（鍵暗号化鍵、コンテンツ暗号化鍵、初期化ベクトルなど）を複数のJWKまたはJWKセットオブジェクトを暗号化するために再利用することは推奨されません（NOT RECOMMENDED）。また、同じJWKまたはJWKセットオブジェクトを複数回暗号化することも推奨されません。再利用を防止するための1つの提案は、常に少なくとも1つの新しい鍵素材（例：新しいコンテンツ暗号化鍵、新しいIV、および/または新しいPBES2 Salt）を各暗号化操作ごとに生成することです。RFC 4086[RFC4086]の考慮事項に加え、このドキュメントで指定された考慮事項に基づいています。

8.8. Password Considerations

8.8. パスワードに関する考慮事項

Passwords are vulnerable to a number of attacks. To help mitigate some of these limitations, this document applies principles from RFC 2898 [RFC2898] to derive cryptographic keys from user-supplied passwords.

パスワードは、さまざまな攻撃に対して脆弱です。このドキュメントでは、RFC 2898[RFC2898]の原則を適用して、ユーザーが提供したパスワードから暗号鍵を派生させることで、これらの制限のいくつかを緩和することができます。

However, the strength of the password still has a significant impact. A high-entropy password has greater resistance to dictionary attacks. [NIST.800-63-2] contains guidelines for estimating password entropy, which can help applications and users generate stronger passwords.

ただし、パスワードの強度は依然として重要な影響を持ちます。高エントロピーのパスワードは、辞書攻撃に対してより強い耐性を持ちます。NIST SP 800-63-2 [NIST.800-63-2] には、パスワードのエントロピーを推定するためのガイドラインが含まれており、これにより、アプリケーションやユーザーがより強力なパスワードを生成できます。

An ideal password is one that is as large as (or larger than) the derived key length. However, passwords larger than a certain algorithm-specific size are first hashed, which reduces an attacker's effective search space to the length of the hash algorithm. It is RECOMMENDED that a password used for "PBES2-HS256+A128KW" be no shorter than 16 octets and no longer than 128 octets and a password used for "PBES2-HS512+A256KW" be no shorter than 32 octets and no longer than 128 octets long.

理想的なパスワードは、派生鍵の長さと同じかそれ以上の長さであることです。ただし、特定のアルゴリズムに固有のサイズよりも大きなパスワードは、最初にハッシュされるため、攻撃者の有効な探索空間がハッシュアルゴリズムの長さに制限されます。したがって、「PBES2-HS256+A128KW」に使用されるパスワードは、16オクテット以上128オクテット以下であり、「PBES2-HS512+A256KW」に使用されるパスワードは、32オクテット以上128オクテット以下であることが推奨されます（RECOMMENDED）。

Still, care needs to be taken in where and how password-based encryption is used. These algorithms can still be susceptible to dictionary-based attacks if the iteration count is too small; this is of particular concern if these algorithms are used to protect data that an attacker can have indefinite number of attempts to circumvent the protection, such as protected data stored on a file system.

ただし、パスワードベースの暗号化が使用される場所と方法には注意が必要です。これらのアルゴリズムは、反復回数が小さすぎる場合には辞書攻撃に対して依然として脆弱であり、攻撃者が保護を回避するために無制限の試行回数を持つことができるデータ（たとえば、ファイルシステムに保存された保護されたデータ）を保護するためにこれらのアルゴリズムが使用される場合にはとくに注意が必要です。

8.9. Key Entropy and Random Values

8.9. 鍵のエントロピーとランダム値

See Section 10.1 of [JWS] for security considerations on key entropy and random values.

[JWS]のセクション10.1を参照して、鍵のエントロピーとランダム値に関するセキュリティー上の考慮事項について説明します。

8.10. Differences between Digital Signatures and MACs

8.10. デジタル署名と MAC の違い

See Section 10.5 of [JWS] for security considerations on differences between digital signatures and MACs.

[JWS]のセクション10.5を参照して、デジタル署名とMACの違いに関するセキュリティー上の考慮事項について説明します。

8.11. Using Matching Algorithm Strengths

8.11. マッチングアルゴリズムの強度の使用

See Section 11.3 of [JWE] for security considerations on using matching algorithm strengths.

[JWE]のセクション11.3を参照して、一致するアルゴリズムの強度を使用する場合のセキュリティー上の考慮事項について説明します。

8.12. Adaptive Chosen-Ciphertext Attacks

8.12. 適応型選択暗号文攻撃

See Section 11.4 of [JWE] for security considerations on adaptive chosen-ciphertext attacks.

[JWE]のセクション11.4を参照して、適応的選択暗号文攻撃に関するセキュリティー上の考慮事項について説明します。

8.13. Timing Attacks

8.13. タイミング攻撃

See Section 10.9 of [JWS] and Section 11.5 of [JWE] for security considerations on timing attacks.

[JWS]のセクション10.9および[JWE]のセクション11.5を参照して、タイミング攻撃に関するセキュリティー上の考慮事項について説明します。

8.14. RSA Private Key Representations and Blinding

8.14. RSAプライベートキーの表現とブラインディング

See Section 9.3 of [JWK] for security considerations on RSA private key representations and blinding.

[JWK]のセクション9.3を参照して、RSA秘密鍵の表現とブラインディングに関するセキュリティー上の考慮事項について説明します。


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


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


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


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


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


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

Appendix B. AES_CBC_HMAC_SHA2 アルゴリズムのテストケース

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.

以下のテストケースは、セクション5.2で定義されたAES_CBC_HMAC_SHA2アルゴリズムの実装を検証するために使用できます。また、暗号計算が同じであることを示す、将来の[AEAD-CBC-SHA]のバージョンに表示される可能性のあるテストケースに対応することも意図されています。

The variable names are those defined in Section 5.2. All values are hexadecimal.

変数名は、セクション5.2で定義されたものです。すべての値は16進数です。

B.1. Test Cases for AES_128_CBC_HMAC_SHA_256

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

  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

  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

  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

  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

  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

  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

  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

  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

  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

  T =       65 2c 3f a3 6b 0a 7c 5b 32 19 fa b3 a3 0b c1 c4

B.2. Test Cases for AES_192_CBC_HMAC_SHA_384

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

  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

  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

  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

  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

  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

  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

  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

  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

  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

  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

B.3. Test Cases for AES_256_CBC_HMAC_SHA_512

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

  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

  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

  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

  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

  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

  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

  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

  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

  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

  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

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

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

RFC 7518

JSON Web Algorithms (JWA)

RFC 7518

JSON Web Algorithms (JWA)

Abstract

概要