暗号化JWK

JOSE

[5] JOSE は、 JSON 形式で署名暗号化を扱う技術群や、 その標準化を担当した IETF のグループです。

仕様書

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

技術

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

[4] JOSE

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

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

JWS と JWE

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

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

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

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

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

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

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

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] 公開鍵でないを含んだ JWKJWK集合は不正なアクセスから保護しなければならないということで、 JWKJWE の組合せが規定されています。 >>26

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

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

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

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

メモ

[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 文化と同じ方面なのにわりと富豪的よね。)