要約

  • RFC 3029では、データ検証サービスが正常に実行され、署名済みDVCを返しても、その中の対象判定は無効になり得た。
  • 応答は要求または要約値、時刻、通し番号、方針、全体状態と個別結果を結び付け、利用側には応答検証と採否判断が残された。

証明書という語は、合格証を連想させる。しかしRFC 3029のData Validation Certificate（DVC）は、対象へ有効性を与える免状ではなかった。検証サーバーが一定の条件で出した結論を署名し、持ち運べる形にした記録である。否定的な結論も正規の成果物だった。

仕様はDVCSCertInfoを、検証サービスが正常に実行された結果として返す。同じ段落で、正常実行は検証成功を意味せず、有効と無効のどちらの結果も入り得ると明記する。要求を処理できたこと、応答の発行者を確認できること、対象が方針を満たすことは、それぞれ独立している。

四つのサービスは観測範囲が違った

cpdは実データの提示を伴い、要求者がその時点でデータを保有しサーバーへ示したことを対象とした。ccpdはメッセージダイジェストだけを受け取り、その要約値に関する保有主張を扱った。後者から、サーバーが元データを見たとは言えない。

vsdは署名文書を検証し、署名の数学的正しさだけでなく、証明書パス、失効状態、信頼方針も調べた。vpkcは指定時刻に一つ以上の公開鍵証明書を検証した。DVCSはCRL、OCSP、ディレクトリ、別のDVCSを参照できたが、大規模な公開環境でCRLやOCSPを置き換えるものとはされなかった。

同じDVCという器でも、実データの提示、要約値の提示、署名文書の適合、証明書の適合では主張が異なる。一つの「検証済み」表示に統合すれば、この差が消える。

署名は判定条件ごと包んだ

DVCはCMS SignedDataで表現された。要求情報、対象と結び付くmessageImprint、単調増加する通し番号、応答時刻、検証方針、全体状態、証明書または署名ごとの詳細が分けて保持された。外部タイムスタンプなどを時刻に使う場合、DVCS自身がそれを検証する必要もあった。

利用者は外側の署名だけを確認して終われない。許容できる時刻、DVCS名、要求情報、要約値、署名、状態、サービス、方針を照合し、DVCSの署名証明書も評価する。正しい署名が別の要約値へ結び付いていれば、別の問いへの答えである。利用者が受け入れない方針による結論も、その用途には足りない。

方針は、同一対象への異なる結論を説明する。信頼するルート、状態情報、必要な署名数が違えば、サーバーは別の判断をし得る。DVCが固定するのは普遍的な真理ではなく、サーバー、時刻、方針、要求、結果の組である。

全体状態と個別状態は交換できない

証明書群の全体失敗では、どの要素が失敗したかを詳細から読む必要があった。複数署名文書では、一つの署名失敗が全体失敗になるとは限らない。方針が十分な数の署名を要求するなら、grantedWithModsになり得た。反対に、各署名が正しくても必要数や組合せを満たさず、全体では失敗する場合がある。grantedは全署名の検証成功に限られた。

WAITINGも弱い承認ではない。最終応答がまだないことを示し、後続手続は方針に委ねられた。

署名済みの否定と、署名できないエラー

サービスを実行したDVCは、対象が無効だと署名付きで報告できた。要求の解析や要求者認証に失敗し、検証を実行できなければ、返るのはエラー通知だった。前者は問いに「否」と答え、後者は問いへ到達していない。

DVCSの署名鍵が既知の危殆化状態にあるなど、有効な署名を作れない場合、署名者情報のない構造でエラーを送る規定もあった。クライアントはそれを重大かつ致命的なエラーとして扱い、内容を暗黙に信頼してはならない。署名済みの否定判定は認証された証拠だが、未署名エラーは応答権限そのものの故障である。

RFC 3029は2001年2月のExperimental文書で、Internet Standardではない。後のRFC 3379とRFC 5055は委任検証の要件とSCVPを別に定めた。それらはDVCSの普及を証明しない。残る教訓は、計算を委任しても判断の責任まで消えないことだ。何を問い、どの方針で、何が返り、アプリケーションが何を決めたかを分けなければならない。

出典

Lu HengはRFC 3029および関連PKIX標準の著者でも承認者でもない。ここでは明示した分析視点として各論考を用いる。