To be clear, we have not decided on any hard cutoff date for SHA-1, much less made it July 1.
January 1, 2017 and July 1, 2016 are both options under consideration. I expect that we will try to come to a final decision some time in early 2016, once we have more data about how quickly people seem to be retiring SHA-1. Right now, it's still used in around 10% of Firefox certificate verifications in release, but the trend line is downward. The beta population went from ~10.7% usage to ~8.2% usage over the course of October. On Tue, Nov 10, 2015 at 2:28 PM, Bruce <[email protected]> wrote: > On Friday, November 6, 2015 at 7:15:31 PM UTC-5, Rick Andrews wrote: > > > - We are re-evaluating when we should start rejecting all SHA-1 SSL > > > certificates (regardless of when they were issued). As we said before, > > > the current plan is to make this change on January 1, 2017. However, > in > > > light of recent attacks on SHA-1, we are also considering the > > > feasibility of having a cut-off date as early as July 1, 2016. > > > > I think that pulling in this date will create chaos for some large > enterprises who are already scrambling to phase out SHA-1 by the end of > 2016. They had been counting on using all of 2016 to complete their > migration. It wouldn't just be an inconvenience - it would make an > already-difficult situation nearly impossible. > > > > And I'll point out that Microsoft is considering the same thing but with > a different date - June 1, 2016. Would you at least consider collaborating > with other browser vendors to agree on the same date? > > I agree with Rick that I don't think the date should change. Currently the > CAs will stop issuing SHA-1 as of 1 January 2016. This will largely > mitigate the collision attack similar to the previous MD5 attack. The input > from SHAppening, makes it arguable that mitigating collision on 1 January > 2016 was probably too late, but there is not much we can do about that > decision. > > From what I understand we are not yet concerned about preimage or > second-preimage attacks on SHA-1, so this would not be a reason to change > the date. > > It would be great to understand what vulnerability we are trying to > mitigate before changing the date when SHA-1 will be rejected. > > Thanks, Bruce. > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
