[cabfpub] Mozilla SHA-1 further restrictions

[Gervase Markham]

On 21/11/16 19:45, Wayne Thayer wrote:
> By your own definition, I believe so because they are "hierarchies
> chaining up to our embedded roots". While no EE certs issued from
> these roots will be "trusted" come January (they're all SHA-1), I'm
> not aware of any immediate plans for Mozilla to remove SHA-1 roots.

We have no plans to remove "SHA-1 roots" - although the definition of
what is a SHA-1 root might be a little fuzzy, because NSS doesn't check
the signature on the roots themselves, and some CAs may well be using a
root which happens itself to have a SHA-1 signature to construct chains
which are otherwise entirely SHA-256, and that's fine.

Of course issuing new SHA-1 certs (which fall under the BRs) from any
root trusted by Mozilla is banned.

I am not attempting to prevent SHA-1-signed OCSP responses and CRLs - if
I were, writing this would be much easier! I am trying to circumscribe
SHA-1 use as much as possible, and make sure that remaining uses don't
sign arbitrary attacker-controlled data, and that if someone did
engineer a collision, the usefulness of that would be as small as possible.

We don't have email BRs (yet), and so there is no formal phase-out plan
for SHA-1 usage in the email space. Perhaps this is actually part of the
problem I'm grappling with. I'd like to hear from CAs about the
prevalence and use cases for SHA-1 in the email space, and how possible
they think it is and on what timeframe to move away from issuing new
SHA-1 certs which contain id-kp-emailProtection.

Gerv