On 16/12/2016 13:34, Jürgen Brauckmann wrote:
Hanno Böck schrieb:
I believe the potential problem is a different one: Systems that accept
SHA256 on certificate signatures, but not on OCSP responses. I don't
know if such systems exist, but if I had to make a bet I'd say they do.
Roland does not talk about signature algorithms. He is considering
something different:
OCSP requests contain a CertId to identify the requested certificate.
CertId contains hashes of the issuer public key and subject-dn.
Roland wants to accept OCSP requests with sha1 issuer hashes (which is
standard practice today), and issue OCSP responses for those requests
with a CertId with sha256 hashes (which is unusual). Especially unusual
is to respond with a different CertId than was used in the request.
rfc6960 does not state that the response CertId must be constructed with
the same algorithm as the request CertId. So, from a standards point of
view all should be fine.
Given that the code path for verification in e.g. openssl is slightly
different for same-algorithm issuer hashes than for different-algorithm
issuer hashes (see ocsp_check_ids() in ocsp_vfy.c), I would be surprised
if this plan will work without some major bumps. But I don't have any
hard data to contribute, and Roland has said that they already did some
investigations, so he'll know more about the feasibilty of their plans
than most of us here.
I would say that would violate the Postel principle by skating a bit
too close to the edge of what the spec allows. I don't think it should
be much of a cost to pregenerate responses for both forms of CertID
(SHA-256 and SHA-1) and send the response matching the query what is
asked.
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
