[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]
PROPOSED STANDARD
Errata ExistInternet Engineering Task Force (IETF) M. Jones
Request for Comments: 7515 Microsoft
Category: Standards Track J. Bradley
ISSN: 2070-1721 Ping Identity
N. Sakimura
NRI
May 2015
JSON Web Signature（JWS）
要約
JSON Web Signature（JWS）は、JSON ベースのデータ構造を用いて、
デジタル署名またはメッセージ認証コード（MAC）によって
保護されたコンテンツを表現する。これらの仕様で使用される
暗号アルゴリズムおよび識別子は、別途定義されている
JSON Web Algorithms（JWA）仕様および、その仕様で定義される
IANA レジストリに記述されている。関連する暗号化機能については、
別途定義されている JSON Web Encryption（JWE）仕様に記述されている。
本メモの位置付け
本文書は、インターネット標準トラック文書である。
本文書は、Internet Engineering Task Force（IETF）の成果物である。
これは IETF コミュニティの合意を反映したものである。
本文書は公開レビューを受け、Internet Engineering Steering Group
（IESG）によって公開が承認されている。インターネット標準に
関する追加情報は、
RFC 5741 の Section 2
を参照されたい。
本文書の現在のステータス、正誤表、およびフィードバックの
提供方法に関する情報は、次の URL から取得できる。
http://www.rfc-editor.org/info/rfc7515.
Jones, et al. Standards Track [Page 1]
RFC 7515 JSON Web Signature (JWS) May 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
目次
1. はじめに ....................................................4
1.1. 表記規約 .................................................4
2. 用語 .........................................................5
3. JSON Web Signature（JWS）の概要 .............................7
3.1. JWS Compact Serialization の概要 .......................7
3.2. JWS JSON Serialization の概要 ..........................8
3.3. JWS の例 ................................................8
4. JOSE ヘッダ ...................................................9
4.1. 登録済みヘッダパラメータ名 .............................10
4.1.1. "alg"（アルゴリズム）ヘッダパラメータ .............10
4.1.2. "jku"（JWK セット URL）ヘッダパラメータ .........10
4.1.3. "jwk"（JSON Web Key）ヘッダパラメータ ............11
4.1.4. "kid"（キー ID）ヘッダパラメータ ..................11
4.1.5. "x5u"（X.509 URL）ヘッダパラメータ ...............11
4.1.6. "x5c"（X.509 証明書チェーン）ヘッダパラメータ ...11
4.1.7. "x5t"（X.509 証明書 SHA-1 サムプリント）
ヘッダパラメータ ...................................12
4.1.8. "x5t#S256"（X.509 証明書 SHA-256
サムプリント）ヘッダパラメータ ...................12
4.1.9. "typ"（型）ヘッダパラメータ ......................12
4.1.10. "cty"（コンテンツ型）ヘッダパラメータ ..........13
4.1.11. "crit"（クリティカル）ヘッダパラメータ ..........14
4.2. 公開ヘッダパラメータ名 .................................14
4.3. 私的ヘッダパラメータ名 .................................14
5. JWS の生成および処理 .......................................15
5.1. メッセージ署名または MAC の計算 ....................15
5.2. メッセージ署名または MAC の検証 ....................16
5.3. 文字列比較規則 .........................................17
6. 鍵識別 .......................................................18
Jones, et al. Standards Track [Page 2]
RFC 7515 JSON Web Signature (JWS) May 2015
7. シリアライゼーション .......................................19
7.1. JWS Compact Serialization .............................19
7.2. JWS JSON Serialization ................................19
7.2.1. 一般 JWS JSON Serialization 構文 ..............20
7.2.2. フラット化 JWS JSON Serialization 構文 ........21
8. TLS 要件 .....................................................22
9. IANA に関する考慮事項 ........................................22
9.1. JSON Web Signature および暗号化ヘッダ
パラメータレジストリ ....................................23
9.1.1. 登録テンプレート ..............................23
9.1.2. 初期レジストリ内容 ............................24
9.2. メディア型登録 .........................................26
9.2.1. レジストリ内容 .................................26
10. セキュリティに関する考慮事項 ...............................27
10.1. 鍵エントロピーおよび乱数値 .........................27
10.2. 鍵の保護 .............................................28
10.3. 鍵の起源認証 .........................................28
10.4. 暗号アルゴリズムのアジリティ .......................28
10.5. デジタル署名と MAC の違い ..........................28
10.6. アルゴリズム検証 .....................................29
10.7. アルゴリズム保護 .....................................29
10.8. 選択平文攻撃 .........................................30
10.9. タイミング攻撃 .......................................30
10.10. リプレイ保護 .........................................30
10.11. SHA-1 証明書サムプリント ...........................30
10.12. JSON セキュリティに関する考慮事項 ..................31
10.13. Unicode 比較に関するセキュリティ考慮事項 ..........31
11. 参照 .........................................................32
11.1. 規範的参照 ...........................................32
11.2. 参考参照 .............................................34
付録 A. JWS の例 .............................................36
A.1. HMAC SHA-256 を用いた JWS の例 ......................36
A.1.1. エンコード ........................................36
A.1.2. 検証 ..............................................38
A.2. RSASSA-PKCS1-v1_5 SHA-256 を用いた JWS の例 .........38
A.2.1. エンコード ........................................38
A.2.2. 検証 ..............................................42
A.3. ECDSA P-256 SHA-256 を用いた JWS の例 ...............42
A.3.1. エンコード ........................................42
A.3.2. 検証 ..............................................44
A.4. ECDSA P-521 SHA-512 を用いた JWS の例 ...............45
A.4.1. エンコード ........................................45
A.4.2. 検証 ..............................................47
A.5. 署名なし JWS の例 ....................................47
A.6. 一般 JWS JSON Serialization を用いた JWS の例 ......48
A.6.1. 署名ごとの保護ヘッダ .............................48
A.6.2. 署名ごとの非保護ヘッダ ...........................49
A.6.3. 完全な JOSE ヘッダ値 ..............................49
Jones, et al. Standards Track [Page 3]
RFC 7515 JSON Web Signature (JWS) May 2015
A.6.4. 完全な JWS JSON Serialization 表現 ..............50
A.7. フラット化 JWS JSON Serialization を用いた JWS の例 ..51
付録 B. "x5c"（X.509 証明書チェーン）の例 .................52
付録 C. パディングなし base64url エンコード実装に関する注記 ..54
付録 D. 鍵選択に関する注記 .................................55
付録 E. "crit" ヘッダパラメータの否定テストケース .........57
付録 F. 分離コンテンツ .....................................57
謝辞 ..........................................................58
著者連絡先 ....................................................58
1. はじめに
JSON Web Signature（JWS）は、JSON ベースの
[RFC7159] データ構造を用いて、
デジタル署名またはメッセージ認証コード（MAC）によって
保護されたコンテンツを表現する。JWS の暗号メカニズムは、
任意のオクテット列に対する完全性保護を提供する。
デジタル署名と MAC の違いについては、
Section 10.5 を参照されたい。
JWS には、密接に関連する 2 つのシリアライゼーションが定義されている。
JWS Compact Serialization は、HTTP Authorization ヘッダや
URI クエリパラメータなど、空間制約のある環境を想定した、
コンパクトで URL セーフな表現である。
JWS JSON Serialization は、JWS を JSON オブジェクトとして表現し、
同一のコンテンツに対して複数の署名および／または MAC を
適用できるようにする。両者は同一の暗号学的基盤を共有する。
本仕様で使用される暗号アルゴリズムおよび識別子は、
別途定義されている JSON Web Algorithms（JWA）
[JWA] 仕様および、
その仕様で定義される IANA レジストリに記述されている。
関連する暗号化機能については、別途定義されている
JSON Web Encryption（JWE）
[JWE] 仕様に記述されている。
本仕様で定義される名前は、結果として得られる表現を
コンパクトにすることが中核的な目標であるため、短く定義されている。
1.1. 表記規約
本文書中のキーワード "MUST"、"MUST NOT"、"REQUIRED"、
"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、
"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、および
"OPTIONAL" は、
「RFC における要件レベルを示すためのキーワード」
[RFC2119]
に記載されているとおりに解釈される。
これらの解釈は、用語がすべて大文字で記載されている場合にのみ適用される。
BASE64URL(OCTETS) は、
Section 2 に従った OCTETS の base64url エンコードを表す。
Jones, et al. Standards Track [Page 4]
RFC 7515 JSON Web Signature (JWS) May 2015
UTF8(STRING) は、STRING（0 個以上の Unicode
[UNICODE]
文字からなる列）の UTF-8
[RFC3629]
表現のオクテット列を表す。
ASCII(STRING) は、STRING（0 個以上の ASCII 文字からなる列）の
ASCII
[RFC20]
表現のオクテット列を表す。
2 つの値 A と B の連結は、A || B と表記される。
2. 用語
次の用語は本仕様で定義される。
JSON Web Signature（JWS）
デジタル署名または MAC されたメッセージを表すデータ構造。
JOSE ヘッダ
使用される暗号操作およびパラメータを記述する
パラメータを含む JSON オブジェクト。
JOSE（JSON Object Signing and Encryption）ヘッダは、
ヘッダパラメータの集合から構成される。
JWS ペイロード
保護されるオクテット列、すなわちメッセージ。
ペイロードは任意のオクテット列を含むことができる。
JWS 署名
JWS 保護ヘッダおよび JWS ペイロードに対する
デジタル署名または MAC。
ヘッダパラメータ
JOSE ヘッダのメンバーである名前／値の組。
JWS 保護ヘッダ
JWS 署名のデジタル署名または MAC 操作によって
完全性保護されるヘッダパラメータを含む JSON オブジェクト。
JWS Compact Serialization では、これは JOSE ヘッダ全体を構成する。
JWS JSON Serialization では、これは JOSE ヘッダの 1 構成要素である。
JWS 非保護ヘッダ
完全性保護されないヘッダパラメータを含む JSON オブジェクト。
これは JWS JSON Serialization を使用する場合にのみ存在できる。
Jones, et al. Standards Track [Page 5]
RFC 7515 JSON Web Signature (JWS) May 2015
Base64url エンコード
RFC 4648 の Section 5
[RFC4648]
で定義されている URL およびファイル名セーフな文字セットを使用した
Base64 エンコードであり、末尾のすべての '=' 文字を
（Section 3.2 で許可されているとおり）
省略し、改行、空白、その他の追加文字を一切含めない。
空のオクテット列の base64url エンコード結果は空文字列であることに注意されたい。
（パディングなしの base64url エンコード実装に関する注記については
付録 C を参照。）
JWS 署名入力
デジタル署名または MAC 計算への入力。
その値は
ASCII(BASE64URL(UTF8(JWS 保護ヘッダ)) || '.' ||
BASE64URL(JWS ペイロード))
である。
JWS Compact Serialization
JWS をコンパクトで URL セーフな文字列として表現したもの。
JWS JSON Serialization
JWS を JSON オブジェクトとして表現したもの。
JWS Compact Serialization とは異なり、JWS JSON Serialization では
同一のコンテンツに対して複数のデジタル署名および／または MAC を
適用できる。
この表現は、コンパクトさや URL セーフ性に最適化されていない。
非保護 JWS（Unsecured JWS）
完全性保護を提供しない JWS。
非保護 JWS では "alg" の値として "none" を使用する。
衝突耐性名（Collision-Resistant Name）
他の名前と衝突する可能性が極めて低くなるような方法で
名前を割り当てることが可能な名前空間内の名前。
衝突耐性を持つ名前空間の例には、ドメイン名、
ITU-T 勧告 X.660 および X.670 シリーズで定義される
オブジェクト識別子（OID）、
およびユニバーサル一意識別子（UUID）
[RFC4122]
が含まれる。
管理的に委任された名前空間を使用する場合、名前の定義者は、
自身がその名前を定義するために使用する名前空間の部分を
管理していることを確保するため、合理的な予防措置を講じる必要がある。
StringOrURI
JSON の文字列値であり、追加要件として、
任意の文字列値を使用してもよいが、
":" 文字を含む値は URI
[RFC3986]
でなければならない。
StringOrURI の値は、大文字・小文字を区別する文字列として比較され、
いかなる変換や正規化も適用されない。
Jones, et al. Standards Track [Page 6]
RFC 7515 JSON Web Signature (JWS) May 2015
「JSON Web Encryption（JWE）」、「JWE Compact Serialization」、
および「JWE JSON Serialization」という用語は、JWE 仕様
[JWE] によって定義されている。
「デジタル署名（Digital Signature）」および
「メッセージ認証コード（Message Authentication Code, MAC）」という用語は、
「Internet Security Glossary, Version 2」
[RFC4949] によって定義されている。
3. JSON Web Signature（JWS）概要
JWS は、JSON データ構造および base64url エンコードを用いて、
デジタル署名または MAC が付与されたコンテンツを表現する。
これらの JSON データ構造は、
RFC 7159 の Section 2
[RFC7159]
に従い、任意の JSON 値または構造文字の前後に、
空白および／または改行を含んでもよい。
JWS は、次の論理値（それぞれ Section 2 で定義されている）
を表現する。
o JOSE ヘッダ
o JWS ペイロード
o JWS 署名
JWS において、JOSE ヘッダのメンバは、
次の値のメンバの和集合である
（それぞれ Section 2 で定義されている）。
o JWS 保護ヘッダ
o JWS 非保護ヘッダ
本文書は、JWS のために 2 種類のシリアライゼーションを定義する。
1 つは、JWS Compact Serialization と呼ばれる
コンパクトで URL セーフなシリアライゼーションであり、
もう 1 つは、JWS JSON Serialization と呼ばれる
JSON シリアライゼーションである。
いずれのシリアライゼーションにおいても、
JWS 保護ヘッダ、JWS ペイロード、および JWS 署名は、
JSON には任意のオクテット列を直接表現する方法がないため、
base64url エンコードされる。
3.1. JWS Compact Serialization の概要
JWS Compact Serialization では、JWS 非保護ヘッダは使用されない。
この場合、JOSE ヘッダと JWS 保護ヘッダは同一である。
JWS Compact Serialization において、JWS は次の連結として表現される。
BASE64URL(UTF8(JWS 保護ヘッダ)) || '.' ||
BASE64URL(JWS ペイロード) || '.' ||
BASE64URL(JWS 署名)
JWS Compact Serialization に関する詳細は、
Section 7.1 を参照されたい。
Jones, et al. Standards Track [Page 7]
RFC 7515 JSON Web Signature (JWS) May 2015
3.2. JWS JSON Serialization の概要
JWS JSON Serialization では、JWS 保護ヘッダおよび
JWS 非保護ヘッダの一方または両方が存在しなければならない。
この場合、JOSE ヘッダのメンバは、
存在する JWS 保護ヘッダおよび JWS 非保護ヘッダの
メンバの和集合となる。
JWS JSON Serialization において、JWS は、
次の 4 つのメンバの一部または全部を含む
JSON オブジェクトとして表現される。
o "protected"：値は BASE64URL(UTF8(JWS 保護ヘッダ))
o "header"：値は JWS 非保護ヘッダ
o "payload"：値は BASE64URL(JWS ペイロード)
o "signature"：値は BASE64URL(JWS 署名)
base64url エンコードされた 3 つの結果文字列と
JWS 非保護ヘッダの値は、JSON オブジェクト内のメンバとして表現される。
これらの値の一部の包含は OPTIONAL である。
JWS JSON Serialization は、1 つだけでなく、
複数の署名および／または MAC 値を表現することもできる。
JWS JSON Serialization に関する詳細は、
Section 7.2 を参照されたい。
3.3. JWS の例
本節では、JWS の例を示す。
その計算方法は、
使用される JSON 値を表す正確なオクテット列および
使用される鍵の値を含め、
Appendix A.1 でより詳細に説明されている。
次の例の JWS 保護ヘッダは、
エンコードされたオブジェクトが
JSON Web Token
[JWT]
であること、
および JWS 保護ヘッダと JWS ペイロードが
HMAC SHA-256
[RFC2104]
[SHS]
アルゴリズムを用いて保護されていることを宣言している。
{"typ":"JWT",
"alg":"HS256"}
この JWS 保護ヘッダを
BASE64URL(UTF8(JWS 保護ヘッダ))
としてエンコードすると、次の値が得られる。
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
次の JSON オブジェクトの UTF-8 表現が
JWS ペイロードとして使用される。
（ペイロードは任意のコンテンツでよく、
JSON オブジェクトの表現である必要はない点に注意されたい。）
Jones, et al. Standards Track [Page 8]
RFC 7515 JSON Web Signature (JWS) May 2015
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
この JWS ペイロードを
BASE64URL(JWS ペイロード)
としてエンコードすると、次の値が得られる
（表示目的のためにのみ改行を含めている）。
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
Appendix A.1 で指定されている鍵を用い、
HMAC SHA-256 アルゴリズムによって
JWS 署名入力
ASCII(BASE64URL(UTF8(JWS 保護ヘッダ)) || '.' || BASE64URL(JWS ペイロード))
の HMAC を計算し、
その結果を base64url エンコードすると、
次の BASE64URL(JWS 署名) の値が得られる。
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
これらの値を、
Header.Payload.Signature の順に、
各部分の間をピリオド（'.'）文字で区切って連結すると、
次の JWS Compact Serialization による
完全な JWS 表現が得られる
（表示目的のためにのみ改行を含めている）。
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
Sections A.6 および A.7 における
JWS JSON Serialization を用いた例を含む、
追加の例については Appendix A を参照されたい。
4. JOSE ヘッダ
JWS において、JOSE ヘッダを表す JSON オブジェクトのメンバは、
JWS 保護ヘッダおよび JWS ペイロードに適用される
デジタル署名または MAC を記述し、
さらに JWS の追加プロパティを任意で記述する。
JOSE ヘッダ内のヘッダパラメータ名は一意でなければならない。
JWS パーサは、
重複するヘッダパラメータ名を含む JWS を拒否するか、
ECMAScript 5.1
[ECMAScript]
の Section 15.12
（「JSON オブジェクト」）で規定されているとおり、
字句的に最後の重複メンバ名のみを返す
JSON パーサを使用しなければならない。
実装は、
本仕様で定義され、「理解されなければならない（MUST be understood）」
と指定されている特定のヘッダパラメータを理解し、
本仕様で定義された方法でそれらを処理することが要求される。
本仕様で定義されているその他すべてのヘッダパラメータは、
Jones, et al. Standards Track [Page 9]
RFC 7515 JSON Web Signature (JWS) May 2015
そのように指定されていない場合、
理解されないときは無視されなければならない。
Section 4.1.11 に従い、
クリティカルなヘッダパラメータとして列挙されていない限り、
本仕様で定義されていないすべてのヘッダパラメータは、
理解されないときは無視されなければならない。
ヘッダパラメータ名には、
登録済みヘッダパラメータ名、
公開ヘッダパラメータ名、
および非公開ヘッダパラメータ名の
3 つのクラスがある。
4.1. 登録済みヘッダパラメータ名
JWS で使用する次のヘッダパラメータ名は、
Section 9.1 によって確立された
IANA「JSON Web Signature and Encryption Header Parameters」
レジストリに登録されており、
その意味は以下の各小節で定義されている。
共通レジストリが示すとおり、
JWS と JWE は共通のヘッダパラメータ空間を共有する。
あるパラメータが両方の仕様で使用される場合、
その使用方法は仕様間で互換性がなければならない。
4.1.1. "alg"（アルゴリズム）ヘッダパラメータ
"alg"（algorithm）ヘッダパラメータは、
JWS を保護するために使用される暗号アルゴリズムを識別する。
"alg" の値がサポートされていないアルゴリズムを表している場合、
またはそのアルゴリズムで使用する鍵が、
コンテンツにデジタル署名または MAC を施した主体に関連付けられていない場合、
JWS 署名値は有効ではない。
"alg" の値は、
[JWA]
によって確立された
IANA「JSON Web Signature and Encryption Algorithms」
レジストリに登録されるか、
または衝突耐性名を含む値であるべきである。
"alg" の値は、
StringOrURI 値を含む、
大文字・小文字を区別する ASCII 文字列である。
このヘッダパラメータは MUST で存在しなければならず、
実装によって理解され、処理されなければならない。
この用途のために定義されている "alg" の値の一覧は、
[JWA]
によって確立された
IANA「JSON Web Signature and Encryption Algorithms」
レジストリに記載されている。
このレジストリの初期内容は、
[JWA]
の Section 3.1 で定義されている値である。
4.1.2. "jku"（JWK Set URL）ヘッダパラメータ
"jku"（JWK Set URL）ヘッダパラメータは、
JWS にデジタル署名を行うために使用された鍵に対応する
JSON エンコードされた公開鍵集合を指すリソースを参照する
URI
[RFC3986]
である。
鍵は JWK Set
[JWK]
としてエンコードされなければならない。
このリソースを取得するために使用されるプロトコルは、
完全性保護を提供しなければならない。
JWK Set を取得するための HTTP GET リクエストは、
トランスポート層セキュリティを使用しなければならない。
Jones, et al. Standards Track [Page 10]
RFC 7515 JSON Web Signature (JWS) May 2015
(TLS) [RFC2818] [RFC5246]；また、サーバの同一性は
RFC 6125 の Section 6
[RFC6125]
に従って検証されなければならない。
さらに、TLS 要件については Section 8 も参照されたい。
このヘッダパラメータの使用は OPTIONAL である。
4.1.3. "jwk"（JSON Web Key）ヘッダパラメータ
"jwk"（JSON Web Key）ヘッダパラメータは、
JWS にデジタル署名を行うために使用された鍵に対応する公開鍵である。
この鍵は JSON Web Key
[JWK]
として表現される。
このヘッダパラメータの使用は OPTIONAL である。
4.1.4. "kid"（Key ID）ヘッダパラメータ
"kid"（key ID）ヘッダパラメータは、
JWS を保護するためにどの鍵が使用されたかを示すヒントである。
このパラメータにより、発信者は受信者に対して
鍵の変更を明示的に通知することができる。
"kid" 値の構造は規定されていない。
その値は大文字・小文字を区別する文字列でなければならない。
このヘッダパラメータの使用は OPTIONAL である。
JWK とともに使用される場合、
"kid" の値は JWK の "kid" パラメータ値と照合するために使用される。
4.1.5. "x5u"（X.509 URL）ヘッダパラメータ
"x5u"（X.509 URL）ヘッダパラメータは、
JWS にデジタル署名を行うために使用された鍵に対応する
X.509 公開鍵証明書または証明書チェーン
[RFC5280]
のためのリソースを参照する URI
[RFC3986]
である。
指定されたリソースは、
RFC 5280
[RFC5280]
に適合する PEM エンコード形式の証明書または証明書チェーンの表現を
提供しなければならない。
各証明書は、
RFC 4945 の Section 6.1
[RFC4945]
で規定されているとおり区切られなければならない。
JWS にデジタル署名を行うために使用された鍵に対応する公開鍵を含む証明書は、
最初の証明書でなければならない。
その後に追加の証明書が続いてもよく、
各後続の証明書は直前の証明書を認証するために使用されたものである。
リソースを取得するために使用されるプロトコルは、
完全性保護を提供しなければならない。
証明書を取得するための HTTP GET リクエストは、
TLS
[RFC2818]
[RFC5246]
を使用しなければならない。
また、サーバの同一性は
RFC 6125 の Section 6
[RFC6125]
に従って検証されなければならない。
さらに、TLS 要件については Section 8 も参照されたい。
このヘッダパラメータの使用は OPTIONAL である。
4.1.6. "x5c"（X.509 証明書チェーン）ヘッダパラメータ
"x5c"（X.509 証明書チェーン）ヘッダパラメータは、
JWS にデジタル署名を行うために使用された鍵に対応する
X.509 公開鍵証明書または証明書チェーン
[RFC5280]
を含む。
証明書または証明書チェーンは、
証明書値文字列の JSON 配列として表現される。
Jones, et al. Standards Track [Page 11]
RFC 7515 JSON Web Signature (JWS) May 2015
配列内の各文字列は、
base64 エンコード
（[RFC4648] の Section 4 ― base64url エンコードではない）
された DER
[ITU.X690.2008]
PKIX 証明書値である。
JWS にデジタル署名を行うために使用された鍵に対応する公開鍵を含む証明書は、
最初の証明書でなければならない。
その後に追加の証明書が続いてもよく、
各後続の証明書は直前の証明書を認証するために使用されたものである。
受信者は、
RFC 5280
[RFC5280]
に従って証明書チェーンを検証し、
いずれかの検証失敗が発生した場合には、
その証明書または証明書チェーンを無効と見なさなければならない。
このヘッダパラメータの使用は OPTIONAL である。
"x5c" 値の例については Appendix B を参照されたい。
4.1.7. "x5t"（X.509 証明書 SHA-1 サムプリント）ヘッダパラメータ
"x5t"（X.509 証明書 SHA-1 サムプリント）ヘッダパラメータは、
JWS にデジタル署名を行うために使用された鍵に対応する
X.509 証明書
[RFC5280]
の DER エンコードに対する
SHA-1 サムプリント（別名ダイジェスト）を
base64url エンコードしたものである。
証明書サムプリントは、
証明書フィンガープリントと呼ばれることもある。
このヘッダパラメータの使用は OPTIONAL である。
4.1.8. "x5t#S256"（X.509 証明書 SHA-256 サムプリント）ヘッダ
パラメータ
"x5t#S256"（X.509 証明書 SHA-256 サムプリント）ヘッダパラメータは、
JWS にデジタル署名を行うために使用された鍵に対応する
X.509 証明書
[RFC5280]
の DER エンコードに対する
SHA-256 サムプリント（別名ダイジェスト）を
base64url エンコードしたものである。
証明書サムプリントは、
証明書フィンガープリントと呼ばれることもある。
このヘッダパラメータの使用は OPTIONAL である。
4.1.9. "typ"（Type）ヘッダパラメータ
"typ"（type）ヘッダパラメータは、
この完全な JWS のメディア型
[IANA.MediaTypes]
を宣言するために JWS アプリケーションによって使用される。
これは、JWS を含むことができるアプリケーションデータ構造内に
複数種類のオブジェクトが存在し得る場合に、
それらを区別するためにアプリケーションが使用することを意図している。
通常、オブジェクトの種類がすでに分かっている場合には、
アプリケーションによって使用されることはない。
このパラメータは JWS 実装によっては無視される。
このパラメータの処理は、
JWS アプリケーションによって実行される。
このヘッダパラメータの使用は OPTIONAL である。
RFC 2045
[RFC2045]
に従い、すべてのメディア型値、サブタイプ値、および
パラメータ名は大文字・小文字を区別しない。
ただし、特定のパラメータについて別途指定されていない限り、
パラメータ値は大文字・小文字を区別する。
Jones, et al. Standards Track [Page 12]
RFC 7515 JSON Web Signature (JWS) May 2015
一般的な状況においてメッセージをコンパクトに保つため、
メディア型値に他の '/' が含まれていない場合には、
"typ" ヘッダパラメータにおいて
メディア型値の "application/" 接頭辞を省略することが
RECOMMENDED である。
メディア型値を使用する受信者は、
'/' を含まない任意の "typ" 値について、
あたかも "application/" が前置されているかのように
扱わなければならない。
たとえば、
"example" という "typ" 値は
"application/example" メディア型を表すために使用されるべきである一方、
メディア型
"application/example;part="1/2""
は
"example;part="1/2""
に短縮することはできない。
"typ" 値 "JOSE" は、
このオブジェクトが
JWS Compact Serialization または
JWE Compact Serialization を使用する
JWS または JWE であることを示すために、
アプリケーションによって使用することができる。
"typ" 値 "JOSE+JSON" は、
このオブジェクトが
JWS JSON Serialization または
JWE JSON Serialization を使用する
JWS または JWE であることを示すために、
アプリケーションによって使用することができる。
その他の型値も、
アプリケーションによって使用することができる。
4.1.10. "cty"（Content Type）ヘッダパラメータ
"cty"（content type）ヘッダパラメータは、
保護されたコンテンツ（ペイロード）のメディア型
[IANA.MediaTypes]
を宣言するために JWS アプリケーションによって使用される。
これは、JWS ペイロード内に
複数種類のオブジェクトが存在し得る場合に、
それらを区別するためにアプリケーションが使用することを意図している。
通常、オブジェクトの種類がすでに分かっている場合には、
アプリケーションによって使用されることはない。
このパラメータは JWS 実装によっては無視される。
このパラメータの処理は、
JWS アプリケーションによって実行される。
このヘッダパラメータの使用は OPTIONAL である。
RFC 2045
[RFC2045]
に従い、すべてのメディア型値、サブタイプ値、および
パラメータ名は大文字・小文字を区別しない。
ただし、特定のパラメータについて別途指定されていない限り、
パラメータ値は大文字・小文字を区別する。
一般的な状況においてメッセージをコンパクトに保つため、
メディア型値に他の '/' が含まれていない場合には、
"cty" ヘッダパラメータにおいて
メディア型値の "application/" 接頭辞を省略することが
RECOMMENDED である。
メディア型値を使用する受信者は、
'/' を含まない任意の "cty" 値について、
あたかも "application/" が前置されているかのように
扱わなければならない。
たとえば、
"example" という "cty" 値は
"application/example" メディア型を表すために使用されるべきである一方、
メディア型
"application/example;part="1/2""
は
"example;part="1/2""
に短縮することはできない。
Jones, et al. Standards Track [Page 13]
RFC 7515 JSON Web Signature (JWS) May 2015
4.1.11. "crit"（Critical）ヘッダパラメータ
"crit"（critical）ヘッダパラメータは、
本仕様および／または
[JWA]
に対する拡張が使用されており、
それらが理解され、処理されなければならないことを示す。
その値は、
それらの拡張を使用する
JOSE ヘッダ内に存在するヘッダパラメータ名を列挙した配列である。
列挙された拡張ヘッダパラメータのいずれかが
受信者によって理解またはサポートされていない場合、
JWS は無効である。
生成者は、
本仕様または
[JWA]
によって JWS 用に定義されているヘッダパラメータ名、
重複する名前、
または JOSE ヘッダ内のヘッダパラメータ名として
出現しない名前を
"crit" リストに含めてはならない。
生成者は、
"crit" の値として空のリスト "[]" を使用してはならない。
受信者は、
クリティカルリストに
本仕様または
[JWA]
によって JWS 用に定義されているヘッダパラメータ名が含まれている場合、
またはその使用に関するその他の制約に違反している場合には、
JWS を無効と見なしてもよい。
使用される場合、このヘッダパラメータは完全性保護されなければならない。
したがって、JWS 保護ヘッダ内にのみ出現しなければならない。
このヘッダパラメータの使用は OPTIONAL である。
このヘッダパラメータは、
実装によって理解され、処理されなければならない。
仮想的な "exp"（有効期限）フィールドとともに使用する例は次のとおりである。
{"alg":"ES256",
"crit":["exp"],
"exp":1363284000
}
4.2. 公開ヘッダパラメータ名
追加のヘッダパラメータ名は、
JWS を使用する者によって定義することができる。
ただし、衝突を防ぐため、
新しいヘッダパラメータ名は、
Section 9.1 によって確立された
IANA「JSON Web Signature and Encryption Header Parameters」
レジストリに登録されるか、
公開名（衝突耐性名を含む値）であるべきである。
いずれの場合においても、
名前または値を定義する者は、
ヘッダパラメータ名を定義するために使用する
名前空間の部分を自らが管理していることを確実にするため、
合理的な予防措置を講じる必要がある。
新しいヘッダパラメータは、
相互運用性のない JWS を生じさせる可能性があるため、
慎重に導入されるべきである。
4.3. 非公開ヘッダパラメータ名
JWS の生成者と消費者は、
非公開名
（登録済みヘッダパラメータ名ではない名前
（Section 4.1））
または公開ヘッダパラメータ名
Jones, et al. Standards Track [Page 14]
RFC 7515 JSON Web Signature (JWS) May 2015
（Section 4.2）である
ヘッダパラメータ名を使用することに合意することができる。
公開ヘッダパラメータ名とは異なり、
非公開ヘッダパラメータ名は衝突の可能性があり、
注意して使用されるべきである。
5. JWS の生成および消費
5.1. メッセージ署名または MAC の計算
JWS を作成するには、次の手順を実行する。
手順の順序は、
手順の入力と出力の間に依存関係が存在しない場合には重要ではない。
1. JWS ペイロードとして使用するコンテンツを作成する。
2. エンコードされたペイロード値
BASE64URL(JWS ペイロード)
を計算する。
3. 所望のヘッダパラメータ集合を含む
JSON オブジェクトを作成し、
それらを合わせて JOSE ヘッダ
（JWS 保護ヘッダおよび／または JWS 非保護ヘッダ）
を構成する。
4. エンコードされたヘッダ値
BASE64URL(UTF8(JWS 保護ヘッダ))
を計算する。
JWS 保護ヘッダが存在しない場合
（これは、JWS JSON Serialization を使用し、
"protected" メンバが存在しない場合にのみ発生し得る）、
この値は空文字列とする。
5. 使用されている特定のアルゴリズムに対して定義されている方法で、
JWS 署名入力
ASCII(BASE64URL(UTF8(JWS 保護ヘッダ)) || '.' ||
BASE64URL(JWS ペイロード))
に対する JWS 署名を計算する。
"alg"（algorithm）ヘッダパラメータは、
JOSE ヘッダ内に必ず存在しなければならず、
そのアルゴリズム値は、
JWS 署名を構成するために使用されたアルゴリズムを
正確に表していなければならない。
6. エンコードされた署名値
BASE64URL(JWS 署名)
を計算する。
7. JWS JSON Serialization が使用されている場合、
実行される各デジタル署名または MAC 操作ごとに、
この処理（手順 3〜6）を繰り返す。
8. 所望のシリアライズされた出力を作成する。
この結果の JWS Compact Serialization は、
BASE64URL(UTF8(JWS 保護ヘッダ)) || '.' ||
BASE64URL(JWS ペイロード) || '.' ||
BASE64URL(JWS 署名)
である。
JWS JSON Serialization については、
Section 7.2 で説明されている。
Jones, et al. Standards Track [Page 15]
RFC 7515 JSON Web Signature (JWS) May 2015
5.2. メッセージ署名または MAC の検証
JWS を検証する際には、以下の手順が実行される。手順の
順序は、手順の入力と出力の間に依存関係が存在しない場合には
重要ではない。列挙された手順のいずれかが失敗した場合、
署名または MAC は検証できない。
複数の JWS Signature 値が存在する場合、どの JWS Signature 値が
正常に検証されなければ JWS を受理するかは、アプリケーションの
判断となる。場合によっては、すべてが正常に検証されなければ
ならず、その場合、JWS は無効とみなされる。別の場合には、
特定の JWS Signature 値のみが正常に検証されればよい。
しかし、いずれの場合でも、少なくとも 1 つの JWS Signature 値が
正常に検証されなければならず、そうでなければ JWS は
無効とみなされなければならない。
1. JWS 表現を解析し、JWS の各構成要素に対応するシリアライズされた
値を抽出する。JWS Compact Serialization を使用する場合、
これらの構成要素は、JWS Protected Header、JWS Payload、および
JWS Signature の base64url エンコードされた表現であり、
JWS JSON Serialization を使用する場合には、これらの構成要素に
エンコードされていない JWS Unprotected Header の値も含まれる。
JWS Compact Serialization を使用する場合、JWS Protected Header、
JWS Payload、および JWS Signature は、この順序で
base64url エンコードされた値として表現され、各値は単一の
ピリオド（'.'）文字によって区切られ、その結果、区切り用の
ピリオド文字がちょうど 2 個使用される。
JWS JSON Serialization については
Section 7.2 に記述されている。
2. JWS Protected Header のエンコードされた表現を Base64url デコード
する。この際、改行、空白、またはその他の追加文字が使用されて
いないという制約に従う。
3. 得られたオクテット列が、UTF-8 エンコードされた、完全に有効な
JSON オブジェクトの表現であり、
RFC 7159 [RFC7159] に適合していることを検証する。
この JSON オブジェクトを JWS Protected Header とする。
4. JWS Compact Serialization を使用している場合、JOSE Header は
JWS Protected Header とする。それ以外の場合、すなわち
JWS JSON Serialization を使用している場合、JOSE Header は、
対応する JWS Protected Header と JWS Unprotected Header の
メンバーの和集合とし、それらはすべて完全に有効な JSON
オブジェクトでなければならない。この手順において、
結果として得られる JOSE Header に、重複した Header Parameter
名が含まれていないことを検証する。JWS
Jones, et al. Standards Track [Page 16]
RFC 7515 JSON Web Signature (JWS) May 2015
JSON Serialization を使用する場合、この制約には、JOSE Header を
構成する複数の JSON オブジェクト値において、同一の Header
Parameter 名が重複して出現してはならないことも含まれる。
5. 実装が、この仕様、使用されているアルゴリズム、または
"crit" Header Parameter の値によって要求されているすべての
フィールドを理解し、処理できること、ならびにそれらの
パラメータの値も理解され、サポートされていることを検証する。
6. JWS Payload のエンコードされた表現を Base64url デコードする。
この際、改行、空白、またはその他の追加文字が使用されていない
という制約に従う。
7. JWS Signature のエンコードされた表現を Base64url デコードする。
この際、改行、空白、またはその他の追加文字が使用されていない
という制約に従う。
8. 使用されているアルゴリズムに対して定義された方法で、
JWS Signing Input
ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload))
に対して JWS Signature を検証する。このアルゴリズムは、
必須である "alg"（algorithm）Header Parameter の値によって
正確に表現されていなければならない。
アルゴリズム検証に関するセキュリティ上の考慮事項については
Section 10.6 を参照のこと。
検証が成功したか否かを記録する。
9. JWS JSON Serialization を使用している場合、この処理
（手順 4〜8）を、表現に含まれる各デジタル署名または
MAC 値について繰り返す。
10. 手順 9 におけるいずれの検証も成功しなかった場合、
JWS は無効とみなされなければならない。それ以外の場合、
JWS JSON Serialization の場合には、どの検証が成功し、
どの検証が失敗したかを示す結果をアプリケーションに返す。
JWS Compact Serialization の場合には、JWS が正常に検証された
か否かのみを示す結果を返せばよい。
最後に、どのアルゴリズムを特定の文脈で使用できるかは、
アプリケーションの判断であることに注意すること。
JWS が正常に検証できた場合であっても、JWS で使用されている
アルゴリズムがアプリケーションにとって受け入れ可能でない
場合には、JWS は無効とみなされるべきである。
5.3. 文字列比較規則
JWS の処理では、既知の文字列を JSON オブジェクト内のメンバー名や
値と比較する必要が必然的に生じる。例えば、アルゴリズムを確認する
際には、Unicode 文字列 "alg" が、JOSE Header 内のメンバー名と
一致するものが存在するかどうかを確認するために比較される。
Jones, et al. Standards Track [Page 17]
RFC 7515 JSON Web Signature (JWS) May 2015
Header Parameter 名。同じ処理が、その後、
"alg" Header Parameter の値がサポートされている
アルゴリズムを表しているかどうかを判定するためにも
使用される。
JSON におけるメンバー名比較の規則は、
RFC 7159 の Section 8.3
[RFC7159]
に記述されている。実行される文字列比較操作は、
等価および非等価のみであるため、同じ規則を、メンバー名および
メンバー値の両方を既知の文字列と比較するために使用できる。
これらの比較規則は、定義において、そのメンバー値に対して
異なる比較規則を使用することが明示的に指定されている場合を
除き、すべての JSON 文字列比較に使用されなければならない。
この仕様で定義されている "typ" および "cty" の
メンバー値のみが、これらの比較規則を使用しない。
一部のアプリケーションでは、大文字と小文字を区別する値の中に、
大文字小文字を区別しない情報が含まれる場合がある。例えば、
"kid"（key ID）値の一部として DNS 名を含める場合などである。
そのような場合、複数の当事者が同じ値を生成して比較する必要が
あるときには、大文字小文字を区別しない部分を表現するために
使用する正規化された大文字小文字の規約（例えば小文字化）を、
アプリケーションが定義する必要がある場合がある。
（ただし、他のすべての当事者が、生成側が出力した値をそのまま
消費し、独立に生成した値と比較しようとしない場合には、
生成側が使用した大文字小文字は問題とならない。）
また、JSON に関するセキュリティ上の考慮事項については
Section 10.12 を、
Unicode に関するセキュリティ上の考慮事項については
Section 10.13 を参照のこと。
6. 鍵識別
JWS の受信者が、デジタル署名または MAC 操作に使用された鍵を
特定できることが必要である。使用された鍵は、
Section 4.1 に記述されている
Header Parameter の方法を用いて識別することも、
本仕様の範囲外の方法を用いて識別することもできる。
具体的には、Header Parameter "jku"、"jwk"、"kid"、"x5u"、
"x5c"、"x5t"、および "x5t#S256" を使用して、使用された鍵を
識別できる。これらの Header Parameter は、それらが伝達する
情報が信頼判断に利用される場合には、完全性保護されて
いなければならない。ただし、信頼判断に使用される情報が
鍵のみである場合には、これらのパラメータは完全性保護
されている必要はない。なぜなら、それらを変更して別の鍵が
使用されるようにすると、検証が失敗するからである。
生成者は、アプリケーションが使用される鍵を決定するために
他の手段や規約を使用しない限り、使用された鍵を識別するために
十分な情報を Header Parameter に含めるべきである。検証は、
Jones, et al. Standards Track [Page 18]
RFC 7515 JSON Web Signature (JWS) May 2015
使用されたアルゴリズムが鍵を必要とする場合
（"none" を除くすべてのアルゴリズムが該当する）に、
その鍵を特定できないときには、署名または MAC の検証は
失敗する。
使用される共有対称鍵を交換する手段は、
本仕様の範囲外である。
鍵選択アルゴリズムの可能性に関する注記については
Appendix D を参照のこと。
7. シリアライゼーション
JWS は、JWS Compact Serialization または
JWS JSON Serialization の 2 種類のシリアライゼーションの
いずれかを使用する。本仕様を使用するアプリケーションは、
どのシリアライゼーションおよびシリアライゼーション機能を
使用するかを指定する必要がある。例えば、JWS JSON
Serialization のみを使用すること、単一の署名または MAC 値に
対する JWS JSON Serialization のみをサポートすること、
あるいは複数の署名および／または MAC 値のサポートを使用する
ことを指定できる。JWS 実装は、それらがサポートするよう
設計されているアプリケーションに必要な機能のみを
実装すればよい。
7.1. JWS Compact Serialization
JWS Compact Serialization は、デジタル署名または MAC が
施されたコンテンツを、コンパクトで URL セーフな文字列として
表現する。この文字列は次のとおりである。
BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) || '.' ||
BASE64URL(JWS Signature)
JWS Compact Serialization では、1 つの署名／MAC のみが
サポートされ、JWS Unprotected Header 値を表現するための
構文は提供されない。
7.2. JWS JSON Serialization
JWS JSON Serialization は、デジタル署名または MAC が
施されたコンテンツを JSON オブジェクトとして表現する。
この表現は、コンパクトさにも URL セーフ性にも
最適化されていない。
JWS JSON Serialization には、密接に関連する 2 つの
構文が定義されている。1 つは、複数のデジタル署名および／または
MAC 操作によってコンテンツを保護できる完全に汎用的な構文であり、
もう 1 つは、単一のデジタル署名または MAC の場合に最適化された
フラット化構文である。
Jones, et al. Standards Track [Page 19]
RFC 7515 JSON Web Signature (JWS) May 2015
7.2.1. 一般 JWS JSON Serialization 構文
完全に汎用的な JWS JSON Serialization 構文で使用される
トップレベルの JSON オブジェクトに対して、以下のメンバーが
定義されている。
payload
"payload" メンバーは必須であり、
BASE64URL(JWS Payload) の値を含まなければならない。
signatures
"signatures" メンバー値は、JSON オブジェクトの配列で
なければならない。各オブジェクトは、JWS Payload および
JWS Protected Header に対する署名または MAC を表す。
以下のメンバーは、"signatures" 配列の要素である JSON
オブジェクトで使用するために定義されている。
protected
"protected" メンバーは必須であり、JWS Protected Header
値が空でない場合には、
BASE64URL(UTF8(JWS Protected Header)) の値を含まなければ
ならない。それ以外の場合には、存在してはならない。
これらの Header Parameter 値は完全性保護される。
header
"header" メンバーは、JWS Unprotected Header 値が空でない
場合には必須であり、それ以外の場合には存在してはならない。
この値は、文字列ではなく、エンコードされていない JSON
オブジェクトとして表現される。これらの Header Parameter
値は完全性保護されない。
signature
"signature" メンバーは必須であり、
BASE64URL(JWS Signature) の値を含まなければならない。
各署名／MAC 計算について、"alg" Header Parameter 値が
伝達されるようにするために、
"protected" および "header" メンバーの少なくとも一方が
存在しなければならない。
上記で定義された JSON オブジェクトには、追加のメンバーを
含めることができる。実装がそれらを理解できない場合には、
それらは無視されなければならない。
個々の署名または MAC 値を生成または検証する際に使用される
Header Parameter 値は、次の 2 つの集合の和集合である。
(1) 署名／MAC の配列要素の "protected" メンバーで表現される
JWS Protected Header、(2) "header" メンバー内の
JWS Unprotected Header
Jones, et al. Standards Track [Page 20]
RFC 7515 JSON Web Signature (JWS) May 2015
値である。これらの集合の和集合が JOSE Header を構成する。
2 つの場所における Header Parameter 名は、互いに
重複してはならない。
各 JWS Signature 値は、JWS Compact Serialization の場合と
同様の方法で、対応する JOSE Header 値のパラメータを使用して
計算される。これにより、"signatures" 配列に表現される各
JWS Signature 値は、その署名／MAC 計算に用いられた
JWS Protected Header 値（完全性保護された Header Parameter
値を表す）が JWS Compact Serialization で使用されるものと
一致する限り、JWS Compact Serialization で同じパラメータに
対して計算される値と同一になるという望ましい性質を持つ。
要約すると、一般 JWS JSON Serialization を使用する JWS の
構文は次のとおりである。
{
"payload":"<payload contents>",
"signatures":[
{"protected":"<integrity-protected header 1 contents>",
"header":<non-integrity-protected header 1 contents>,
"signature":"<signature 1 contents>"},
...
{"protected":"<integrity-protected header N contents>",
"header":<non-integrity-protected header N contents>,
"signature":"<signature N contents>"}]
}
一般 JWS JSON Serialization 構文を使用した JWS の例については
Appendix A.6 を参照のこと。
7.2.2. フラット化 JWS JSON Serialization 構文
フラット化 JWS JSON Serialization 構文は、一般構文を基にしつつ、
単一のデジタル署名または MAC の場合に最適化するため、
"signatures" メンバーを削除し、"signatures" 配列で使用される
メンバー（"protected"、"header"、および "signature"）を、
トップレベルの JSON オブジェクト（"payload" メンバーと同じ
レベル）に配置することで、構文をフラット化する。
この構文を使用する場合、"signatures" メンバーは
存在してはならない。これ以外の点については、
フラット化構文を使用する JWS JSON Serialization オブジェクトは、
一般構文を使用するものと同一に処理される。
Jones, et al. Standards Track [Page 21]
RFC 7515 JSON Web Signature (JWS) May 2015
要約すると、フラット化 JWS JSON Serialization を使用する JWS の
構文は次のとおりである。
{
"payload":"<payload contents>",
"protected":"<integrity-protected header contents>",
"header":<non-integrity-protected header contents>,
"signature":"<signature contents>"
}
フラット化 JWS JSON Serialization 構文を使用した JWS の例については
Appendix A.7 を参照のこと。
8. TLS 要件
"jku" および／または "x5u" Header Parameter をサポートする
実装は、TLS をサポートしなければならない。どの TLS バージョンを
実装すべきかは、実装時点における広範な展開状況および既知の
セキュリティ脆弱性に依存して、時間とともに変化する。
本書執筆時点では、TLS バージョン 1.2
[RFC5246]
が最新のバージョンである。
情報漏えいおよび改ざんを防止するために、機密性および完全性の
保護を提供する暗号スイートを使用した TLS によって、
機密性保護を適用しなければならない。現在適切と考えられている
暗号スイートに関する指針については、IETF TLS 作業部会による
現行の公開文書、RFC
6176
[RFC6176]
を含めて参照のこと。また、TLS を使用するソフトウェアおよび
サービスのセキュリティ向上に関する推奨事項については、
「Recommendations for Secure Use of Transport Layer Security (TLS)
and Datagram Transport Layer Security (DTLS)」
[RFC7525]
を参照のこと。
TLS を使用する場合には常に、TLS サーバ証明書にエンコードされた
サービス提供者の識別情報を、
RFC 6125 の Section 6
[RFC6125]
に記述されている手順を用いて検証しなければならない。
9. IANA に関する考慮事項
本仕様によって確立されるすべてのレジストリには、
以下の登録手続きが使用される。
値は、jose-reg-review@ietf.org メーリングリストにおける
3 週間のレビュー期間を経て、1 人以上の指定専門家の助言に基づき、
Specification Required
[RFC5226]
に基づいて登録される。ただし、公開前に値を割り当てることを
可能にするため、指定専門家は、そのような仕様が公開されると
満足できる場合には、登録を承認してもよい。
Jones, et al. Standards Track [Page 22]
RFC 7515 JSON Web Signature (JWS) May 2015
レビューのためにメーリングリストへ送信される登録要求は、
適切な件名（例: 「Request to register header parameter:
example」）を使用するべきである。
レビュー期間中に、指定専門家（Designated Experts）は登録要求を
承認または拒否し、その決定をレビュー用メーリングリストおよび
IANA に通知する。拒否の場合には、その理由を説明し、該当する場合には、
要求を成功させるための提案を含めるべきである。
21 日を超える期間にわたって未決定の登録要求は、解決のために
IESG（iesg@ietf.org メーリングリストを使用）に付託することができる。
指定専門家が適用すべき基準には、提案された登録が既存の機能を
重複していないか、一般的な適用性を持つ可能性があるか、それとも
単一のアプリケーションにのみ有用であるか、ならびに登録記述が
明確であるかを判断することが含まれる。
IANA は、指定専門家からのレジストリ更新のみを受け付けなければならず、
登録に関するすべての要求をレビュー用メーリングリストへ誘導する
べきである。
登録決定について十分に情報に基づいた幅広いレビューを可能にするため、
この仕様を使用する異なるアプリケーションの観点を代表できる
複数の指定専門家を任命することが提案される。
特定の専門家にとって、登録決定が利益相反を生じさせると
受け取られ得る場合には、その専門家は他の専門家の判断に
委ねるべきである。
9.1. JSON Web Signature および暗号化ヘッダパラメータレジストリ
本仕様は、ヘッダパラメータ名のための IANA
「JSON Web Signature and Encryption Header Parameters」
レジストリを確立する。このレジストリは、ヘッダパラメータ名と、
それを定義する仕様への参照を記録する。
同一のヘッダパラメータ名は、パラメータの使用方法が仕様間で
互換である限り、複数回登録することができる。
同一のヘッダパラメータ名に対する異なる登録は、通常、
異なる Header Parameter Usage Locations の値を使用する。
9.1.1. 登録テンプレート
Header Parameter Name:
要求される名前（例: 「kid」）。
本仕様の中核的な目標の 1 つは、結果として得られる表現を
コンパクトにすることであるため、やむを得ない理由がない限り、
名前は短いもの（8 文字を超えない）とすることが
RECOMMENDED される。この名前は
Jones, et al. Standards Track [Page 23]
RFC 7515 JSON Web Signature (JWS) May 2015
大文字と小文字を区別する。
指定専門家が例外を認めるに足る十分な理由があると述べない限り、
大文字小文字を区別しない形で、他の登録済み名称と一致してはならない。
Header Parameter Description:
ヘッダパラメータの簡潔な説明（例: 「Key ID」）。
Header Parameter Usage Location(s):
ヘッダパラメータの使用箇所。値は「JWS」または「JWE」の
1 つ以上であるべきである。
Change Controller:
Standards Track の RFC の場合は「IESG」を記載する。
それ以外の場合は、責任主体の名称を記載する。
その他の詳細（例: 郵送先住所、メールアドレス、
ホームページ URI）を含めてもよい。
Specification Document(s):
パラメータを規定する文書への参照。
可能であれば、文書の写しを取得できる URI を含める。
関連する節の指示を含めてもよいが、必須ではない。
9.1.2. 初期レジストリ内容
本節では、本レジストリにおいて
Section 4.1 で定義されたヘッダパラメータ名を登録する。
o Header Parameter Name: "alg"
o Header Parameter Description: Algorithm
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): Section 4.1.1 of RFC 7515
o Header Parameter Name: "jku"
o Header Parameter Description: JWK Set URL
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): Section 4.1.2 of RFC 7515
o Header Parameter Name: "jwk"
o Header Parameter Description: JSON Web Key
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): Section 4.1.3 of RFC 7515
Jones, et al. Standards Track [Page 24]
RFC 7515 JSON Web Signature (JWS) May 2015
o Header Parameter Name: "kid"
o Header Parameter Description: Key ID
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): Section 4.1.4 of RFC 7515
o Header Parameter Name: "x5u"
o Header Parameter Description: X.509 URL
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): Section 4.1.5 of RFC 7515
o Header Parameter Name: "x5c"
o Header Parameter Description: X.509 証明書チェーン
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): Section 4.1.6 of RFC 7515
o Header Parameter Name: "x5t"
o Header Parameter Description: X.509 証明書 SHA-1 サムプリント
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): Section 4.1.7 of RFC 7515
o Header Parameter Name: "x5t#S256"
o Header Parameter Description: X.509 証明書 SHA-256 サムプリント
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): Section 4.1.8 of RFC 7515
o Header Parameter Name: "typ"
o Header Parameter Description: Type
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): Section 4.1.9 of RFC 7515
o Header Parameter Name: "cty"
o Header Parameter Description: Content Type
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): Section 4.1.10 of RFC 7515
o Header Parameter Name: "crit"
o Header Parameter Description: Critical
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): Section 4.1.11 of RFC 7515
Jones, et al. Standards Track [Page 25]
RFC 7515 JSON Web Signature (JWS) May 2015
9.2. メディアタイプ登録
9.2.1. レジストリ内容
本節では、「application/jose」メディアタイプ
[RFC2046] を、
RFC 6838 [RFC6838] に記載された方法に従って、
「Media Types」レジストリ
[IANA.MediaTypes] に登録する。
これは、JWS Compact Serialization または JWE Compact Serialization
を用いた JWS または JWE であることを示すために使用できる。
また本節では、「application/jose+json」メディアタイプを
「Media Types」レジストリに登録する。これは、
JWS JSON Serialization または JWE JSON Serialization を用いた
JWS または JWE であることを示すために使用できる。
o Type name: application
o Subtype name: jose
o Required parameters: n/a
o Optional parameters: n/a
o Encoding considerations: 8bit; application/jose の値は、
base64url エンコードされた一連の値（空文字列となるものを
含む場合がある）としてエンコードされ、各値は単一の
ピリオド（'.'）文字によって区切られる。
o Security considerations: RFC 7515 の
Security Considerations 節を参照。
o Interoperability considerations: n/a
o Published specification: RFC 7515
o Applications that use this media type: OpenID Connect、Mozilla
Persona、Salesforce、Google、Android、Windows Azure、Xbox One、
Amazon Web Services、ならびに JWT を使用する多数のその他の
アプリケーション
o Fragment identifier considerations: n/a
o Additional information:
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
o Person & email address to contact for further information:
Michael B. Jones, mbj@microsoft.com
o Intended usage: COMMON
o Restrictions on usage: none
o Author: Michael B. Jones, mbj@microsoft.com
o Change Controller: IESG
o Provisional registration? No
Jones, et al. Standards Track [Page 26]
RFC 7515 JSON Web Signature (JWS) May 2015
o Type name: application
o Subtype name: jose+json
o Required parameters: n/a
o Optional parameters: n/a
o Encoding considerations: 8bit; application/jose+json の値は
JSON オブジェクトとして表現される。JSON オブジェクトには
UTF-8 エンコーディングを使用することが
SHOULD である。
o Security considerations: RFC 7515 の
Security Considerations 節を参照。
o Interoperability considerations: n/a
o Published specification: RFC 7515
o Applications that use this media type: Nimbus JOSE + JWT library
o Fragment identifier considerations: n/a
o Additional information:
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
o Person & email address to contact for further information:
Michael B. Jones, mbj@microsoft.com
o Intended usage: COMMON
o Restrictions on usage: none
o Author: Michael B. Jones, mbj@microsoft.com
o Change Controller: IESG
o Provisional registration? No
10. セキュリティに関する考慮事項
暗号アプリケーションに関係するすべてのセキュリティ上の問題は、
JWS/JWE/JWK エージェントによって対処されなければならない。
これらの問題には、ユーザの非対称秘密鍵および対称秘密鍵を
保護することや、さまざまな攻撃に対する対策を講じることが含まれる。
「XML Signature Syntax and Processing Version 2.0」
[W3C.NOTE-xmldsig-core2-20130411] に記載された
セキュリティ上の考慮事項は、XML 固有のものを除き、
本仕様にも同様に適用される。
同様に、「XML Signature Best Practices」
[W3C.NOTE-xmldsig-bestpractices-20130411] に記載された
多くのベストプラクティスも、XML 固有のものを除き、
本仕様に適用される。
10.1. 鍵のエントロピーおよび乱数値
鍵の強度は、それを生成するために使用されるエントロピー量に
依存する。すべての鍵には最低 128 ビットのエントロピーを
使用するべきであり、アプリケーションの文脈によっては、
さらに多くが必要となる場合がある。
Jones, et al. Standards Track [Page 27]
RFC 7515 JSON Web Signature (JWS) May 2015
実装は、公開鍵／秘密鍵ペア、MAC 鍵、およびパディング値を
ランダムに生成しなければならない。
不十分な擬似乱数生成器（PRNG）を用いて暗号鍵を生成すると、
セキュリティがほとんど、あるいはまったく得られない結果となり得る。
攻撃者は、鍵が生成された PRNG 環境を再現し、
鍵空間全体を総当たりで探索するよりもはるかに容易に、
得られる小さな候補集合を探索できる可能性がある。
高品質な乱数の生成は困難である。
RFC 4086 [RFC4086] は、
この分野において重要な指針を提供している。
10.2. 鍵の保護
実装は、署名者の秘密鍵を保護しなければならない。
署名者の秘密鍵が漏洩すると、攻撃者が署名者になりすますことが可能となる。
実装は、MAC 鍵を保護しなければならない。
MAC 鍵が漏洩すると、認証された内容が検知されることなく
改ざんされる結果となり得る。
10.3. 鍵の発行元認証
公開鍵を取得するために用いられる鍵管理手法は、
鍵の発行元を認証しなければならない。
そうでなければ、どの主体がメッセージに署名したのかが不明となる。
同様に、MAC 鍵を配布するために用いられる鍵管理手法は、
データの発行元認証を提供しなければならない。
そうでなければ、内容は不明な発行元からの完全性を伴って
配信されたものとなる。
10.4. 暗号アルゴリズムの柔軟性
暗号アルゴリズムの柔軟性に関するセキュリティ上の考慮事項については、
[JWA] の Section 8.1 を参照。
10.5. デジタル署名と MAC の相違点
MAC とデジタル署名はいずれも完全性検証に使用できるが、
それぞれが提供するセキュリティ特性には重要な違いがある。
これらは、プロトコルの設計や使用するアルゴリズムの選択において
考慮される必要がある。
署名と MAC の双方は完全性検証を提供する。
すなわち、完全性値が計算された後にメッセージが改変されていないことを
検証する。しかし、MAC が発行元識別を提供できるのは、
特定の条件下に限られる。
通常、署名に用いられる秘密鍵は単一の主体のみが保持していると
想定される（分散された主体の場合を除く）が、
Jones, et al. Standards Track [Page 28]
RFC 7515 JSON Web Signature (JWS) May 2015
（複製サーバの場合を含む）MAC 鍵は、完全性の計算および検証に
使用するすべての主体が保持する必要がある。
MAC の検証は、その対称 MAC 鍵を知っているいずれかの主体が
メッセージを生成したことの裏付けしか提供しない。
これは、MAC 鍵が 2 つの主体のみが知っており、かつ受信者が
自身ではメッセージを生成していないことを知っている場合にのみ、
発行元を特定できることを意味する。
MAC の検証は、第三者に対して発行元を証明するためには
使用できない。
10.6. アルゴリズムの検証
一部のアルゴリズムにおけるデジタル署名表現には、
署名値の内部に使用されたアルゴリズムに関する情報が含まれている。
例えば、RSASSA-PKCS1-v1_5 [RFC3447] によって生成された署名は、
使用されたハッシュ関数を符号化しており、多くのライブラリは、
署名を検証する際に署名内で指定されたハッシュアルゴリズムを
実際に使用する。
そのようなライブラリを使用する場合、アルゴリズム検証の一環として、
実装は、署名内に符号化されたアルゴリズム情報が
「alg」ヘッダパラメータで指定されたものと一致することを
MUST 確認しなければならない。
これが行われない場合、攻撃者は強力なハッシュアルゴリズムを
使用したと主張しながら、実際には署名値に表現された
弱いアルゴリズムを使用することが可能となる。
10.7. アルゴリズム保護
JWS のいくつかの利用形態では、アルゴリズム置換攻撃の
リスクが存在する。この攻撃では、攻撃者が既存のデジタル署名値を
異なる署名アルゴリズムと組み合わせることで、
署名者が実際には署名していないものに署名したかのように
見せかけることができる。
これらの攻撃は、Cryptographic Message Syntax (CMS)
[RFC6211] の文脈において詳細に議論されている。
このリスクは、以下のすべてが真である場合に生じる。
o 署名の検証者が複数のアルゴリズムをサポートしている。
o 既存の署名が与えられたとき、攻撃者が、
異なるアルゴリズムで同一の署名値を生成する別のペイロードを
見つけることができる。
o 攻撃者が作成したペイロードが、アプリケーションの文脈において
有効である。
アプリケーションがアルゴリズム置換攻撃を軽減する方法はいくつかある。
o 置換攻撃に対して脆弱でないデジタル署名アルゴリズムのみを使用する。
置換攻撃は、受信者が受け入れるハッシュ関数に対して
攻撃者がプレイメージを計算できる場合にのみ実現可能である。
JWA で定義されたすべての署名アルゴリズムは SHA-2 ハッシュを使用しており、
本書執筆時点では既知のプレイメージ攻撃は存在しない。
Jones, et al. Standards Track [Page 29]
RFC 7515 JSON Web Signature (JWS) May 2015
o 「alg」ヘッダパラメータを JWS Protected Header に含めることを
要求する。
（これは、JWS Compact Serialization を使用する場合には常に
成立し、CMS [RFC6211] が採用している方法である。）
o アプリケーションのペイロードにアルゴリズムを含むフィールドを
追加し、検証時にそれが「alg」ヘッダパラメータと一致することを
要求する。
（これは、PKIX [RFC5280] が採用している方法である。）
10.8. 選択平文攻撃
JWS の作成者は、第三者が、第三者によって制御されない
エントロピーを追加することなく、任意の内容をメッセージに
挿入できるようにしてはならない。
10.9. タイミング攻撃
暗号アルゴリズムが、成功した操作と失敗した操作とで
異なる時間を要するように実装されている場合、
攻撃者はその時間差を利用して、使用されている鍵に関する
情報を取得できる可能性がある。
したがって、そのような時間差は回避されなければならない。
10.10. リプレイ防止
本仕様の直接の対象範囲ではないが、JWS（または JWE）オブジェクトを
使用するアプリケーションは、JWS（または JWE）メッセージ内の
完全性保護された内容として一意のメッセージ識別子を含め、
受信者がそのメッセージが以前に受信または処理されていないことを
検証することで、リプレイ攻撃を防止できる。
10.11. SHA-1 証明書サムプリント
互換性の理由から、「x5t」
（X.509 証明書 SHA-1 サムプリント）値の計算には
SHA-1 ハッシュが使用されている。
将来、SHA-1 ハッシュ衝突を生成する効果的な手段が開発され、
攻撃者が特定のシステム上で既知の証明書の使用を妨害したいと
考えた場合、同一の SHA-1 ハッシュ値を持つ別の証明書を作成し、
それを被害者が使用する証明書ストアに追加することで、
これを達成できる可能性がある。
この攻撃が成功する前提条件は、攻撃者が被害者の
証明書ストアに対する書き込みアクセスを有していることである。
Jones, et al. Standards Track [Page 30]
RFC 7515 JSON Web Signature (JWS) May 2015
代替として、「x5t#S256」
（X.509 証明書 SHA-256 サムプリント）ヘッダパラメータを、
「x5t」の代わりに使用することができる。
しかし、本書執筆時点では、SHA-256 証明書サムプリントを
サポートする開発プラットフォームは知られていない。
10.12. JSON に関するセキュリティ考慮事項
厳格な JSON [RFC7159] 検証は、
セキュリティ要件である。
不正な形式の JSON を受信した場合、生成者の意図を
信頼性高く判断することは不可能となる。
使用される JSON パーサが不正な JSON 構文を拒否しない場合、
あいまいで潜在的に悪用可能な状況が生じ得る。
特に、RFC 7159 で定義された JSON-text 構文に
準拠しない JSON 入力は、JSON パーサによって
MUST 全体として拒否されなければならない。
「The JavaScript Object Notation (JSON) Data Interchange Format」
の Section 4 [RFC7159] では、
「オブジェクト内の名前は一意であるべきである（SHOULD）」と
述べられているが、本仕様では次のように規定している。
JOSE ヘッダ内のヘッダパラメータ名は一意でなければならない。
JWS パーサは、重複するヘッダパラメータ名を含む JWS を
拒否するか、または ECMAScript 5.1
[ECMAScript] の
Section 15.12（「JSON オブジェクト」）で
規定されているとおり、語彙的に最後の重複メンバー名のみを
返す JSON パーサを使用しなければならない。
したがって、本仕様では、[RFC7159] の Section 4 における
「SHOULD」を、生成者に対しては「MUST」として扱い、
消費者に対しては「MUST」として扱うか、または
ECMAScript 5.1 で規定された方法で扱うことを要求する。
JSON パーサがメンバー名の一意性を強制しない場合や、
重複するメンバー名に対して予測不能な値を返す場合、
あいまいで潜在的に悪用可能な状況が生じ得る。
一部の JSON パーサは、有効な入力の後に余分な
意味のある文字が含まれていても、それを拒否しない場合がある。
例えば、入力「{"tag":"value"}ABCD」は、
有効な JSON-text オブジェクトの後に余分な文字列「ABCD」が
続いている。
実装は、このような入力を含む JWS を無効であると
MUST 判断しなければならない。
10.13. Unicode 比較に関するセキュリティ考慮事項
ヘッダパラメータ名およびアルゴリズム名は Unicode 文字列である。
セキュリティ上の理由から、これらの名前の表現は、
エスケープ処理（RFC 7159 の Section 8.3 に従う）を
実行した後に、逐語的に比較されなければならない。
これは例えば、これらの JSON 文字列が
("sig", "\u0073ig") のように等しいと比較される一方で、
("SIG", "Sig", "si\u0047") は、最初の集合とも、
互い同士とも等しくないと比較されなければならないことを意味する。
Jones, et al. Standards Track [Page 31]
RFC 7515 JSON Web Signature (JWS) May 2015
JSON 文字列には、Unicode 基本多言語面の外にある文字を
含めることができる。
例えば、ト音記号（U+1D11E）は、
JSON 文字列内で "\uD834\uDD1E" として表現される場合がある。
理想的には、JWS 実装は、基本多言語面外の文字が
正しく保持および比較されることを
SHOULD 確保するべきである。
代替として、これらの文字が、基盤となる JSON 実装に存在する
制限を顕在化させるために処理できない場合には、
それらを含む入力は MUST 拒否されなければならない。
11. 参考文献
11.1. 規定参照
[ECMAScript] Ecma International, 「ECMAScript Language Specification,
5.1 Edition」, ECMA 262, June 2011,
<http://www.ecma-international.org/ecma-262/5.1/
ECMA-262.pdf>.
[IANA.MediaTypes]
IANA, 「Media Types」,
<http://www.iana.org/assignments/media-types>.
[ITU.X690.2008]
International Telecommunications Union,
「Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)」,
ITU-T Recommendation X.690, 2008.
[JWA] Jones, M., 「JSON Web Algorithms (JWA)」,
RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<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>.
[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>.
[RFC2045] Freed, N. and N. Borenstein,
「Multipurpose Internet Mail Extensions (MIME)
Part One: Format of Internet Message Bodies」,
RFC 2045,
DOI 10.17487/RFC2045, November 1996,
<http://www.rfc-editor.org/info/rfc2045>.
Jones, et al. Standards Track [Page 32]
RFC 7515 JSON Web Signature (JWS) May 2015
[RFC2046] Freed, N. and N. Borenstein,
「Multipurpose Internet Mail Extensions (MIME)
Part Two: Media Types」,
RFC 2046,
DOI 10.17487/RFC2046, November 1996,
<http://www.rfc-editor.org/info/rfc2046>.
[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>.
[RFC2818] Rescorla, E.,
「HTTP Over TLS」,
RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
「Uniform Resource Identifier (URI): Generic Syntax」,
STD 66, RFC 3986,
DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC4648] Josefsson, S.,
「The Base16, Base32, and Base64 Data Encodings」,
RFC 4648,
DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC4945] Korver, B.,
「The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX」,
RFC 4945,
DOI 10.17487/RFC4945, August 2007,
<http://www.rfc-editor.org/info/rfc4945>.
[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>.
[RFC5246] Dierks, T. and E. Rescorla,
「The Transport Layer Security (TLS) Protocol
Version 1.2」,
RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[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>.
Jones, et al. Standards Track [Page 33]
RFC 7515 JSON Web Signature (JWS) May 2015
[RFC6125] Saint-Andre, P. および J. Hodges,
「トランスポート層セキュリティ (TLS) の文脈において
X.509 (PKIX) 証明書を用いた、
インターネット公開鍵基盤内での
ドメインベースアプリケーションサービス
アイデンティティの表現および検証」,
RFC 6125, DOI 10.17487/RFC6125,
2011年3月,
<http://www.rfc-editor.org/info/rfc6125>.
[RFC6176] Turner, S. および T. Polk,
「セキュアソケット層 (SSL) バージョン 2.0 の禁止」,
RFC 6176,
DOI 10.17487/RFC6176,
2011年3月,
<http://www.rfc-editor.org/info/rfc6176>.
[RFC7159] Bray, T., 編,
「JavaScript Object Notation (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/>.
11.2. 参考文献
[CanvasApp] Facebook,
「Canvas Applications」,
<http://developers.facebook.com/docs/authentication/
canvas>.
[JSS] Bradley, J. および N. Sakimura, 編,
「JSON Simple Sign」,
2010年9月,
<http://jsonenc.info/jss/1.0/>.
[JWE] Jones, M. および J. Hildebrand,
「JSON Web Encryption (JWE)」,
RFC 7516,
DOI 10.17487/RFC7516,
2015年5月,
<http://www.rfc-editor.org/info/rfc7516>.
[JWT] Jones, M., Bradley, J., および N. Sakimura,
「JSON Web Token (JWT)」,
RFC 7519,
DOI 10.17487/RFC7519,
2015年5月,
<http://www.rfc-editor.org/info/rfc7519>.
[MagicSignatures]
Panzer, J., 編, Laurie, B., および D. Balfanz,
「Magic Signatures」,
2011年1月,
<http://salmon-protocol.googlecode.com/svn/trunk/
draft-panzer-magicsig-01.html>.
[RFC2104] Krawczyk, H., Bellare, M., および R. Canetti,
「HMAC: メッセージ認証のための
鍵付きハッシュ」,
RFC 2104,
DOI 10.17487/RFC2104,
1997年2月,
<http://www.rfc-editor.org/info/rfc2104>.
Jones, et al. Standards Track [Page 34]
RFC 7515 JSON Web Signature (JWS) May 2015
[RFC3447] Jonsson, J. および B. Kaliski,
「公開鍵暗号標準 (PKCS) #1:
RSA 暗号仕様 バージョン 2.1」,
RFC 3447,
DOI 10.17487/RFC3447,
2003年2月,
<http://www.rfc-editor.org/info/rfc3447>.
[RFC4086] Eastlake 3rd, D., Schiller, J., および S. Crocker,
「セキュリティのための乱数要件」,
BCP 106,
RFC 4086,
DOI 10.17487/RFC4086,
2005年6月,
<http://www.rfc-editor.org/info/rfc4086>.
[RFC4122] Leach, P., Mealling, M., および R. Salz,
「汎用一意識別子 (UUID)
URN 名前空間」,
RFC 4122,
DOI 10.17487/RFC4122,
2005年7月,
<http://www.rfc-editor.org/info/rfc4122>.
[RFC5226] Narten, T. および H. Alvestrand,
「RFC における IANA Considerations
セクション記述のための指針」,
BCP 26,
RFC 5226,
DOI 10.17487/RFC5226,
2008年5月,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6211] Schaad, J.,
「暗号化メッセージ構文 (CMS)
アルゴリズム識別子保護属性」,
RFC 6211,
DOI 10.17487/RFC6211,
2011年4月,
<http://www.rfc-editor.org/info/rfc6211>.
[RFC6838] Freed, N., Klensin, J., および T. Hansen,
「メディアタイプ仕様および
登録手続き」,
BCP 13,
RFC 6838,
DOI 10.17487/RFC6838,
2013年1月,
<http://www.rfc-editor.org/info/rfc6838>.
[RFC7525] Sheffer, Y., Holz, R., および P. Saint-Andre,
「トランスポート層セキュリティ (TLS)
およびデータグラムトランスポート層
セキュリティ (DTLS) の安全な利用に関する推奨事項」,
BCP 195,
RFC 7525,
DOI 10.17487/RFC7525,
2015年5月,
<http://www.rfc-editor.org/info/rfc7525>.
[SHS] National Institute of Standards and Technology,
「Secure Hash Standard (SHS)」,
FIPS PUB 180-4,
2012年3月,
<http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>.
[W3C.NOTE-xmldsig-bestpractices-20130411]
Hirsch, F. および P. Datta,
「XML Signature Best Practices」,
World Wide Web Consortium Note
NOTE-xmldsig-bestpractices-20130411,
2013年4月,
<http://www.w3.org/TR/2013/
NOTE-xmldsig-bestpractices-20130411/>.
Jones, et al. Standards Track [Page 35]
RFC 7515 JSON Web Signature (JWS) May 2015
[W3C.NOTE-xmldsig-core2-20130411]
Eastlake, D., Reagle, J., Solo, D., Hirsch, F.,
Roessler, T., Yiu, K., Datta, P., および S. Cantor,
「XML Signature Syntax and Processing Version 2.0」,
World Wide Web Consortium Note
NOTE-xmldsig-core2-20130411,
2013年4月,
<http://www.w3.org/TR/2013/NOTE-xmldsig-core2-20130411/>.
Jones, et al. Standards Track [Page 36]
RFC 7515 JSON Web Signature (JWS) May 2015
Appendix A. JWS の例
本節では、いくつかの JWS の例を示す。最初の 3 つの例はいずれも
JSON Web Token (JWT) [JWT] を表しているが、
Appendix A.4 に示すように、ペイロードは任意のオクテット列で
かまわない。
A.1. HMAC SHA-256 を使用した JWS の例
A.1.1. エンコード
次の例の JWS Protected Header は、データ構造が JWT
[JWT] であることを宣言しており、JWS Signing Input は
HMAC SHA-256 アルゴリズムを用いて保護されている。
{"typ":"JWT",
"alg":"HS256"}
上記の JSON オブジェクト表現における潜在的な曖昧さを排除するため、
本例で使用されている UTF8(JWS Protected Header) を表す実際の
オクテット列も以下に示す。(なお、曖昧さは、改行コードの
プラットフォーム差異 (CRLF と LF)、行頭や行末の空白の違い、
最終行に終端改行があるかどうか、その他の要因によって生じ得る。
本例で用いている表現では、1 行目には前後の空白はなく、
1 行目と 2 行目の間には CRLF の改行 (13, 10) があり、2 行目には
行頭に 1 つの空白 (32) があり行末の空白はなく、最終行には
終端改行は存在しない。) 本例における UTF8(JWS Protected Header)
を表すオクテット列 (JSON 配列表記) は次のとおりである。
[123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32,
34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125]
この JWS Protected Header を BASE64URL(UTF8(JWS Protected
Header)) としてエンコードすると、次の値になる。
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
本例で使用される JWS Payload は、以下に示す JSON オブジェクトの
UTF-8 表現のオクテットである。(なお、ペイロードは任意の
base64url エンコードされたオクテット列でよく、必ずしも
base64url エンコードされた JSON オブジェクトである必要はない。)
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
Jones, et al. Standards Track [Page 37]
RFC 7515 JSON Web Signature (JWS) May 2015
上記の JSON オブジェクトについて、本例で使用されている UTF-8 表現の
オクテット列は次のとおりであり、これが JWS Payload である。
[123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10,
32, 34, 101, 120, 112, 34, 58, 49, 51, 48, 48, 56, 49, 57, 51, 56,
48, 44, 13, 10, 32, 34, 104, 116, 116, 112, 58, 47, 47, 101, 120, 97,
109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111,
111, 116, 34, 58, 116, 114, 117, 101, 125]
この JWS Payload を BASE64URL(UTF8(JWS Payload)) として
エンコードすると、次の値になる
(表示目的のみで改行を挿入している)。
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
これらを BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) として結合すると、次の文字列になる
(表示目的のみで改行を挿入している)。
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
得られる JWS Signing Input の値は、上記文字列の ASCII 表現であり、
次のオクテット列となる (JSON 配列表記)。
[101, 121, 74, 48, 101, 88, 65, 105, 79, 105, 74, 75, 86, 49, 81,
105, 76, 65, 48, 75, 73, 67, 74, 104, 98, 71, 99, 105, 79, 105, 74,
73, 85, 122, 73, 49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51,
77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67,
74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84,
107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100,
72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76,
109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73,
106, 112, 48, 99, 110, 86, 108, 102, 81]
HMAC は鍵を用いて生成される。本例では、以下に示す
JSON Web Key [JWK] 形式で表される対称鍵を使用する
(表示目的のみで値中に改行を挿入している)。
{"kty":"oct",
"k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75
aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow"
}
Jones, et al. Standards Track [Page 38]
RFC 7515 JSON Web Signature (JWS) May 2015
この鍵を用いて JWS Signing Input に対して HMAC SHA-256
アルゴリズムを実行すると、次の JWS Signature のオクテット列が
得られる。
[116, 24, 223, 180, 151, 153, 224, 37, 79, 250, 96, 125, 216, 173,
187, 186, 22, 212, 37, 77, 105, 214, 191, 240, 91, 88, 5, 88, 83,
132, 141, 121]
この JWS Signature を BASE64URL(JWS Signature) として
エンコードすると、次の値になる。
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
これらの値を Header.Payload.Signature の順で、各部分の間に
ピリオド ('.') を入れて連結すると、JWS Compact Serialization
を用いた完全な JWS 表現が得られる
(表示目的のみで改行を挿入している)。
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
A.1.2. 検証
"alg" Header Parameter が "HS256" であるため、JWS Signature に
含まれる HMAC SHA-256 の値を検証する。
HMAC の値を検証するには、正しい鍵と JWS Signing Input
(JWS Compact Serialization 表現の先頭から 2 つ目のピリオド文字を
含まない直前までの部分文字列) を入力として HMAC SHA-256 関数を
再度実行し、その出力が JWS Signature
(JWS 表現にエンコードされている値を base64url デコードしたもの)
と一致するかどうかを判定する。完全に一致すれば、HMAC は
検証されたことになる。
A.2. RSASSA-PKCS1-v1_5 SHA-256 を使用した JWS の例
A.2.1. エンコード
本例の JWS Protected Header は、前の例と 2 点で異なる。
第 1 に、使用するアルゴリズムが異なるため、"alg" の値が異なる。
第 2 に、説明目的のみとして、オプションの "typ" (type)
Header Parameter を使用していない。
(この違いは、使用されるアルゴリズムとは関係ない。)
使用される JWS Protected Header は次のとおりである。
Jones, et al. Standards Track [Page 39]
RFC 7515 JSON Web Signature (JWS) May 2015
{"alg":"RS256"}
本例における UTF8(JWS Protected Header) を表すオクテット列
(JSON 配列表記) は次のとおりである。
[123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 50, 53, 54, 34, 125]
この JWS Protected Header を BASE64URL(UTF8(JWS Protected
Header)) としてエンコードすると、次の値になる。
eyJhbGciOiJSUzI1NiJ9
本例で使用される JWS Payload は、前の例と同一であり、以下に示す。
したがって、BASE64URL(JWS Payload) の値も同一となるため、
ここではその計算を繰り返さない。
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
これらを BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) として結合すると、次の文字列になる
(表示目的のみで改行を挿入している)。
eyJhbGciOiJSUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
得られる JWS Signing Input の値は、上記文字列の ASCII 表現であり、
次のオクテット列となる。
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 122, 73,
49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105,
74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72,
65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68,
65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76,
121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118,
98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48,
99, 110, 86, 108, 102, 81]
Jones, et al. Standards Track [Page 40]
RFC 7515 JSON Web Signature (JWS) May 2015
本例では、以下に示す JSON Web Key [JWK]
形式で表される RSA 鍵を使用する
(表示目的のみで値中に改行を挿入している)。
{"kty":"RSA",
"n":"ofgWCuLjybRlzo0tZWJjNiuSfb4p4fAkd_wWJcyQoTbji9k0l8W26mPddx
HmfHQp-Vaw-4qPCJrcS2mJPMEzP1Pt0Bm4d4QlL-yRT-SFd2lZS-pCgNMs
D1W_YpRPEwOWvG6b32690r2jZ47soMZo9wGzjb_7OMg0LOL-bSf63kpaSH
SXndS5z5rexMdbBYUsLA9e-KXBdQOS-UTo7WTBEMa2R2CapHg665xsmtdV
MTBQY4uDZlxvb3qCo5ZwKh9kG4LT6_I5IhlJH7aGhyxXFvUK-DWNmoudF8
NAco9_h9iaGNj8q2ethFkMLs91kzk2PAcDTW9gb54h4FRWyuXpoQ",
"e":"AQAB",
"d":"Eq5xpGnNCivDflJsRQBXHx1hdR1k6Ulwe2JZD50LpXyWPEAeP88vLNO97I
jlA7_GQ5sLKMgvfTeXZx9SE-7YwVol2NXOoAJe46sui395IW_GO-pWJ1O0
BkTGoVEn2bKVRUCgu-GjBVaYLU6f3l9kJfFNS3E0QbVdxzubSu3Mkqzjkn
439X0M_V51gfpRLI9JYanrC4D4qAdGcopV_0ZHHzQlBjudU2QvXt4ehNYT
CBr6XCLQUShb1juUO1ZdiYoFaFQT5Tw8bGUl_x_jTj3ccPDVZFD9pIuhLh
BOneufuBiB4cS98l2SR_RQyGWSeWjnczT0QU91p1DhOVRuOopznQ",
"p":"4BzEEOtIpmVdVEZNCqS7baC4crd0pqnRH_5IB3jw3bcxGn6QLvnEtfdUdi
YrqBdss1l58BQ3KhooKeQTa9AB0Hw_Py5PJdTJNPY8cQn7ouZ2KKDcmnPG
BY5t7yLc1QlQ5xHdwW1VhvKn-nXqhJTBgIPgtldC-KDV5z-y2XDwGUc",
"q":"uQPEfgmVtjL0Uyyx88GZFF1fOunH3-7cepKmtH4pxhtCoHqpWmT8YAmZxa
ewHgHAjLYsp1ZSe7zFYHj7C6ul7TjeLQeZD_YwD66t62wDmpe_HlB-TnBA
-njbglfIsRLtXlnDzQkv5dTltRJ11BKBBypeeF6689rjcJIDEz9RWdc",
"dp":"BwKfV3Akq5_MFZDFZCnW-wzl-CCo83WoZvnLQwCTeDv8uzluRSnm71I3Q
CLdhrqE2e9YkxvuxdBfpT_PI7Yz-FOKnu1R6HsJeDCjn12Sk3vmAktV2zb
34MCdy7cpdTh_YVr7tss2u6vneTwrA86rZtu5Mbr1C1XsmvkxHQAdYo0",
"dq":"h_96-mK1R_7glhsum81dZxjTnYynPbZpHziZjeeHcXYsXaaMwkOlODsWa
7I9xXDoRwbKgB719rrmI2oKr6N3Do9U0ajaHF-NKJnwgjMd2w9cjz3_-ky
NlxAr2v4IKhGNpmM5iIgOS1VZnOZ68m6_pbLBSp3nssTdlqvd0tIiTHU",
"qi":"IYd7DHOhrWvxkwPQsRM2tOgrjbcrfvtQJipd-DlcxyVuuM9sQLdgjVk2o
y26F0EmpScGLq2MowX7fhd_QJQ3ydy5cY7YIBi87w93IKLEdfnbJtoOPLU
W0ITrJReOgo1cq9SbsxYawBgfp_gh6A5603k2-ZQwVK0JKSHuLFkuQ3U"
}
Jones, et al. Standards Track [Page 41]
RFC 7515 JSON Web Signature (JWS) May 2015
次に、この RSA 秘密鍵を RSA 署名関数に渡す。この関数は、ハッシュ種別
SHA-256 と JWS Signing Input も入力として受け取る。デジタル署名の
結果はオクテット列であり、ビッグエンディアン整数を表す。本例では、
次のとおりである。
[112, 46, 33, 137, 67, 232, 143, 209, 30, 181, 216, 45, 191, 120, 69,
243, 65, 6, 174, 27, 129, 255, 247, 115, 17, 22, 173, 209, 113, 125,
131, 101, 109, 66, 10, 253, 60, 150, 238, 221, 115, 162, 102, 62, 81,
102, 104, 123, 0, 11, 135, 34, 110, 1, 135, 237, 16, 115, 249, 69,
229, 130, 173, 252, 239, 22, 216, 90, 121, 142, 232, 198, 109, 219,
61, 184, 151, 91, 23, 208, 148, 2, 190, 237, 213, 217, 217, 112, 7,
16, 141, 178, 129, 96, 213, 248, 4, 12, 167, 68, 87, 98, 184, 31,
190, 127, 249, 217, 46, 10, 231, 111, 36, 242, 91, 51, 187, 230, 244,
74, 230, 30, 177, 4, 10, 203, 32, 4, 77, 62, 249, 18, 142, 212, 1,
48, 121, 91, 212, 189, 59, 65, 238, 202, 208, 102, 171, 101, 25, 129,
253, 228, 141, 247, 127, 55, 45, 195, 139, 159, 175, 221, 59, 239,
177, 139, 93, 163, 204, 60, 46, 176, 47, 158, 58, 65, 214, 18, 202,
173, 21, 145, 18, 115, 160, 95, 35, 185, 232, 56, 250, 175, 132, 157,
105, 132, 41, 239, 90, 30, 136, 121, 130, 54, 195, 212, 14, 96, 69,
34, 165, 68, 200, 242, 122, 122, 45, 184, 6, 99, 209, 108, 247, 202,
234, 86, 222, 64, 92, 178, 33, 90, 69, 178, 194, 85, 102, 181, 90,
193, 167, 72, 160, 112, 223, 200, 163, 42, 70, 149, 67, 208, 25, 238,
251, 71]
この署名を BASE64URL(JWS Signature) としてエンコードすると、
次の値が生成される (表示目的のみで改行を挿入している)。
cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7
AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4
BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K
0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv
hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB
p0igcN_IoypGlUPQGe77Rw
Jones, et al. Standards Track [Page 42]
RFC 7515 JSON Web Signature (JWS) May 2015
これらの値を Header.Payload.Signature の順で、各部分の間に
ピリオド ('.') を入れて連結すると、JWS Compact Serialization
を用いた完全な JWS 表現が得られる
(表示目的のみで改行を挿入している)。
eyJhbGciOiJSUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7
AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4
BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K
0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv
hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB
p0igcN_IoypGlUPQGe77Rw
A.2.2. 検証
"alg" Header Parameter が "RS256" であるため、JWS Signature に
含まれる RSASSA-PKCS1-v1_5 SHA-256 デジタル署名を検証する。
JWS Signature の検証は、前の例とはやや異なる。公開鍵 (n, e)、
JWS Signature (JWS 表現にエンコードされている値を base64url
デコードしたもの)、および JWS Signing Input
(JWS Compact Serialization 表現の先頭から 2 つ目のピリオド文字を
含まない直前までの部分文字列) を、SHA-256 ハッシュ関数を使用する
よう構成された RSASSA-PKCS1-v1_5 署名検証器に渡す。
A.3. ECDSA P-256 SHA-256 を使用した JWS の例
A.3.1. エンコード
本例の JWS Protected Header は、使用されるアルゴリズムが異なるため、
前の例とは異なる。使用される JWS Protected Header は次のとおりである。
{"alg":"ES256"}
本例における UTF8(JWS Protected Header) を表すオクテット列
(JSON 配列表記) は次のとおりである。
[123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 50, 53, 54, 34, 125]
Jones, et al. Standards Track [Page 43]
RFC 7515 JSON Web Signature (JWS) May 2015
この JWS Protected Header を BASE64URL(UTF8(JWS Protected
Header)) としてエンコードすると、次の値になる:
eyJhbGciOiJFUzI1NiJ9
この例で使用される JWS Payload は、以下に示すものであり、
前の例と同一である。したがって、
BASE64URL(JWS Payload) の値も同一となるため、
ここではその計算を繰り返さない。
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
これらを BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) として結合すると、次の文字列になる
(表示目的のみによる改行を含む):
eyJhbGciOiJFUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
得られる JWS Signing Input 値は、上記文字列の ASCII
表現であり、次のオクテット列である:
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 70, 85, 122, 73,
49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105,
74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72,
65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68,
65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76,
121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118,
98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48,
99, 110, 86, 108, 102, 81]
この例では、以下に示す JSON Web Key
[JWK] 形式で表現された楕円曲線鍵を使用する:
{"kty":"EC",
"crv":"P-256",
"x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
"y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
"d":"jpsQnnGQmL-YBIffH1136cspYG6-0iY7X1fCE9-E9LI"
}
次に、楕円曲線デジタル署名アルゴリズム (ECDSA) の秘密部分 d
が ECDSA 署名関数に渡される。この関数は、
曲線種別 P-256、ハッシュ種別 SHA-256、
および JWS Signing Input も入力として受け取る。
デジタル署名の結果は楕円曲線の
Jones, et al. Standards Track [Page 44]
RFC 7515 JSON Web Signature (JWS) May 2015
(EC) 点 (R, S) であり、R および S は符号なし整数である。
この例では、ビッグエンディアン整数を表すオクテット列として
与えられる R および S の値は次のとおりである:
+--------+----------------------------------------------------------+
| Result | Value |
| Name | |
+--------+----------------------------------------------------------+
| R | [14, 209, 33, 83, 121, 99, 108, 72, 60, 47, 127, 21, 88, |
| | 7, 212, 2, 163, 178, 40, 3, 58, 249, 124, 126, 23, 129, |
| | 154, 195, 22, 158, 166, 101] |
| S | [197, 10, 7, 211, 140, 60, 112, 229, 216, 241, 45, 175, |
| | 8, 74, 84, 128, 166, 101, 144, 197, 242, 147, 80, 154, |
| | 143, 63, 127, 138, 131, 163, 84, 213] |
+--------+----------------------------------------------------------+
JWS Signature は R || S の値である。署名を
BASE64URL(JWS Signature) としてエンコードすると、
次の値が生成される (表示目的のみによる改行を含む):
DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA
pmWQxfKTUJqPP3-Kg6NU1Q
これらの値を Header.Payload.Signature の順に、
各部分の間にピリオド ('.') 文字を挿入して連結すると、
JWS Compact Serialization を用いた完全な JWS 表現が得られる
(表示目的のみによる改行を含む):
eyJhbGciOiJFUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA
pmWQxfKTUJqPP3-Kg6NU1Q
A.3.2. 検証
"alg" Header Parameter が "ES256" であるため、
JWS Signature に含まれる ECDSA P-256 SHA-256
デジタル署名を検証する。
JWS Signature の検証は、前の例とは少し異なる。
JWS Signature の 64 メンバーのオクテット列
(JWS 表現中でエンコードされた値を base64url デコードしたもの)
を 2 つの 32 オクテット列に分割する必要がある。
最初は R を表し、2 番目は S を表す。
次に、公開鍵 (x, y)、署名 (R, S)、および
JWS Signing Input (JWS Compact Serialization 表現の
先頭から 2 番目のピリオド文字直前までの初期部分) を
Jones, et al. Standards Track [Page 45]
RFC 7515 JSON Web Signature (JWS) May 2015
P-256 曲線および SHA-256 ハッシュ関数を使用するように
設定された ECDSA 署名検証器に渡す。
A.4. ECDSA P-521 SHA-512 を使用した JWS の例
A.4.1. エンコード
この例の JWS Protected Header は、
使用される ECDSA 曲線およびハッシュ関数が異なるため、
前の例とは異なる。
使用される JWS Protected Header は次のとおりである:
{"alg":"ES512"}
この例における UTF8(JWS Protected Header) を表すオクテットは、
(JSON 配列表記を用いると) 次のとおりである:
[123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 53, 49, 50, 34, 125]
この JWS Protected Header を BASE64URL(UTF8(JWS Protected
Header)) としてエンコードすると、次の値になる:
eyJhbGciOiJFUzUxMiJ9
この例で使用される JWS Payload は、
ASCII 文字列 "Payload" である。
この文字列の表現は、次のオクテット列である:
[80, 97, 121, 108, 111, 97, 100]
この JWS Payload を BASE64URL(JWS Payload) としてエンコードすると、
次の値になる:
UGF5bG9hZA
これらを BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) として結合すると、次の文字列になる:
eyJhbGciOiJFUzUxMiJ9.UGF5bG9hZA
得られる JWS Signing Input 値は、上記文字列の ASCII
表現であり、次のオクテット列である:
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 70, 85, 122, 85,
120, 77, 105, 74, 57, 46, 85, 71, 70, 53, 98, 71, 57, 104, 90, 65]
Jones, et al. Standards Track [Page 46]
RFC 7515 JSON Web Signature (JWS) May 2015
この例では、以下に示す JSON Web Key
[JWK] 形式で表現された楕円曲線鍵を使用する
(表示目的のみによる値内の改行を含む):
{"kty":"EC",
"crv":"P-521",
"x":"AekpBQ8ST8a8VcfVOTNl353vSrDCLLJXmPk06wTjxrrjcBpXp5EOnYG_
NjFZ6OvLFV1jSfS9tsz4qUxcWceqwQGk",
"y":"ADSmRA43Z1DSNx_RvcLI87cdL07l6jQyyBXMoxVg_l2Th-x3S1WDhjDl
y79ajL4Kkd0AZMaZmh9ubmf63e3kyMj2",
"d":"AY5pb7A0UFiB3RELSD64fTLOSV_jazdF7fLYyuTw8lOfRhWg6Y6rUrPA
xerEzgdRhajnu0ferB0d53vM9mE15j2C"
}
次に、ECDSA の秘密部分 d が ECDSA 署名関数に渡される。
この関数は、曲線種別 P-521、ハッシュ種別 SHA-512、
および JWS Signing Input も入力として受け取る。
デジタル署名の結果は EC 点 (R, S) であり、
R および S は符号なし整数である。
この例では、ビッグエンディアン整数を表すオクテット列として
与えられる R および S の値は次のとおりである:
+--------+----------------------------------------------------------+
| Result | Value |
| Name | |
+--------+----------------------------------------------------------+
| R | [1, 220, 12, 129, 231, 171, 194, 209, 232, 135, 233, |
| | 117, 247, 105, 122, 210, 26, 125, 192, 1, 217, 21, 82, |
| | 91, 45, 240, 255, 83, 19, 34, 239, 71, 48, 157, 147, |
| | 152, 105, 18, 53, 108, 163, 214, 68, 231, 62, 153, 150, |
| | 106, 194, 164, 246, 72, 143, 138, 24, 50, 129, 223, 133, |
| | 206, 209, 172, 63, 237, 119, 109] |
| S | [0, 111, 6, 105, 44, 5, 41, 208, 128, 61, 152, 40, 92, |
| | 61, 152, 4, 150, 66, 60, 69, 247, 196, 170, 81, 193, |
| | 199, 78, 59, 194, 169, 16, 124, 9, 143, 42, 142, 131, |
| | 48, 206, 238, 34, 175, 83, 203, 220, 159, 3, 107, 155, |
| | 22, 27, 73, 111, 68, 68, 21, 238, 144, 229, 232, 148, |
| | 188, 222, 59, 242, 103] |
+--------+----------------------------------------------------------+
JWS Signature は R || S の値である。署名を
BASE64URL(JWS Signature) としてエンコードすると、
次の値が生成される (表示目的のみによる改行を含む):
AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq
wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp
EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn
Jones, et al. Standards Track [Page 47]
RFC 7515 JSON Web Signature (JWS) May 2015
これらの値を Header.Payload.Signature の順に、
各部分の間にピリオド ('.') 文字を挿入して連結すると、
JWS Compact Serialization を用いた完全な JWS 表現が得られる
(表示目的のみによる改行を含む):
eyJhbGciOiJFUzUxMiJ9
.
UGF5bG9hZA
.
AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq
wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp
EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn
A.4.2. 検証
"alg" Header Parameter が "ES512" であるため、
JWS Signature に含まれる ECDSA P-521 SHA-512
デジタル署名を検証する。
この JWS Signature の検証は、前の例と非常に似ている。
JWS Signature の 132 メンバーのオクテット列を
2 つの 66 オクテット列に分割する必要がある。
最初は R を表し、2 番目は S を表す。
次に、公開鍵 (x, y)、署名 (R, S)、および
JWS Signing Input を、
P-521 曲線および SHA-512 ハッシュ関数を使用するように
設定された ECDSA 署名検証器に渡す。
A.5. 署名なし JWS の例
次の例の JWS Protected Header は、
エンコードされたオブジェクトが署名なし JWS であることを
宣言している:
{"alg":"none"}
この JWS Protected Header を BASE64URL(UTF8(JWS Protected
Header)) としてエンコードすると、次の値になる:
eyJhbGciOiJub25lIn0
この例で使用される JWS Payload は、
前の例と同一である。
したがって、BASE64URL(JWS Payload) の値も同一となるため、
ここではその計算を繰り返さない。
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
JWS Signature は空のオクテット文字列であり、
BASE64URL(JWS Signature) は空文字列である。
Jones, et al. Standards Track [Page 48]
RFC 7515 JSON Web Signature (JWS) May 2015
これらの値を Header.Payload.Signature の順に、
各部分の間にピリオド ('.') 文字を挿入して連結すると、
JWS Compact Serialization を用いた完全な JWS 表現が得られる
(表示目的のみによる改行を含む):
eyJhbGciOiJub25lIn0
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
A.6. 一般 JWS JSON Serialization を使用した JWS の例
この節では、一般 JWS JSON Serialization 構文を使用した例を示す。
この例は、同一のペイロードに対して複数のデジタル署名および／または
MAC を伝達できる能力を実証するものである。
この例で使用される JWS Payload は、
Appendix A.2 および Appendix A.3 の例で
使用されたものと同一である
(表示目的のみによる改行を含む):
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
この例では 2 つのデジタル署名を使用する。
1 つ目は RSASSA-PKCS1-v1_5 SHA-256 を使用し、
2 つ目は ECDSA P-256 SHA-256 を使用する。
1 つ目については、JWS Protected Header および鍵は
Appendix A.2 の例と同一であり、
同じ JWS Signature 値が得られるため、
ここではその計算を繰り返さない。
2 つ目については、JWS Protected Header および鍵は
Appendix A.3 の例と同一であり、
同じ JWS Signature 値が得られるため、
ここではその計算を繰り返さない。
A.6.1. 署名ごとの JWS Protected Header
1 つ目の署名に使用される JWS Protected Header の値は次のとおりである:
{"alg":"RS256"}
この JWS Protected Header を BASE64URL(UTF8(JWS Protected
Header)) としてエンコードすると、次の値になる:
eyJhbGciOiJSUzI1NiJ9
2 つ目の署名に使用される JWS Protected Header の値は次のとおりである:
{"alg":"ES256"}
Jones, et al. Standards Track [Page 49]
RFC 7515 JSON Web Signature (JWS) May 2015
この JWS Protected Header を BASE64URL(UTF8(JWS Protected
Header)) としてエンコードすると、次の値になる:
eyJhbGciOiJFUzI1NiJ9
A.6.2. 署名ごとの JWS Unprotected Header
鍵 ID の値は、署名ごとの Header Parameter を使用して
両方の鍵に対して供給される。
これらの鍵 ID を表す 2 つの JWS Unprotected Header の値は
次のとおりである:
{"kid":"2010-12-29"}
および
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
A.6.3. 完全な JOSE Header 値
提供された JWS Protected Header および
JWS Unprotected Header の値を組み合わせると、
1 つ目および 2 つ目の署名に使用される
JOSE Header の値はそれぞれ次のとおりである:
{"alg":"RS256",
"kid":"2010-12-29"}
および
{"alg":"ES256",
"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
Jones, et al. Standards Track [Page 50]
RFC 7515 JSON Web Signature (JWS) May 2015
A.6.4. 完全な JWS JSON シリアライゼーション表現
これらの値に対する完全な JWS JSON シリアライゼーションは次のとおりである
（値内の改行は表示目的のみのものである）。
{
"payload":
"eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF
tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
"signatures":[
{"protected":"eyJhbGciOiJSUzI1NiJ9",
"header":
{"kid":"2010-12-29"},
"signature":
"cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZ
mh7AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjb
KBYNX4BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHl
b1L07Qe7K0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZES
c6BfI7noOPqvhJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AX
LIhWkWywlVmtVrBp0igcN_IoypGlUPQGe77Rw"},
{"protected":"eyJhbGciOiJFUzI1NiJ9",
"header":
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
"signature":
"DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS
lSApmWQxfKTUJqPP3-Kg6NU1Q"}]
}
Jones, et al. Standards Track [Page 51]
RFC 7515 JSON Web Signature (JWS) May 2015
A.7. フラット化された JWS JSON シリアライゼーションを用いた JWS の例
この節では、フラット化された JWS JSON シリアライゼーション構文を使用した
例を示す。この例は、単一のデジタル署名または MAC をフラット化された
JSON 構造で伝達できることを示している。
この例における値は、付録 A.6 の前の例における
2 番目の署名の値と同一である。
これらの値に対する完全な JWS JSON シリアライゼーションは次のとおりである
（値内の改行は表示目的のみのものである）。
{
"payload":
"eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF
tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
"protected":"eyJhbGciOiJFUzI1NiJ9",
"header":
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
"signature":
"DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS
lSApmWQxfKTUJqPP3-Kg6NU1Q"
}
Jones, et al. Standards Track [Page 52]
RFC 7515 JSON Web Signature (JWS) May 2015
Appendix B. 「x5c」（X.509 証明書チェーン）の例
以下の JSON 配列は、4.1.6 節 に従って
「x5c」（X.509 証明書チェーン）ヘッダーパラメーターの値として
使用され得る証明書チェーンの例である
（値内の改行は表示目的のみのものである）。
["MIIE3jCCA8agAwIBAgICAwEwDQYJKoZIhvcNAQEFBQAwYzELMAkGA1UEBhMCVVM
xITAfBgNVBAoTGFRoZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR2
8gRGFkZHkgQ2xhc3MgMiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjExM
TYwMTU0MzdaFw0yNjExMTYwMTU0MzdaMIHKMQswCQYDVQQGEwJVUzEQMA4GA1UE
CBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UEChMRR29EYWR
keS5jb20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYW
RkeS5jb20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2VjdXJlIENlc
nRpZmljYXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2OTI4NzCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMQt1RWMnCZM7DI161+4WQFapmGBWTt
wY6vj3D3HKrjJM9N55DrtPDAjhI6zMBS2sofDPZVUBJ7fmd0LJR4h3mUpfjWoqV
Tr9vcyOdQmVZWt7/v+WIbXnvQAjYwqDL1CBM6nPwT27oDyqu9SoWlm2r4arV3aL
GbqGmu75RpRSgAvSMeYddi5Kcju+GZtCpyz8/x4fKL4o/K1w/O5epHBp+YlLpyo
7RJlbmr2EkRTcDCVw5wrWCs9CHRK8r5RsL+H0EwnWGu1NcWdrxcx+AuP7q2BNgW
JCJjPOq8lh8BJ6qf9Z/dFjpfMFDniNoW1fho3/Rb2cRGadDAW/hOUoz+EDU8CAw
EAAaOCATIwggEuMB0GA1UdDgQWBBT9rGEyk2xF1uLuhV+auud2mWjM5zAfBgNVH
SMEGDAWgBTSxLDSkdRMEXGzYcs9of7dqGrU4zASBgNVHRMBAf8ECDAGAQH/AgEA
MDMGCCsGAQUFBwEBBCcwJTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZ29kYWR
keS5jb20wRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NlcnRpZmljYXRlcy5nb2
RhZGR5LmNvbS9yZXBvc2l0b3J5L2dkcm9vdC5jcmwwSwYDVR0gBEQwQjBABgRVH
SAAMDgwNgYIKwYBBQUHAgEWKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5j
b20vcmVwb3NpdG9yeTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggE
BANKGwOy9+aG2Z+5mC6IGOgRQjhVyrEp0lVPLN8tESe8HkGsz2ZbwlFalEzAFPI
UyIXvJxwqoJKSQ3kbTJSMUA2fCENZvD117esyfxVgqwcSeIaha86ykRvOe5GPLL
5CkKSkB2XIsKd83ASe8T+5o0yGPwLPk9Qnt0hCqU7S+8MxZC9Y7lhyVJEnfzuz9
p0iRFEUOOjZv2kWzRaJBydTXRE4+uXR21aITVSzGh6O1mawGhId/dQb8vxRMDsx
uxN89txJx9OjxUUAiKEngHUuHqDTMBqLdElrRhjZkAzVvb3du6/KFUJheqwNTrZ
EjYx8WnM25sgVjOuH0aBsXBTWVU+4=",
"MIIE+zCCBGSgAwIBAgICAQ0wDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1Z
hbGlDZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIE
luYy4xNTAzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb
24gQXV0aG9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8x
IDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTA0MDYyOTE3MDY
yMFoXDTI0MDYyOTE3MDYyMFowYzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGFRoZS
BHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28gRGFkZHkgQ2xhc3MgM
iBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggEN
ADCCAQgCggEBAN6d1+pXGEmhW+vXX0iG6r7d/+TvZxz0ZWizV3GgXne77ZtJ6XC
APVYYYwhv2vLM0D9/AlQiVBDYsoHUwHU9S3/Hd8M+eKsaA7Ugay9qK7HFiH7Eux
6wwdhFJ2+qN1j3hybX2C32qRe3H3I2TqYXP2WYktsqbl2i/ojgC95/5Y0V4evLO
tXiEqITLdiOr18SPaAIBQi2XKVlOARFmR6jYGB0xUGlcmIbYsUfb18aQr4CUWWo
riMYavx4A6lNf4DD+qta/KFApMoZFv6yyO9ecw3ud72a9nmYvLEHZ6IVDd2gWMZ
Eewo+YihfukEHU1jPEX44dMX4/7VpkI+EdOqXG68CAQOjggHhMIIB3TAdBgNVHQ
Jones, et al. Standards Track [Page 53]
RFC 7515 JSON Web Signature (JWS) May 2015
4EFgQU0sSw0pHUTBFxs2HLPaH+3ahq1OMwgdIGA1UdIwSByjCBx6GBwaSBvjCBu
zEkMCIGA1UEBxMbVmFsaUNlcnQgVmFsaWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQK
Ew5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFsaUNlcnQgQ2xhc3MgMiBQb2x
pY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0dHA6Ly93d3cudm
FsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5jb22CA
QEwDwYDVR0TAQH/BAUwAwEB/zAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGG
F2h0dHA6Ly9vY3NwLmdvZGFkZHkuY29tMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA
6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS9yb290LmNybD
BLBgNVHSAERDBCMEAGBFUdIAAwODA2BggrBgEFBQcCARYqaHR0cDovL2NlcnRpZ
mljYXRlcy5nb2RhZGR5LmNvbS9yZXBvc2l0b3J5MA4GA1UdDwEB/wQEAwIBBjAN
BgkqhkiG9w0BAQUFAAOBgQC1QPmnHfbq/qQaQlpE9xXUhUaJwL6e4+PrxeNYiY+
Sn1eocSxI0YGyeR+sBjUZsE4OWBsUs5iB0QQeyAfJg594RAoYC5jcdnplDQ1tgM
QLARzLrUc+cb53S8wGd9D0VmsfSxOaFIqII6hR8INMqzW/Rn453HWkrugp++85j
09VZw==",
"MIIC5zCCAlACAQEwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlDZXJ
0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNT
AzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0a
G9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkq
hkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTk5MDYyNjAwMTk1NFoXDTE
5MDYyNjAwMTk1NFowgbsxJDAiBgNVBAcTG1ZhbGlDZXJ0IFZhbGlkYXRpb24gTm
V0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsTLFZhbGlDZ
XJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQD
ExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9
AdmFsaWNlcnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOOnHK5a
vIWZJV16vYdA757tn2VUdZZUcOBVXc65g2PFxTXdMwzzjsvUGJ7SVCCSRrCl6zf
N1SLUzm1NZ9WlmpZdRJEy0kTRxQb7XBhVQ7/nHk01xC+YDgkRoKWzk2Z/M/VXwb
P7RfZHM047QSv4dk+NoS/zcnwbNDu+97bi5p9wIDAQABMA0GCSqGSIb3DQEBBQU
AA4GBADt/UG9vUJSZSWI4OB9L+KXIPqeCgfYrx+jFzug6EILLGACOTb2oWH+heQ
C1u+mNr0HZDzTuIYEZoDJJKPTEjlbVUjP9UNV+mWwD5MlM/Mtsq2azSiGM5bUMM
j4QssxsodyamEwCW/POuZ6lcg5Ktz885hZo+L7tdEy8W9ViH0Pd"]
Jones, et al. Standards Track [Page 54]
RFC 7515 JSON Web Signature (JWS) May 2015
Appendix C. パディングなし base64url エンコーディングの実装に関する注記
この付録では、パディングを使用する標準的な base64 エンコーディングおよび
デコーディング関数に基づいて、パディングなしの base64url
エンコーディングおよびデコーディング関数を実装する方法を説明する。
具体例として、これらの関数を実装した C# のサンプルコードを以下に示す。
同様のコードは他の言語でも使用できる。
static string base64urlencode(byte [] arg)
{
string s = Convert.ToBase64String(arg); // 通常の base64 エンコーダー
s = s.Split('=')[0]; // 末尾の '=' をすべて削除
s = s.Replace('+', '-'); // エンコーディングの 62 番目の文字
s = s.Replace('/', '_'); // エンコーディングの 63 番目の文字
return s;
}
static byte [] base64urldecode(string arg)
{
string s = arg;
s = s.Replace('-', '+'); // エンコーディングの 62 番目の文字
s = s.Replace('_', '/'); // エンコーディングの 63 番目の文字
switch (s.Length % 4) // 末尾に '=' を追加してパディング
{
case 0: break; // この場合、パディング文字は不要
case 2: s += "=="; break; // パディング文字 2 個
case 3: s += "="; break; // パディング文字 1 個
default: throw new System.Exception(
"不正な base64url 文字列！");
}
return Convert.FromBase64String(s); // 標準の base64 デコーダー
}
上記のサンプルコードに示されているとおり、パディングなしの
base64url エンコード文字列の末尾に、パディング付きのものに変換するために
追加すべき '=' パディング文字の数は、エンコード文字列の長さに基づく
決定論的な関数である。具体的には、長さを 4 で割った余りが 0 の場合は
パディングは追加されず、余りが 2 の場合は '=' を 2 個、余りが 3 の場合は
'=' を 1 個追加する。余りが 1 の場合、入力は不正である。
Jones, et al. Standards Track [Page 55]
RFC 7515 JSON Web Signature (JWS) May 2015
エンコード前とエンコード後の値の対応例を以下に示す。
以下のオクテット列は、その下に示す文字列にエンコードされ、
その文字列をデコードすると元のオクテット列が再現される。
3 236 255 224 193
A-z_4ME
Appendix D. 鍵選択に関する注記
この付録では、JWS のデジタル署名または MAC を検証するため、あるいは
JWE を復号するために使用する鍵を選択する際の、考え得るアルゴリズムの
集合について説明する。この指針は単一のアルゴリズムではなく、
アルゴリズムのファミリーを示している。これは、文脈によっては
すべての鍵ソースが使用されるわけではなく、異なる順序で試行されたり、
収集されたすべての鍵が試されない場合があるためである。
その結果、異なるアプリケーション文脈では異なるアルゴリズムが使用される。
以下に示す手順は、説明目的のみのものである。特定のアプリケーションでは、
異なるアルゴリズムを使用したり、手順の一部を異なる順序で実行したりする
ことがある。特定のアプリケーションでは、使用目的に特化した 1 つまたは
2 つの鍵選択方法が存在するため、使用すべき鍵を決定する方法が
はるかに単純である場合が多い。この付録は、6 節 における
鍵の所在に関する規定情報を補足するものである。
これらのアルゴリズムには、以下の手順が含まれる。これらの手順は、
任意の順序で実行でき、必ずしも個別のものとして扱う必要はない。
例えば、すべての鍵を収集してから試行するのではなく、
鍵が見つかり次第試行することもできる。
1. 適用可能性のある鍵の集合を収集する。鍵のソースには、以下が含まれ得る。
* 使用しているアプリケーションプロトコルによって提供される鍵。
* 「jku」（JWK セット URL）ヘッダーパラメーターによって参照される鍵。
* 「jwk」（JSON Web Key）ヘッダーパラメーターによって提供される鍵。
* 「x5u」（X.509 URL）ヘッダーパラメーターによって参照される鍵。
* 「x5c」（X.509 証明書チェーン）ヘッダーパラメーターによって提供される鍵。
* アプリケーションで利用可能なその他の適用可能な鍵。
Jones, et al. Standards Track [Page 56]
RFC 7515 JSON Web Signature (JWS) May 2015
異なる鍵ソースから鍵を収集および試行する順序は、通常、
アプリケーションに依存する。例えば、多くの場合、
ローカルキャッシュのような 1 つの場所にあるすべての鍵が、
他の場所から鍵を収集して試行する前に試される。
2. 収集した鍵の集合をフィルタリングする。例えば、
一部のアプリケーションでは、「kid」（鍵 ID）や
「x5t」（X.509 証明書 SHA-1 サムプリント）
パラメーターによって参照される鍵のみを使用する。
アプリケーションが JWK の「alg」（アルゴリズム）,
「use」（公開鍵の用途）, または「key_ops」（鍵操作）
パラメーターを使用する場合、これらのパラメーターの値が
不適切な鍵は除外される。
さらに、アプリケーション固有の方法で、
他のメンバー値を持つ鍵を含めたり除外したりすることもある。
一部のアプリケーションでは、フィルタリングは行われない。
3. 収集した鍵の集合を順序付けする。例えば、
「kid」（鍵 ID）や「x5t」（X.509 証明書 SHA-1 サムプリント）
パラメーターによって参照される鍵は、
これらの値を持たない鍵よりも先に試行される場合がある。
同様に、特定のメンバー値を持つ鍵が、
他のメンバー値を持つ鍵よりも先に試行されることがある。
一部のアプリケーションでは、順序付けは行われない。
4. 鍵に関する信頼判断を行う。アプリケーションの信頼基準を
満たさない鍵で作成された署名は受け入れられない。
そのような基準には、鍵のソース、URL から取得した鍵に対する
TLS 証明書の検証結果、X.509 証明書内の鍵が
有効な証明書チェーンによって裏付けられているかどうか、
およびアプリケーションが把握しているその他の情報などが含まれるが、
これらに限定されない。
5. 収集され、場合によってはフィルタリングおよび／または
順序付けされた鍵の一部または全部を用いて、
JWS の署名または MAC の検証、あるいは JWE の復号を試みる。
試行する鍵の数に制限が設けられる場合もある。
この処理は、通常、検証または復号が成功した時点で終了する。
一部のアプリケーションでは、鍵に対する信頼判断を行う前に
署名または MAC の検証を行うことが合理的である点に注意されたい。
なぜなら、検証に失敗した鍵については、
信頼判断を行う必要がないためである。
Jones, et al. Standards Track [Page 57]
RFC 7515 JSON Web Signature (JWS) May 2015
Appendix E. 「crit」ヘッダーパラメーターの否定テストケース
適合する実装は、理解できない、または処理できない重要拡張を含む入力を
拒否しなければならない。以下の JWS は、理解できない拡張
ヘッダーパラメーター名「http://example.invalid/
UNDEFINED」を使用しているため、
すべての実装によって拒否されなければならない。
実装が理解できない他の任意のヘッダーパラメーター名に対して、
値「http://example.invalid/UNDEFINED」を
代入した同様の入力も、同様に拒否されなければならない。
この JWS に対する JWS 保護ヘッダー値は次のとおりである。
{"alg":"none",
"crit":["http://example.invalid/UNDEFINED"],
"http://example.invalid/UNDEFINED":true
}
拒否されなければならない完全な JWS は次のとおりである
（改行は表示目的のみのものである）。
eyJhbGciOiJub25lIiwNCiAiY3JpdCI6WyJodHRwOi8vZXhhbXBsZS5jb20vVU5ERU
ZJTkVEIl0sDQogImh0dHA6Ly9leGFtcGxlLmNvbS9VTkRFRklORUQiOnRydWUNCn0.
RkFJTA.
Appendix F. 分離されたコンテンツ
一部の文脈では、JWS 自体に含まれていないコンテンツの完全性を
保護することが有用である。その方法の 1 つは、
コンテンツの表現をペイロードとして通常どおり JWS を作成し、
その後、JWS からペイロード表現を削除して、
JWS ではなくこの修正済みオブジェクトを受信者に送信することである。
JWS コンパクトシリアライゼーションを使用する場合、
削除は 2 番目のフィールド
（BASE64URL(JWS ペイロード) を含む）の値を空文字列に
置き換えることで行われる。
JWS JSON シリアライゼーションを使用する場合、
削除は「payload」メンバーを削除することで行われる。
この方法は、受信者が JWS で使用された正確なペイロードを
再構成できることを前提としている。
修正済みオブジェクトを使用するには、受信者が
ペイロード表現を再挿入して JWS を再構成し、
得られた JWS を通常どおり使用する。
この方法は JWS ライブラリからの特別なサポートを必要とせず、
アプリケーションが標準的な JWS ライブラリの入出力を
修正することで使用できる点に注意されたい。
Jones, et al. Standards Track [Page 58]
RFC 7515 JSON Web Signature (JWS) May 2015
謝辞
JSON コンテンツの署名に関する解決策は、以前に
Magic Signatures [MagicSignatures]、
JSON Simple Sign [JSS]、
および Canvas Applications
[CanvasApp] によって検討されており、
これらすべてが本書に影響を与えた。
JWS および JWE 仕様に関する初期実装とフィードバックを提供した
Axel Nennker に感謝する。
本仕様は JOSE ワーキンググループの成果であり、
数十名の活発で献身的な参加者が含まれている。
特に、以下の人物が本仕様に影響を与えた
アイデア、フィードバック、および文言を提供した。
Dirk Balfanz, Richard Barnes, Brian Campbell, Alissa Cooper, Breno de
Medeiros, Stephen Farrell, Yaron Y. Goland, Dick Hardt, Joe
Hildebrand, Jeff Hodges, Russ Housley, Edmund Jay, Tero Kivinen, Ben
Laurie, Ted Lemon, James Manger, Matt Miller, Kathleen Moriarty, Tony
Nadalin, Hideki Nara, Axel Nennker, John Panzer, Ray Polk, Emmanuel
Raviart, Eric Rescorla, Pete Resnick, Jim Schaad, Paul Tarjan, Hannes
Tschofenig, and Sean Turner.
Jim Schaad および Karen O'Donoghue は JOSE ワーキンググループの
議長を務め、Sean Turner、Stephen Farrell、Kathleen Moriarty は
本仕様策定期間中にセキュリティエリアディレクターを務めた。
著者の連絡先
Michael B. Jones
Microsoft
EMail: mbj@microsoft.com
URI: http://self-issued.info/
John Bradley
Ping Identity
EMail: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/
Nat Sakimura
Nomura Research Institute
EMail: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/
Jones, et al. Standards Track [Page 59]