Re: [pkix] OCSP Signing Certificate Key usage standards

["Dr. Massimiliano Pala" <[e-mail]>]

Hi Daniel,

personally, as long as the key is properly protected (and you are using 
HSMs for that - so it should be ok) and rotated (limited lifetime) and 
you have an easy way to request the different certificates from the 
different CAs (hopefully you have an automated interface to them), I 
would go with Option #2 - this simplifies key management as you said.

However, this comes with a price on security in case the key is 
compromised - in this case, you will have to revoke 20 certificates at 
once and get a new certificate for all the 20 CAs you are serving. For 
this, the "automation" for getting the certificate and have the old ones 
revoked is a key feature, IMHO.

To address the last point, my suggestion would be to play ahead. Have 2 
different keys and have certificates issued for both of them. Use one 
key in production and keep the other one in a safe place (separate form 
the deployment one). Then setup a procedure to switch the keys when 
needed - this allows you to stop using a compromised key without having 
to wait for the 20 (or more) CAs to process your revocation and new 
certificate requests which can now be processed in parallel. (This said, 
clients will continue to trust the compromised key until the proper 
revocation is provided by the different CAs - but that is true for both 
options)

If you value simplicity, this might provide you with an easy 
implementation and yet gives you the ability to respond quickly. Of 
course, not knowing the capabilities and setup of your systems there 
might be more clever and/or better fitting solutions... this is a very 
generic response!

Last but not least - I am a bit curious about the HSM you are using: in 
my experience current HSMs are really too slow for any crypto operation 
that is in response to live traffic (modern CPUs outperform them by A 
LOT). For that reason (and others, actually) it is common, today, to 
pre-produce all responses and store them in CDNs so that the performance 
of the HSMs is not an issue (but, of course, you might have a 
"publishing" window vulnerability in this case).

I hope this helps,

Cheers,
Max


On 4/4/16 4:07 PM, daniel bryan wrote:
> 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
>
>
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix
>
> -- 
> Massimiliano Pala, PhD
> Director at OpenCA Labs
> twitter: @openca