[要約] RFC 7516は、JSON Web Encryption (JWE) に関する規格で、JSON形式のデータを暗号化するための構造と処理方法を定義しています。この規格の目的は、インターネット上で安全に情報を交換するために、データの機密性を保護することです。利用場面としては、Webアプリケーション間での機密情報の安全な送受信、トークンやメッセージの暗号化があります。関連するRFCには、RFC 7515 (JSON Web Signature (JWS))、RFC 7517 (JSON Web Key (JWK))、RFC 7518 (JSON Web Algorithms (JWA)) があり、これらはJWEと合わせて、Web上での安全なデータ交換を実現するための一連の規格を形成しています。
Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 7516 Microsoft
Category: Standards Track J. Hildebrand
ISSN: 2070-1721 Cisco
May 2015
JSON Web Encryption (JWE)
JSON Web暗号化（PLAY）
Abstract
概要
JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification.
JSON Web Encryption（JWE）は、JSONベースのデータ構造を使用して暗号化されたコンテンツを表します。この仕様で使用する暗号化アルゴリズムと識別子は、別のJSON Web Algorithms（JWA）仕様と、その仕様で定義されているIANAレジストリで説明されています。関連するデジタル署名とメッセージ認証コード（MAC）機能については、別のJSON Web Signature（JWS）仕様で説明されています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7516.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7516で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. JSON Web Encryption (JWE) Overview . . . . . . . . . . . . . 8
3.1. JWE Compact Serialization Overview . . . . . . . . . . . 8
3.2. JWE JSON Serialization Overview . . . . . . . . . . . . . 9
3.3. Example JWE . . . . . . . . . . . . . . . . . . . . . . . 10
4. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Registered Header Parameter Names . . . . . . . . . . . . 11
4.1.1. "alg" (Algorithm) Header Parameter . . . . . . . . . 12
4.1.2. "enc" (Encryption Algorithm) Header Parameter . . . . 12
4.1.3. "zip" (Compression Algorithm) Header Parameter . . . 12
4.1.4. "jku" (JWK Set URL) Header Parameter . . . . . . . . 13
4.1.5. "jwk" (JSON Web Key) Header Parameter . . . . . . . . 13
4.1.6. "kid" (Key ID) Header Parameter . . . . . . . . . . . 13
4.1.7. "x5u" (X.509 URL) Header Parameter . . . . . . . . . 13
4.1.8. "x5c" (X.509 Certificate Chain) Header Parameter . . 13
4.1.9. "x5t" (X.509 Certificate SHA-1 Thumbprint) Header
Parameter . . . . . . . . . . . . . . . . . . . . . . 14
4.1.10. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint)
Header Parameter . . . . . . . . . . . . . . . . . . 14
4.1.11. "typ" (Type) Header Parameter . . . . . . . . . . . . 14
4.1.12. "cty" (Content Type) Header Parameter . . . . . . . . 14
4.1.13. "crit" (Critical) Header Parameter . . . . . . . . . 14
4.2. Public Header Parameter Names . . . . . . . . . . . . . . 14
4.3. Private Header Parameter Names . . . . . . . . . . . . . 15
5. Producing and Consuming JWEs . . . . . . . . . . . . . . . . 15
5.1. Message Encryption . . . . . . . . . . . . . . . . . . . 15
5.2. Message Decryption . . . . . . . . . . . . . . . . . . . 17
5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 20
6. Key Identification . . . . . . . . . . . . . . . . . . . . . 20
7. Serializations . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. JWE Compact Serialization . . . . . . . . . . . . . . . . 20
7.2. JWE JSON Serialization . . . . . . . . . . . . . . . . . 20
7.2.1. General JWE JSON Serialization Syntax . . . . . . . . 21
7.2.2. Flattened JWE JSON Serialization Syntax . . . . . . . 23
8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 24
9. Distinguishing between JWS and JWE Objects . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10.1. JSON Web Signature and Encryption Header Parameters
Registration . . . . . . . . . . . . . . . . . . . . . . 25
10.1.1. Registry Contents . . . . . . . . . . . . . . . . . 25
11. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11.1. Key Entropy and Random Values . . . . . . . . . . . . . 27
11.2. Key Protection . . . . . . . . . . . . . . . . . . . . . 27
11.3. Using Matching Algorithm Strengths . . . . . . . . . . . 28
11.4. Adaptive Chosen-Ciphertext Attacks . . . . . . . . . . . 28
11.5. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. JWE Examples . . . . . . . . . . . . . . . . . . . . 32
A.1. Example JWE using RSAES-OAEP and AES GCM . . . . . . . . 32
A.1.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 32
A.1.2. Content Encryption Key (CEK) . . . . . . . . . . . . 32
A.1.3. Key Encryption . . . . . . . . . . . . . . . . . . . 33
A.1.4. Initialization Vector . . . . . . . . . . . . . . . . 34
A.1.5. Additional Authenticated Data . . . . . . . . . . . . 35
A.1.6. Content Encryption . . . . . . . . . . . . . . . . . 35
A.1.7. Complete Representation . . . . . . . . . . . . . . . 36
A.1.8. Validation . . . . . . . . . . . . . . . . . . . . . 36
A.2. Example JWE using RSAES-PKCS1-v1_5 and
AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . . 36
A.2.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 37
A.2.2. Content Encryption Key (CEK) . . . . . . . . . . . . 37
A.2.3. Key Encryption . . . . . . . . . . . . . . . . . . . 38
A.2.4. Initialization Vector . . . . . . . . . . . . . . . . 39
A.2.5. Additional Authenticated Data . . . . . . . . . . . . 40
A.2.6. Content Encryption . . . . . . . . . . . . . . . . . 40
A.2.7. Complete Representation . . . . . . . . . . . . . . . 40
A.2.8. Validation . . . . . . . . . . . . . . . . . . . . . 41
A.3. Example JWE Using AES Key Wrap and
AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . . 41
A.3.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 41
A.3.2. Content Encryption Key (CEK) . . . . . . . . . . . . 42
A.3.3. Key Encryption . . . . . . . . . . . . . . . . . . . 42
A.3.4. Initialization Vector . . . . . . . . . . . . . . . . 42
A.3.5. Additional Authenticated Data . . . . . . . . . . . . 43
A.3.6. Content Encryption . . . . . . . . . . . . . . . . . 43
A.3.7. Complete Representation . . . . . . . . . . . . . . . 43
A.3.8. Validation . . . . . . . . . . . . . . . . . . . . . 44
A.4. Example JWE Using General JWE JSON Serialization . . . . 44
A.4.1. JWE Per-Recipient Unprotected Headers . . . . . . . . 45
A.4.2. JWE Protected Header . . . . . . . . . . . . . . . . 45
A.4.3. JWE Shared Unprotected Header . . . . . . . . . . . . 45
A.4.4. Complete JOSE Header Values . . . . . . . . . . . . . 45
A.4.5. Additional Authenticated Data . . . . . . . . . . . . 46
A.4.6. Content Encryption . . . . . . . . . . . . . . . . . 46
A.4.7. Complete JWE JSON Serialization Representation . . . 47
A.5. Example JWE Using Flattened JWE JSON Serialization . . . 47
Appendix B. Example AES_128_CBC_HMAC_SHA_256 Computation . . . . 48
B.1. Extract MAC_KEY and ENC_KEY from Key . . . . . . . . . . 48
B.2. Encrypt Plaintext to Create Ciphertext . . . . . . . . . 49
B.3. 64-Bit Big-Endian Representation of AAD Length . . . . . 49
B.4. Initialization Vector Value . . . . . . . . . . . . . . . 49
B.5. Create Input to HMAC Computation . . . . . . . . . . . . 50
B.6. Compute HMAC Value . . . . . . . . . . . . . . . . . . . 50
B.7. Truncate HMAC Value to Create Authentication Tag . . . . 50
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures [RFC7159]. The JWE cryptographic mechanisms encrypt and provide integrity protection for an arbitrary sequence of octets.
JSON Web Encryption（JWE）は、JSONベースのデータ構造[RFC7159]を使用して暗号化されたコンテンツを表します。 JWE暗号化メカニズムは、オクテットの任意のシーケンスを暗号化し、整合性保護を提供します。
Two closely related serializations for JWEs are defined. The JWE Compact Serialization is a compact, URL-safe representation intended for space constrained environments such as HTTP Authorization headers and URI query parameters. The JWE JSON Serialization represents JWEs as JSON objects and enables the same content to be encrypted to multiple parties. Both share the same cryptographic underpinnings.
JWEの2つの密接に関連するシリアル化が定義されています。 JWE Compact Serializationは、HTTP AuthorizationヘッダーやURIクエリパラメーターなど、スペースに制約のある環境向けのコンパクトでURLセーフな表現です。 JWE JSONシリアライゼーションは、JWEをJSONオブジェクトとして表し、同じコンテンツを複数の関係者に暗号化できるようにします。どちらも同じ暗号基盤を共有しています。
Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) [JWA] specification and IANA registries defined by that specification. Related digital signature and MAC capabilities are described in the separate JSON Web Signature (JWS) [JWS] specification.
この仕様で使用する暗号化アルゴリズムと識別子は、別のJSON Web Algorithms（JWA）[JWA]仕様と、その仕様で定義されているIANAレジストリで説明されています。関連するデジタル署名とMAC機能は、別のJSON Web Signature（JWS）[JWS]仕様で説明されています。
Names defined by this specification are short because a core goal is for the resulting representations to be compact.
この仕様で定義されている名前は、最終的な表現をコンパクトにすることを主な目的としているため、短くなっています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. The interpretation should only be applied when the terms appear in all capital letters.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「は、「RFCで使用して要件レベルを示すためのキーワード」[RFC2119]で説明されているように解釈されます。解釈が適用されるのは、用語がすべて大文字である場合のみです。
BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per Section 2 of [JWS].
BASE64URL（OCTETS）は、[JWS]のセクション2に従って、OCTETSのbase64urlエンコーディングを示します。
UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation of STRING, where STRING is a sequence of zero or more Unicode [UNICODE] characters.
UTF8（STRING）は、STRINGのUTF-8 [RFC3629]表現のオクテットを示します。STRINGは、ゼロ個以上のUnicode [UNICODE]文字のシーケンスです。
ASCII(STRING) denotes the octets of the ASCII [RFC20] representation of STRING, where STRING is a sequence of zero or more ASCII characters.
ASCII（STRING）は、STRINGのASCII [RFC20]表現のオクテットを示します。STRINGは、0個以上のASCII文字のシーケンスです。
The concatenation of two values A and B is denoted as A || B.
2つの値AとBの連結は、A ||として示されます。 Ｂ．
The terms "JSON Web Signature (JWS)", "Base64url Encoding", "Collision-Resistant Name", "Header Parameter", "JOSE Header", and "StringOrURI" are defined by the JWS specification [JWS].
「JSON Web Signature（JWS）」、「Base64url Encoding」、「Collision-Resistant Name」、「Header Parameter」、「JOSE Header」、および「StringOrURI」という用語は、JWS仕様[JWS]によって定義されています。
The terms "Ciphertext", "Digital Signature", "Initialization Vector (IV)", "Message Authentication Code (MAC)", and "Plaintext" are defined by the "Internet Security Glossary, Version 2" [RFC4949].
「暗号文」、「デジタル署名」、「初期化ベクトル（IV）」、「メッセージ認証コード（MAC）」、および「プレーンテキスト」という用語は、「インターネットセキュリティ用語集、バージョン2」[RFC4949]で定義されています。
These terms are defined by this specification:
これらの用語は、この仕様で定義されています。
JSON Web Encryption (JWE) A data structure representing an encrypted and integrity-protected message.
JSON Web Encryption（JWE）暗号化され整合性が保護されたメッセージを表すデータ構造。
Authenticated Encryption with Associated Data (AEAD) An AEAD algorithm is one that encrypts the plaintext, allows Additional Authenticated Data to be specified, and provides an integrated content integrity check over the ciphertext and Additional Authenticated Data. AEAD algorithms accept two inputs, the plaintext and the Additional Authenticated Data value, and produce two outputs, the ciphertext and the Authentication Tag value. AES Galois/Counter Mode (GCM) is one such algorithm.
関連データを使用した認証暗号化（AEAD）AEADアルゴリズムは、プレーンテキストを暗号化し、追加の認証データを指定できるようにし、暗号文と追加の認証データに対して統合されたコンテンツ整合性チェックを提供します。 AEADアルゴリズムは、平文と追加認証データの2つの入力を受け入れ、暗号文と認証タグ値の2つの出力を生成します。 AESガロア/カウンターモード（GCM）は、そのようなアルゴリズムの1つです。
Additional Authenticated Data (AAD) An input to an AEAD operation that is integrity protected but not encrypted.
追加認証データ（AAD）整合性は保護されているが暗号化されていないAEAD操作への入力。
Authentication Tag An output of an AEAD operation that ensures the integrity of the ciphertext and the Additional Authenticated Data. Note that some algorithms may not use an Authentication Tag, in which case this value is the empty octet sequence.
認証タグ暗号文と追加認証データの整合性を保証するAEAD操作の出力。一部のアルゴリズムは認証タグを使用しない場合があることに注意してください。この場合、この値は空のオクテットシーケンスです。
Content Encryption Key (CEK) A symmetric key for the AEAD algorithm used to encrypt the plaintext to produce the ciphertext and the Authentication Tag.
Content Encryption Key（CEK）平文を暗号化して暗号文と認証タグを生成するために使用されるAEADアルゴリズムの対称鍵。
JWE Encrypted Key Encrypted Content Encryption Key value. Note that for some algorithms, the JWE Encrypted Key value is specified as being the empty octet sequence.
JWE暗号化キー暗号化コンテンツ暗号化キーの値。一部のアルゴリズムでは、JWE暗号化キーの値が空のオクテットシーケンスとして指定されていることに注意してください。
JWE Initialization Vector Initialization Vector value used when encrypting the plaintext. Note that some algorithms may not use an Initialization Vector, in which case this value is the empty octet sequence.
JWE初期化ベクトル平文を暗号化するときに使用される初期化ベクトル値。一部のアルゴリズムは初期化ベクトルを使用しない場合があることに注意してください。この場合、この値は空のオクテットシーケンスです。
JWE AAD Additional value to be integrity protected by the authenticated encryption operation. This can only be present when using the JWE JSON Serialization. (Note that this can also be achieved when using either the JWE Compact Serialization or the JWE JSON Serialization by including the AAD value as an integrity-protected Header Parameter value, but at the cost of the value being double base64url encoded.)
JWE AAD認証された暗号化操作によって保全性が保護される追加の値。これは、JWE JSONシリアル化を使用する場合にのみ存在できます。 （これは、AWE値を整合性保護されたヘッダーパラメーター値として含めることにより、JWEコンパクトシリアル化またはJWE JSONシリアル化を使用するときにも達成できますが、値は二重にbase64urlエンコードされます。）
JWE Ciphertext Ciphertext value resulting from authenticated encryption of the plaintext with Additional Authenticated Data.
JWE Ciphertext追加認証データを使用したプレーンテキストの認証済み暗号化から得られるCiphertext値。
JWE Authentication Tag Authentication Tag value resulting from authenticated encryption of the plaintext with Additional Authenticated Data.
JWE認証タグ認証タグ値は、追加の認証済みデータを含むプレーンテキストの認証済み暗号化から得られます。
JWE Protected Header JSON object that contains the Header Parameters that are integrity protected by the authenticated encryption operation. These parameters apply to all recipients of the JWE. For the JWE Compact Serialization, this comprises the entire JOSE Header. For the JWE JSON Serialization, this is one component of the JOSE Header.
JWE保護ヘッダー認証された暗号化操作によって保全性が保護されているヘッダーパラメーターを含むJSONオブジェクト。これらのパラメーターは、JWEのすべての受信者に適用されます。 JWE Compact Serializationの場合、これはJOSEヘッダー全体で構成されます。 JWE JSONシリアライゼーションの場合、これはJOSEヘッダーのコンポーネントの1つです。
JWE Shared Unprotected Header JSON object that contains the Header Parameters that apply to all recipients of the JWE that are not integrity protected. This can only be present when using the JWE JSON Serialization.
整合性が保護されていないJWEのすべての受信者に適用されるヘッダーパラメーターを含むJWE共有非保護ヘッダーJSONオブジェクト。これは、JWE JSONシリアル化を使用する場合にのみ存在できます。
JWE Per-Recipient Unprotected Header JSON object that contains Header Parameters that apply to a single recipient of the JWE. These Header Parameter values are not integrity protected. This can only be present when using the JWE JSON Serialization.
JWE受信者ごとの無保護ヘッダーJWEの単一の受信者に適用されるヘッダーパラメーターを含むJSONオブジェクト。これらのヘッダーパラメータ値は整合性が保護されていません。これは、JWE JSONシリアル化を使用する場合にのみ存在できます。
JWE Compact Serialization A representation of the JWE as a compact, URL-safe string.
JWEコンパクトシリアライゼーションコンパクトでURLセーフな文字列としてのJWEの表現。
JWE JSON Serialization A representation of the JWE as a JSON object. The JWE JSON Serialization enables the same content to be encrypted to multiple parties. This representation is neither optimized for compactness nor URL safe.
JWE JSONシリアライゼーションJSONオブジェクトとしてのJWEの表現。 JWE JSONシリアル化により、同じコンテンツを複数の関係者に暗号化できます。この表現は、コンパクトさもURLセーフも最適化されていません。
Key Management Mode A method of determining the Content Encryption Key value to use. Each algorithm used for determining the CEK value uses a specific Key Management Mode. Key Management Modes employed by this specification are Key Encryption, Key Wrapping, Direct Key Agreement, Key Agreement with Key Wrapping, and Direct Encryption.
キー管理モード使用するコンテンツ暗号化キーの値を決定する方法。 CEK値の決定に使用される各アルゴリズムは、特定の鍵管理モードを使用します。この仕様で採用されているキー管理モードは、キー暗号化、キーラッピング、直接キーアグリーメント、キーラッピングとのキーアグリーメント、および直接暗号化です。
Key Encryption A Key Management Mode in which the CEK value is encrypted to the intended recipient using an asymmetric encryption algorithm.
キー暗号化非対称暗号化アルゴリズムを使用して、CEK値が目的の受信者に対して暗号化されるキー管理モード。
Key Wrapping A Key Management Mode in which the CEK value is encrypted to the intended recipient using a symmetric key wrapping algorithm.
キーラッピングCEK値が対称キーラッピングアルゴリズムを使用して目的の受信者に対して暗号化されるキー管理モード。
Direct Key Agreement A Key Management Mode in which a key agreement algorithm is used to agree upon the CEK value.
直接鍵合意CEK値を合意するために鍵合意アルゴリズムが使用される鍵管理モード。
Key Agreement with Key Wrapping A Key Management Mode in which a key agreement algorithm is used to agree upon a symmetric key used to encrypt the CEK value to the intended recipient using a symmetric key wrapping algorithm.
鍵ラッピングとの鍵合意鍵管理モードでは、対称鍵ラッピングアルゴリズムを使用して、目的の受信者に対してCEK値を暗号化するために使用される対称鍵に合意します。
Direct Encryption A Key Management Mode in which the CEK value used is the secret symmetric key value shared between the parties.
直接暗号化使用されるCEK値が、当事者間で共有される秘密対称鍵値である鍵管理モード。
JWE represents encrypted content using JSON data structures and base64url encoding. These JSON data structures MAY contain whitespace and/or line breaks before or after any JSON values or structural characters, in accordance with Section 2 of RFC 7159 [RFC7159]. A JWE represents these logical values (each of which is defined in Section 2):
JWEは、JSONデータ構造とbase64urlエンコーディングを使用して暗号化されたコンテンツを表します。 RFC 7159 [RFC7159]のセクション2に従い、これらのJSONデータ構造には、JSON値または構造文字の前後に空白や改行が含まれる場合があります。 JWEはこれらの論理値を表します（それぞれはセクション2で定義されています）。
o JOSE Header o JWE Encrypted Key o JWE Initialization Vector o JWE AAD o JWE Ciphertext o JWE Authentication Tag
o JOSEヘッダーo JWE暗号化キーo JWE初期化ベクトルo JWE AAD o JWE暗号文o JWE認証タグ
For a JWE, the JOSE Header members are the union of the members of these values (each of which is defined in Section 2):
JWEの場合、JOSEヘッダーメンバーはこれらの値のメンバーの和集合です（それぞれはセクション2で定義されています）。
o JWE Protected Header o JWE Shared Unprotected Header o JWE Per-Recipient Unprotected Header
o JWE保護ヘッダーo JWE共有非保護ヘッダーo JWE受信者ごとの非保護ヘッダー
JWE utilizes authenticated encryption to ensure the confidentiality and integrity of the plaintext and the integrity of the JWE Protected Header and the JWE AAD.
JWEは、認証された暗号化を利用して、平文の機密性と整合性、およびJWE保護ヘッダーとJWE AADの整合性を保証します。
This document defines two serializations for JWEs: a compact, URL-safe serialization called the JWE Compact Serialization and a JSON serialization called the JWE JSON Serialization. In both serializations, the JWE Protected Header, JWE Encrypted Key, JWE Initialization Vector, JWE Ciphertext, and JWE Authentication Tag are base64url encoded, since JSON lacks a way to directly represent arbitrary octet sequences. When present, the JWE AAD is also base64url encoded.
このドキュメントでは、JWEの2つのシリアル化を定義します。JWEコンパクトシリアル化と呼ばれるコンパクトでURLセーフなシリアル化と、JWE JSONシリアル化と呼ばれるJSONシリアル化です。どちらのシリアル化でも、JSONには任意のオクテットシーケンスを直接表す方法がないため、JWE保護ヘッダー、JWE暗号化キー、JWE初期化ベクトル、JWE暗号化テキスト、およびJWE認証タグはbase64urlエンコードされます。存在する場合、JWE AADもbase64urlエンコードされます。
In the JWE Compact Serialization, no JWE Shared Unprotected Header or JWE Per-Recipient Unprotected Header are used. In this case, the JOSE Header and the JWE Protected Header are the same.
JWEコンパクトシリアライゼーションでは、JWE共有非保護ヘッダーまたはJWE受信者非保護ヘッダーは使用されません。この場合、JOSEヘッダーとJWE保護ヘッダーは同じです。
In the JWE Compact Serialization, a JWE is represented as the concatenation:
JWE Compact Serializationでは、JWEは連結として表されます。
BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag)
BASE64URL（UTF8（JWE保護ヘッダー））|| 「。」 || BASE64URL（PLAY暗号化キー）|| 「。」 || BASE64URL（PLAY初期化ベクトル）|| 「。」 || BASE64URL（PLAY Ciphertext）|| 「。」 || BASE64URL（PLAY認証タグ）
See Section 7.1 for more information about the JWE Compact Serialization.
JWE Compact Serializationの詳細については、セクション7.1を参照してください。
In the JWE JSON Serialization, one or more of the JWE Protected Header, JWE Shared Unprotected Header, and JWE Per-Recipient Unprotected Header MUST be present. In this case, the members of the JOSE Header are the union of the members of the JWE Protected Header, JWE Shared Unprotected Header, and JWE Per-Recipient Unprotected Header values that are present.
JWE JSONシリアル化では、1つ以上のJWE保護ヘッダー、JWE共有非保護ヘッダー、およびJWE受信者非保護ヘッダーが存在する必要があります。この場合、JOSEヘッダーのメンバーは、存在するJWE保護ヘッダー、JWE共有非保護ヘッダー、およびJWE受信者非保護ヘッダー値のメンバーの和集合です。
In the JWE JSON Serialization, a JWE is represented as a JSON object containing some or all of these eight members:
JWE JSONシリアライゼーションでは、JWEは次の8つのメンバーの一部またはすべてを含むJSONオブジェクトとして表されます。
"protected", with the value BASE64URL(UTF8(JWE Protected Header)) "unprotected", with the value JWE Shared Unprotected Header "header", with the value JWE Per-Recipient Unprotected Header "encrypted_key", with the value BASE64URL(JWE Encrypted Key) "iv", with the value BASE64URL(JWE Initialization Vector) "ciphertext", with the value BASE64URL(JWE Ciphertext) "tag", with the value BASE64URL(JWE Authentication Tag) "aad", with the value BASE64URL(JWE AAD)
値がBASE64URL（UTF8（JWE Protected Header））の "保護された"、値がJWE Shared Unprotected Header "header"、値がJWE Per-Recipient Unprotected Header "encrypted_key"、値がBASE64URL（JWE暗号化されたキー） "iv"、値BASE64URL（JWE Initialization Vector） "ciphertext"、値BASE64URL（JWE Ciphertext） "tag"、値BASE64URL（JWE Authentication Tag） "aad"、値BASE64URL（ JWE AAD）
The six base64url-encoded result strings and the two unprotected JSON object values are represented as members within a JSON object. The inclusion of some of these values is OPTIONAL. The JWE JSON Serialization can also encrypt the plaintext to multiple recipients. See Section 7.2 for more information about the JWE JSON Serialization.
6つのbase64urlエンコード結果文字列と2つの保護されていないJSONオブジェクト値は、JSONオブジェクト内のメンバーとして表されます。これらの値の一部を含めることはオプションです。 JWE JSONシリアライゼーションは、プレーンテキストを複数の受信者に暗号化することもできます。 JWE JSONシリアル化の詳細については、セクション7.2を参照してください。
This example encrypts the plaintext "The true sign of intelligence is not knowledge but imagination." to the recipient.
この例では、「知性の真の兆候は知識ではなく想像力である」という平文を暗号化しています。受信者に。
The following example JWE Protected Header declares that:
次の例のJWE保護ヘッダーは、それを宣言しています。
o The Content Encryption Key is encrypted to the recipient using the RSAES-OAEP [RFC3447] algorithm to produce the JWE Encrypted Key.
o コンテンツ暗号化キーは、RSAES-OAEP [RFC3447]アルゴリズムを使用して受信者に対して暗号化され、JWE暗号化キーが生成されます。
o Authenticated encryption is performed on the plaintext using the AES GCM [AES] [NIST.800-38D] algorithm with a 256-bit key to produce the ciphertext and the Authentication Tag.
o 認証された暗号化は、AES GCM [AES] [NIST.800-38D]アルゴリズムと256ビットキーを使用して平文に対して実行され、暗号文と認証タグが生成されます。
{"alg":"RSA-OAEP","enc":"A256GCM"}
Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected Header)) gives this value:
このJWE保護ヘッダーをBASE64URL（UTF8（JWE保護ヘッダー））としてエンコードすると、次の値が得られます。
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ
The remaining steps to finish creating this JWE are:
このJWEの作成を完了する残りの手順は次のとおりです。
o Generate a random Content Encryption Key (CEK).
o ランダムなコンテンツ暗号化キー（CEK）を生成します。
o Encrypt the CEK with the recipient's public key using the RSAES-OAEP algorithm to produce the JWE Encrypted Key.
o RSAES-OAEPアルゴリズムを使用して受信者の公開鍵でCEKを暗号化し、JWE暗号化鍵を生成します。
o Base64url-encode the JWE Encrypted Key.
o J64暗号化キーをBase64urlエンコードします。
o Generate a random JWE Initialization Vector.
o ランダムなJWE初期化ベクトルを生成します。
o Base64url-encode the JWE Initialization Vector.
o JWE初期化ベクトルをBase64urlエンコードします。
o Let the Additional Authenticated Data encryption parameter be ASCII(BASE64URL(UTF8(JWE Protected Header))).
o 追加認証データ暗号化パラメーターをASCII（BASE64URL（UTF8（JWE Protected Header）））にします。
o Perform authenticated encryption on the plaintext with the AES GCM algorithm using the CEK as the encryption key, the JWE Initialization Vector, and the Additional Authenticated Data value, requesting a 128-bit Authentication Tag output.
o 暗号化キーとしてCEKを使用するAES GCMアルゴリズム、JWE初期化ベクトル、および追加の認証済みデータ値を使用して、プレーンテキストで認証済み暗号化を実行し、128ビット認証タグ出力を要求します。
o Base64url-encode the ciphertext.
o 暗号文をBase64urlエンコードします。
o Base64url-encode the Authentication Tag.
o 認証タグをBase64urlエンコードします。
o Assemble the final representation: The Compact Serialization of this result is the string BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag).
o 最終的な表現を組み立てます。この結果のコンパクトなシリアル化は、文字列BASE64URL（UTF8（JWE Protected Header））です|| 「。」 || BASE64URL（JWE暗号化キー）|| 「。」 || BASE64URL（JWE初期化ベクトル）|| 「。」 || BASE64URL（JWE暗号文）|| 「。」 || BASE64URL（JWE認証タグ）。
The final result in this example (with line breaks for display purposes only) is:
この例の最終的な結果（表示目的のみの改行あり）は次のとおりです。
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ. OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8 1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi 6UklfCpIMfIjf7iGdXKHzg. 48V1_ALb6US04U3b. 5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji SdiwkIr3ajwQzaBtQD_A. XFBoMYUZodetZdvTiFvSkQ
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ。 OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8 1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi 6UklfCpIMfIjf7iGdXKHzg。 48V1_ALb6US04U3b。 5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji SdiwkIr3ajwQzaBtQD_A。 XFBoMYUZodetZdvTiFvSkQ
See Appendix A.1 for the complete details of computing this JWE. See Appendix A for additional examples, including examples using the JWE JSON Serialization in Sections A.4 and A.5.
このJWEの計算の詳細については、付録A.1を参照してください。セクションA.4およびA.5のJWE JSONシリアル化を使用した例を含む追加の例については、付録Aを参照してください。
For a JWE, the members of the JSON object(s) representing the JOSE Header describe the encryption applied to the plaintext and optionally additional properties of the JWE. The Header Parameter names within the JOSE Header MUST be unique, just as described in Section 4 of [JWS]. The rules about handling Header Parameters that are not understood by the implementation are also the same. The classes of Header Parameter names are likewise the same.
JWEの場合、JOSEヘッダーを表すJSONオブジェクトのメンバーは、プレーンテキストに適用される暗号化と、オプションでJWEの追加プロパティを記述します。 [JWS]のセクション4で説明されているように、JOSEヘッダー内のヘッダーパラメータ名は一意である必要があります。実装で理解されないヘッダーパラメータの処理に関するルールも同じです。ヘッダーパラメータ名のクラスも同様です。
The following Header Parameter names for use in JWEs are registered in the IANA "JSON Web Signature and Encryption Header Parameters" registry established by [JWS], with meanings as defined below.
JWEで使用される次のヘッダーパラメータ名は、[JWS]によって確立されたIANA "JSON Web Signature and Encryption Header Parameters"レジストリに登録されており、その意味は以下に定義されています。
As indicated by the common registry, JWSs and JWEs share a common Header Parameter space; when a parameter is used by both specifications, its usage must be compatible between the specifications.
共通レジストリに示されているように、JWSとJWEは共通のヘッダーパラメータスペースを共有しています。パラメータが両方の仕様で使用される場合、その使用法は仕様間で互換性がなければなりません。
This parameter has the same meaning, syntax, and processing rules as the "alg" Header Parameter defined in Section 4.1.1 of [JWS], except that the Header Parameter identifies the cryptographic algorithm used to encrypt or determine the value of the CEK. The encrypted content is not usable if the "alg" value does not represent a supported algorithm, or if the recipient does not have a key that can be used with that algorithm.
このパラメーターは、[JWS]のセクション4.1.1で定義されている「alg」ヘッダーパラメーターと同じ意味、構文、および処理ルールを持っていますが、ヘッダーパラメーターはCEKの値の暗号化または決定に使用される暗号化アルゴリズムを識別します。 「alg」値がサポートされているアルゴリズムを表していない場合、または受信者がそのアルゴリズムで使用できるキーを持っていない場合、暗号化されたコンテンツは使用できません。
A list of defined "alg" values for this use can be found in the IANA "JSON Web Signature and Encryption Algorithms" registry established by [JWA]; the initial contents of this registry are the values defined in Section 4.1 of [JWA].
この用途に定義された「alg」値のリストは、[JWA]によって確立されたIANAの「JSON Web署名および暗号化アルゴリズム」レジストリにあります。このレジストリの初期内容は、[JWA]のセクション4.1で定義されている値です。
The "enc" (encryption algorithm) Header Parameter identifies the content encryption algorithm used to perform authenticated encryption on the plaintext to produce the ciphertext and the Authentication Tag. This algorithm MUST be an AEAD algorithm with a specified key length. The encrypted content is not usable if the "enc" value does not represent a supported algorithm. "enc" values should either be registered in the IANA "JSON Web Signature and Encryption Algorithms" registry established by [JWA] or be a value that contains a Collision-Resistant Name. The "enc" value is a case-sensitive ASCII string containing a StringOrURI value. This Header Parameter MUST be present and MUST be understood and processed by implementations.
"enc"（暗号化アルゴリズム）ヘッダーパラメーターは、平文で認証された暗号化を実行して暗号文と認証タグを生成するために使用されるコンテンツ暗号化アルゴリズムを識別します。このアルゴリズムは、指定された鍵長のAEADアルゴリズムである必要があります。 「enc」値がサポートされているアルゴリズムを表していない場合、暗号化されたコンテンツは使用できません。 "enc"値は、[JWA]によって確立されたIANA "JSON Web Signature and Encryption Algorithms"レジストリに登録するか、衝突防止名を含む値にする必要があります。 「enc」値は、StringOrURI値を含む、大文字と小文字が区別されるASCII文字列です。このヘッダーパラメータは存在しなければならず、実装によって理解および処理される必要があります。
A list of defined "enc" values for this use can be found in the IANA "JSON Web Signature and Encryption Algorithms" registry established by [JWA]; the initial contents of this registry are the values defined in Section 5.1 of [JWA].
この用途に定義された「enc」値のリストは、[JWA]によって確立されたIANAの「JSON Web署名および暗号化アルゴリズム」レジストリにあります。このレジストリの初期コンテンツは、[JWA]のセクション5.1で定義されている値です。
The "zip" (compression algorithm) applied to the plaintext before encryption, if any. The "zip" value defined by this specification is:
暗号化する前にプレーンテキストに適用される「zip」（圧縮アルゴリズム）。この仕様で定義されている「zip」値は次のとおりです。
o "DEF" - Compression with the DEFLATE [RFC1951] algorithm
o "DEF"-DEFLATE [RFC1951]アルゴリズムによる圧縮
Other values MAY be used. Compression algorithm values can be registered in the IANA "JSON Web Encryption Compression Algorithms" registry established by [JWA]. The "zip" value is a case-sensitive string. If no "zip" parameter is present, no compression is applied to the plaintext before encryption. When used, this Header Parameter MUST be integrity protected; therefore, it MUST occur only within the JWE Protected Header. Use of this Header Parameter is OPTIONAL. This Header Parameter MUST be understood and processed by implementations.
他の値が使用される場合があります。圧縮アルゴリズムの値は、[JWA]によって確立されたIANA "JSON Web Encryption Compression Algorithms"レジストリに登録できます。 「zip」値は、大文字と小文字が区別される文字列です。 「zip」パラメータが存在しない場合、暗号化の前にプレーンテキストに圧縮は適用されません。使用する場合、このヘッダーパラメーターは整合性を保護する必要があります。したがって、JWE保護ヘッダー内でのみ発生する必要があります。このヘッダーパラメータの使用はオプションです。このヘッダーパラメータは、実装によって理解および処理される必要があります。
This parameter has the same meaning, syntax, and processing rules as the "jku" Header Parameter defined in Section 4.1.2 of [JWS], except that the JWK Set resource contains the public key to which the JWE was encrypted; this can be used to determine the private key needed to decrypt the JWE.
このパラメーターは、[JWS]のセクション4.1.2で定義されている「jku」ヘッダーパラメーターと同じ意味、構文、および処理規則を持っていますが、JWK SetリソースにJWEが暗号化された公開鍵が含まれている点が異なります。これは、JWEを復号化するために必要な秘密鍵を判別するために使用できます。
This parameter has the same meaning, syntax, and processing rules as the "jwk" Header Parameter defined in Section 4.1.3 of [JWS], except that the key is the public key to which the JWE was encrypted; this can be used to determine the private key needed to decrypt the JWE.
このパラメーターは、[JWS]のセクション4.1.3で定義されている「jwk」ヘッダーパラメーターと同じ意味、構文、および処理規則を持っていますが、キーはJWEが暗号化された公開キーです。これは、JWEを復号化するために必要な秘密鍵を判別するために使用できます。
This parameter has the same meaning, syntax, and processing rules as the "kid" Header Parameter defined in Section 4.1.4 of [JWS], except that the key hint references the public key to which the JWE was encrypted; this can be used to determine the private key needed to decrypt the JWE. This parameter allows originators to explicitly signal a change of key to JWE recipients.
このパラメーターは、[JWS]のセクション4.1.4で定義されている「kid」ヘッダーパラメーターと同じ意味、構文、および処理ルールを持っていますが、キーヒントがJWEが暗号化された公開キーを参照する点が異なります。これは、JWEを復号化するために必要な秘密鍵を判別するために使用できます。このパラメーターにより、発信者はキーの変更をJWE受信者に明示的に通知できます。
This parameter has the same meaning, syntax, and processing rules as the "x5u" Header Parameter defined in Section 4.1.5 of [JWS], except that the X.509 public key certificate or certificate chain [RFC5280] contains the public key to which the JWE was encrypted; this can be used to determine the private key needed to decrypt the JWE.
このパラメーターは、[JWS]のセクション4.1.5で定義されている「x5u」ヘッダーパラメーターと同じ意味、構文、および処理ルールを持っていますが、X.509公開鍵証明書または証明書チェーン[RFC5280]には、 JWEは暗号化されました。これは、JWEを復号化するために必要な秘密鍵を判別するために使用できます。
This parameter has the same meaning, syntax, and processing rules as the "x5c" Header Parameter defined in Section 4.1.6 of [JWS], except that the X.509 public key certificate or certificate chain [RFC5280] contains the public key to which the JWE was encrypted; this can be used to determine the private key needed to decrypt the JWE.
このパラメーターは、[JWS]のセクション4.1.6で定義されている「x5c」ヘッダーパラメーターと同じ意味、構文、および処理ルールを持っていますが、X.509公開鍵証明書または証明書チェーン[RFC5280]には、 JWEは暗号化されました。これは、JWEを復号化するために必要な秘密鍵を判別するために使用できます。
See Appendix B of [JWS] for an example "x5c" value.
「x5c」値の例については、[JWS]の付録Bを参照してください。
This parameter has the same meaning, syntax, and processing rules as the "x5t" Header Parameter defined in Section 4.1.7 of [JWS], except that the certificate referenced by the thumbprint contains the public key to which the JWE was encrypted; this can be used to determine the private key needed to decrypt the JWE. Note that certificate thumbprints are also sometimes known as certificate fingerprints.
このパラメーターは、[JWS]のセクション4.1.7で定義されている「x5t」ヘッダーパラメーターと同じ意味、構文、および処理規則を持っていますが、サムプリントによって参照される証明書に、JWEが暗号化された公開鍵が含まれている点が異なります。これは、JWEを復号化するために必要な秘密鍵を判別するために使用できます。証明書の拇印は、証明書の指紋とも呼ばれます。
4.1.10. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) Header Parameter
4.1.10. "x5t＃S256"（X.509 Certificate SHA-256 Thumbprint）ヘッダーパラメーター
This parameter has the same meaning, syntax, and processing rules as the "x5t#S256" Header Parameter defined in Section 4.1.8 of [JWS], except that the certificate referenced by the thumbprint contains the public key to which the JWE was encrypted; this can be used to determine the private key needed to decrypt the JWE. Note that certificate thumbprints are also sometimes known as certificate fingerprints.
このパラメーターは、[JWS]のセクション4.1.8で定義されている「x5t＃S256」ヘッダーパラメーターと同じ意味、構文、および処理規則を持っていますが、サムプリントによって参照される証明書に、JWEが暗号化された公開鍵が含まれている点が異なります。 ;これは、JWEを復号化するために必要な秘密鍵を判別するために使用できます。証明書の拇印は、証明書の指紋とも呼ばれます。
This parameter has the same meaning, syntax, and processing rules as the "typ" Header Parameter defined in Section 4.1.9 of [JWS], except that the type is that of this complete JWE.
このパラメーターは、[JWS]のセクション4.1.9で定義されている「typ」ヘッダーパラメーターと同じ意味、構文、および処理ルールを持っていますが、タイプはこの完全なJWEのものです。
This parameter has the same meaning, syntax, and processing rules as the "cty" Header Parameter defined in Section 4.1.10 of [JWS], except that the type is that of the secured content (the plaintext).
このパラメーターは、[JWS]のセクション4.1.10で定義されている「cty」ヘッダーパラメーターと同じ意味、構文、および処理ルールを持っていますが、タイプは保護されたコンテンツ（プレーンテキスト）のタイプです。
This parameter has the same meaning, syntax, and processing rules as the "crit" Header Parameter defined in Section 4.1.11 of [JWS], except that Header Parameters for a JWE are being referred to, rather than Header Parameters for a JWS.
このパラメーターは、JWSのヘッダーパラメーターではなくJWEのヘッダーパラメーターが参照されることを除いて、[JWS]のセクション4.1.11で定義された「crit」ヘッダーパラメーターと同じ意味、構文、および処理規則を持っています。
Additional Header Parameter names can be defined by those using JWEs. However, in order to prevent collisions, any new Header Parameter name should either be registered in the IANA "JSON Web Signature and Encryption Header Parameters" registry established by [JWS] or be a Public Name: a value that contains a Collision-Resistant Name. In each case, the definer of the name or value needs to take reasonable precautions to make sure they are in control of the part of the namespace they use to define the Header Parameter name.
JWEを使用するユーザーは、追加のヘッダーパラメーター名を定義できます。ただし、衝突を防ぐために、新しいヘッダーパラメータ名は、[JWS]によって確立されたIANA "JSON Web Signature and Encryption Header Parameters"レジストリに登録するか、パブリック名（衝突耐性名を含む値）にする必要があります。 。いずれの場合も、名前または値の定義者は、適切な予防策を講じて、ヘッダーパラメーター名の定義に使用する名前空間の一部を確実に制御できるようにする必要があります。
New Header Parameters should be introduced sparingly, as they can result in non-interoperable JWEs.
新しいヘッダーパラメータは、相互運用できないJWEになる可能性があるため、慎重に導入する必要があります。
A producer and consumer of a JWE may agree to use Header Parameter names that are Private Names: names that are not Registered Header Parameter names (Section 4.1) or Public Header Parameter names (Section 4.2). Unlike Public Header Parameter names, Private Header Parameter names are subject to collision and should be used with caution.
JWEのプロデューサーとコンシューマーは、プライベート名であるヘッダーパラメーター名を使用することに同意する場合があります。登録済みヘッダーパラメーター名（セクション4.1）またはパブリックヘッダーパラメーター名（セクション4.2）ではない名前です。パブリックヘッダーパラメーター名とは異なり、プライベートヘッダーパラメーター名は競合する可能性があるため、注意して使用する必要があります。
The message encryption process is as follows. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps.
メッセージの暗号化プロセスは次のとおりです。ステップの入力と出力の間に依存関係がない場合、ステップの順序は重要ではありません。
1. Determine the Key Management Mode employed by the algorithm used to determine the Content Encryption Key value. (This is the algorithm recorded in the "alg" (algorithm) Header Parameter of the resulting JWE.)
1. コンテンツ暗号化キーの値を決定するために使用されるアルゴリズムで使用されるキー管理モードを決定します。 （これは、結果のJWEの「alg」（アルゴリズム）ヘッダーパラメーターに記録されたアルゴリズムです。）
2. When Key Wrapping, Key Encryption, or Key Agreement with Key Wrapping are employed, generate a random CEK value. See RFC 4086 [RFC4086] for considerations on generating random values. The CEK MUST have a length equal to that required for the content encryption algorithm.
2. 鍵ラッピング、鍵暗号化、または鍵ラッピングとの鍵合意が採用されている場合、ランダムなCEK値を生成します。ランダム値の生成に関する考慮事項については、RFC 4086 [RFC4086]を参照してください。 CEKは、コンテンツ暗号化アルゴリズムに必要な長さに等しい長さを持つ必要があります。
3. When Direct Key Agreement or Key Agreement with Key Wrapping are employed, use the key agreement algorithm to compute the value of the agreed upon key. When Direct Key Agreement is employed, let the CEK be the agreed upon key. When Key Agreement with Key Wrapping is employed, the agreed upon key will be used to wrap the CEK.
3. ダイレクトキーアグリーメントまたはキーラッピングとのキーアグリーメントを使用する場合は、キーアグリーメントアルゴリズムを使用して、合意したキーの値を計算します。ダイレクトキーアグリーメントを使用する場合は、CEKを合意済みのキーにします。鍵ラッピングとの鍵合意が採用されている場合、合意された鍵がCEKのラップに使用されます。
4. When Key Wrapping, Key Encryption, or Key Agreement with Key Wrapping are employed, encrypt the CEK to the recipient and let the result be the JWE Encrypted Key.
4. キーラッピング、キー暗号化、またはキーラッピングとのキーアグリーメントを使用する場合は、受信者に対してCEKを暗号化し、結果をJWE暗号化キーにします。
5. When Direct Key Agreement or Direct Encryption are employed, let the JWE Encrypted Key be the empty octet sequence.
5. ダイレクトキーアグリーメントまたはダイレクト暗号化を使用する場合、JWE暗号化キーを空のオクテットシーケンスにします。
6. When Direct Encryption is employed, let the CEK be the shared symmetric key.
6. 直接暗号化を使用する場合は、CEKを共有対称キーにします。
7. Compute the encoded key value BASE64URL(JWE Encrypted Key).
7. エンコードされたキー値BASE64URL（JWE Encrypted Key）を計算します。
8. If the JWE JSON Serialization is being used, repeat this process (steps 1-7) for each recipient.
8. JWE JSONシリアル化が使用されている場合は、受信者ごとにこのプロセス（手順1〜7）を繰り返します。
9. Generate a random JWE Initialization Vector of the correct size for the content encryption algorithm (if required for the algorithm); otherwise, let the JWE Initialization Vector be the empty octet sequence.
9. コンテンツ暗号化アルゴリズムの正しいサイズのランダムなJWE初期化ベクトルを生成します（アルゴリズムに必要な場合）。それ以外の場合は、JWE初期化ベクトルを空のオクテットシーケンスにします。
10. Compute the encoded Initialization Vector value BASE64URL(JWE Initialization Vector).
10. エンコードされた初期化ベクトル値BASE64URL（JWE初期化ベクトル）を計算します。
11. If a "zip" parameter was included, compress the plaintext using the specified compression algorithm and let M be the octet sequence representing the compressed plaintext; otherwise, let M be the octet sequence representing the plaintext.
11. 「zip」パラメータが含まれている場合、指定された圧縮アルゴリズムを使用してプレーンテキストを圧縮し、Mを圧縮されたプレーンテキストを表すオクテットシーケンスにします。それ以外の場合は、Mを平文を表すオクテットシーケンスとします。
12. Create the JSON object(s) containing the desired set of Header Parameters, which together comprise the JOSE Header: one or more of the JWE Protected Header, the JWE Shared Unprotected Header, and the JWE Per-Recipient Unprotected Header.
12. JOSEヘッダー（JWE保護ヘッダー、JWE共有非保護ヘッダー、およびJWE受信者非保護ヘッダーの1つ以上）で構成されるヘッダーパラメーターの必要なセットを含むJSONオブジェクトを作成します。
13. Compute the Encoded Protected Header value BASE64URL(UTF8(JWE Protected Header)). If the JWE Protected Header is not present (which can only happen when using the JWE JSON Serialization and no "protected" member is present), let this value be the empty string.
13. エンコードされた保護ヘッダー値BASE64URL（UTF8（JWE Protected Header））を計算します。 JWE保護ヘッダーが存在しない場合（これは、JWE JSONシリアル化を使用し、「保護された」メンバーが存在しない場合にのみ発生する可能性があります）、この値を空の文字列にします。
14. Let the Additional Authenticated Data encryption parameter be ASCII(Encoded Protected Header). However, if a JWE AAD value is present (which can only be the case when using the JWE JSON Serialization), instead let the Additional Authenticated Data encryption parameter be ASCII(Encoded Protected Header || '.' || BASE64URL(JWE AAD)).
14. 追加認証データ暗号化パラメーターをASCII（エンコードされた保護ヘッダー）にします。ただし、JWE AAD値が存在する場合（JWE JSONシリアル化を使用する場合にのみ該当）、代わりに追加認証データ暗号化パラメーターをASCII（エンコードされた保護ヘッダー|| '。' || BASE64URL（JWE AAD）にします。 ）。
15. Encrypt M using the CEK, the JWE Initialization Vector, and the Additional Authenticated Data value using the specified content encryption algorithm to create the JWE Ciphertext value and the JWE Authentication Tag (which is the Authentication Tag output from the encryption operation).
15. 指定されたコンテンツ暗号化アルゴリズムを使用して、CEK、JWE初期化ベクトル、および追加認証データ値を使用してMを暗号化し、JWE暗号文値およびJWE認証タグ（暗号化操作からの認証タグ出力）を作成します。
16. Compute the encoded ciphertext value BASE64URL(JWE Ciphertext).
16. エンコードされた暗号テキスト値BASE64URL（JWE Ciphertext）を計算します。
17. Compute the encoded Authentication Tag value BASE64URL(JWE Authentication Tag).
17. エンコードされた認証タグ値BASE64URL（JWE認証タグ）を計算します。
18. If a JWE AAD value is present, compute the encoded AAD value BASE64URL(JWE AAD).
18. JWE AAD値が存在する場合は、エンコードされたAAD値BASE64URL（JWE AAD）を計算します。
19. Create the desired serialized output. The Compact Serialization of this result is the string BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag). The JWE JSON Serialization is described in Section 7.2.
19. 目的のシリアル化された出力を作成します。この結果のコンパクトシリアル化は、文字列BASE64URL（UTF8（JWE Protected Header））です|| 「。」 || BASE64URL（JWE暗号化キー）|| 「。」 || BASE64URL（JWE初期化ベクトル）|| 「。」 || BASE64URL（JWE暗号文）|| 「。」 || BASE64URL（JWE認証タグ）。 JWE JSONシリアライゼーションについては、セクション7.2で説明しています。
The message decryption process is the reverse of the encryption process. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps. If any of these steps fail, the encrypted content cannot be validated.
メッセージの復号化プロセスは、暗号化プロセスの逆です。ステップの入力と出力の間に依存関係がない場合、ステップの順序は重要ではありません。これらの手順のいずれかが失敗すると、暗号化されたコンテンツを検証できません。
When there are multiple recipients, it is an application decision which of the recipients' encrypted content must successfully validate for the JWE to be accepted. In some cases, encrypted content for all recipients must successfully validate or the JWE will be considered invalid. In other cases, only the encrypted content for a single recipient needs to be successfully validated. However, in all cases, the encrypted content for at least one recipient MUST successfully validate or the JWE MUST be considered invalid.
複数の受信者がいる場合、JWEが受け入れられるためには、どの受信者の暗号化されたコンテンツが正常に検証される必要があるかは、アプリケーションの決定です。場合によっては、すべての受信者の暗号化されたコンテンツが正常に検証されなければ、JWEは無効と見なされます。他の場合では、単一の受信者の暗号化されたコンテンツのみが正常に検証される必要があります。ただし、すべての場合において、少なくとも1人の受信者の暗号化されたコンテンツは正常に検証する必要があります。そうしないと、JWEは無効と見なされます。
1. Parse the JWE representation to extract the serialized values for the components of the JWE. When using the JWE Compact Serialization, these components are the base64url-encoded representations of the JWE Protected Header, the JWE Encrypted Key, the JWE Initialization Vector, the JWE Ciphertext, and the JWE Authentication Tag, and when using the JWE JSON Serialization, these components also include the base64url-encoded representation of the JWE AAD and the unencoded JWE Shared Unprotected Header and JWE Per-Recipient Unprotected Header values. When using the JWE Compact Serialization, the JWE Protected Header, the JWE Encrypted Key, the JWE Initialization Vector, the JWE Ciphertext, and the JWE Authentication Tag are represented as base64url-encoded values in that order, with each value being separated from the next by a single period ('.') character, resulting in exactly four delimiting period characters being used. The JWE JSON Serialization is described in Section 7.2.
1. JWE表現を解析して、JWEのコンポーネントのシリアル化された値を抽出します。 JWEコンパクトシリアル化を使用する場合、これらのコンポーネントは、JWE保護ヘッダー、JWE暗号化キー、JWE初期化ベクトル、JWE暗号化テキスト、およびJWE認証タグのbase64urlエンコード表現であり、JWE JSONシリアル化を使用する場合、これらはコンポーネントには、JWE AADのbase64urlエンコード表現と、エンコードされていないJWE共有非保護ヘッダーおよびJWE受信者非保護ヘッダー値も含まれます。 JWEコンパクトシリアライゼーションを使用する場合、JWE保護ヘッダー、JWE暗号化キー、JWE初期化ベクトル、JWE暗号化テキスト、およびJWE認証タグは、順番にbase64urlエンコード値として表され、各値は次の値から分離されます単一のピリオド（ '。'）文字によって、正確に4つの区切りピリオド文字が使用されます。 JWE JSONシリアライゼーションについては、セクション7.2で説明しています。
2. Base64url decode the encoded representations of the JWE Protected Header, the JWE Encrypted Key, the JWE Initialization Vector, the JWE Ciphertext, the JWE Authentication Tag, and the JWE AAD, following the restriction that no line breaks, whitespace, or other additional characters have been used.
2. Base64urlは、JWE保護ヘッダー、JWE暗号化キー、JWE初期化ベクトル、JWE暗号化テキスト、JWE認証タグ、およびJWE AADのエンコードされた表現をデコードします。使用されました。
3. Verify that the octet sequence resulting from decoding the encoded JWE Protected Header is a UTF-8-encoded representation of a completely valid JSON object conforming to RFC 7159 [RFC7159]; let the JWE Protected Header be this JSON object.
3. エンコードされたJWE保護ヘッダーのデコードから生じるオクテットシーケンスが、RFC 7159 [RFC7159]に準拠した完全に有効なJSONオブジェクトのUTF-8エンコード表現であることを確認します。 JWE保護ヘッダーをこのJSONオブジェクトにします。
4. If using the JWE Compact Serialization, let the JOSE Header be the JWE Protected Header. Otherwise, when using the JWE JSON Serialization, let the JOSE Header be the union of the members of the JWE Protected Header, the JWE Shared Unprotected Header and the corresponding JWE Per-Recipient Unprotected Header, all of which must be completely valid JSON objects. During this step, verify that the resulting JOSE Header does not contain duplicate Header Parameter names. When using the JWE JSON Serialization, this restriction includes that the same Header Parameter name also MUST NOT occur in distinct JSON object values that together comprise the JOSE Header.
4. JWE Compact Serializationを使用している場合は、JOSEヘッダーをJWE保護ヘッダーにします。それ以外の場合、JWE JSONシリアル化を使用するときは、JOSEヘッダーをJWE保護ヘッダー、JWE共有非保護ヘッダー、および対応するJWE受信者非保護ヘッダーのメンバーの和集合にします。これらはすべて完全に有効なJSONオブジェクトでなければなりません。この手順では、結果のJOSEヘッダーに重複するヘッダーパラメーター名が含まれていないことを確認します。 JWE JSONシリアライゼーションを使用する場合、この制限には、JOSEヘッダーを構成する個別のJSONオブジェクト値で同じヘッダーパラメーター名が発生してはならないことも含まれます。
5. Verify that the implementation understands and can process all fields that it is required to support, whether required by this specification, by the algorithms being used, or by the "crit" Header Parameter value, and that the values of those parameters are also understood and supported.
5. この仕様、使用されているアルゴリズム、または「crit」ヘッダーパラメーター値によって必要とされるかどうかにかかわらず、実装がサポートする必要があるすべてのフィールドを理解して処理できること、およびそれらのパラメーターの値も理解されていることを確認します。サポートされています。
6. Determine the Key Management Mode employed by the algorithm specified by the "alg" (algorithm) Header Parameter.
6. 「alg」（アルゴリズム）ヘッダーパラメータで指定されたアルゴリズムで使用されるキー管理モードを決定します。
7. Verify that the JWE uses a key known to the recipient.
7. JWEが受信者に既知のキーを使用していることを確認します。
8. When Direct Key Agreement or Key Agreement with Key Wrapping are employed, use the key agreement algorithm to compute the value of the agreed upon key. When Direct Key Agreement is employed, let the CEK be the agreed upon key. When Key Agreement with Key Wrapping is employed, the agreed upon key will be used to decrypt the JWE Encrypted Key.
8. ダイレクトキーアグリーメントまたはキーラッピングとのキーアグリーメントを使用する場合は、キーアグリーメントアルゴリズムを使用して、合意したキーの値を計算します。ダイレクトキーアグリーメントを使用する場合は、CEKを合意済みのキーにします。鍵ラッピングとの鍵合意が採用されると、合意された鍵がJWE暗号化鍵の暗号化解除に使用されます。
9. When Key Wrapping, Key Encryption, or Key Agreement with Key Wrapping are employed, decrypt the JWE Encrypted Key to produce the CEK. The CEK MUST have a length equal to that required for the content encryption algorithm. Note that when there are multiple recipients, each recipient will only be able to decrypt JWE Encrypted Key values that were encrypted to a key in that recipient's possession. It is therefore normal to only be able to decrypt one of the per-recipient JWE Encrypted Key values to obtain the CEK value. Also, see Section 11.5 for security considerations on mitigating timing attacks.
9.鍵ラッピング、鍵暗号化、または鍵ラッピングとの鍵合意が採用されている場合、CWEを生成するためにJWE暗号化鍵を復号化します。 CEKは、コンテンツ暗号化アルゴリズムに必要な長さに等しい長さを持つ必要があります。複数の受信者がいる場合、各受信者は、その受信者が所有するキーに暗号化されたJWE暗号化キー値のみを復号化できることに注意してください。したがって、CEK値を取得するには、受信者ごとのJWE暗号化キー値の1つだけを復号化できるのが普通です。また、タイミング攻撃の軽減に関するセキュリティの考慮事項については、セクション11.5を参照してください。
10. When Direct Key Agreement or Direct Encryption are employed, verify that the JWE Encrypted Key value is an empty octet sequence.
10. ダイレクトキーアグリーメントまたはダイレクト暗号化が採用されている場合、JWE暗号化キーの値が空のオクテットシーケンスであることを確認します。
11. When Direct Encryption is employed, let the CEK be the shared symmetric key.
11. 直接暗号化を使用する場合は、CEKを共有対称キーにします。
12. Record whether the CEK could be successfully determined for this recipient or not.
12. この受信者についてCEKを正常に決定できたかどうかを記録します。
13. If the JWE JSON Serialization is being used, repeat this process (steps 4-12) for each recipient contained in the representation.
13. JWE JSONシリアル化が使用されている場合は、表現に含まれる各受信者に対してこのプロセス（手順4〜12）を繰り返します。
14. Compute the Encoded Protected Header value BASE64URL(UTF8(JWE Protected Header)). If the JWE Protected Header is not present (which can only happen when using the JWE JSON Serialization and no "protected" member is present), let this value be the empty string.
14. エンコードされた保護ヘッダー値BASE64URL（UTF8（JWE Protected Header））を計算します。 JWE保護ヘッダーが存在しない場合（これは、JWE JSONシリアル化を使用し、「保護された」メンバーが存在しない場合にのみ発生する可能性があります）、この値を空の文字列にします。
15. Let the Additional Authenticated Data encryption parameter be ASCII(Encoded Protected Header). However, if a JWE AAD value is present (which can only be the case when using the JWE JSON Serialization), instead let the Additional Authenticated Data encryption parameter be ASCII(Encoded Protected Header || '.' || BASE64URL(JWE AAD)).
15. 追加認証データ暗号化パラメーターをASCII（エンコードされた保護ヘッダー）にします。ただし、JWE AAD値が存在する場合（JWE JSONシリアル化を使用する場合にのみ該当）、代わりに追加認証データ暗号化パラメーターをASCII（エンコードされた保護ヘッダー|| '。' || BASE64URL（JWE AAD）にします。 ）。
16. Decrypt the JWE Ciphertext using the CEK, the JWE Initialization Vector, the Additional Authenticated Data value, and the JWE Authentication Tag (which is the Authentication Tag input to the calculation) using the specified content encryption algorithm, returning the decrypted plaintext and validating the JWE Authentication Tag in the manner specified for the algorithm, rejecting the input without emitting any decrypted output if the JWE Authentication Tag is incorrect.
16. 指定されたコンテンツ暗号化アルゴリズムを使用して、CEK、JWE初期化ベクトル、追加認証データ値、およびJWE認証タグ（計算への認証タグ入力）を使用してJWE暗号文を復号化し、復号化された平文を返し、JWEを検証しますアルゴリズムに指定された方法での認証タグ。JWE認証タグが正しくない場合、復号化された出力を発行せずに入力を拒否します。
17. If a "zip" parameter was included, uncompress the decrypted plaintext using the specified compression algorithm.
17. 「zip」パラメーターが含まれている場合は、指定された圧縮アルゴリズムを使用して、復号化された平文を解凍します。
18. If there was no recipient for which all of the decryption steps succeeded, then the JWE MUST be considered invalid. Otherwise, output the plaintext. In the JWE JSON Serialization case, also return a result to the application indicating for which of the recipients the decryption succeeded and failed.
18. すべての復号化ステップが成功した受信者がいない場合、JWEは無効と見なされる必要があります。それ以外の場合は、平文を出力します。 JWE JSONシリアライゼーションの場合、復号化が成功したか失敗したかを示す結果をアプリケーションに返します。
Finally, note that it is an application decision which algorithms may be used in a given context. Even if a JWE can be successfully decrypted, unless the algorithms used in the JWE are acceptable to the application, it SHOULD consider the JWE to be invalid.
最後に、特定のコンテキストで使用できるアルゴリズムはアプリケーションの決定であることに注意してください。 JWEが正常に復号化できたとしても、JWEで使用されているアルゴリズムがアプリケーションに受け入れられない限り、JWEは無効であると見なすべきです。
The string comparison rules for this specification are the same as those defined in Section 5.3 of [JWS].
この仕様の文字列比較規則は、[JWS]のセクション5.3で定義されているものと同じです。
The key identification methods for this specification are the same as those defined in Section 6 of [JWS], except that the key being identified is the public key to which the JWE was encrypted.
この仕様のキー識別方法は、識別されるキーがJWEが暗号化された公開キーであることを除いて、[JWS]のセクション6で定義されたものと同じです。
JWEs use one of two serializations: the JWE Compact Serialization or the JWE JSON Serialization. Applications using this specification need to specify what serialization and serialization features are used for that application. For instance, applications might specify that only the JWE JSON Serialization is used, that only JWE JSON Serialization support for a single recipient is used, or that support for multiple recipients is used. JWE implementations only need to implement the features needed for the applications they are designed to support.
JWEは、JWE Compact SerializationまたはJWE JSON Serializationの2つのシリアライゼーションのいずれかを使用します。この仕様を使用するアプリケーションは、そのアプリケーションに使用されるシリアル化およびシリアル化機能を指定する必要があります。たとえば、アプリケーションは、JWE JSONシリアル化のみが使用されること、単一の受信者に対するJWE JSONシリアル化サポートのみが使用されること、または複数の受信者に対するサポートが使用されることを指定する場合があります。 JWE実装は、サポートするように設計されたアプリケーションに必要な機能を実装するだけで済みます。
The JWE Compact Serialization represents encrypted content as a compact, URL-safe string. This string is:
JWE Compact Serializationは、暗号化されたコンテンツをコンパクトでURLセーフな文字列として表します。この文字列は次のとおりです。
BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag)
BASE64URL（UTF8（JWE保護ヘッダー））|| 「。」 || BASE64URL（PLAY暗号化キー）|| 「。」 || BASE64URL（PLAY初期化ベクトル）|| 「。」 || BASE64URL（PLAY Ciphertext）|| 「。」 || BASE64URL（PLAY認証タグ）
Only one recipient is supported by the JWE Compact Serialization and it provides no syntax to represent JWE Shared Unprotected Header, JWE Per-Recipient Unprotected Header, or JWE AAD values.
JWE Compact Serializationでサポートされる受信者は1つだけであり、JWE共有非保護ヘッダー、JWE受信者非保護ヘッダー、またはJWE AAD値を表す構文は提供されません。
The JWE JSON Serialization represents encrypted content as a JSON object. This representation is neither optimized for compactness nor URL safe.
JWE JSON Serializationは、暗号化されたコンテンツをJSONオブジェクトとして表します。この表現は、コンパクトさもURLセーフも最適化されていません。
Two closely related syntaxes are defined for the JWE JSON Serialization: a fully general syntax, with which content can be encrypted to more than one recipient, and a flattened syntax, which is optimized for the single-recipient case.
JWE JSONシリアライゼーションには、密接に関連する2つの構文が定義されています。コンテンツを複数の受信者に暗号化できる完全に一般的な構文と、単一の受信者の場合に最適化されたフラット化された構文です。
The following members are defined for use in top-level JSON objects used for the fully general JWE JSON Serialization syntax:
次のメンバーは、完全に一般的なJWE JSONシリアル化構文に使用されるトップレベルのJSONオブジェクトで使用するために定義されています。
protected The "protected" member MUST be present and contain the value BASE64URL(UTF8(JWE Protected Header)) when the JWE Protected Header value is non-empty; otherwise, it MUST be absent. These Header Parameter values are integrity protected.
JWE保護ヘッダー値が空でない場合、「保護」メンバーが存在し、値BASE64URL（UTF8（JWE保護ヘッダー））を含んでいる必要があります。それ以外の場合は、存在しない必要があります。これらのヘッダーパラメータ値は整合性が保護されています。
unprotected The "unprotected" member MUST be present and contain the value JWE Shared Unprotected Header when the JWE Shared Unprotected Header value is non-empty; otherwise, it MUST be absent. This value is represented as an unencoded JSON object, rather than as a string. These Header Parameter values are not integrity protected.
unprotected「非保護」メンバーが存在し、JWE共有非保護ヘッダー値が空でない場合は、値JWE共有非保護ヘッダーを含む必要があります。それ以外の場合は、存在しない必要があります。この値は、文字列としてではなく、エンコードされていないJSONオブジェクトとして表されます。これらのヘッダーパラメータ値は整合性が保護されていません。
iv The "iv" member MUST be present and contain the value BASE64URL(JWE Initialization Vector) when the JWE Initialization Vector value is non-empty; otherwise, it MUST be absent.
iv JWE初期化ベクトル値が空でない場合、「iv」メンバーが存在し、値BASE64URL（JWE初期化ベクトル）を含んでいる必要があります。それ以外の場合は、存在しない必要があります。
aad The "aad" member MUST be present and contain the value BASE64URL(JWE AAD)) when the JWE AAD value is non-empty; otherwise, it MUST be absent. A JWE AAD value can be included to supply a base64url-encoded value to be integrity protected but not encrypted.
aad JWE AAD値が空でない場合、「aad」メンバーが存在し、値BASE64URL（JWE AAD））を含んでいる必要があります。それ以外の場合は、存在しない必要があります。 JWE AAD値を含めて、base64urlでエンコードされた値を提供して、整合性を保護するが暗号化しないようにすることができます。
ciphertext The "ciphertext" member MUST be present and contain the value BASE64URL(JWE Ciphertext).
ciphertext「ciphertext」メンバーが存在し、値BASE64URL（JWE Ciphertext）を含んでいる必要があります。
tag The "tag" member MUST be present and contain the value BASE64URL(JWE Authentication Tag) when the JWE Authentication Tag value is non-empty; otherwise, it MUST be absent.
tag「タグ」メンバーが存在しなければならず、JWE認証タグ値が空でない場合は、値BASE64URL（JWE Authentication Tag）が含まれている必要があります。それ以外の場合は、存在しない必要があります。
recipients The "recipients" member value MUST be an array of JSON objects. Each object contains information specific to a single recipient. This member MUST be present with exactly one array element per recipient, even if some or all of the array element values are the empty JSON object "{}" (which can happen when all Header Parameter values are shared between all recipients and when no encrypted key is used, such as when doing Direct Encryption).
受信者 "recipients"メンバーの値は、JSONオブジェクトの配列である必要があります。各オブジェクトには、単一の受信者に固有の情報が含まれています。配列要素の値の一部またはすべてが空のJSONオブジェクト "{}"であっても、このメンバーは受信者ごとに1つの配列要素とともに存在する必要があります（すべてのヘッダーパラメーター値がすべての受信者間で共有され、暗号化されていない場合に発生する可能性があります）キーが使用されます（直接暗号化を行う場合など）。
The following members are defined for use in the JSON objects that are elements of the "recipients" array:
次のメンバーは、「recipients」配列の要素であるJSONオブジェクトで使用するために定義されています。
header The "header" member MUST be present and contain the value JWE Per-Recipient Unprotected Header when the JWE Per-Recipient Unprotected Header value is non-empty; otherwise, it MUST be absent. This value is represented as an unencoded JSON object, rather than as a string. These Header Parameter values are not integrity protected.
header "header"メンバーは存在しなければならず、JWE Per-Recipient Unprotected Header値が空でない場合、値JWE Per-Recipient Unprotected Headerが含まれている必要があります。それ以外の場合は、存在しない必要があります。この値は、文字列としてではなく、エンコードされていないJSONオブジェクトとして表されます。これらのヘッダーパラメータ値は整合性が保護されていません。
encrypted_key The "encrypted_key" member MUST be present and contain the value BASE64URL(JWE Encrypted Key) when the JWE Encrypted Key value is non-empty; otherwise, it MUST be absent.
encrypted_key「encrypted_key」メンバーは、JWE暗号化キー値が空でない場合に存在し、値BASE64URL（JWE暗号化キー）を含んでいる必要があります。それ以外の場合は、存在しない必要があります。
At least one of the "header", "protected", and "unprotected" members MUST be present so that "alg" and "enc" Header Parameter values are conveyed for each recipient computation.
「ヘッダー」、「保護」、および「非保護」のメンバーの少なくとも1つが存在する必要があります。これにより、「alg」および「enc」のヘッダーパラメーター値が各受信者の計算で伝達されます。
Additional members can be present in both the JSON objects defined above; if not understood by implementations encountering them, they MUST be ignored.
上記で定義した両方のJSONオブジェクトに追加のメンバーを含めることができます。それらに遭遇する実装によって理解されない場合、それらは無視されなければなりません。
Some Header Parameters, including the "alg" parameter, can be shared among all recipient computations. Header Parameters in the JWE Protected Header and JWE Shared Unprotected Header values are shared among all recipients.
「alg」パラメーターを含む一部のヘッダーパラメーターは、すべての受信者の計算で共有できます。 JWE保護ヘッダーのヘッダーパラメーターとJWE共有非保護ヘッダーの値は、すべての受信者間で共有されます。
The Header Parameter values used when creating or validating per-recipient ciphertext and Authentication Tag values are the union of the three sets of Header Parameter values that may be present: (1) the JWE Protected Header represented in the "protected" member, (2) the JWE Shared Unprotected Header represented in the "unprotected" member, and (3) the JWE Per-Recipient Unprotected Header represented in the "header" member of the recipient's array element. The union of these sets of Header Parameters comprises the JOSE Header. The Header Parameter names in the three locations MUST be disjoint.
受信者ごとの暗号文と認証タグの値を作成または検証するときに使用されるヘッダーパラメーター値は、存在する可能性のあるヘッダーパラメーター値の3つのセットの和集合です。（1）「保護された」メンバーで表されるJWE保護ヘッダー、（2 ）「無保護」メンバーで表されるJWE共有無保護ヘッダー、および（3）受信者の配列要素の「ヘッダー」メンバーで表される受信者ごとの無保護ヘッダー。これらのヘッダーパラメータのセットの和集合がJOSEヘッダーを構成します。 3つの場所のヘッダーパラメータ名はばらばらにする必要があります。
Each JWE Encrypted Key value is computed using the parameters of the corresponding JOSE Header value in the same manner as for the JWE Compact Serialization. This has the desirable property that each JWE Encrypted Key value in the "recipients" array is identical to the value that would have been computed for the same parameter in the JWE Compact Serialization. Likewise, the JWE Ciphertext and JWE Authentication Tag values match those produced for the JWE Compact Serialization, provided that the JWE Protected Header value (which represents the integrity-protected Header Parameter values) matches that used in the JWE Compact Serialization.
各JWE暗号化キーの値は、JWE Compact Serializationの場合と同じ方法で、対応するJOSEヘッダー値のパラメーターを使用して計算されます。これには、「recipients」配列の各JWE暗号化キーの値が、JWE Compact Serializationの同じパラメーターに対して計算された値と同じであるという望ましい特性があります。同様に、JWE暗号化テキストとJWE認証タグの値は、JWE保護シリアル化で生成された値と一致します。
All recipients use the same JWE Protected Header, JWE Initialization Vector, JWE Ciphertext, and JWE Authentication Tag values, when present, resulting in potentially significant space savings if the message is large. Therefore, all Header Parameters that specify the treatment of the plaintext value MUST be the same for all recipients. This primarily means that the "enc" (encryption algorithm) Header Parameter value in the JOSE Header for each recipient and any parameters of that algorithm MUST be the same.
すべての受信者が同じJWE保護ヘッダー、JWE初期化ベクトル、JWE暗号テキスト、およびJWE認証タグの値を使用しているため、メッセージが大きい場合、大幅にスペースを節約できる可能性があります。したがって、平文の値の扱いを指定するすべてのヘッダーパラメータは、すべての受信者に対して同じでなければなりません。これは主に、各受信者のJOSEヘッダーの「enc」（暗号化アルゴリズム）ヘッダーパラメーター値とそのアルゴリズムのパラメーターが同じでなければならないことを意味します。
In summary, the syntax of a JWE using the general JWE JSON Serialization is as follows:
要約すると、一般的なJWE JSONシリアル化を使用するJWEの構文は次のとおりです。
{
"protected":"<integrity-protected shared header contents>",
"unprotected":<non-integrity-protected shared header contents>,
"recipients":[
{"header":<per-recipient unprotected header 1 contents>,
"encrypted_key":"<encrypted key 1 contents>"},
...
{"header":<per-recipient unprotected header N contents>,
"encrypted_key":"<encrypted key N contents>"}],
"aad":"<additional authenticated data contents>",
"iv":"<initialization vector contents>",
"ciphertext":"<ciphertext contents>",
"tag":"<authentication tag contents>"
}
See Appendix A.4 for an example JWE using the general JWE JSON Serialization syntax.
一般的なJWE JSONシリアル化構文を使用したJWEの例については、付録A.4を参照してください。
The flattened JWE JSON Serialization syntax is based upon the general syntax, but flattens it, optimizing it for the single-recipient case. It flattens it by removing the "recipients" member and instead placing those members defined for use in the "recipients" array (the "header" and "encrypted_key" members) in the top-level JSON object (at the same level as the "ciphertext" member).
フラット化されたJWE JSONシリアル化構文は、一般的な構文に基づいていますが、フラット化して、単一の受信者の場合に合わせて最適化します。 「recipients」メンバーを削除してフラット化し、代わりに、トップレベルのJSONオブジェクトの「recipients」配列（「header」および「encrypted_key」メンバー）で使用するために定義されたメンバーを（「暗号文」メンバー）。
The "recipients" member MUST NOT be present when using this syntax. Other than this syntax difference, JWE JSON Serialization objects using the flattened syntax are processed identically to those using the general syntax.
この構文を使用する場合、「受信者」メンバーは存在してはなりません（MUST NOT）。この構文の違いを除いて、フラット化された構文を使用するJWE JSONシリアル化オブジェクトは、一般的な構文を使用するオブジェクトと同じように処理されます。
In summary, the syntax of a JWE using the flattened JWE JSON Serialization is as follows:
要約すると、フラット化されたJWE JSONシリアル化を使用するJWEの構文は次のとおりです。
{
"protected":"<integrity-protected header contents>",
"unprotected":<non-integrity-protected header contents>,
"header":<more non-integrity-protected header contents>,
"encrypted_key":"<encrypted key contents>",
"aad":"<additional authenticated data contents>",
"iv":"<initialization vector contents>",
"ciphertext":"<ciphertext contents>",
"tag":"<authentication tag contents>"
}
Note that when using the flattened syntax, just as when using the general syntax, any unprotected Header Parameter values can reside in either the "unprotected" member or the "header" member, or in both.
一般的な構文を使用する場合と同様に、フラット化された構文を使用する場合、保護されていないヘッダーパラメーター値は、「保護されていない」メンバーまたは「ヘッダー」メンバーのいずれか、または両方に存在できることに注意してください。
See Appendix A.5 for an example JWE using the flattened JWE JSON Serialization syntax.
平坦化されたJWE JSONシリアル化構文を使用するJWEの例については、付録A.5を参照してください。
The Transport Layer Security (TLS) requirements for this specification are the same as those defined in Section 8 of [JWS].
この仕様のトランスポート層セキュリティ（TLS）要件は、[JWS]のセクション8で定義されているものと同じです。
There are several ways of distinguishing whether an object is a JWS or JWE. All these methods will yield the same result for all legal input values; they may yield different results for malformed inputs.
オブジェクトがJWSかJWEかを区別する方法はいくつかあります。これらのメソッドはすべて、すべての有効な入力値に対して同じ結果をもたらします。不正な入力に対して異なる結果が生じる可能性があります。
o If the object is using the JWS Compact Serialization or the JWE Compact Serialization, the number of base64url-encoded segments separated by period ('.') characters differs for JWSs and JWEs. JWSs have three segments separated by two period ('.') characters. JWEs have five segments separated by four period ('.') characters.
o オブジェクトがJWS Compact SerializationまたはJWE Compact Serializationを使用している場合、ピリオド（ '。'）文字で区切られたbase64urlエンコードセグメントの数は、JWSとJWEで異なります。 JWSには、2つのピリオド（ '。'）文字で区切られた3つのセグメントがあります。 JWEには、4つのピリオド（ '。'）文字で区切られた5つのセグメントがあります。
o If the object is using the JWS JSON Serialization or the JWE JSON Serialization, the members used will be different. JWSs have a "payload" member and JWEs do not. JWEs have a "ciphertext" member and JWSs do not.
o オブジェクトがJWS JSONシリアル化またはJWE JSONシリアル化を使用している場合、使用されるメンバーは異なります。 JWSには「ペイロード」メンバーがあり、JWEにはありません。 JWEには「暗号文」メンバーがあり、JWSにはありません。
o The JOSE Header for a JWS can be distinguished from the JOSE Header for a JWE by examining the "alg" (algorithm) Header Parameter value. If the value represents a digital signature or MAC algorithm, or is the value "none", it is for a JWS; if it represents a Key Encryption, Key Wrapping, Direct Key Agreement, Key Agreement with Key Wrapping, or Direct Encryption algorithm, it is for a JWE. (Extracting the "alg" value to examine is straightforward when using the JWS Compact Serialization or the JWE Compact Serialization and may be more difficult when using the JWS JSON Serialization or the JWE JSON Serialization.)
o JWSのJOSEヘッダーは、「alg」（アルゴリズム）ヘッダーパラメーター値を調べることにより、JWEのJOSEヘッダーと区別できます。値がデジタル署名またはMACアルゴリズムを表す場合、または値が「なし」の場合は、JWS用です。それが鍵暗号化、鍵ラッピング、直接鍵合意、鍵ラッピングとの鍵合意、または直接暗号化アルゴリズムを表す場合、それはJWE用です。 （調査する「alg」値の抽出は、JWSコンパクトシリアライゼーションまたはJWEコンパクトシリアライゼーションを使用する場合は簡単で、JWS JSONシリアライゼーションまたはJWE JSONシリアライゼーションを使用する場合はさらに困難になる場合があります。）
o The JOSE Header for a JWS can also be distinguished from the JOSE Header for a JWE by determining whether an "enc" (encryption algorithm) member exists. If the "enc" member exists, it is a JWE; otherwise, it is a JWS.
o JWSのJOSEヘッダーは、 "enc"（暗号化アルゴリズム）メンバーが存在するかどうかを判別することにより、JWEのJOSEヘッダーと区別することもできます。 「enc」メンバーが存在する場合、それはJWEです。それ以外の場合は、JWSです。
This section registers the Header Parameter names defined in Section 4.1 in the IANA "JSON Web Signature and Encryption Header Parameters" registry established by [JWS].
このセクションは、セクション4.1で定義されたヘッダーパラメータ名を、[JWS]によって確立されたIANA "JSON Web Signature and Encryption Header Parameters"レジストリに登録します。
o Header Parameter Name: "alg" o Header Parameter Description: Algorithm o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.1.1 of RFC 7516
o ヘッダーパラメーター名：「alg」oヘッダーパラメーターの説明：アルゴリズムoヘッダーパラメーターの使用場所：JWE o変更コントローラー：IESG o仕様書：RFC 7516のセクション4.1.1
o Header Parameter Name: "enc" o Header Parameter Description: Encryption Algorithm o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.1.2 of RFC 7516
o ヘッダーパラメーター名： "enc" oヘッダーパラメーターの説明：暗号化アルゴリズムoヘッダーパラメーターの使用場所：JWE o変更コントローラー：IESG o仕様書：RFC 7516のセクション4.1.2
o Header Parameter Name: "zip"
o Header Parameter Description: Compression Algorithm
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.1.3 of RFC 7516
o Header Parameter Name: "jku"
o Header Parameter Description: JWK Set URL
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.1.4 of RFC 7516
o Header Parameter Name: "jwk" o Header Parameter Description: JSON Web Key o Header Parameter Usage Location(s): JWE
o ヘッダーパラメーター名： "jwk" oヘッダーパラメーターの説明：JSON Web Key oヘッダーパラメーターの使用場所：JWE
o Change Controller: IESG o Specification Document(s): Section 4.1.5 of RFC 7516
o 変更管理者：IESG o仕様書：RFC 7516のセクション4.1.5
o Header Parameter Name: "kid" o Header Parameter Description: Key ID o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.1.6 of RFC 7516
o ヘッダーパラメータ名：「kid」oヘッダーパラメータの説明：キーID oヘッダーパラメータの使用場所：JWE o変更コントローラ：IESG o仕様書：RFC 7516のセクション4.1.6
o Header Parameter Name: "x5u" o Header Parameter Description: X.509 URL o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.1.7 of RFC 7516
o ヘッダーパラメーター名： "x5u" oヘッダーパラメーターの説明：X.509 URL oヘッダーパラメーターの使用場所：JWE o変更コントローラー：IESG o仕様書：RFC 7516のセクション4.1.7
o Header Parameter Name: "x5c" o Header Parameter Description: X.509 Certificate Chain o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.1.8 of RFC 7516
o ヘッダーパラメーター名： "x5c" oヘッダーパラメーターの説明：X.509証明書チェーンoヘッダーパラメーターの使用場所：JWE o変更コントローラー：IESG o仕様書：RFC 7516のセクション4.1.8
o Header Parameter Name: "x5t" o Header Parameter Description: X.509 Certificate SHA-1 Thumbprint o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.1.9 of RFC 7516
o ヘッダーパラメーター名： "x5t" oヘッダーパラメーターの説明：X.509証明書のSHA-1サムプリントoヘッダーパラメーターの使用場所：JWE o変更コントローラー：IESG o仕様書：RFC 7516のセクション4.1.9
o Header Parameter Name: "x5t#S256" o Header Parameter Description: X.509 Certificate SHA-256 Thumbprint o Header Parameter Usage Location(s): JWE o Change Controller: IESG o Specification Document(s): Section 4.1.10 of RFC 7516
o ヘッダーパラメーター名：「x5t＃S256」oヘッダーパラメーターの説明：X.509証明書のSHA-256サムプリントoヘッダーパラメーターの使用場所：JWE o変更コントローラー：IESG o仕様書：RFCのセクション4.1.10 7516
o Header Parameter Name: "typ"
o Header Parameter Description: Type
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.1.11 of RFC 7516
o Header Parameter Name: "cty"
o Header Parameter Description: Content Type
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): Section 4.1.12 of RFC 7516
o Header Parameter Name: "crit" o Header Parameter Description: Critical o Header Parameter Usage Location(s): JWE
o ヘッダーパラメーター名：「crit」oヘッダーパラメーターの説明：重要oヘッダーパラメーターの使用場所：JWE
o Change Controller: IESG o Specification Document(s): Section 4.1.13 of RFC 7516
o 変更管理者：IESG o仕様書：RFC 7516のセクション4.1.13
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エージェントによって対処する必要があります。これらの問題の中には、ユーザーの非対称秘密鍵と対称秘密鍵の保護と、さまざまな攻撃への対策の採用があります。
All the security considerations in the JWS specification also apply to this specification. Likewise, all the security considerations in XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411] also apply, other than those that are XML specific.
JWS仕様のセキュリティに関する考慮事項はすべて、この仕様にも適用されます。同様に、XML暗号化1.1 [W3C.REC-xmlenc-core1-20130411]のセキュリティに関するすべての考慮事項も、XML固有の考慮事項を除いて適用されます。
See Section 10.1 of [JWS] for security considerations on key entropy and random values. In addition to the uses of random values listed there, note that random values are also used for Content Encryption Keys (CEKs) and Initialization Vectors (IVs) when performing encryption.
キーエントロピーとランダム値のセキュリティに関する考慮事項については、[JWS]のセクション10.1を参照してください。そこにリストされているランダム値の使用に加えて、ランダム値は暗号化を実行するときにコンテンツ暗号化キー（CEK）と初期化ベクトル（IV）にも使用されることに注意してください。
See Section 10.2 of [JWS] for security considerations on key protection. In addition to the keys listed there that must be protected, implementations performing encryption must protect the key encryption key and the Content Encryption Key. Compromise of the key encryption key may result in the disclosure of all contents protected with that key. Similarly, compromise of the Content Encryption Key may result in disclosure of the associated encrypted content.
キー保護に関するセキュリティの考慮事項については、[JWS]のセクション10.2を参照してください。保護する必要があるそこにリストされているキーに加えて、暗号化を実行する実装は、キー暗号化キーとコンテンツ暗号化キーを保護する必要があります。キー暗号化キーが侵害されると、そのキーで保護されているすべてのコンテンツが漏洩する可能性があります。同様に、コンテンツ暗号化キーの侵害により、関連する暗号化されたコンテンツが開示される可能性があります。
Algorithms of matching strengths should be used together whenever possible. For instance, when AES Key Wrap is used with a given key size, using the same key size is recommended when AES GCM is also used. If the key encryption and content encryption algorithms are different, the effective security is determined by the weaker of the two algorithms.
強度を一致させるアルゴリズムは、可能な限り一緒に使用する必要があります。たとえば、特定のキーサイズでAESキーラップを使用する場合、AES GCMも使用するときは同じキーサイズを使用することをお勧めします。キー暗号化とコンテンツ暗号化アルゴリズムが異なる場合、効果的なセキュリティは2つのアルゴリズムのうちの弱い方によって決定されます。
Also, see RFC 3766 [RFC3766] for information on determining strengths for public keys used for exchanging symmetric keys.
また、対称鍵の交換に使用される公開鍵の強度を決定する方法については、RFC 3766 [RFC3766]を参照してください。
When decrypting, particular care must be taken not to allow the JWE recipient to be used as an oracle for decrypting messages. RFC 3218 [RFC3218] should be consulted for specific countermeasures to attacks on RSAES-PKCS1-v1_5. An attacker might modify the contents of the "alg" Header Parameter from "RSA-OAEP" to "RSA1_5" in order to generate a formatting error that can be detected and used to recover the CEK even if RSAES-OAEP was used to encrypt the CEK. It is therefore particularly important to report all formatting errors to the CEK, Additional Authenticated Data, or ciphertext as a single error when the encrypted content is rejected.
復号化するときは、JWE受信者がメッセージを復号化するためのオラクルとして使用されないように特に注意する必要があります。 RSAES-PKCS1-v1_5への攻撃に対する具体的な対策については、RFC 3218 [RFC3218]を参照してください。攻撃者は、RSAES-OAEPを使用して暗号化した場合でもCEKを回復するために検出および使用できるフォーマットエラーを生成するために、「alg」ヘッダーパラメータの内容を「RSA-OAEP」から「RSA1_5」に変更する可能性があります。 CEK。したがって、暗号化されたコンテンツが拒否された場合、すべてのフォーマットエラーをCEK、追加の認証データ、または暗号文に1つのエラーとして報告することが特に重要です。
Additionally, this type of attack can be prevented by restricting the use of a key to a limited set of algorithms -- usually one. This means, for instance, that if the key is marked as being for "RSA-OAEP" only, any attempt to decrypt a message using the "RSA1_5" algorithm with that key should fail immediately due to invalid use of the key.
さらに、このタイプの攻撃は、キーの使用を限られたアルゴリズムのセット（通常は1つ）に制限することで防止できます。これは、たとえば、キーが「RSA-OAEP」のみとしてマークされている場合、そのキーを使用して「RSA1_5」アルゴリズムを使用するメッセージを復号化しようとすると、キーの無効な使用により直ちに失敗することを意味します。
To mitigate the attacks described in RFC 3218 [RFC3218], the recipient MUST NOT distinguish between format, padding, and length errors of encrypted keys. It is strongly recommended, in the event of receiving an improperly formatted key, that the recipient substitute a randomly generated CEK and proceed to the next step, to mitigate timing attacks.
RFC 3218 [RFC3218]で説明されている攻撃を緩和するために、受信者は、暗号化されたキーのフォーマット、パディング、および長さのエラーを区別してはなりません（MUST NOT）。不適切な形式のキーを受け取った場合は、受信者がランダムに生成されたCEKを代用して次のステップに進み、タイミング攻撃を緩和することを強くお勧めします。
[JWA] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <http://www.rfc-editor.org/info/rfc7518>.
[JWA]ジョーンズ、M。、「JSON Web Algorithms（JWA）」、RFC 7518、DOI 10.17487 / RFC7518、2015年5月、<http://www.rfc-editor.org/info/rfc7518>。
[JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <http://www.rfc-editor.org/info/rfc7517>.
[JWK]ジョーンズ、M。、「JSON Web Key（JWK）」、RFC 7517、DOI 10.17487 / RFC7517、2015年5月、<http://www.rfc-editor.org/info/rfc7517>。
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <http://www.rfc-editor.org/info/rfc7515>.
[JWS]ジョーンズ、M。、ブラッドリー、J.、N。崎村、「JSON Web Signature（JWS）」、RFC 7515、DOI 10.17487 / RFC7515、2015年5月、<http://www.rfc-editor.org / info / rfc7515>。
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, <http://www.rfc-editor.org/info/rfc1951>.
[RFC1951] Deutsch、P。、「DEFLATE Compressed Data Format Specification version 1.3」、RFC 1951、DOI 10.17487 / RFC1951、1996年5月、<http://www.rfc-editor.org/info/rfc1951>。
[RFC20] Cerf, V., "ASCII format for Network Interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20] Cerf、V。、「ネットワークインターチェンジのASCII形式」、STD 80、RFC 20、DOI 10.17487 / RFC0020、1969年10月、<http://www.rfc-editor.org/info/rfc20>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<http://www.rfc-editor.org/info/ rfc3629>。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、FYI 36、RFC 4949、DOI 10.17487 / RFC4949、2007年8月、<http://www.rfc-editor.org/info/rfc4949>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]ブレイ、T。、編、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、RFC 7159、DOI 10.17487 / RFC7159、2014年3月、<http://www.rfc-editor.org/info/ rfc7159>。
[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[UNICODE] Unicodeコンソーシアム、「The Unicode Standard」、<http://www.unicode.org/versions/latest/>。
[AES] National Institute of Standards and Technology (NIST), "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001, <http://csrc.nist.gov/publications/ fips/fips197/fips-197.pdf>.
[AES]米国国立標準技術研究所（NIST）、「Advanced Encryption Standard（AES）」、FIPS PUB 197、2001年11月、<http://csrc.nist.gov/publications/fips/fips197/fips-197。 pdf>。
[JSE] Bradley, J. and N. Sakimura (editor), "JSON Simple Encryption", September 2010, <http://jsonenc.info/enc/1.0/>.
[JSE] Bradley、J。およびN.崎村（編集者）、「JSON Simple Encryption」、2010年9月、<http://jsonenc.info/enc/1.0/>。
[JSMS] Rescorla, E. and J. Hildebrand, "JavaScript Message Security Format", Work in Progress, draft-rescorla-jsms-00, March 2011.
[JSMS] Rescorla、E。およびJ. Hildebrand、「JavaScript Message Security Format」、Work in Progress、draft-rescorla-jsms-00、2011年3月。
[NIST.800-38D] National Institute of Standards and Technology (NIST), "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST PUB 800-38D, November 2007, <http://csrc.nist.gov/publications/ nistpubs/800-38D/SP-800-38D.pdf>.
[NIST.800-38D]米国国立標準技術研究所（NIST）、「Block Cipher Modes of Operation：Galois / Counter Mode（GCM）and GMAC」、NIST PUB 800-38D、2007年11月、<http：/ /csrc.nist.gov/publications/ nistpubs / 800-38D / SP-800-38D.pdf>。
[RFC3218] Rescorla, E., "Preventing the Million Message Attack on Cryptographic Message Syntax", RFC 3218, DOI 10.17487/RFC3218, January 2002, <http://www.rfc-editor.org/info/rfc3218>.
[RFC3218] Rescorla、E。、「Preventing the Million Message Attack on Cryptographic Message Syntax」、RFC 3218、DOI 10.17487 / RFC3218、2002年1月、<http://www.rfc-editor.org/info/rfc3218>。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC3447] Jonsson、J。およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA Cryptography Specifications Version 2.1」、RFC 3447、DOI 10.17487 / RFC3447、2003年2月、<http：//www.rfc -editor.org/info/rfc3447>。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, DOI 10.17487/RFC3766, April 2004, <http://www.rfc-editor.org/info/rfc3766>.
[RFC3766] Orman、H。およびP. Hoffman、「Determining Strengths for Public Keys Exchangeing Symmetric Keys」、BCP 86、RFC 3766、DOI 10.17487 / RFC3766、2004年4月、<http：//www.rfc-editor。 org / info / rfc3766>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.
[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、June 2005、<http：//www.rfc-editor .org / info / rfc4086>。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <http://www.rfc-editor.org/info/rfc5652>.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、DOI 10.17487 / RFC5652、2009年9月、<http://www.rfc-editor.org/info/rfc5652>。
[W3C.REC-xmlenc-core1-20130411] Eastlake, D., Reagle, J., Hirsch, F., and T. Roessler, "XML Encryption Syntax and Processing Version 1.1", World Wide Web Consortium Recommendation REC-xmlenc-core1-20130411, April 2013, <http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/>.
[W3C.REC-xmlenc-core1-20130411] Eastlake、D.、Reagle、J.、Hirsch、F。、およびT. Roessler、「XML Encryption Syntax and Processing Version 1.1」、World Wide Web Consortium Recommendation REC-xmlenc- core1-20130411、2013年4月、<http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/>。
This section provides examples of JWE computations.
このセクションでは、JWE計算の例を示します。
This example encrypts the plaintext "The true sign of intelligence is not knowledge but imagination." to the recipient using RSAES-OAEP for key encryption and AES GCM for content encryption. The representation of this plaintext (using JSON array notation) is:
この例では、「知性の真の兆候は知識ではなく想像力である」という平文を暗号化しています。キーの暗号化にはRSAES-OAEPを使用し、コンテンツの暗号化にはAES GCMを使用して受信者に送信します。このプレーンテキストの表現（JSON配列表記を使用）は次のとおりです。
[84, 104, 101, 32, 116, 114, 117, 101, 32, 115, 105, 103, 110, 32, 111, 102, 32, 105, 110, 116, 101, 108, 108, 105, 103, 101, 110, 99, 101, 32, 105, 115, 32, 110, 111, 116, 32, 107, 110, 111, 119, 108, 101, 100, 103, 101, 32, 98, 117, 116, 32, 105, 109, 97, 103, 105, 110, 97, 116, 105, 111, 110, 46]
[84, 104, 101, 32, 116, 114, 117, 101, 32, 115, 105, 103, 110, 32, 111, 102, 32, 105, 110, 116, 101, 108, 108, 105, 103, 101, 110, 99, 101, 32, 105, 115, 32, 110, 111, 116, 32, 107, 110, 111, 119, 108, 101, 100, 103, 101, 32, 98, 117, 116, 32, 105, 109, 97, 103, 105, 110, 97, 116, 105, 111, 110, 46]
The following example JWE Protected Header declares that:
次の例のJWE保護ヘッダーは、それを宣言しています。
o The Content Encryption Key is encrypted to the recipient using the RSAES-OAEP algorithm to produce the JWE Encrypted Key. o Authenticated encryption is performed on the plaintext using the AES GCM algorithm with a 256-bit key to produce the ciphertext and the Authentication Tag.
o コンテンツ暗号化キーは、RSAES-OAEPアルゴリズムを使用して受信者に対して暗号化され、JWE暗号化キーが生成されます。 o認証された暗号化は、AES GCMアルゴリズムと256ビットキーを使用して平文で実行され、暗号文と認証タグを生成します。
{"alg":"RSA-OAEP","enc":"A256GCM"}
Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected Header)) gives this value:
このJWE保護ヘッダーをBASE64URL（UTF8（JWE保護ヘッダー））としてエンコードすると、次の値が得られます。
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ
Generate a 256-bit random CEK. In this example, the value (using JSON array notation) is:
256ビットのランダムCEKを生成します。この例では、値（JSON配列表記を使用）は次のとおりです。
[177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154, 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122, 234, 64, 252]
「１７７、 １６１、 ２４４、 １２８、 ８４、 １４３、 ２２５、 １１５、 ６３、 １８０、 ３、 ２５５、 １０７、 １５４、 ２１２、 ２４６、 １３８、 ７、 １１０、 ９１、 １１２、 ４６、 ３４、 １０５、 ４７、 １３０、 ２０３、 ４６、 １２２、 ２３４、 ６４、 ２５２」
Encrypt the CEK with the recipient's public key using the RSAES-OAEP algorithm to produce the JWE Encrypted Key. This example uses the RSA key represented in JSON Web Key [JWK] format below (with line breaks within values for display purposes only):
RSAES-OAEPアルゴリズムを使用して受信者の公開鍵でCEKを暗号化し、JWE暗号化鍵を生成します。この例では、以下のJSON Web Key [JWK]形式で表されたRSAキーを使用します（表示目的でのみ値内に改行を入れます）。
{"kty":"RSA", "n":"oahUIoWw0K0usKNuOR6H4wkf4oBUXHTxRvgb48E-BVvxkeDNjbC4he8rUW cJoZmds2h7M70imEVhRU5djINXtqllXI4DFqcI1DgjT9LewND8MW2Krf3S psk_ZkoFnilakGygTwpZ3uesH-PFABNIUYpOiN15dsQRkgr0vEhxN92i2a sbOenSZeyaxziK72UwxrrKoExv6kc5twXTq4h-QChLOln0_mtUZwfsRaMS tPs6mS6XrgxnxbWhojf663tuEQueGC-FCMfra36C9knDFGzKsNa7LZK2dj YgyD3JR_MB_4NUJW_TqOQtwHYbxevoJArm-L5StowjzGy-_bq6Gw", "e":"AQAB", "d":"kLdtIj6GbDks_ApCSTYQtelcNttlKiOyPzMrXHeI-yk1F7-kpDxY4-WY5N WV5KntaEeXS1j82E375xxhWMHXyvjYecPT9fpwR_M9gV8n9Hrh2anTpTD9 3Dt62ypW3yDsJzBnTnrYu1iwWRgBKrEYY46qAZIrA2xAwnm2X7uGR1hghk qDp0Vqj3kbSCz1XyfCs6_LehBwtxHIyh8Ripy40p24moOAbgxVw3rxT_vl t3UVe4WO3JkJOzlpUf-KTVI2Ptgm-dARxTEtE-id-4OJr0h-K-VFs3VSnd VTIznSxfyrj8ILL6MG_Uv8YAu7VILSB3lOW085-4qE3DzgrTjgyQ", "p":"1r52Xk46c-LsfB5P442p7atdPUrxQSy4mti_tZI3Mgf2EuFVbUoDBvaRQ-SWxkbkmoEzL7JXroSBjSrK3YIQgYdMgyAEPTPjXv_hI2_1eTSPVZfzL0lf fNn03IXqWF5MDFuoUYE0hzb2vhrlN_rKrbfDIwUbTrjjgieRbwC6Cl0", "q":"wLb35x7hmQWZsWJmB_vle87ihgZ19S8lBEROLIsZG4ayZVe9Hi9gDVCOBm UDdaDYVTSNx_8Fyw1YYa9XGrGnDew00J28cRUoeBB_jKI1oma0Orv1T9aX IWxKwd4gvxFImOWr3QRL9KEBRzk2RatUBnmDZJTIAfwTs0g68UZHvtc", "dp":"ZK-YwE7diUh0qR1tR7w8WHtolDx3MZ_OTowiFvgfeQ3SiresXjm9gZ5KL hMXvo-uz-KUJWDxS5pFQ_M0evdo1dKiRTjVw_x4NyqyXPM5nULPkcpU827 rnpZzAJKpdhWAgqrXGKAECQH0Xt4taznjnd_zVpAmZZq60WPMBMfKcuE", "dq":"Dq0gfgJ1DdFGXiLvQEZnuKEN0UUmsJBxkjydc3j4ZYdBiMRAy86x0vHCj ywcMlYYg4yoC4YZa9hNVcsjqA3FeiL19rk8g6Qn29Tt0cj8qqyFpz9vNDB UfCAiJVeESOjJDZPYHdHY8v1b-o-Z2X5tvLx-TCekf7oxyeKDUqKWjis", "qi":"VIMpMYbPf47dT1w_zDUXfPimsSegnMOA1zTaX7aGk_8urY6R8-ZW1FxU7 AlWAyLWybqq6t16VFd7hQd0y6flUK4SlOydB61gwanOsXGOAOv82cHq0E3 eL4HrtZkUuKvnPrMnsUUFlfUdybVzxyjz9JF_XyaY14ardLSjf4L_FNY" }
{ "KTY"： "RSA"、 "N"： "oahUIoWw0K0usKNuOR6H4wkf4oBUXHTxRvgb48E-BVvxkeDNjbC4he8rUW cJoZmds2h7M70imEVhRU5djINXtqllXI4DFqcI1DgjT9LewND8MW2Krf3S psk_ZkoFnilakGygTwpZ3uesH-PFABNIUYpOiN15dsQRkgr0vEhxN92i2a sbOenSZeyaxziK72UwxrrKoExv6kc5twXTq4h-QChLOln0_mtUZwfsRaMS tPs6mS6XrgxnxbWhojf663tuEQueGC-FCMfra36C9knDFGzKsNa7LZK2dj YgyD3JR_MB_4NUJW_TqOQtwHYbxevoJArm-L5StowjzGy-_bq6Gw"、 "E"： "AQAB"、 "D"： "kLdtIj6GbDks_ApCSTYQtelcNttlKiOyPzMrXHeI-yk1F7 -kpDxY4-WY5N WV5KntaEeXS1j82E375xxhWMHXyvjYecPT9fpwR_M9gV8n9Hrh2anTpTD9 3Dt62ypW3yDsJzBnTnrYu1iwWRgBKrEYY46qAZIrA2xAwnm2X7uGR1hghk qDp0Vqj3kbSCz1XyfCs6_LehBwtxHIyh8Ripy40p24moOAbgxVw3rxT_vl t3UVe4WO3JkJOzlpUf-KTVI2Ptgm-dARxTEtE-ID-4OJr0h-K-VFs3VSnd VTIznSxfyrj8ILL6MG_Uv8YAu7VILSB3lOW085-4qE3DzgrTjgyQ " "P"： "1r52Xk46c-LsfB5P442p7atdPUrxQSy4mti_tZI3Mgf2EuFVbUoDBvaRQ-SWxkbkmoEzL7JXroSBjSrK3YIQgYdMgyAEPTPjXv_hI2_1eTSPVZfzL0lf fNn03IXqWF5MDFuoUYE0hzb2vhrlN_rKrbfDIwUbTrjjgieRbwC6Cl0"、 "Q"：" wLb35x7hmQWZsWJmB_vle87ihgZ19S8lBEROLIsZG4ayZVe9Hi9gDVCOBm UDdaDYVTSNx_8Fyw1YYa 9XGrGnDew00J28cRUoeBB_jKI1oma0Orv1T9aX IWxKwd4gvxFImOWr3QRL9KEBRzk2RatUBnmDZJTIAfwTs0g68UZHvtc」、 "DP"： "ZK-YwE7diUh0qR1tR7w8WHtolDx3MZ_OTowiFvgfeQ3SiresXjm9gZ5KL hMXvo-UZ-KUJWDxS5pFQ_M0evdo1dKiRTjVw_x4NyqyXPM5nULPkcpU827 rnpZzAJKpdhWAgqrXGKAECQH0Xt4taznjnd_zVpAmZZq60WPMBMfKcuE"、 "DQ"： "Dq0gfgJ1DdFGXiLvQEZnuKEN0UUmsJBxkjydc3j4ZYdBiMRAy86x0vHCj ywcMlYYg4yoC4YZa9hNVcsjqA3FeiL19rk8g6Qn29Tt0cj8qqyFpz9vNDB UfCAiJVeESOjJDZPYHdHY8v1b-O- Z2X5tvLx-TCekf7oxyeKDUqKWjis"、 "チー"： "VIMpMYbPf47dT1w_zDUXfPimsSegnMOA1zTaX7aGk_8urY6R8-ZW1FxU7 AlWAyLWybqq6t16VFd7hQd0y6flUK4SlOydB61gwanOsXGOAOv82cHq0E3 eL4HrtZkUuKvnPrMnsUUFlfUdybVzxyjz9JF_XyaY14ardLSjf4L_FNY"}
The resulting JWE Encrypted Key value is:
結果のJWE暗号化キーの値は次のとおりです。
[56, 163, 154, 192, 58, 53, 222, 4, 105, 218, 136, 218, 29, 94, 203, 22, 150, 92, 129, 94, 211, 232, 53, 89, 41, 60, 138, 56, 196, 216, 82, 98, 168, 76, 37, 73, 70, 7, 36, 8, 191, 100, 136, 196, 244, 220, 145, 158, 138, 155, 4, 117, 141, 230, 199, 247, 173, 45, 182, 214, 74, 177, 107, 211, 153, 11, 205, 196, 171, 226, 162, 128, 171, 182, 13, 237, 239, 99, 193, 4, 91, 219, 121, 223, 107, 167, 61, 119, 228, 173, 156, 137, 134, 200, 80, 219, 74, 253, 56, 185, 91, 177, 34, 158, 89, 154, 205, 96, 55, 18, 138, 43, 96, 218, 215, 128, 124, 75, 138, 243, 85, 25, 109, 117, 140, 26, 155, 249, 67, 167, 149, 231, 100, 6, 41, 65, 214, 251, 232, 87, 72, 40, 182, 149, 154, 168, 31, 193, 126, 215, 89, 28, 111, 219, 125, 182, 139, 235, 195, 197, 23, 234, 55, 58, 63, 180, 68, 202, 206, 149, 75, 205, 248, 176, 67, 39, 178, 60, 98, 193, 32, 238, 122, 96, 158, 222, 57, 183, 111, 210, 55, 188, 215, 206, 180, 166, 150, 166, 106, 250, 55, 229, 72, 40, 69, 214, 216, 104, 23, 40, 135, 212, 28, 127, 41, 80, 175, 174, 168, 115, 171, 197, 89, 116, 92, 103, 246, 83, 216, 182, 176, 84, 37, 147, 35, 45, 219, 172, 99, 226, 233, 73, 37, 124, 42, 72, 49, 242, 35, 127, 184, 134, 117, 114, 135, 206]
[56, 163, 154, 192, 58, 53, 222, 4, 105, 218, 136, 218, 29, 94, 203, 22, 150, 92, 129, 94, 211, 232, 53, 89, 41, 60, 138, 56, 196, 216, 82, 98, 168, 76, 37, 73, 70, 7, 36, 8, 191, 100, 136, 196, 244, 220, 145, 158, 138, 155, 4, 117, 141, 230, 199, 247, 173, 45, 182, 214, 74, 177, 107, 211, 153, 11, 205, 196, 171, 226, 162, 128, 171, 182, 13, 237, 239, 99, 193, 4, 91, 219, 121, 223, 107, 167, 61, 119, 228, 173, 156, 137, 134, 200, 80, 219, 74, 253, 56, 185, 91, 177, 34, 158, 89, 154, 205, 96, 55, 18, 138, 43, 96, 218, 215, 128, 124, 75, 138, 243, 85, 25, 109, 117, 140, 26, 155, 249, 67, 167, 149, 231, 100, 6, 41, 65, 214, 251, 232, 87, 72, 40, 182, 149, 154, 168, 31, 193, 126, 215, 89, 28, 111, 219, 125, 182, 139, 235, 195, 197, 23, 234, 55, 58, 63, 180, 68, 202, 206, 149, 75, 205, 248, 176, 67, 39, 178, 60, 98, 193, 32, 238, 122, 96, 158, 222, 57, 183, 111, 210, 55, 188, 215, 206, 180, 166, 150, 166, 106, 250, 55, 229, 72, 40, 69, 214, 216, 104, 23, 40, 135, 212, 28, 127, 41, 80, 175, 174, 168, 115, 171, 197, 89, 116, 92, 103, 246, 83, 216, 182, 176, 84, 37, 147, 35, 45, 219, 172, 99, 226, 233, 73, 37, 124, 42, 72, 49, 242, 35, 127, 184, 134, 117, 114, 135, 206]
Encoding this JWE Encrypted Key as BASE64URL(JWE Encrypted Key) gives this value (with line breaks for display purposes only):
このJWE暗号化キーをBASE64URL（JWE暗号化キー）としてエンコードすると、次の値が表示されます（表示目的でのみ改行されます）。
OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8 1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi 6UklfCpIMfIjf7iGdXKHzg
OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8 1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi 6UklfCpIMfIjf7iGdXKHzg
Generate a random 96-bit JWE Initialization Vector. In this example, the value is:
ランダムな96ビットJWE初期化ベクトルを生成します。この例では、値は次のとおりです。
[227, 197, 117, 252, 2, 219, 233, 68, 180, 225, 77, 219]
「２２７、 １９７、 １１７、 ２５２、 ２、 ２１９、 ２３３、 ６８、 １８０、 ２２５、 ７７、 ２１９」
Encoding this JWE Initialization Vector as BASE64URL(JWE Initialization Vector) gives this value:
このJWE初期化ベクトルをBASE64URL（JWE初期化ベクトル）としてエンコードすると、次の値が得られます。
48V1_ALb6US04U3b
48V1_ALb6US04U3b
Let the Additional Authenticated Data encryption parameter be ASCII(BASE64URL(UTF8(JWE Protected Header))). This value is:
追加認証データ暗号化パラメーターをASCII（BASE64URL（UTF8（JWE Protected Header）））にします。この値は次のとおりです。
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73, 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 102, 81]
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73, 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 102, 81]
Perform authenticated encryption on the plaintext with the AES GCM algorithm using the CEK as the encryption key, the JWE Initialization Vector, and the Additional Authenticated Data value above, requesting a 128-bit Authentication Tag output. The resulting ciphertext is:
暗号化キーとしてCEK、JWE初期化ベクトル、および上記の追加認証データ値を使用してAES GCMアルゴリズムでプレーンテキストに対して認証済み暗号化を実行し、128ビット認証タグ出力を要求します。結果の暗号文は次のとおりです。
[229, 236, 166, 241, 53, 191, 115, 196, 174, 43, 73, 109, 39, 122, 233, 96, 140, 206, 120, 52, 51, 237, 48, 11, 190, 219, 186, 80, 111, 104, 50, 142, 47, 167, 59, 61, 181, 127, 196, 21, 40, 82, 242, 32, 123, 143, 168, 226, 73, 216, 176, 144, 138, 247, 106, 60, 16, 205, 160, 109, 64, 63, 192]
[229, 236, 166, 241, 53, 191, 115, 196, 174, 43, 73, 109, 39, 122, 233, 96, 140, 206, 120, 52, 51, 237, 48, 11, 190, 219, 186, 80, 111, 104, 50, 142, 47, 167, 59, 61, 181, 127, 196, 21, 40, 82, 242, 32, 123, 143, 168, 226, 73, 216, 176, 144, 138, 247, 106, 60, 16, 205, 160, 109, 64, 63, 192]
The resulting Authentication Tag value is:
結果の認証タグ値は次のとおりです。
[92, 80, 104, 49, 133, 25, 161, 215, 173, 101, 219, 211, 136, 91, 210, 145]
「９２、 ８０、 １０４、 ４９、 １３３、 ２５、 １６１、 ２１５、 １７３、 １０１、 ２１９、 ２１１、 １３６、 ９１、 ２１０、 １４５」
Encoding this JWE Ciphertext as BASE64URL(JWE Ciphertext) gives this value (with line breaks for display purposes only):
このJWE暗号文をBASE64URL（JWE暗号文）としてエンコードすると、次の値が得られます（表示目的でのみ改行が含まれます）。
5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji SdiwkIr3ajwQzaBtQD_A
5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji SdiwkIr3ajwQzaBtQD_A
Encoding this JWE Authentication Tag as BASE64URL(JWE Authentication Tag) gives this value:
このJWE認証タグをBASE64URL（JWE認証タグ）としてエンコードすると、次の値が得られます。
XFBoMYUZodetZdvTiFvSkQ
Ксфбомюзодецдвитифвскя
Assemble the final representation: The Compact Serialization of this result is the string BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag).
最終的な表現を組み立てます。この結果のコンパクトなシリアル化は、文字列BASE64URL（UTF8（JWE Protected Header））です|| 「。」 || BASE64URL（JWE暗号化キー）|| 「。」 || BASE64URL（JWE初期化ベクトル）|| 「。」 || BASE64URL（JWE暗号文）|| 「。」 || BASE64URL（JWE認証タグ）。
The final result in this example (with line breaks for display purposes only) is:
この例の最終的な結果（表示目的のみの改行あり）は次のとおりです。
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ. OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8 1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi 6UklfCpIMfIjf7iGdXKHzg. 48V1_ALb6US04U3b. 5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji SdiwkIr3ajwQzaBtQD_A. XFBoMYUZodetZdvTiFvSkQ
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ。 OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8 1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi 6UklfCpIMfIjf7iGdXKHzg。 48V1_ALb6US04U3b。 5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji SdiwkIr3ajwQzaBtQD_A。 XFBoMYUZodetZdvTiFvSkQ
This example illustrates the process of creating a JWE with RSAES-OAEP for key encryption and AES GCM for content encryption. These results can be used to validate JWE decryption implementations for these algorithms. Note that since the RSAES-OAEP computation includes random values, the encryption results above will not be completely reproducible. However, since the AES GCM computation is deterministic, the JWE Encrypted Ciphertext values will be the same for all encryptions performed using these inputs.
この例は、鍵の暗号化にはRSAES-OAEPを、コンテンツの暗号化にはAES GCMを使用してJWEを作成するプロセスを示しています。これらの結果を使用して、これらのアルゴリズムのJWE復号化実装を検証できます。 RSAES-OAEPの計算にはランダムな値が含まれるため、上記の暗号化の結果は完全に再現可能ではないことに注意してください。ただし、AES GCMの計算は確定的であるため、JWE暗号化暗号文の値は、これらの入力を使用して実行されるすべての暗号化で同じになります。
This example encrypts the plaintext "Live long and prosper." to the recipient using RSAES-PKCS1-v1_5 for key encryption and AES_128_CBC_HMAC_SHA_256 for content encryption. The representation of this plaintext (using JSON array notation) is:
この例では、「長く生きて繁栄する」という平文を暗号化します。キーの暗号化にはRSAES-PKCS1-v1_5を使用し、コンテンツの暗号化にはAES_128_CBC_HMAC_SHA_256を使用して受信者に送信します。このプレーンテキストの表現（JSON配列表記を使用）は次のとおりです。
[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46]
「７６、 １０５、 １１８、 １０１、 ３２、 １０８、 １１１、 １１０、 １０３、 ３２、 ９７、 １１０、 １００、 ３２、 １１２、 １１４、 １１１、 １１５、 １１２、 １０１、 １１４、 ４６」
The following example JWE Protected Header declares that:
次の例のJWE保護ヘッダーは、それを宣言しています。
o The Content Encryption Key is encrypted to the recipient using the RSAES-PKCS1-v1_5 algorithm to produce the JWE Encrypted Key. o Authenticated encryption is performed on the plaintext using the AES_128_CBC_HMAC_SHA_256 algorithm to produce the ciphertext and the Authentication Tag.
o コンテンツ暗号化キーは、RSAES-PKCS1-v1_5アルゴリズムを使用して受信者に対して暗号化され、JWE暗号化キーが生成されます。 o AES_128_CBC_HMAC_SHA_256アルゴリズムを使用して平文に対して認証された暗号化が実行され、暗号文と認証タグが生成されます。
{"alg":"RSA1_5","enc":"A128CBC-HS256"}
Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected Header)) gives this value:
このJWE保護ヘッダーをBASE64URL（UTF8（JWE保護ヘッダー））としてエンコードすると、次の値が得られます。
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
Generate a 256-bit random CEK. In this example, the key value is:
256ビットのランダムCEKを生成します。この例では、キー値は次のとおりです。
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44, 207]
「４、 ２１１、 ３１、 １９７、 ８４、 １５７、 ２５２、 ２５４、 １１、 １００、 １５７、 ２５０、 ６３、 １７０、 １０６、 ２０６、 １０７、 １２４、 ２１２、 ４５、 １１１、 １０７、 ９、 ２１９、 ２００、 １７７、 ０、 ２４０、 １４３、 １５６、 ４４、 ２０７」
Encrypt the CEK with the recipient's public key using the RSAES-PKCS1-v1_5 algorithm to produce the JWE Encrypted Key. This example uses the RSA key represented in JSON Web Key [JWK] format below (with line breaks within values for display purposes only):
RSAES-PKCS1-v1_5アルゴリズムを使用して受信者の公開鍵でCEKを暗号化し、JWE暗号化鍵を生成します。この例では、以下のJSON Web Key [JWK]形式で表されたRSAキーを使用します（表示目的でのみ値内に改行を入れます）。
{"kty":"RSA", "n":"sXchDaQebHnPiGvyDOAT4saGEUetSyo9MKLOoWFsueri23bOdgWp4Dy1Wl UzewbgBHod5pcM9H95GQRV3JDXboIRROSBigeC5yjU1hGzHHyXss8UDpre cbAYxknTcQkhslANGRUZmdTOQ5qTRsLAt6BTYuyvVRdhS8exSZEy_c4gs_ 7svlJJQ4H9_NxsiIoLwAEk7-Q3UXERGYw_75IDrGA84-lA_-Ct4eTlXHBI Y2EaV7t7LjJaynVJCpkv4LKjTTAumiGUIuQhrNhZLuF_RJLqHpM2kgWFLU 7-VTdL1VbC2tejvcI2BlMkEpk1BzBZI0KQB0GaDWFLN-aEAw3vRw", "e":"AQAB", "d":"VFCWOqXr8nvZNyaaJLXdnNPXZKRaWCjkU5Q2egQQpTBMwhprMzWzpR8Sxq 1OPThh_J6MUD8Z35wky9b8eEO0pwNS8xlh1lOFRRBoNqDIKVOku0aZb-ry nq8cxjDTLZQ6Fz7jSjR1Klop-YKaUHc9GsEofQqYruPhzSA-QgajZGPbE_ 0ZaVDJHfyd7UUBUKunFMScbflYAAOYJqVIVwaYR5zWEEceUjNnTNo_CVSj -VvXLO5VZfCUAVLgW4dpf1SrtZjSt34YLsRarSb127reG_DUwg9Ch-Kyvj T1SkHgUWRVGcyly7uvVGRSDwsXypdrNinPA4jlhoNdizK2zF2CWQ", "p":"9gY2w6I6S6L0juEKsbeDAwpd9WMfgqFoeA9vEyEUuk4kLwBKcoe1x4HG68 ik918hdDSE9vDQSccA3xXHOAFOPJ8R9EeIAbTi1VwBYnbTp87X-xcPWlEP krdoUKW60tgs1aNd_Nnc9LEVVPMS390zbFxt8TN_biaBgelNgbC95sM", "q":"uKlCKvKv_ZJMVcdIs5vVSU_6cPtYI1ljWytExV_skstvRSNi9r66jdd9-y BhVfuG4shsp2j7rGnIio901RBeHo6TPKWVVykPu1iYhQXw1jIABfw-MVsN -3bQ76WLdt2SDxsHs7q7zPyUyHXmps7ycZ5c72wGkUwNOjYelmkiNS0", "dp":"w0kZbV63cVRvVX6yk3C8cMxo2qCM4Y8nsq1lmMSYhG4EcL6FWbX5h9yuv ngs4iLEFk6eALoUS4vIWEwcL4txw9LsWH_zKI-hwoReoP77cOdSL4AVcra Hawlkpyd2TWjE5evgbhWtOxnZee3cXJBkAi64Ik6jZxbvk-RR3pEhnCs", "dq":"o_8V14SezckO6CNLKs_btPdFiO9_kC1DsuUTd2LAfIIVeMZ7jn1Gus_Ff 7B7IVx3p5KuBGOVF8L-qifLb6nQnLysgHDh132NDioZkhH7mI7hPG-PYE_ odApKdnqECHWw0J-F0JWnUd6D2B_1TvF9mXA2Qx-iGYn8OVV1Bsmp6qU", "qi":"eNho5yRBEBxhGBtQRww9QirZsB66TrfFReG_CcteI1aCneT0ELGhYlRlC tUkTRclIfuEPmNsNDPbLoLqqCVznFbvdB7x-Tl-m0l_eFTj2KiqwGqE9PZ B9nNTwMVvH3VRRSLWACvPnSiwP8N5Usy-WRXS-V7TbpxIhvepTfE0NNo" }
{ "KTY"： "RSA"、 "N"： "sXchDaQebHnPiGvyDOAT4saGEUetSyo9MKLOoWFsueri23bOdgWp4Dy1Wl UzewbgBHod5pcM9H95GQRV3JDXboIRROSBigeC5yjU1hGzHHyXss8UDpre cbAYxknTcQkhslANGRUZmdTOQ5qTRsLAt6BTYuyvVRdhS8exSZEy_c4gs_ 7svlJJQ4H9_NxsiIoLwAEk7-Q3UXERGYw_75IDrGA84-lA_-Ct4eTlXHBI Y2EaV7t7LjJaynVJCpkv4LKjTTAumiGUIuQhrNhZLuF_RJLqHpM2kgWFLU -7- VTdL1VbC2tejvcI2BlMkEpk1BzBZI0KQB0GaDWFLN-aEAw3vRw"、 "E"： "AQAB"、 "D"： "VFCWOqXr8nvZNyaaJLXdnNPXZKRaWCjkU5Q2egQQpTBMwhprMzWzpR8Sxq 1OPThh_J6MUD8Z35wky9b8eEO0pwNS8xlh1lOFRRBoNqDIKVOku0aZb-RY nq8cxjDTLZQ6Fz7jSjR1Klop -YKaUHc9GsEofQqYruPhzSA-QgajZGPbE_ 0ZaVDJHfyd7UUBUKunFMScbflYAAOYJqVIVwaYR5zWEEceUjNnTNo_CVSj -VvXLO5VZfCUAVLgW4dpf1SrtZjSt34YLsRarSb127reG_DUwg9Ch-Kyvj T1SkHgUWRVGcyly7uvVGRSDwsXypdrNinPA4jlhoNdizK2zF2CWQ " "P"： "9gY2w6I6S6L0juEKsbeDAwpd9WMfgqFoeA9vEyEUuk4kLwBKcoe1x4HG68 ik918hdDSE9vDQSccA3xXHOAFOPJ8R9EeIAbTi1VwBYnbTp87X-xcPWlEP krdoUKW60tgs1aNd_Nnc9LEVVPMS390zbFxt8TN_biaBgelNgbC95sM"、 "Q"：" uKlCKvKv_ZJMVcdIs5vVSU_6cPtYI1ljWytExV_skstvRSNi9r66jdd9-Y BhVfuG4shsp2j7rGnIi o901RBeHo6TPKWVVykPu1iYhQXw1jIABfw-MVsN -3bQ76WLdt2SDxsHs7q7zPyUyHXmps7ycZ5c72wGkUwNOjYelmkiNS0" 、 "DP"： "w0kZbV63cVRvVX6yk3C8cMxo2qCM4Y8nsq1lmMSYhG4EcL6FWbX5h9yuv ngs4iLEFk6eALoUS4vIWEwcL4txw9LsWH_zKI-hwoReoP77cOdSL4AVcra Hawlkpyd2TWjE5evgbhWtOxnZee3cXJBkAi64Ik6jZxbvk-RR3pEhnCs"、 "DQ"： "o_8V14SezckO6CNLKs_btPdFiO9_kC1DsuUTd2LAfIIVeMZ7jn1Gus_Ff 7B7IVx3p5KuBGOVF8L-qifLb6nQnLysgHDh132NDioZkhH7mI7hPG-PYE_ odApKdnqECHWw0J-F0JWnUd6D2B_1TvF9mXA2Qx-iGYn8OVV1Bsmp6qU"、 "気"： "eNho5yRBEBxhGBtQRww9QirZsB66TrfFReG_CcteI1aCneT0ELGhYlRlC tUkTRclIfuEPmNsNDPbLoLqqCVznFbvdB7x-TL-m0l_eFTj2KiqwGqE9PZ B9nNTwMVvH3VRRSLWACvPnSiwP8N5Usy-WRXS-V7TbpxIhvepTfE0NNo "}
The resulting JWE Encrypted Key value is:
結果のJWE暗号化キーの値は次のとおりです。
[80, 104, 72, 58, 11, 130, 236, 139, 132, 189, 255, 205, 61, 86, 151, 176, 99, 40, 44, 233, 176, 189, 205, 70, 202, 169, 72, 40, 226, 181, 156, 223, 120, 156, 115, 232, 150, 209, 145, 133, 104, 112, 237, 156, 116, 250, 65, 102, 212, 210, 103, 240, 177, 61, 93, 40, 71, 231, 223, 226, 240, 157, 15, 31, 150, 89, 200, 215, 198, 203, 108, 70, 117, 66, 212, 238, 193, 205, 23, 161, 169, 218, 243, 203, 128, 214, 127, 253, 215, 139, 43, 17, 135, 103, 179, 220, 28, 2, 212, 206, 131, 158, 128, 66, 62, 240, 78, 186, 141, 125, 132, 227, 60, 137, 43, 31, 152, 199, 54, 72, 34, 212, 115, 11, 152, 101, 70, 42, 219, 233, 142, 66, 151, 250, 126, 146, 141, 216, 190, 73, 50, 177, 146, 5, 52, 247, 28, 197, 21, 59, 170, 247, 181, 89, 131, 241, 169, 182, 246, 99, 15, 36, 102, 166, 182, 172, 197, 136, 230, 120, 60, 58, 219, 243, 149, 94, 222, 150, 154, 194, 110, 227, 225, 112, 39, 89, 233, 112, 207, 211, 241, 124, 174, 69, 221, 179, 107, 196, 225, 127, 167, 112, 226, 12, 242, 16, 24, 28, 120, 182, 244, 213, 244, 153, 194, 162, 69, 160, 244, 248, 63, 165, 141, 4, 207, 249, 193, 79, 131, 0, 169, 233, 127, 167, 101, 151, 125, 56, 112, 111, 248, 29, 232, 90, 29, 147, 110, 169, 146, 114, 165, 204, 71, 136, 41, 252]
[80, 104, 72, 58, 11, 130, 236, 139, 132, 189, 255, 205, 61, 86, 151, 176, 99, 40, 44, 233, 176, 189, 205, 70, 202, 169, 72, 40, 226, 181, 156, 223, 120, 156, 115, 232, 150, 209, 145, 133, 104, 112, 237, 156, 116, 250, 65, 102, 212, 210, 103, 240, 177, 61, 93, 40, 71, 231, 223, 226, 240, 157, 15, 31, 150, 89, 200, 215, 198, 203, 108, 70, 117, 66, 212, 238, 193, 205, 23, 161, 169, 218, 243, 203, 128, 214, 127, 253, 215, 139, 43, 17, 135, 103, 179, 220, 28, 2, 212, 206, 131, 158, 128, 66, 62, 240, 78, 186, 141, 125, 132, 227, 60, 137, 43, 31, 152, 199, 54, 72, 34, 212, 115, 11, 152, 101, 70, 42, 219, 233, 142, 66, 151, 250, 126, 146, 141, 216, 190, 73, 50, 177, 146, 5, 52, 247, 28, 197, 21, 59, 170, 247, 181, 89, 131, 241, 169, 182, 246, 99, 15, 36, 102, 166, 182, 172, 197, 136, 230, 120, 60, 58, 219, 243, 149, 94, 222, 150, 154, 194, 110, 227, 225, 112, 39, 89, 233, 112, 207, 211, 241, 124, 174, 69, 221, 179, 107, 196, 225, 127, 167, 112, 226, 12, 242, 16, 24, 28, 120, 182, 244, 213, 244, 153, 194, 162, 69, 160, 244, 248, 63, 165, 141, 4, 207, 249, 193, 79, 131, 0, 169, 233, 127, 167, 101, 151, 125, 56, 112, 111, 248, 29, 232, 90, 29, 147, 110, 169, 146, 114, 165, 204, 71, 136, 41, 252]
Encoding this JWE Encrypted Key as BASE64URL(JWE Encrypted Key) gives this value (with line breaks for display purposes only):
このJWE暗号化キーをBASE64URL（JWE暗号化キー）としてエンコードすると、次の値が表示されます（表示目的でのみ改行されます）。
UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-kFm
1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKxGHZ7Pc
HALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3YvkkysZIF
NPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPhcCdZ6XDP0_F8
rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPgwCp6X-nZZd9OHBv
-B3oWh2TbqmScqXMR4gp_A
Generate a random 128-bit JWE Initialization Vector. In this example, the value is:
ランダムな128ビットのJWE初期化ベクトルを生成します。この例では、値は次のとおりです。
[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, 101]
「３、 ２２、 ６０、 １２、 ４３、 ６７、 １０４、 １０５、 １０８、 １０８、 １０５、 ９９、 １１１、 １１６、 １０４、 １０１」
Encoding this JWE Initialization Vector as BASE64URL(JWE Initialization Vector) gives this value:
このJWE初期化ベクトルをBASE64URL（JWE初期化ベクトル）としてエンコードすると、次の値が得られます。
AxY8DCtDaGlsbGljb3RoZQ
AxY8DCtDaGlsbGljb3RoZQ
Let the Additional Authenticated Data encryption parameter be ASCII(BASE64URL(UTF8(JWE Protected Header))). This value is:
追加認証データ暗号化パラメーターをASCII（BASE64URL（UTF8（JWE Protected Header）））にします。この値は次のとおりです。
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 120, 88, 122, 85, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48]
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 120, 88, 122, 85, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48]
Perform authenticated encryption on the plaintext with the AES_128_CBC_HMAC_SHA_256 algorithm using the CEK as the encryption key, the JWE Initialization Vector, and the Additional Authenticated Data value above. The steps for doing this using the values from Appendix A.3 are detailed in Appendix B. The resulting ciphertext is:
暗号化キーとしてCEK、JWE初期化ベクトル、および上記の追加認証データ値を使用して、AES_128_CBC_HMAC_SHA_256アルゴリズムでプレーンテキストに対して認証済み暗号化を実行します。付録A.3の値を使用してこれを行う手順については、付録Bで詳しく説明します。結果の暗号文は次のとおりです。
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143, 112, 56, 102]
「４０、 ５７、 ８３、 １８１、 １１９、 ３３、 １３３、 １４８、 １９８、 １８５、 ２４３、 ２４、 １５２、 ２３０、 ６、 ７５、 １２９、 ２２３、 １２７、 １９、 ２１０、 ８２、 １８３、 ２３０、 １６８、 ３３、 ２１５、 １０４、 １４３、 １１２、 ５６、 １０２」
The resulting Authentication Tag value is:
結果の認証タグ値は次のとおりです。
[246, 17, 244, 190, 4, 95, 98, 3, 231, 0, 115, 157, 242, 203, 100, 191]
「２４６、 １７、 ２４４、 １９０、 ４、 ９５、 ９８、 ３、 ２３１、 ０、 １１５、 １５７、 ２４２、 ２０３、 １００、 １９１」
Encoding this JWE Ciphertext as BASE64URL(JWE Ciphertext) gives this value:
このJWE暗号文をBASE64URL（JWE暗号文）としてエンコードすると、次の値が得られます。
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
Encoding this JWE Authentication Tag as BASE64URL(JWE Authentication Tag) gives this value:
このJWE認証タグをBASE64URL（JWE認証タグ）としてエンコードすると、次の値が得られます。
9hH0vgRfYgPnAHOd8stkvw
9hH0vgRfYgPnAHOd8stkvw
Assemble the final representation: The Compact Serialization of this result is the string BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag).
最終的な表現を組み立てます。この結果のコンパクトなシリアル化は、文字列BASE64URL（UTF8（JWE Protected Header））です|| 「。」 || BASE64URL（JWE暗号化キー）|| 「。」 || BASE64URL（JWE初期化ベクトル）|| 「。」 || BASE64URL（JWE暗号文）|| 「。」 || BASE64URL（JWE認証タグ）。
The final result in this example (with line breaks for display purposes only) is:
この例の最終的な結果（表示目的のみの改行あり）は次のとおりです。
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.
UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-kFm
1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKxGHZ7Pc
HALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3YvkkysZIF
NPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPhcCdZ6XDP0_F8
rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPgwCp6X-nZZd9OHBv
-B3oWh2TbqmScqXMR4gp_A.
AxY8DCtDaGlsbGljb3RoZQ.
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.
9hH0vgRfYgPnAHOd8stkvw
This example illustrates the process of creating a JWE with RSAES-PKCS1-v1_5 for key encryption and AES_CBC_HMAC_SHA2 for content encryption. These results can be used to validate JWE decryption implementations for these algorithms. Note that since the RSAES-PKCS1-v1_5 computation includes random values, the encryption results above will not be completely reproducible. However, since the AES-CBC computation is deterministic, the JWE Encrypted Ciphertext values will be the same for all encryptions performed using these inputs.
この例は、キー暗号化用のRSAES-PKCS1-v1_5とコンテンツ暗号化用のAES_CBC_HMAC_SHA2を使用してJWEを作成するプロセスを示しています。これらの結果を使用して、これらのアルゴリズムのJWE復号化実装を検証できます。 RSAES-PKCS1-v1_5の計算にはランダムな値が含まれるため、上記の暗号化の結果は完全に再現可能ではないことに注意してください。ただし、AES-CBCの計算は確定的であるため、JWE暗号化暗号文の値は、これらの入力を使用して実行されるすべての暗号化で同じになります。
This example encrypts the plaintext "Live long and prosper." to the recipient using AES Key Wrap for key encryption and AES_128_CBC_HMAC_SHA_256 for content encryption. The representation of this plaintext (using JSON array notation) is:
この例では、「長く生きて繁栄する」という平文を暗号化します。キーの暗号化にはAESキーラップを使用し、コンテンツの暗号化にはAES_128_CBC_HMAC_SHA_256を使用して受信者に送信します。このプレーンテキストの表現（JSON配列表記を使用）は次のとおりです。
[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46]
「７６、 １０５、 １１８、 １０１、 ３２、 １０８、 １１１、 １１０、 １０３、 ３２、 ９７、 １１０、 １００、 ３２、 １１２、 １１４、 １１１、 １１５、 １１２、 １０１、 １１４、 ４６」
The following example JWE Protected Header declares that:
次の例のJWE保護ヘッダーは、それを宣言しています。
o The Content Encryption Key is encrypted to the recipient using the AES Key Wrap algorithm with a 128-bit key to produce the JWE Encrypted Key. o Authenticated encryption is performed on the plaintext using the AES_128_CBC_HMAC_SHA_256 algorithm to produce the ciphertext and the Authentication Tag.
o コンテンツ暗号化キーは、AESキーラップアルゴリズムと128ビットキーを使用して受信者に対して暗号化され、JWE暗号化キーが生成されます。 o AES_128_CBC_HMAC_SHA_256アルゴリズムを使用して平文に対して認証された暗号化が実行され、暗号文と認証タグが生成されます。
{"alg":"A128KW","enc":"A128CBC-HS256"}
Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected Header)) gives this value:
このJWE保護ヘッダーをBASE64URL（UTF8（JWE保護ヘッダー））としてエンコードすると、次の値が得られます。
eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
Generate a 256-bit random CEK. In this example, the value is:
256ビットのランダムCEKを生成します。この例では、値は次のとおりです。
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44, 207]
「４、 ２１１、 ３１、 １９７、 ８４、 １５７、 ２５２、 ２５４、 １１、 １００、 １５７、 ２５０、 ６３、 １７０、 １０６、 ２０６、 １０７、 １２４、 ２１２、 ４５、 １１１、 １０７、 ９、 ２１９、 ２００、 １７７、 ０、 ２４０、 １４３、 １５６、 ４４、 ２０７」
Encrypt the CEK with the shared symmetric key using the AES Key Wrap algorithm to produce the JWE Encrypted Key. This example uses the symmetric key represented in JSON Web Key [JWK] format below:
AESキーラップアルゴリズムを使用して共有対称キーでCEKを暗号化し、JWE暗号化キーを生成します。この例では、以下のJSON Web Key [JWK]形式で表される対称鍵を使用しています。
{"kty":"oct", "k":"GawgguFyGrWKav7AX4VKUg" }
{"kty"： "oct"、 "k"： "GawgguFyGrWKav7AX4VKUg"}
The resulting JWE Encrypted Key value is:
結果のJWE暗号化キーの値は次のとおりです。
[232, 160, 123, 211, 183, 76, 245, 132, 200, 128, 123, 75, 190, 216, 22, 67, 201, 138, 193, 186, 9, 91, 122, 31, 246, 90, 28, 139, 57, 3, 76, 124, 193, 11, 98, 37, 173, 61, 104, 57]
[232, 160, 123, 211, 183, 76, 245, 132, 200, 128, 123, 75, 190, 216, 22, 67, 201, 138, 193, 186, 9, 91, 122, 31, 246, 90, 28, 139, 57, 3, 76, 124, 193, 11, 98, 37, 173, 61, 104, 57]
Encoding this JWE Encrypted Key as BASE64URL(JWE Encrypted Key) gives this value:
このJWE暗号化キーをBASE64URL（JWE暗号化キー）としてエンコードすると、次の値が得られます。
6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ
Generate a random 128-bit JWE Initialization Vector. In this example, the value is:
ランダムな128ビットのJWE初期化ベクトルを生成します。この例では、値は次のとおりです。
[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, 101]
「３、 ２２、 ６０、 １２、 ４３、 ６７、 １０４、 １０５、 １０８、 １０８、 １０５、 ９９、 １１１、 １１６、 １０４、 １０１」
Encoding this JWE Initialization Vector as BASE64URL(JWE Initialization Vector) gives this value:
このJWE初期化ベクトルをBASE64URL（JWE初期化ベクトル）としてエンコードすると、次の値が得られます。
AxY8DCtDaGlsbGljb3RoZQ
AxY8DCtDaGlsbGljb3RoZQ
Let the Additional Authenticated Data encryption parameter be ASCII(BASE64URL(UTF8(JWE Protected Header))). This value is:
追加認証データ暗号化パラメーターをASCII（BASE64URL（UTF8（JWE Protected Header）））にします。この値は次のとおりです。
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52, 83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48]
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52, 83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48]
Perform authenticated encryption on the plaintext with the AES_128_CBC_HMAC_SHA_256 algorithm using the CEK as the encryption key, the JWE Initialization Vector, and the Additional Authenticated Data value above. The steps for doing this using the values from this example are detailed in Appendix B. The resulting ciphertext is:
暗号化キーとしてCEK、JWE初期化ベクトル、および上記の追加認証データ値を使用して、AES_128_CBC_HMAC_SHA_256アルゴリズムでプレーンテキストに対して認証済み暗号化を実行します。この例の値を使用してこれを行う手順の詳細は、付録Bにあります。結果の暗号文は次のとおりです。
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143, 112, 56, 102]
「４０、 ５７、 ８３、 １８１、 １１９、 ３３、 １３３、 １４８、 １９８、 １８５、 ２４３、 ２４、 １５２、 ２３０、 ６、 ７５、 １２９、 ２２３、 １２７、 １９、 ２１０、 ８２、 １８３、 ２３０、 １６８、 ３３、 ２１５、 １０４、 １４３、 １１２、 ５６、 １０２」
The resulting Authentication Tag value is:
結果の認証タグ値は次のとおりです。
[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38, 194, 85]
「８３、 ７３、 １９１、 ９８、 １０４、 ２０５、 ２１１、 １２８、 ２０１、 １８９、 １９９、 １３３、 ３２、 ３８、 １９４、 ８５」
Encoding this JWE Ciphertext as BASE64URL(JWE Ciphertext) gives this value:
このJWE暗号文をBASE64URL（JWE暗号文）としてエンコードすると、次の値が得られます。
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
Encoding this JWE Authentication Tag as BASE64URL(JWE Authentication Tag) gives this value:
このJWE認証タグをBASE64URL（JWE認証タグ）としてエンコードすると、次の値が得られます。
U0m_YmjN04DJvceFICbCVQ
U0m_YmjN04DJvceFICbCVQ
Assemble the final representation: The Compact Serialization of this result is the string BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag).
最終的な表現を組み立てます。この結果のコンパクトなシリアル化は、文字列BASE64URL（UTF8（JWE Protected Header））です|| 「。」 || BASE64URL（JWE暗号化キー）|| 「。」 || BASE64URL（JWE初期化ベクトル）|| 「。」 || BASE64URL（JWE暗号文）|| 「。」 || BASE64URL（JWE認証タグ）。
The final result in this example (with line breaks for display purposes only) is:
この例の最終的な結果（表示目的のみの改行あり）は次のとおりです。
eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0. 6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ. AxY8DCtDaGlsbGljb3RoZQ. KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY. U0m_YmjN04DJvceFICbCVQ
eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0。 6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ。 AxY8DCtDaGlsbGljb3RoZQ。 KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY。 U0m_YmjN04DJvceFICbCVQ
This example illustrates the process of creating a JWE with AES Key Wrap for key encryption and AES GCM for content encryption. These results can be used to validate JWE decryption implementations for these algorithms. Also, since both the AES Key Wrap and AES GCM computations are deterministic, the resulting JWE value will be the same for all encryptions performed using these inputs. Since the computation is reproducible, these results can also be used to validate JWE encryption implementations for these algorithms.
この例は、キー暗号化用のAESキーラップとコンテンツ暗号化用のAES GCMを使用してJWEを作成するプロセスを示しています。これらの結果を使用して、これらのアルゴリズムのJWE復号化実装を検証できます。また、AESキーラップとAES GCMの計算はどちらも確定的であるため、結果として得られるJWE値は、これらの入力を使用して実行されるすべての暗号化で同じになります。計算は再現可能であるため、これらの結果を使用して、これらのアルゴリズムのJWE暗号化実装を検証することもできます。
This section contains an example using the general JWE JSON Serialization syntax. This example demonstrates the capability for encrypting the same plaintext to multiple recipients.
このセクションには、一般的なJWE JSONシリアル化構文を使用した例が含まれています。この例は、複数の受信者に対して同じプレーンテキストを暗号化する機能を示しています。
Two recipients are present in this example. The algorithm and key used for the first recipient are the same as that used in Appendix A.2. The algorithm and key used for the second recipient are the same as that used in Appendix A.3. The resulting JWE Encrypted Key values are therefore the same; those computations are not repeated here.
この例では、2人の受信者が存在しています。最初の受信者に使用されるアルゴリズムとキーは、付録A.2で使用されているものと同じです。 2番目の受信者に使用されるアルゴリズムとキーは、付録A.3で使用されているものと同じです。したがって、結果のJWE暗号化キーの値は同じです。これらの計算はここでは繰り返されません。
The plaintext, the CEK, JWE Initialization Vector, and JWE Protected Header are shared by all recipients (which must be the case, since the ciphertext and Authentication Tag are also shared).
平文、CEK、JWE初期化ベクトル、およびJWE保護ヘッダーは、すべての受信者によって共有されます（暗号文と認証タグも共有されているため、そうである必要があります）。
The first recipient uses the RSAES-PKCS1-v1_5 algorithm to encrypt the CEK. The second uses AES Key Wrap to encrypt the CEK. Key ID values are supplied for both keys. The two JWE Per-Recipient Unprotected Header values used to represent these algorithms and key IDs are:
最初の受信者は、RSAES-PKCS1-v1_5アルゴリズムを使用してCEKを暗号化します。 2つ目は、AESキーラップを使用してCEKを暗号化します。キーID値は両方のキーに提供されます。これらのアルゴリズムとキーIDを表すために使用される2つのJWE Per-Recipient Unprotected Header値は次のとおりです。
{"alg":"RSA1_5","kid":"2011-04-29"}
and
そして
{"alg":"A128KW","kid":"7"}
Authenticated encryption is performed on the plaintext using the AES_128_CBC_HMAC_SHA_256 algorithm to produce the common JWE Ciphertext and JWE Authentication Tag values. The JWE Protected Header value representing this is:
認証された暗号化は、AES_128_CBC_HMAC_SHA_256アルゴリズムを使用して平文で実行され、共通のJWE暗号文とJWE認証タグの値を生成します。これを表すJWE保護ヘッダー値は次のとおりです。
{"enc":"A128CBC-HS256"}
Encoding this JWE Protected Header as BASE64URL(UTF8(JWE Protected Header)) gives this value:
このJWE保護ヘッダーをBASE64URL（UTF8（JWE保護ヘッダー））としてエンコードすると、次の値が得られます。
eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0
This JWE uses the "jku" Header Parameter to reference a JWK Set. This is represented in the following JWE Shared Unprotected Header value as:
このJWEは、「jku」ヘッダーパラメータを使用してJWKセットを参照します。これは、次のJWE共有非保護ヘッダー値で次のように表されます。
{"jku":"https://server.example.com/keys.jwks"}
Combining the JWE Per-Recipient Unprotected Header, JWE Protected Header, and JWE Shared Unprotected Header values supplied, the JOSE Header values used for the first and second recipient, respectively, are:
提供されたJWE受信者ごとの無保護ヘッダー、JWE保護ヘッダー、およびJWE共有無保護ヘッダー値を組み合わせると、最初と2番目の受信者にそれぞれ使用されるJOSEヘッダー値は次のとおりです。
{"alg":"RSA1_5",
"kid":"2011-04-29",
"enc":"A128CBC-HS256",
"jku":"https://server.example.com/keys.jwks"}
and
そして
{"alg":"A128KW",
"kid":"7",
"enc":"A128CBC-HS256",
"jku":"https://server.example.com/keys.jwks"}
Let the Additional Authenticated Data encryption parameter be ASCII(BASE64URL(UTF8(JWE Protected Header))). This value is:
追加認証データ暗号化パラメーターをASCII（BASE64URL（UTF8（JWE Protected Header）））にします。この値は次のとおりです。
[101, 121, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48]
「１０１、 １２１、 ７４、 １０８、 ９８、 １０９、 ７７、 １０５、 ７９、 １０５、 ７４、 ６６、 ７７、 ８４、 ７３、 ５２、 ８１、 ４８、 ７４、 ６８、 ７６、 ８５、 １０４、 ８４、 ７７、 １０６、 ８５、 ５０、 ７３、 １１０、 ４８」
Perform authenticated encryption on the plaintext with the AES_128_CBC_HMAC_SHA_256 algorithm using the CEK as the encryption key, the JWE Initialization Vector, and the Additional Authenticated Data value above. The steps for doing this using the values from Appendix A.3 are detailed in Appendix B. The resulting ciphertext is:
暗号化キーとしてCEK、JWE初期化ベクトル、および上記の追加認証データ値を使用して、AES_128_CBC_HMAC_SHA_256アルゴリズムでプレーンテキストに対して認証済み暗号化を実行します。付録A.3の値を使用してこれを行う手順については、付録Bで詳しく説明します。結果の暗号文は次のとおりです。
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143, 112, 56, 102]
「４０、 ５７、 ８３、 １８１、 １１９、 ３３、 １３３、 １４８、 １９８、 １８５、 ２４３、 ２４、 １５２、 ２３０、 ６、 ７５、 １２９、 ２２３、 １２７、 １９、 ２１０、 ８２、 １８３、 ２３０、 １６８、 ３３、 ２１５、 １０４、 １４３、 １１２、 ５６、 １０２」
The resulting Authentication Tag value is:
結果の認証タグ値は次のとおりです。
[51, 63, 149, 60, 252, 148, 225, 25, 92, 185, 139, 245, 35, 2, 47, 207]
「５１、 ６３、 １４９、 ６０、 ２５２、 １４８、 ２２５、 ２５、 ９２、 １８５、 １３９、 ２４５、 ３５、 ２、 ４７、 ２０７」
Encoding this JWE Ciphertext as BASE64URL(JWE Ciphertext) gives this value:
このJWE暗号文をBASE64URL（JWE暗号文）としてエンコードすると、次の値が得られます。
KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY
Encoding this JWE Authentication Tag as BASE64URL(JWE Authentication Tag) gives this value:
このJWE認証タグをBASE64URL（JWE認証タグ）としてエンコードすると、次の値が得られます。
Mz-VPPyU4RlcuYv1IwIvzw
Mz-VPPyU4RlcuYv1IwIvzw
The complete JWE JSON Serialization for these values is as follows (with line breaks within values for display purposes only):
これらの値の完全なJWE JSONシリアライゼーションは次のとおりです（表示目的でのみ値内の改行を使用）。
{
"protected":
"eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
"unprotected":
{"jku":"https://server.example.com/keys.jwks"},
"recipients":[
{"header":
{"alg":"RSA1_5","kid":"2011-04-29"},
"encrypted_key":
"UGhIOguC7IuEvf_NPVaXsGMoLOmwvc1GyqlIKOK1nN94nHPoltGRhWhw7Zx0-
kFm1NJn8LE9XShH59_i8J0PH5ZZyNfGy2xGdULU7sHNF6Gp2vPLgNZ__deLKx
GHZ7PcHALUzoOegEI-8E66jX2E4zyJKx-YxzZIItRzC5hlRirb6Y5Cl_p-ko3
YvkkysZIFNPccxRU7qve1WYPxqbb2Yw8kZqa2rMWI5ng8OtvzlV7elprCbuPh
cCdZ6XDP0_F8rkXds2vE4X-ncOIM8hAYHHi29NX0mcKiRaD0-D-ljQTP-cFPg
wCp6X-nZZd9OHBv-B3oWh2TbqmScqXMR4gp_A"},
{"header":
{"alg":"A128KW","kid":"7"},
"encrypted_key":
"6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ"}],
"iv":
"AxY8DCtDaGlsbGljb3RoZQ",
"ciphertext":
"KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY",
"tag":
"Mz-VPPyU4RlcuYv1IwIvzw"
}
This section contains an example using the flattened JWE JSON Serialization syntax. This example demonstrates the capability for encrypting the plaintext to a single recipient in a flattened JSON structure.
このセクションには、フラット化されたJWE JSONシリアル化構文を使用した例が含まれています。この例は、フラット化されたJSON構造で単一の受信者へのプレーンテキストを暗号化する機能を示しています。
The values in this example are the same as those for the second recipient of the previous example in Appendix A.4.
この例の値は、付録A.4の前の例の2番目の受信者の値と同じです。
The complete JWE JSON Serialization for these values is as follows (with line breaks within values for display purposes only):
これらの値の完全なJWE JSONシリアライゼーションは次のとおりです（表示目的でのみ値内の改行を使用）。
{
"protected":
"eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
"unprotected":
{"jku":"https://server.example.com/keys.jwks"},
"header":
{"alg":"A128KW","kid":"7"},
"encrypted_key":
"6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ",
"iv":
"AxY8DCtDaGlsbGljb3RoZQ",
"ciphertext":
"KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY",
"tag":
"Mz-VPPyU4RlcuYv1IwIvzw"
}
Appendix B. Example AES_128_CBC_HMAC_SHA_256 Computation
付録B. AES_128_CBC_HMAC_SHA_256計算の例
This example shows the steps in the AES_128_CBC_HMAC_SHA_256 authenticated encryption computation using the values from the example in Appendix A.3. As described where this algorithm is defined in Sections 5.2 and 5.2.3 of JWA, the AES_CBC_HMAC_SHA2 family of algorithms are implemented using Advanced Encryption Standard (AES) in Cipher Block Chaining (CBC) mode with Public-Key Cryptography Standards (PKCS) #7 padding to perform the encryption and an HMAC SHA-2 function to perform the integrity calculation -- in this case, HMAC SHA-256.
この例は、付録A.3の例の値を使用して、AES_128_CBC_HMAC_SHA_256認証済み暗号化計算の手順を示しています。このアルゴリズムがJWAのセクション5.2および5.2.3で定義されている場所で説明されているように、AES_CBC_HMAC_SHA2ファミリーのアルゴリズムは、公開鍵暗号化標準（PKCS）＃7の暗号ブロック連鎖（CBC）モードでAdvanced Encryption Standard（AES）を使用して実装されます。暗号化を実行するためのパディング、および整合性計算を実行するためのHMAC SHA-2関数（この場合はHMAC SHA-256）。
The 256 bit AES_128_CBC_HMAC_SHA_256 key K used in this example (using JSON array notation) is:
この例で使用されている256ビットのAES_128_CBC_HMAC_SHA_256キーK（JSON配列表記を使用）は次のとおりです。
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, 206, 107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44, 207]
「４、 ２１１、 ３１、 １９７、 ８４、 １５７、 ２５２、 ２５４、 １１、 １００、 １５７、 ２５０、 ６３、 １７０、 １０６、 ２０６、 １０７、 １２４、 ２１２、 ４５、 １１１、 １０７、 ９、 ２１９、 ２００、 １７７、 ０、 ２４０、 １４３、 １５６、 ４４、 ２０７」
Use the first 128 bits of this key as the HMAC SHA-256 key MAC_KEY, which is:
この鍵の最初の128ビットをHMAC SHA-256鍵MAC_KEYとして使用します。
[4, 211, 31, 197, 84, 157, 252, 254, 11, 100, 157, 250, 63, 170, 106, 206] Use the last 128 bits of this key as the AES-CBC key ENC_KEY, which is:
[4、211、31、197、84、157、252、254、11、100、157、250、63、170、106、206]このキーの最後の128ビットをAES-CBCキーENC_KEYとして使用します。です：
[107, 124, 212, 45, 111, 107, 9, 219, 200, 177, 0, 240, 143, 156, 44, 207]
「１０７、 １２４、 ２１２、 ４５、 １１１、 １０７、 ９、 ２１９、 ２００、 １７７、 ０、 ２４０、 １４３、 １５６、 ４４、 ２０７」
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 identifiers "AES_128_CBC_HMAC_SHA_256" and "A128CBC-HS256".
MACキーは、入力キーKの暗号化キーの前に来ることに注意してください。これは、識別子「AES_128_CBC_HMAC_SHA_256」と「A128CBC-HS256」のアルゴリズム名とは逆の順序です。
Encrypt the plaintext with AES in CBC mode using PKCS #7 padding using the ENC_KEY above. The plaintext in this example is:
上記のENC_KEYを使用してPKCS＃7パディングを使用し、CBCモードのAESでプレーンテキストを暗号化します。この例の平文は次のとおりです。
[76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97, 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46]
「７６、 １０５、 １１８、 １０１、 ３２、 １０８、 １１１、 １１０、 １０３、 ３２、 ９７、 １１０、 １００、 ３２、 １１２、 １１４、 １１１、 １１５、 １１２、 １０１、 １１４、 ４６」
The encryption result is as follows, which is the ciphertext output:
暗号化の結果は次のとおりです。これは暗号文の出力です。
[40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143, 112, 56, 102]
「４０、 ５７、 ８３、 １８１、 １１９、 ３３、 １３３、 １４８、 １９８、 １８５、 ２４３、 ２４、 １５２、 ２３０、 ６、 ７５、 １２９、 ２２３、 １２７、 １９、 ２１０、 ８２、 １８３、 ２３０、 １６８、 ３３、 ２１５、 １０４、 １４３、 １１２、 ５６、 １０２」
The Additional Authenticated Data (AAD) in this example is:
この例の追加認証データ（AAD）は次のとおりです。
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52, 83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48]
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52, 83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48]
This AAD is 51-bytes long, which is 408-bits long. The octet string AL, which is the number of bits in AAD expressed as a big-endian 64-bit unsigned integer is:
このAADは51バイト長、つまり408ビット長です。オクテット文字列ALは、ビッグエンディアン64ビット符号なし整数として表されるAADのビット数です。
[0, 0, 0, 0, 0, 0, 1, 152]
「０、 ０、 ０、 ０、 ０、 ０、 １、 １５２」
The Initialization Vector value used in this example is:
この例で使用されている初期化ベクトルの値は次のとおりです。
[3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, 101]
「３、 ２２、 ６０、 １２、 ４３、 ６７、 １０４、 １０５、 １０８、 １０８、 １０５、 ９９、 １１１、 １１６、 １０４、 １０１」
Concatenate the AAD, the Initialization Vector, the ciphertext, and the AL value. The result of this concatenation is:
AAD、初期化ベクトル、暗号文、およびAL値を連結します。この連結の結果は次のとおりです。
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52, 83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48, 3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, 101, 40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143, 112, 56, 102, 0, 0, 0, 0, 0, 0, 1, 152]
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 66, 77, 84, 73, 52, 83, 49, 99, 105, 76, 67, 74, 108, 98, 109, 77, 105, 79, 105, 74, 66, 77, 84, 73, 52, 81, 48, 74, 68, 76, 85, 104, 84, 77, 106, 85, 50, 73, 110, 48, 3, 22, 60, 12, 43, 67, 104, 105, 108, 108, 105, 99, 111, 116, 104, 101, 40, 57, 83, 181, 119, 33, 133, 148, 198, 185, 243, 24, 152, 230, 6, 75, 129, 223, 127, 19, 210, 82, 183, 230, 168, 33, 215, 104, 143, 112, 56, 102, 0, 0, 0, 0, 0, 0, 1, 152]
Compute the HMAC SHA-256 of the concatenated value above. This result M is:
上記の連結値のHMAC SHA-256を計算します。この結果Mは：
[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38, 194, 85, 9, 84, 229, 201, 219, 135, 44, 252, 145, 102, 179, 140, 105, 86, 229, 116]
「８３、 ７３、 １９１、 ９８、 １０４、 ２０５、 ２１１、 １２８、 ２０１、 １８９、 １９９、 １３３、 ３２、 ３８、 １９４、 ８５、 ９、 ８４、 ２２９、 ２０１、 ２１９、 １３５、 ４４、 ２５２、 １４５、 １０２、 １７９、 １４０、 １０５、 ８６、 ２２９、 １１６」
Use the first half (128 bits) of the HMAC output M as the Authentication Tag output T. This truncated value is:
HMAC出力Mの前半（128ビット）を認証タグ出力Tとして使用します。この切り捨てられた値は次のとおりです。
[83, 73, 191, 98, 104, 205, 211, 128, 201, 189, 199, 133, 32, 38, 194, 85]
「８３、 ７３、 １９１、 ９８、 １０４、 ２０５、 ２１１、 １２８、 ２０１、 １８９、 １９９、 １３３、 ３２、 ３８、 １９４、 ８５」
Acknowledgements
謝辞
Solutions for encrypting JSON content were also explored by "JSON Simple Encryption" [JSE] and "JavaScript Message Security Format" [JSMS], both of which significantly influenced this document. This document attempts to explicitly reuse as many of the relevant concepts from XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411] and RFC 5652 [RFC5652] as possible, while utilizing simple, compact JSON-based data structures.
JSONコンテンツを暗号化するためのソリューションは、「JSON Simple Encryption」[JSE]と「JavaScript Message Security Format」[JSMS]によっても調査され、どちらもこのドキュメントに大きな影響を与えました。このドキュメントでは、シンプルでコンパクトなJSONベースのデータ構造を利用しながら、XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411]およびRFC 5652 [RFC5652]の関連する概念をできるだけ明示的に再利用しようとしています。
Special thanks are due to John Bradley, Eric Rescorla, and Nat Sakimura for the discussions that helped inform the content of this specification; to Eric Rescorla and Joe Hildebrand for allowing the reuse of text from [JSMS] in this document; and to Eric Rescorla for co-authoring many drafts of this specification.
この仕様の内容を伝えるのに役立つ議論をしてくれたJohn Bradley、Eric Rescorla、Nat Sakimuraに特に感謝します。このドキュメントの[JSMS]からのテキストの再利用を許可してくださったEric RescorlaおよびJoe Hildebrandに感謝します。この仕様の多くのドラフトを共同執筆したEric Rescorlaに。
Thanks to Axel Nennker, Emmanuel Raviart, Brian Campbell, and Edmund Jay for validating the examples in this specification.
この仕様の例を検証してくれたAxel Nennker、Emmanuel Raviart、Brian Campbell、およびEdmund Jayに感謝します。
This specification is the work of the JOSE working group, which includes dozens of active and dedicated participants. In particular, the following individuals contributed ideas, feedback, and wording that influenced this specification:
この仕様は、何十人ものアクティブで熱心な参加者を含むJOSEワーキンググループの作業です。特に、以下の個人がこの仕様に影響を与えるアイデア、フィードバック、および表現を提供しました。
Richard Barnes, John Bradley, Brian Campbell, Alissa Cooper, Breno de Medeiros, Stephen Farrell, Dick Hardt, Jeff Hodges, Russ Housley, Edmund Jay, Scott Kelly, Stephen Kent, Barry Leiba, James Manger, Matt Miller, Kathleen Moriarty, Tony Nadalin, Hideki Nara, Axel Nennker, Ray Polk, Emmanuel Raviart, Eric Rescorla, Pete Resnick, Nat Sakimura, Jim Schaad, Hannes Tschofenig, and Sean Turner.
リチャードバーンズ、ジョンブラッドリー、ブライアンキャンベル、アリッサクーパー、ブレノデメデイロス、スティーブンファレル、ディックハード、ジェフホッジス、ラスハウズリー、エドマンドジェイ、スコットケリー、スティーブンケント、バリーレイバ、ジェームズマンガー、マットミラー、キャスリーンモリアーティ、トニーナダリン、奈良秀樹、アクセルネンカー、レイポーク、エマニュエルラヴィアート、エリックレスコーラ、ピートレズニック、崎村ナット、ジムシャード、ハンネスショフェニグ、ショーンターナー。
Jim Schaad and Karen O'Donoghue chaired the JOSE working group and Sean Turner, Stephen Farrell, and Kathleen Moriarty served as Security Area Directors during the creation of this specification.
ジムシャードとカレンオドノヒューがJOSEワーキンググループの議長を務め、ショーンターナー、スティーブンファレル、キャスリーンモリアーティがこの仕様の作成中にセキュリティエリアディレクターを務めました。
Authors' Addresses
著者のアドレス
Michael B. Jones Microsoft
マイケルB.ジョーンズマイクロソフト
EMail: mbj@microsoft.com
URI: http://self-issued.info/
Joe Hildebrand Cisco Systems, Inc.
Joe Hildebrand Cisco Systems、Inc.
EMail: jhildebr@cisco.com