仕様書

鍵識別

[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

[137] x5u、jku のように、 鍵の決定にネットワークアクセスが発生し得るものもあります。 その場合、鍵の選択に不定の時間を要することがあり、 パフォーマンスや実装戦略上、エラー処理上の特段の配慮が必要となります。 また鍵の取得を試みた事実が送信者側または送信者の指定した第三者 (改竄を想定し得るケースでは、悪意ある第三者) に伝わり得ることにも注意が必要となります。 こうした懸念を排除できる場合を除き、 応用は外部から鍵を取得する方法を認めるべきではありません。 汎用的な JWS の実装は、 明示的に求められない限り、 こうした手法を有効にするべきではありません。

[133] これらヘッダー引数の情報を使って信頼決定trust decisionする場合にあっては、 これらヘッダー引数は一貫性保護しなければなりません >>129。 (つまり JWS保護ヘッダーとしなければなりません。) しかし信頼決定に使われる情報が鍵だけの場合にあっては、 これらヘッダー引数を一貫性保護せずとも構いません >>129。 なぜなら、鍵が違えば検証が失敗するからです >>129。

[136] ところがこの要件が満たされない時受信者がこれを失敗とみなさなければならないという規定はありません。 セキュリティーの根幹に関わる部分がこんな曖昧でいいのでしょうか。

[151] 鍵選択は、応用次第で異なる方法で行われ得るのであって、 仕様書には一定の指針が示されているものの、 すべての情報源を使う必要もなく、 適用し得るすべての鍵を使う必要もなく、 また順序もその通りである必要はないものとされています。 ともかく、指針として、次のようにします。 >>150

  1. [152] 適用し得る鍵を探します。情報源には次のものが含まれ得ます。
    • [153] 応用プロトコルで指定されるもの
    • [154] jku で指定されたもの
    • [155] jwk で与えられたもの
    • [156] x5u で指定されたもの
    • [157] x5c で与えられたもの
    • [158] その他応用で利用可能なもの
  2. [159] 集めた鍵から適切なものを選択します。
    • [160] 例えば、 kid や x5t が合致するもののみを選ぶことができます。
    • [161] 応用が alg, use, key_ops を使う場合、これらの値に合わないものを除外します。
    • [162] その他応用規定の方法で適当なもののみ選んで構いませんし、 応用次第でまったく除外しなくても構いません。
  3. [164] 鍵を整列します。
    • [165] 例えば、 kid や x5t に合致するものを、それ以外より先に試すことにできます。
    • [163] その他特定条件のものを優先しても構いませんし、 応用次第でまったく順序を改めなくても構いません。
  4. [166] 鍵について、信頼決定します。
    • [167] 応用の信頼条件に満たない鍵を使った署名は、拒絶します。
    • [168] 信頼条件とは、例えば、 鍵の出所、 URL から取得した鍵にあってはTLS証明書が妥当であったか否か、 X.509証明書中の鍵にあっては妥当な証明書鎖に裏付けられたものか否か、 その他応用の有する情報を用い得ます。
  5. [169] 鍵について、 JWS の RFC 4949 デジタル署名や RFC 4949 MAC の検証を試みたり、 JWE の解読を試みたりします。
    • [170] 得られた鍵をすべて試みても構いませんし、 上限数を設定しても構いません。
[171] デジタル署名や MAC の検証や解読に失敗するなら、 信頼決定するまでもありませんから、 応用次第で信頼決定を後回しにすることもできます。 >>150

JWS 取得プロトコル

[63] JWS および JWE は jku, x5u に URL を指定して別ファイルを参照できます。 JWSの取得プロトコルには次のような制約が規定されています。

[64] 資源の取得acquireに使うプロトコルは、 一貫性保護を提供するものでなければなりません。 >>47, >>5

[66] 取得retrieveに使う 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 の仕様書の改訂が必要になることを述べています。 service identity 現時点でそのような改訂版はありません。 これは JWS に関して RFC 6125 を適用するべき特別の規定と解すべきなのか、 勇み足なのか、判断しかねます。 (現実の実装状況がどうなっているのかはまた別の問題であります。)

[140] TLS については、 実装するべき版は時代により変化し得るものであって、執筆時点では RFC 5246 TLS/1.2 である >>138 と明記されています。

[139] TLS では機密性confidentiality保護と一貫性保護を提供する ciphersuite を使わなければなりません。 適切な ciphersuite については RFC 6176 その他現行の IETF TLS working group 出版物を参照するべきです。 RFC 7572 も参照するべきです。 >>138

[68] こうした要件を満たし現実的に運用可能なプロトコルとなると、 HTTPS (URL scheme は https:) をおいて他にはありません。 (理論上は FTP over TLS なども該当し得ますが、 相互運用性に難があります。)

[65] 一昔前ならこうした要件は保安輸送路といわれていました。

[4] なおこうした要件は JWS だけでなく、 JWS の仕様書を参照する JWE の場合にも適用されます >>3。

メモ