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 <[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. > > > > > On Sun, May 7, 2017 at 4:57 PM, Darin Fisher <[email protected] > <mailto:[email protected]>> wrote: > > I wanted to give folks an update about the current state of this > Intent. Given all of the feedback we've received from the community, > right now we are continuing to evaluate different options and are > improving our understanding of the impact these proposals would have > on the ecosystem. We understand the desire to reach closure here, > but also want to make sure that we take the appropriate amount of > time to ensure that we come up with the best possible proposal. If > you have additional feedback that could help inform our decision, we > welcome hearing it. > > Thanks, > -Darin > > > > On Thu, Mar 23, 2017 at 9:02 AM, Ryan Sleevi <[email protected] > <mailto:[email protected]>> wrote: > > Note: Historically, the Google Chrome team has not used the > Blink Process <http://www.chromium.org/blink#new-features>for > Certificate Authority-related security issues, of which there > have been a number over the years. However, we are interested in > exploring using this process for such changes, as it provides a > greater degree of transparency and public participation. Based > on the level of participation and feedback we receive, we may > consider using this for the future. However, as CA-related > security incidents may require immediate response to protect > users, this should not be seen as a guarantee that this process > can be used in future incident responses. > > > Primary eng (and PM) emails: > > [email protected] > <mailto:[email protected]>[email protected] > <mailto:[email protected]> > > > Summary > > Since January 19, the Google Chrome team has been investigating > a series of failures by Symantec Corporation to properly > validate certificates. Over the course of this investigation, > the explanations provided by Symantec have revealed a > continually increasing scope of misissuance with each set of > questions from members of the Google Chrome team; an initial set > of reportedly 127 certificates has expanded to include at least > 30,000 certificates, issued over a period spanning several > years. This is also coupled with a series of failures following > the previous set of misissued certificates from Symantec > > <https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html>, > causing us to no longer have confidence in the certificate > issuance policies and practices of Symantec over the past > several years. To restore confidence and security of our users, > we propose the following steps: > > * > > A reduction in the accepted validity period of newly issued > Symantec-issued certificates to nine months or less, in > order to minimize any impact to Google Chrome users from any > further misissuances that may arise. > > * > > An incremental distrust, spanning a series of Google Chrome > releases, of all currently-trusted Symantec-issued > certificates, requiring they be revalidated and replaced. > > * > > Removal of recognition of the Extended Validation status of > Symantec issued certificates, until such a time as the > community can be assured in the policies and practices of > Symantec, but no sooner than one year. > > > Motivation > > As captured in Chrome’s Root Certificate Policy > <https://www.chromium.org/Home/chromium-security/root-ca-policy>, > root certificate authorities are expected to perform a number of > critical functions commensurate with the trust granted to them. > This includes properly ensuring that domain control validation > is performed for server certificates, to audit logs frequently > for evidence of unauthorized issuance, and to protect their > infrastructure in order to minimize the ability for the issuance > of fraudulent certs. > > > On the basis of the details publicly provided by Symantec, we do > not believe that they have properly upheld these principles, and > as such, have created significant risk for Google Chrome users. > Symantec allowed at least four parties access to their > infrastructure in a way to cause certificate issuance, did not > sufficiently oversee these capabilities as required and > expected, and when presented with evidence of these > organizations’ failure to abide to the appropriate standard of > care, failed to disclose such information in a timely manner or > to identify the significance of the issues reported to them. > > > These issues, and the corresponding failure of appropriate > oversight, spanned a period of several years, and were trivially > identifiable from the information publicly available or that > Symantec shared. > > > The full disclosure of these issues has taken more than a month. > Symantec has failed to provide timely updates to the community > regarding these issues. Despite having knowledge of these > issues, Symantec has repeatedly failed to proactively disclose > them. Further, even after issues have become public, Symantec > failed to provide the information that the community required to > assess the significance of these issues until they had been > specifically questioned. The proposed remediation steps offered > by Symantec have involved relying on known-problematic > information or using practices insufficient to provide the level > of assurance required under the Baseline Requirements and > expected by the Chrome Root CA Policy. > > > In January 2015, Symantec-issued certificates represented more > than 30% of the valid certificates by volume. While changes in > the CA ecosystem have seen that share decrease over the past two > years, there is still a significant compatibility risk for an > immediate and complete distrust. Further, due to overall TLS > ecosystem concerns, we understand that it may take non-trivial > effort for some site operators to find suitable solutions, as > the need to support older devices may necessitate the use of > particular CAs, meaning that distrust of new certificates also > has significant compatibility risk. > > > To balance the compatibility risks versus the security risks, we > propose a gradual distrust of all existing Symantec-issued > certificates, requiring that they be replaced over time with > new, fully revalidated certificates, compliant with the current > Baseline Requirements. This will be accomplished by gradually > decreasing the ‘maximum age’ of Symantec-issued certificates > over a series of releases, distrusting certificates whose > validity period (the difference of notBefore to notAfter) > exceeds the specified maximum. > > > The proposed schedule is as follows: > > Chrome 59 (Dev, Beta, Stable): 33 months validity (1023 days) > > Chrome 60 (Dev, Beta, Stable): 27 months validity (837 days) > > Chrome 61 (Dev, Beta, Stable): 21 months validity (651 days) > > Chrome 62 (Dev, Beta, Stable): 15 months validity (465 days) > > Chrome 63 (Dev, Beta): 9 months validity (279 days) > > Chrome 63 (Stable): 15 months validity (465 days) > > Chrome 64 (Dev, Beta, Stable): 9 months validity (279 days) > > > The proposed schedule attempts to avoid making changes in Chrome > 63 Stable, as that would be released during the winter holiday > production freeze many organizations undergo. This is solely to > reduce disruption for site operators and users, and attempts to > resume with Chrome 64 following the holiday season. Further, the > practical impact of the changes in Chrome 59 and 60 are > relatively minimal, due to many of the certificates issued > during that period of time being issued using SHA-1, which is no > longer supported for certificates in Chrome. > > > In addition, we propose to require that all newly-issued > certificates must have validity periods of no greater than 9 > months (279 days) in order to be trusted in Google Chrome, > effective Chrome 61. This ensures that the risk of any further > misissuance is, at most, limited to nine months, and more > importantly, that if any further action is warranted or > necessary, that the entire ecosystem can migrate within that > time period, thus minimizing the risk of further compatibility > issues. > > > By combining these two steps, we can ensure that the level of > assurance in Symantec-issued certificates is able to match what > is expected by Google Chrome and the ecosystem, and that the > risks posed both from past and possible future misissuance is > minimized as much as possible. > > > Given the nature of these issues, and the multiple failures of > Symantec to ensure that the level of assurance provided by their > certificates meets the requirements of the Baseline Requirements > or Extended Validation Guidelines, we no longer have the > confidence necessary in order to grant Symantec-issued > certificates the “Extended Validation” status. As documented > with both the current and past misissuance, Symantec failed to > ensure that the organizational attributes, displayed within the > address bar for such certificates, meet the level of quality and > validation required for such display. Therefore, we propose to > remove such indicators, effective immediately, until Symantec is > able to demonstrate the level of sustained compliance necessary > to grant such trust, which will be a period no less than a year. > After such time has passed, we will consider requests from > Symantec to re-evaluate this position, in collaboration with the > broader Chromium community. > > > Compatibility and Interoperability Risk > > As with any reduction in trust in a Certificate Authority, this > poses a non-trivial degree of compatibility risk. This is > because site operators desire to have their certificates > recognized in all client browsers, and if one or more browsers > fail to trust a given CA, this is prevented from happening. > > > On the other hand, all site operators expect that certificates > will only be issued for their domains upon their request, and > the failure to have that assurance significantly undermines the > security of HTTPS for both site operators and users. > > > This compatibility risk is especially high for Symantec-issued > certificates, due to their acquisition of some of the first CAs, > such as Thawte, Verisign, and Equifax, which are some of the > most widely supported CAs. Distrusting such CAs creates further > difficulty for providing secure connections to both old and new > devices alike, due to the need to ensure the CA a site operator > uses is recognized across these devices. > > > Further, the immediate distrust of a CA, as has been necessary > in the past, can significantly impact both site operators and > users. Site operators are forced to acquire certificates from > other CAs, without having the opportunity and time to research > which CAs best meet their needs, and users encounter a > substantial number of errors until those site operators act, > conditioning them to ignore security warnings. In the event that > only a single browser distrusts such a CA, the error is often > seen as the browser’s fault, despite it being a failure of the > CA to provide the necessary level of assurance, and the site > operator to respond in a timely fashion. > > > Assessing the compatibility risk with both Edge and Safari is > difficult, because neither Microsoft nor Apple communicate > publicly about their changes in trust prior to enacting them. > > > While Mozilla conducts their discussions regarding Certificate > Authorities in public, and were the first to be alerted of these > latest issues, they have not yet begun discussion of the next > steps to how best to protect their users. Our hope is that this > proposal may be seen as one that appropriately balances the > security and compatibility risks with the needs of site > operators, browsers, and users, and we welcome all feedback. > > > Alternative implementation suggestion for web developers > > This proposal allows for web developers to continue to use > Symantec issued certificates, but will see their validity period > reduced. This ensure that web developers are aware of the risk > and potential of future distrust of Symantec-issued > certificates, should additional misissuance events occur, while > also allowing them the flexibility to continue using such > certificates should it be necessary. > > > Usage information from UseCounter > > <https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>: > > For a variety of non-technical reasons, we do not currently > instrument the usage of CAs. Further, few public metrics exist > for intersecting usage information with the validity period, > since only certificates valid greater than nine months will be > affected outside of their normal replacement cycle. From Mozilla > Firefox’s Telemetry, we know that Symantec issued certificates > are responsible for 42% of certificate validations. However, > this number is not strictly an indicator for impact, as this > number is biased towards counting certificates for > heavily-trafficked sites, and whose issuance is fully automated > and/or whose validity periods will be unaffected, thus > significantly overstating impact. By phasing such changes in > over a series of releases, we aim to minimize the impact any > given release poses, while still continually making progress > towards restoring the necessary level of security to ensure > Symantec issued certificates are as trustworthy as certificates > from other CAs. > > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "blink-dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/chromium.org/d/topic/blink-dev/eUAKwjihhBs/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP0-QptbKT2UaAe_WhX2eYO3P4QMZmM8q2HT27YXSVRCouO4MQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP0-QptbKT2UaAe_WhX2eYO3P4QMZmM8q2HT27YXSVRCouO4MQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
