On Fri, 16 Dec 2016 02:51:47 +0100 Jakob Bohm <[email protected]> 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: [email protected] GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
