On 09/03/2016 20:03, Yuhong Bao wrote:
I know of one blocker: Microsoft. Their TechNet article at aka.ms/sha1 says 
that CAs are allowed to use SHA-1 and SHA-2 for OCSP signing certs and OCSP 
responses, to allow continued support for XP SP1 and 2, and Server 2003. Using 
SHA-2 only for OCSP signing certs and OCSP responses will break those platforms.
I don't think XP supports OCSP at all.                                  

It does.

And XP is not the only old system that needs to be serviced. Many embedded or semi-embedded systems had a permanent code freeze (read:
ROM manufactured, source code now lost) in the past.  In fact we have
have had to stop using SSL/TLS to communicate with some such systems
because of the modern ban on algorithms those systems understand.

The more fundamental point is this:

An OCSP response for existing certificate X is pretty must guaranteed
to have been requested by something that understands the algorithms
(such as SHA-1 and RSA) in certificate X.  It is much less likely that
a legitimate requester understands any other algorithm.

Therefore OCSP responders should sign requests related to existing
certificates with the same algorithms that were used for those
certificates, even if those algorithms are no longer used for new

If the query is for a non-existing (never issued) certificate, the
response needs to use the algorithms that were used to issue or
self-sign the alleged issuing certificate (which must be known to the
OCSP responder if it is to have an opinion at all).

Furthermore, the use of securely timestamped signatures means that OCSP
responders need to keep responding about certificates for a significant
period (years) after those certificates expire.  This is to service
clients that validate existing signatures on existing data (such as
documents or code).

So in practice, only the following can be done to secure OCSP
responders for CAs that used now obsolete algorithms to issue
certificates in the past:

1. Use a non-CA OCSP certificate if the relevant clients are known to
  support this aspect of the OCSP protocol (I don't know if any OCSP
  clients, historic or otherwise, lack this ability).  Such an OCSP
  certificate needs to be issued using the historic (and obsolete!)
  algorithms that were used for the certificates the OCSP is responding
  about, even though this technically violates fanatical readings of
  modern algorithm bans.

2. Find a way to add OCSP responder chosen random data in each OCSP
  response.  And preferably lots of bits, e.g. 256 or more bits with
  current technology.  This does not preclude the use of precomputed
  pre-signed responses for each known single certificate query, as
  the random value only needs to change when the rest of the response
  changes, so a pre-computed response would contain a pre-computed
  random value.


Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, 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
dev-security-policy mailing list

Reply via email to