Re: [pkix] OCSP Signing Certificate Key usage standards

["Liaquat Khan" <[e-mail]>]

Hi Daniel 

 

We have deployed both options in the past, although with a variation on option 2 in that we generate separate PKCS#10 CSR from the same public key to send to the different CAs.  I don’t think there is much difference in performance with either option, remember the OCSP responder needs to find the right responder certificate to attach to the OCSP response even if it’s using a single private key – although I have not specifically tested the performance difference.  In terms of security having separate keys is better although if they are in an HSM compromise is unlikely and if somehow one can be comprised then so can others.   I am not aware of any specific industry/standards-based guidance to help choose between these options. 

 

Regards

LK

 

From: pkix [mailto:[e-mail]] On Behalf Of daniel bryan
Sent: 04 April 2016 20:07
To: [e-mail]
Subject: [pkix] OCSP Signing Certificate Key usage standards

 

Hello,

I am looking for guidance/standards on deploying an OCSP service in specific regards to the key management of the OCSP Signing certificate. 

Suppose I have a service, and I want to provide certificate status on 20 different certificate authorities using a "CA Designated responder" described in section 2.2 of RFC 6960. Technically I have a few options:

Option #1: Generate 20 Keys on my HSM, Create 20 PKCS 10s, Submit all 20 for Signing to each CA. Import the Signed Certificate into my OCSP service.

Option #2: Generate 1 Key on the HSM, Create 1 PKCS 10 with a generic CN, Submit 1 CSR to all 20 CA's. The CA will override the CN value during Signing to reference their CA name, Import all 20 Signed certificates into my OCSP service.

Option #1 adds complexity to key management, could potentially have an impact on signing speed. An advantage is that if a key is lost/compromised, it would only involve troubling one CA instead of all.

Option #2 will greatly simplify key management, and I speculate it will increase the signing speed potential of the HSM, being that it doesn't have to determine which key to use from a pool of 20 keys.  Obviously the bad side is, if we ever loose the key, I would have to get all 20 CAs to sign another request. This is especially bad when the certs have the noCheck extension.



Here are my 2 questions:

 

Q1: From a security perspective, is option #2 worth considering. Simplification is a huge priority, but security is a must.

Q2: Does the IETF/cabforum/Any other authority provide guidance/standards on key management in this situation that I can use to support/defend the choice?

Thanks,

--Dan