x5u

ヘッダー引数 x5u (JOSE ヘッダー)

仕様書

意味

[2] JWSヘッダー引数 x5u (X.509 URL) は、 JWSRFC 4949 デジタル署名するのに使ったに対応する RFC 5280 X.509 公開鍵証明書または証明書鎖資源を参照する RFC 3986 URI を表します。 >>1

[6] JWEヘッダー引数x5u (X.509 URL) は、 それに対して JWE暗号化した RFC 5280 X.509 公開鍵証明書または証明書鎖に関するものを表します。 JWE解読に必要な秘密鍵の決定に使えます。 >>5

[11] JWK 鍵引数x5u (X.509 URL) は、 RFC 5280 X.509 公開鍵証明書または証明書鎖資源を参照する RFC 3986 URI を表します。 >>10

構文

[4] 値は URL です。

[3] URL で指定するファイルについては、 x5uで指定された証明書鎖の要件が適用されます。

[8] URL で指定されたファイルの取得については、 JWSの取得プロトコルの要件が適用されます。

文脈

[7] x5u 引数の利用は任意です。 >>1, >>10


[12] JWK において鍵用法、算法、その他の省略可能な情報を共に指定しなければならないということはありませんが、 指定することで RFC 5280 PKIX 証明書を扱わない応用との相互運用性を改善させられるかもしれない >>10 とされます。

[14] 例示により usealg が想定されている >>10 ことがわかります。「その他」は alg 依存の各種鍵引数を指すと思われます。 「鍵用法」が指すものは不明瞭ですが、 use の他に key_ops も含まれると解するのが妥当でしょう。

[13] そのような情報を指定する場合には、 参照される資源の最初の証明書の相当する欄と意味的に一貫していなければなりません>>10

[15] つまり JWK に参照された証明書メタ情報を入れておけば、 x5u で参照された証明書を取得して PKIX 証明書として解釈する実装と、 そこまでせずに JWKメタ情報だけ読んで (自体は使わない) 処理をする (ことができる) 実装との相互運用性が向上する、 ということらしいです。
[16] しかし応用間の相互運用性が云々と言っているのは謎です。 特定応用「内」では当該メタ情報を含めなければならない、含めなくても構わない、 いつどの情報を読んでどう処理する、 ということを決めておかなければ、 そもそも相互運用不能です。 そのような合意が取れない異なる応用「間」の相互運用性が求められるのは、 いったいどういう状況なのでしょう。
[17] 多数の JWK 応用に適用可能な汎用的な JWK 実装を提供する場合でしょうか? でもそういうものを実現したいなら、それこそ JWKRFC がしっかり要件を定めないと無理でしょう...

[18] なお、これと同等の規定が x5c, x5t にもあります。

処理

JOSE鍵識別, JWSの取得プロトコル

関連

[9] URL でなく証明書鎖自体を指定する x5c もあります。

メモ