要約

  • STIR OCSPドラフト第14版は、証明書全体の状態ではなく、PASSporTの特定番号が現在も権限範囲にあるかをTNQueryで尋ねる。
  • 署名済み応答が証明するのは証明書と番号の関係であり、話者の人物、目的、要求の正当性、通話結果ではない。
  • 応答不能、期限切れ、unknown、TNQuery欠落を同じ「不正」にまとめず、終端側の方針判断と分けて保存する必要がある。

失効していなくても範囲外になり得る

通常のOCSPは証明書をgood、revoked、unknownで表す。ところがSTIRの委任証明書では、電話番号の集合が変動する。証明書自体が有効でも、ある番号だけが委任範囲から外れている場合がある。

draft-ietf-stir-certificates-ocsp-14は、PASSporTのorigにある番号を単一要求のTNQueryへ入れる。応答側が署名済み応答にもその番号を返せば、応答の時間境界において、その証明書が番号について有効だと伝える。

ここから先を推測してはいけない。応答は、誰が端末を持つか、本人が発信に同意したか、用件が真実か、送金してよいかを知らない。RFC 8224でも、検証後の認可は別工程として仕様の外に置かれている。

要求にTNQueryがあったのに応答から消えていれば、応答側は番号が範囲内だと確認できなかった。unknownもnot goodとして扱う。だが、これは詐欺の認定ではない。権限データの更新遅延、OCSP障害、証明書経路の失敗、実際のなりすましを、運用記録では分離しなければならない。

stplが短くするのは待ち時間

通話開始時のOCSP照会は遅延を生む。そこでドラフトは、OCSP応答をPASSporTに載せるstplクレームを定義する。認証サービスは事前生成された応答を受け取ることも、通話ごとに取得することもできる。

ステープルは証拠の配送経路を変えるだけで、意味を増やさない。検証側は署名、時刻、番号、証明書経路、委任範囲、PASSporTを確認する。その後に、終端ドメインの規則が許可、警告、追加確認、拒否を選ぶ。

多数の番号を含む証明書では、発信し得る番号ごとに応答を用意する必要がある。保存済みの全応答が正しく署名されていても、在庫が全番号を覆うとは限らない。完全性、鮮度、配布、暗号学的妥当性は別々の指標である。

照会先には通話の関係が見える

リアルタイム照会は、発信番号と、その通話を扱う検証サービスをOCSP運用者に知らせる。TLSは第三者の盗聴を抑えるが、応答者自身の可視性は消さない。ステープリングはその漏えいを減らす一方、期限管理と在庫管理を必要とする。

新鮮さを優先すればメタデータが集中し、プライバシーを優先すればキャッシュの古さが問題になる。この選択は署名者が自動的に持つ権限ではない。終端側が自らの責任で決め、説明できる形で残すべきである。

「検証済み」の一語では監査できない

残すべき記録は、観測したorig、証明書と経路、TN権限範囲、要求、署名済み応答と時刻、照会方式、検証結果、方針の版と理由、実行した通話処理、観測結果である。

第14版はIESG承認を経てRFC Editorの待ち行列にあるが、正式発行まではInternet-Draftである。この進捗は実装、通信事業者での採用、迷惑電話減少の証拠ではない。

出典