Feedback requested on draft guidance for OCSP responders

["David A. Cooper" <david.cooper@nist.gov>]

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

GuidanceforOCSPReponders.doc