Is it me or is ocsp.comodoca.com doing something wrong?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Is it me or is ocsp.comodoca.com doing something wrong?

Igor Sverkos
Hi,

I tried to validate a certificate from Comodo using their OCSP, but I
cannot verify the response:

  3073455752:error:27069076:OCSP routines:OCSP_basic_verify:signer
certificate not found:ocsp_vfy.c:85:


The certificate I want to validate was issued by

C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO
High-Assurance Secure Server CA

The cert chain is:
0: <The certificate I want to validate>
1: COMODO High-Assurance Secure Server CA
2: AddTrust External CA Root (aka USERTrust)

My steps:
1) # wget -O level1.pem
"https://support.comodo.com/index.php?dload=Download&_m=downloads&_a=downloadfile&downloaditemid=101"


2) Verifying the level1.pem certificate (COMODO High-Assurance Secure
Server CA), this check will also make sure, that the root certificate
(level2) is present on my system:

# openssl verify -CApath /etc/ssl/certs/ level1.pem
level1.pem: OK


3) Now I created the OCSP request:

# openssl ocsp -CApath /etc/ssl/certs -CAfile level1.crt \
   -issuer level1.crt -cert level0.crt \
   -url http://ocsp.comodoca.com \
   -reqout request.der

To share it with you, I called base64 on request.der:

# base64 request.der
MHYwdDBNMEswSTAJBgUrDgMCGgUABBT950qEosxt1h7EdDv7v4q+SjikWAQUP9W10NZEeVBKF6Ob
jErcuLAiZGsCEExO1VM4XfiatpW5unQb4gOiIzAhMB8GCSsGAQUFBzABAgQSBBAo6nzdxvtLR5Gi
hO44WuHv

So you can grab the response from
<http://ocsp.comodoca.com/MHYwdDBNMEswSTAJBgUrDgMCGgUABBT950qEosxt1h7EdDv7v4q+SjikWAQUP9W10NZEeVBKF6ObjErcuLAiZGsCEExO1VM4XfiatpW5unQb4gOiIzAhMB8GCSsGAQUFBzABAgQSBBAo6nzdxvtLR5GihO44WuHv>



When I compare against responses from ocsp.verisign.com or
ocsp.globalsign.com I am missing the OCSP responder certificate in the
response.


So my question is:
1) Is it ok, what Comodo is doing here?

2) If it is OK, how can I be sure, that the response is from a valid
source, when I cannot validate (=or how can I validate this
certificate/response)?

Thanks.


/etc/ssl/certs is from ca-certificates package (20130119)
I am using OpenSSL 1.0.1e 11 Feb 2013


--
Regards,
Igor
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Is it me or is ocsp.comodoca.com doing something wrong?

Ryan Hurst-3
They are doing a CA signed OCSP response, this is legitimate.

We will do this in the not so distant future as well for many of our
responses also.

You basically need to look at the responderID and see if it's the same
entity that signed the certificate you are checking if so use that key
material to do the validation.

Ryan

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Igor Sverkos
Sent: Wednesday, June 12, 2013 4:41 PM
To: [hidden email]
Subject: Is it me or is ocsp.comodoca.com doing something wrong?

Hi,

I tried to validate a certificate from Comodo using their OCSP, but I cannot
verify the response:

  3073455752:error:27069076:OCSP routines:OCSP_basic_verify:signer
certificate not found:ocsp_vfy.c:85:


The certificate I want to validate was issued by

C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO
High-Assurance Secure Server CA

The cert chain is:
0: <The certificate I want to validate>
1: COMODO High-Assurance Secure Server CA
2: AddTrust External CA Root (aka USERTrust)

My steps:
1) # wget -O level1.pem
"https://support.comodo.com/index.php?dload=Download&_m=downloads&_a=downloa
dfile&downloaditemid=101"


2) Verifying the level1.pem certificate (COMODO High-Assurance Secure Server
CA), this check will also make sure, that the root certificate
(level2) is present on my system:

# openssl verify -CApath /etc/ssl/certs/ level1.pem
level1.pem: OK


3) Now I created the OCSP request:

# openssl ocsp -CApath /etc/ssl/certs -CAfile level1.crt \
   -issuer level1.crt -cert level0.crt \
   -url http://ocsp.comodoca.com \
   -reqout request.der

To share it with you, I called base64 on request.der:

# base64 request.der
MHYwdDBNMEswSTAJBgUrDgMCGgUABBT950qEosxt1h7EdDv7v4q+SjikWAQUP9W10NZEeVBK
MHYwdDBNMEswSTAJBgUrDgMCGgUABBT950qEosxt1h7EdDv7v4q+F6Ob
jErcuLAiZGsCEExO1VM4XfiatpW5unQb4gOiIzAhMB8GCSsGAQUFBzABAgQSBBAo6nzdxvtLR5Gi
hO44WuHv

So you can grab the response from
<http://ocsp.comodoca.com/MHYwdDBNMEswSTAJBgUrDgMCGgUABBT950qEosxt1h7EdDv7v4
q+SjikWAQUP9W10NZEeVBKF6ObjErcuLAiZGsCEExO1VM4XfiatpW5unQb4gOiIzAhMB8GCSsGAQ
UFBzABAgQSBBAo6nzdxvtLR5GihO44WuHv>



When I compare against responses from ocsp.verisign.com or
ocsp.globalsign.com I am missing the OCSP responder certificate in the
response.


So my question is:
1) Is it ok, what Comodo is doing here?

2) If it is OK, how can I be sure, that the response is from a valid source,
when I cannot validate (=or how can I validate this certificate/response)?

Thanks.


/etc/ssl/certs is from ca-certificates package (20130119) I am using OpenSSL
1.0.1e 11 Feb 2013


--
Regards,
Igor
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Is it me or is ocsp.comodoca.com doing something wrong?

Igor Sverkos
Hi,

Ryan Hurst wrote:
> They are doing a CA signed OCSP response, this is legitimate.
>
> We will do this in the not so distant future as well for many of our
> responses also.

If this is called "CA signed OCSP response", how is *your* current
response, which you will change in future, called?


> You basically need to look at the responderID and see if it's the same
> entity that signed the certificate you are checking if so use that key
> material to do the validation.

Mh...

The responderID is "3FD5B5D0D64479504A17A39B8C4ADCB8B022646B".

I don't know how to check it. Can somebody help?

I sha1sum'ed the fingerprint, issuer and subject of level1 (COMODO
High-Assurance Secure Server CA) and level2 (AddTrust External CA
Root) but I did not find such a hash/value.

For me it looks like they are using some kind of delegated OCSP
signer, but because they did not include the signer's certificate in
the response like other OCSP are currntly doing, I am unable to verify
(like openssl's binary), because I don't have the signer certificate.
But how should I get it?

But maybe I am totally wrong... I am new to this, sorry.

Thanks.


--
Regards,
Igor
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Is it me or is ocsp.comodoca.com doing something wrong?

Igor Sverkos
Hi,

forget it - I got it :)

"-VAfile level1.crt" is doing 'the trick'.

But I still don't now how to compute/get the responseID on my own.

Thanks.


--
Regards,
Igor
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Is it me or is ocsp.comodoca.com doing something wrong?

Ryan Hurst-3
In reply to this post by Igor Sverkos
CA delegated.

Ryan Hurst
Chief Technology Officer
GMO Globalsign

twitter: @rmhrisk
email: [hidden email]
phone: 206-650-7926

Sent from my phone, please forgive the brevity.

On Jun 13, 2013, at 3:42 AM, Igor Sverkos <[hidden email]> wrote:

> Hi,
>
> Ryan Hurst wrote:
>> They are doing a CA signed OCSP response, this is legitimate.
>>
>> We will do this in the not so distant future as well for many of our
>> responses also.
>
> If this is called "CA signed OCSP response", how is *your* current
> response, which you will change in future, called?
>
>
>> You basically need to look at the responderID and see if it's the same
>> entity that signed the certificate you are checking if so use that key
>> material to do the validation.
>
> Mh...
>
> The responderID is "3FD5B5D0D64479504A17A39B8C4ADCB8B022646B".
>
> I don't know how to check it. Can somebody help?
>
> I sha1sum'ed the fingerprint, issuer and subject of level1 (COMODO
> High-Assurance Secure Server CA) and level2 (AddTrust External CA
> Root) but I did not find such a hash/value.
>
> For me it looks like they are using some kind of delegated OCSP
> signer, but because they did not include the signer's certificate in
> the response like other OCSP are currntly doing, I am unable to verify
> (like openssl's binary), because I don't have the signer certificate.
> But how should I get it?
>
> But maybe I am totally wrong... I am new to this, sorry.
>
> Thanks.
>
>
> --
> Regards,
> Igor
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why CA-signed OCSP responders are a bad idea [WAS:Is it me or is ocsp.comodoca.com doing something wrong?]

Jakob Bohm-7
In reply to this post by Ryan Hurst-3
On 6/13/2013 1:50 AM, Ryan Hurst wrote:
> They are doing a CA signed OCSP response, this is legitimate.
>
> We will do this in the not so distant future as well for many of our
> responses also.
>

Please don't!

As a knowledgeable GlobalSign customer I would prefer that you keep your
root private keys as secure as possible.

Using CA signed OCSP responses implies some serious and almost
impossible to mitigate security risks:

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For a "CRL-style" CA signed OCSP responder:

- I define this as an OCSP responder that returns ONLY pregenerated
  responses, which it receives a a regular batch of responses for all
  issued certificates from the offline CA.

1. The short validity times expected by OCSP clients requires that new
  response batches are created 100 times per day or more, while the need
  to remain compatible with older (RFC2560) clients requires each
  response in the batch to cover only one certificate.  Together, these
  two factors provides attackers with an easily collected collection of
  millions of signatures on algorithmically predictable data issued by
  the root key.  This is exactly the kind of data needed for most
  otherwise infeasible/theoretical attacks on a public/private key pair.

2. The only way to make the signed data in a pregenerated OCSP response
  unpredictable is to include a random salt in a non-standard extension
  in each response.  To avoid leaking the state of the internal RNG of
  the CA's HSM, such salt must be generated by a trusted RNG unrelated
  to the one in the primary HSM.

3. Due to shortcomings of the OCSP protocol documents, response batches
  can only be pregenerated ahead of time by including false time
  information in them, (lack of clarity means that some clients might
  reject producedAt values before thisUpdate) at best one could use the
  CRL reference extension to indicate the true generation time, but only
  if a real CRL is also generated as part of the batch.  This makes it
  hard to take the root key holding HSM temporarily offline for security
  issues or any other good reason.  This issue persists in RFC6960.

4. Due to shortcomings and lack of foresight in the OCSP protocol
  documents, the generation and return of responses using the SHA-1 hash
  algorithm will probably remain necessary at least until June 2021 (the
  10 year anniversary of RFC6277), and responses using the SHA-256 hash
  algorithm until an unknown date after the year 2023 (since no RFC has
  yet been issued specifying any other must-accept algorithms).

  Furthermore, there are no must-accept algorithms using any
  contemporary version of DSA, nor using any algorithms not from the
  NSA-designed MD4-derived old SHA algorithms.  There is not even a
  requirement that clients must accept the algorithm used to sign the
  certificate being checked.  This issue persists in RFC6960.

5. There is no feasible way to pregenerate negative responses for never-
  issued certificates.  Most notably, such negative responses cannot
  cover a range of unissued serial numbers and standard practice uses
  serial numbers so long that it is virtually impossible to even store
  one bit of response data for each unused serial number, let alone
  transmit such responses.  The closest potential solution would be to
  use a streaming algorithm to generate but not store a sequence of
  SingleResponse for all serial numbers from X to Y, compute and store
  the surrounding parts of a BasicOCSPResponse holding that sequence,
  then recreate it on the fly when sending this response to a requestor,
  however the transmission bandwidth of such a monster response would
  still be prohibitive.  This issue is present in RFC6960.

6. A "CRL-style" CA signed OCSP responder cannot respond to requests
  covering more than one certificate, since doing so requires the
  generation and storage of responses for almost infinitely many sets
  of certificates.  If the client implements RFC6960, it is possible to
  simply send back a pre-signed response which is essentially the entire
  CRL in a different format, however the protocol does not provide this
  information in the Request, so this cannot be done until June 2023 (10
  year anniversary of RFC6960).

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For a truly online CA-signed OCSP responder, things are even worse:

- I define this as an OCSP responder which generates responses on the
  fly and signs them with the CA root key.

1. It requires the CA root key to be available to at least one system
  (HSM or otherwise) with access to the CA private key to be online in
  a manner which completely prevents human vetting of requests (because
  the root key must be used at very short notice 24x7).  This provides
  an avenue for seriously motivated attackers to work their way through
  all the security layers one by one until they reach the private key.

  The GlobalSign root keys are such valuable targets to both criminal
  and rogue government government groups that a STYX style operation to
  capture them must always be expected.

2. It requires the HSM storing the root key to never be offline, at
  all.  This makes it impossible to take the root key holding HSM
  temporarily offline for security issues or any other good reason.

3. Due to shortcomings and lack of foresight in the OCSP protocol
  documents, the generation and return of responses using the SHA-1 hash
  algorithm will probably remain necessary at least until June 2021 (the
  10 year anniversary of RFC6277), and responses using the SHA-256 hash
  algorithm until an unknown date after the year 2023 (since no RFC has
  yet been issued specifying any other must-accept algorithms).

  Furthermore, there are no must-accept algorithms using any
  contemporary version of DSA, nor using any algorithms not from the
  NSA-designed MD4-derived old SHA family.  There is not even a
  requirement that clients must accept the algorithm used to sign the
  certificate being checked.  This issue persists in RFC6960.

4. It allows, by design, anonymous remote users to request a huge
  number of sample signatures made with the root private key, which is
  exactly the unobtainable part of many known theoretical attacks, and
  this is likely to be the case of many yet-to-be known future attacks.

  The standard countermeasures against such attacks are likely to be
  ineffective in the case of a high profile OCSP responder:

4.1  Limiting the request rate to a safe value is not possible, an OCSP
  responder for a large CA must by definition process millions of
  requests per week, each with subsecond response time.

4.2  Watching for suspect request patterns and taking the system
  offline until the attack fades away.  Taking an OCSP responder offline
  for even a few minutes will have devastating consequences that
  preclude taking such measures on a mere suspicion (and when it is no
  longer just a suspicion, it is probably too late).

4.3  Blocking IPs that issue suspiciously many requests will be
  ineffective (because anyone going after such a high value target is
  likely to use botnets or other request IP scattering techniques), and
  counterproductive (because it will most likely detect and falsely
  block major proxies, online virus scanning services etc.).

4.4  Salting the responses with random or other attacker-uncontrolled
  data requires the ability to know which aspects of such salting will
  prevent which attacks.  And high profile CAs need to be prepared for
  unknown attacks on their private key.  Random salts also provide
  attackers with excellent insights into the RNG employed, thus any
  security weakness in the RNG design (even if it is backed by a true
  quantum phenomenon hardware RNG) can be more readily exploited by
  attackers.

4.5  Rejecting requests for the status of never issued certificates at
  a front end without (indirect) root key access may reduce the
  attackers flexibility in choosing data to be signed, but there are
  still plenty of issued certificates that can be harvested from public
  certificate uses, collated and sorted on their bit patterns relative
  to the needs of the attempted attack.

4.6  Caching responses, so each certificate only gets a freshly signed
  OCSP response once every few minutes, severely limits the ability of
  OCSP clients to verify that the response is current, and cannot cope
  with some of the protocol requirements (request nonces, multiple
  certificates in one request, negative responses for never issued
  certificates), while still providing lots of data (100.000 unique
  signatures per issued cert per year of validity if you cache each
  response for 5 minutes).  And note that the attacker will have the
  full root cert lifetime to gather up sample responses for input to his
  cryptanalysis.

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Contrast this with the security properties of a delegated OCSP
responder:

1. Delegated OCSP signing certs can be routinely revoked and replaced
  as often as needed (you will need to set up a second OCSP responder
  URL, with each URL the sole source of OCSP checking of certificates
  issued to responders at the other URL).

2. Spare and backup responders can be prepared, complete with their own
  private keys and certificates ahead of time.

3. Because their hardware lifetime is not tied to the (old) HSM holding
  a 30+ year key, delegated OCSP responders can deploy new security
  measures without having to work around hardware limitations of the
  existing HSMs used.  In fact, even if no HSM implementations of a new
  security measure are available, an ordinary server with an ultra-
  short-lifespan OCSP-responder certificate can do the job with little
  overall risk until a more robust implementation is available.

4. Because there is no requirement that all responses are signed with
  the same key, delegated OCSP responders can be set up as redundant
  systems with multiple servers and sites handling the same OCSP URL,
  allowing maintenance to be done without taking all the clients offline.

5. In case of non-compromised root key loss (imagine if the root key
  facility had been in in Dresden last week or New York during Sandy or
  the 2001 attack), a delegated OCSP responder with a pre-issued
  non-expiring certificate can continue to serve customers while a new
  root key is brought online, deployed into browser trust stores and
  finally used to issue new replacement certificates.  For good measure,
  supplement with a set of similar delegated CRL signing certs, although
  I suspect the latter would not be usable with many existing clients.

6. In case of root key compromise, a handful of almost-never-expiring
  OCSP certificates can be pregenerated and stored at secure off-site
  locations.  In case of disaster, these can be installed on OCSP
  servers that return "key compromise, certificate revoked" for all
  requests that mention the lost CA.  These (along with pre-signed
  non-expiring revoke-all CRLs) can be used even if access to the
  compromised root private key was lost in the disaster, e.g. due to
  a too late triggering of a self-destruct mechanisms.  Remember to not
  use all the pre-issued OCSP certificates at once, hold some of them
  back in case the online ones are compromised.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Why CA-signed OCSP responders are a bad idea [WAS:Is it me or is ocsp.comodoca.com doing something wrong?]

Ryan Hurst-3
Jakob,

Online CA signing keys for something like OCSP signing is a bad idea and
don't worry we wont do that; we are looking at doing is using pre-produced
OCSP for issuing CAs issued certificates; in this model all cache-misses and
root responses would be VA delegated still.

This protects the CA key material yet keeps the large majority of the
responses much smaller due to the left out keys.

For this to be a viable model, as you point out frequency of response
generation is one factor, as is the validity period of the issuing CA.

CAs are required to produce responses every 7 days, we comply with that but
as part of our new infrastructure investment we will be bringing that time
down quite a bit; the largest issue here being time skew on the broader
internet. This introduces practical limits that mean that you cant be "too
fresh" on your revocation times.

It also means producing fresher responses 100s of times a day isn't of much
value, you can of course update the changes in the cached responses set to
be accurate but fresher / shorter lived responses end up breaking things for
a reasonably large % of users.

I believe this approach addresses most  of the concerns you mentioned
bellow, a few exceptions:

You state that pre-produced OCSP responses cant span multiple certids
(practically), while this is true we receive exactly zero such requests to
do and testing shows that major clients don't even handle the case correctly
when such responses are returned (geotrust does this); they simply store the
larger response many times even if they already had a signed response that
was valid covering that certid.

Ryan

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Jakob Bohm
Sent: Friday, June 14, 2013 3:10 PM
To: [hidden email]
Subject: Re: Why CA-signed OCSP responders are a bad idea [WAS:Is it me or
is ocsp.comodoca.com doing something wrong?]

On 6/13/2013 1:50 AM, Ryan Hurst wrote:
> They are doing a CA signed OCSP response, this is legitimate.
>
> We will do this in the not so distant future as well for many of our
> responses also.
>

Please don't!

As a knowledgeable GlobalSign customer I would prefer that you keep your
root private keys as secure as possible.

Using CA signed OCSP responses implies some serious and almost impossible to
mitigate security risks:

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For a "CRL-style" CA signed OCSP responder:

- I define this as an OCSP responder that returns ONLY pregenerated
  responses, which it receives a a regular batch of responses for all
  issued certificates from the offline CA.

1. The short validity times expected by OCSP clients requires that new
  response batches are created 100 times per day or more, while the need
  to remain compatible with older (RFC2560) clients requires each
  response in the batch to cover only one certificate.  Together, these
  two factors provides attackers with an easily collected collection of
  millions of signatures on algorithmically predictable data issued by
  the root key.  This is exactly the kind of data needed for most
  otherwise infeasible/theoretical attacks on a public/private key pair.

2. The only way to make the signed data in a pregenerated OCSP response
  unpredictable is to include a random salt in a non-standard extension
  in each response.  To avoid leaking the state of the internal RNG of
  the CA's HSM, such salt must be generated by a trusted RNG unrelated
  to the one in the primary HSM.

3. Due to shortcomings of the OCSP protocol documents, response batches
  can only be pregenerated ahead of time by including false time
  information in them, (lack of clarity means that some clients might
  reject producedAt values before thisUpdate) at best one could use the
  CRL reference extension to indicate the true generation time, but only
  if a real CRL is also generated as part of the batch.  This makes it
  hard to take the root key holding HSM temporarily offline for security
  issues or any other good reason.  This issue persists in RFC6960.

4. Due to shortcomings and lack of foresight in the OCSP protocol
  documents, the generation and return of responses using the SHA-1 hash
  algorithm will probably remain necessary at least until June 2021 (the
  10 year anniversary of RFC6277), and responses using the SHA-256 hash
  algorithm until an unknown date after the year 2023 (since no RFC has
  yet been issued specifying any other must-accept algorithms).

  Furthermore, there are no must-accept algorithms using any
  contemporary version of DSA, nor using any algorithms not from the
  NSA-designed MD4-derived old SHA algorithms.  There is not even a
  requirement that clients must accept the algorithm used to sign the
  certificate being checked.  This issue persists in RFC6960.

5. There is no feasible way to pregenerate negative responses for never-
  issued certificates.  Most notably, such negative responses cannot
  cover a range of unissued serial numbers and standard practice uses
  serial numbers so long that it is virtually impossible to even store
  one bit of response data for each unused serial number, let alone
  transmit such responses.  The closest potential solution would be to
  use a streaming algorithm to generate but not store a sequence of
  SingleResponse for all serial numbers from X to Y, compute and store
  the surrounding parts of a BasicOCSPResponse holding that sequence,
  then recreate it on the fly when sending this response to a requestor,
  however the transmission bandwidth of such a monster response would
  still be prohibitive.  This issue is present in RFC6960.

6. A "CRL-style" CA signed OCSP responder cannot respond to requests
  covering more than one certificate, since doing so requires the
  generation and storage of responses for almost infinitely many sets
  of certificates.  If the client implements RFC6960, it is possible to
  simply send back a pre-signed response which is essentially the entire
  CRL in a different format, however the protocol does not provide this
  information in the Request, so this cannot be done until June 2023 (10
  year anniversary of RFC6960).

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For a truly online CA-signed OCSP responder, things are even worse:

- I define this as an OCSP responder which generates responses on the
  fly and signs them with the CA root key.

1. It requires the CA root key to be available to at least one system
  (HSM or otherwise) with access to the CA private key to be online in
  a manner which completely prevents human vetting of requests (because
  the root key must be used at very short notice 24x7).  This provides
  an avenue for seriously motivated attackers to work their way through
  all the security layers one by one until they reach the private key.

  The GlobalSign root keys are such valuable targets to both criminal
  and rogue government government groups that a STYX style operation to
  capture them must always be expected.

2. It requires the HSM storing the root key to never be offline, at
  all.  This makes it impossible to take the root key holding HSM
  temporarily offline for security issues or any other good reason.

3. Due to shortcomings and lack of foresight in the OCSP protocol
  documents, the generation and return of responses using the SHA-1 hash
  algorithm will probably remain necessary at least until June 2021 (the
  10 year anniversary of RFC6277), and responses using the SHA-256 hash
  algorithm until an unknown date after the year 2023 (since no RFC has
  yet been issued specifying any other must-accept algorithms).

  Furthermore, there are no must-accept algorithms using any
  contemporary version of DSA, nor using any algorithms not from the
  NSA-designed MD4-derived old SHA family.  There is not even a
  requirement that clients must accept the algorithm used to sign the
  certificate being checked.  This issue persists in RFC6960.

4. It allows, by design, anonymous remote users to request a huge
  number of sample signatures made with the root private key, which is
  exactly the unobtainable part of many known theoretical attacks, and
  this is likely to be the case of many yet-to-be known future attacks.

  The standard countermeasures against such attacks are likely to be
  ineffective in the case of a high profile OCSP responder:

4.1  Limiting the request rate to a safe value is not possible, an OCSP
  responder for a large CA must by definition process millions of
  requests per week, each with subsecond response time.

4.2  Watching for suspect request patterns and taking the system
  offline until the attack fades away.  Taking an OCSP responder offline
  for even a few minutes will have devastating consequences that
  preclude taking such measures on a mere suspicion (and when it is no
  longer just a suspicion, it is probably too late).

4.3  Blocking IPs that issue suspiciously many requests will be
  ineffective (because anyone going after such a high value target is
  likely to use botnets or other request IP scattering techniques), and
  counterproductive (because it will most likely detect and falsely
  block major proxies, online virus scanning services etc.).

4.4  Salting the responses with random or other attacker-uncontrolled
  data requires the ability to know which aspects of such salting will
  prevent which attacks.  And high profile CAs need to be prepared for
  unknown attacks on their private key.  Random salts also provide
  attackers with excellent insights into the RNG employed, thus any
  security weakness in the RNG design (even if it is backed by a true
  quantum phenomenon hardware RNG) can be more readily exploited by
  attackers.

4.5  Rejecting requests for the status of never issued certificates at
  a front end without (indirect) root key access may reduce the
  attackers flexibility in choosing data to be signed, but there are
  still plenty of issued certificates that can be harvested from public
  certificate uses, collated and sorted on their bit patterns relative
  to the needs of the attempted attack.

4.6  Caching responses, so each certificate only gets a freshly signed
  OCSP response once every few minutes, severely limits the ability of
  OCSP clients to verify that the response is current, and cannot cope
  with some of the protocol requirements (request nonces, multiple
  certificates in one request, negative responses for never issued
  certificates), while still providing lots of data (100.000 unique
  signatures per issued cert per year of validity if you cache each
  response for 5 minutes).  And note that the attacker will have the
  full root cert lifetime to gather up sample responses for input to his
  cryptanalysis.

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Contrast this with the security properties of a delegated OCSP
responder:

1. Delegated OCSP signing certs can be routinely revoked and replaced
  as often as needed (you will need to set up a second OCSP responder
  URL, with each URL the sole source of OCSP checking of certificates
  issued to responders at the other URL).

2. Spare and backup responders can be prepared, complete with their own
  private keys and certificates ahead of time.

3. Because their hardware lifetime is not tied to the (old) HSM holding
  a 30+ year key, delegated OCSP responders can deploy new security
  measures without having to work around hardware limitations of the
  existing HSMs used.  In fact, even if no HSM implementations of a new
  security measure are available, an ordinary server with an ultra-
  short-lifespan OCSP-responder certificate can do the job with little
  overall risk until a more robust implementation is available.

4. Because there is no requirement that all responses are signed with
  the same key, delegated OCSP responders can be set up as redundant
  systems with multiple servers and sites handling the same OCSP URL,
  allowing maintenance to be done without taking all the clients offline.

5. In case of non-compromised root key loss (imagine if the root key
  facility had been in in Dresden last week or New York during Sandy or
  the 2001 attack), a delegated OCSP responder with a pre-issued
  non-expiring certificate can continue to serve customers while a new
  root key is brought online, deployed into browser trust stores and
  finally used to issue new replacement certificates.  For good measure,
  supplement with a set of similar delegated CRL signing certs, although
  I suspect the latter would not be usable with many existing clients.

6. In case of root key compromise, a handful of almost-never-expiring
  OCSP certificates can be pregenerated and stored at secure off-site
  locations.  In case of disaster, these can be installed on OCSP
  servers that return "key compromise, certificate revoked" for all
  requests that mention the lost CA.  These (along with pre-signed
  non-expiring revoke-all CRLs) can be used even if access to the
  compromised root private key was lost in the disaster, e.g. due to
  a too late triggering of a self-destruct mechanisms.  Remember to not
  use all the pre-issued OCSP certificates at once, hold some of them
  back in case the online ones are compromised.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com Transformervej
29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10 This public discussion
message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Why CA-signed OCSP responders are a bad idea [WAS:Is it me or is ocsp.comodoca.com doing something wrong?]

Jakob Bohm-7
On 6/15/2013 1:15 AM, Ryan Hurst wrote:

Thanks for your reply, just one tidbit that surprised me:

>
> CAs are required to produce responses every 7 days, we comply with that but
> as part of our new infrastructure investment we will be bringing that time
> down quite a bit; the largest issue here being time skew on the broader
> internet. This introduces practical limits that mean that you cant be "too
> fresh" on your revocation times.
>
> It also means producing fresher responses 100s of times a day isn't of much
> value, you can of course update the changes in the cached responses set to
> be accurate but fresher / shorter lived responses end up breaking things for
> a reasonably large % of users.
>

Ahh, I never heard about this 7 day rule, the closest I had previously
heard was a CSP for a (now essentially defunct) national CA, which
required CRL update delays of 1 minute or less from compromise reports,
and those were not even qualified certs!

 From this I kind of surmised that OCSP validity times > 5 minutes would
be as unsupported as DNS TTLs > 1 month.

> I believe this approach addresses most  of the concerns you mentioned
> bellow, a few exceptions:
>
 > ...

You missed another concern: The need to use old dubious signature
algorithms for the next 10 years, due to the late publication of
RFC6277, the failure to require in the spec that clients must
accept the alg used to sign the cert and the failure of even the
latest RFC6960 to specify anything other than SHA-1 and SHA-256, and
the failure to provide any request indication that a client
implements anything post-RFC2560 (you could be lucky to receive
a redundant algorithm list specifying the defaults from some post
RFC6277 clients).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Why CA-signed OCSP responders are a bad idea [WAS:Is it me or is ocsp.comodoca.com doing something wrong?]

Ryan Hurst-3
I agree 2560's lack of algorithm agility is a problem and RFC6960's lack of
specifying an indicator of which algorithm to use is also a little
problematic; that said it is one that can be worked around in most cases.

One likely way is that responders will rely on the User Agent header to
determine platform support for a given behavior and if algorithm support
isn't explicitly known fallback to SHA1; this can help accelerate the
adoption of SHA2 in OCSP but the larger platform adoption problem still
exists.

It takes roughly 10 years from release of Windows to 98% ubiquity; that mean
we better hope Windows adds support for RFC6960 soon so that clock can start
ticking.

Has support been added to OpenSSL yet?

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Jakob Bohm
Sent: Friday, June 14, 2013 5:00 PM
To: [hidden email]
Subject: Re: Why CA-signed OCSP responders are a bad idea [WAS:Is it me or
is ocsp.comodoca.com doing something wrong?]

On 6/15/2013 1:15 AM, Ryan Hurst wrote:

Thanks for your reply, just one tidbit that surprised me:

>
> CAs are required to produce responses every 7 days, we comply with
> that but as part of our new infrastructure investment we will be
> bringing that time down quite a bit; the largest issue here being time
> skew on the broader internet. This introduces practical limits that
> mean that you cant be "too fresh" on your revocation times.
>
> It also means producing fresher responses 100s of times a day isn't of
> much value, you can of course update the changes in the cached
> responses set to be accurate but fresher / shorter lived responses end
> up breaking things for a reasonably large % of users.
>

Ahh, I never heard about this 7 day rule, the closest I had previously heard
was a CSP for a (now essentially defunct) national CA, which required CRL
update delays of 1 minute or less from compromise reports, and those were
not even qualified certs!

 From this I kind of surmised that OCSP validity times > 5 minutes would be
as unsupported as DNS TTLs > 1 month.

> I believe this approach addresses most  of the concerns you mentioned
> bellow, a few exceptions:
>
 > ...

You missed another concern: The need to use old dubious signature algorithms
for the next 10 years, due to the late publication of RFC6277, the failure
to require in the spec that clients must accept the alg used to sign the
cert and the failure of even the latest RFC6960 to specify anything other
than SHA-1 and SHA-256, and the failure to provide any request indication
that a client implements anything post-RFC2560 (you could be lucky to
receive a redundant algorithm list specifying the defaults from some post
RFC6277 clients).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com Transformervej
29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10 This public discussion
message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Why CA-signed OCSP responders are a bad idea [WAS:Is it me or is ocsp.comodoca.com doing something wrong?]

Ryan Hurst-3
In reply to this post by Jakob Bohm-7
Btw let me know if I can ever be of help.

Ryan Hurst
Chief Technology Officer
GMO Globalsign

twitter: @rmhrisk
email: [hidden email]
phone: 206-650-7926

Sent from my phone, please forgive the brevity.

On Jun 14, 2013, at 3:09 PM, Jakob Bohm <[hidden email]> wrote:

> On 6/13/2013 1:50 AM, Ryan Hurst wrote:
>> They are doing a CA signed OCSP response, this is legitimate.
>>
>> We will do this in the not so distant future as well for many of our
>> responses also.
>
> Please don't!
>
> As a knowledgeable GlobalSign customer I would prefer that you keep your root private keys as secure as possible.
>
> Using CA signed OCSP responses implies some serious and almost
> impossible to mitigate security risks:
>
> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> For a "CRL-style" CA signed OCSP responder:
>
> - I define this as an OCSP responder that returns ONLY pregenerated
> responses, which it receives a a regular batch of responses for all
> issued certificates from the offline CA.
>
> 1. The short validity times expected by OCSP clients requires that new
> response batches are created 100 times per day or more, while the need
> to remain compatible with older (RFC2560) clients requires each
> response in the batch to cover only one certificate.  Together, these
> two factors provides attackers with an easily collected collection of
> millions of signatures on algorithmically predictable data issued by
> the root key.  This is exactly the kind of data needed for most
> otherwise infeasible/theoretical attacks on a public/private key pair.
>
> 2. The only way to make the signed data in a pregenerated OCSP response
> unpredictable is to include a random salt in a non-standard extension
> in each response.  To avoid leaking the state of the internal RNG of
> the CA's HSM, such salt must be generated by a trusted RNG unrelated
> to the one in the primary HSM.
>
> 3. Due to shortcomings of the OCSP protocol documents, response batches
> can only be pregenerated ahead of time by including false time
> information in them, (lack of clarity means that some clients might
> reject producedAt values before thisUpdate) at best one could use the
> CRL reference extension to indicate the true generation time, but only
> if a real CRL is also generated as part of the batch.  This makes it
> hard to take the root key holding HSM temporarily offline for security
> issues or any other good reason.  This issue persists in RFC6960.
>
> 4. Due to shortcomings and lack of foresight in the OCSP protocol
> documents, the generation and return of responses using the SHA-1 hash
> algorithm will probably remain necessary at least until June 2021 (the
> 10 year anniversary of RFC6277), and responses using the SHA-256 hash
> algorithm until an unknown date after the year 2023 (since no RFC has
> yet been issued specifying any other must-accept algorithms).
>
> Furthermore, there are no must-accept algorithms using any
> contemporary version of DSA, nor using any algorithms not from the
> NSA-designed MD4-derived old SHA algorithms.  There is not even a
> requirement that clients must accept the algorithm used to sign the
> certificate being checked.  This issue persists in RFC6960.
>
> 5. There is no feasible way to pregenerate negative responses for never-
> issued certificates.  Most notably, such negative responses cannot
> cover a range of unissued serial numbers and standard practice uses
> serial numbers so long that it is virtually impossible to even store
> one bit of response data for each unused serial number, let alone
> transmit such responses.  The closest potential solution would be to
> use a streaming algorithm to generate but not store a sequence of
> SingleResponse for all serial numbers from X to Y, compute and store
> the surrounding parts of a BasicOCSPResponse holding that sequence,
> then recreate it on the fly when sending this response to a requestor,
> however the transmission bandwidth of such a monster response would
> still be prohibitive.  This issue is present in RFC6960.
>
> 6. A "CRL-style" CA signed OCSP responder cannot respond to requests
> covering more than one certificate, since doing so requires the
> generation and storage of responses for almost infinitely many sets
> of certificates.  If the client implements RFC6960, it is possible to
> simply send back a pre-signed response which is essentially the entire
> CRL in a different format, however the protocol does not provide this
> information in the Request, so this cannot be done until June 2023 (10
> year anniversary of RFC6960).
>
> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> For a truly online CA-signed OCSP responder, things are even worse:
>
> - I define this as an OCSP responder which generates responses on the
> fly and signs them with the CA root key.
>
> 1. It requires the CA root key to be available to at least one system
> (HSM or otherwise) with access to the CA private key to be online in
> a manner which completely prevents human vetting of requests (because
> the root key must be used at very short notice 24x7).  This provides
> an avenue for seriously motivated attackers to work their way through
> all the security layers one by one until they reach the private key.
>
> The GlobalSign root keys are such valuable targets to both criminal
> and rogue government government groups that a STYX style operation to
> capture them must always be expected.
>
> 2. It requires the HSM storing the root key to never be offline, at
> all.  This makes it impossible to take the root key holding HSM
> temporarily offline for security issues or any other good reason.
>
> 3. Due to shortcomings and lack of foresight in the OCSP protocol
> documents, the generation and return of responses using the SHA-1 hash
> algorithm will probably remain necessary at least until June 2021 (the
> 10 year anniversary of RFC6277), and responses using the SHA-256 hash
> algorithm until an unknown date after the year 2023 (since no RFC has
> yet been issued specifying any other must-accept algorithms).
>
> Furthermore, there are no must-accept algorithms using any
> contemporary version of DSA, nor using any algorithms not from the
> NSA-designed MD4-derived old SHA family.  There is not even a
> requirement that clients must accept the algorithm used to sign the
> certificate being checked.  This issue persists in RFC6960.
>
> 4. It allows, by design, anonymous remote users to request a huge
> number of sample signatures made with the root private key, which is
> exactly the unobtainable part of many known theoretical attacks, and
> this is likely to be the case of many yet-to-be known future attacks.
>
> The standard countermeasures against such attacks are likely to be
> ineffective in the case of a high profile OCSP responder:
>
> 4.1  Limiting the request rate to a safe value is not possible, an OCSP
> responder for a large CA must by definition process millions of
> requests per week, each with subsecond response time.
>
> 4.2  Watching for suspect request patterns and taking the system
> offline until the attack fades away.  Taking an OCSP responder offline
> for even a few minutes will have devastating consequences that
> preclude taking such measures on a mere suspicion (and when it is no
> longer just a suspicion, it is probably too late).
>
> 4.3  Blocking IPs that issue suspiciously many requests will be
> ineffective (because anyone going after such a high value target is
> likely to use botnets or other request IP scattering techniques), and
> counterproductive (because it will most likely detect and falsely
> block major proxies, online virus scanning services etc.).
>
> 4.4  Salting the responses with random or other attacker-uncontrolled
> data requires the ability to know which aspects of such salting will
> prevent which attacks.  And high profile CAs need to be prepared for
> unknown attacks on their private key.  Random salts also provide
> attackers with excellent insights into the RNG employed, thus any
> security weakness in the RNG design (even if it is backed by a true
> quantum phenomenon hardware RNG) can be more readily exploited by
> attackers.
>
> 4.5  Rejecting requests for the status of never issued certificates at
> a front end without (indirect) root key access may reduce the
> attackers flexibility in choosing data to be signed, but there are
> still plenty of issued certificates that can be harvested from public
> certificate uses, collated and sorted on their bit patterns relative
> to the needs of the attempted attack.
>
> 4.6  Caching responses, so each certificate only gets a freshly signed
> OCSP response once every few minutes, severely limits the ability of
> OCSP clients to verify that the response is current, and cannot cope
> with some of the protocol requirements (request nonces, multiple
> certificates in one request, negative responses for never issued
> certificates), while still providing lots of data (100.000 unique
> signatures per issued cert per year of validity if you cache each
> response for 5 minutes).  And note that the attacker will have the
> full root cert lifetime to gather up sample responses for input to his
> cryptanalysis.
>
> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Contrast this with the security properties of a delegated OCSP
> responder:
>
> 1. Delegated OCSP signing certs can be routinely revoked and replaced
> as often as needed (you will need to set up a second OCSP responder
> URL, with each URL the sole source of OCSP checking of certificates
> issued to responders at the other URL).
>
> 2. Spare and backup responders can be prepared, complete with their own
> private keys and certificates ahead of time.
>
> 3. Because their hardware lifetime is not tied to the (old) HSM holding
> a 30+ year key, delegated OCSP responders can deploy new security
> measures without having to work around hardware limitations of the
> existing HSMs used.  In fact, even if no HSM implementations of a new
> security measure are available, an ordinary server with an ultra-
> short-lifespan OCSP-responder certificate can do the job with little
> overall risk until a more robust implementation is available.
>
> 4. Because there is no requirement that all responses are signed with
> the same key, delegated OCSP responders can be set up as redundant
> systems with multiple servers and sites handling the same OCSP URL,
> allowing maintenance to be done without taking all the clients offline.
>
> 5. In case of non-compromised root key loss (imagine if the root key
> facility had been in in Dresden last week or New York during Sandy or
> the 2001 attack), a delegated OCSP responder with a pre-issued
> non-expiring certificate can continue to serve customers while a new
> root key is brought online, deployed into browser trust stores and
> finally used to issue new replacement certificates.  For good measure,
> supplement with a set of similar delegated CRL signing certs, although
> I suspect the latter would not be usable with many existing clients.
>
> 6. In case of root key compromise, a handful of almost-never-expiring
> OCSP certificates can be pregenerated and stored at secure off-site
> locations.  In case of disaster, these can be installed on OCSP
> servers that return "key compromise, certificate revoked" for all
> requests that mention the lost CA.  These (along with pre-signed
> non-expiring revoke-all CRLs) can be used even if access to the
> compromised root private key was lost in the disaster, e.g. due to
> a too late triggering of a self-destruct mechanisms.  Remember to not
> use all the pre-issued OCSP certificates at once, hold some of them
> back in case the online ones are compromised.
>
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
> Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why CA-signed OCSP responders are a bad idea [WAS:Is it me or is ocsp.comodoca.com doing something wrong?]

Ryan Hurst-3
In reply to this post by Jakob Bohm-7
I forgot to respond the the 1 minute reference, we revoke right away and most CAs do that is just different than pre producing all revoked responses when one cert is revoked.

Ryan Hurst
Chief Technology Officer
GMO Globalsign

twitter: @rmhrisk

Sent from my phone, please forgive the brevity.

On Jun 14, 2013, at 4:59 PM, Jakob Bohm <[hidden email]> wrote:

> On 6/15/2013 1:15 AM, Ryan Hurst wrote:
>
> Thanks for your reply, just one tidbit that surprised me:
>>
>> CAs are required to produce responses every 7 days, we comply with that but
>> as part of our new infrastructure investment we will be bringing that time
>> down quite a bit; the largest issue here being time skew on the broader
>> internet. This introduces practical limits that mean that you cant be "too
>> fresh" on your revocation times.
>>
>> It also means producing fresher responses 100s of times a day isn't of much
>> value, you can of course update the changes in the cached responses set to
>> be accurate but fresher / shorter lived responses end up breaking things for
>> a reasonably large % of users.
>
> Ahh, I never heard about this 7 day rule, the closest I had previously heard was a CSP for a (now essentially defunct) national CA, which required CRL update delays of 1 minute or less from compromise reports,
> and those were not even qualified certs!
>
> From this I kind of surmised that OCSP validity times > 5 minutes would
> be as unsupported as DNS TTLs > 1 month.
>
>> I believe this approach addresses most  of the concerns you mentioned
>> bellow, a few exceptions:
> > ...
>
> You missed another concern: The need to use old dubious signature algorithms for the next 10 years, due to the late publication of RFC6277, the failure to require in the spec that clients must
> accept the alg used to sign the cert and the failure of even the
> latest RFC6960 to specify anything other than SHA-1 and SHA-256, and
> the failure to provide any request indication that a client
> implements anything post-RFC2560 (you could be lucky to receive
> a redundant algorithm list specifying the defaults from some post RFC6277 clients).
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
> Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]

smime.p7s (2K) Download Attachment