検証ループを作成せずにOCSP署名を行う最も安全な方法は何ですか？
Windows 2008 SP1以降でサポートされる最も安全なOCSP検証を有効にしたいと思います。
次の情報に基づいて、OCSP証明書に
id-pkix-ocsp-nocheckを実装する必要がありますか？もしそうなら、それはOCSP応答が偽造される可能性があり、取り消された証明書が被害者に気付かれないようにすることを意味しますか？
OCSP応答の署名は、Windows VistaまたはWindows Server 2008クライアントによって有効であると見なされるために、次の規則に従う必要があります。
Windows Vistaの場合、OCSP署名証明書は、検証される証明書と同じCAによって発行されるか、OCSP応答は発行CAによって署名される必要があります。
Windows Vista Service Pack 1およびWindows Server 2008の場合、OCSP署名証明書は、証明書チェーンにOCSP署名EKU拡張が含まれている限り、信頼できるルートCAまでチェーンできます。
CryptoAPIは、循環依存を回避するために、このOCSP署名証明書チェーンの失効チェック中に独立したOCSP署名者をサポートしません。 CryptoAPIは、CRLおよび委任されたOCSP署名者のみをサポートします。
OCSP署名証明書で失効チェックが実行されないように、OCSP署名証明書でid-pkix-ocsp-nocheck（1.3.6.1.5.5.7.48.1.5）拡張を有効にすることをお勧めします。これにより、OCSP署名証明書を検証するためにCRLがダウンロードされなくなります。
（ ソース ）
通常のチェーン検証では、チェーン内の各証明書の失効ステータスを確認する必要があります。失効ステータスを確認するには、CRLまたはOCSP応答を取得する必要があります。両方のタイプのオブジェクトが署名され、使用前に検証する必要があります。 CRLまたはOCSP応答の検証には、オブジェクトの発行者の公開鍵（別の証明書チェーンの検証から取得した公開鍵）と比較して、署名の検証が伴います。プロセス全体が再帰的であり、プロセスで多くの証明書を検証することになる可能性があります。
もちろん、再帰はループの可能性があり、ループは悪いです。
単純なパス、ルート-> SubCA-> EEを考えます。
パスを検証し、すべての署名を検証し、SubCAが取り消されていないことも確認するポイントに達しました。ここで、EE証明書を検討しています。 EE証明書には、OCSPレスポンダを指すAIA拡張が含まれています。そのレスポンダに話しかけ、OCSP応答を受け取ります。すごい ！ OCSP応答は、その秘密鍵（EE証明書の署名に使用されたものと同じ秘密鍵）を使用して、SubCAによって直接署名されたようです。これは良いことです。失効ステータスを含め、そのキーをすでに検証しているため、OCSP応答の署名を確認するだけで十分であり、OCSPを「使用」できます。応答とは、その内容を見て信頼することを意味します）。
上記のこのモデルは、 RFC 256 のセクション4.2.2.2の「状況2」です。OCSP応答の検証に使用される証明書は、ターゲット証明書を発行したCAの証明書（ "SubCA"）と同じです。この例では）。
セクション4.2.2.2の「シチュエーション3」として説明されている別のモデルがサポートされることになっています。OCSP応答は、である証明書（「Resp」と呼ぶ）を持つ専用レスポンダによって署名されています。 SubCAによって発行されました。 Resp証明書はOCSP応答に埋め込まれています。それをどのように検証しますか？署名を確認することも、Respが委任されたOCSPレスポンダをマークする特定のEKUを備えていることを確認することも簡単です。しかし、Resp証明書自体が取り消されていないことをどのように確認しますか？
次の3つの方法があります。
- 情報を提供するCRLまたは別のOCSPレスポンダを使用します。もちろん、これによりプロセスが再帰的になります。
- Respは特定の
id-pkix-ocsp-nocheck拡張。Resp証明書を「取り消し不可能」にします（したがって、定義によって取り消されないため、その取り消しステータスを取得する必要はありません）。 - CAは気にせず、RespにOCSPレスポンダとして itself を指すAIAを含めます。したがって、Respを検証するには、まずRespを検証する必要があります。この鶏と卵の問題に直面すると、泣き、無関心でCAに加わり、単にRespが「おそらく問題ない」と考えます。
残念ながら、私は、本当によく知っているはずの巨大な企業や主権国家が後援する大きなPKIで3番目の方法に遭遇しました。
RFC 2560のセクション4.2.2.2は、OCSレスポンダが「何か他の何か」であり、検証エンジンが何らかの「ローカル構成」を介して安全であることがわかっている「状況1」を示唆しています（「ローカル構成」という表現はRFCに対応しています） 「妖精の魔法によって」を意味する）。
あなたが引用するテキストは、VistaまでのWindowsが状況2と3を処理する方法を知っていることを意味します。VistaSP1以降、それは状況1も次のように処理します。OCSPレスポンダ証明書は「任意の証明書」にすることができますが、CryptoAPIはそれを検証するためにCRLを必要とします。これは、検証ループを回避するための抜本的な方法です。
概要：PKIを構築している場合、問題を最小限に抑える方法は、OCSP応答の署名にCAキーを使用することです。 本当に異なるキーを使用する必要がある場合（たとえば、CAはオフラインであることが想定されているが、OCSPレスポンダは本質的にオンラインである）、CAが専用の証明書を発行するようにするOCSPレスポンダ用。この専用レスポンダ証明書には、id-kp-OCSPSigning EKU およびid-pkix-ocsp-nocheck拡張子。取り消しできない証明書はポリシーの重大な違反と見なされる可能性があるため、推奨される方法は、証明書の有効期間を非常に短くすることです。レスポンダ証明書を2週間ほど有効に設定し、新しい週を1週間ごとに発行します。
他の人が指摘したように、多くの実装は、「余分な」証明書（メインチェーンにはないが、CRLやOCSP応答などの失効オブジェクトを検証するために使用される）の失効ステータスをチェックしません。商業的方法）物事を適切に行わない大きなPKIに対処する。 PKIが実際に、あなたが知り、働き、セキュリティを提供するポイントに私たちを近づけるために、それよりも上に（上で説明したように）行動するのはあなたの道徳的義務です。
現実には、証明書チェーン全体をOCSPまたはCRLを使用して検証する必要があります。ただし、実際には、取り消される証明書の数はごくわずかです。 SSL/TLSハンドシェイクを高速化するにはchrome デフォルトでOCSPとCRLの使用が削除されました （Chromeの設定を再度有効にできます）代わりにChromeは、独自のブラックリストのシステムに依存しています。
「OCSP応答が偽造される可能性があり、期限切れの証明書が被害者に気付かれないようにすることを意味しますか？」脅威モデルを指定していませんが、答えは次のとおりです。
攻撃者がネットワークを制御している場合（中間者など）、はい、攻撃者はOCSP応答を偽造し、失効した証明書を被害者に気付かれないようにすることができます。攻撃者はOCSP応答を偽造する必要さえありません。彼は OCSP応答をブロック することができ、ブラウザは失敗したOCSPを無視し、証明書が有効であると想定します。 （ブラウザがこのように機能するのはなぜですか？ Webサイトの破壊を回避する を行う必要があります。）これは、証明書の構成方法に関係なく当てはまります。
はい、これは、OCSPが中間者である、またはOCSPクエリへの応答を偽装する可能性がある攻撃者に対して現在、OCSPが役に立たないことを意味します。だからそうなるのです。