SHA-1 with 'notAfter >= 2017-1-1'

[s...@gmx.ch]

Hi

We're already having some discussions about SHA-1, but I'll split this
up into a new thread.

The initial goal of bug 942515 was to mark certs as insecure, that are
valid 'notBefore >= 2016-01-01' (means issued to use in 2016+) AND also
for certs that are valid 'notAfter >= 2017-1-1' (means still valid in
2017+).

The first condition has been implemented, but there are some
'compatibility' issues with MITM software. [1]
The second condition has not been implemented, but it was already
announced [2] and also considered to set the cut-off a half year earlier
to the July 1, 2016. If this should really happen, we need to hurry up
on this discussion. Of course the problem mentioned in [1] should be
solved first.

Regards,
Jonas


[1]
https://blog.mozilla.org/security/2016/01/06/man-in-the-middle-interfering-with-increased-security/
[2]
https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
[3]
https://blog.mozilla.org/security/2015/10/20/continuing-to-phase-out-sha-1-certificates/

[Ryan Sleevi]

On Tue, January 19, 2016 2:56 pm, s...@gmx.ch wrote:
> Hi
>
> We're already having some discussions about SHA-1, but I'll split this
> up into a new thread.
>
> The initial goal of bug 942515 was to mark certs as insecure, that are
> valid 'notBefore >= 2016-01-01' (means issued to use in 2016+) AND also
> for certs that are valid 'notAfter >= 2017-1-1' (means still valid in
> 2017+).
>
> The first condition has been implemented, but there are some
> 'compatibility' issues with MITM software. [1]
> The second condition has not been implemented, but it was already
> announced [2] and also considered to set the cut-off a half year earlier
> to the July 1, 2016. If this should really happen, we need to hurry up
> on this discussion. Of course the problem mentioned in [1] should be
> solved first.
>
> Regards,
> Jonas

Moving dev-tech-crypto to BCC

You've misread [2]. It is *not* about the notAfter but the notBefore. I
can assure you, based on our telemetry, there will still be some nasty
breakages with measuring on the notAfter. The goal of the announcement
(and as agreed by Mozilla, Microsoft, Google, and, of course, the
CA/Browser Forum) is that effective 2017-1-1, it's reasonable to turn off
support for SHA-1.

The only use of the notAfter, in the context of [2], was using that as a
signal to show some form of prominent warning in the developer console.
And that's been implemented for some time, AFAIK.

So the implementation of [2] is still something that, based on Firefox's
release calendar, puts it around Firefox 52 [3], thus needing to be
implemented sometime around late October / early November, 2016.


[2]
https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
[3] https://wiki.mozilla.org/RapidRelease/Calendar

[Richard Barnes]

In particular, there's no action to take with regard to Firefox until we
start to get close to the end of 2016. And given the experience this past
Jan 1, I'm not really inclined to make changes that take effect on that day
:)

> The only use of the notAfter, in the context of [2], was using that as a
> signal to show some form of prominent warning in the developer console.
> And that's been implemented for some time, AFAIK.
>

There have been SHA-1 cert warnings there for ages. I suppose we could
make them shoutier.

--Richard

> So the implementation of [2] is still something that, based on Firefox's
> release calendar, puts it around Firefox 52 [3], thus needing to be
> implemented sometime around late October / early November, 2016.
>
>
> [2]
>
> https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
> [3] https://wiki.mozilla.org/RapidRelease/Calendar
>
>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>