要約
- RFC 9919に従う新しい軽量OCSPクライアントは、
CertIDの発行者名ハッシュと発行者鍵ハッシュにSHA-256を使わなければならない。RFC 5019互換の旧クライアントは、実行可能になり次第SHA-1から移行する。 - レスポンダーは後方互換性のため、SHA-1とSHA-256の
CertIDを持つ二つのSingleResponseを一つの応答に含められる。クライアントが使ったハッシュ方式のログは、その互換応答をやめる判断材料になり得る。 - しかしログが数えるのは測定対象の入口へ届いた要求だけである。クライアントやプロキシのキャッシュ、事前生成、stapling、別レスポンダー、帯域外の運用合意は分母の外に残り得る。
CertIDのSHA-1は証明書発行者を識別する二つの値の計算方式であり、OCSP応答を保護する署名アルゴリズムではない。- 廃止には観測地点、対象人口、除外、終了条件、決定者、canary、fallback、例外期限、切替後の結果を結び付けた記録が要る。
静かな入口と残っている依存
あるレスポンダーでSHA-1要求がゼロになった、と考える。これは測定として正しいかもしれない。誤りは、その一行を「すべての旧クライアントが更新済み」と読み替えるところから始まる。
高負荷向けprofileは、そもそもoriginへのアクセスを減らすためにある。署名済み応答を事前に作り、クライアントが保存し、HTTPプロキシが再利用し、サーバー側でも配布できる。TLSなどの交換に応答を含めれば、クライアントはOCSPレスポンダーへ別のHTTPセッションを張らずに検証できる。originログの減少は設計上の成功であって、必ずしもクライアント更新の証拠ではない。
交通分散も視野を分ける。一つの地域、一つのhostname、一つのcertificate familyだけを見れば、別経路に残ったSHA-1は現れない。さらにOCSPはレスポンダー能力をプロトコル内で通知しないため、運用者間の帯域外合意でprofileを選ぶ場合がある。その契約や閉域網の設定は、通常のアクセスログから復元できない。
したがって、ゼロには注釈が必要だ。どの入口、どの証明書、どの期間、どの再利用経路を含むゼロなのか。それを答えられないグラフは、移行状況ではなく一つの観測装置の状態を表す。
SHA-256への変更点を取り違えない
RFC 5019はissuerNameHashとissuerKeyHashにSHA-1を要求した。RFC 9919は旧profileを廃止し、新profileのクライアントにSHA-256を要求する。一方、旧クライアントとの互換性を即座に切断するわけではない。SHA-1利用者は速やかに移行すべきで、レスポンダーは必要な間だけ両方のSingleResponseを含められる。
ここには恒久的な互換権はない。SHA-1を必要とするクライアントがいなければ、SHA-1のCertIDを含む応答を配布すべきではない。要求アルゴリズムのログは、その条件を評価する一つの手段である。しかしRFCは、何日間ゼロならよいか、どの比率を許すか、どのレスポンダーを全体とみなすかを定めていない。
安全性の説明も精密でなければならない。RFC 6960では、CertID.hashAlgorithmは発行者名と発行者公開鍵のハッシュを作る方式で、serial numberと共に照会対象を識別する。BasicOCSPResponse.signatureAlgorithmは別の欄である。RFC 9919は、CertID計算でのSHA-1自体を暗号学的懸念とはせず、相互運用のためソフトウェアがSHA-1対応を維持することで複雑さと潜在的attack surfaceが増える点を問題にする。
つまり廃止の価値は実装面にある。ただし「SHA-1署名をやめた」と報告してはならない。測っている層が違う。
分母を設計する
観測台帳には、全レスポンダーinstance、地域、hostname、経路、certificate family、主要クライアント群を並べる。各行で、直接要求、client cache、proxyやCDN、stapling、offline利用、fallbackを観測できるかを記す。見えないものはゼロではなく「未観測」とする。
期間はresponse lifetimeより短くできない。長く保存された旧応答を使うクライアントは、期限まで再要求しないからである。リリース周期が長い機器、保守窓が限定された企業estate、地域別の経路も別に扱う。canaryは、実際に異なる経路を代表するcertificate familyと利用者を含めなければならない。
必要なのは巨大なtelemetry計画ではない。分子が何を数え、分母が何を含み、何を除外したかを説明できる最小の記録である。除外を承認する人と期限まで書けば、未知を「移行済み」に変換せずに済む。
廃止記録の形
記録には、決定範囲とowner、観測地点と分母、SHA-1例外一覧、単一/二重応答方針、cacheとstaplingの範囲、測定期間、終了条件、canary期間、rollback条件、fallback経路、例外の失効日を含める。
切替後には、SHA-1要求の再出現、応答error、検証失敗、fallback発動、影響した証明書群とサービス結果を追記する。承認だけでは廃止は終わらない。結果が加わって初めて、後から判断を再現できる。
IETFは相互運用の境界を定める。個々のproduction変更を所有するのは運用者である。だから互換性は、誰も決めないまま残すものでも、静かなグラフを理由に消すものでもない。
情報源
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
