Idea Details

OCSP Trust Chain / Issuing CA's (i.e., stop requiring end-entity responder certs)

Last activity 06-13-2019 09:38 AM
Chris Bertagnolli's profile image
03-11-2015 02:57 PM

Problem Description

OCSP end-entity responder certificates are required to be stored locally to support OCSP validation; even when supplied the public certificate it does not walk the chain and requires a direct certificate comparison/validation.

 

Problem Impact

Utilization of CA SSO OCSP certificate validation is unmanageable due to operational overhead maintaining the end-entity certificates. This is especially difficult when supporting certificates/smartcards which may be issued by some external issuer that you trust; the end-point certificates are not generally distributed and often have very short lifetimes (i.e., 30-90 days); a single external end-point may also consist of numerous certificates in a load balanced environment. However, the issuing CA chains are published, known, and multi-year expirations.

 

Even internally it is unnecessary and counter to common PKI practice to require the end-entity certificates.

 

Requested Functionality
The product should take the public certificate that was presented as part of the response, build the chain by following the AIA entries in the certificate and make sure that it terminates at a root that was chosen to be trusted. If this is successful, then validation passes and the OCSP response is considered 'trusted'.


Comments

02-12-2019 04:08 AM

Thank you for your contribution of an enhancement idea to the CA Community. CA is continually working to improve its software and services to best meet the needs of its customers. Your input is vital to that effort. The CA Single Sign-On Product Management team is reviewing your enhancement suggestion following the process outlined here: https://communities.ca.com/docs/DOC-231170123 

The Community will continue to be able to vote on this enhancement idea.

02-08-2016 11:34 AM

Thank you for your contribution of an enhancement idea to the CA Community.   CA is continually working to improve its software and services to best meet the needs of its customers.  Your input is vital to that effort.  The CA Single Sign-On Product Management team has reviewed your enhancement suggestion and decided to maintain the idea for possible consideration in a future release.  The Community will continue to be able to vote on this enhancement idea.

04-08-2015 12:30 PM

Hi Christopher,  Apologies for not responding sooner.  I will be reviewing this over next 3-4 business days and get back to you.  

03-17-2015 10:24 AM

The concern isn’t whether the responder is a trusted responder.  The concern is if the response that was delivered is a trusted response.

 

Today you require that we provide a copy of the OCSP Signing certificate used to sign the response. These certificates by federal policy cannot be valid for more than 90 days.  This means the product forces us to go out and contact the owner of every responder we have every 90 days to be sure they send us a copy of their signing certificate to host in a directory.

 

What we are suggesting, is that instead of comparing the signing certificate to one you have a local copy of, instead just make sure that the OCSP signing certificate is issued by a CA that we have designated to trust.  Just like standard Windows OCSP Validation behavior and most other PKI implementations.

 

When validating a certificate and it’s response, the OS doesn’t need us to compare the signing certificate, it just needs to be sure that the certificate that issued the OCSP signing certificate is issued by one we trust.

 

Per RFC6960 section 2.2

  1. 2.2. Response

OCSP responses can be of various types.  An OCSP response consists of

a response type and the bytes of the actual response.  There is one

basic type of OCSP response that MUST be supported by all OCSP

servers and clients.  The rest of this section pertains only to this

basic response type.

 

All definitive response messages SHALL be digitally signed.  The key

used to sign the response MUST belong to one of the following:

 

-1 the CA who issued the certificate in question

 

-2 a Trusted Responder whose public key is trusted by the requestor

 

-3 a CA Designated Responder (Authorized Responder, defined in

Section 4.2.2.2) who holds a specially marked certificate issued

directly by the CA, indicating that the responder may issue OCSP

responses for that CA

 

It appears SiteMinder has implemented the least operationally sustainable condition of the “MUST” options to choose (Option 3) . It also requires the second least sustainable condition (option 2) as you also require us to provide the server certificate of the OCSP responder.

 

Both of those options in an isolated environment might work well were we only validating our own certificates and had access to and control over the responders. However, in a world of federated identities, the configuration requires us to get, maintain and monitor when the certificate changes on any responder(s) that we federate with. 

 

To put this in perspective: just one of our partners, has 10 load balanced responders each with a different server certificate and each with their own OCSP Signing certificate; to validate one partner's OCSP requires us to monitor and install 20 certificates in a repository to keep our trust working as we do not know which of the 10 will be the one answering a particular request. All of these certificates are not publicly posted where someone can easily harvest them and monitor on any kind of convenient basis.

 

We are asking you to implement “Option  1”.  Under this option, we only need to trust the root CA and the issuing CA of a partner's chain; a small number of certificates, which ARE publicly available, and change once every 3-6 years as opposed to 20+ certificates - which change every 90 days, not readily available and not on the same schedule.

03-17-2015 09:54 AM

Hi Christopher,   I believe it is common certificate validation practice to be sure that the end point to be validated can be proven to be in possession of the private key.  In order to do that I believe it is necessary for SiteMinder to obtain the certificate with the public key that matches the private key that the OCSP end entity holds.  Is that important to you?