Re: [pkix] OCSP Signing Certificate Key usage standards

[daniel bryan <[e-mail]>]

Thanks for the info, I agree with you that it doesn't matter if 1 key, or
all the keys are on the HSM, if the HSM is compromised, everything would
need to rekeyed.

On Mon, Apr 4, 2016 at 3:44 PM Liaquat Khan <[e-mail]>
wrote:

> 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
>