仕様書

意味

[2] JWS のヘッダー引数 x5u (X.509 URL) は、 JWS を RFC 4949 デジタル署名するのに使った鍵に対応する RFC 5280 X.509 公開鍵の証明書または証明書鎖の資源<code xmlns="http://www.w3.org/1999/xhtml">x5u</code>で指定された証明書鎖を参照する 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 公開鍵の証明書または証明書鎖の資源<code xmlns="http://www.w3.org/1999/xhtml">x5u</code>で指定された証明書鎖を参照する RFC 3986 URI を表します。 >>10

構文

[4] 値は URL です。

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

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

文脈

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

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

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

[13] そのような情報を指定する場合には、 参照される資源<code xmlns="http://www.w3.org/1999/xhtml">x5u</code>で指定された証明書鎖の最初の証明書の相当する欄と意味的に一貫していなければなりません。 >>10

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

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

処理

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

関連

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

メモ