Subject: [pkix] OCSP Signing Certificate Key usage standards

From: daniel bryan <[email-masked]>
Date: Mon, 4 Apr 2016 15:07:26 -0400

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

---

From: "Liaquat Khan" <[email-masked]>
Date: Mon, 4 Apr 2016 20:44:13 +0100

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:[email-masked]] On Behalf Of daniel bryan
Sent: 04 April 2016 20:07
To: [email-masked]
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

---

From: daniel bryan <[email-masked]>
Date: Mon, 04 Apr 2016 23:10:13 +0000

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 <[email-masked]>
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:[email-masked]] *On Behalf Of *daniel bryan
> *Sent:* 04 April 2016 20:07
> *To:* [email-masked]
> *Subject:* [pkix] OCSP Signing Certificate Key usage standards
>
>
>
> Hello,
>
> *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
> *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
>

---

From: "Dr. Massimiliano Pala" <[email-masked]>
Date: Tue, 5 Apr 2016 11:13:48 -0300

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:
> Suppose I have a service, and I want to provide certificate status on 
> 20 different certificate authorities using a "CA Designated responder" 
> *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.
>
> 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:
>
> *
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>
> -- 
> Massimiliano Pala, PhD
> Director at OpenCA Labs
> twitter: @openca

---

From: "Dr. Pala" <[email-masked]>
Date: Mon, 4 Apr 2016 16:54:42 -0300

Hi Daniel,

I hope this helps,

Cheers,
Max

---

From: "Dr. Pala" <[email-masked]>
Date: Tue, 5 Apr 2016 10:53:45 -0300

Hi Daniel,

I hope this helps,

Cheers,
Max

---

From: "Dr. Pala" <[email-masked]>
Date: Tue, 5 Apr 2016 10:57:10 -0300

Hi Daniel,

I hope this helps,

Cheers,
Max

---

From: "Dr. Pala" <[email-masked]>
Date: Tue, 5 Apr 2016 10:39:32 -0300

Hi Daniel,

I hope this helps,

Cheers,
Max

---

From: daniel bryan <[email-masked]>
Date: Tue, 05 Apr 2016 18:57:40 +0000

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-masked]> wrote:

> 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.
>
> 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.
>
> 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)
>
> 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
>
>
> * Q2:* Does the IETF/cabforum/Any other authority provide
> pkix mailing [email-masked]://www.ietf.org/mailman/listinfo/pkix
>
>
> --
> Massimiliano Pala, PhD
> Director at OpenCA Labs
> twitter: @openca
>

---

From: "Dr. Pala" <[email-masked]>
Date: Wed, 6 Apr 2016 10:49:47 -0300

Hi Daniel,

for the noCheck extension - that is a tricky one. In general, it does 
simplify checks on the client side for sure. The only issue is then that 
you can not reliably revoke the certificate (although you can stop using 
it!) in case of compromise. That means that if you plan to use that, you 
might want to use short-lived certificates for that. In particular, a 
validity period of 1 or 2 weeks might be a good choice (since no 
reliable revocation can be put in place). This, of course, depends on 
how easy is the integration with your CA. I have seen deployments with a 
3-6 months validity period for such certificates as well - it all 
depends on your risk profile.

For the "vulnerability window", I refer to the fact that in the 
pre-computed environments, usually the OCSP will generate all the 
responses every few hours. So, unless your system makes "exceptions" in 
case of revocation events (e.g., triggers the generation of the OCSP 
response for the revoked certificate and its publication on the CDN 
right away), there might be a delay between the revocation request/event 
and the publication of the appropriate OCSP response on the CDN (e.g., 
if the publication happens once every 6 hrs, you might have a 
"vulnerability window" as big as 6 hrs).

Last thing I want to point out is that if you use pre-computed responses 
(i.e., no NONCE is present that links the response to a specific client 
request), you are susceptible to reply attacks for the validity of the 
response. In the pre-computed environment this is bad since even if your 
system publishes the revoked OCSP response right away after revocation, 
an attacker could use the original non-revoked response for up to the 
expiration of the response (which, in the example above, should be 
greater than 6 hrs). On the other hand, where "real-time" revocation 
information is needed, the use of short-lived OCSP responses and the use 
of NONCEs provides better security (which seems what you might need).

A mixed solution could be to generate the responses with short validity 
period (e.g., 5mins) [no NONCE] and cache them for that period. This 
would allow for better performance (e.g., less signatures required than 
the NONCE case), at the expense of not being able to leverage CDN 
deployments (usually needed only for billions of requests per day).

Cheers,
Max

P.S.: Another option to speedup the validation process is to use the 
CA's certificate as the OCSP responder directly. This removes the 
requirement of validating a certificate chain (although, as you can 
imagine, it would be appropriate only for the pre-computed case as you 
do not want to expose those keys to possible attacks)

P.P.S.: Long time ago I promised myself I would publish some I-D about 
the OCSP-over-DNS idea (pre-computed, but distributed and eliminates the 
need for large OCSP infrastructures for CAs == lower costs) and its 
successor that tackles the redundancy of information in the case of 
"valid" responses (but this requires a new type of response).

On 4/5/16 3:57 PM, daniel bryan wrote:
> 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-masked] 
> <mailto:[email-masked]>> 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.
>
>     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)
>
>     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
>
>
>>     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.
>>
>>     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
>>     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.
>>     *
>>     guidance/standards on key management in this situation that I can
>>     use to support/defend the choice?
>>
>>     Thanks,
>>
>>     --Dan
>>
>>
>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca