OCSP レスポンス・リクエストデコーダー

使い方

1. .der ファイルをドロップするか、レスポンスを base64・PEM・16 進ダンプで貼り付けてください。解析はすべてページ内で行われます。
2. まずレスポンスステータスを見ます。successful 以外は署名も証明書ステータスも含まない、それ自体で完結したレスポンスです。
3. 証明書ステータスの表で good・revoked・unknown と thisUpdate・nextUpdate を、失効していれば失効時刻と理由もあわせて読みます。
4. 鮮度の行と、その横の基準時刻を確認します。nextUpdate を過ぎたレスポンスは、仕様に従うクライアントなら拒否します。
5. 最後の欄に送ったリクエストを貼ってノンスが返ってきたかを確かめ、証明書の欄で委任レスポンダーが id-kp-OCSPSigning を持つかを見ます。

よくある質問

レスポンスが 6 バイトしかありません。切れているのでしょうか。

まず違います。OCSPResponse は最初のフィールドがステータスの SEQUENCE で、続くレスポンス本体はステータスが successful のときにだけ存在します。したがって malformedRequest、internalError、tryLater、sigRequired、unauthorized は 5〜6 バイトで完結したレスポンスであり、署名も producedAt もなく、どの証明書にも言及しません。とくに tryLater は負荷のかかったレスポンダーが返す値で、クライアントは失敗扱いにせず再試行すべきものです。ステープリング用にレスポンスを保存しているなら、これを保存していること自体が不具合です。

CertID がいまだに SHA-1 なのはなぜですか。弱点ではないのですか。

認証ではなく識別に使われているからです。CertID は発行者名のハッシュ、発行者公開鍵のハッシュ、証明書のシリアル番号からなる索引キーにすぎず、返ってきた答えを守るのはレスポンス全体への署名であってこのハッシュではありません。衝突攻撃を成立させるには、名前のハッシュも鍵のハッシュもシリアルも一致する別の発行者が必要で、それで得られるものは攻撃者にとってほとんど価値がありません。だから RFC 6960 はこの場所に SHA-1 を残しています。一方、レスポンス自体が SHA-1 で署名されているなら、それは本当の問題であり、このデコーダーは別途警告します。

nextUpdate がありません。いつ期限切れになりますか。

形式上は期限切れになりません。RFC 6960 は、nextUpdate がない場合は常により新しい情報が利用可能であり、更新されるまで依拠してよいと述べています。実際にはクライアントが独自の上限を設けますが、解析できる限り受け入れ続ける実装も少なくありません。再送攻撃が狙うのはまさにこの窓です。ノンスが重要になる理由も同じで、ノンスがあれば捕まえたレスポンスを後の問い合わせに使い回せません。

レスポンダーがノンスを落としました。無効なレスポンスですか。

いいえ。これはデバッグ時に最もよく出会う驚きです。大手の公開 CA はレスポンスをまとめて事前生成し CDN から配るため、リクエストごとに異なるノンスを返す方式と相容れず、単に省きます。RFC 8954 もレスポンダーがこの拡張を無視することを認めています。レスポンス自体は有効で、失われるのは「自分の問い合わせのために作られた」という裏づけだけであり、鮮度は thisUpdate と nextUpdate に委ねられます。リクエストを貼り付ければ、返ってきたか、落とされたか、別の値で返ってきたかを教えます。最後の場合こそ、他人の問い合わせへの答えを見ているということです。

unknown と、何も述べていないレスポンスはどう違いますか。

unknown は明確な答えです。このレスポンダーにそのシリアルの記録がないという意味で、たいていは CertID が指す CA とは別の CA が発行したか、そもそも存在しない証明書です。good と同じではなく、同じに扱ってもいけません。その証明書については一切答えないという unauthorized とも違います。extended-revoke 拡張を持つレスポンダーなら意味はさらに狭まります。発行したことのない証明書にも 1970 年初頭を失効時刻とする revoked を返すため、そのレスポンダーの unknown は「自分の担当範囲外」に近くなります。

どの証明書についてのレスポンスかを教えたり、署名を検証したりできますか。

前者はできず、後者は意図的に行いません。CertID はハッシュとシリアルの組で、ハッシュは逆にたどれないため、レスポンスと証明書を突き合わせるにはその証明書の発行者名と鍵をハッシュして比べるしかなく、証明書が手元にある必要があります。署名検証には発行者の公開鍵が必要ですが、このページは持たず取得もしません。ただしバイト列だけでも署名者は絞れます。同梱された証明書の鍵ハッシュを CertID の issuerKeyHash と比べれば、発行 CA か委任レスポンダーかが分かります。

関連ツール