[14] JWS は、 電子署名のための JSON応用です。
[9] JSON Web Signature (JWS) は、 デジタル的に RFC 4949 署名されまたは RFC 4949 MAC されたメッセージです。 >>8, >>22
[13]
JOSEヘッダーには、
JWS 用のヘッダー引数をいくつか指定できます。
ヘッダー引数は名前と値の組です。
[10]
JOSEヘッダー内のヘッダー引数の重複は認められません。
[23] JWS は、 RFC 7159 JSON データや base64url
を使って記述されます。 JSON は、その定めるところにより、
値の前後に空白を挿入できます。
[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 や enc は耐衝突名かつ StringOrURI
(を含む文字列) とされています。
[173]
JWS のうち JWSペイロードを含めない、
つまり JWS 生成後に JWS簡潔直列化にあっては該当部分を空文字列とし、
JWS JSON直列化にあっては payload
を削除したものを扱うのが時に有用なのであって、
受信者も別の手段で JWSペイロード相当の情報を入手し、
容易に JWS を再構築し得るものである、
と仕様書に敢えて言及があります >>172。
[174] しかしなぜか本体仕様とは別に簡単に説明されているに過ぎず、 しかも送受信者がそのような簡単な操作で標準的な JWS のライブラリーの入出力を改変して実現可能だ、 と JWS 本体ではなく応用側で実装するべきものとしています。 本当にそのような需要があるのなら、 こうした取ってつけた説明ではなく JWS 本体仕様に組み込んで詳細に規定するべきで、不可解です。
[27] JWS は、 3種類の表現方法があります。 JWS を使う応用は、 どちらの直列化を使うか、 どの直列化機能を使うかを、 規定する必要があります。 JWS の実装は、 対応したい応用で必要な機能のみ実装する必要があります。 >>31
[33] 例えば、 「JWS JSON直列化で署名か MAC の値は1つだけ対応する」 のような定めが可能です。 >>31
[17] JWS簡潔直列化は、 JWS を簡潔で URL安全な文字列として表現したものです。 >>8
[28] JWS簡潔直列化では、 JWS非保護ヘッダーを使うことが出来ません。 JOSEヘッダー = JWS保護ヘッダーです。 >>8, >>22
[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
[48]
ヘッダー引数と違って明言されていませんが、
JSONオブジェクトの重複メンバーは
ヘッダー引数の重複と同様に処理するべきと思われます。
[36] (完全)一般JWS JSON直列化構文は、 次のような最上位の JSONオブジェクトです。 >>31
payloadsignatures[41] 各JSONオブジェクトは、 JWSペイロードと JWS保護ヘッダーの署名や MAC を表します。 >>31
protectedheadersignature[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
[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
[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