要約

  • RFC 3709は証明書にロゴを関連づけられるようにした一方、その画像を証明書パスの自動検証から明確に除外した。
  • ハッシュ照合が示すのは、取得したファイルが証明書の参照と一致すること。パスの有効性や、描かれたロゴの正当性までは示さない。

一つの証明書に、二つの読み方

ソフトウェアは証明書を処理し、ポリシーに照らしてパスや署名、名前、制約などを検証する。人が証明書を見る場面では、相手を識別したり、機械的な条件を満たす複数の候補から選んだりすることがある。RFC 3709が扱ったのは後者だ。証明書の属性は人には読みにくく、最終的な選択を利用者に委ねるアプリケーションもある。

画像を署名対象の証明書に結びつけると、その画像も機械的な証明として扱えるように見える。RFC 3709はそこに線を引いた。ロゴは人が解釈するためのものであり、証明書パスの自動検証に積極的に関与してはならない。RFC 3709とRFC 6170を2023年に置き換えたRFC 9399も、この分離を維持している。自動検証と人の認識は補い合えるが、答える問いが異なる。 RFC 3709 §1.3 RFC 9399 §§1.3、6

画像そのものではなく参照を運ぶ

RFC 3709は、すべての画像や音声を証明書に埋め込むのではなく、取得先のURIとデータの一方向ハッシュを記録できるようにした。クライアントはファイルを取得して指定されたハッシュを計算し、一致しなければロゴデータを破棄する。直接参照は個々のファイルを指し、間接参照は複数の形式や候補を記した構造を指す。代替URIは同じデータを別の場所から取得する手段になる。

この照合の範囲は限定的だ。証明書の参照どおりのバイト列かは確認できるが、描かれた印が実際に記載組織に属すること、発行者が使う権利を持つこと、利用者が正しく認識することまでは証明しない。証明書パスが無効なら、画像の一致で補うこともできない。ファイルの同一性、パスの検証、人の解釈は別々の論点である。後継のRFC 9399はハッシュ規則を更新しており、RFC 3709にあるSHA-1の歴史的要件を現在の推奨として読んではならない。 RFC 3709 §4.2 RFC 9399 §4.2

検証に失敗した証明書のロゴは出さない

表示にも境界がある。RFC 3709は、証明書を正常に検証できない依存側ソフトウェアに対し、関連ロゴを表示しないよう求める。ロゴは他の識別情報と一緒に示すものであり、識別情報の代わりではない。仕様は、不誠実または不注意な発行者が、権利を主張できない名前や画像を証明書に含める可能性にも触れ、親しみのある図柄がソーシャルエンジニアリングに利用されうると警告する。

これはロゴに影響がないという主張ではない。RFC 3709は、図柄が証明書を信頼または利用するかという人の判断に影響すると認めている。だからこそ自動検証と人の認識を分離する。機械は証明書ポリシーで定めた検証結果を出し、その後、人が表示された識別情報、文脈、用途を考慮できる。ロゴは判断材料になりうるが、暗号学的な検証手順にはならない。 RFC 3709 §§1.3、5–7

改訂後も残った線引き

RFC 6170は2011年に拡張を更新し、RFC 9399は2023年に旧二文書を置き換えた。後継仕様は中心的な分離を保ちながら、遠隔ロゴ取得に伴う現代的なプライバシー問題も指摘する。TLS 1.3でサーバー証明書が暗号化されていても、クライアントが外部ロゴを取りに行けば、ネットワークの観測者にサーバーの識別情報を推測されることがある。キャッシュは露出の時点を変えるだけで、画像の証明力は変えない。 RFC 6170 RFC 9399 §9

この仕様の歴史的な意味は、証明書に図柄を足したことだけではない。確認可能な画像を、人のための手掛かりにとどめ、自動検証が暗黙の判定に使わないよう境界を設けたことにある。

出典