JWS と JWE

[10] JWS と JWE は、それぞれ独自形式と JSON 形式の合計6種類の直列化構文を規定しています。 JWS, JWE

[11] 両者はよく似ていますが、 (合法な) 入力が JWS か JWE のいずれであるかは、次のように区別できると説明されています。 >>9

[12] JWS簡潔直列化と JWE簡潔直列化は、 .FULL STOP 2つで3部に分けられるのが JWS、 .FULL STOP 3つで4部に分けられるのが JWE です。 >>9
[13] JWS JSON直列化と JWE JSON直列化は、
- [14] payload があれば JWS です。 >>9
- [15] ciphertext があれば JWE です。 >>9
[16] JOSEヘッダーにおいて alg ヘッダー引数が表すのがデジタル署名かMAC算法か none なら、 JWS です。 alg ヘッダー引数が表すのが鍵暗号化、鍵包み、直接鍵合意、鍵包み付き鍵合意、直接暗号化の算法なら、 JWE です。 >>9
[17] JOSEヘッダーにおいて enc ヘッダー引数があれば、 JWE です。 >>9

[18] 仕様書にはこのように区別のための特徴が列挙されているだけで、区別が必要なときにどのように判断するべきか明確に規定しているわけではありません。こんな具合で相互運用性は得られるのでしょうか?

[19] JWS や JWE のどちらかだけを使う応用は、どちらであるかを明確に規定するべきです。

[20] JWS や JWE の両方を使い得る応用は、どちらであるかを明確に区別する方法を定め、実装がどのように出力するべきか、実装がどのように入力を処理するべきかをエラー処理まで含めて明確に規定するべきです。

[22] その方法は仕様書が提示するようなものでも構いませんし、外部情報を使うようなものでも構いませんが、確実な方法を1つだけ明確に定めるべきです。

[21] JWS や JWE の両方に対応する実装は、どちらか自動判定するような動作モードを提供するべきではありません。便宜上のヒントを提示するようなタイプの実装は仕様書にあるような特徴を検査してどちらか判定してもいいのでしょうが、それに基づき勝手に処理を進行するようでは、相互運用性とセキュリティーの問題の温床となりかねません。

MIME 型

[145] 簡潔直列化の MIME型は application/jose です。 JWS または JWE の簡潔直列化を表します。 >>142

[24]

MIME型

MIME型: application/jose
説明: JOSE 簡潔直列化

[146] JSON 直列化の MIME型は application/jose+json です。 JWS または JWE の JSON 直列化を表します。 JSONオブジェクトは UTF-8 で符号化するべきです。 >>142

[147] なぜ UTF-8 以外の余地を残しているのか謎です。

[25]

MIME型

MIME型: application/jose+json
説明: JOSE JSON 直列化

暗号化された JWK

[27] 公開鍵でない鍵を含んだ JWK や JWK集合は不正なアクセスから保護しなければならないということで、 JWK と JWE の組合せが規定されています。 >>26

[28] そのような場合に暗号化JWKや暗号化JWK集合が推奨recommendされます。暗あん号ごう化かJWKEncrypted JWKや暗あん号ごう化かJWK集しゅう合ごうEncrypted JWK Setは、 JWK や JWK集合を RFC 3629 UTF-8 符号化したものを平文値とする JWE です。 >>26

[29] JWE のヘッダー引数 cty は、 jwk+json や jwk-set+json としなければなりません。ただし、応用が他の手段または表現法で JWK や JWK集合を暗号化していると分かっているときは、 cty は普通はtypically省略します。 >>26

[30] なぜ非標準の方法を選択する余地があるのか謎です。非標準の場合もその適切な MIME型ではなく cty を省略するのが一般的だといいますが、そうすると cty の意義も薄れます。応用独自の方法でいいなら、 JWK や JWE を使う必然性も無いわけなのですが、どういう用途が想定されていたのでしょう。

[33] JWE の直列化方式は特に規定されていません。その他 JWE の各種特性は応用ごとに定める必要があります.

メモ

[1] RFC 7165 - Use Cases and Requirements for JSON Object Signing and Encryption (JOSE) ( (2014-04-15 15:05:12 +09:00 版)) http://tools.ietf.org/html/rfc7165

[2] RFC 7520 - Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE) (2015-05-20 10:10:42 +09:00 版) https://tools.ietf.org/html/rfc7520
- [23] RFC Errata Report » RFC Editor, 2022-11-24T13:29:55.000Z https://www.rfc-editor.org/errata_search.php?rfc=7520

[3] JOSE (Javascript Object Signing and Encryption) is a Bad Standard That Everyone Should Avoid - Paragon Initiative Enterprises Blog ( (2017-04-13 19:35:33 +09:00)) https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid

[37] XユーザーのTakashi Kawasakiさん: 「この識別子を1バイトでもケチる文化、90年代後半ぐらいから崩壊したんだっけなぁ。Javaとか、今までのケチケチはなんだったんだよと思うぐらいクラス名長くなったし、拡張子とかも。」 / X, 午後2:28 · 2024年6月18日2024-06-18T05:28:22.000Z, 2024-06-19T03:14:15.000Z https://x.com/espresso3389/status/1802936369632952726
- [34] Xユーザーのlef/HAYASHI, Tatsuyaさん: 「@espresso3389 それなのに!JWTに!謎の!3文字文化が!」 / X, 午後4:50 · 2024年6月18日2024-06-18T07:50:01.000Z, 2024-06-19T03:14:15.000Z https://x.com/lef/status/1802972019983880246
- [35] XユーザーのTakashi Kawasakiさん: 「@lef 全部、HTTPが悪いのです。」 / X, 午後5:09 · 2024年6月18日2024-06-18T08:09:03.000Z, 2024-06-19T03:14:15.000Z https://x.com/espresso3389/status/1802976808113238277

[36] なんか謎に HTTP に流れ弾いってるけど HTTP って別に省略文化ないよね。 RFC 822 からの流れでヘッダー名とかクッソ長いし。 (RFC 822 というかインターネットメールって太古の昔からあるし Unix 文化と同じ方面なのにわりと富豪的よね。)