要約

  • RFC 5276 の ERS を含む SCVP 応答は、依拠当事者が信頼する公開鍵で署名を検証しなければならず、応答内の trust anchor は受け手が採用することも拒否することもできる。
  • 正しく署名され保存された回答は、指定条件下でサーバーが何を述べたかを証明するが、別のアプリケーションの信頼方針や最終認可を拘束しない。

長期アーカイブから二十年前の SCVP 応答が取り出された。証明書経路も失効情報もそろい、EvidenceRecord の時刻印チェーンも検証できる。応答自体にも署名がある。それでも、新しい検証者は最初にこう問わなければならない。

「私は、この応答署名鍵を信頼していたのか。今も、その由来を検証できるのか。」

署名が数学的に正しいだけでは足りない。署名者鍵が依拠当事者の信頼範囲に入っていなければ、応答は真正な権限ある証言にならない。RFC 5276 はこの境界を明記する。ERS を含む SCVP 応答の署名は、依拠当事者が信頼する公開鍵で検証されなければならない。

これは細部ではない。RFC 5276 は保存技術に権限を与える文書ではなく、保存された検証材料を別の判断者が再評価できるようにする文書だからである。

応答内の trust anchor は命令ではない

SCVP 応答は、ERS の内部層を検証するための trust anchor を含むことができる。応答署名で保護されていれば、搬送中の改変を検出できる。しかし RFC 5276 は、依拠当事者がその anchor を使ってもよいし、帯域外で取得した別の anchor を使ってもよいとしている。未署名応答に含まれる anchor は無視すべきである。

つまり、コンテナに入っていること、署名されたコンテナに入っていること、受け手が権限源として採用することは三段階である。第一段階は所在、第二段階は応答の完全性と出所、第三段階はローカルな信頼方針だ。

RFC 5280 も trust anchor を経路検証アルゴリズムの入力として扱う。異なるアプリケーションは異なる anchor を採用できる。同じ証明書経路が、ある用途では受理され、別の用途では拒否されても矛盾ではない。経路は自分の権限を自分で生成しない。

長期保存によって、この選択が消えることもない。二十年前に一組織が採用した anchor は、別組織や別用途に自動的に継承されない。保存されるべきなのは anchor 自体だけでなく、「誰が、どの方針で、何の目的に採用したか」である。

WantBack は対象と証拠を対にする

SCVP では、クライアントが WantBack によって追加情報を要求する。RFC 5276 は、終端証明書、完全な証明書経路、部分経路、失効情報について EvidenceRecord を求める識別子を定義した。

EvidenceRecord の要求には、保護対象そのものの WantBack が必要である。完全経路の証拠を求めるなら完全経路も求める。応答には両方が必要で、EvidenceRecord は返された DER 形式の CertBundle 値を覆う。単一証明書では CertReply 内の証明書値を覆う。CRL や OCSP 応答では、各失効資料とそれを覆う証拠を対応付けなければならない。

一括要求では EvidenceRecordWantBacks が使われる。各項目の targetWantBack が、どの種類の応答を覆うかを示す。他の WantBack 応答と一対一で対応しなければならない。この構造により、「証拠らしい塊が応答に付いていた」という曖昧な説明は通用しない。

検証者は、証拠が特定の返却バイト列を覆っていることを示せる。その後で初めて、そのバイト列が目的のアーカイブ署名に関係するかを検討できる。証拠範囲と業務関係は別々に証明される。

証拠が無い状態を正確に残す

サーバーが要求された EvidenceRecord を返せない場合、RFC 5276 は対応する応答型を返しつつ値を空にする。一括形式では、その対象の evidenceRecord を欠落させる。対象データの WantBack 自体が要求されていなければ、wantBackUnsatisfied になる。

空値は証明書の失効判定ではない。保存証拠が得られなかったという状態である。逆に、EvidenceRecord が検証できても、証明書状態が良好になるわけではない。証拠の存在と検証結果を一つの状態コードに畳むと、監査は根拠を失う。

運用画面は少なくとも、要求構文、対象資料の返却、証拠の返却、証拠の検証、方針に基づく経路結果を分けるべきだ。そうすれば、欠けているのが証拠なのか、経路なのか、信頼方針なのかを局所的に直せる。

部分経路では署名者を別に結ぶ

RFC 5276 は、終端証明書から anchor までを含む完全経路だけでなく、終端証明書の発行 CA から始まる部分経路も扱う。終端証明書は署名済みアーカイブ資料の中に置き、その資料側の EvidenceRecord で保護できる。

この方式は、同じ時期・同じ PKI の多数の資料で上位経路を再利用できる。だが将来の検証者は、アーカイブ資料内の証明書がその資料とともに保護されていたこと、資料の署名がその証明書で検証できること、証明書が部分経路に接続すること、失効資料が必要な期間を扱うことを別々に確認する。

部分経路の EvidenceRecord が完全でも、資料署名が壊れていることはある。資料内の証明書が完全でも、部分経路が別の発行系列であることもある。保存効率は関係証拠を不要にせず、将来の組み立て責任を増やす。

過去の肯定回答は後から更新され得る

SCVP の validationTime は、過去の時点について証明書状態を評価するために使える。サーバーは適切な歴史資料を持たない場合、エラーを返さなければならない。この機能は、現在は期限切れでも署名時には有効だった証明書を扱うために重要である。

しかし RFC 5055 は、過去時点で知られていた状態が、後に得られる最も完全な情報とは限らないと警告する。後日発行された失効通知が、元の validationTime より前の無効日を示すことがある。その場合、元の肯定応答は真正な過去の記録でありながら、現在の判断を支配できなくなる。

したがって、アーカイブは対象時刻と知識取得時刻を両方保持する。最初の応答を消さず、後の情報がどの判断を置き換えたかを記録する。改ざん防止と結論の訂正可能性は両立する。

また、クライアントが応答署名や MAC を検証せず、要求 nonce の一致も確認しなければ、改変や再送に欺かれ得る。長期間保存する前に、取得時点の真正性を確保しなければならない。

ERS は一度きりの封印ではない

RFC 4998 の EvidenceRecord は、アーカイブ時刻印の系列を使ってデータの存在と完全性を維持する。時刻印証明書や署名アルゴリズムが弱くなる前に、次の時刻印で前の時刻印を覆う。ハッシュ木のアルゴリズムが弱くなる場合は、古い時刻印と対象データを新しいハッシュ構造で覆い、新しいチェーンを開始する。

証拠は保存した瞬間に永遠になるのではなく、強度が残っている間に更新され続ける。運用者は最後の時刻印の有効性、アルゴリズム方針、次回更新期限、過去層の検証資料を監視する必要がある。

cryptoInfos には証明書、失効資料、trust anchor、アルゴリズム強度の履歴などを入れられるが、RFC 4998 はこの領域が時刻印で保護されていないと述べる。補助情報が同梱されていることと、その情報が認証済みであることを混同してはならない。

再現できる判断記録

長期判断には、アーカイブ資料のハッシュ、実際の署名、使用証明書、照会時刻、検証方針と全パラメータ、anchor の出所、SCVP 応答署名、返却経路、失効資料、各資料を覆う EvidenceRecord、更新履歴、後から判明した情報、用途別認可を結ぶ記録が必要だ。

この記録があれば、別の依拠当事者は元の結論を再現した上で、自分の方針で再評価できる。元の結論と異なる結果になっても、どの入力が違うかを説明できる。これが証拠の可搬性であって、結論の強制ではない。

RFC 5276 は、特定の SCVP 実装が普及しているとも、保存結果に法的効果があるとも述べない。ここで扱うのは仕様が作る証拠境界であり、実運用の成功を推測することではない。