kid

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

仕様書

意味

[2] JWS の kid (key ID (鍵識別子) ) ヘッダー引数は、 JWS の保安に用いた鍵を示すヒントを表します。 >>1

[9] JWE の kid (key ID (鍵識別子) ) ヘッダー引数は、 それに対して JWE が暗号化された公開鍵を示すヒントを表します。 JWE を解読するために必要な秘密鍵の決定に使えます。 >>8

[14] JWK の kid (key ID (鍵識別子) ) 鍵引数は、 特定の鍵に一致するために使います。 例えば鍵ロールオーバー中に JWK集合中の鍵の集合から鍵を選ぶために使います。 >>13

[3] JWS の起案者 (originator) は、 kid ヘッダー引数によって受信者に対して鍵の変更を明示的に信号できます。 >>1, >>8

[6] JWS や JWE と JWK と併用する時、 JWS の kid の値は JWK や JWE の kid の値との照合に用いられます。 >>1, >>13

値

[4] kid 値の構造は、 規定されていません (unspecified) 。 >>1, >>13 大文字・小文字区別ありの文字列 >>13 でなければなりません >>1。

[7] 仕様書のいう構造がない、規定されていないというのは、 特定の構文が規定されず任意の文字列を使っていいということです。 大文字と小文字を区別しなければならない、 完全一致しないといけないとしたら、 それはそれで不透明な構造と規定されているといえなくもないですが...

[10] RFC 7520 の JWS や JWE や JWK の kid の利用例では、 UUID のように見える文字列や、 メールアドレスのように見える文字列が使われています。

[11] 当事者が鍵を特定するヒントとして付与する文字列で、 プロトコルとしてはその内容に関知しないので、何でもいいのでしょう。 UUID もメールアドレスも大域的に固有な値ですが、 そこまでする必要すらなく、 鍵を区別する必要のある系内部で十分に特定可能ならそれで良いものです。

[12] といっても JWS や JWE や JWK を使う応用によっては、 具体的にどのように使うか規定しているかもしれません。

[15] JWK集合中の kid 値は、 鍵ごとに違う値を使うべきです。 >>13

[16] しかし kty が違うものの応用にとって等価な鍵とみなせるようなときには、 同じ kid を使うこともできます。 >>13

文脈

[5] kid ヘッダー引数の利用は任意です。 >>1, >>13

処理

JOSE鍵識別

メモ