ADCSとCRL/OCSPのPKIについてはかなり読みましたが、まだあるいくつかの質問に対する答えが見つからないようです。
OCSPが配置されている場合でも、(delta)CRLが必要であることは明らかです(たとえば、OCSPはCRLを使用して証明書が有効かどうかをチェックします)が、クライアントがアクセスするURLを持っていることも重要です。 (デルタ)CRL。
明確ではないのは、証明書にOCSP URLが提供されていて、そのOCSPにアクセスできる場合でも、クライアントがCRL/Delta CRLをダウンロードするかどうかです。
理にかなっているのは(ウェブサーバーの例)に似ているようです:
ここで私が確信していないのは、上記の仮定が正しいかどうかですが、たとえそうであったとしても、他のいくつかの質問が生じます(すべての質問は、上記の手順が正しいと仮定しています)。
証明書がOCSPとCRLの両方を指定し、OCSPが応答を提供できない場合、クライアントはCRLにフォールバックします(そしてキャッシュします)。では、ユーザーが次に同じWebサイトにアクセスしようとするとどうなるでしょうか。 CRLからの応答がキャッシュされることを念頭に置いて、TTLが期限切れで、OCSPに再度接続しないようにしない限り、常にそれを信頼しますか?
クライアントが本当にCRL/Delta CRLをダウンロードするのは、証明書にOCSPが提供されていない場合、またはOCSPが回答を提供しない場合だけですか?
私は、Vista OCSPクライアントが応答をキャッシュすることを読みましたが、それをキャッシュする期間と、これが構成可能かどうかについての情報は見つかりません。
RFC 5280のセクション6.3-インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト(CRL)プロファイル は、CRLのみを使用した証明書の検証について説明しています-OCSPについては言及していません。
から RFC 5019のセクション3.1-大量環境用の軽量オンライン証明書ステータスプロトコル(OCSP) (RFC 2119の観点から)すべてが曖昧であることがわかります。
3.1。 OCSPレスポンダーの発見
クライアントは、[PKIX]で定義されているauthorityInfoAccess拡張をサポートしなければならず、id-ad-ocspアクセス方法を認識しなければなりません。これにより、CAはクライアントにOCSPサービスに接続する方法を通知できます。
クライアントが、OCSPレスポンダを指すauthorityInformationAccess(AIA)拡張とCRLを指すcRLDistributionPoints拡張の両方を含む証明書のステータスをチェックしている場合、クライアントは最初にOCSPレスポンダへの接続を試みる必要があります(SHOULD)。ローカルで構成されたタイムアウトと再試行回数の後にレスポンダーからOCSPResponseが受信されない場合、クライアントはCRLの取得を試行できます(MAY)。
上記の[PKIX]は RFC 528 によって廃止されたRFC 3280を参照しています
したがって、正確な処理順序については、主にクライアント側の実装に依存します。
あなたの最後の質問(3)に関して、私はWindowsが有効期限情報が含まれていない場合(nextUpdate
)が期限切れになるまでOCSP応答をキャッシュすると信じています。