Re: OCSP Signing Certificate Key usage standards

Max, thanks for the info. I think you brought up some great points, and I
agree that auto enrollment would save lots of time during the re-key. I
also appreciate you sharing the idea of having a spare key on standby in a
separate secure location.  Do you typically use the noCheck extension on
OCSP Signing certificates? I imagine if you don't revocation loops could be
introduced in your PKI.  I also agree with you that HSMs are slower then
modern CPUs for real time crypto operations, and it's important to use
pre-computed responses, e-tags, stapling, anything to offload the OCSP/HSM.
Sometimes a client needs high assurance of real time status and forces a a
signing operation by sending a nonce in the request. Is this what you meant
when you says "publishing window vulnerability"? In my opinion anything you
can do to increase the signing speed potential seems beneficial. Thanks
again for the info, and for openca!

On Tue, Apr 5, 2016 at 1:37 PM Dr. Pala <[email protected]> wrote:

> 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 [email protected]://www.ietf.org/mailman/listinfo/pkix
>
>
> --
> Massimiliano Pala, PhD
> Director at OpenCA Labs
> twitter: @openca
>
> _______________________________________________
> pkix mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pkix
>

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix