[132] JWK において、 RFC 4949 デジタル署名または RFC 4949 MAC は、 必要な鍵を決定できないとき、失敗します。 >>129, >>47
[130]
受信器は、
JWS の演算で使用する鍵を、
ヘッダー引数
jku,
jwk,
kid,
x5u,
x5c,
x5t,
x5t#S256
の値から決定することもできますし、
JWS 仕様書の定めない別の方法で決めても構いません。
[2] JWE にあっては、 それに対して JWE が暗号化された公開鍵について、 同様であります。 >>1
[131] 生成器は、 他の方法によって鍵が決定されるべき場合を除き、 十分な情報をヘッダー引数に含めるべきです。 >>129
[133] これらヘッダー引数の情報を使って信頼決定する場合にあっては、 これらヘッダー引数は一貫性保護しなければなりません >>129。 (つまり JWS保護ヘッダーとしなければなりません。) しかし信頼決定に使われる情報が鍵だけの場合にあっては、 これらヘッダー引数を一貫性保護せずとも構いません >>129。 なぜなら、鍵が違えば検証が失敗するからです >>129。
[151] 鍵選択は、応用次第で異なる方法で行われ得るのであって、 仕様書には一定の指針が示されているものの、 すべての情報源を使う必要もなく、 適用し得るすべての鍵を使う必要もなく、 また順序もその通りである必要はないものとされています。 ともかく、指針として、次のようにします。 >>150
[63] JWS および JWE は jku, x5u に URL
を指定して別ファイルを参照できます。
JWSの取得プロトコルには次のような制約が規定されています。
[64] 資源の取得に使うプロトコルは、 一貫性保護を提供するものでなければなりません。 >>47, >>5
[66]
取得に使う HTTP GET 要求は、
TLS を使わなければなりません >>47, >>5。
jku や x5u に対応する実装は、
TLS に対応しなければなりません >>138。
[141] RFC 6125 service identity 検証を実施しなければなりません。 >>47, >>138, >>5
[67]
ここで仕様書は TLS について RFC 2818 (HTTPS)
と
RFC 5246 (TLS/1.2)
を参照していますが、その意図するところは不明です。
(他の理論上はあり得る方法ではなく) HTTPS
を使うことを要求するべきでしょうか。
さらに RFC 6125 が参照されていますが、
RFC 6125 自身は HTTPS に適用されるとはしておらず、
適用する場合 HTTPS の仕様書の改訂が必要になることを述べています。
[140] TLS については、 実装するべき版は時代により変化し得るものであって、執筆時点では RFC 5246 TLS/1.2 である >>138 と明記されています。
[139] TLS では機密性保護と一貫性保護を提供する ciphersuite を使わなければなりません。 適切な ciphersuite については RFC 6176 その他現行の IETF TLS working group 出版物を参照するべきです。 RFC 7572 も参照するべきです。 >>138
[68]
こうした要件を満たし現実的に運用可能なプロトコルとなると、
HTTPS (URL scheme は https:)
をおいて他にはありません。
(理論上は FTP over TLS なども該当し得ますが、
相互運用性に難があります。)
x5u、jkuのように、 鍵の決定にネットワークアクセスが発生し得るものもあります。 その場合、鍵の選択に不定の時間を要することがあり、 パフォーマンスや実装戦略上、エラー処理上の特段の配慮が必要となります。 また鍵の取得を試みた事実が送信者側または送信者の指定した第三者 (改竄を想定し得るケースでは、悪意ある第三者) に伝わり得ることにも注意が必要となります。 こうした懸念を排除できる場合を除き、 応用は外部から鍵を取得する方法を認めるべきではありません。 汎用的な JWS の実装は、 明示的に求められない限り、 こうした手法を有効にするべきではありません。