[5] [DFN[JOSE]] は、 [[JSON]] 形式で[[署名]]や[[暗号化]]を扱う技術群や、 その[[標準化]]を担当した [[IETF]] のグループです。 * 仕様書 [8] 個別の[[仕様書]]は各技術の項を参照。 [REFS[ - [7] [CITE[JSON Object Signing and Encryption (JOSE)]], [TIME[2019-03-14 06:55:09 +09:00]] - [142] [CITE@en[[[RFC 7515]] - JSON Web Signature (JWS)]], [TIME[2020-03-29 16:13:43 +09:00]] - [9] [CITE@en[[[RFC 7516]] - JSON Web Encryption (JWE)]], [TIME[2022-11-24T09:25:18.000Z]] - [26] [CITE@en[[[RFC 7517]]: JSON Web Key (JWK)]], [TIME[2022-12-15T11:34:06.000Z]] ]REFS] * 技術 [6] [[JOSE]] 技術は「[DFN[JW[VAR[○]]]]」のような名称がついています。 [FIG(short list)[ [4] [[JOSE]] - [[JWA]] - [[JWS]] - [[JWT]] - [[JWE]] - [[JWK]] - [[JOSEヘッダー]] - [[JOSE鍵識別]] ]FIG] [31] [[JWS]] と [[JWE]] は一番外側が [[JSON]] である [DFN[JSON直列化]]と独自[[テキストファイル]]である[DFN[簡潔直列化]]の2種類に大別できる記述方法を提供しています。 [32] [[JWK]] は [[JSON直列化]]しか提供していません。 * JWS と JWE [10] [[JWS]] と [[JWE]] は、それぞれ独自形式と [[JSON]] 形式の合計6種類の[[直列化]]構文を規定しています。 [SEE[ [[JWS]], [[JWE]] ]] [11] 両者はよく似ていますが、 (合法な) 入力が [[JWS]] か [[JWE]] のいずれであるかは、次のように区別できると説明されています。 [SRC[>>9]] - [12] [[JWS簡潔直列化]]と [[JWE簡潔直列化]]は、 [CODE[.][FULL STOP]] 2つで3部に分けられるのが [[JWS]]、 [CODE[.][FULL STOP]] 3つで4部に分けられるのが [[JWE]] です。 [SRC[>>9]] - [13] [[JWS JSON直列化]]と [[JWE JSON直列化]]は、 -- [14] [CODE[payload]] があれば [[JWS]] です。 [SRC[>>9]] -- [15] [CODE[ciphertext]] があれば [[JWE]] です。 [SRC[>>9]] - [16] [[JOSEヘッダー]]において [CODE[alg]] [[ヘッダー引数]]が表すのが[[デジタル署名]]か[[MAC算法]]か [CODE[none]] なら、 [[JWS]] です。 [CODE[alg]] [[ヘッダー引数]]が表すのが[[鍵暗号化]]、 [[鍵包み]]、 [[直接鍵合意]]、 [[鍵包み付き鍵合意]]、 [[直接暗号化]]の[[算法]]なら、 [[JWE]] です。 [SRC[>>9]] - [17] [[JOSEヘッダー]]において [CODE[enc]] [[ヘッダー引数]]があれば、 [[JWE]] です。 [SRC[>>9]] [18] [[仕様書]]にはこのように区別のための特徴が列挙されているだけで、 区別が必要なときにどのように判断するべきか明確に規定しているわけではありません。 こんな具合で[[相互運用性]]は得られるのでしょうか? [19] [[JWS]] や [[JWE]] のどちらかだけを使う[[応用]]は、 どちらであるかを明確に規定するべきです。 [20] [[JWS]] や [[JWE]] の両方を使い得る[[応用]]は、 どちらであるかを明確に区別する方法を定め、 実装がどのように出力するべきか、 実装がどのように入力を処理するべきかをエラー処理まで含めて明確に規定するべきです。 ;; [22] その方法は仕様書が提示するようなものでも構いませんし、 外部情報を使うようなものでも構いませんが、 確実な方法を1つだけ明確に定めるべきです。 [21] [[JWS]] や [[JWE]] の両方に対応する実装は、 どちらか自動判定するような動作モードを提供するべきではありません。 便宜上の[[ヒント]]を提示するようなタイプの実装は仕様書にあるような特徴を検査してどちらか判定してもいいのでしょうが、 それに基づき勝手に処理を進行するようでは、 [[相互運用性]]と[[セキュリティー]]の問題の温床となりかねません。 ** MIME 型 [145] 簡潔直列化の [[MIME型]]は [DFN[[CODE[application/jose]]]] です。 [[JWS]] または [[JWE]] の簡潔直列化を表します。 [SRC[>>142]] [FIG(data list middle)[ [24] [[MIME型]] :[[MIME型]]: [CODE[application/jose]] :説明:[[JOSE]] 簡潔直列化 ]FIG] [146] [[JSON]] 直列化の [[MIME型]]は [DFN[[CODE[application/jose+json]]]] です。 [[JWS]] または [[JWE]] の JSON 直列化を表します。 [[JSONオブジェクト]]は [[UTF-8]] で符号化する[SHOULD[べきです]]。 [SRC[>>142]] ;; [147] なぜ [[UTF-8]] 以外の余地を残しているのか謎です。 [FIG(data list middle)[ [25] [[MIME型]] :[[MIME型]]: [CODE[application/jose+json]] :説明:[[JOSE]] [[JSON]] 直列化 ]FIG] * 暗号化された JWK [27] [[公開鍵]]でない[[鍵]]を含んだ [[JWK]] や [[JWK集合]]は不正なアクセスから保護しなければ[MUST[ならない]]ということで、 [[JWK]] と [[JWE]] の組合せが規定されています。 [SRC[>>26]] [28] そのような場合に[[暗号化JWK]]や[[暗号化JWK集合]]が[RUBYB[推奨][recommend]]されます。 [DFN[[RUBYB[[RUBY[暗][あん]][RUBY[号][ごう]][RUBY[化][か]]JWK][Encrypted JWK]]]]や [DFN[[RUBYB[[RUBY[暗][あん]][RUBY[号][ごう]][RUBY[化][か]]JWK[RUBY[集][しゅう]][RUBY[合][ごう]]][Encrypted JWK Set]]]]は、 [[JWK]] や [[JWK集合]]を [[RFC 3629]] [[UTF-8]] [[符号化]]したものを[[平文]]値とする [[JWE]] です。 [SRC[>>26]] [29] [[JWE]] の[[ヘッダー引数]] [CODE[cty]] は、 [CODE[jwk+json]] や [CODE[jwk-set+json]] としなければ[MUST[なりません]]。 ただし、 [[応用]]が他の手段または表現法で [[JWK]] や [[JWK集合]]を暗号化していると分かっているときは、 [CODE[cty]] は[RUBYB[普通は][typically]]省略します。 [SRC[>>26]] ;; [30] なぜ非標準の方法を選択する余地があるのか謎です。 非標準の場合もその適切な [[MIME型]]ではなく [CODE[cty]] を省略するのが一般的だといいますが、そうすると [CODE[cty]] の意義も薄れます。 [[応用]]独自の方法でいいなら、 [[JWK]] や [[JWE]] を使う必然性も無いわけなのですが、 どういう用途が想定されていたのでしょう。 [33] [[JWE]] の[[直列化]]方式は特に規定されていません。 その他 [[JWE]] の各種特性は[[応用]]ごとに定める必要があります. * メモ [1] [CITE@en[[[RFC 7165]] - Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)]] ( ([TIME[2014-04-15 15:05:12 +09:00]] 版)) -[2] [CITE@en[[[RFC 7520]] - Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE)]] ([TIME[2015-05-20 10:10:42 +09:00]] 版) --[23] [CITE[RFC Errata Report » RFC Editor]], [TIME[2022-11-24T13:29:55.000Z]] [3] [CITE@en[[[JOSE]] (Javascript Object Signing and Encryption) is a Bad Standard That Everyone Should Avoid - Paragon Initiative Enterprises Blog]] ( ([TIME[2017-04-13 19:35:33 +09:00]])) - [37] [CITE@ja[XユーザーのTakashi Kawasakiさん: 「この識別子を1バイトでもケチる文化、90年代後半ぐらいから崩壊したんだっけなぁ。Javaとか、今までのケチケチはなんだったんだよと思うぐらいクラス名長くなったし、拡張子とかも。」 / X]], [TIME[午後2:28 · 2024年6月18日][2024-06-18T05:28:22.000Z]], [TIME[2024-06-19T03:14:15.000Z]] -- [34] [CITE@ja[Xユーザーのlef/HAYASHI, Tatsuyaさん: 「@espresso3389 それなのに!JWTに!謎の!3文字文化が!」 / X]], [TIME[午後4:50 · 2024年6月18日][2024-06-18T07:50:01.000Z]], [TIME[2024-06-19T03:14:15.000Z]] -- [35] [CITE@ja[XユーザーのTakashi Kawasakiさん: 「@lef 全部、HTTPが悪いのです。」 / X]], [TIME[午後5:09 · 2024年6月18日][2024-06-18T08:09:03.000Z]], [TIME[2024-06-19T03:14:15.000Z]] [36] なんか謎に [[HTTP]] に流れ弾いってるけど [[HTTP]] って別に省略文化ないよね。 [[RFC 822]] からの流れで[[ヘッダー名]]とかクッソ長いし。 ([[RFC 822]] というか[[インターネットメール]]って太古の昔からあるし [[Unix]] 文化と同じ方面なのにわりと[[富豪的]]よね。)