Discussion:
Intent to Deprecate and Remove: Trust in existing Symantec-issued Certificates
(too old to reply)
a***@chromium.org
2017-08-04 00:27:46 UTC
Permalink
Hello blink-dev,

As many of you have already heard, Symantec has just announced
<https://www.symantec.com/about/newsroom/press-releases/2017/symantec_0802_01>
the sale of their PKI business to DigiCert. We had intended to post a
Google Security Blog update with the final plan outlined in our post
<https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/El1mH8S6AwAJ>
on July 27, but we’re holding off while we evaluate all of the new
information coming in.

As of right now, the plan of action and associated timelines from the above
July 27 post are still in place, meaning the previously-stated August 2017
dates are no longer applicable. Should any of the new information affect
this plan, we will update the community immediately. More information on
this matter can be found in the m.d.s.p. thread
<https://groups.google.com/d/msg/mozilla.dev.security.policy/_EnH2IeuZtw/TzsFlNvSAAAJ>.


Thanks,

Devon
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e5dd264a-efe0-4ab5-9a5d-4c97034f377a%40chromium.org.
Vincent Lynch
2017-08-04 16:36:04 UTC
Permalink
(Posting on behalf of my employer, TheSSLStore.com)

Hopefully Devon and Darin's above posts have cleared up any concern about
what the effective date of Google's plan is.

I know that for some, following this thread can be difficult. It can also
be hard to read or link to specific posts on the Google Groups UI.

For anyone who is looking for a single page reference (maybe to convince a
coworker), I have published this post:

https://www.thesslstore.com/blog/symantec-certificates-august-8/

There is no new information here - it simply reaffirms that the effective
date for Google's plan is *April 2018*, not August 8th 2017. I hope it can
be of use for some people.

-Vincent
Post by a***@chromium.org
Hello blink-dev,
As many of you have already heard, Symantec has just announced
<https://www.symantec.com/about/newsroom/press-releases/2017/symantec_0802_01>
the sale of their PKI business to DigiCert. We had intended to post a
Google Security Blog update with the final plan outlined in our post
<https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/El1mH8S6AwAJ>
on July 27, but we’re holding off while we evaluate all of the new
information coming in.
As of right now, the plan of action and associated timelines from the
above July 27 post are still in place, meaning the previously-stated August
2017 dates are no longer applicable. Should any of the new information
affect this plan, we will update the community immediately. More
information on this matter can be found in the m.d.s.p. thread
<https://groups.google.com/d/msg/mozilla.dev.security.policy/_EnH2IeuZtw/TzsFlNvSAAAJ>.
Thanks,
Devon
--
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
To view this discussion on the web visit https://groups.google.com/a/
chromium.org/d/msgid/blink-dev/e5dd264a-efe0-4ab5-9a5d-
4c97034f377a%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e5dd264a-efe0-4ab5-9a5d-4c97034f377a%40chromium.org?utm_medium=email&utm_source=footer>
.
--
Vincent Lynch
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM_pNreg6pJo4YbWVi67oPqPmT8z-ZTZnkP685Uu40u-bf6%3DZw%40mail.gmail.com.
Peter Bowen
2017-08-04 16:45:56 UTC
Permalink
Some of you might have gotten this, DigitCert is acquiring Symantec PKI,
http://app.website-security.symantec.com/e/es?s=1701211846&e=76074 .
So, what now ?
Over in mozilla.dev.security.policy, which is handling a discussion on this
same topic for Mozilla, there was a post that laid out the Mozilla plans (
https://groups.google.com/d/msg/mozilla.dev.security.policy/Oaeqtddo_Cw/lN-Pp6h1AAAJ)
Gerv Markham is a Mozilla employee and one of the employees responsible
for the decision for Mozilla. In that post he said, "I would also
reiterate, in case it becomes relevant, that any change of control of some
or all of Symantec's roots would not be grounds for a renegotiation of
these dates."

This posted prior to the announcement of the acquisition, when there were
only rumors int the press. It has now obviously become relevant.

My personal interpretation of this is:

1) Anyone with certificates from GeoTrust, RapidSSL, Symantec, Thawte, or
VeriSign that were issued prior to June 1, 2016 should replace these
certificates as soon as possible. The replacement can be from the same
Symantec-operated CAs or from any other CA.

2) DigiCert expects to take over issuance on or before December 1, 2017.
Once this happens, all certificates from GeoTrust, RapidSSL, Symantec,
Thawte, or VeriSign will need to be replaced with DigiCert issued
certificates. This replacement needs to happen by mid-July 2018. It is
expected that DigiCert will offer certificates that chain to the
existing GeoTrust,
RapidSSL, Symantec, Thawte, and VeriSign roots, so there should not be
compatibility problems with existing applications.

Obviously I don't work for Google or speak for Chromium, so I could have
this wrong, but this is my interpretation.

Thanks,
Peter
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6vND-aVu05okUVnXZMjhDReO8G8%2BFhbZHmet6EfmqXW_HACw%40mail.gmail.com.
b***@gmail.com
2017-08-08 21:53:33 UTC
Permalink
Hey Darin,

Do you have a rough estimate as to when the blog will be posted?

There's a bit of a confusion in the market and some clients are some what
reluctant to believe the timeline without "official" announcement from
google.


Thanks.

-Sean
Yes, there will be a corresponding blog post up shortly.
-Darin
Hey Darin,
Are there any plans to post this information somewhere with a bit more
visibility, like the Chromium Blog, or the Google Online Security Blog?
I get the feeling not nearly as many developers and site operators are
subscribed to this mailing list as are following those blogs.
- Andrew
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
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
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.
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.
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.
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
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.
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
-
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.
Chrome 59 (Dev, Beta, Stable): 33 months validity (1023 days)
Chrome 60 (Dev, Beta, Stable): 27 months validity (837 days)
...
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b6865ed5-c90d-4229-a523-58320e3be6d4%40chromium.org.
Darin Fisher
2017-08-08 22:32:40 UTC
Permalink
Hi Sean,

Apologies for the delay. We know folks are eager for an official blog post.
Please see Devon's recent update
<https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs%5B276-300%5D>
on
the matter.

Thanks,
-Darin
Post by b***@gmail.com
Hey Darin,
Do you have a rough estimate as to when the blog will be posted?
There's a bit of a confusion in the market and some clients are some what
reluctant to believe the timeline without "official" announcement from
google.
Thanks.
-Sean
Yes, there will be a corresponding blog post up shortly.
-Darin
Hey Darin,
Are there any plans to post this information somewhere with a bit more
visibility, like the Chromium Blog, or the Google Online Security Blog?
I get the feeling not nearly as many developers and site operators are
subscribed to this mailing list as are following those blogs.
- Andrew
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
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
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.
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.
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.
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
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.
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
-
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.
Chrome 59 (Dev, Beta, Stable): 33 months validity (1023 days)
Chrome 60 (Dev, Beta, Stable): 27 months validity (837 days)
...
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/
chromium.org/d/msgid/blink-dev/b6865ed5-c90d-4229-a523-
58320e3be6d4%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b6865ed5-c90d-4229-a523-58320e3be6d4%40chromium.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP0-Qpus8HOy9aL0-sz%2BE0TNViqg76nFELjBnM0U8xXnsAsggA%40mail.gmail.com.
Darin Fisher
2017-08-08 22:51:35 UTC
Permalink
Post by Darin Fisher
Hi Sean,
Apologies for the delay. We know folks are eager for an official blog
post. Please see Devon's recent update
<https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs%5B276-300%5D> on
the matter.
Sorry, bad link. Try this instead:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/1SRvvnKCAgAJ

-Darin
Post by Darin Fisher
Thanks,
-Darin
Post by b***@gmail.com
Hey Darin,
Do you have a rough estimate as to when the blog will be posted?
There's a bit of a confusion in the market and some clients are some what
reluctant to believe the timeline without "official" announcement from
google.
Thanks.
-Sean
Yes, there will be a corresponding blog post up shortly.
-Darin
Hey Darin,
Are there any plans to post this information somewhere with a bit more
visibility, like the Chromium Blog, or the Google Online Security Blog?
I get the feeling not nearly as many developers and site operators are
subscribed to this mailing list as are following those blogs.
- Andrew
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
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
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.
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.
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.
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
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.
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
-
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.
Chrome 59 (Dev, Beta, Stable): 33 months validity (1023 days)
Chrome 60 (Dev, Beta, Stable): 27 months validity (837 days)
...
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/ch
romium.org/d/msgid/blink-dev/b6865ed5-c90d-4229-a523-58320e
3be6d4%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b6865ed5-c90d-4229-a523-58320e3be6d4%40chromium.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP0-QpsTUfXyBBBBOhfqW6nr4nXL7HwNG0hV70c-yQ74PrTCow%40mail.gmail.com.
d***@gmail.com
2017-08-09 19:21:57 UTC
Permalink
Hi Darin,

Some of the previous proposals identified shorter validity periods for
those certificates issued under the Symantec PKI after a certain date and
also identified dates when prior Symantec Domain and Enterprise data
couldn't be reused (primarily by the Managed CAs).

In the latest proposal, are there any limits on re-use of domain validation
data or on the validity periods for certificates issued under the existing
PKI by Symantec, or is this business as usual until Chrome 70?

Doug
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
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
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.
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.
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.
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
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.
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
-
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.
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)
...
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ddd8ea6a-9f70-4d15-9d55-4ee987602fb6%40chromium.org.
a***@chromium.org
2017-08-18 16:51:48 UTC
Permalink
Hi Doug,


The “Managed Partner Infrastructure
<https://docs.google.com/document/d/1Yd079EsKQ-QawTvWgjIfrCV6d0NNlwoS1ftB0MaJkBc/>”
description still contains limits on the re-use of domain validation data
and the validity periods associated with certificates that reuse this data.
The only changes made to this section are reducing the transition dates
from three dates to the two dates Symantec proposed.

Certificates that contain any data obtained using Symantec’s previous
validation procedures will be limited to 13 months in validity.
Certificates that contain fully-revalidated data, gathered under the
policies and practices of the Managed CA, may have their validity period up
to the maximum allowed by Chrome for all CAs.

-Devon
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f6744c2c-352b-4c31-b7b9-3e609c908c27%40chromium.org.
d***@gmail.com
2017-08-18 19:15:44 UTC
Permalink
Thanks for the reply Devon.

I see the 400 day requirement in the “Managed Partner Infrastructure
<https://docs.google.com/document/d/1Yd079EsKQ-QawTvWgjIfrCV6d0NNlwoS1ftB0MaJkBc/>”
description which relates to the Managed CA validity limits when re-using
Organizational information. I'm curious about certificates that continue
to be issued from the Symantec Infrastructure after the December 1st date.
Is that permitted, and if so what validation requirements and validity
limits apply?

Doug
Post by a***@chromium.org
Hi Doug,
The “Managed Partner Infrastructure
<https://docs.google.com/document/d/1Yd079EsKQ-QawTvWgjIfrCV6d0NNlwoS1ftB0MaJkBc/>”
description still contains limits on the re-use of domain validation data
and the validity periods associated with certificates that reuse this data.
The only changes made to this section are reducing the transition dates
from three dates to the two dates Symantec proposed.
Certificates that contain any data obtained using Symantec’s previous
validation procedures will be limited to 13 months in validity.
Certificates that contain fully-revalidated data, gathered under the
policies and practices of the Managed CA, may have their validity period up
to the maximum allowed by Chrome for all CAs.
-Devon
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6cfdb114-2974-49a2-be1d-2f9380c625a3%40chromium.org.
a***@chromium.org
2017-08-25 21:48:37 UTC
Permalink
Symantec has indicated that the new infrastructure will reach full issuance
capacity by December 1, 2017, and therefore, Chrome will no longer trust
newly issued certificates from the old infrastructure after this date.

As described in the Managed Partner Infrastructure
<https://docs.google.com/document/d/1Yd079EsKQ-QawTvWgjIfrCV6d0NNlwoS1ftB0MaJkBc/>
document, “Chrome will require that by 2017-12-01, all new
Symantec-chaining certificates be issued by independently operated
third-parties (aka “Managed CAs”). Chrome will implement a check,
on-or-after 2017-12-01, to enforce this by ensuring that the validated
certificate chain contain a whitelist of intermediates (independently
operated sub-CAs or the Managed CAs).” This code change will propagate
through the regular Chrome release window and will land in stable in early
2018.

Symantec should cease issuance from the old infrastructure by 2017-12-01 in
order to ensure that all newly issued certificates work in Chrome, and to
ensure that no subscriber is given a replacement certificate that will be
affected by this distrust.


-Devon
Post by d***@gmail.com
Thanks for the reply Devon.
I see the 400 day requirement in the “Managed Partner Infrastructure
<https://docs.google.com/document/d/1Yd079EsKQ-QawTvWgjIfrCV6d0NNlwoS1ftB0MaJkBc/>”
description which relates to the Managed CA validity limits when re-using
Organizational information. I'm curious about certificates that continue
to be issued from the Symantec Infrastructure after the December 1st date.
Is that permitted, and if so what validation requirements and validity
limits apply?
Doug
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4c1ea0ee-1e54-4839-95d6-b219df900ff8%40chromium.org.
c***@cem.me
2017-08-30 19:25:12 UTC
Permalink
Hi Devon,



I’d like to understand better how the trust above the whitelist you
mentioned would work. In the MPI document
<https://docs.google.com/document/d/1Yd079EsKQ-QawTvWgjIfrCV6d0NNlwoS1ftB0MaJkBc/>
it says, “The Managed CAs could be cross signed by an *agreed upon set* of
existing Symantec roots”, has that set already been agreed upon?


It looks like Akamai has already posted
<https://community.akamai.com/community/web-performance/blog/2017/08/29/google-symantec-subca-transition>
that the G5 and old 1024-bit Class3 are planned for support, I just haven’t
seen that information come from the Chrome Team. I’ll also note that
Mozilla has left the cross-signings “at Symantec’s discretion
<https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/>”
(if Mozilla is sticking with their Proposal document).
Post by a***@chromium.org
Symantec has indicated that the new infrastructure will reach full
issuance capacity by December 1, 2017, and therefore, Chrome will no longer
trust newly issued certificates from the old infrastructure after this
date.
As described in the Managed Partner Infrastructure
<https://docs.google.com/document/d/1Yd079EsKQ-QawTvWgjIfrCV6d0NNlwoS1ftB0MaJkBc/>
document, “Chrome will require that by 2017-12-01, all new
Symantec-chaining certificates be issued by independently operated
third-parties (aka “Managed CAs”). Chrome will implement a check,
on-or-after 2017-12-01, to enforce this by ensuring that the validated
certificate chain contain a whitelist of intermediates (independently
operated sub-CAs or the Managed CAs).” This code change will propagate
through the regular Chrome release window and will land in stable in early
2018.
Symantec should cease issuance from the old infrastructure by 2017-12-01
in order to ensure that all newly issued certificates work in Chrome, and
to ensure that no subscriber is given a replacement certificate that will
be affected by this distrust.
-Devon
Thanks for the reply Devon.
I see the 400 day requirement in the “
...
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9ce5f2cc-b417-42e7-b8fb-5ca58ef2e80c%40chromium.org.
Jeremy Rowley
2017-08-28 19:41:09 UTC
Permalink
Hi Devon - I posted some info about the transition to DigiCert a few days
ago. Do you have an eta on when Google might comment? We're very
interested in hearing your thoughts.

Thanks!
Jeremy
Post by d***@gmail.com
Thanks for the reply Devon.
I see the 400 day requirement in the “Managed Partner Infrastructure
<https://docs.google.com/document/d/1Yd079EsKQ-QawTvWgjIfrCV6d0NNlwoS1ftB0MaJkBc/>”
description which relates to the Managed CA validity limits when re-using
Organizational information. I'm curious about certificates that continue
to be issued from the Symantec Infrastructure after the December 1st date.
Is that permitted, and if so what validation requirements and validity
limits apply?
Doug
Post by a***@chromium.org
Hi Doug,
The “Managed Partner Infrastructure
<https://docs.google.com/document/d/1Yd079EsKQ-QawTvWgjIfrCV6d0NNlwoS1ftB0MaJkBc/>”
description still contains limits on the re-use of domain validation data
and the validity periods associated with certificates that reuse this data.
The only changes made to this section are reducing the transition dates
from three dates to the two dates Symantec proposed.
Certificates that contain any data obtained using Symantec’s previous
validation procedures will be limited to 13 months in validity.
Certificates that contain fully-revalidated data, gathered under the
policies and practices of the Managed CA, may have their validity period up
to the maximum allowed by Chrome for all CAs.
-Devon
--
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
To view this discussion on the web visit https://groups.google.com/a/
chromium.org/d/msgid/blink-dev/6cfdb114-2974-49a2-be1d-
2f9380c625a3%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6cfdb114-2974-49a2-be1d-2f9380c625a3%40chromium.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFK%3DoS97%3Divr5Q7VE2VHGtwKj3dz-pbmwmnQoFd%3DtOrtH-DmgA%40mail.gmail.com.
Ivan Ristic
2017-08-10 15:28:11 UTC
Permalink
Hi Darin,

Will some independently-operated Symantec sub-CAs be excluded from the
proposed lifetime restrictions, for example those listed on this
page: https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/
?
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
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
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.
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.
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.
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
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.
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
-
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.
Chrome 59 (Dev, Beta, Stable): 33 months validity (1023 days)
...
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b19de41c-aaf6-42ab-bb9d-7a98e3c2aa31%40chromium.org.
Ivan Ristic
2017-08-16 12:33:54 UTC
Permalink
Another question along the same lines: it's conceivable that there might
exist multiple trust paths from the leaf certificate, some of which lead to
Symantec roots and some of which don't. Any hints how a certificate might
be treated in this situation?
Post by d***@gmail.com
Hi Darin,
Will some independently-operated Symantec sub-CAs be excluded from the
https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/
symantec/ ?
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
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
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.
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.
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.
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
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.
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
-
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.
Chrome 59 (Dev, Beta, Stable): 33 months validity (1023 days)
...
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit https://groups.google.com/a/
chromium.org/d/msgid/blink-dev/b19de41c-aaf6-42ab-bb9d-
7a98e3c2aa31%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b19de41c-aaf6-42ab-bb9d-7a98e3c2aa31%40chromium.org?utm_medium=email&utm_source=footer>
.
--
Ivan
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANHgQ8HPpmXLSgR-q17gvdKz30PY4CAyEET1db-e%3DyJLjBy%2BHA%40mail.gmail.com.
a***@chromium.org
2017-08-18 16:56:01 UTC
Permalink
Hi Ivan,


Under the current, existing Symantec infrastructure and PKI, there are no
disclosed paths that transit multiple CA operators and are trusted or
intended to be used for Web PKI issuance, thus this scenario is purely
hypothetical at present.

RFC 5280 explicitly does not set out requirements on the selection of
certification paths, and as RFC 4158 informationally documents, there are a
variety of considerations in the selection of path, which can vary based on
client configuration, operational profile, and network capabilities. As
such, the most consistent answer is the simplest answer: All newly issued
certificates that have at least one certificate path that terminates in a
Symantec-operated root should be expected to be subject to these
requirements. Similarly, all existing certificates that have at least one
certificate path that terminates in a Symantec-operated CA will have trust
removed according to the schedule provided.

Note that because revocation may be examined during certificate path
building or during certificate path verification (after the path has been
selected), revocation of any existing cross-certifications is not a
sufficient mitigation. For the avoidance of confusion, there should be no
impact if there are no certification paths that terminate or transit a
Symantec-operated CA.

This means that it is largely dependent upon how Symantec’s old
infrastructure is phased out, both by DigiCert and the broader community,
and how migration to the new infrastructure is managed. For example, if
Symantec’s old infrastructure cross-signs any new roots stood up as part of
a Managed Partner transition, clients may terminate in either the old or
new root, but would consistently have the policies (or exceptions) applied.
However, if both Symantec and DigiCert were to cross-certify such
infrastructure, or if Symantec’s old or new roots were used to certify
existing DigiCert infrastructure, path non-determinism would be introduced
that would impact DigiCert’s customers. As DigiCert and Symantec have not
provided technical details to the community as to their planned transition,
it’s not possible at this time to describe client behaviour. To minimize
risk, we encourage both organizations to share their plans prior to
implementing and to solicit wide feedback, both from the broader Web PKI
community and specifically from trust store operators, to minimize the
overall risk to the ecosystem, browser users, and their customers.

-Devon
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7925cb77-8765-4f26-b428-24ec7e71d4c1%40chromium.org.
Jeremy Rowley
2017-08-18 17:51:27 UTC
Permalink
Sorry we haven't provided those details yet Devon. I plan to post the plan
to the Mozilla list soon. Is it okay if I only post it there? I know that
earlier in the thread there was an interest in consolidating the
conversation to a single location.
Post by a***@chromium.org
Hi Ivan,
Under the current, existing Symantec infrastructure and PKI, there are no
disclosed paths that transit multiple CA operators and are trusted or
intended to be used for Web PKI issuance, thus this scenario is purely
hypothetical at present.
RFC 5280 explicitly does not set out requirements on the selection of
certification paths, and as RFC 4158 informationally documents, there are a
variety of considerations in the selection of path, which can vary based on
client configuration, operational profile, and network capabilities. As
such, the most consistent answer is the simplest answer: All newly issued
certificates that have at least one certificate path that terminates in a
Symantec-operated root should be expected to be subject to these
requirements. Similarly, all existing certificates that have at least one
certificate path that terminates in a Symantec-operated CA will have trust
removed according to the schedule provided.
Note that because revocation may be examined during certificate path
building or during certificate path verification (after the path has been
selected), revocation of any existing cross-certifications is not a
sufficient mitigation. For the avoidance of confusion, there should be no
impact if there are no certification paths that terminate or transit a
Symantec-operated CA.
This means that it is largely dependent upon how Symantec’s old
infrastructure is phased out, both by DigiCert and the broader community,
and how migration to the new infrastructure is managed. For example, if
Symantec’s old infrastructure cross-signs any new roots stood up as part of
a Managed Partner transition, clients may terminate in either the old or
new root, but would consistently have the policies (or exceptions) applied.
However, if both Symantec and DigiCert were to cross-certify such
infrastructure, or if Symantec’s old or new roots were used to certify
existing DigiCert infrastructure, path non-determinism would be introduced
that would impact DigiCert’s customers. As DigiCert and Symantec have not
provided technical details to the community as to their planned transition,
it’s not possible at this time to describe client behaviour. To minimize
risk, we encourage both organizations to share their plans prior to
implementing and to solicit wide feedback, both from the broader Web PKI
community and specifically from trust store operators, to minimize the
overall risk to the ecosystem, browser users, and their customers.
-Devon
--
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
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7925cb77-8765-4f26-b428-24ec7e71d4c1%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7925cb77-8765-4f26-b428-24ec7e71d4c1%40chromium.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFK%3DoS8zh2924JqwY6%2BXve_g6kUgq7dFExLar9_1NTpG41W4Mw%40mail.gmail.com.
a***@chromium.org
2017-08-25 21:22:40 UTC
Permalink
Hi Jeremy,

Thanks for the heads up. We think that continuing the conversation of
DigiCert and Symantec’s transition on the M.D.S.P. thread is the best
course of action. We’ve seen your recent posts there and will participate
in that discussion with technical input on the transition plan as details
solidify.

-Devon
Post by Jeremy Rowley
Sorry we haven't provided those details yet Devon. I plan to post the plan
to the Mozilla list soon. Is it okay if I only post it there? I know that
earlier in the thread there was an interest in consolidating the
conversation to a single location.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8908a19c-8eee-4f66-8b43-e17f43979e46%40chromium.org.
Ivan Ristic
2017-08-25 06:15:24 UTC
Permalink
Thank you for those clarifications. That makes sense.

Assuming the dates don't change, I propose that we collectively adopt March
1st 2018 and September 1st 2018 as the two deadlines the organisation need
to meet to ensure continued operation. They're easier to remember and also
provide an additional margin of safety over the "real" cutoff dates.

If anyone's interested, that's the advice I've implemented in Hardenize:
https://www.hardenize.com/report/verisign.com#www_certs
(there's no full path building at the moment but it will be added soon,
after the UI is updated).
Post by a***@chromium.org
Hi Ivan,
Under the current, existing Symantec infrastructure and PKI, there are no
disclosed paths that transit multiple CA operators and are trusted or
intended to be used for Web PKI issuance, thus this scenario is purely
hypothetical at present.
RFC 5280 explicitly does not set out requirements on the selection of
certification paths, and as RFC 4158 informationally documents, there are a
variety of considerations in the selection of path, which can vary based on
client configuration, operational profile, and network capabilities. As
such, the most consistent answer is the simplest answer: All newly issued
certificates that have at least one certificate path that terminates in a
Symantec-operated root should be expected to be subject to these
requirements. Similarly, all existing certificates that have at least one
certificate path that terminates in a Symantec-operated CA will have trust
removed according to the schedule provided.
Note that because revocation may be examined during certificate path
building or during certificate path verification (after the path has been
selected), revocation of any existing cross-certifications is not a
sufficient mitigation. For the avoidance of confusion, there should be no
impact if there are no certification paths that terminate or transit a
Symantec-operated CA.
This means that it is largely dependent upon how Symantec’s old
infrastructure is phased out, both by DigiCert and the broader community,
and how migration to the new infrastructure is managed. For example, if
Symantec’s old infrastructure cross-signs any new roots stood up as part of
a Managed Partner transition, clients may terminate in either the old or
new root, but would consistently have the policies (or exceptions) applied.
However, if both Symantec and DigiCert were to cross-certify such
infrastructure, or if Symantec’s old or new roots were used to certify
existing DigiCert infrastructure, path non-determinism would be introduced
that would impact DigiCert’s customers. As DigiCert and Symantec have not
provided technical details to the community as to their planned transition,
it’s not possible at this time to describe client behaviour. To minimize
risk, we encourage both organizations to share their plans prior to
implementing and to solicit wide feedback, both from the broader Web PKI
community and specifically from trust store operators, to minimize the
overall risk to the ecosystem, browser users, and their customers.
-Devon
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit https://groups.google.com/a/
chromium.org/d/msgid/blink-dev/7925cb77-8765-4f26-b428-
24ec7e71d4c1%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7925cb77-8765-4f26-b428-24ec7e71d4c1%40chromium.org?utm_medium=email&utm_source=footer>
.
--
Ivan
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANHgQ8HGZN5qQYPeaqDbEN-_2UsW99BxtZZMVtTN9PrnC8K1tA%40mail.gmail.com.
a***@chromium.org
2017-08-18 16:53:14 UTC
Permalink
Hi Ivan,

The independently audited and operated sub CAs that have been disclosed to
us will be exempted from the certificate lifetime restrictions. These CAs
are those listed on the page you linked under “Excluded Sub-CAs
<https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/#Excluded-Sub_CAs>
”.

-Devon
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fb189dcb-2c82-4ae1-acf7-87f9918731e7%40chromium.org.
1***@gmail.com
2018-08-01 01:48:04 UTC
Permalink
What does this mean
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/354a989f-131e-4f62-9647-e5c92ed69937%40chromium.org.
j***@gmail.com
2018-10-06 00:52:54 UTC
Permalink
Can you send me a Simplified definitions?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1362761c-32ff-4f38-8d28-ae7a039de895%40chromium.org.
Continue reading on narkive:
Loading...