SHA256 for OCSP response issuer hashing

[Roland Shoemaker]

Let's Encrypt is currently considering moving away from using SHA1 as
the issuer subject/public key hashing function in OCSP responses and
using SHA256 instead. Given a little investigation this seems like a
safe move to make but we wanted to check with the community to see if
anyone was aware of legacy (or contemporary) software issues that may
cause us any trouble.

Thanks,
Roland

[Jakob Bohm]

I believe it would cause a problem with legacy systems that don't
understand SHA-256 signatures at all, noting that such systems will
only ever trust SHA-1 (and older) certificates, thus SHA-1 signing can
be limited to cases where the CA chain leading to the certificate
issuer has no SHA-256 signatures and the certificate being checked is
not a known SHA-256 certificate (generating the dynamic rejection
response for a never issued certificate would choose the hash based on
the hash algorithm in the involved intermediary CA certs).

I wonder if Let's Encrypt ever issued SHA-1 certificates, and if any of
those are non-expired. Worst case, I guess there might be only a few
such certificates, all of them Intermediary CA certs (given that LE
only issues TLS, CA and OCSP-signing certificates, and the former have
3 month lifetime).


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

[Hanno Böck]

On Fri, 16 Dec 2016 02:51:47 +0100
Jakob Bohm <jb-mo...@wisemo.com> wrote:

> I believe it would cause a problem with legacy systems that don't
> understand SHA-256 signatures at all, noting that such systems will
> only ever trust SHA-1 (and older) certificates, thus SHA-1 signing can
> be limited to cases where the CA chain leading to the certificate
> issuer has no SHA-256 signatures and the certificate being checked is
> not a known SHA-256 certificate (generating the dynamic rejection
> response for a never issued certificate would choose the hash based on
> the hash algorithm in the involved intermediary CA certs).

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.

I stated on multiple occasions that almost every imaginable TLS
implementation flaw can be found in the wild. I was never disappointed
with this prediction.

That said: I'd recommend just do it. We'll see what happens and if we
learn something about broken systems that's a good thing.

> I wonder if Let's Encrypt ever issued SHA-1 certificates, and if any
> of those are non-expired.

Almost certainly not. Given 3 month lifetime of certs this would have
been either a violation of the baseline requirements or an agreed upon
exception. Neither of which I'm aware of, and I'm pretty sure if one of
that happened it would've made some noise.


--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

[Jürgen Brauckmann]

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.

Jürgen

[Jakob Bohm]

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.

[Jakob Bohm]

On 16/12/2016 12:22, Hanno Böck wrote:
> On Fri, 16 Dec 2016 02:51:47 +0100
> Jakob Bohm <jb-mo...@wisemo.com> wrote:
>
>

> [Snip: Discussion of potential odd client bug]
> ...

>
>> I wonder if Let's Encrypt ever issued SHA-1 certificates, and if any
>> of those are non-expired.
>
> Almost certainly not. Given 3 month lifetime of certs this would have
> been either a violation of the baseline requirements or an agreed upon
> exception. Neither of which I'm aware of, and I'm pretty sure if one of
> that happened it would've made some noise.
>

I wrote that in the part you snipped. The possibility that remains
would be SHA-1 Intermediary CA certs issued before Jan 1, 2016 and not
yet expired. Some of those may have a longer lifetime so they can
(indirectly) sign OCSP responses and CRLs with SHA-1 without violating
the BRs.

[Brian Smith]

Roland Shoemaker <rol...@letsencrypt.org> wrote:
> Let's Encrypt is currently considering moving away from using SHA1 as
> the issuer subject/public key hashing function in OCSP responses and
> using SHA256 instead. Given a little investigation this seems like a
> safe move to make but we wanted to check with the community to see if
> anyone was aware of legacy (or contemporary) software issues that may
> cause us any trouble.

I'm not sure I understand you correctly, but see:
https://bugzilla.mozilla.org/show_bug.cgi?id=966856
https://hg.mozilla.org/mozilla-central/annotate/578899c0b819/security/pkix/lib/pkixocsp.cpp#l717

Cheers,
Brian
--
https://briansmith.org/