RE: Feedback requested on draft guidance for OCSP responders

["Dave Engberg" <dengberg@corestreet.com>]

 

Dave -

 

Thanks for putting this together.  This sort of guidance will be very useful for interoperability.  A few notes:

 

Your doc says that responder delegated certificates must include either id-ocsp-nocheck or cRLDistributionPoint URLs.  Some parts of the government are using applications that perform OCSP and will not process CRLs (random example: Akamai's hosted SSL web services), so you may want to consider making a stronger endorsement for id-ocsp-nocheck for the broadest interoperability.

 

One of the main considerations for cost/performance of an OCSP deployment is the ability to use caching and/or pre-signing.  I'd recommend an explicit statement about the requirements for servers regarding requests containing an OCSP nonce.  For example, see the Lightweight Profile's section 1.2.1, which says that a compliant server may return a response without a nonce, regardless whether the client includes one.  Requiring signed responses with a nonce would have a significant impact on an OCSP deployment's cost and security (e.g. vulnerability to DoS and server compromise attacks).

 

I don't believe that any commercial OCSP plug-ins or applications would have any problems with your profile.  The only possible exception that I am aware of would be Adobe Acrobat, which does not support cached/pre-signed responses without changing a configuration option from its default setting.  Other native OCSP (e.g. Mozilla/Firefox, Windows Vista) should work fine.

 

 

Regarding your last section regarding OCSP trust models, I am positive that there are OCSP client implementations that would fail to accept an OCSP response if it were signed by a different CA key than the entity cert, unless the second CA certificate happened to also include the "ocspSigning" extendedKeyUsage, which collapses the solution down to Option #3.

 

Standing up a separate CA key pair to generate responses doesn't provide any particular deployment advantages over a similar box with the same key pair using a delegated ocspSigning responder certificate. But a compromise of the former box would allow an attacker to issue themselves acceptable certificates from the government CA, and a compromise of a delegated-responder would only permit the unrevocation of existing certificates.  Plus the significant increase in key usage providing more fuel for cryptoanalysis, etc.

 

I think you'll want to steer folks towards Option #3.  Every OCSP client implementation will support #3, although things get a little unpredictable if you don't use the noCheck extension in the responder's cert.

 

Dave

 

---

From: pkits@nist.gov [mailto:pkits@nist.gov] On Behalf Of David A. Cooper
Sent: Friday, August 18, 2006 3:46 PM
To: Multiple recipients of list
Subject: Feedback requested on draft guidance for OCSP responders

All,

In order to comply with FIPS 201, U.S. Federal agencies are going to be required to begin deploying PKI to all of their employees in the near future.  FIPS 201 requires that certificate status information be made available via OCSP for authentication certificates.  In order to help ensure that the OCSP responders that are deployed for this purpose can work with as many clients as possible, we are looking to provide guidance to those who will be setting up OCSP responders.

I have developed the initial draft guidance document (attached), which is slightly long that one page in length.  This guidance was developed using the draft Lightweight OCSP Profile for High Volume Environments Internet-draft as the basis for most of its content.

We are seeking feedback from people who are knowledgeable about the capabilities of OCSP clients.  In particular, we would like to know if existing OCSP clients would be able to interoperate with OCSP responders that functioned in conformance with this guidance or if the guidance would need to be adjusted in order to ensure interoperability.

We are also interested in knowing whether the rules imposed on OCSP responders could be relaxed without compromising interoperability.  In particular, section 4.2.2.2 of RFC 2560 states that clients "MUST reject the response if the certificate required to validate the signature on the response fails to meet at least one of the following criteria:

1. Matches a local configuration of OCSP signing authority for the certificate in question; or
2. Is the certificate of the CA that issued the certificate in question; or
3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage extension and is issued by the CA that issued the certificate in question."

The guidance document does not consider option 1 since that would not work well for relying parties that do not belong to the same organization as the issuing CA.  For options 2 and 3, the guidance document is more restrictive than RFC 2560.  For option 2 it requires that the same key be used to sign both the certificate and OCSP response, and for option 2, it requires that the OCSP responder's certificate be signed by the CA that issued the certificate in question using the same key as was used to sign the certificate.  I am concerned that requiring the same key will cause problems for CAs that perform key rollover, since the CAs may have trouble signing the OCSP responder's certificate using any key other than the most recently generated one.  On the other hand, it was my guess that many OCSP clients would be unable to validate OCSP responses if the CA used different keys to sign the OCSP response and the certificate in question.  So, I would like to hear from those who are familiar with the capabilities of OCSP clients about whether or not the clients could validate OCSP responses if the OCSP responder's certificate and the certificate in question were signed by the CA using different keys.

Any information that people could provide us on this issue would be appreciated.

Thanks,

Dave

smime.p7s