[5] JOSE は、 JSON 形式で署名や暗号化を扱う技術群や、 その標準化を担当した IETF のグループです。
[6] JOSE 技術は「JW○」のような名称がついています。
[31] JWS と JWE は一番外側が JSON である JSON直列化と独自テキストファイルである簡潔直列化の2種類に大別できる記述方法を提供しています。
[10] JWS と JWE は、それぞれ独自形式と JSON
形式の合計6種類の直列化構文を規定しています。
[11] 両者はよく似ていますが、 (合法な) 入力が JWS か JWE のいずれであるかは、次のように区別できると説明されています。 >>9
. 2つで3部に分けられるのが JWS、
. 3つで4部に分けられるのが JWE
です。
>>9alg
ヘッダー引数が表すのがデジタル署名かMAC算法か
none
なら、
JWS
です。
alg
ヘッダー引数が表すのが鍵暗号化、
鍵包み、
直接鍵合意、
鍵包み付き鍵合意、
直接暗号化の算法なら、
JWE
です。
>>9enc
ヘッダー引数があれば、
JWE
です。
>>9[18] 仕様書にはこのように区別のための特徴が列挙されているだけで、 区別が必要なときにどのように判断するべきか明確に規定しているわけではありません。 こんな具合で相互運用性は得られるのでしょうか?
[19] JWS や JWE のどちらかだけを使う応用は、 どちらであるかを明確に規定するべきです。
[20] JWS や JWE の両方を使い得る応用は、 どちらであるかを明確に区別する方法を定め、 実装がどのように出力するべきか、 実装がどのように入力を処理するべきかをエラー処理まで含めて明確に規定するべきです。
[21] JWS や JWE の両方に対応する実装は、 どちらか自動判定するような動作モードを提供するべきではありません。 便宜上のヒントを提示するようなタイプの実装は仕様書にあるような特徴を検査してどちらか判定してもいいのでしょうが、 それに基づき勝手に処理を進行するようでは、 相互運用性とセキュリティーの問題の温床となりかねません。
[145]
簡潔直列化の
MIME型は
application/jose
です。 JWS または JWE の簡潔直列化を表します。
>>142
application/jose[146]
JSON
直列化の
MIME型は
application/jose+json
です。 JWS または JWE の JSON 直列化を表します。
JSONオブジェクトは UTF-8 で符号化するべきです。
>>142
[27] 公開鍵でない鍵を含んだ JWK や JWK集合は不正なアクセスから保護しなければならないということで、 JWK と JWE の組合せが規定されています。 >>26
[28] そのような場合に暗号化JWKや暗号化JWK集合が推奨されます。 暗号化JWKや 暗号化JWK集合は、 JWK や JWK集合を RFC 3629 UTF-8 符号化したものを平文値とする JWE です。 >>26
[29]
JWE のヘッダー引数 cty は、 jwk+json
や
jwk-set+json
としなければなりません。
ただし、
応用が他の手段または表現法で JWK や
JWK集合を暗号化していると分かっているときは、
cty は普通は省略します。
>>26
[1] RFC 7165 - Use Cases and Requirements for JSON Object Signing and Encryption (JOSE) ( ( 版)) http://tools.ietf.org/html/rfc7165
[3] JOSE (Javascript Object Signing and Encryption) is a Bad Standard That Everyone Should Avoid - Paragon Initiative Enterprises Blog ( ()) https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid
[36] なんか謎に HTTP に流れ弾いってるけど HTTP って別に省略文化ないよね。 RFC 822 からの流れでヘッダー名とかクッソ長いし。 (RFC 822 というかインターネットメールって太古の昔からあるし Unix 文化と同じ方面なのにわりと富豪的よね。)