仕様書

[8] 個別の仕様書は各技術の項を参照。

技術

[6] JOSE 技術は「JW○」のような名称がついています。

[31] JWS と JWE は一番外側が JSON である JSON直列化と独自テキストファイルである簡潔直列化の2種類に大別できる記述方法を提供しています。

[32] JWK は JSON直列化しか提供していません。

JWS と JWE

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

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

• [12] JWS簡潔直列化と JWE簡潔直列化は、 . 2つで3部に分けられるのが JWS、 . 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 の両方を使い得る応用は、 どちらであるかを明確に区別する方法を定め、 実装がどのように出力するべきか、 実装がどのように入力を処理するべきかをエラー処理まで含めて明確に規定するべきです。

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

暗号化された JWK

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

[28] そのような場合に暗号化JWKや暗号化JWK集合が推奨 (recommend) されます。 暗 (あん) 号 (ごう) 化 (か) JWK (Encrypted 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

[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-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-19T03:14:15.000Z https://x.com/lef/status/1802972019983880246
  • [35] XユーザーのTakashi Kawasakiさん: 「@lef 全部、HTTPが悪いのです。」 / X, 午後5:09 · 2024年6月18日, 2024-06-19T03:14:15.000Z https://x.com/espresso3389/status/1802976808113238277

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