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] <[[email protected]]>
>
> 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/xxxxxx
> 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 ??%.
>
> [email protected] serial number ABCDEFABCDEFABCDEFABCDEFABCDEFABCDEF
> Issued for: [email protected] (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 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 <[email protected]>
To: Darin Fisher <[email protected]>
CC: blink-dev <[email protected]>
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
<https://groups.google.com/d/msg/mozilla.dev.security.policy/gn1i2JNVCnc/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
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 certificates from Symantec,
provided these certificates comply with the existing Chrome requirements
<https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html>for
new certificates issued from Symantec.
While we intend to stick with this schedule, if there is new information
highlighting additional security risks with this set of certificates,
the dates could change to more rapidly distrust the existing certificates.
Chrome 70 will distrust TLS certificates issued from Symantec’s old
infrastructure:
In order to complete this migration, we will be removing trust in all
certificates issued by Symantec’s old infrastructure in Chrome 70. This
includes any replacement certificates issued by Symantec prior to the
transition to the non-Symantec-operated “Managed Partner Infrastructure
<https://docs.google.com/document/d/1Yd079EsKQ-QawTvWgjIfrCV6d0NNlwoS1ftB0MaJkBc/>”.
Chrome 70 is tentatively scheduled to first reach Beta on September 13,
2018 and Stable on October 23, 2018, which is approximately 5 months
after Chrome 66’s corresponding dates.
By these dates, affected site operators will need to have fully replaced
any TLS server certificates issued from Symantec’s old infrastructure,
using any trusted CA including the new Managed Partner Infrastructure.
Failure to migrate a site to one of these two options will result in
breakage when Chrome 70 is released.
Reference Timeline:
In order to distill Chrome’s final plan into an actionable set of
information for site operators, we’ve drawn up a timeline of relevant
dates associated with this plan. As always, Chrome release dates can
vary by a number of days, but upcoming release dates can be tracked here
<https://www.chromium.org/developers/calendar>.
Date
Event
July 27, 2017
through
~March 15, 2018
Site Operators using Symantec-issued TLS server certificates issued
before June 1, 2016 should replace these certificates. These
certificates can be replaced by any currently trusted CA, including
Symantec.
~October 24, 2017
Chrome 62 released to Stable, which will add alerting in DevTools when
evaluating certificates that will be affected by the Chrome 66 distrust.
December 1, 2017
According to Symantec, the new Managed Partner Infrastructure will at
this point be capable of full issuance. Any certificates issued by
Symantec’s old infrastructure after this point will cease working in a
future Chrome update.
From this date forward, Site Operators can obtain TLS server
certificates from the new Managed Partner Infrastructure that will
continue to be trusted after Chrome 70 (~October 23, 2018).
December 1, 2017 does not mandate any certificate changes, but
represents an opportunity for site operators to obtain TLS server
certificates that will not be affected by Chrome 70’s distrust of the
old infrastructure.
~March 15, 2018
Chrome 66 released to beta, which will remove trust in Symantec-issued
certificates with a not-before date before June 1, 2016. As of this
date, in order to ensure continuity of operations, Site Operators must
be using either a Symantec-issued TLS server certificate issued on or
after June 1, 2016 or a currently valid certificate issued from any
other trusted CA as of Chrome 66.
Site Operators that obtained a certificate from Symantec’s old
infrastructure after June 1, 2016 are unaffected by Chrome 66 but will
need to obtain a new certificate by the Chrome 70 dates described below.
~April 17, 2018
Chrome 66 released to Stable.
~September 13, 2018
Chrome 70 released to Beta, which will remove trust in the old
Symantec-rooted Infrastructure. This will not affect any certificate
chaining to the new Managed Partner Infrastructure, which Symantec has
said will be operational by December 1, 2017.
Only TLS server certificates issued by Symantec’s old infrastructure
will be affected by this distrust regardless of issuance date.
~October 23, 2018
Chrome 70 released to Stable.
A note on the Blink process and this Intent:
As mentioned at the start of this discussion, the Google Chrome team
<https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ>decided
to use the Blink Process <http://www.chromium.org/blink#new-features>in
discussing this change, as a way to gather feedback from site operators,
the Chromium community, other browsers, and the broader ecosystem about
how to balance the interoperability risk and compatibility risk. A goal
of this process is to balance risk by aligning on interoperable
solutions, minimize ambiguity, and provide transparency into the
decision making process. This process was designed around balancing
changes to the Web Platform APIs, and we recognize there are further
opportunities to improve this for Certificate Authority decisions. As
those improvements are not yet in place, we will be forgoing the Blink
API owner LGTM process for approval, and treating this more as a
product-level decision instead.
Thanks to everyone who put in so much time and energy to arrive at this
point.
(snip earlier e-mails)
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
