Re: Final Decision by Google on Symantec

[J.C. Jones via dev-security-policy]

I share the desire to move faster than these dates, but upon
consideration, I don't think it's much of a boon to web security for
Mozilla to be substantially ahead of Chrome in implementing these trust
changes.

Since Chrome's decision to implement in April is final, their large user
population is exposed to any problem certificates until then; presumably
they believe the risk is low enough to proceed that way. No matter what
choice we make, the Web PKI as a whole has this nebulous danger until
Chrome's implementation date arrives.

If Firefox chooses to move faster, we'd need to educate users on why
some websites are functioning in Chrome but not in Firefox, for over 5
months. While we all know users need more education on security on the
Web, I don't want to spend their attention spans on this particular issue.

I think we should match Google's 17 April date.

(For the record: I am not swayed by this talk in July about avoiding Q4
configuration freezes; I absolutely agree with 1 December 2017 being a
practical cut-off date as long as the decision point is in the next
several days.)

J.C.


On 7/27/17 11:14 PM, Gervase Markham via dev-security-policy wrote:
> Google have made a final decision on the various dates they plan to
> implement as part of the consensus plan in the Symantec matter. The
> message from blink-dev is included below.
>
> Most of the dates have consensus - the dates for Symantec to implement
> the Managed CA infrastructure are agreed by all, and the date for final
> distrust of the old Symantec PKI is agreed by Google and Mozilla (to
> within a week, at any rate). I proposed November 1st 2018. Google has
> gone for October 23rd 2018; in practical terms, we would implement that
> using Firefox 63 (October 16th) or 64 (November 27th).
>
> However, there is some difference in the proposals for the date on which
> browsers should dis-trust Symantec certificates issued before June 1st,
> 2016. This date is significant because after that, Symantec have been
> required to log all their certs to CT and so there is much better
> transparency of issuance practice. I proposed December 1st 2017. Google
> strongly considered late January, but have finally chosen April 17th 2018.
>
> We now have two choices. We can accept the Google date for ourselves, or
> we can decide to implement something earlier. Implementing something
> earlier would involve us leading on compatibility risk, and so would
> need to get wider sign-off from within Mozilla, but nevertheless I would
> like to get the opinions of the m.d.s.p community.
>
> I would like to make a decision on this matter on or before July 31st,
> as Symantec have asked for dates to be nailed down by then in order for
> them to be on track with their Managed CA implementation timetable. If
> no alternative decision is taken and communicated here and to Symantec,
> the default will be that we will accept Google's final proposal as a
> consensus date.
>
> Gerv
>
>  Forwarded Message 
> Subject:  Re: [blink-dev] Intent to Deprecate and Remove: Trust in
> existing Symantec-issued Certificates
> Date: Thu, 27 Jul 2017 17:16:06 -0700
> From: Darin Fisher 
> To:   Darin Fisher 
> CC:   blink-dev 
>
>
>
> Representing Google Chrome and the Chromium open source project, what
> follows is our final proposal on this matter.
>
>
> We’d like to first thank the blink-dev community for your input on this
> discussion. After taking this input into consideration along with the
> latest responses from Symantec and Mozilla, we have produced the
> following proposal that is intended to be our final plan of action on
> this matter.
>
>
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016:
>
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016, which is tentatively scheduled to hit Canary on January
> 19, 2018; Beta on March 15, 2018; and Stable (the vast majority of
> Chrome users) on April 17, 2018. Affected site operators are strongly
> encouraged to replace their TLS certificates before March 15, 2018 to
> prevent breakage. Although this is significantly later than our initial
> proposal of August 2017 and Mozilla’s proposal for late 2017
> ,
> we think it hits an appropriate balance between the security risk to
> Chrome users and minimizing disruption to the ecosystem. This time will
> allow clear messaging and scheduling for site operators to update
> certificates.
>
>
> We considered a number of alternative dates for distrusting this subset
> of existing certificates before landing on Chrome 66. Given the scale of
> Symantec’s existing PKI and the impact to the ecosystem that these
> mitigations pose, one of our goals was to consider dates that gave site
> operators enough lead time, as well as to try to clear 

Re: Final Decision by Google on Symantec

[Jonathan Rudenberg via dev-security-policy]

> On Jul 28, 2017, at 09:34, Alex Gaynor via dev-security-policy 
>  wrote:
> 
> Frankly I was surprised to see Chromium reverse course on this -- they have
> a history of aggressive leadership in their handling of CA failures, it's a
> little disappointing to see them abandon that.
> 
> I'd strongly advocate for us perusing an earlier date -- December 1st at
> the latest.

I strongly agree. Even if an organization has a conservative freeze in October 
for Black Friday/Cyber Monday at the end of November, replacing certificates 
issued before 2016-06-01 within the next two months should be feasible. If 
re-issuing these old certificates is problematic in any way, I would have 
expected Symantec to warn their customers and provide a solution immediately in 
March after Chrome released the first version of their plan for distrust based 
on validity period or in April/May when Chrome’s subsequent revisions of the 
plan included the 2017-08-08 distrust date.

Actions are much more compelling than delay tactics and counter-proposals, so 
the complete lack of proactive measures from Symantec indicates to me that they 
do not consider the implementation of the various detailed proposals of 
distrust over the next few months to be a problem for their customers.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Final Decision by Google on Symantec

[okaphone.elektronika--- via dev-security-policy]

On Friday, 28 July 2017 08:15:43 UTC+2, Gervase Markham  wrote:
> Google have made a final decision on the various dates they plan to
> implement as part of the consensus plan in the Symantec matter. The
> message from blink-dev is included below.
> 
> Most of the dates have consensus - the dates for Symantec to implement
> the Managed CA infrastructure are agreed by all, and the date for final
> distrust of the old Symantec PKI is agreed by Google and Mozilla (to
> within a week, at any rate). I proposed November 1st 2018. Google has
> gone for October 23rd 2018; in practical terms, we would implement that
> using Firefox 63 (October 16th) or 64 (November 27th).
> 
> However, there is some difference in the proposals for the date on which
> browsers should dis-trust Symantec certificates issued before June 1st,
> 2016. This date is significant because after that, Symantec have been
> required to log all their certs to CT and so there is much better
> transparency of issuance practice. I proposed December 1st 2017. Google
> strongly considered late January, but have finally chosen April 17th 2018.
> 
> We now have two choices. We can accept the Google date for ourselves, or
> we can decide to implement something earlier. Implementing something
> earlier would involve us leading on compatibility risk, and so would
> need to get wider sign-off from within Mozilla, but nevertheless I would
> like to get the opinions of the m.d.s.p community.
> 
> I would like to make a decision on this matter on or before July 31st,
> as Symantec have asked for dates to be nailed down by then in order for
> them to be on track with their Managed CA implementation timetable. If
> no alternative decision is taken and communicated here and to Symantec,
> the default will be that we will accept Google's final proposal as a
> consensus date.
> 
> Gerv

I can understand that it would be safest (from the point of PR) to remove their 
roots more or less at the same time as Chrome. But the simple fact that 
Symantec is still playing "to big to fail" shows that THEY will not do what is 
in the interest of the browser users... Browsers and browser users will 
therefore have to fend for themselves. I'd say allowing them until november 1st 
is a very generous implementation of "some time in 2018" and will have to do 
for them. After all they have been dragging their feet for months now. They 
could actually have used all that wasted time... ;-)

CU Hans
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Final Decision by Google on Symantec

[David E. Ross via dev-security-policy]

On 7/28/2017 6:34 AM, Alex Gaynor wrote:
> Frankly I was surprised to see Chromium reverse course on this -- they have
> a history of aggressive leadership in their handling of CA failures, it's a
> little disappointing to see them abandon that.
> 
> I'd strongly advocate for us perusing an earlier date -- December 1st at
> the latest. Reasons:
> 
> 1) Chromium's stated reason for avoiding dates around the holidays makes no
> sense -- organizations with change freezes they need to adhere to have a
> simple solution: obtain and deploy a new certificate at an earlier date!
> They have 4 months between now and December 1st, if you can't deploy a cert
> in 4 months, I submit you have larger problems.
> 
> 2) It is important that CAs not be rewarded for the length of time this
> process takes. CAs should be encouraged and rewarded for active
> participation and engagement in this list.
> 
> 3) Mandatory CT (well, mandatory for trust in Chromium) is a significant
> win for security and transparency. At the moment, even discussing the
> parameters of the distrust is complicated by the fact that we have limited
> visibility into the iceberg of their PKI before June 1st, 2016 (see the
> other thread where I attempt to discuss the count they provide of
> outstanding certs that would be impacted). Given the challenges we know
> exist in their legacy PKI, I think it's fair to say that continuing to
> trust these certs represents real risk for our users's security.
> 
> Alex

I strongly agree.  The focus must be on protecting end-users, not on
Symantec or on Symantec's customers.

Symantec must know who has subscriber certificates that chain to
Symantec's roots.  Those customers could all be notified very quickly
that their certificates are about to be distrusted.  Those customers
would then have ample time to obtain and install replacement subscriber
certificates chaining to alternative roots of other certification
authorities.

As for any disruption of secure transactions, consider the abrupt
termination of DigiNotar when that certification authority was found to
have serious lapses in its operations.  The world did not end.

-- 

David E. Ross
.

The only reason we have so many laws is that not enough people will do
the right thing.  (© 1997 by David Ross)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Final Decision by Google on Symantec

[Vincent Lynch via dev-security-policy]

Hi Gerv,

Thank you for reaching out to the mdsp community.

There are valid security reasons to consider a dis-trust date earlier than
April 2018 for the corpus of Symantec certs issued prior to June 1st, 2016.

However, I also believe there are security and operational risks in
complicating the needed remediation by having two major browsers propose
different dis-trust dates.

I believe the internet community would benefit more from simplified
messaging than they would from a dis-trust date that is a few months
earlier. For that reason, I think Mozilla should match Google's April 2018
dis-trust date.

Thank you,

Vincent

[Disclaimer: I work for a company that sells Symantec SSL certificates, but
am commenting in a personal capacity.]

On Fri, Jul 28, 2017 at 2:14 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Google have made a final decision on the various dates they plan to
> implement as part of the consensus plan in the Symantec matter. The
> message from blink-dev is included below.
>
> Most of the dates have consensus - the dates for Symantec to implement
> the Managed CA infrastructure are agreed by all, and the date for final
> distrust of the old Symantec PKI is agreed by Google and Mozilla (to
> within a week, at any rate). I proposed November 1st 2018. Google has
> gone for October 23rd 2018; in practical terms, we would implement that
> using Firefox 63 (October 16th) or 64 (November 27th).
>
> However, there is some difference in the proposals for the date on which
> browsers should dis-trust Symantec certificates issued before June 1st,
> 2016. This date is significant because after that, Symantec have been
> required to log all their certs to CT and so there is much better
> transparency of issuance practice. I proposed December 1st 2017. Google
> strongly considered late January, but have finally chosen April 17th 2018.
>
> We now have two choices. We can accept the Google date for ourselves, or
> we can decide to implement something earlier. Implementing something
> earlier would involve us leading on compatibility risk, and so would
> need to get wider sign-off from within Mozilla, but nevertheless I would
> like to get the opinions of the m.d.s.p community.
>
> I would like to make a decision on this matter on or before July 31st,
> as Symantec have asked for dates to be nailed down by then in order for
> them to be on track with their Managed CA implementation timetable. If
> no alternative decision is taken and communicated here and to Symantec,
> the default will be that we will accept Google's final proposal as a
> consensus date.
>
> Gerv
>
>  Forwarded Message 
> Subject:Re: [blink-dev] Intent to Deprecate and Remove: Trust in
> existing Symantec-issued Certificates
> Date:   Thu, 27 Jul 2017 17:16:06 -0700
> From:   Darin Fisher 
> To: Darin Fisher 
> CC: blink-dev 
>
>
>
> Representing Google Chrome and the Chromium open source project, what
> follows is our final proposal on this matter.
>
>
> We’d like to first thank the blink-dev community for your input on this
> discussion. After taking this input into consideration along with the
> latest responses from Symantec and Mozilla, we have produced the
> following proposal that is intended to be our final plan of action on
> this matter.
>
>
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016:
>
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016, which is tentatively scheduled to hit Canary on January
> 19, 2018; Beta on March 15, 2018; and Stable (the vast majority of
> Chrome users) on April 17, 2018. Affected site operators are strongly
> encouraged to replace their TLS certificates before March 15, 2018 to
> prevent breakage. Although this is significantly later than our initial
> proposal of August 2017 and Mozilla’s proposal for late 2017
>  y7IRQALJBgAJ>,
> we think it hits an appropriate balance between the security risk to
> Chrome users and minimizing disruption to the ecosystem. This time will
> allow clear messaging and scheduling for site operators to update
> certificates.
>
>
> We considered a number of alternative dates for distrusting this subset
> of existing certificates before landing on Chrome 66. Given the scale of
> Symantec’s existing PKI and the impact to the ecosystem that these
> mitigations pose, one of our goals was to consider dates that gave site
> operators enough lead time, as well as to try to clear end-of-year time
> periods where production freezes are typically in place. Chrome 62 which
> comes out in October 2017 was seriously considered, but was rejected due
> to concerns around not giving enough lead time for site operators.
> Chrome 63 which comes out in December was rejected due to overlapping
> 

Re: Final Decision by Google on Symantec

[Alex Gaynor via dev-security-policy]

Frankly I was surprised to see Chromium reverse course on this -- they have
a history of aggressive leadership in their handling of CA failures, it's a
little disappointing to see them abandon that.

I'd strongly advocate for us perusing an earlier date -- December 1st at
the latest. Reasons:

1) Chromium's stated reason for avoiding dates around the holidays makes no
sense -- organizations with change freezes they need to adhere to have a
simple solution: obtain and deploy a new certificate at an earlier date!
They have 4 months between now and December 1st, if you can't deploy a cert
in 4 months, I submit you have larger problems.

2) It is important that CAs not be rewarded for the length of time this
process takes. CAs should be encouraged and rewarded for active
participation and engagement in this list.

3) Mandatory CT (well, mandatory for trust in Chromium) is a significant
win for security and transparency. At the moment, even discussing the
parameters of the distrust is complicated by the fact that we have limited
visibility into the iceberg of their PKI before June 1st, 2016 (see the
other thread where I attempt to discuss the count they provide of
outstanding certs that would be impacted). Given the challenges we know
exist in their legacy PKI, I think it's fair to say that continuing to
trust these certs represents real risk for our users's security.

Alex


On Fri, Jul 28, 2017 at 2:14 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Google have made a final decision on the various dates they plan to
> implement as part of the consensus plan in the Symantec matter. The
> message from blink-dev is included below.
>
> Most of the dates have consensus - the dates for Symantec to implement
> the Managed CA infrastructure are agreed by all, and the date for final
> distrust of the old Symantec PKI is agreed by Google and Mozilla (to
> within a week, at any rate). I proposed November 1st 2018. Google has
> gone for October 23rd 2018; in practical terms, we would implement that
> using Firefox 63 (October 16th) or 64 (November 27th).
>
> However, there is some difference in the proposals for the date on which
> browsers should dis-trust Symantec certificates issued before June 1st,
> 2016. This date is significant because after that, Symantec have been
> required to log all their certs to CT and so there is much better
> transparency of issuance practice. I proposed December 1st 2017. Google
> strongly considered late January, but have finally chosen April 17th 2018.
>
> We now have two choices. We can accept the Google date for ourselves, or
> we can decide to implement something earlier. Implementing something
> earlier would involve us leading on compatibility risk, and so would
> need to get wider sign-off from within Mozilla, but nevertheless I would
> like to get the opinions of the m.d.s.p community.
>
> I would like to make a decision on this matter on or before July 31st,
> as Symantec have asked for dates to be nailed down by then in order for
> them to be on track with their Managed CA implementation timetable. If
> no alternative decision is taken and communicated here and to Symantec,
> the default will be that we will accept Google's final proposal as a
> consensus date.
>
> Gerv
>
>  Forwarded Message 
> Subject:Re: [blink-dev] Intent to Deprecate and Remove: Trust in
> existing Symantec-issued Certificates
> Date:   Thu, 27 Jul 2017 17:16:06 -0700
> From:   Darin Fisher 
> To: Darin Fisher 
> CC: blink-dev 
>
>
>
> Representing Google Chrome and the Chromium open source project, what
> follows is our final proposal on this matter.
>
>
> We’d like to first thank the blink-dev community for your input on this
> discussion. After taking this input into consideration along with the
> latest responses from Symantec and Mozilla, we have produced the
> following proposal that is intended to be our final plan of action on
> this matter.
>
>
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016:
>
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016, which is tentatively scheduled to hit Canary on January
> 19, 2018; Beta on March 15, 2018; and Stable (the vast majority of
> Chrome users) on April 17, 2018. Affected site operators are strongly
> encouraged to replace their TLS certificates before March 15, 2018 to
> prevent breakage. Although this is significantly later than our initial
> proposal of August 2017 and Mozilla’s proposal for late 2017
>  y7IRQALJBgAJ>,
> we think it hits an appropriate balance between the security risk to
> Chrome users and minimizing disruption to the ecosystem. This time will
> allow clear messaging and scheduling for site operators to update
> certificates.
>
>
> We considered 

Re: Final Decision by Google on Symantec

[Jakob Bohm via dev-security-policy]

As it stands, aligning with Chrome, plus/minus 14 days would be the best
approach.

It is of cause regrettable that Symantec managed to delay the decision
process until a time when key Mozilla personnel (most notable Gerv)
where unavailable, thus allowing Chrome to make the decisions while
Mozilla was waiting for the summer vacations to end.  But done is done,
and at this point its better to keep the established schedule than a
similar-but-different schedule which would simply confuse matters.

Maybe Mozilla should, as quickly as possible, create a (temporary)
about:config setting "security.certs.symantec.testdate" which can be
used by site operators to test how the planned behavior would affect
their current site over the transition period.  For example, setting
this to "2018-03-15" would make the trust of Symantec WebPKI certs
follow the planned timeline as it would apply to the most recent
released browser available on that particular date.  The setting would
go away when the last deadline passes In late 2018.

Of cause until the managed SubCA certs are known, this would trust an
empty set of such certificates for that role, but that's OK since no end
certs would have been issued from them either.

Also (Mozilla and Chrome) should reach out to Qualsys to encourage them
to incorporate the timetable and related warnings into their ssllabs.com
test service.

Of cause, Symantec itself should use its internal records to reach out
to affected certificate subscribers telling them when each of their
existing certificates would be affected (if at all), which replacement
product Symantec recommends for each one, and if there will be any
pro-rata discount for that replacement.

Something like this:

Example text only e-mail, sent from symantec.com e-mail and digitally
signed with a Symantec-issued S/MIME certificate:
(Return receipt requested from e-mail clients that do that).

> Subject: EMERGENCY Replacement of some of your certificates.
> OR: Your certificates not affected by emergency replacement.
> (latter subject used if the count of affected certificates is 0).
>
> Dear [customer name] <[n...@example.com]>
>
> Due to security issues, it is necessary to replace some Symantec-
> issued certificates before their original expiry dates in order for
> your website to continue to work in various browsers.  Below is a list
> of the certificates you have purchased using this e-mail address as
> one of the official points of contact and how they will be affected.
>
> For background information, please see https://www.symantec.com/xx
> Or go directly to the www.symantec.com front page and click on the
> link marked "early certificate replacements 2017-2018".
>
> www.example.com serial number 123456890123456890123456890123456890
> Issued for: www.example.com, example.com
> Symantec brand: Verisign
> Issued: Jan 15, 2016
> Original expiry: Jan 15, 2018
> NOT AFFECTED
>
> www.example.net serial number 567890123456890123456890123456890120
> Issued for: www.example.net, 192.0.2.1 (IP address)
> Symantec brand: Symantec
> Issued: May 30, 2016
> Original expiry: May 30, 2019
> NEW EXPIRY IN SOME BROWSERS: April 17, 2017
> NEW EXPIRY IN TEST BROWSERS: January 19, 2017
> Suggested replacement: Order a replacement 2 year certificate from
> Symantec between December 2, 2017 and April 17, 2017 with a pro-rata
> discount of ??%.  Or order a replacement 1 year certificate from
> Symantec between December 2, 2017 and April 17, 2017 with a pro-rata
> discount of ??%.
>
> c...@example.com serial number ABCDEFABCDEFABCDEFABCDEFABCDEFABCDEF
> Issued for: c...@example.com (e-mail)
> Symantec brand: Symantec
> Issued: May 20, 2016
> Original expiry: May 20, 2019
> NOT AFFECTED
>
> Total: 3 certificates issued, 1 affected.



On 28/07/2017 08:14, Gervase Markham wrote:

Google have made a final decision on the various dates they plan to
implement as part of the consensus plan in the Symantec matter. The
message from blink-dev is included below.

Most of the dates have consensus - the dates for Symantec to implement
the Managed CA infrastructure are agreed by all, and the date for final
distrust of the old Symantec PKI is agreed by Google and Mozilla (to
within a week, at any rate). I proposed November 1st 2018. Google has
gone for October 23rd 2018; in practical terms, we would implement that
using Firefox 63 (October 16th) or 64 (November 27th).

However, there is some difference in the proposals for the date on which
browsers should dis-trust Symantec certificates issued before June 1st,
2016. This date is significant because after that, Symantec have been
required to log all their certs to CT and so there is much better
transparency of issuance practice. I proposed December 1st 2017. Google
strongly considered late January, but have finally chosen April 17th 2018.

We now have two choices. We can accept the Google date for ourselves, or
we can decide to implement something earlier. Implementing something
earlier would involve us 

Re: Final Decision by Google on Symantec

[wizard--- via dev-security-policy]

With respect to the date of distrust of symantec certificates issues before 
June 1, 2016, I believe Mozilla has a third option:

Remove indicators of trust (green lock, etc.) on December 1, 2017 for Symantec 
certificates issued prior to June 1, 2016 (but do not produce interstitials and 
do not actively distrust until April 17th 2018).

Yes, this is somewhat more engineering work for Mozilla, but it strikes the 
right balance between usability and safety.

Why? The underlying security rationale for an earlier distrust of certificates 
issued prior to June 1, 2016 is that there is no CT disclosure requirement for 
DV/OV. The lack of transparency afforded to issuances prior to June 1, 2016, 
inherently makes them "riskier" to end users given Symantec's demonstrated 
prior practices.

The above strategy properly incorporates that additional risk in the trust 
decision, while not introducing the much larger potential compatibility issues 
of full distrust of old certificates on the same day that the managed CA 
becomes fully operational.

Mozilla could even consider waiving the above if Symantec were to log *all* 
(including expired and revoked) certificates from prior to June 1, 2016 [with 
the enforcement being: if anyone in the world provides Mozilla with a copy of 
even a single certificate that is not in CT after Symantec says that they are, 
then the above, or something more stringent, immediately goes into effect]. 
Symantec has even provided a fairly accurate count of how many non-expired, 
non-revoked certificates prior to June 1, 2016 should be present as an initial 
sanity check.

Note this strategy may also help eliminate compatibility problems April 17th 
2018, since there will have been a large period of time where indicators of 
trust were removed (but otherwise remaining functional).

On Friday, July 28, 2017 at 2:15:43 AM UTC-4, Gervase Markham wrote:
> Google have made a final decision on the various dates they plan to
> implement as part of the consensus plan in the Symantec matter. The
> message from blink-dev is included below.
> 
> Most of the dates have consensus - the dates for Symantec to implement
> the Managed CA infrastructure are agreed by all, and the date for final
> distrust of the old Symantec PKI is agreed by Google and Mozilla (to
> within a week, at any rate). I proposed November 1st 2018. Google has
> gone for October 23rd 2018; in practical terms, we would implement that
> using Firefox 63 (October 16th) or 64 (November 27th).
> 
> However, there is some difference in the proposals for the date on which
> browsers should dis-trust Symantec certificates issued before June 1st,
> 2016. This date is significant because after that, Symantec have been
> required to log all their certs to CT and so there is much better
> transparency of issuance practice. I proposed December 1st 2017. Google
> strongly considered late January, but have finally chosen April 17th 2018.
> 
> We now have two choices. We can accept the Google date for ourselves, or
> we can decide to implement something earlier. Implementing something
> earlier would involve us leading on compatibility risk, and so would
> need to get wider sign-off from within Mozilla, but nevertheless I would
> like to get the opinions of the m.d.s.p community.
> 
> I would like to make a decision on this matter on or before July 31st,
> as Symantec have asked for dates to be nailed down by then in order for
> them to be on track with their Managed CA implementation timetable. If
> no alternative decision is taken and communicated here and to Symantec,
> the default will be that we will accept Google's final proposal as a
> consensus date.
> 
> Gerv
> 
>  Forwarded Message 
> Subject:  Re: [blink-dev] Intent to Deprecate and Remove: Trust in
> existing Symantec-issued Certificates
> Date: Thu, 27 Jul 2017 17:16:06 -0700
> From: Darin Fisher 
> To:   Darin Fisher 
> CC:   blink-dev 
> 
> 
> 
> Representing Google Chrome and the Chromium open source project, what
> follows is our final proposal on this matter.
> 
> 
> We’d like to first thank the blink-dev community for your input on this
> discussion. After taking this input into consideration along with the
> latest responses from Symantec and Mozilla, we have produced the
> following proposal that is intended to be our final plan of action on
> this matter.
> 
> 
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016:
> 
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016, which is tentatively scheduled to hit Canary on January
> 19, 2018; Beta on March 15, 2018; and Stable (the vast majority of
> Chrome users) on April 17, 2018. Affected site operators are strongly
> encouraged to replace their TLS certificates before March 15, 2018 to
> prevent breakage. Although this is significantly later than our initial
> 

Final Decision by Google on Symantec

[Gervase Markham via dev-security-policy]

Google have made a final decision on the various dates they plan to
implement as part of the consensus plan in the Symantec matter. The
message from blink-dev is included below.

Most of the dates have consensus - the dates for Symantec to implement
the Managed CA infrastructure are agreed by all, and the date for final
distrust of the old Symantec PKI is agreed by Google and Mozilla (to
within a week, at any rate). I proposed November 1st 2018. Google has
gone for October 23rd 2018; in practical terms, we would implement that
using Firefox 63 (October 16th) or 64 (November 27th).

However, there is some difference in the proposals for the date on which
browsers should dis-trust Symantec certificates issued before June 1st,
2016. This date is significant because after that, Symantec have been
required to log all their certs to CT and so there is much better
transparency of issuance practice. I proposed December 1st 2017. Google
strongly considered late January, but have finally chosen April 17th 2018.

We now have two choices. We can accept the Google date for ourselves, or
we can decide to implement something earlier. Implementing something
earlier would involve us leading on compatibility risk, and so would
need to get wider sign-off from within Mozilla, but nevertheless I would
like to get the opinions of the m.d.s.p community.

I would like to make a decision on this matter on or before July 31st,
as Symantec have asked for dates to be nailed down by then in order for
them to be on track with their Managed CA implementation timetable. If
no alternative decision is taken and communicated here and to Symantec,
the default will be that we will accept Google's final proposal as a
consensus date.

Gerv

 Forwarded Message 
Subject:Re: [blink-dev] Intent to Deprecate and Remove: Trust in
existing Symantec-issued Certificates
Date:   Thu, 27 Jul 2017 17:16:06 -0700
From:   Darin Fisher 
To: Darin Fisher 
CC: blink-dev 



Representing Google Chrome and the Chromium open source project, what
follows is our final proposal on this matter.


We’d like to first thank the blink-dev community for your input on this
discussion. After taking this input into consideration along with the
latest responses from Symantec and Mozilla, we have produced the
following proposal that is intended to be our final plan of action on
this matter.


Chrome 66 will distrust Symantec-issued TLS certificates issued before
June 1, 2016:

Chrome 66 will distrust Symantec-issued TLS certificates issued before
June 1, 2016, which is tentatively scheduled to hit Canary on January
19, 2018; Beta on March 15, 2018; and Stable (the vast majority of
Chrome users) on April 17, 2018. Affected site operators are strongly
encouraged to replace their TLS certificates before March 15, 2018 to
prevent breakage. Although this is significantly later than our initial
proposal of August 2017 and Mozilla’s proposal for late 2017
,
we think it hits an appropriate balance between the security risk to
Chrome users and minimizing disruption to the ecosystem. This time will
allow clear messaging and scheduling for site operators to update
certificates.


We considered a number of alternative dates for distrusting this subset
of existing certificates before landing on Chrome 66. Given the scale of
Symantec’s existing PKI and the impact to the ecosystem that these
mitigations pose, one of our goals was to consider dates that gave site
operators enough lead time, as well as to try to clear end-of-year time
periods where production freezes are typically in place. Chrome 62 which
comes out in October 2017 was seriously considered, but was rejected due
to concerns around not giving enough lead time for site operators.
Chrome 63 which comes out in December was rejected due to overlapping
with end-of-year freezes. Chrome 64 which comes out in late January 2018
was strongly considered, but its early release channels also overlap
with holiday and end of year freezes.  Chrome 65’s branch point is close
to the new year, and could present a challenge for some site operators.
Hence, Chrome 66 was chosen as the final approach.


Site operators currently using Symantec-issued TLS server certificates
that were issued before June 1, 2016 need to replace these certificates
as soon as possible to avoid disruption to their users. The distrust of
these certificates is necessary and is specifically targeted at removing
the risk of trusting old certificates that were issued under an
inadequately controlled infrastructure. Site operators can choose to
obtain their certificates from any trusted Certificate Authority.
Although the old infrastructure will be distrusted in the future (see
below), site operators with critical dependencies on Symantec’s current
infrastructure may also obtain replacement