Re: [pkix] OCSP Signing Certificate Key usage standards

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

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

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