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
certificates.
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.
Enjoy
Jakob
--
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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
