[9] JSON Web Signature (JWS) は、 デジタル的に RFC 4949 署名されまたは RFC 4949 MAC されたメッセージです。 >>8, >>22
[23] JWS は、 RFC 7159 JSON データや base64url
を使って記述されます。 JSON は、その定めるところにより、
値の前後に空白を挿入できます。
[24] JWS は、論理的に JOSEヘッダー、JWSペイロード、 JWS署名で構成されます。
[11] JWSペイロードは、 保安されるオクテット列、すなわちメッセージです。 ペイロードは、 任意のオクテット列を含められます。 >>8
[12] JWS署名は、 JWS保護ヘッダーとJWSペイロードに関する RFC 4949 デジタル署名や RFC 4949 MAC です。 >>8
[16] JWS署名入力は、 RFC 4949 デジタル署名または RFC 4949 MAC 計算への入力です。 この値は、
[20]
StringOrURI
は、
JSON文字列値であって、
任意の文字列値であっても構わないものの、
: が含まれる場合は
RFC 3986 URI
でなければならないものです。
比較は、
大文字・小文字区別ありで変形や正準化なく行います。
>>8
[62] alg は耐衝突名かつ StringOrURI とされています。
[173]
JWS のうち JWSペイロードを含めない、
つまり JWS 生成後に JWS簡潔直列化にあっては該当部分を空文字列とし、
JWS JSON直列化にあっては payload
を削除したものを扱うのが時に有用なのであって、
受信者も別の手段で JWSペイロード相当の情報を入手し、
容易に JWS を再構築し得るものである、
と仕様書に敢えて言及があります >>172。
[174] しかしなぜか本体仕様とは別に簡単に説明されているに過ぎず、 しかも送受信者がそのような簡単な操作で標準的な JWS のライブラリーの入出力を改変して実現可能だ、 と JWS 本体ではなく応用側で実装するべきものとしています。 本当にそのような需要があるのなら、 こうした取ってつけた説明ではなく JWS 本体仕様に組み込んで詳細に規定するべきで、不可解です。
[27] JWS は、 JWS簡潔直列化と JWS JSON直列化の 2種類の表現方法があります >>31。 JWS JSON直列化の方が高い記述能力を持ちます。
[32] JWS を使う応用は、 どちらの直列化を使うか、 どの直列化機能を使うかを、 規定する必要があります。 JWS の実装は、 対応したい応用で必要な機能のみ実装する必要があります。 >>31
[33] 例えば、 「JWS JSON直列化で署名か MAC の値は1つだけ対応する」 のような定めが可能です。 >>31
[17] JWS簡潔直列化は、 JWS を簡潔で URL 安全な文字列として表現したものです。 >>8
[28] JWS簡潔直列化では、 JWS非保護ヘッダーを使うことが出来ません。 JOSEヘッダー = JWS保護ヘッダーです。 >>8, >>22
[29] JWS簡潔直列化は、 次のものを順に連結したものです。 >>22, >>31
..[34] 署名・MAC は1つだけしか指定できません。 >>31
[145]
MIME型は
application/jose
です。 JWS または JWE の簡潔直列化を表します。
>>142
[18] JWS JSON直列化は、 JWS を JSONオブジェクトとして表現したものです。 JWS簡潔直列化と違って、 複数の RFC 4949 デジタル署名と RFC 4949 MAC の一方又は両方を同じ内容に適用できます。 簡潔性や URL 安全性は重視していません。 >>8
[30] JWS JSON直列化では、 JWS保護ヘッダーとJWS非保護ヘッダーの両方を使うことができます >>8, >>22。 どちらか一方は存在しなければなりません >>22。 JOSEヘッダーは両者全体で構成されます >>8, >>22。
[35] 一般構文と呼ばれるものと、平坦化構文と呼ばれるものの2種類があります。 >>31
[146]
MIME型は
application/jose+json
です。 JWS または JWE の JSON 直列化を表します。
JSONオブジェクトは UTF-8 で符号化するべきです。
>>142
[36] (完全)一般JWS JSON直列化構文は、 次のような最上位の JSONオブジェクトです。 >>31
payloadsignatures[41]
各JSONオブジェクトは、
JWSペイロードと JWS保護ヘッダーの署名や MAC を表します。
>>31protectedheadersignature
[42]
protected または header
の一方または両方がなければなりません。
最低でも alg ヘッダー引数が必要です。
>>31
[43]
署名や MAC 値の作成や検証に使うヘッダー引数は、
protected と
header
を合同して得られる
JOSEヘッダーです。
両者のヘッダー引数の名前は、互いに素でなければなりません。
>>31
protected,
header,
signature
も禁止はされていません。)[37] 平滑化JWS JSON直列化構文は、 単一のデジタル署名・ MAC の場合に最適化したもので、 次のような最上位 JSONオブジェクトです。 >>31
payloadprotectedheadersignaturesignatures があってはなりません。
>>31[45]
protected または header
の一方または両方がなければなりません。
最低でも alg ヘッダー引数が必要です。
>>31
[46]
署名や MAC 値の作成や検証に使うヘッダー引数は、
protected と
header
を合同して得られる
JOSEヘッダーです。
両者のヘッダー引数の名前は、互いに素でなければなりません。
>>31
[10] JOSEヘッダーは、 使用する RFC 4949 デジタル署名や RFC 4949 MAC の演算や引数を記述する JSONオブジェクトです。 >>8, >>47 更に追加の情報も含めることが出来ます。 >>47
[13] ヘッダー引数は、 JOSEヘッダーのメンバーたる名前と値の組です。 >>8
[48]
ヘッダー引数の名前は、JOSEヘッダー内で固有でなければなりません。
JWS 構文解析器は、
JWS
がヘッダー引数の重複を含む時、
これを拒絶するか、
または重複するメンバー名について字句的に最後のもののみ採用する
JavaScript JSON.parse
と同じ挙動の JSON 構文解析器を使うかしなければなりません。
>>47, >>148
さらに、
JWS保護ヘッダーとJWS非保護ヘッダーの間でも同名があってはなりません (>>43, >>46)。
{"name": "value1", "name": "value2"}
のごとく同名のメンバーを複数含めることが出来ます。
JWS はこれを拒絶するか、最後の value2 のみ採用することを求めています。
挙動に曖昧性が認められるのは、
相互運用性の火種であり、
とりわけセキュリティー技術には好ましからざる性質です。
どちらとも実装し得る JSON 仕様側の問題といえなくもないですが。
JSON の標準的な実装である JSON.parse
の挙動、すなわちエラーとせず最後のもののみを採用するのが好ましいと考えられます。[26] JWS の JOSEヘッダーのメンバーは、 JWS保護ヘッダーとJWS非保護ヘッダーの各メンバーの合同です。 >>22
[14] JWS保護ヘッダーは、 JWS署名の RFC 4949 デジタル署名または RFC 4949 MAC演算によって一貫性保護されたヘッダー引数を含む JSONオブジェクトです。 >>8
[15] JWS非保護ヘッダーは、 一貫性保護されていないヘッダー引数を含む JSONオブジェクトです。 >>8
[50] 実装は、理解しなければならないと規定されたヘッダー引数を、 理解し処理しなければなりません。 >>47
[51]
それ以外は、理解できない場合無視しなければなりません。
ただし、 crit が適用されるものを除きます。
>>47
crit ヘッダー引数[70]
ヘッダー引数
crit
(critical)
は、
JWS や JWA の仕様書に対する拡張が使われていて、
これを理解して処理しなければならないことを示すものです。
>>69
[71] 値は、 当該拡張を使う JOSEヘッダーのヘッダー引数名の配列です。 >>69
[73] 生成器は、 JWS や JWA の仕様書で定められたヘッダー引数名を指定してはなりません。 >>69
[74] 生成器は、 ヘッダー引数名を重複して指定したり、 JOSEヘッダー内に出現しないヘッダー引数名を指定したりしてはなりません。 >>69
[75] 生成器は、 空の配列を指定してはなりません。 >>69
[78]
crit を使う場合、
JWS保護ヘッダーに含めなければなりません。
>>69
JWS非保護ヘッダーでは使えません。
[80]
実装は、ヘッダー引数
crit
を理解し処理しなければなりません。
>>69
[76]
受信者は、
crit の値が制約 (>>73, >>74, >>75) 違反のとき、
当該 JWS を非妥当とみなして構いません。
>>69
[72] 受信者が指定されたヘッダー引数のいずれかを理解対応していない場合には、 当該 JWS は非妥当です。 >>69
[52] ヘッダー引数名には、 登録ヘッダー引数名、 公開ヘッダー引数名、 私的ヘッダー引数名の3種類があります。 >>47 この「class」は互いに素のようにも感じられますが、 仕様書の定義が曖昧で意図を掴みかねます。
[53] 登録ヘッダー引数名は、 IANA登録簿に登録されたものです >>47。 IANA登録簿は JWS と JWE で共通で、一方または両方で使用するかを指定できます >>142。 JWS と JWE の両方で使うものを定める場合、用法が一貫していなければなりません >>47。
[143] 登録するヘッダー引数名は、 短く、原則として8文字以下であるべきとされています。 >>142
[144] 一般にヘッダー引数名は大文字・小文字区別ありですが、 登録時に指定専門家が必要と認めた場合を除き、 大文字・小文字不区別で既存の名称と一致するものは登録できません。 >>142
[54] 公開ヘッダー引数名 >>47 が何であるか仕様書はなぜか明確に述べていませんが、 登録ヘッダー引数名でも私的ヘッダー引数名でもないものとみられます。
[57] 公開ヘッダー引数名に関する仕様書の節には、 次のようにあります。 JWS 利用者は、 RFC 7515 にない追加のヘッダー引数名を定義できますが、 IANA登録簿に登録するか、 または Public Name (耐衝突名が含まれる値) であるかとするべきです。 いずれにせよ、 定義者は、 名前を定義するため使う名前空間の部分に関して、 制御下に置かれるべく十分に注意を払う必要があります。 >>47 (この Public Name が公開ヘッダー引数名を指しているとも解せます。 主語の利用者が誰を指すか明らかではありませんが (私的ヘッダー引数名との違いに注意)、 JWS を利用する技術の仕様策定者とみるべきでしょうか。)
[58] 新しいヘッダー引数の追加は、相互運用性の低下を招き得るため、 慎重にするべきです。 >>47
[55] 私的ヘッダー引数名 >>47 が何であるか仕様書はなぜか不明瞭にしていますが、 仕様書の私的ヘッダー引数名の節には、 JWS の生成者と消費者は Private Names (登録ヘッダー引数名でない名前) や公開ヘッダー引数名を使うことに合意して構わない >>47 とあります。 この Private Names が私的ヘッダー引数名とも解し得ますが、 「登録ヘッダー引数名でない」 ならそれは公開ヘッダー引数名を含むとも考えられ、 だとすると敢えて公開ヘッダー引数名に言及しているのが不審です。 公開ヘッダー引数名と違って私的ヘッダー引数名は衝突の恐れがあり、 注意して使うべきである >>47 とされており、だとすると両者は互いに素であるとも思われます。
[59] この通りヘッダー引数名には3つの分類がありますが、 仕様書は注意せよと言っているだけで、 利用の制限も特になく、 定義も曖昧で、 実質的な違いはないといって良いでしょう。
[60] 相互運用性を考慮すると、 JWS を使う応用は、 それぞれどれを実装しなければならないか定め、 それ以外は実装してはならないと定める必要がありそうです。 JWS の実装は、 その適用対象の応用に合わせ、 不要なものを生成せず、 対応が求められていないものを無視することを徹底するべきでしょう。
[82]
JWSを作成するには、
JWSペイロード、
JSONオブジェクトまたは null JWS保護ヘッダー、
JSONオブジェクトまたは null JWS非保護ヘッダーを、
次のようにします。
>>81
alg ヘッダー引数が含まれなければなりません。null でない場合、.、
符号化ペイロード値を順に連結した結果[128] BOM を生成するべきか否か仕様書から明らかではありません。一般的には Encoding Standard の UTF-8符号化のように BOM を生成しないものと解されています。
[91] JWS を検証するには、 JWS を、 次のようにします。 >>81
null でない場合、crit ヘッダー引数で指定されたものについて、
実装が理解し処理できるヘッダー引数であること、
その値もまた理解し処理できるものであることを確認します。そうでない場合、.、
結果の符号化ペイロード値を順に連結した結果[125] JWS署名が複数含まれる時、 どれを検証するか、すべてを検証するかは応用が決めることとされています。 最低でも1つは検証し真を返すことを確認しなければなりません。 >>81
[126] 検証結果が真であっても、 アルゴリズムが応用の期待するものでなければ、 非妥当とみなすべきです。 >>81
[127]
UTF-8 や JSON の復号について、参照している仕様が明確に方法を定めていないため、
相互運用性の問題が生じるおそれがあります。仕様書の厳密な解釈に従うことは避け、
明確な規定のある Encoding Standard BOMなしUTF-8復号または失敗や
ECMAScript JSON.stringify に倣うべきでしょう。
[134]
JWS署名の計算に使われるアルゴリズムは、
alg ヘッダー引数に指定することになっています。
生成器は、これを指定しなければなりません。
alg の値が受信器の対応しているアルゴリズムでないとき、
妥当ではありません >>47。
検証は失敗します。
[149]
アルゴリズムの実装によってはJWS署名値内に含まれるアルゴリズムを使って検証する場合があります。
その場合でもそれが alg と一致しているか確認しなければなりません。
さもなくば alg に強いアルゴリズムを指定し、
実際には弱いアルゴリズムで攻撃することが可能となってしまいます。
>>148
[132] RFC 4949 デジタル署名または RFC 4949 MAC は、 必要な鍵を決定できないとき、失敗します。 >>129, >>47
[130]
受信器は、
JWS の演算で使用する鍵を、
ヘッダー引数
jku,
jwk,
kid,
x5u,
x5c,
x5t,
x5t#S256
の値から決定することもできますし、
JWS 仕様書の定めない別の方法で決めても構いません。
[131] 生成器は、 他の方法によって鍵が決定されるべき場合を除き、 十分な情報をヘッダー引数に含めるべきです。 >>129
x5u、jku のように、
鍵の決定にネットワークアクセスが発生し得るものもあります。
その場合、鍵の選択に不定の時間を要することがあり、
パフォーマンスや実装戦略上、エラー処理上の特段の配慮が必要となります。
また鍵の取得を試みた事実が送信者側または送信者の指定した第三者
(改竄を想定し得るケースでは、悪意ある第三者)
に伝わり得ることにも注意が必要となります。
こうした懸念を排除できる場合を除き、
応用は外部から鍵を取得する方法を認めるべきではありません。
汎用的な JWS の実装は、
明示的に求められない限り、
こうした手法を有効にするべきではありません。[133] これらヘッダー引数の情報を使って信頼決定する場合にあっては、 これらヘッダー引数は一貫性保護しなければなりません >>129。 (つまり JWS保護ヘッダーとしなければなりません。) しかし信頼決定に使われる情報が鍵だけの場合にあっては、 これらヘッダー引数を一貫性保護せずとも構いません >>129。 なぜなら、鍵が違えば検証が失敗するからです >>129。
[151] 鍵選択は、応用次第で異なる方法で行われ得るのであって、 仕様書には一定の指針が示されているものの、 すべての情報源を使う必要もなく、 適用し得るすべての鍵を使う必要もなく、 また順序もその通りである必要はないものとされています。 ともかく、指針として、次のようにします。 >>150
[63] JWS は jku, x5u に URL
を指定して別ファイルを参照できます。
JWSの取得プロトコルには次のような制約が規定されています。
[64] 資源の取得に使うプロトコルは、 一貫性保護を提供するものでなければなりません。 >>47
[66]
取得に使う HTTP GET 要求は、
TLS を使わなければなりません >>47。
jku や x5u に対応する実装は、
TLS に対応しなければなりません >>138。
[141] RFC 6125 service identity 検証を実施しなければなりません。 >>47, >>138
[67]
ここで仕様書は TLS について RFC 2818 (HTTPS)
と
RFC 5246 (TLS/1.2)
を参照していますが、その意図するところは不明です。
(他の理論上はあり得る方法ではなく) HTTPS
を使うことを要求するべきでしょうか。
さらに RFC 6125 が参照されていますが、
RFC 6125 自身は HTTPS に適用されるとはしておらず、
適用する場合 HTTPS の仕様書の改訂が必要になることを述べています。
[140] TLS については、 実装するべき版は時代により変化し得るものであって、執筆時点では RFC 5246 TLS/1.2 である >>138 と明記されています。
[139] TLS では機密性保護と一貫性保護を提供する ciphersuite を使わなければなりません。 適切な ciphersuite については RFC 6176 その他現行の IETF TLS working group 出版物を参照するべきです。 RFC 7572 も参照するべきです。 >>138
[68]
こうした要件を満たし現実的に運用可能なプロトコルとなると、
HTTPS (URL scheme は https:)
をおいて他にはありません。
(理論上は FTP over TLS なども該当し得ますが、
相互運用性に問題があります。)
[1] JSON Web Signature (JWS) ( ( 版)) http://openid.net/specs/draft-jones-json-web-signature-04.html
[2] draft-ietf-jose-json-web-signature-19 - JSON Web Signature (JWS) ( ( 版)) http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-19
[3] 、 IETF 提案標準 RFC 7515 として出版されました。
[4] RFC 7797 - JSON Web Signature (JWS) Unencoded Payload Option ( 版) https://tools.ietf.org/html/rfc7797
[5] RFC 8055 - Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm () https://tools.ietf.org/html/rfc8055