* 仕様書 [REFS[ - [7] [CITE@en[[[RFC 7515]] - JSON Web Signature (JWS)]], [TIME[2019-11-24 17:13:01 +09:00]] -- [47] [CITE@en[RFC 7515 - JSON Web Signature (JWS)]], [TIME[2020-03-29 16:13:43 +09:00]] -- [129] [CITE@en[RFC 7515 - JSON Web Signature (JWS)]], [TIME[2020-03-29 16:13:43 +09:00]] -- [138] [CITE@en[RFC 7515 - JSON Web Signature (JWS)]], [TIME[2020-03-29 16:13:43 +09:00]] -- [150] [CITE@en[RFC 7515 - JSON Web Signature (JWS)]], [TIME[2020-03-29 16:13:43 +09:00]] - [1] [CITE@en[[[RFC 7516]] - JSON Web Encryption (JWE)]], [TIME[2022-11-23T13:04:47.000Z]] - [3] [CITE@en[[[RFC 7516]] - JSON Web Encryption (JWE)]], [TIME[2022-11-24T09:23:18.000Z]] - [5] [CITE@en[[[RFC 7517]]: JSON Web Key (JWK)]], [TIME[2022-12-02T09:19:40.000Z]] ]REFS] * 鍵識別 [132] [[JWK]] において、 [[RFC 4949]] [[デジタル署名]]または [[RFC 4949]] [[MAC]] は、 必要な[[鍵]]を決定できないとき、[[失敗]]します。 [SRC[>>129, >>47]] [130] [[受信器]]は、 [[JWS]] の演算で使用する[[鍵]]を、 [[ヘッダー引数]] [CODE[jku]], [CODE[jwk]], [CODE[kid]], [CODE[x5u]], [CODE[x5c]], [CODE[x5t]], [CODE[x5t#S256]] の値から決定することもできますし、 [[JWS]] [[仕様書]]の定めない別の方法で決めても構いません。 [2] [[JWE]] にあっては、 それに対して [[JWE]] が[[暗号化]]された[[公開鍵]]について、 同様であります。 [SRC[>>1]] [131] [[生成器]]は、 他の方法によって[[鍵]]が決定されるべき場合を除き、 十分な情報を[[ヘッダー引数]]に含める[SHOULD[べきです]]。 [SRC[>>129]] ;; [137] [CODE[x5u]]、[CODE[jku]] のように、 [[鍵]]の決定に[[ネットワーク]]アクセスが発生し得るものもあります。 その場合、[[鍵]]の選択に不定の時間を要することがあり、 パフォーマンスや実装戦略上、[[エラー処理]]上の特段の配慮が必要となります。 また[[鍵]]の取得を試みた事実が送信者側または送信者の指定した第三者 (改竄を想定し得るケースでは、悪意ある第三者) に伝わり得ることにも注意が必要となります。 こうした懸念を排除できる場合を除き、 [[応用]]は外部から[[鍵]]を取得する方法を認めるべきではありません。 汎用的な [[JWS]] の実装は、 明示的に求められない限り、 こうした手法を有効にするべきではありません。 [133] これら[[ヘッダー引数]]の情報を使って[RUBYB[信頼決定][trust decision]]する場合にあっては、 これら[[ヘッダー引数]]は[[一貫性]]保護しなければ[MUST[なりません]] [SRC[>>129]]。 (つまり [[JWS保護ヘッダー]]としなければなりません。) しかし信頼決定に使われる情報が[[鍵]]だけの場合にあっては、 これら[[ヘッダー引数]]を[[一貫性]]保護せずとも構いません [SRC[>>129]]。 なぜなら、[[鍵]]が違えば[[検証]]が[[失敗]]するからです [SRC[>>129]]。 ;; [136] ところがこの要件が満たされない時[[受信者]]がこれを[[失敗]]とみなさなければならないという規定はありません。 [[セキュリティー]]の根幹に関わる部分がこんな曖昧でいいのでしょうか。 [151] [[鍵]]選択は、[[応用]]次第で異なる方法で行われ得るのであって、 [[仕様書]]には一定の指針が示されているものの、 すべての情報源を使う必要もなく、 適用し得るすべての[[鍵]]を使う必要もなく、 また順序もその通りである必要はないものとされています。 ともかく、指針として、次のようにします。 [SRC[>>150]] [FIG(steps)[ = [152] 適用し得る[[鍵]]を探します。情報源には次のものが含まれ得ます。 -- [153] [[応用プロトコル]]で指定されるもの -- [154] [CODE[jku]] で指定されたもの -- [155] [CODE[jwk]] で与えられたもの -- [156] [CODE[x5u]] で指定されたもの -- [157] [CODE[x5c]] で与えられたもの -- [158] その他[[応用]]で利用可能なもの = [159] 集めた[[鍵]]から適切なものを選択します。 -- [160] 例えば、 [CODE[kid]] や [CODE[x5t]] が合致するもののみを選ぶことができます。 -- [161] [[応用]]が [CODE[alg]], [CODE[use]], [CODE[key_ops]] を使う場合、これらの値に合わないものを除外します。 -- [162] その他[[応用]]規定の方法で適当なもののみ選んで構いませんし、 [[応用]]次第でまったく除外しなくても構いません。 = [164] [[鍵]]を[[整列]]します。 -- [165] 例えば、 [CODE[kid]] や [CODE[x5t]] に合致するものを、それ以外より先に試すことにできます。 -- [163] その他特定条件のものを優先しても構いませんし、 [[応用]]次第でまったく順序を改めなくても構いません。 = [166] [[鍵]]について、信頼決定します。 -- [167] [[応用]]の信頼条件に満たない鍵を使った署名は、拒絶します。 -- [168] 信頼条件とは、例えば、 鍵の出所、 [[URL]] から取得した[[鍵]]にあっては[[TLS証明書]]が[[妥当]]であったか否か、 [[X.509証明書]]中の[[鍵]]にあっては妥当な[[証明書鎖]]に裏付けられたものか否か、 その他[[応用]]の有する情報を用い得ます。 = [169] [[鍵]]について、 [[JWS]] の [[RFC 4949]] [[デジタル署名]]や [[RFC 4949]] [[MAC]] の検証を試みたり、 [[JWE]] の[[解読]]を試みたりします。 -- [170] 得られた[[鍵]]をすべて試みても構いませんし、 上限数を設定しても構いません。 ]FIG] ;; [171] [[デジタル署名]]や [[MAC]] の検証や[[解読]]に失敗するなら、 信頼決定するまでもありませんから、 [[応用]]次第で信頼決定を後回しにすることもできます。 [SRC[>>150]] * JWS 取得プロトコル [63] [[JWS]] および [[JWE]] は [CODE[jku]], [CODE[x5u]] に [[URL]] を指定して別ファイルを参照できます。 [DFN[JWSの取得プロトコル]]には次のような制約が規定されています。 [64] [[資源]]の[RUBYB[取得][acquire]]に使う[[プロトコル]]は、 [[一貫性保護]]を提供するものでなければ[MUST[なりません]]。 [SRC[>>47, >>5]] [66] [RUBYB[取得][retrieve]]に使う [[HTTP]] [CODE[GET]] [[要求]]は、 [[TLS]] を使わなければ[MUST[なりません]] [SRC[>>47, >>5]]。 [CODE[jku]] や [CODE[x5u]] に対応する実装は、 [[TLS]] に対応しなければ[MUST[なりません]] [SRC[>>138]]。 [141] [[RFC 6125]] [[service identity]] [[検証]]を実施しなければ[MUST[なりません]]。 [SRC[>>47, >>138, >>5]] [67] ここで[[仕様書]]は [[TLS]] について [[RFC 2818]] ([[HTTPS]]) と [[RFC 5246]] ([[TLS/1.2]]) を参照していますが、その意図するところは不明です。 (他の理論上はあり得る方法ではなく) [[HTTPS]] を使うことを要求するべきでしょうか。 さらに [[RFC 6125]] が参照されていますが、 [[RFC 6125]] 自身は [[HTTPS]] に適用されるとはしておらず、 適用する場合 [[HTTPS]] の[[仕様書]]の改訂が必要になることを述べています。 [SEE[ [[service identity]] ]] 現時点でそのような改訂版はありません。 これは [[JWS]] に関して [[RFC 6125]] を適用するべき特別の規定と解すべきなのか、 勇み足なのか、判断しかねます。 (現実の実装状況がどうなっているのかはまた別の問題であります。) [140] [[TLS]] については、 実装するべき版は時代により変化し得るものであって、執筆時点では [[RFC 5246]] [[TLS/1.2]] である [SRC[>>138]] と明記されています。 [139] [[TLS]] では[RUBYB[[[機密性]]][confidentiality]]保護と[[一貫性保護]]を提供する [[ciphersuite]] を使わなければ[MUST[なりません]]。 適切な [[ciphersuite]] については [[RFC 6176]] その他現行の [[IETF TLS working group]] 出版物を参照するべきです。 [[RFC 7572]] も参照するべきです。 [SRC[>>138]] [68] こうした要件を満たし現実的に運用可能な[[プロトコル]]となると、 [[HTTPS]] ([[URL scheme]] は [CODE[https:]]) をおいて他にはありません。 (理論上は [[FTP]] over [[TLS]] なども該当し得ますが、 [[相互運用性]]に難があります。) ;; [65] 一昔前ならこうした要件は[[保安輸送路]]といわれていました。 [4] なおこうした要件は [[JWS]] だけでなく、 [[JWS]] の仕様書を参照する [[JWE]] の場合にも適用されます [SRC[>>3]]。 * メモ