[blink-dev] Intent to Deprecate and Remove: Trust in existing Symantec-issued Certificates

[Ryan Sleevi]

Note: Historically, the Google Chrome team has not used the Blink Process
<http://www.chromium.org/blink#new-features> for Certificate
Authority-related security issues, of which there have been a number over
the years. However, we are interested in exploring using this process for
such changes, as it provides a greater degree of transparency and public
participation. Based on the level of participation and feedback we receive,
we may consider using this for the future. However, as CA-related security
incidents may require immediate response to protect users, this should not
be seen as a guarantee that this process can be used in future incident
responses.

Primary eng (and PM) emails:

***@chromium.org ***@chromium.org

Summary

Since January 19, the Google Chrome team has been investigating a series of
failures by Symantec Corporation to properly validate certificates. Over
the course of this investigation, the explanations provided by Symantec
have revealed a continually increasing scope of misissuance with each set
of questions from members of the Google Chrome team; an initial set of
reportedly 127 certificates has expanded to include at least 30,000
certificates, issued over a period spanning several years. This is also
coupled with a series of failures following the previous set of misissued
certificates from Symantec
<https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html>,
causing us to no longer have confidence in the certificate issuance
policies and practices of Symantec over the past several years. To restore
confidence and security of our users, we propose the following steps:

-

A reduction in the accepted validity period of newly issued
Symantec-issued certificates to nine months or less, in order to minimize
any impact to Google Chrome users from any further misissuances that may
arise.
-

An incremental distrust, spanning a series of Google Chrome releases, of
all currently-trusted Symantec-issued certificates, requiring they be
revalidated and replaced.
-

Removal of recognition of the Extended Validation status of Symantec
issued certificates, until such a time as the community can be assured in
the policies and practices of Symantec, but no sooner than one year.


Motivation

As captured in Chrome’s Root Certificate Policy
<https://www.chromium.org/Home/chromium-security/root-ca-policy>, root
certificate authorities are expected to perform a number of critical
functions commensurate with the trust granted to them. This includes
properly ensuring that domain control validation is performed for server
certificates, to audit logs frequently for evidence of unauthorized
issuance, and to protect their infrastructure in order to minimize the
ability for the issuance of fraudulent certs.

On the basis of the details publicly provided by Symantec, we do not
believe that they have properly upheld these principles, and as such, have
created significant risk for Google Chrome users. Symantec allowed at least
four parties access to their infrastructure in a way to cause certificate
issuance, did not sufficiently oversee these capabilities as required and
expected, and when presented with evidence of these organizations’ failure
to abide to the appropriate standard of care, failed to disclose such
information in a timely manner or to identify the significance of the
issues reported to them.

These issues, and the corresponding failure of appropriate oversight,
spanned a period of several years, and were trivially identifiable from the
information publicly available or that Symantec shared.

The full disclosure of these issues has taken more than a month. Symantec
has failed to provide timely updates to the community regarding these
issues. Despite having knowledge of these issues, Symantec has repeatedly
failed to proactively disclose them. Further, even after issues have
become public, Symantec failed to provide the information that the
community required to assess the significance of these issues until they
had been specifically questioned. The proposed remediation steps offered by
Symantec have involved relying on known-problematic information or using
practices insufficient to provide the level of assurance required under the
Baseline Requirements and expected by the Chrome Root CA Policy.

In January 2015, Symantec-issued certificates represented more than 30% of
the valid certificates by volume. While changes in the CA ecosystem have
seen that share decrease over the past two years, there is still a
significant compatibility risk for an immediate and complete distrust.
Further, due to overall TLS ecosystem concerns, we understand that it may
take non-trivial effort for some site operators to find suitable solutions,
as the need to support older devices may necessitate the use of particular
CAs, meaning that distrust of new certificates also has significant
compatibility risk.

To balance the compatibility risks versus the security risks, we propose a
gradual distrust of all existing Symantec-issued certificates, requiring
that they be replaced over time with new, fully revalidated certificates,
compliant with the current Baseline Requirements. This will be accomplished
by gradually decreasing the ‘maximum age’ of Symantec-issued certificates
over a series of releases, distrusting certificates whose validity period
(the difference of notBefore to notAfter) exceeds the specified maximum.

The proposed schedule is as follows:

Chrome 59 (Dev, Beta, Stable): 33 months validity (1023 days)

Chrome 60 (Dev, Beta, Stable): 27 months validity (837 days)

Chrome 61 (Dev, Beta, Stable): 21 months validity (651 days)

Chrome 62 (Dev, Beta, Stable): 15 months validity (465 days)

Chrome 63 (Dev, Beta): 9 months validity (279 days)

Chrome 63 (Stable): 15 months validity (465 days)

Chrome 64 (Dev, Beta, Stable): 9 months validity (279 days)

The proposed schedule attempts to avoid making changes in Chrome 63 Stable,
as that would be released during the winter holiday production freeze many
organizations undergo. This is solely to reduce disruption for site
operators and users, and attempts to resume with Chrome 64 following the
holiday season. Further, the practical impact of the changes in Chrome 59
and 60 are relatively minimal, due to many of the certificates issued
during that period of time being issued using SHA-1, which is no longer
supported for certificates in Chrome.

In addition, we propose to require that all newly-issued certificates must
have validity periods of no greater than 9 months (279 days) in order to be
trusted in Google Chrome, effective Chrome 61. This ensures that the risk
of any further misissuance is, at most, limited to nine months, and more
importantly, that if any further action is warranted or necessary, that the
entire ecosystem can migrate within that time period, thus minimizing the
risk of further compatibility issues.

By combining these two steps, we can ensure that the level of assurance in
Symantec-issued certificates is able to match what is expected by Google
Chrome and the ecosystem, and that the risks posed both from past and
possible future misissuance is minimized as much as possible.

Given the nature of these issues, and the multiple failures of Symantec to
ensure that the level of assurance provided by their certificates meets the
requirements of the Baseline Requirements or Extended Validation
Guidelines, we no longer have the confidence necessary in order to grant
Symantec-issued certificates the “Extended Validation” status. As
documented with both the current and past misissuance, Symantec failed to
ensure that the organizational attributes, displayed within the address bar
for such certificates, meet the level of quality and validation required
for such display. Therefore, we propose to remove such indicators,
effective immediately, until Symantec is able to demonstrate the level of
sustained compliance necessary to grant such trust, which will be a period
no less than a year. After such time has passed, we will consider requests
from Symantec to re-evaluate this position, in collaboration with the
broader Chromium community.

Compatibility and Interoperability Risk

As with any reduction in trust in a Certificate Authority, this poses a
non-trivial degree of compatibility risk. This is because site operators
desire to have their certificates recognized in all client browsers, and if
one or more browsers fail to trust a given CA, this is prevented from
happening.

On the other hand, all site operators expect that certificates will only be
issued for their domains upon their request, and the failure to have that
assurance significantly undermines the security of HTTPS for both site
operators and users.

This compatibility risk is especially high for Symantec-issued
certificates, due to their acquisition of some of the first CAs, such as
Thawte, Verisign, and Equifax, which are some of the most widely supported
CAs. Distrusting such CAs creates further difficulty for providing secure
connections to both old and new devices alike, due to the need to ensure
the CA a site operator uses is recognized across these devices.

Further, the immediate distrust of a CA, as has been necessary in the past,
can significantly impact both site operators and users. Site operators are
forced to acquire certificates from other CAs, without having the
opportunity and time to research which CAs best meet their needs, and users
encounter a substantial number of errors until those site operators act,
conditioning them to ignore security warnings. In the event that only a
single browser distrusts such a CA, the error is often seen as the
browser’s fault, despite it being a failure of the CA to provide the
necessary level of assurance, and the site operator to respond in a timely
fashion.

Assessing the compatibility risk with both Edge and Safari is difficult,
because neither Microsoft nor Apple communicate publicly about their
changes in trust prior to enacting them.

While Mozilla conducts their discussions regarding Certificate Authorities
in public, and were the first to be alerted of these latest issues, they
have not yet begun discussion of the next steps to how best to protect
their users. Our hope is that this proposal may be seen as one that
appropriately balances the security and compatibility risks with the needs
of site operators, browsers, and users, and we welcome all feedback.

Alternative implementation suggestion for web developers

This proposal allows for web developers to continue to use Symantec issued
certificates, but will see their validity period reduced. This ensure that
web developers are aware of the risk and potential of future distrust of
Symantec-issued certificates, should additional misissuance events occur,
while also allowing them the flexibility to continue using such
certificates should it be necessary.

Usage information from UseCounter
<https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>
:
For a variety of non-technical reasons, we do not currently instrument the
usage of CAs. Further, few public metrics exist for intersecting usage
information with the validity period, since only certificates valid greater
than nine months will be affected outside of their normal replacement
cycle. From Mozilla Firefox’s Telemetry, we know that Symantec issued
certificates are responsible for 42% of certificate validations. However,
this number is not strictly an indicator for impact, as this number is
biased towards counting certificates for heavily-trafficked sites, and
whose issuance is fully automated and/or whose validity periods will be
unaffected, thus significantly overstating impact. By phasing such changes
in over a series of releases, we aim to minimize the impact any given
release poses, while still continually making progress towards restoring
the necessary level of security to ensure Symantec issued certificates are
as trustworthy as certificates from other CAs.

[Vincent Lynch]

"Therefore, we propose to remove [EV] indicators, effective immediately,"

Two questions about this:

1. Can you clarify what "effective immediately" means? Will this occur with
the next stable release of Chrome? Or will an update be pushed to the
current stable version?

2. Can you confirm that the removal of EV indicators will affect *all*
Symantec-issued EV certificates, regardless of their compliance with
Chrome's reduced validity schedule?

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)
Chrome 62 (Dev, Beta, Stable): 15 months validity (465 days)
Chrome 63 (Dev, Beta): 9 months validity (279 days)
Chrome 63 (Stable): 15 months validity (465 days)
Chrome 64 (Dev, Beta, Stable): 9 months validity (279 days)
The proposed schedule attempts to avoid making changes in Chrome 63
Stable, as that would be released during the winter holiday production
freeze many organizations undergo. This is solely to reduce disruption for
site operators and users, and attempts to resume with Chrome 64 following
the holiday season. Further, the practical impact of the changes in Chrome
59 and 60 are relatively minimal, due to many of the certificates issued
during that period of time being issued using SHA-1, which is no longer
supported for certificates in Chrome.
In addition, we propose to require that all newly-issued certificates must
have validity periods of no greater than 9 months (279 days) in order to be
trusted in Google Chrome, effective Chrome 61. This ensures that the risk
of any further misissuance is, at most, limited to nine months, and more
importantly, that if any further action is warranted or necessary, that the
entire ecosystem can migrate within that time period, thus minimizing the
risk of further compatibility issues.
By combining these two steps, we can ensure that the level of assurance in
Symantec-issued certificates is able to match what is expected by Google
Chrome and the ecosystem, and that the risks posed both from past and
possible future misissuance is minimized as much as possible.
Given the nature of these issues, and the multiple failures of Symantec to
ensure that the level of assurance provided by their certificates meets the
requirements of the Baseline Requirements or Extended Validation
Guidelines, we no longer have the confidence necessary in order to grant
Symantec-issued certificates the “Extended Validation” status. As
documented with both the current and past misissuance, Symantec failed to
ensure that the organizational attributes, displayed within the address bar
for such certificates, meet the level of quality and validation required
for such display. Therefore, we propose to remove such indicators,
effective immediately, until Symantec is able to demonstrate the level of
sustained compliance necessary to grant such trust, which will be a period
no less than a year. After such time has passed, we will consider requests
from Symantec to re-evaluate this position, in collaboration with the
broader Chromium community.
Compatibility and Interoperability Risk
As with any reduction in trust in a Certificate Authority, this poses a
non-trivial degree of compatibility risk. This is because site operators
desire to have their certificates recognized in all client browsers, and if
one or more browsers fail to trust a given CA, this is prevented from
happening.
On the other hand, all site operators expect that certificates will only
be issued for their domains upon their request, and the failure to have
that assurance significantly undermines the security of HTTPS for both site
operators and users.
This compatibility risk is especially high for Symantec-issued
certificates, due to their acquisition of some of the first CAs, such as
Thawte, Verisign, and Equifax, which are some of the most widely supported
CAs. Distrusting such CAs creates further difficulty for providing secure
connections to both old and new devices alike, due to the need to ensure
the CA a site operator uses is recognized across these devices.
Further, the immediate distrust of a CA, as has been necessary in the
past, can significantly impact both site operators and users. Site
operators are forced to acquire certificates from other CAs, without having
the opportunity and time to research which CAs best meet their needs, and
users encounter a substantial number of errors until those site operators
act, conditioning them to ignore security warnings. In the event that only
a single browser distrusts such a CA, the error is often seen as the
browser’s fault, despite it being a failure of the CA to provide the
necessary level of assurance, and the site operator to respond in a timely
fashion.
Assessing the compatibility risk with both Edge and Safari is difficult,
because neither Microsoft nor Apple communicate publicly about their
changes in trust prior to enacting them.
While Mozilla conducts their discussions regarding Certificate Authorities
in public, and were the first to be alerted of these latest issues, they
have not yet begun discussion of the next steps to how best to protect
their users. Our hope is that this proposal may be seen as one that
appropriately balances the security and compatibility risks with the needs
of site operators, browsers, and users, and we welcome all feedback.
Alternative implementation suggestion for web developers
This proposal allows for web developers to continue to use Symantec issued
certificates, but will see their validity period reduced. This ensure that
web developers are aware of the risk and potential of future distrust of
Symantec-issued certificates, should additional misissuance events occur,
while also allowing them the flexibility to continue using such
certificates should it be necessary.
Usage information from UseCounter
<https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>
For a variety of non-technical reasons, we do not currently instrument the
usage of CAs. Further, few public metrics exist for intersecting usage
information with the validity period, since only certificates valid greater
than nine months will be affected outside of their normal replacement
cycle. From Mozilla Firefox’s Telemetry, we know that Symantec issued
certificates are responsible for 42% of certificate validations. However,
this number is not strictly an indicator for impact, as this number is
biased towards counting certificates for heavily-trafficked sites, and
whose issuance is fully automated and/or whose validity periods will be
unaffected, thus significantly overstating impact. By phasing such changes
in over a series of releases, we aim to minimize the impact any given
release poses, while still continually making progress towards restoring
the necessary level of security to ensure Symantec issued certificates are
as trustworthy as certificates from other CAs.

[Ryan]

"Therefore, we propose to remove [EV] indicators, effective immediately,"
1. Can you clarify what "effective immediately" means? Will this occur
with the next stable release of Chrome? Or will an update be pushed to the
current stable version?

As this is a security related incident, the proposal is to land this in
Trunk and update Dev and Beta to reflect this, treating this as "Medium"
severity per https://www.chromium.org/developers/severity-guidelines by
treating this as an address bar spoofing issue.

2. Can you confirm that the removal of EV indicators will affect *all*
Symantec-issued EV certificates, regardless of their compliance with
Chrome's reduced validity schedule?

Correct. Extended Validation certificates are recognition of the processes
and controls related to validating the information in the certificates is
accurate and correct. The issues highlighted have undermined that
confidence. The validity issue is separate and mitigates future issues that
may arise or be discovered.

[j***@valu.fi]

Post by Ryan

Post by Vincent Lynch
1. Can you clarify what "effective immediately" means? Will this occur
with the next stable release of Chrome? Or will an update be pushed to the
current stable version?

As this is a security related incident, the proposal is to land this in
Trunk and update Dev and Beta to reflect this, treating this as "Medium"
severity per https://www.chromium.org/developers/severity-guidelines by
treating this as an address bar spoofing issue.

Post by Vincent Lynch
2. Can you confirm that the removal of EV indicators will affect *all*
Symantec-issued EV certificates, regardless of their compliance with
Chrome's reduced validity schedule?

Correct. Extended Validation certificates are recognition of the processes
and controls related to validating the information in the certificates is
accurate and correct. The issues highlighted have undermined that
confidence. The validity issue is separate and mitigates future issues that
may arise or be discovered.

So, does this mean that e.g. paypal.com will lose its EV status? Doesn't
this introduce whole new possibilities for fake/spoof Paypal websites as
the original site doesn't have EV status anymore?

[Ryan Sleevi]

Post by j***@valu.fi
So, does this mean that e.g. paypal.com will lose its EV status?

Yes

[a***@gmail.com]

It appears that PayPal <https://www.paypal.com/> has not yet lost its EV
status, as of this writing.

Has it been special-cased? If yes, why? If not, then how is it still able
to display the EV chip?

By comparison, Bank of America <https://www.bankofamerica.com/>, and even
Symantec <https://www.symantec.com/> itself, lost their EV status in Chrome
immediately after this announcement.

Post by j***@valu.fi
So, does this mean that e.g. paypal.com will lose its EV status?

Yes

[PhistucK]

1. Note that this intent was not approved yet, so no action has been taken
yet.
2. Even if this intent is approved, the EV indication will only be lost
once Chrome 58 (or Chrome 59? I forget) is released.


☆*PhistucK*

Post by a***@gmail.com
It appears that PayPal <https://www.paypal.com/> has not yet lost its EV
status, as of this writing.
Has it been special-cased? If yes, why? If not, then how is it still able
to display the EV chip?
By comparison, Bank of America <https://www.bankofamerica.com/>, and even
Symantec <https://www.symantec.com/> itself, lost their EV status in
Chrome immediately after this announcement.

Post by j***@valu.fi
So, does this mean that e.g. paypal.com will lose its EV status?

Yes

--
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

[a***@gmail.com]

Can somebody explain these?

More specifically, why does Firefox still display the EV chip on BoA, and
Symantec, while Chrome stopped displaying the chip almost immediately after
I read this post when it was first shared.

Both Chrome and Firefox display the chip on PayPal. All three sites use
Symantec EV certs.

Post by PhistucK
1. Note that this intent was not approved yet, so no action has been taken
yet.
2. Even if this intent is approved, the EV indication will only be lost
once Chrome 58 (or Chrome 59? I forget) is released.
☆*PhistucK*

Post by a***@gmail.com
It appears that PayPal <https://www.paypal.com/> has not yet lost its EV
status, as of this writing.
Has it been special-cased? If yes, why? If not, then how is it still able
to display the EV chip?
By comparison, Bank of America <https://www.bankofamerica.com/>, and
even Symantec <https://www.symantec.com/> itself, lost their EV status
in Chrome immediately after this announcement.

Post by j***@valu.fi
So, does this mean that e.g. paypal.com will lose its EV status?

Yes

--
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

[c***@free.fr]

There's another case I cannot explain, comparing two French banks both use
certificates issued by Symantec Class 3 EV SSL CA - G3, one shows EV status
contrary to the other one (In Firefox both are considered EV) the only
obvious difference is the number of CT logs in which the certificate is
recorded.

<Loading Image...>

<Loading Image...>

[PhistucK]

Bank Of America has this note in the Developer Tools -
"The connection to this site uses a strong protocol (TLS 1.2), an obsolete
key exchange (RSA), and a strong cipher (AES_256_GCM)."
Note the "obsolete" part. I think it might affect the indication...
And it has two certificate transparency log entries.

Not sure regarding Symantec, though. It has two certificate transparency
log entries (one by Symantec and one by Google). Weird.

PayPal has three certificate transparency entries (Symantec, Google,
Google).


☆*PhistucK*

Post by a***@gmail.com
Can somebody explain these?
More specifically, why does Firefox still display the EV chip on BoA, and
Symantec, while Chrome stopped displaying the chip almost immediately after
I read this post when it was first shared.
Both Chrome and Firefox display the chip on PayPal. All three sites use
Symantec EV certs.

Post by PhistucK
1. Note that this intent was not approved yet, so no action has been
taken yet.
2. Even if this intent is approved, the EV indication will only be lost
once Chrome 58 (or Chrome 59? I forget) is released.
☆*PhistucK*

Post by a***@gmail.com
It appears that PayPal <https://www.paypal.com/> has not yet lost its
EV status, as of this writing.
Has it been special-cased? If yes, why? If not, then how is it still
able to display the EV chip?
By comparison, Bank of America <https://www.bankofamerica.com/>, and
even Symantec <https://www.symantec.com/> itself, lost their EV status
in Chrome immediately after this announcement.

Post by j***@valu.fi
So, does this mean that e.g. paypal.com will lose its EV status?

Yes

--
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

--

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

[Ryan Sleevi]

Post by a***@gmail.com
Can somebody explain these?
More specifically, why does Firefox still display the EV chip on BoA, and
Symantec, while Chrome stopped displaying the chip almost immediately after
I read this post when it was first shared.
Both Chrome and Firefox display the chip on PayPal. All three sites use
Symantec EV certs.

This is a separate bug related to how Symantec encodes its EV status in a
certificate and how Chrome recognizes that EV status. See and star
https://bugs.chromium.org/p/chromium/issues/detail?id=705285 for further
details.

[Ankit Pati]

Thank you for the clarification.

Post by a***@gmail.com
Can somebody explain these?
More specifically, why does Firefox still display the EV chip on BoA, and
Symantec, while Chrome stopped displaying the chip almost immediately after
I read this post when it was first shared.
Both Chrome and Firefox display the chip on PayPal. All three sites use
Symantec EV certs.
This is a separate bug related to how Symantec encodes its EV status in a
certificate and how Chrome recognizes that EV status. See and star
https://bugs.chromium.org/p/chromium/issues/detail?id=705285 for further
details.

[k***@ankuraconsulting.com]

Can you please clarify if any related CAs are affected, such as GeoTrust
and Thawte, are affected?

Post by Ryan Sleevi
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)
Chrome 62 (Dev, Beta, Stable): 15 months validity (465 days)
Chrome 63 (Dev, Beta): 9 months validity (279 days)
Chrome 63 (Stable): 15 months validity (465 days)
Chrome 64 (Dev, Beta, Stable): 9 months validity (279 days)
The proposed schedule attempts to avoid making changes in Chrome 63
Stable, as that would be released during the winter holiday production
freeze many organizations undergo. This is solely to reduce disruption for
site operators and users, and attempts to resume with Chrome 64 following
the holiday season. Further, the practical impact of the changes in Chrome
59 and 60 are relatively minimal, due to many of the certificates issued
during that period of time being issued using SHA-1, which is no longer
supported for certificates in Chrome.
In addition, we propose to require that all newly-issued certificates must
have validity periods of no greater than 9 months (279 days) in order to be
trusted in Google Chrome, effective Chrome 61. This ensures that the risk
of any further misissuance is, at most, limited to nine months, and more
importantly, that if any further action is warranted or necessary, that the
entire ecosystem can migrate within that time period, thus minimizing the
risk of further compatibility issues.
By combining these two steps, we can ensure that the level of assurance in
Symantec-issued certificates is able to match what is expected by Google
Chrome and the ecosystem, and that the risks posed both from past and
possible future misissuance is minimized as much as possible.
Given the nature of these issues, and the multiple failures of Symantec to
ensure that the level of assurance provided by their certificates meets the
requirements of the Baseline Requirements or Extended Validation
Guidelines, we no longer have the confidence necessary in order to grant
Symantec-issued certificates the “Extended Validation” status. As
documented with both the current and past misissuance, Symantec failed to
ensure that the organizational attributes, displayed within the address bar
for such certificates, meet the level of quality and validation required
for such display. Therefore, we propose to remove such indicators,
effective immediately, until Symantec is able to demonstrate the level of
sustained compliance necessary to grant such trust, which will be a period
no less than a year. After such time has passed, we will consider requests
from Symantec to re-evaluate this position, in collaboration with the
broader Chromium community.
Compatibility and Interoperability Risk
As with any reduction in trust in a Certificate Authority, this poses a
non-trivial degree of compatibility risk. This is because site operators
desire to have their certificates recognized in all client browsers, and if
one or more browsers fail to trust a given CA, this is prevented from
happening.
On the other hand, all site operators expect that certificates will only
be issued for their domains upon their request, and the failure to have
that assurance significantly undermines the security of HTTPS for both site
operators and users.
This compatibility risk is especially high for Symantec-issued
certificates, due to their acquisition of some of the first CAs, such as
Thawte, Verisign, and Equifax, which are some of the most widely supported
CAs. Distrusting such CAs creates further difficulty for providing secure
connections to both old and new devices alike, due to the need to ensure
the CA a site operator uses is recognized across these devices.
Further, the immediate distrust of a CA, as has been necessary in the
past, can significantly impact both site operators and users. Site
operators are forced to acquire certificates from other CAs, without having
the opportunity and time to research which CAs best meet their needs, and
users encounter a substantial number of errors until those site operators
act, conditioning them to ignore security warnings. In the event that only
a single browser distrusts such a CA, the error is often seen as the
browser’s fault, despite it being a failure of the CA to provide the
necessary level of assurance, and the site operator to respond in a timely
fashion.
Assessing the compatibility risk with both Edge and Safari is difficult,
because neither Microsoft nor Apple communicate publicly about their
changes in trust prior to enacting them.
While Mozilla conducts their discussions regarding Certificate Authorities
in public, and were the first to be alerted of these latest issues, they
have not yet begun discussion of the next steps to how best to protect
their users. Our hope is that this proposal may be seen as one that
appropriately balances the security and compatibility risks with the needs
of site operators, browsers, and users, and we welcome all feedback.
Alternative implementation suggestion for web developers
This proposal allows for web developers to continue to use Symantec issued
certificates, but will see their validity period reduced. This ensure that
web developers are aware of the risk and potential of future distrust of
Symantec-issued certificates, should additional misissuance events occur,
while also allowing them the flexibility to continue using such
certificates should it be necessary.
Usage information from UseCounter
<https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>
For a variety of non-technical reasons, we do not currently instrument the
usage of CAs. Further, few public metrics exist for intersecting usage
information with the validity period, since only certificates valid greater
than nine months will be affected outside of their normal replacement
cycle. From Mozilla Firefox’s Telemetry, we know that Symantec issued
certificates are responsible for 42% of certificate validations. However,
this number is not strictly an indicator for impact, as this number is
biased towards counting certificates for heavily-trafficked sites, and
whose issuance is fully automated and/or whose validity periods will be
unaffected, thus significantly overstating impact. By phasing such changes
in over a series of releases, we aim to minimize the impact any given
release poses, while still continually making progress towards restoring
the necessary level of security to ensure Symantec issued certificates are
as trustworthy as certificates from other CAs.

[Ryan Sleevi]

Post by k***@ankuraconsulting.com
Can you please clarify if any related CAs are affected, such as GeoTrust
and Thawte, are affected?

All Symantec issued certificates. GeoTrust and Thawte are CAs operated by
Symantec, simply afforded different branding.

While this list may need to be updated for some recently created roots,
https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/README.md
may accurately capture the state of impact

[g***@garyzhu.net]

Great initial question from Ankura, just want to be double-sure:

Google is using SSL certificate issued by "Google Internet Authority G2"
with root CA "GeoTrust Global CA", so this is also affected (initially the
reduced expiration date) ?

I understand completely that GeoTrust is a subsidiary of Symantec, but it
is different from the certificate issued directly from Symantec, such as
the one on www.bankofamerica.com, its EV status is immediately affected.

Post by Ryan Sleevi

Post by k***@ankuraconsulting.com
Can you please clarify if any related CAs are affected, such as GeoTrust
and Thawte, are affected?

All Symantec issued certificates. GeoTrust and Thawte are CAs operated by
Symantec, simply afforded different branding.
While this list may need to be updated for some recently created roots,
https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/README.md
may accurately capture the state of impact

[Ryan Sleevi]

Post by g***@garyzhu.net
Google is using SSL certificate issued by "Google Internet Authority G2"
with root CA "GeoTrust Global CA", so this is also affected (initially the
reduced expiration date) ?

Please see
https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/README.md

Post by g***@garyzhu.net
I understand completely that GeoTrust is a subsidiary of Symantec, but it
is different from the certificate issued directly from Symantec, such as
the one on www.bankofamerica.com, its EV status is immediately affected.

As noted in
https://www.symantec.com/content/en/us/about/media/repository/GeoTrust-WTBR-2015.pdf
, GeoTrust is simply the branding identifier of the root certificate and
key material owned and operated by Symantec Corporation.

Note that this report also highlights that, during the period of December
1, 2014 through November 30, 2015, the auditors made the following
statement:

"We noted that audit reports were not obtained during the examination
period for 2 of 5 external partner subordinate CAs signed by the GeoTrust
Global CA and managed by contracted third parties as part of the GeoRoot
service). In addition, the report obtained for 1 of 5 external partner
subordinate CAs was not in accordance with permitted audit schemes.
Furthermore, in lieu of third party audits completed by delegated third
parties, no out-of-band mechanisms were used to confirm the authenticity of
the certificate requests, or the information supporting the certificate and
internal reviews were not performed by Symantec to determine third party
compliance with baseline requirements. "

It is important to highlight that the above-linked report was produced
following following
https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html
, and describes a separate incident than the one described in this thread.
That is, the issues in this thread arose after Symantec was reported to
have remedied the above issues, and therefore indicates that the process
and procedures which Symantec instituted in response to
https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html
were insufficient to adequately assure necessary trust or to improve
compliance with the stated and expected policies.

[g***@garyzhu.net]

So from the report (second link), GeoTrust "is" one of the bad apples.
As a website operator, I will swap out the SSL cert within a year if this
decision did not cause all users to ditch Chrome browsers.

Ours are using GeoTrust Global CA (like million others), but, obviously, it
is not cross-signed by Google or Apple.

Post by Ryan Sleevi

Post by g***@garyzhu.net
Google is using SSL certificate issued by "Google Internet Authority G2"
with root CA "GeoTrust Global CA", so this is also affected (initially the
reduced expiration date) ?

Please see
https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/README.md

Post by g***@garyzhu.net
I understand completely that GeoTrust is a subsidiary of Symantec, but it
is different from the certificate issued directly from Symantec, such as
the one on www.bankofamerica.com, its EV status is immediately affected.

As noted in
https://www.symantec.com/content/en/us/about/media/repository/GeoTrust-WTBR-2015.pdf
, GeoTrust is simply the branding identifier of the root certificate and
key material owned and operated by Symantec Corporation.
Note that this report also highlights that, during the period of December
1, 2014 through November 30, 2015, the auditors made the following
"We noted that audit reports were not obtained during the examination
period for 2 of 5 external partner subordinate CAs signed by the GeoTrust
Global CA and managed by contracted third parties as part of the GeoRoot
service). In addition, the report obtained for 1 of 5 external partner
subordinate CAs was not in accordance with permitted audit schemes.
Furthermore, in lieu of third party audits completed by delegated third
parties, no out-of-band mechanisms were used to confirm the authenticity of
the certificate requests, or the information supporting the certificate and
internal reviews were not performed by Symantec to determine third party
compliance with baseline requirements. "
It is important to highlight that the above-linked report was produced
following following
https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html
, and describes a separate incident than the one described in this thread.
That is, the issues in this thread arose after Symantec was reported to
have remedied the above issues, and therefore indicates that the process
and procedures which Symantec instituted in response to
https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html
were insufficient to adequately assure necessary trust or to improve
compliance with the stated and expected policies.

[p***@gmail.com]

Post by Ryan Sleevi
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)
Chrome 62 (Dev, Beta, Stable): 15 months validity (465 days)
Chrome 63 (Dev, Beta): 9 months validity (279 days)
Chrome 63 (Stable): 15 months validity (465 days)
Chrome 64 (Dev, Beta, Stable): 9 months validity (279 days)
The proposed schedule attempts to avoid making changes in Chrome 63
Stable, as that would be released during the winter holiday production
freeze many organizations undergo. This is solely to reduce disruption for
site operators and users, and attempts to resume with Chrome 64 following
the holiday season. Further, the practical impact of the changes in Chrome
59 and 60 are relatively minimal, due to many of the certificates issued
during that period of time being issued using SHA-1, which is no longer
supported for certificates in Chrome

I'm trying to convert this to concrete terms.

If a sever authentication certificate has a notBefore date of
2017-03-24T00:00:00Z and a notAfter date of 2018-03-23T23:59:59Z
(approximately 365 days), and this intent is implemented as described, is
it accurate that this certificate will be accepted by Chrome Beta until
Chrome 63 and by Chrome Stable 64?

Post by Ryan Sleevi
In addition, we propose to require that all newly-issued certificates must
have validity periods of no greater than 9 months (279 days) in order to be
trusted in Google Chrome, effective Chrome 61.

How is "newly-issued" defined?

Post by Ryan Sleevi
This ensures that the risk of any further misissuance is, at most, limited
to nine months, and more importantly, that if any further action is
warranted or necessary, that the entire ecosystem can migrate within that
time period, thus minimizing the risk of further compatibility issues.
By combining these two steps, we can ensure that the level of assurance in
Symantec-issued certificates is able to match what is expected by Google
Chrome and the ecosystem, and that the risks posed both from past and
possible future misissuance is minimized as much as possible.

Thanks,
Peter

[Ryan Sleevi]

Post by p***@gmail.com
I'm trying to convert this to concrete terms.
If a sever authentication certificate has a notBefore date of
2017-03-24T00:00:00Z and a notAfter date of 2018-03-23T23:59:59Z
(approximately 365 days), and this intent is implemented as described, is
it accurate that this certificate will be accepted by Chrome Beta until
Chrome 63 and by Chrome Stable 64?

I believe you meant "accepted by Chrome Beta (until Chrome 63) and by
Chrome Stable (until Chrome 64)", correct? If so, that is correct.

Alternatively stated, using the end-goal as the measuring stick, if Chrome
64 were to come out on January 30, 2018 (more or less 6 weeks after
December 12, modulo holidays), then the earliest accepted certificate would
be one whose notBefore was on or after April 26, 2017 (279 days before
January 30, 2018). If Chrome 64 were used on January 31, 2018, then the
earliest accepted certificate would be one whose notBefore was issued on or
after April 27, 2017. Both of these would only work if their validity
periods were less than or equal to 279 days.

Post by p***@gmail.com
In addition, we propose to require that all newly-issued certificates must

Post by Ryan Sleevi
have validity periods of no greater than 9 months (279 days) in order to be
trusted in Google Chrome, effective Chrome 61.

How is "newly-issued" defined?

Chrome 60 is estimated to be branched the week of May 25, 2017, as detailed
at https://www.chromium.org/developers/calendar . On or after that branch
point, in which 'trunk' becomes the intended and eventual Chrome 61
development tree, a change would be landed to require all certificates
issued on or after that date have validity periods less than or equal to
nine months. For example, a certificate issued on May 26, 2017 would need
to expire on or before March 1, 2018. This would work through the normal
development cycle of Canary -> Dev -> Beta and be released to Chrome Stable
during the week of September 12, 2017. Note these represent estimated
dates, as mentioned on the page.

The proposed definition for this is to rely upon the notBefore as an
appropriate signal. This does create risk, for example, if a certificate
issued on May 26, 2017 has its "notBefore" set to a date prior to the
actual issuance date. An alternative definition that may mitigate that
risk, but provide site operators less flexibility, is to use the earliest
accepted Signed Certificate Timestamp presented with the certificate
(either within the certificate, via a stapled OCSP response, or with the
TLS extension), and rely on the Trusted Certificate Transparency Logs to
provide an accurate timestamp. This provides less flexibility for other
Chromium embedders (in that it relies on Certificate Transparency, for
which may not be an appropriate dependency for these embedders), and less
flexibility for site operators (in that it measures "first disclosed", not
necessarily issuance date), but can provide a stronger security guarantee
by providing a counter-signature as to the earliest possible time the
certificate was 'publicly' known.



As a proposal, I'm especially looking for feedback as to any potential
interoperability and compatibility risks, and welcome suggestions on how
best to minimize. If the Blink OWNERS would find it helpful and useful, and
an appropriate use of WICG, this could be iterated further in a WICG
Repository to provide a more formal explainer and pseudo-code to reduce
that risk. As I mentioned, this is a particularly new and unique approach
for something that has historically been announced post-facto of
implementation, and feedback is welcome on how best to minimize risks.

[t***@gmail.com]

I think the immediate removal of EV indicator is very unnecessary. Practically speaking very few users are going to think twice about it. They will not suddenly become educated in what OV means compared to DV and re-evaluate how that fits into their busy lives. It's not going to prevent any attack surely. What it will do is produce confusion, regulatory heartache, and money wasted on fixing perception rather than demonstrable risk.

[Andrew Ayer]

Hi Ryan,

What restrictions, if any, will be placed on the reuse of validation
information?

Regards,
Andrew

[Ryan Sleevi]

Post by Andrew Ayer
What restrictions, if any, will be placed on the reuse of validation
information?

For better or worse, the reuse of validation information is not
web-visible, and as a consequence, is effectively not a quantifiable part
of the Web Platform, beyond the audit engagement of a Certificate Authority
.

However, this also highlights a gap in incompletely addressing the security
concerns. For example, if the information reused was obtained by not
following the proper and expected procedures - such as by one of the
Delegated Third Parties who were improperly responsible for validating the
information that appeared within these 30,000 certificates - then the
issuance of a new certificate would fail to meaningfully ensure the
information has been appropriately validated.

A way to mitigate these concerns - and ensure the proper level of security
- would be to require that any information that appears within certificates
issued after a particular date ONLY rely on information which Symantec has
independently validated, consistent with the Baseline Requirements.

[u***@gmail.com]

Post by Ryan Sleevi

Post by Andrew Ayer
What restrictions, if any, will be placed on the reuse of validation
information?

For better or worse, the reuse of validation information is not
web-visible, and as a consequence, is effectively not a quantifiable part
of the Web Platform, beyond the audit engagement of a Certificate Authority
.
However, this also highlights a gap in incompletely addressing the
security concerns. For example, if the information reused was obtained by
not following the proper and expected procedures - such as by one of the
Delegated Third Parties who were improperly responsible for validating the
information that appeared within these 30,000 certificates - then the
issuance of a new certificate would fail to meaningfully ensure the
information has been appropriately validated.
A way to mitigate these concerns - and ensure the proper level of security
- would be to require that any information that appears within certificates
issued after a particular date ONLY rely on information which Symantec has
independently validated, consistent with the Baseline Requirements.

So out of curiosity:

Assumptions:
1. Say I am Symantec or any SubCA/RA/DTP/subdivision/... operating under
one of their roots.
2. I am not exempt from the measures (Apple/Google subCAs) or one of the
naughty third parties (CrossCert/Certisign/Certsuperior/Certisur).
3. No additional violations of the rules by Symantec are discovered (yeah,
bear with me here...)

Goal: Have trusted certs in Chrome despite the sanctions.

Possible way to achieve this:

1. non-EV:
a. Existing: To make sure my certificates remain trusted in Chrome, I
provide my customers a way to reissue/convert their existing multi-year
certs to some with max validity period of 9 months (and I allow them to
reissue for as long as the original cert/contract would have lasted). I can
do that because the existing validation info lasts for up to 39 months.
That cert swap is all that is needed for customer sites to remain trusted
and nobody has to worry about transition periods/Chrome updates breaking
things. All correct?
b. New: I promptly start to issue new certs with <= 9 months validity. I
could, however, still offer multi-year contracts because validation info
for my new certs also lasts for 39 (or 27 in 2018) months just like it does
for every other CA. Correct?
c. Future: The 9 months validity requirement is basically the full extent
of the proposed sanctions, I won't have to create new root or sub CAs and
Chrome won't decide to distrust my certs in a year or two. This is not a
road to complete or partial distrust unless I fuck up again. Correct?

2. EV:
Not much I can do, as a punishment my existing and new EV certs are
effectively DV certs in Chrome58+ for at least a year. I could, however,
work with another EV-enabled CA to keep providing EV services. If they
perform the validation, that should be allowed. Correct? What if they
(cross-)sign an EV subCA of mine with valid audits and stuff? Not allowed?

[Ryan Sleevi]

Post by u***@gmail.com
1. Say I am Symantec or any SubCA/RA/DTP/subdivision/... operating under
one of their roots.
2. I am not exempt from the measures (Apple/Google subCAs) or one of the
naughty third parties (CrossCert/Certisign/Certsuperior/Certisur).
3. No additional violations of the rules by Symantec are discovered (yeah,
bear with me here...)
Goal: Have trusted certs in Chrome despite the sanctions.
a. Existing: To make sure my certificates remain trusted in Chrome, I
provide my customers a way to reissue/convert their existing multi-year
certs to some with max validity period of 9 months (and I allow them to
reissue for as long as the original cert/contract would have lasted). I can
do that because the existing validation info lasts for up to 39 months.
That cert swap is all that is needed for customer sites to remain trusted
and nobody has to worry about transition periods/Chrome updates breaking
things. All correct?

Correct

Post by u***@gmail.com
b. New: I promptly start to issue new certs with <= 9 months validity. I
could, however, still offer multi-year contracts because validation info
for my new certs also lasts for 39 (or 27 in 2018) months just like it does
for every other CA. Correct?

Correct

Post by u***@gmail.com
c. Future: The 9 months validity requirement is basically the full extent
of the proposed sanctions, I won't have to create new root or sub CAs and
Chrome won't decide to distrust my certs in a year or two. This is not a
road to complete or partial distrust unless I fuck up again. Correct?

Correct

Post by u***@gmail.com
Not much I can do, as a punishment my existing and new EV certs are
effectively DV certs in Chrome58+ for at least a year. I could, however,
work with another EV-enabled CA to keep providing EV services. If they
perform the validation, that should be allowed. Correct? What if they
(cross-)sign an EV subCA of mine with valid audits and stuff? Not allowed?

Note: This is not a punishment. This is an expression of the uncertainty
related to the validation procedures and the process and controls related
to those procedures, of which evidence and admission have been provided
that demonstrates Symantec has not suitably adhered to the level of
diligence expected, and as codified in the Baseline Requirements, which
underpin the Extended Validation Guidelines. The removal of EV reflects the
uncertainty that has resulted from the sustained period of issues.

With how EV works, an issuing CA (trust anchor) is recognized for "EV
trust" given a set of particular OIDs in their certificate policy. If a
server certificate bearing one of these policies is presented, and a valid
path (appropriate for the policies) can be built to a root enabled for
those policies, the certificate is recognized as EV.

While the CA/Browser Forum has defined a generic set of EV policy OIDs,
many CAs make use of vendor-specific OIDs that reflect policies in their
CP/CPS, which may and often do go above and beyond what the EV Guidelines
require, in order to satisfy their business and customer needs. As a
consequence, such an issuing CA would have to recognize the sub-CA as being
compliant with those issuance policies expressed in the issuing CA's
CP/CPS. The issuing CA would need to receive an audit that they believe
sufficiently demonstrates the sub-CA's compliance with the issuing CA's
policies - which would be the appropriate WebTrust or ETSI set of schemes.
As Symantec currently operates WebTrust-audited CAs, this presumably is
"WebTrust for CAs", "WebTrust for CAs - SSL", and "WebTrust for CAs - EV"
(as they're commonly abbreviated).

Given that these issues are reasonable grounds to expect that the next
period of audit should produce "qualifications" (due to these issues of
non-compliance), the issuing CA would be accepting the liability, risk, and
responsibility to ensure the sub-CA is operating according to both the
issuing CA's and the sub-CA's stated CP/CPS, that the CP/CPS appropriately
reflect the requirements contained within the "Baseline Requirements" and
"Extended Validation Guidelines", and the audits appropriately examine
compliance to these statements.

As noted earlier on this thread, Symantec bore this responsibility with
their Delegated Third Parties, and by the evidence presented by them,
failed to uphold this standard. Should a CA issue such a subordinate CA,
they too would bear the responsibility and liability for ensuring it is
appropriately complying with the expectations, and failure to do may be
reasonable grounds to begin a similar discussion, once the appropriate
facts and details were gathered from the issuing CA.

[b***@gmail.com]

(just to be super clear I'm writing this in a personal capacity and not
representing the thoughts of my employer)

As a developer I feel like this plan might be excessively confusing. Given
this list of dates, how would I calculate when I have to do something? Do I
even remember when my cert was issued? Also, this process seems to aim at a
gradual breakage, but from a developer's perspective this is not gradual --
I own a single site, and during one of the chrome releases my site will
break the day that release goes to stable.

In addition the lack of a single deadline would seem to make it hard for a
campaign to get site owners to replace these certs to be effective. If I
were in the shoes of Symantec, I'd start emailing my customers offering
them a free renewal of their certificate. If I were another CA I'd start
offering Symantec customers a free replacement for their old certificate.
If customers are affected over the course of a year it's hard for people to
make these kinds of campaigns high profile.

Did you guys consider something where there would be an escalating level of
distrust (eg, in one version you get a warning rather than a green lock,
the next release a red not secure, then a intersticial)? This would allow
attentive operators who might not hear about this change otherwise to
figure out that there is an issue before their site breaks completely. It
also gives all parties involved a small number of times where they can
promote this change.

If other browser vendors might implement a similar policy it could make
sense to tie those events to dates rather than releases so that this type
of promotion could be more effective.

Post by Ryan Sleevi
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)
Chrome 62 (Dev, Beta, Stable): 15 months validity (465 days)
Chrome 63 (Dev, Beta): 9 months validity (279 days)
Chrome 63 (Stable): 15 months validity (465 days)
Chrome 64 (Dev, Beta, Stable): 9 months validity (279 days)
The proposed schedule attempts to avoid making changes in Chrome 63
Stable, as that would be released during the winter holiday production
freeze many organizations undergo. This is solely to reduce disruption for
site operators and users, and attempts to resume with Chrome 64 following
the holiday season. Further, the practical impact of the changes in Chrome
59 and 60 are relatively minimal, due to many of the certificates issued
during that period of time being issued using SHA-1, which is no longer
supported for certificates in Chrome.
In addition, we propose to require that all newly-issued certificates must
have validity periods of no greater than 9 months (279 days) in order to be
trusted in Google Chrome, effective Chrome 61. This ensures that the risk
of any further misissuance is, at most, limited to nine months, and more
importantly, that if any further action is warranted or necessary, that the
entire ecosystem can migrate within that time period, thus minimizing the
risk of further compatibility issues.
By combining these two steps, we can ensure that the level of assurance in
Symantec-issued certificates is able to match what is expected by Google
Chrome and the ecosystem, and that the risks posed both from past and
possible future misissuance is minimized as much as possible.
Given the nature of these issues, and the multiple failures of Symantec to
ensure that the level of assurance provided by their certificates meets the
requirements of the Baseline Requirements or Extended Validation
Guidelines, we no longer have the confidence necessary in order to grant
Symantec-issued certificates the “Extended Validation” status. As
documented with both the current and past misissuance, Symantec failed to
ensure that the organizational attributes, displayed within the address bar
for such certificates, meet the level of quality and validation required
for such display. Therefore, we propose to remove such indicators,
effective immediately, until Symantec is able to demonstrate the level of
sustained compliance necessary to grant such trust, which will be a period
no less than a year. After such time has passed, we will consider requests
from Symantec to re-evaluate this position, in collaboration with the
broader Chromium community.
Compatibility and Interoperability Risk
As with any reduction in trust in a Certificate Authority, this poses a
non-trivial degree of compatibility risk. This is because site operators
desire to have their certificates recognized in all client browsers, and if
one or more browsers fail to trust a given CA, this is prevented from
happening.
On the other hand, all site operators expect that certificates will only
be issued for their domains upon their request, and the failure to have
that assurance significantly undermines the security of HTTPS for both site
operators and users.
This compatibility risk is especially high for Symantec-issued
certificates, due to their acquisition of some of the first CAs, such as
Thawte, Verisign, and Equifax, which are some of the most widely supported
CAs. Distrusting such CAs creates further difficulty for providing secure
connections to both old and new devices alike, due to the need to ensure
the CA a site operator uses is recognized across these devices.
Further, the immediate distrust of a CA, as has been necessary in the
past, can significantly impact both site operators and users. Site
operators are forced to acquire certificates from other CAs, without having
the opportunity and time to research which CAs best meet their needs, and
users encounter a substantial number of errors until those site operators
act, conditioning them to ignore security warnings. In the event that only
a single browser distrusts such a CA, the error is often seen as the
browser’s fault, despite it being a failure of the CA to provide the
necessary level of assurance, and the site operator to respond in a timely
fashion.
Assessing the compatibility risk with both Edge and Safari is difficult,
because neither Microsoft nor Apple communicate publicly about their
changes in trust prior to enacting them.
While Mozilla conducts their discussions regarding Certificate Authorities
in public, and were the first to be alerted of these latest issues, they
have not yet begun discussion of the next steps to how best to protect
their users. Our hope is that this proposal may be seen as one that
appropriately balances the security and compatibility risks with the needs
of site operators, browsers, and users, and we welcome all feedback.
Alternative implementation suggestion for web developers
This proposal allows for web developers to continue to use Symantec issued
certificates, but will see their validity period reduced. This ensure that
web developers are aware of the risk and potential of future distrust of
Symantec-issued certificates, should additional misissuance events occur,
while also allowing them the flexibility to continue using such
certificates should it be necessary.
Usage information from UseCounter
<https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>
For a variety of non-technical reasons, we do not currently instrument the
usage of CAs. Further, few public metrics exist for intersecting usage
information with the validity period, since only certificates valid greater
than nine months will be affected outside of their normal replacement
cycle. From Mozilla Firefox’s Telemetry, we know that Symantec issued
certificates are responsible for 42% of certificate validations. However,
this number is not strictly an indicator for impact, as this number is
biased towards counting certificates for heavily-trafficked sites, and
whose issuance is fully automated and/or whose validity periods will be
unaffected, thus significantly overstating impact. By phasing such changes
in over a series of releases, we aim to minimize the impact any given
release poses, while still continually making progress towards restoring
the necessary level of security to ensure Symantec issued certificates are
as trustworthy as certificates from other CAs.

[k***@gmail.com]

Did you guys consider something where there would be an escalating level of distrust (eg, in one version you get a warning rather than a green lock, the next release a red not secure, then a interstitial)? This would allow attentive operators who might not hear about this change otherwise to figure out that there is an issue before their site breaks completely. It also gives all parties involved a small number of times where they can promote this change.

As a developer, this sounds reasonable to me.

Wording & iconography such as this might be reusable for future incidents:

#######
(i) Warning | https://example.com

Your connection to this site is not fully secure

The site presented old identity information which needs to be revalidated. Learn more
#######

- Learn more would link to a help center article saying you need to get your certificate reissued
- Not overly alarmist - use of Info icon, "Warning" instead of "Not Secure"
- Text does not imply operator is at fault, but they do need to take action
- Notice could be upgraded to red in a later release, then to interstitial
- Needs new translation work - "Warning" is not an already used term in the address bar


Kane York

['Chris Palmer' via blink-dev]

On Thursday, March 23, 2017 at 11:07:03 AM UTC-7, ***@gmail.com wrote:

As a developer I feel like this plan might be excessively confusing. Given

Post by b***@gmail.com
this list of dates, how would I calculate when I have to do something?

This is a good and important question. A big part of the solution is
automating re-issuance. Automation is a good value-add that various CAs and
resellers are offering now, because lots of people need it for lots of
reasons. I won't endorse any particular vendor, but there are several
vendors you can choose from that are quite affordable and who provide
automated re-issuance.

Combined with the gradual move to certificates with shorter lifespans
anyway (as a way of coping with problems like this, and with the difficulty
of certificate revocation generally), automation is a necessity going
forward.

[PhistucK]

Perhaps this just needs a similar treatment to the one SHA-1 got/mixed
content get (simply showing a website as secure, but not emphasizing that
it is insecure). No interstitial on one hand, but also not shown as secure
on the other hand.
I think this is the best outcome, as Symantec has (repeatedly) demonstrated
that it cannot be trusted and not showing a website as secure indicates
that it cannot be completely trusted (which is the case).

Also, some warning in the console might help (with a cutoff date,
obviously), in anticipation for an interstitial or some other drastic
action.


​Also, note that the iconography and taxonomy was simplified. There are
three states, if I remember correctly (four, if you count Extended
Validation​, but ignore that for now) - Secure (great HTTPS), Not Secure
(for form filling HTTP websites, data URLs and so on) and none (HTTP
without forms and HTTPS with problems). A warning signal is probably a step
back and does not mean a lot to user.


☆*PhistucK*

Post by b***@gmail.com
(just to be super clear I'm writing this in a personal capacity and not
representing the thoughts of my employer)
As a developer I feel like this plan might be excessively confusing. Given
this list of dates, how would I calculate when I have to do something? Do I
even remember when my cert was issued? Also, this process seems to aim at a
gradual breakage, but from a developer's perspective this is not gradual --
I own a single site, and during one of the chrome releases my site will
break the day that release goes to stable.
In addition the lack of a single deadline would seem to make it hard for a
campaign to get site owners to replace these certs to be effective. If I
were in the shoes of Symantec, I'd start emailing my customers offering
them a free renewal of their certificate. If I were another CA I'd start
offering Symantec customers a free replacement for their old certificate.
If customers are affected over the course of a year it's hard for people to
make these kinds of campaigns high profile.
Did you guys consider something where there would be an escalating level
of distrust (eg, in one version you get a warning rather than a green lock,
the next release a red not secure, then a intersticial)? This would allow
attentive operators who might not hear about this change otherwise to
figure out that there is an issue before their site breaks completely. It
also gives all parties involved a small number of times where they can
promote this change.
If other browser vendors might implement a similar policy it could make
sense to tie those events to dates rather than releases so that this type
of promotion could be more effective.

Post by Ryan Sleevi
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)
Chrome 62 (Dev, Beta, Stable): 15 months validity (465 days)
Chrome 63 (Dev, Beta): 9 months validity (279 days)
Chrome 63 (Stable): 15 months validity (465 days)
Chrome 64 (Dev, Beta, Stable): 9 months validity (279 days)
The proposed schedule attempts to avoid making changes in Chrome 63
Stable, as that would be released during the winter holiday production
freeze many organizations undergo. This is solely to reduce disruption for
site operators and users, and attempts to resume with Chrome 64 following
the holiday season. Further, the practical impact of the changes in Chrome
59 and 60 are relatively minimal, due to many of the certificates issued
during that period of time being issued using SHA-1, which is no longer
supported for certificates in Chrome.
In addition, we propose to require that all newly-issued certificates
must have validity periods of no greater than 9 months (279 days) in order
to be trusted in Google Chrome, effective Chrome 61. This ensures that the
risk of any further misissuance is, at most, limited to nine months, and
more importantly, that if any further action is warranted or necessary,
that the entire ecosystem can migrate within that time period, thus
minimizing the risk of further compatibility issues.
By combining these two steps, we can ensure that the level of assurance
in Symantec-issued certificates is able to match what is expected by Google
Chrome and the ecosystem, and that the risks posed both from past and
possible future misissuance is minimized as much as possible.
Given the nature of these issues, and the multiple failures of Symantec
to ensure that the level of assurance provided by their certificates meets
the requirements of the Baseline Requirements or Extended Validation
Guidelines, we no longer have the confidence necessary in order to grant
Symantec-issued certificates the “Extended Validation” status. As
documented with both the current and past misissuance, Symantec failed to
ensure that the organizational attributes, displayed within the address bar
for such certificates, meet the level of quality and validation required
for such display. Therefore, we propose to remove such indicators,
effective immediately, until Symantec is able to demonstrate the level of
sustained compliance necessary to grant such trust, which will be a period
no less than a year. After such time has passed, we will consider requests
from Symantec to re-evaluate this position, in collaboration with the
broader Chromium community.
Compatibility and Interoperability Risk
As with any reduction in trust in a Certificate Authority, this poses a
non-trivial degree of compatibility risk. This is because site operators
desire to have their certificates recognized in all client browsers, and if
one or more browsers fail to trust a given CA, this is prevented from
happening.
On the other hand, all site operators expect that certificates will only
be issued for their domains upon their request, and the failure to have
that assurance significantly undermines the security of HTTPS for both site
operators and users.
This compatibility risk is especially high for Symantec-issued
certificates, due to their acquisition of some of the first CAs, such as
Thawte, Verisign, and Equifax, which are some of the most widely supported
CAs. Distrusting such CAs creates further difficulty for providing secure
connections to both old and new devices alike, due to the need to ensure
the CA a site operator uses is recognized across these devices.
Further, the immediate distrust of a CA, as has been necessary in the
past, can significantly impact both site operators and users. Site
operators are forced to acquire certificates from other CAs, without having
the opportunity and time to research which CAs best meet their needs, and
users encounter a substantial number of errors until those site operators
act, conditioning them to ignore security warnings. In the event that only
a single browser distrusts such a CA, the error is often seen as the
browser’s fault, despite it being a failure of the CA to provide the
necessary level of assurance, and the site operator to respond in a timely
fashion.
Assessing the compatibility risk with both Edge and Safari is difficult,
because neither Microsoft nor Apple communicate publicly about their
changes in trust prior to enacting them.
While Mozilla conducts their discussions regarding Certificate
Authorities in public, and were the first to be alerted of these latest
issues, they have not yet begun discussion of the next steps to how best to
protect their users. Our hope is that this proposal may be seen as one that
appropriately balances the security and compatibility risks with the needs
of site operators, browsers, and users, and we welcome all feedback.
Alternative implementation suggestion for web developers
This proposal allows for web developers to continue to use Symantec
issued certificates, but will see their validity period reduced. This
ensure that web developers are aware of the risk and potential of future
distrust of Symantec-issued certificates, should additional misissuance
events occur, while also allowing them the flexibility to continue using
such certificates should it be necessary.
Usage information from UseCounter
<https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>
For a variety of non-technical reasons, we do not currently instrument
the usage of CAs. Further, few public metrics exist for intersecting usage
information with the validity period, since only certificates valid greater
than nine months will be affected outside of their normal replacement
cycle. From Mozilla Firefox’s Telemetry, we know that Symantec issued
certificates are responsible for 42% of certificate validations. However,
this number is not strictly an indicator for impact, as this number is
biased towards counting certificates for heavily-trafficked sites, and
whose issuance is fully automated and/or whose validity periods will be
unaffected, thus significantly overstating impact. By phasing such changes
in over a series of releases, we aim to minimize the impact any given
release poses, while still continually making progress towards restoring
the necessary level of security to ensure Symantec issued certificates are
as trustworthy as certificates from other CAs.

--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an

[l***@gmail.com]

Could you put the dates those versions hit stable in the original post?

[e***@gmail.com]

See: https://www.chromium.org/developers/calendar

*2017*

* Release * * Estimated Week of Stable*
56 Jan 31st, 2017
57 Mar 14th, 2017
58 Apr 25th, 2017
59 Jun 6th, 2017
60 Aug 1st, 2017
61 Sep 12th, 2017
62 Oct 24th, 2017
63 Dec 12th, 2017

Post by l***@gmail.com
Could you put the dates those versions hit stable in the original post?

[Ryan Sleevi]

Post by b***@gmail.com
(just to be super clear I'm writing this in a personal capacity and not
representing the thoughts of my employer)
As a developer I feel like this plan might be excessively confusing. Given
this list of dates, how would I calculate when I have to do something? Do I
even remember when my cert was issued? Also, this process seems to aim at a
gradual breakage, but from a developer's perspective this is not gradual --
I own a single site, and during one of the chrome releases my site will
break the day that release goes to stable.

This is the unfortunate reality of the CA ecosystem, in which the trust
afforded to any given site is binary, but the trust afforded to a CA is
expressed in gradations, dependent upon how the certificate was validated
and when it was validated.

The simple answer would be that, if adopted by Blink OWNERS, then to
minimize all parties should strive to replace their certificates with
versions whose validity period is less than or equal to 279 days (9
months). By replacing the existing certificates with such a certificate,
there should be no negative effect. The remaining dates relate to a
ratcheting enforcement that attempts to minimize the breakage from any
given release.

Alternatively, should it be that measuring by validity period represents
too great an ecosystem concern, an alternative approach would be to express
this requirement as "The certificate was issued on or after this date" -
such as Chrome 59 rejecting certificates issued prior to 1023 days than the
current date. This approach would replace certificates in batches based on
issuance. Accompanied with a requirement that certificates issued on or
after the proposed Chrome 61 'open' date (the day on or after the Chrome 60
"branch" date of May 25, 2017) have validity periods less than or equal to
9 months, this would also see the eventual harmonization of nine month
validity, but affect a different population of certificates.

Would such an approach be easier to understand and communicate?

Post by b***@gmail.com
Did you guys consider something where there would be an escalating level
of distrust (eg, in one version you get a warning rather than a green lock,
the next release a red not secure, then a intersticial)? This would allow
attentive operators who might not hear about this change otherwise to
figure out that there is an issue before their site breaks completely. It
also gives all parties involved a small number of times where they can
promote this change.

Yes, this was considered. This is similar to the approach used with SHA-1
deprecation, but in this case, may cause undesired security risk, in that
such certificates continue to be used, and thus private information (such
as cookies) are still transmitted, and privileged features (such as
geolocation) may still be enabled. This proposal was an attempt to balance
those security concerns with the interoperability and compatibility risk.

[p***@gmail.com]

Post by Ryan Sleevi

Post by b***@gmail.com
(just to be super clear I'm writing this in a personal capacity and not
representing the thoughts of my employer)
Did you guys consider something where there would be an escalating level
of distrust (eg, in one version you get a warning rather than a green lock,
the next release a red not secure, then a intersticial)? This would allow
attentive operators who might not hear about this change otherwise to
figure out that there is an issue before their site breaks completely. It
also gives all parties involved a small number of times where they can
promote this change.

Yes, this was considered. This is similar to the approach used with SHA-1
deprecation, but in this case, may cause undesired security risk, in that
such certificates continue to be used, and thus private information (such
as cookies) are still transmitted, and privileged features (such as
geolocation) may still be enabled. This proposal was an attempt to balance
those security concerns with the interoperability and compatibility risk.

I realize API changes usually don't have corresponding UX, but as was
called out in the initial email this is using the blink intent process for
something that is not technically Blink.

To that end, I think that this this intent seems to be unclear on the
resulting user experiences. There are a variety of gradations of trust
reduction available, ranging from simply treating as neutral (currently
the ⓘ) to affirmatively insecure (currently red struck through https)
to bypassable interstitial to non-bypassable interstitial. Can you
clarity which level of trust is proposed for certificates exceeding the
defined maximum validity periods? Is there any intent to vary this level
of trust across the proposed schedule?

Thanks,
Peter

[Rick Byers]

I'm following this thread with great interest and trying to build up the
context in order to form a well-reasoned opinion. In the interim I just

Post by p***@gmail.com

Post by Ryan Sleevi

Post by b***@gmail.com
(just to be super clear I'm writing this in a personal capacity and not
representing the thoughts of my employer)
Did you guys consider something where there would be an escalating level
of distrust (eg, in one version you get a warning rather than a green lock,
the next release a red not secure, then a intersticial)? This would allow
attentive operators who might not hear about this change otherwise to
figure out that there is an issue before their site breaks completely. It
also gives all parties involved a small number of times where they can
promote this change.

Yes, this was considered. This is similar to the approach used with SHA-1
deprecation, but in this case, may cause undesired security risk, in that
such certificates continue to be used, and thus private information (such
as cookies) are still transmitted, and privileged features (such as
geolocation) may still be enabled. This proposal was an attempt to balance
those security concerns with the interoperability and compatibility risk.

I realize API changes usually don't have corresponding UX, but as was
called out in the initial email this is using the blink intent process for
something that is not technically Blink.

Note that for quite some time now we've been using this web platform change
process <https://www.chromium.org/blink#TOC-Web-Platform-Changes:-Process> for
most chromium changes things that impact web developers, regardless of
where the code happens to be located (the division between blink and
content is pretty artificial these days). Here's a few recent examples
which I believe are not (or at least primarily not) blink:

Intent to Deprecate and Remove: Support for HTTP over port 9100, 6697, and
631.
<https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Ttkgd4aPkW0/7Uwd-S16BwAJ>
Intent to Remove: Support for RSA keys smaller than 2048 bits in TLS
certificates
<https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Ttkgd4aPkW0/7Uwd-S16BwAJ>
Intent to implement and Ship: Shoutcast support
<https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Ttkgd4aPkW0/7Uwd-S16BwAJ>

That said, I think we're all trying to figure out if this web platform
change process will provide value to the web community for tricky
PKI-decisions like this. But at a minimum, the extra transparency and
community involvement seems clearly valuable.

To that end, I think that this this intent seems to be unclear on the

Post by p***@gmail.com
resulting user experiences. There are a variety of gradations of trust
reduction available, ranging from simply treating as neutral (currently
the ⓘ) to affirmatively insecure (currently red struck through https)
to bypassable interstitial to non-bypassable interstitial. Can you
clarity which level of trust is proposed for certificates exceeding the
defined maximum validity periods? Is there any intent to vary this level
of trust across the proposed schedule?
Thanks,
Peter

[Ryan Sleevi]

Post by p***@gmail.com
I realize API changes usually don't have corresponding UX, but as was
called out in the initial email this is using the blink intent process for
something that is not technically Blink.
To that end, I think that this this intent seems to be unclear on the
resulting user experiences. There are a variety of gradations of trust
reduction available, ranging from simply treating as neutral (currently
the ⓘ) to affirmatively insecure (currently red struck through https)
to bypassable interstitial to non-bypassable interstitial. Can you
clarity which level of trust is proposed for certificates exceeding the
defined maximum validity periods? Is there any intent to vary this level
of trust across the proposed schedule?

I have attempted a franken-hybrid of an explainer / spec at
https://github.com/sleevi/explainer/blob/master/README.md

Should other vendors wish to collaborate and formalize this, we could
explore migrating it to the WICG, consistent with our "Incubate First"
approach, in order to best align with the web platform change process to
reduce interoperability and compatibility risk, as explained in
https://groups.google.com/a/chromium.org/d/msg/blink-dev/PJ_E04kcFb8/baiLN3DTBgAJ
. Of course, this may not be appropriate for WICG, given the unique nature
of this, and so I defer to the Blink API Owners, given the lack of
'standardization' venue for such a proposal.

[Andrew Ayer]

On Fri, 24 Mar 2017 17:38:52 -0400

Post by Ryan Sleevi
I have attempted a franken-hybrid of an explainer / spec at
https://github.com/sleevi/explainer/blob/master/README.md

Hi Ryan,

Thanks for preparing this document.

The algorithm in the document appears to differ from the description

Post by Ryan Sleevi
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.

However, in the document, it is calculated as 'the difference beween
the certificate's "notBefore" and the current day'.

Is the algorithm in the document correct?

FWIW, I think the algorithm in the document makes a lot more sense.

Regards,
Andrew

[Ryan Sleevi]

Post by Andrew Ayer
However, in the document, it is calculated as 'the difference beween
the certificate's "notBefore" and the current day'.
Is the algorithm in the document correct?

Given the difficulty of tracking technical changes on a thread, the
document at https://github.com/sleevi/explainer/blob/master/README.md makes
much more sense to be treated as "The proposal" for further discussion,
given that the full provenance of all changes can be traced. Should there
be a need for further collaboration, can be easily moved to an appropriate
venue, so that the I2D just becomes "Adopt what this document says". This
is an understandable but unexpected part of the complexity of the process -
which was primarily designed for implementing particular APIs that were
already specified and actively collaborated on.

In this case, the issue with the initial proposal, despite many, many
rounds of internal review, was that the clarifying parenthetical "(the
difference between the certificate's "notBefore to notAfter")" was quite
literally the last change made. It was added in an attempt to clarify for
those not familiar with certificates, so of course it would be the first
matter to cause confusion, particularly for those who are familiar. The
intent is the algorithm specified at
https://github.com/sleevi/explainer/blob/master/README.md , which describes
a means of computing an _effective maximum_ validity period, and gradually
reducing that in a way that hopefully risk.

The difference is both subtle and significant, and I appreciate you
highlighting it, because rejecting based on the encoded validity period
would have much more significant compatibility risk, since that period is
fixed at issuance and generally buckets into 39 month, 27 month, and 13
month. By describing the _effective maximum_ validity period, it instead
makes a sliding scale based on when the certificate was issued, with slight
bumps of breakage around each release, but otherwise gently smoothed
throughout the upcoming year.

The bumps could also be smoothed out by fully defining the proposal
algorithmically - as suggested in
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/CewaHomoCQAJ
- but releasing it with the bumps may help bring better awareness, and ease
discovery, making it easier to minimize or avoid negative user impact.
Further, it becomes easier for site operators to examine when their
certificate was issued - as the oldest issued certificates are the first
affected, but also the least likely to still be working (e.g. due to
SHA-1), and thus the least likely to cause compatibility issues.

[p***@gmail.com]

Post by Ryan Sleevi

Post by Andrew Ayer
However, in the document, it is calculated as 'the difference beween
the certificate's "notBefore" and the current day'.
Is the algorithm in the document correct?

Given the difficulty of tracking technical changes on a thread, the
document at https://github.com/sleevi/explainer/blob/master/README.md
makes much more sense to be treated as "The proposal" for further
discussion, given that the full provenance of all changes can be traced.
Should there be a need for further collaboration, can be easily moved to an
appropriate venue, so that the I2D just becomes "Adopt what this document
says". This is an understandable but unexpected part of the complexity of
the process - which was primarily designed for implementing particular APIs
that were already specified and actively collaborated on.

How does the algorithm intersect with administrator defined policies?
Can an administrator whitelist domains that should be allowed to have
validity periods longer than proposed?
Can an administrator set policy to have additional public keys in the
excluded sub-CAs list?

What if an administrator adds a CA as a trust anchor that is cross-signed
by Symantec? Will it work the same on all Blink/Chromium platforms?

Does this proposal change the already existing rule that all connections
validated using Symantec certs must provide Certificate Transparency
information that follows the Chromium CT policy (with caveats for
administrator policies)?

Thanks,
Peter

[Ryan Sleevi]

Post by p***@gmail.com
How does the algorithm intersect with administrator defined policies?

As noted, there are none proposed.

Post by p***@gmail.com
Can an administrator whitelist domains that should be allowed to have
validity periods longer than proposed?
Can an administrator set policy to have additional public keys in the
excluded sub-CAs list?

As documented, no.

To consider whether or not it is appropriate to add enterprise policies,
it's necessary to understand the compatibility risk for enterprises
relative to the security goals, the factors related to those compatibility
risks, and the reasons and types of such policies. It's unclear if you're
asking or requesting; if asking, then as documented at present, no. If
requesting, can you help understand and explain the compatibility risk that
would necessitate such a change that would be particular for enterprises?

Given that this proposal allows all newly issued certificates to remain
trusted, it does not appear to bear the compatibility risk as, say,
disabling ciphersuites (for which no policy exists), or for the temporary
re-enabling support of SHA-1 certificates for enterprise cases (for which
policies do exist).

What if an administrator adds a CA as a trust anchor that is cross-signed

Post by p***@gmail.com
by Symantec? Will it work the same on all Blink/Chromium platforms?

What you're describing is a case where an administrator intentionally
exposes multiple certificate validation paths. No user agent that I'm aware
of - and especially not those of Edge/IE, Safari, Opera, Firefox, or Chrome
- have ever guaranteed a particular certificate validation path as part of
the Web platform. Rather, the web observable behaviour has been whether or
not a path exists to a trust anchor. This is conceptually similar to the
question about how a given user agent will resolve a hostname, and whether
or not the Fetch specification <https://fetch.spec.whatwg.org/> details
interactions with third-party modules, such as nsswitch or WINS.

In this case, RFC 5280 is intentionally silent as to how a path is
constructed. While RFCs such as RFC 4158 exist, they are informative, and
themselves do not specify a formal path building algorithm.

In this case, this situation described arises due to a non-common
configuration done manually by an administrator. This is similar to
enterprises that may install certificates for purposes of MITM, and which
terminate TLS themselves, or enterprises that install third-party tools
that perform name resolution. Under such circumstances, the behaviours
dictated will be affected by those interception tools or configuration.

Post by p***@gmail.com
Does this proposal change the already existing rule that all connections
validated using Symantec certs must provide Certificate Transparency
information that follows the Chromium CT policy (with caveats for
administrator policies)?

No

[Peter Bowen]

Post by Ryan Sleevi

Post by p***@gmail.com
How does the algorithm intersect with administrator defined policies?

As noted, there are none proposed.

Post by p***@gmail.com
Can an administrator whitelist domains that should be allowed to have
validity periods longer than proposed?
Can an administrator set policy to have additional public keys in the
excluded sub-CAs list?

As documented, no.
To consider whether or not it is appropriate to add enterprise policies,
it's necessary to understand the compatibility risk for enterprises relative
to the security goals, the factors related to those compatibility risks, and
the reasons and types of such policies. It's unclear if you're asking or
requesting; if asking, then as documented at present, no. If requesting, can
you help understand and explain the compatibility risk that would
necessitate such a change that would be particular for enterprises?
Given that this proposal allows all newly issued certificates to remain
trusted, it does not appear to bear the compatibility risk as, say,
disabling ciphersuites (for which no policy exists), or for the temporary
re-enabling support of SHA-1 certificates for enterprise cases (for which
policies do exist).

This policy assumes re-issuance of all certificates is a reasonably
possibility. Consider the situation where a customer has existing
certificates that they expected to be good until the expiration date
but are ceasing usefulness with Chrome sooner. It is possible that
the customer may not have the same relationship with Symantec they did
when the certificates were issued. Being able to allow their own
certificates on their own systems to work until expected expiration
seems like a reasonable thing.

Post by Ryan Sleevi

Post by p***@gmail.com
What if an administrator adds a CA as a trust anchor that is cross-signed
by Symantec? Will it work the same on all Blink/Chromium platforms?

What you're describing is a case where an administrator intentionally
exposes multiple certificate validation paths. No user agent that I'm aware
of - and especially not those of Edge/IE, Safari, Opera, Firefox, or Chrome
- have ever guaranteed a particular certificate validation path as part of
the Web platform. Rather, the web observable behaviour has been whether or
not a path exists to a trust anchor. This is conceptually similar to the
question about how a given user agent will resolve a hostname, and whether
or not the Fetch specification details interactions with third-party
modules, such as nsswitch or WINS.
In this case, RFC 5280 is intentionally silent as to how a path is
constructed. While RFCs such as RFC 4158 exist, they are informative, and
themselves do not specify a formal path building algorithm.

While the RFCs may be silent,
https://blogs.technet.microsoft.com/pki/2010/05/12/certificate-path-validation-in-bridge-ca-and-cross-certification-environments/
and other Microsoft documentation detail the path building used by
Edge/IE.

Post by Ryan Sleevi
In this case, this situation described arises due to a non-common
configuration done manually by an administrator. This is similar to
enterprises that may install certificates for purposes of MITM, and which
terminate TLS themselves, or enterprises that install third-party tools that
perform name resolution. Under such circumstances, the behaviours dictated
will be affected by those interception tools or configuration.

[f***@gmail.com]

It's not clear to me how sub-content (i.e. the js, css, image files, etc.
loaded subsequent to the original page) is to be treated under this
proposal. Will any of these follow-on requests become blocked at some
point by Chromium?

I agree with Peter B., below, although I would be more forceful and say the
assumption that major sites will reissue certs to accommodate changes being
made to the Chromium UI is not at all reasonable. The more complicated a
site, the more complicated the reissuing, deployment, and validation. All
of that costs money and in some cases it might be a substantial amount.

Has the Chromium team investigated how many of, say, the top 100,000
domains would be impacted by this proposed change? It might be better to
say "web destinations" here instead of domains because the biggest of them
have very elaborate sites, sub-sites, portals, content delivery networks,
and so forth. How much cost is Chromium willing to impose on the
maintainers of those domains/destinations?


On Sunday, March 26, 2017 at 10:23:15 PM UTC-5, Peter Bowen wrote:
...snip...

This policy assumes re-issuance of all certificates is a reasonably

Post by Peter Bowen
possibility. Consider the situation where a customer has existing
certificates that they expected to be good until the expiration date
but are ceasing usefulness with Chrome sooner. It is possible that
the customer may not have the same relationship with Symantec they did
when the certificates were issued. Being able to allow their own
certificates on their own systems to work until expected expiration
seems like a reasonable thing.

[c***@free.fr]

Hello,
this document says nothing about the EV status, which is the most annoying
part from my point of view.
Symantec could offer to reissue replacement certs for existing OV or DV
ones, these replacement certs would have a maximum age of 279 days (with
overlapping periods to cover the whole life span of the original cert). But
customers of costly EV certs face a dead end and they will probably flock
to other CAs to keep the precious green bar. Could it be envisioned that EV
certs issued by Symantec with a maximum age of 186 days (6 months) would
keep the EV status? If your ultimate goal is to reduce the certificates
life span and not hurt Symantec as a business this option makes sense.

Cheers
Frédéric Kayser

Post by Ryan Sleevi
I have attempted a franken-hybrid of an explainer / spec at
https://github.com/sleevi/explainer/blob/master/README.md

[g***@garyzhu.net]

"But customers of costly EV certs face a dead end and they will
probably flock to other CAs to keep the precious green bar. "

Or the website operators (PayPal, bank of America, Citibank), simply tell
their users:

*In order to be assured that your connection to our website is secure,
please use Edge, Firefox or Safari, and make sure you see the our (green)
company name on the browser address bar. *

Post by c***@free.fr
Hello,
this document says nothing about the EV status, which is the most annoying
part from my point of view.
Symantec could offer to reissue replacement certs for existing OV or DV
ones, these replacement certs would have a maximum age of 279 days (with
overlapping periods to cover the whole life span of the original cert). But
customers of costly EV certs face a dead end and they will probably flock
to other CAs to keep the precious green bar. Could it be envisioned that EV
certs issued by Symantec with a maximum age of 186 days (6 months) would
keep the EV status? If your ultimate goal is to reduce the certificates
life span and not hurt Symantec as a business this option makes sense.
Cheers
Frédéric Kayser

Post by Ryan Sleevi
I have attempted a franken-hybrid of an explainer / spec at
https://github.com/sleevi/explainer/blob/master/README.md

[Ryan Sleevi]

Post by c***@free.fr
Hello,
this document says nothing about the EV status, which is the most annoying
part from my point of view.

Thank you for highlighting this. I have updated
https://github.com/sleevi/explainer/blob/master/README.md in
https://github.com/sleevi/explainer/commit/dae20f21f8f60c921da0ea6472da7ad600f4d40f
to highlight this.

Post by c***@free.fr
Symantec could offer to reissue replacement certs for existing OV or DV
ones, these replacement certs would have a maximum age of 279 days (with
overlapping periods to cover the whole life span of the original cert). But
customers of costly EV certs face a dead end and they will probably flock
to other CAs to keep the precious green bar. Could it be envisioned that EV
certs issued by Symantec with a maximum age of 186 days (6 months) would
keep the EV status? If your ultimate goal is to reduce the certificates
life span and not hurt Symantec as a business this option makes sense.

As noted, there is a lack of confidence in the procedures and policies
related to these certificates to reasonably conclude that the certificate
has been properly validated for organization information. As noted during
the investigation, and from the results of previous audits that more
thoroughly examined the operations in response to other significant
security failures, Symantec Corporation failed to properly oversee the
operation of both subordinate CAs and delegated third parties (RAs), which
allowed both these organizations and (previously) employees of Symantec
Corporation to influence and enter arbitrary organization information. The
goal is to ensure that such EV status provides meaningful indication to
users of the nature of the organization, and the provided evidence casts
serious doubt on that having occurred.

The period of one year is to ensure Symantec Corporation has sufficient
time to review the policies and practices related to issuing Extended
Validation certificates, to fully re-examine the issuance processes and
expectations, and to take appropriate corrective actions. Further, it helps
assure users that Symantec Corporation has taken the time to fully examine
the issues and has not overlooked anything.

This proposal hopefully strikes the right balance between security and
compatibility, by ensuring that anything marked as EV has reasonably
assured confidence in the validation procedures and the operational
oversight related to those validation procedures. If there is information
that has been overlooked, it would be most welcome to highlight.

[Florian Weimer]

Post by Ryan Sleevi
I have attempted a franken-hybrid of an explainer / spec at
https://github.com/sleevi/explainer/blob/master/README.md

Would it be possible to perform continuous domain control validation
for the affected certificates (using the certificate itself as the DV
token) and explicitly whitelist the certificates which pass those
checks and have not been revoked by the CA? 30,000 certificate hashes
are not exactly nothing, but the size of the blob wouldn't be truly
prohibitive.

This would enable a safe downgrade to DV (from
organization-validated). Any disruption would be restricted to
certificates which are not used for a public 443/TCP service, which is
hopefully a bit restricted.

Preserving EV is obviously much more difficult, but I'm not sure if EV
actually matters from an end user perspective.

[o***@gmail.com]

I think that is not possible. See page 3 of
https://bug1334377.bmoattachments.org/attachment.cgi?id=8836487

"Is there any reliable programmatic way of determining, looking only at the
contents of the certificate or certificate chain, that a certificate was
issued by CrossCert personnel using their processes, as opposed to by
Symantec personnel or by another RA?

No. The most viable check would be to examine certificates with a KR
country code, however while CrossCert was the only Symantec RA in KR, they
have not been the exclusive source of enrollments in KR. Such a search
would not distinguish KR certificates validated by CrossCert from those
that Symantec processes directly. In any event, we are revalidating every
valid certificate issued by CrossCert."

You would have to rely on Symantec to provide the list of hashes. But can
you be sure (after all this) that it would be an accurate list?

CU Hans

Post by Florian Weimer

Post by Ryan Sleevi
I have attempted a franken-hybrid of an explainer / spec at
https://github.com/sleevi/explainer/blob/master/README.md

Would it be possible to perform continuous domain control validation
for the affected certificates (using the certificate itself as the DV
token) and explicitly whitelist the certificates which pass those
checks and have not been revoked by the CA? 30,000 certificate hashes
are not exactly nothing, but the size of the blob wouldn't be truly
prohibitive.
This would enable a safe downgrade to DV (from
organization-validated). Any disruption would be restricted to
certificates which are not used for a public 443/TCP service, which is
hopefully a bit restricted.
Preserving EV is obviously much more difficult, but I'm not sure if EV
actually matters from an end user perspective.

[Florian Weimer]

Post by o***@gmail.com
I think that is not possible. See page 3 of
https://bug1334377.bmoattachments.org/attachment.cgi?id=8836487
"Is there any reliable programmatic way of determining, looking only at the
contents of the certificate or certificate chain, that a certificate was
issued by CrossCert personnel using their processes, as opposed to by
Symantec personnel or by another RA?
No. The most viable check would be to examine certificates with a KR
country code, however while CrossCert was the only Symantec RA in KR, they
have not been the exclusive source of enrollments in KR. Such a search
would not distinguish KR certificates validated by CrossCert from those
that Symantec processes directly. In any event, we are revalidating every
valid certificate issued by CrossCert."
You would have to rely on Symantec to provide the list of hashes.

They would have to supply the list of domains, not just the hashes. I
would expect that the domain control verification would have to come
from another party, considering the current poisonous climate.

Post by o***@gmail.com
But can you be sure (after all this) that it would be an accurate
list?

So far, I don't think the integrity of Symantec's business records in
this area is in any doubt. The completeness of the list of domains
derived from them could be verified by a trusted third party.

[o***@gmail.com]

Post by Florian Weimer

Post by o***@gmail.com
You would have to rely on Symantec to provide the list of hashes.

They would have to supply the list of domains, not just the hashes. I
would expect that the domain control verification would have to come
from another party, considering the current poisonous climate.

Post by o***@gmail.com
But can you be sure (after all this) that it would be an accurate
list?

So far, I don't think the integrity of Symantec's business records in
this area is in any doubt. The completeness of the list of domains
derived from them could be verified by a trusted third party.

Is it? As I understood it, the problem is not just mis-issuing but also
that they have no reliable proof of validation for these 30.000
certificates. They are stating in their answer clearly that it is not
possible to determine without their help which certificates it concerns.
They do seem to have some idea themselves, otherwise they couldn't
revalidate them obviously, but just how accurate that is... So far I have
seen nothing that makes me assume it 'll be sufficient to restore trust.

Which is what this is all about, isn't it? Not punishment but restoring
trust.

CU Hans

[Florian Weimer]

Post by o***@gmail.com

Post by Florian Weimer

Post by o***@gmail.com
You would have to rely on Symantec to provide the list of hashes.

They would have to supply the list of domains, not just the hashes. I
would expect that the domain control verification would have to come
from another party, considering the current poisonous climate.

Post by o***@gmail.com
But can you be sure (after all this) that it would be an accurate
list?

So far, I don't think the integrity of Symantec's business records in
this area is in any doubt. The completeness of the list of domains
derived from them could be verified by a trusted third party.

Is it? As I understood it, the problem is not just mis-issuing but also
that they have no reliable proof of validation for these 30.000
certificates.

I suggested to address that by performing domain control validation
retroactively. Symantec intends to perform some retroactive
validation as well, but they probably cannot perform automated domain
control verification because they need to keep internal domains and
non-443/TCP server certificates alive, so their checks cannot be as
stringent as those from an external party.

Post by o***@gmail.com
They are stating in their answer clearly that it is not
possible to determine without their help which certificates it concerns.

That's the external view, yes.

Post by o***@gmail.com
They do seem to have some idea themselves, otherwise they couldn't
revalidate them obviously, but just how accurate that is... So far I have
seen nothing that makes me assume it 'll be sufficient to restore trust.

The accuracy of those business records could be audited. I think the
general consensus still trusts the auditors, at least for this kind of
work.

I think it comes down to whether Symantec is willing to share these
internal business records, and whether browser vendors want to
implement the whitelisting.

[Jeffrey Yasskin]

Post by Ryan Sleevi

Post by b***@gmail.com
(just to be super clear I'm writing this in a personal capacity and not
representing the thoughts of my employer)
As a developer I feel like this plan might be excessively confusing.
Given this list of dates, how would I calculate when I have to do
something? Do I even remember when my cert was issued? Also, this process
seems to aim at a gradual breakage, but from a developer's perspective this
is not gradual -- I own a single site, and during one of the chrome
releases my site will break the day that release goes to stable.

This is the unfortunate reality of the CA ecosystem, in which the trust
afforded to any given site is binary, but the trust afforded to a CA is
expressed in gradations, dependent upon how the certificate was validated
and when it was validated.
The simple answer would be that, if adopted by Blink OWNERS, then to
minimize all parties should strive to replace their certificates with
versions whose validity period is less than or equal to 279 days (9
months). By replacing the existing certificates with such a certificate,
there should be no negative effect. The remaining dates relate to a
ratcheting enforcement that attempts to minimize the breakage from any
given release.
Alternatively, should it be that measuring by validity period represents
too great an ecosystem concern, an alternative approach would be to express
this requirement as "The certificate was issued on or after this date" -
such as Chrome 59 rejecting certificates issued prior to 1023 days than the
current date. This approach would replace certificates in batches based on
issuance. Accompanied with a requirement that certificates issued on or
after the proposed Chrome 61 'open' date (the day on or after the Chrome 60
"branch" date of May 25, 2017) have validity periods less than or equal to
9 months, this would also see the eventual harmonization of nine month
validity, but affect a different population of certificates.
Would such an approach be easier to understand and communicate?

Post by b***@gmail.com
Did you guys consider something where there would be an escalating level
of distrust (eg, in one version you get a warning rather than a green lock,
the next release a red not secure, then a intersticial)? This would allow
attentive operators who might not hear about this change otherwise to
figure out that there is an issue before their site breaks completely. It
also gives all parties involved a small number of times where they can
promote this change.

Yes, this was considered. This is similar to the approach used with SHA-1
deprecation, but in this case, may cause undesired security risk, in that
such certificates continue to be used, and thus private information (such
as cookies) are still transmitted, and privileged features (such as
geolocation) may still be enabled. This proposal was an attempt to balance
those security concerns with the interoperability and compatibility risk.

Both the original proposal and the SHA-1-like suggestion allow unwanted
certificates to be used for some time; they just differ on which
certificates and what kind of use.

Original proposal:
Chrome 59 (Dev, Beta, Stable): 34-39 months blocked; 10-33 allowed
Chrome 60 (Dev, Beta, Stable): 28-39 months blocked; 10-27 allowed
Chrome 61 (Dev, Beta, Stable): 22-39 months blocked; 10-21 allowed
Chrome 62 (Dev, Beta, Stable): 16-39 months blocked; 10-15 allowed
Chrome 63 (Dev, Beta): 10-39 months blocked; no unwanted certificates
allowed
Chrome 63 (Stable): 16-39 months blocked; 10-15 allowed15 months validity
(465 days)
Chrome 64 (Dev, Beta, Stable): 10-39 months blocked; no unwanted
certificates allowed

SHA-1-like, elaborated with a schedule the same length as the OP. I have no
idea if keeping the same schedule makes sense when the escalation proceeds
along a different axis, and I trust Ryan to change it appropriately.

Chrome 59 (Dev, Beta, Stable): 10-39 months treated as passive mixed
content; 10-39 months allowed to use [SecureContext] APIs
Chrome 60 (Dev, Beta, Stable): same
Chrome 61 (Dev, Beta, Stable): 10-39 months treated as HTTP, not allowed to
use [SecureContext] APIs. 10-39 months allowed to load.
Chrome 62 (Dev, Beta, Stable): same
Chrome 63 (Dev, Beta): 10-39 months blocked; no unwanted certificates
allowed
Chrome 63 (Stable): same as 62
Chrome 64 (Dev, Beta, Stable): 10-39 months blocked; no unwanted
certificates allowed

This schedule concentrates the breakage for Chrome in 61 and in 64, but
gives each site a longer time to notice and deal with their problems.

One could imagine combining the two schedules, to completely block
long-validity certs earlier, but also remove the lock from 10-21-month
certs more quickly in order to warn site operators.

HTH,
Jeffrey

[Ryan Sleevi]

Is it really necessary to base this on a browser release process?

Note: https://github.com/sleevi/explainer/blob/master/README.md proposes an
explanation for the algorithm that may hopefully help.

new_expiry = April 1st 2017 + (old_expiry_date - April 1st 2017) / 3
lose_ev_status_date = April 1st 2017 + (old_expiry_date - April 1st 2017)
/ 4
lose_padlock_ui_date = April 1st 2017 + (old_expiry_date - April 1st 2017)
/ 5
warn_in_console_date = April 1st 2017 + (old_expiry_date - April 1st 2017)
/ 6
Code could be the same in all browser versions, there is no sudden cutoff
date where lots of sites break, and everyone gets warned first and sees a
gradual decline in functionality.
What are the downsides to this approach?

There are indeed considerable benefits to an algorithmically expressed
scale. There is also considerable difficulty in understanding how and when
it will affect certificates, especially as they scale through. The
algorithm at https://github.com/sleevi/explainer/blob/master/README.md
tries to find an appropriate balance between being discoverable and
noticable during each release cycle - thus improving awareness - while
still allowing a stepped process to allow site operators to find the
appropriate balance for their needs and their needs of their users.

Regarding other warnings, I defer to my very esteemed UI colleagues, but a
considerable amount of work and research has been placed into decreasing
the number of distinct warning states. While it has a very appealing
benefit at first blush, their continued explorations into this problem have
historically steered away from such approaches. This is in the service of
best serving and security users and web developers.

The Security Panel helpfully provides a central place to explain such
warnings, if they should happen, and that may address some of the other
elements of this proposal.

[l***@gmail.com]

Whatever deprecation dates algorithm end up being implemented, can we have a webpage that allows website owners to input a hostname or a pem certificate and the page should download the certificates used by that site, verify if the site is affected, and calculate that websites' specific early expiration dates and the dates they'll lose security indicators/secure context APIs.

This should reduce confusions of what websites administrators should do and when.

[t***@gmail.com]

I would like more details on the issues. "...allowed least four parties
access to their infrastructure in a way to cause certificate issuance..."
is pretty vague. Did these 4 parties then issue 30,000 certificates? What's
wrong with these certificates exactly?

The issues previously known are 1) "test" certificates issued without
domain owner's consent, though Symantec claimed that they were only used
internally; 2) certificates issued for unregistered domains.

Google Internet Authority G2 CA that issues many of Google's TLS
certificates is signed by GeoTrust Global CA, which presumably is owned by
Symantec now. So do Google's own certificates fall into the "gradually
untrustworthy" category?

[j***@gerhardt.link]

Google semi-recently purchased a trusted root ca certificate.

[Ryan Sleevi]

Post by t***@gmail.com
I would like more details on the issues. "...allowed least four parties
access to their infrastructure in a way to cause certificate issuance..."
is pretty vague. Did these 4 parties then issue 30,000 certificates? What's
wrong with these certificates exactly?
The issues previously known are 1) "test" certificates issued without
domain owner's consent, though Symantec claimed that they were only used
internally; 2) certificates issued for unregistered domains.

Apologies for not including the fullness of details in the original report,
and this may hopefully address any confusion as to "why".

The initial problem report was reported publicly, through Mozilla's
dev.security.policy mailing list, at
https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/yvjS5leYCAAJ

In the course of understanding these issues, representatives of Mozilla and
Google both addressed follow-up questions to Symantec, as did broader
members of the community and peers of the Mozilla Root CA Certificate
module.

Symantec's replies are (generally) available at
https://bugzilla.mozilla.org/show_bug.cgi?id=1334377 and share further
details.

These entities are CrossCert (Korea Electronic Certificate
Authority), Certisign Certificatadora Digital, Certsuperior S. de R. L. de
C.V., and Certisur S.A.. Each of these entities were authorized by Symantec
to perform validation services for information within the certificate,
including organizational information and domain names. This process is
permitted by the Baseline Requirements, but requires both that the CA
accept liability for any issues that emerge through such a relationship,
and that the CA ensure these entities are appropriately audited to the
equivalent criteria for the validation roles that they perform, so that all
certificates issued meet a consistent level of quality.

As demonstrated through the information provided, these four entities did
not follow the appropriate practices or did not possess the appropriate and
necessary audits from the appropriate parties. Symantec has acknowledged
they were actively aware of this for at least one party, failed to disclose
this to root programs, and did not sever the relationship with this party.

In effect, each of these parties were able to effect issuance by validating
information improperly. At least 30,000 certificates were issued by these
parties, with no independent way to assess the compliance of these parties
to the expected standards. Further, these certificates cannot be
technically identified or distinguished from certificates where Symantec
performed the validation role. As a consequence, the insufficient
demonstration of compliance, along with the inability to distinguish such
certificates, combined with the incomplete identification of the scope of
the issues, create a degree of uncertainty related to the entire corpus of
certificates, for which the only meaningful way to restore that confidence
is to propose a gradual distrusting of the existing certificates, so that
all new certificates are fully validated according to the appropriate
standards.

The supporting information related to further claims can be founded within
the above linked thread and the formal responses.

Post by t***@gmail.com
Google Internet Authority G2 CA that issues many of Google's TLS
certificates is signed by GeoTrust Global CA, which presumably is owned by
Symantec now. So do Google's own certificates fall into the "gradually
untrustworthy" category?

As discovered during the follow-up of a previous incident -
https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html
- Symantec has cross-signed two organizations who operate wholly
independent infrastructure that is audited as such - Apple and Google. This
is documented at
https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/README.md

As such, these certificates are not "Symantec-issued", for any reasonable
definition, and are effectively operated by independent third parties, and
thus would be proposed to be excluded from these requirements.

This evaluation of trust is not based upon an intrinsic property, but on
the public disclosure and ability to independently confirm and assess the
policies and practices related to issuance by these two parties.

[y***@hotmail.com]

Post by t***@gmail.com
I would like more details on the issues. "...allowed least four parties
access to their infrastructure in a way to cause certificate issuance..."
is pretty vague. Did these 4 parties then issue 30,000 certificates? What's
wrong with these certificates exactly?
The issues previously known are 1) "test" certificates issued without
domain owner's consent, though Symantec claimed that they were only used
internally; 2) certificates issued for unregistered domains.
Google Internet Authority G2 CA that issues many of Google's TLS
certificates is signed by GeoTrust Global CA, which presumably is owned by
Symantec now. So do Google's own certificates fall into the "gradually
untrustworthy" category?

Interestingly, many are 90 days valid, but not all of them (for example,
Nest).

[m***@gmail.com]

When will we know if these proposals are accepted and will become reality?

Post by Ryan Sleevi
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)
Chrome 62 (Dev, Beta, Stable): 15 months validity (465 days)
Chrome 63 (Dev, Beta): 9 months validity (279 days)
Chrome 63 (Stable): 15 months validity (465 days)
Chrome 64 (Dev, Beta, Stable): 9 months validity (279 days)
The proposed schedule attempts to avoid making changes in Chrome 63
Stable, as that would be released during the winter holiday production
freeze many organizations undergo. This is solely to reduce disruption for
site operators and users, and attempts to resume with Chrome 64 following
the holiday season. Further, the practical impact of the changes in Chrome
59 and 60 are relatively minimal, due to many of the certificates issued
during that period of time being issued using SHA-1, which is no longer
supported for certificates in Chrome.
In addition, we propose to require that all newly-issued certificates must
have validity periods of no greater than 9 months (279 days) in order to be
trusted in Google Chrome, effective Chrome 61. This ensures that the risk
of any further misissuance is, at most, limited to nine months, and more
importantly, that if any further action is warranted or necessary, that the
entire ecosystem can migrate within that time period, thus minimizing the
risk of further compatibility issues.
By combining these two steps, we can ensure that the level of assurance in
Symantec-issued certificates is able to match what is expected by Google
Chrome and the ecosystem, and that the risks posed both from past and
possible future misissuance is minimized as much as possible.
Given the nature of these issues, and the multiple failures of Symantec to
ensure that the level of assurance provided by their certificates meets the
requirements of the Baseline Requirements or Extended Validation
Guidelines, we no longer have the confidence necessary in order to grant
Symantec-issued certificates the “Extended Validation” status. As
documented with both the current and past misissuance, Symantec failed to
ensure that the organizational attributes, displayed within the address bar
for such certificates, meet the level of quality and validation required
for such display. Therefore, we propose to remove such indicators,
effective immediately, until Symantec is able to demonstrate the level of
sustained compliance necessary to grant such trust, which will be a period
no less than a year. After such time has passed, we will consider requests
from Symantec to re-evaluate this position, in collaboration with the
broader Chromium community.
Compatibility and Interoperability Risk
As with any reduction in trust in a Certificate Authority, this poses a
non-trivial degree of compatibility risk. This is because site operators
desire to have their certificates recognized in all client browsers, and if
one or more browsers fail to trust a given CA, this is prevented from
happening.
On the other hand, all site operators expect that certificates will only
be issued for their domains upon their request, and the failure to have
that assurance significantly undermines the security of HTTPS for both site
operators and users.
This compatibility risk is especially high for Symantec-issued
certificates, due to their acquisition of some of the first CAs, such as
Thawte, Verisign, and Equifax, which are some of the most widely supported
CAs. Distrusting such CAs creates further difficulty for providing secure
connections to both old and new devices alike, due to the need to ensure
the CA a site operator uses is recognized across these devices.
Further, the immediate distrust of a CA, as has been necessary in the
past, can significantly impact both site operators and users. Site
operators are forced to acquire certificates from other CAs, without having
the opportunity and time to research which CAs best meet their needs, and
users encounter a substantial number of errors until those site operators
act, conditioning them to ignore security warnings. In the event that only
a single browser distrusts such a CA, the error is often seen as the
browser’s fault, despite it being a failure of the CA to provide the
necessary level of assurance, and the site operator to respond in a timely
fashion.
Assessing the compatibility risk with both Edge and Safari is difficult,
because neither Microsoft nor Apple communicate publicly about their
changes in trust prior to enacting them.
While Mozilla conducts their discussions regarding Certificate Authorities
in public, and were the first to be alerted of these latest issues, they
have not yet begun discussion of the next steps to how best to protect
their users. Our hope is that this proposal may be seen as one that
appropriately balances the security and compatibility risks with the needs
of site operators, browsers, and users, and we welcome all feedback.
Alternative implementation suggestion for web developers
This proposal allows for web developers to continue to use Symantec issued
certificates, but will see their validity period reduced. This ensure that
web developers are aware of the risk and potential of future distrust of
Symantec-issued certificates, should additional misissuance events occur,
while also allowing them the flexibility to continue using such
certificates should it be necessary.
Usage information from UseCounter
<https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>
For a variety of non-technical reasons, we do not currently instrument the
usage of CAs. Further, few public metrics exist for intersecting usage
information with the validity period, since only certificates valid greater
than nine months will be affected outside of their normal replacement
cycle. From Mozilla Firefox’s Telemetry, we know that Symantec issued
certificates are responsible for 42% of certificate validations. However,
this number is not strictly an indicator for impact, as this number is
biased towards counting certificates for heavily-trafficked sites, and
whose issuance is fully automated and/or whose validity periods will be
unaffected, thus significantly overstating impact. By phasing such changes
in over a series of releases, we aim to minimize the impact any given
release poses, while still continually making progress towards restoring
the necessary level of security to ensure Symantec issued certificates are
as trustworthy as certificates from other CAs.

[Rik Cabanier]

Post by m***@gmail.com
When will we know if these proposals are accepted and will become reality?

Usually, once 3 blink owners send a lgtm (=looks good to me) to this email
thread, the intent is accepted and the engineer's changes will be accepted
into the chromium code base.

Post by m***@gmail.com

Post by Ryan Sleevi
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)
Chrome 62 (Dev, Beta, Stable): 15 months validity (465 days)
Chrome 63 (Dev, Beta): 9 months validity (279 days)
Chrome 63 (Stable): 15 months validity (465 days)
Chrome 64 (Dev, Beta, Stable): 9 months validity (279 days)
The proposed schedule attempts to avoid making changes in Chrome 63
Stable, as that would be released during the winter holiday production
freeze many organizations undergo. This is solely to reduce disruption for
site operators and users, and attempts to resume with Chrome 64 following
the holiday season. Further, the practical impact of the changes in Chrome
59 and 60 are relatively minimal, due to many of the certificates issued
during that period of time being issued using SHA-1, which is no longer
supported for certificates in Chrome.
In addition, we propose to require that all newly-issued certificates
must have validity periods of no greater than 9 months (279 days) in order
to be trusted in Google Chrome, effective Chrome 61. This ensures that the
risk of any further misissuance is, at most, limited to nine months, and
more importantly, that if any further action is warranted or necessary,
that the entire ecosystem can migrate within that time period, thus
minimizing the risk of further compatibility issues.
By combining these two steps, we can ensure that the level of assurance
in Symantec-issued certificates is able to match what is expected by Google
Chrome and the ecosystem, and that the risks posed both from past and
possible future misissuance is minimized as much as possible.
Given the nature of these issues, and the multiple failures of Symantec
to ensure that the level of assurance provided by their certificates meets
the requirements of the Baseline Requirements or Extended Validation
Guidelines, we no longer have the confidence necessary in order to grant
Symantec-issued certificates the “Extended Validation” status. As
documented with both the current and past misissuance, Symantec failed to
ensure that the organizational attributes, displayed within the address bar
for such certificates, meet the level of quality and validation required
for such display. Therefore, we propose to remove such indicators,
effective immediately, until Symantec is able to demonstrate the level of
sustained compliance necessary to grant such trust, which will be a period
no less than a year. After such time has passed, we will consider requests
from Symantec to re-evaluate this position, in collaboration with the
broader Chromium community.
Compatibility and Interoperability Risk
As with any reduction in trust in a Certificate Authority, this poses a
non-trivial degree of compatibility risk. This is because site operators
desire to have their certificates recognized in all client browsers, and if
one or more browsers fail to trust a given CA, this is prevented from
happening.
On the other hand, all site operators expect that certificates will only
be issued for their domains upon their request, and the failure to have
that assurance significantly undermines the security of HTTPS for both site
operators and users.
This compatibility risk is especially high for Symantec-issued
certificates, due to their acquisition of some of the first CAs, such as
Thawte, Verisign, and Equifax, which are some of the most widely supported
CAs. Distrusting such CAs creates further difficulty for providing secure
connections to both old and new devices alike, due to the need to ensure
the CA a site operator uses is recognized across these devices.
Further, the immediate distrust of a CA, as has been necessary in the
past, can significantly impact both site operators and users. Site
operators are forced to acquire certificates from other CAs, without having
the opportunity and time to research which CAs best meet their needs, and
users encounter a substantial number of errors until those site operators
act, conditioning them to ignore security warnings. In the event that only
a single browser distrusts such a CA, the error is often seen as the
browser’s fault, despite it being a failure of the CA to provide the
necessary level of assurance, and the site operator to respond in a timely
fashion.
Assessing the compatibility risk with both Edge and Safari is difficult,
because neither Microsoft nor Apple communicate publicly about their
changes in trust prior to enacting them.
While Mozilla conducts their discussions regarding Certificate
Authorities in public, and were the first to be alerted of these latest
issues, they have not yet begun discussion of the next steps to how best to
protect their users. Our hope is that this proposal may be seen as one that
appropriately balances the security and compatibility risks with the needs
of site operators, browsers, and users, and we welcome all feedback.
Alternative implementation suggestion for web developers
This proposal allows for web developers to continue to use Symantec
issued certificates, but will see their validity period reduced. This
ensure that web developers are aware of the risk and potential of future
distrust of Symantec-issued certificates, should additional misissuance
events occur, while also allowing them the flexibility to continue using
such certificates should it be necessary.
Usage information from UseCounter
<https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>
For a variety of non-technical reasons, we do not currently instrument
the usage of CAs. Further, few public metrics exist for intersecting usage
information with the validity period, since only certificates valid greater
than nine months will be affected outside of their normal replacement
cycle. From Mozilla Firefox’s Telemetry, we know that Symantec issued
certificates are responsible for 42% of certificate validations. However,
this number is not strictly an indicator for impact, as this number is
biased towards counting certificates for heavily-trafficked sites, and
whose issuance is fully automated and/or whose validity periods will be
unaffected, thus significantly overstating impact. By phasing such changes
in over a series of releases, we aim to minimize the impact any given
release poses, while still continually making progress towards restoring
the necessary level of security to ensure Symantec issued certificates are
as trustworthy as certificates from other CAs.

--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an

[h***@gmail.com]

Can you elaborate on how the gradual distrust will work? If a Symantec issued cert is valid for three years, will it be immediately treated as invalid if the validity period in Chrome 59 is 33 months?

Or will the 33 month validity period only allow the certificate to be valid for 33 months (and gradually decreasing) from the date of issue effectively ignoring the expiration date as issued?

[a***@gmail.com]

:/ the certificate for this blog is a geo-trust certificate.........

[l***@gmail.com]

Are there any plans to put the "View certificate" button back where it
belongs: "Click on the padlock, click on 'view certificate'"?

Half of the times F12 invokes a debugger, and it is counter-intuitive.not
just following the padlock.

[c***@gmail.com]

Disgusting abuse of your power! You are punishing 30,000 websites, 99.9%+
of whom are completely legitimate, in order to exact revenge against
Symantec.

LEAVE THE INNOCENT BYSTANDERS ALONE!!!!

I propose you block all *new* Symantec certificates until they go back and
re-validate (AT THEIR EXPENSE) all the 30,000 websites, and revoke any that
are found incorrect.

Be responsible with the power you have, and mindful of the massive
collateral damage your actions cause!

You've already just destroyed wosign and startssl wreaking havoc across
their entire user base: ***WE*** SUFFER when *you* attack CAs... so STOP
IT!!!!

[f***@gmail.com]

Post by c***@gmail.com
Disgusting abuse of your power! You are punishing 30,000 websites, 99.9%+
of whom are completely legitimate, in order to exact revenge against
Symantec.
LEAVE THE INNOCENT BYSTANDERS ALONE!!!!
I propose you block all *new* Symantec certificates until they go back and
re-validate (AT THEIR EXPENSE) all the 30,000 websites, and revoke any that
are found incorrect.
Be responsible with the power you have, and mindful of the massive
collateral damage your actions cause!
You've already just destroyed wosign and startssl wreaking havoc across
their entire user base: ***WE*** SUFFER when *you* attack CAs... so STOP
IT!!!!

yes, I agree with this, doesn't sound much fair what your proposed
solution. Are you aware this move will affect thousands of e-commerce sites
and related businesses??! Please, ponder your decision carefully and try to
find the best compromise for everyone here.

[t***@encirca.com]

Actually, this impacts ALL existing EV certs from Symantec. Not just the
30,000 that were improperly issued. right?

Post by f***@gmail.com

Post by c***@gmail.com
Disgusting abuse of your power! You are punishing 30,000 websites,
99.9%+ of whom are completely legitimate, in order to exact revenge against
Symantec.
LEAVE THE INNOCENT BYSTANDERS ALONE!!!!
I propose you block all *new* Symantec certificates until they go back
and re-validate (AT THEIR EXPENSE) all the 30,000 websites, and revoke any
that are found incorrect.
Be responsible with the power you have, and mindful of the massive
collateral damage your actions cause!
You've already just destroyed wosign and startssl wreaking havoc across
their entire user base: ***WE*** SUFFER when *you* attack CAs... so STOP
IT!!!!

yes, I agree with this, doesn't sound much fair what your proposed
solution. Are you aware this move will affect thousands of e-commerce sites
and related businesses??! Please, ponder your decision carefully and try to
find the best compromise for everyone here.

[a***@adamcaudill.com]

(Standard disclaimer: speaking on my own behalf, not that of my employer,
etc.)

Post by c***@gmail.com
Disgusting abuse of your power! You are punishing 30,000 websites

[...snip...]

Browsers have a substantial responsibility to protect their users, limiting
validity and otherwise placing restrictions on a CA is an important tool to
minimizing the harm that a CA can do. Browsers, on behalf of users, make
decisions about which CAs can be trusted and which ones can't - strict
rules and requirements are placed on CAs to ensure that they can be
trusted, if these rules are violated, that trust relationship is damaged.
If a browser loses faith in a CA, and the controls they have in place to
ensure that these requirements are met, they have a responsibility to their
users to take action.

If there are signs that controls are defective, if there are signs that a
significant number of certificates were issued in violation of these rules,
if there is reason to believe that the CA didn't discover issues when they
should have, or ignored issues they did discover - there is good reason to
lose faith in that CA and all of the certificates they've issued.

Post by c***@gmail.com
You've already just destroyed wosign and startssl [...snip...]

WoSign/StartSSL showed blatant disregard for the requirements placed on
CAs, and in doing so exposed not just their customers to additional risk,
but all users of browsers that trusted them. The browsers (not just Chrome)
took action to protect their users from such reckless action.

Removing trust, or restricting trust, in a CA is a serious action, with
impact to many; for those that operate TLS servers, that impact is often
additional work and financial costs, for users (the group browsers are
primarily responsible to), the impact is a reduction in risk. CAs that fail
their customers by not living up to their obligations should bear the
burden of the problems they've introduced, not the browsers that call them
out on it. In the case of WoSign, they knowingly performed actions that
violated their obligations - they created the situation, they are
responsible for failing their customers.

If you want to be mad at someone, be mad at CAs that violate the
requirements that keep users safe.

[c***@gmail.com]

I fail to see anything relevant you've said? Yes - we are all mad at
Symantec, and random google vigilante-employees want to cause extreme pain
and damage to that company: fair enough.

However: screwing over 30,000+ innocent bystanders IS NOT THE WAY TO DO IT.

The startcom issue was just one naughty certificate; the destruction of all
startcom user websites (including mine) was a decision google made to
punish startcom for lying about their business relationship with wosign.
This severely hurt huge numbers of innocent bystanders again, caused
irrevocable damage (no other CA offers unlimited wildcard SANs) and massive
costs (startcom were 10x+ less expensive that the greedy big American CAs
ripping us all of $millions for nothing more than a few DNS lookups and
crypto operations).

I'm not supporting Symantec, and not supporting startcom either.

I'm asking that you figure out who the bad guy is, and stop punching us
instead of them. The Google fist is a one-punch killer. Be
***responsible*** with how you wield that power. Execute just bad guy,
don't commit genocide!!!

[PhistucK]

Certificate authorities know they are responsible for the actions of the
companies that validate certificates for them. They must ensure that they
do not abuse their power. Constantly.

Think about it. If browsers do nothing, users may simply encounter websites
that pass the TLS validation, but are actually hosting the content of an
attacker and not the actual website.
Why do you expect browsers to jeopardize their users?
And how can browsers tell that the users are protected? They cannot know
whether a certain certificate is mis-issued (they can, by manually
validating every website, which is unreasonable).

The solution (which is known and common) is not to trust that certificate
authority.
Because distrusting it completely will ruin the internet (due to the very
large number of websites that use it), browsers are pretty much locked into
a really bad state where they have to gradually distrust it.
The safest thing to do would have been to just outright distrust it, but
then users would significantly suffer.

So this is a compromise. It is not a good one (it is not very safe), but it
is a compromise nonetheless.

Also, remember that the recommendation is to have a short-validity
certificate (the shorter the better), if I understand correctly. If
websites (or their certificate issuers) are not following the
recommendation, they should not be surprised when they have a bad time in a
way, right?
Note that this intent does not mention any future plan to completely
distrust Symantec, so following the recommendation would have actually
helped you not be impacted at all from those measures (barring extended
validation scenarios, that is).


☆*PhistucK*

Post by c***@gmail.com
I fail to see anything relevant you've said? Yes - we are all mad at
Symantec, and random google vigilante-employees want to cause extreme pain
and damage to that company: fair enough.
However: screwing over 30,000+ innocent bystanders IS NOT THE WAY TO DO IT.
The startcom issue was just one naughty certificate; the destruction of
all startcom user websites (including mine) was a decision google made to
punish startcom for lying about their business relationship with wosign.
This severely hurt huge numbers of innocent bystanders again, caused
irrevocable damage (no other CA offers unlimited wildcard SANs) and massive
costs (startcom were 10x+ less expensive that the greedy big American CAs
ripping us all of $millions for nothing more than a few DNS lookups and
crypto operations).
I'm not supporting Symantec, and not supporting startcom either.
I'm asking that you figure out who the bad guy is, and stop punching us
instead of them. The Google fist is a one-punch killer. Be
***responsible*** with how you wield that power. Execute just bad guy,
don't commit genocide!!!
--
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

[m***@megazone.org]

Post by c***@gmail.com
I fail to see anything relevant you've said? Yes - we are all mad at
Symantec, and random google vigilante-employees want to cause extreme pain
and damage to that company: fair enough.

You've completely missed the point. This is NOT about causing 'extreme
pain and damage' to Symantec. This is about *protecting ALL Chrome users!*

Post by c***@gmail.com
However: screwing over 30,000+ innocent bystanders IS NOT THE WAY TO DO IT.

It is the ONLY way to do it.

Post by c***@gmail.com
The startcom issue was just one naughty certificate; the destruction of
all startcom user websites (including mine) was a decision google made to
punish startcom for lying about their business relationship with wosign.
This severely hurt huge numbers of innocent bystanders again, caused
irrevocable damage (no other CA offers unlimited wildcard SANs) and massive
costs (startcom were 10x+ less expensive that the greedy big American CAs
ripping us all of $millions for nothing more than a few DNS lookups and
crypto operations).

None of that is Google's problem or responsibility. Startcom misbehaved
and destroyed trust in them. With a CA trust is all or nothing - once
they've shown themselves to be untrustworthy you can't trust *anything*
they've done. You MUST distrust ALL certs they've issued. Period. That's
how it works, like it or not.

Same with Symantec. There is no way for Google to individually validated
every cert that Symantec has issued. The point is not that they've done
30,000 suspicious certs - the point is that those 30,000 certs are strong
evidence that Symantec *has not been doing their job!* That means *ALL*
certs Symantec have issued are now suspect and potentially issued in error.
It is NOT just 30,000 certs - that's just what Google has found - it is
very likely many times that number, with the majority not having been
discovered yet.

Again, unfortunately this is how CAs work. The evidence is that Symantec
has not been doing their job correctly by not properly verifying the owners
when they issue certs. That's what being a CA is all about. If they've
failed in such a fundamental way, unfortunately it means you can't trust
them to have done it right in *any* case.

Yes, this means collateral damage in that valid owners who did nothing
wrong will need to get new certs. But this is not Google's fault nor their
problem - the blame falls 100% on Symantec. They sold themselves as a CA
and sold those certs base on being a *trusted* authority. By behaving in a
way that undermined that trust, they effectively defrauded their customers
by selling them certs with no backing. (When a CA issues a cert it all
rests on that CA being trusted.)

Google's responsibility is NOT to Symantec's customers - that's Symantec's
responsibility - but to their customers, aka Chrome users. To protect
their customers they must downgrade the trust given to Symantec's certs -
that's the ONLY viable option given the way the system works.

It seems like you just don't understand how the system is structured.
Google cannot simply block 'bad' certs, because they have no way to know
which certs are bad or not. That was Symantec's job - and they failed.
Google has to either trust Symantec to get it right and accept all of
their decisions, or not trust Symantec to get it right, and therefore NOT
trust their decisions. And the evidence shows they did NOT get it right.

Life is not always fair. It isn't the small site owners fault they trusted
Symantec, but if they get caught in the fallout they need to blame Symantec
- not Google. And they need to take their business elsewhere.

[c***@gmail.com]

Hard to tell if you're just trolling now.

Post by m***@megazone.org
This is about *protecting ALL Chrome users!*

This is not true.

Take for example online banks. 90% of them do not use HSTS or HPKP, and
more than half operate websites with no SSL whatsoever. If google honestly
wanted to protect users, they would deal with the massive security holes
that put users at risk, not fuss around with procedural squabbles. Lets
look at the big picture here: it's highly unlikely that even one single
Symantec cert will ever cause harm to anyone.

But that's not the point:

Attacking a teeny minority of PERFECTLY HONEST websites because you
disagree with their CA's procedures is not about protecting users. It's
about punishing Symantec but causing their customers the greatest amount of
pain possible.

Zero customers need to hurt here.

If google wanted - they could make Symantec fix the problem. The argument
is over issuance procedures: make them RE DO those procedures in an audited
an compliant way. Problem fixed: no collateral damage caused.

It appears like someone does not want to do that though: they want to cause
the maximum pain, and are disguising their vindictive attack under the fake
banner of "protect users".

Post by m***@megazone.org

Post by c***@gmail.com
However: screwing over 30,000+ innocent bystanders IS NOT THE WAY TO DO IT.

It is the ONLY way to do it.

Look in a mirror: that's an evil bully staring back at you. You know full
well this can be fixed without hurting customers, if google wanted to.

None of that is Google's problem or responsibility. Startcom misbehaved

Post by m***@megazone.org
and destroyed trust in them. With a CA trust is all or nothing - once
they've shown themselves to be untrustworthy you can't trust *anything*
they've done. You MUST distrust ALL certs they've issued. Period. That's
how it works, like it or not.

Pretend, for a moment, you live in a universe where you were not allowed to
hurt bystanders for the sins of the company they buy from.
... but it is still your job to fix the problem.
It's not impossible.
What would you do?

Post by m***@megazone.org
Life is not always fair. It isn't the small site owners fault they
trusted Symantec, but if they get caught in the fallout they need to blame
Symantec - not Google. And they need to take their business elsewhere.

Re-read that last sentence you wrote.
And again.
Google what "vindictive" means.

[Chris Palmer]

Hi all,

This is a difficult problem and to deal with it well we need, facts,
figures, and sound arguments. We also need civil discourse. Thanks.

[MegaZone]

Post by c***@gmail.com

Post by m***@megazone.org
This is about *protecting ALL Chrome users!*

This is not true.

You are, of course, entitled to your opinion.

Post by c***@gmail.com
Take for example online banks. 90% of them do not use HSTS or HPKP, and
more than half operate websites with no SSL whatsoever. If google honestly
wanted to protect users, they would deal with the massive security holes
that put users at risk, not fuss around with procedural squabbles. Lets
look at the big picture here: it's highly unlikely that even one single
Symantec cert will ever cause harm to anyone.

You're right. This has nothing to do with the subject at hand and was a
silly attempt at a red herring. Forcing the use of SSL/TLS is not at all
the same of ensuring it is trustworthy when it is used. If a user goes to
a non-secured site they're fully aware of that and it is their choice. If
they go to an SSL/TLS secured site they have a reasonable expectation of
security, and if a CA behaves in a way to undermine that it undermines the
entire system.

Post by c***@gmail.com
Attacking a teeny minority of PERFECTLY HONEST websites because you
disagree with their CA's procedures is not about protecting users. It's
about punishing Symantec but causing their customers the greatest amount of
pain possible.

Again, I disagree. It is about enforcing minimum standards. And yes, that
means Symantec's customers become leverage against them - in the end it is
all about money. Symantec doesn't seem to want to fix the issue, but if
they lose revenue they might change their mind and realize it's better
business to do the right thing. Unfortunately, this is what it often comes
down to. It isn't about causing pain, but the pain may be the only means
to achieve the end with an unwilling participant.

Post by c***@gmail.com
Zero customers need to hurt here.
If google wanted - they could make Symantec fix the problem. The argument
is over issuance procedures: make them RE DO those procedures in an audited
an compliant way. Problem fixed: no collateral damage caused.
It appears like someone does not want to do that though: they want to
cause the maximum pain, and are disguising their vindictive attack under
the fake banner of "protect users".

This *is* Google making Symantec fix the problem.

Did you miss the part where Google repeatedly approached Symantec about
this issue? Or that Symantec has even responded to this announcement by
basically brushing it off? Google cannot force Symantec to do anything,
Symantec has indicated they have no interest in fixing their broken
behavior. They seem to feel they're 'too big to fail' and that they can
just ignore this and Google will have to back off of this decision.

The ONLY option Google has in this case is to revoke their trust in
Symantec as a CA. If Symantec won't fix the issue then Google has to take
what action they can. That may cause Symantec to lose business, aka
revenue, as customers seek alternative certs. If the loss of business
looks like it is going to cost them more than the cost of fixing the issue,
then they may decide to do the right thing and fix the problem. But Google
cannot *force* anything - the choice is Symantec's, and so far they've
decided not to fix it.

Post by c***@gmail.com
Look in a mirror: that's an evil bully staring back at you. You know full
well this can be fixed without hurting customers, if google wanted to.

I'm happy with the man in the mirror.

The only way to 'fix' this would be to revoke ALL existing Symantec certs
and reissue them with proper verification. Only Symantec can do that, and
they've shown no interest in doing so. Probably because it would cost them
millions and they'd rather play chicken with Google and gamble they can get
away without spending the money than do right by their users. (There is a
reason I haven't used any Symantec products in years.) Like Ford and the
Pinto.

Post by c***@gmail.com
Pretend, for a moment, you live in a universe where you were not allowed
to hurt bystanders for the sins of the company they buy from.
... but it is still your job to fix the problem.
It's not impossible.
What would you do?

Try to work with the company to fix it. But if they refuse, well, I'd
still have to do the right thing and it might suck for the little guy - but
that's the lesser of two evils.

You seem to feel that Google should just let Symantec continue to misbehave
just to avoid inconveniencing the cert owners. I do not agree with that.
It is about more than this one CA. If Symantec is allowed to get away
with not fixing their behavior then it undermines the whole system, and why
should any other CA do any better if Symantec's approach is good enough?

Post by c***@gmail.com
Life is not always fair. It isn't the small site owners fault they

Post by m***@megazone.org
trusted Symantec, but if they get caught in the fallout they need to blame
Symantec - not Google. And they need to take their business elsewhere.

Re-read that last sentence you wrote.
And again.
Google what "vindictive" means.

You keep on using that word. I do not think it means what you think it
means.

It is not vindictive, it is reality. It is not about 'revenge' or
punishment, it is about fixing broken behavior. If Symantec won't do it
because it is the right thing to do, maybe they'll do it because not doing
it hurts their bottom line. That's just how the world works, and sometimes
the little guy gets caught in the process.

That's a shame, but again, that's all on Symantec for 1) not doing their
job in the first place and 2) not owning up to it and making it right when
it was discovered. If they had done *either* of these then we would have
never reached this point in the first place. Now the choice is either to
let them get away with it and undermine the system, or to take action to
protect the system by cutting out the rot. I'm in favor of the latter,
even if that means some good tissue has to be excised to make sure all of
the cancer is gone.

['Chris Palmer' via blink-dev]

This thread is going to be a centithread :) so let's try to keep it as
concise as possible. Please try to post only new information.

Also, the Chromium Code Of Conduct is a good document:
https://www.chromium.org/conduct

[Rick Byers]

On Fri, Mar 24, 2017 at 3:06 PM, 'Chris Palmer' via blink-dev <

Post by 'Chris Palmer' via blink-dev
This thread is going to be a centithread :) so let's try to keep it as
concise as possible. Please try to post only new information.
https://www.chromium.org/conduct

Thanks Chris. This debate is definitely an important one to be having in a
public and respectful fashion.

Since this is an issue that involves the whole web ecosystem, I'd
personally also encourage posts here which link to relevant discussion
elsewhere (even when that discussion elsewhere is not "as concise as
possible"). As a Blink API OWNER I'm certainly doing whatever I can to
read and digest all the history/debate on this topic across the various
locations. I'm sure we'll see several thoughtful blog/medium posts over
the coming week with different people's perspectives and I'm looking
forward to trying to digest them all ;-). I would not want to discourage
people from posting such links here to maximize visibility and diversity of
perspectives.

Ultimately this specific thread is about the chromium open source project
making a decision on whether Ryan's proposal meets our web platform change
guidelines around balancing compat/interop risk with benefit to the web.
But there's obviously a much larger set of discussions to be had across the
community around all of this which we should try not to conflate too much
with the specific question at hand here.

[c***@gmail.com]

Vindictive is taking action designed to force Symantec customers to "take
their business elsewhere" without properly exhausting "talks" and other
persuasive measures first.
If Symantec are non-compliant: stop trusting every certificate they issue
from today onward until they become complaint. That does not hurt
customers.
Easy. No collateral damage. If they still refuse (which I doubt, since
their income is halted until the comply), but if they still do, then AND
ONLY THEN, is it time to consider the collateral damage approach. The
problem still can be fixed without 3rd party pain at this point.

What exactly am I missing here?

I love the irony that an argument about how google is abusing it's
monopolistic power and causing pain to 30,000+ innocent webmaster (and
untold millions of end users) drew a "code of conduct" warning against me.
That conduct document embodies a spirit of behavior. I recommend we ALL
follow that spirit, not just with this discussion, but with we how all act
in resolving this situation.

[Florian Weimer]

Post by c***@gmail.com
If Symantec are non-compliant: stop trusting every certificate they issue
from today onward until they become complaint. That does not hurt
customers.

But isn't this actually more draconian?

Under your proposal, if a Symantec customer needed a new certificate,
they would have to switch at once to a different certificate
authority. This would require immediate business process changes on
the side of the customer. With the gradual decrease in certificate
lifetime, an immediate switch is not enforced.

[Adam Caudill]

Post by c***@gmail.com
I fail to see anything relevant you've said?

Thanks. Good to know.

Post by c***@gmail.com
[...snip...] destruction of all startcom user websites (including mine)

was a decision google made to punish startcom [...snip...]

I find it interesting that you place blame on Google, when all major
browsers took action, and Google's plan more or less mirrored the plan
Mozilla had already announced. [Apologies for the typo in the StartCom name
in my last email.]

When a CA violates their obligations, the browsers (all of them), have an
obligation to take action to protect their users. If there's no faith in
the controls that a CA has in place, as was the case with WoSign (including
StartCom), the only option left to browsers is to stop trusting the
certificates they've issued. Trusting certificates that are issued in
violation of CABF baseline requirements / root program requirements put
users at risk, that's why these requirements exist. You may take the
position that convenience / cheap certificates are more important that
ensuring the security of users, I don't.

I don't see an action against a CA as being a punishment against their
users, although the impact to them is quite unfortunate, but it is
unavoidable if the goal is to eliminate certificates that are of unknown
trust. When browsers loose faith in a CA, and their ability to comply with
the obligations they accept as being a CA, the only course of action is to
eliminate the untrusted certificates from the ecosystem and take steps to
ensure future compliance. It would be great if there was a way to easily
determine which certificates were issued in compliance with all
requirements, and only eliminate those that weren't - a problem that has
been discussed many times. Unfortunately, that's not always possible - when
that's not possible, that means all certificates that were issued by the CA
are suspect.

Post by c***@gmail.com
I'm not supporting Symantec

I'm not taking a position on them here, nor endorsing any plan of action
(nor will I); my point is that the browsers have an obligation to
eliminate or restrict the trust of CAs that have committed substantial
violations of the requirements they accepted. If the browsers have lost
faith in a CA, any CA, their obligation is to take actions to protect their
users and eliminate the untrusted certificates from the ecosystem.





--*Adam Caudill*
http://adamcaudill.com

Post by c***@gmail.com
I fail to see anything relevant you've said? Yes - we are all mad at
Symantec, and random google vigilante-employees want to cause extreme pain
and damage to that company: fair enough.
However: screwing over 30,000+ innocent bystanders IS NOT THE WAY TO DO IT.
The startcom issue was just one naughty certificate; the destruction of
all startcom user websites (including mine) was a decision google made to
punish startcom for lying about their business relationship with wosign.
This severely hurt huge numbers of innocent bystanders again, caused
irrevocable damage (no other CA offers unlimited wildcard SANs) and massive
costs (startcom were 10x+ less expensive that the greedy big American CAs
ripping us all of $millions for nothing more than a few DNS lookups and
crypto operations).
I'm not supporting Symantec, and not supporting startcom either.
I'm asking that you figure out who the bad guy is, and stop punching us
instead of them. The Google fist is a one-punch killer. Be
***responsible*** with how you wield that power. Execute just bad guy,
don't commit genocide!!!

[k***@gmail.com]

1. Is this an official release from Google. Do we take this seriously or
its just a blog.
2. Have you published the list of 30K websites. How do we trust this number
is valid. Is it exactly 30000?

Post by a***@adamcaudill.com
(Standard disclaimer: speaking on my own behalf, not that of my employer,
etc.)

Post by c***@gmail.com
Disgusting abuse of your power! You are punishing 30,000 websites

[...snip...]
Browsers have a substantial responsibility to protect their users,
limiting validity and otherwise placing restrictions on a CA is an
important tool to minimizing the harm that a CA can do. Browsers, on behalf
of users, make decisions about which CAs can be trusted and which ones
can't - strict rules and requirements are placed on CAs to ensure that they
can be trusted, if these rules are violated, that trust relationship is
damaged. If a browser loses faith in a CA, and the controls they have in
place to ensure that these requirements are met, they have a responsibility
to their users to take action.
If there are signs that controls are defective, if there are signs that a
significant number of certificates were issued in violation of these rules,
if there is reason to believe that the CA didn't discover issues when they
should have, or ignored issues they did discover - there is good reason to
lose faith in that CA and all of the certificates they've issued.

Post by c***@gmail.com
You've already just destroyed wosign and startssl [...snip...]

WoSign/StartSSL showed blatant disregard for the requirements placed on
CAs, and in doing so exposed not just their customers to additional risk,
but all users of browsers that trusted them. The browsers (not just Chrome)
took action to protect their users from such reckless action.
Removing trust, or restricting trust, in a CA is a serious action, with
impact to many; for those that operate TLS servers, that impact is often
additional work and financial costs, for users (the group browsers are
primarily responsible to), the impact is a reduction in risk. CAs that fail
their customers by not living up to their obligations should bear the
burden of the problems they've introduced, not the browsers that call them
out on it. In the case of WoSign, they knowingly performed actions that
violated their obligations - they created the situation, they are
responsible for failing their customers.
If you want to be mad at someone, be mad at CAs that violate the
requirements that keep users safe.

[b***@gmail.com]

I have read a few articles about this issue and read statements from both parties and all I have seen from Google seems to be inflated numbers without complete information about the 127 certificates that you seem to inflate to 30,000. Can you even explain where you get this 30,000 number from when Symantec's statement reads

"Google's statements about our issuance practices and the scope of our past mis-issuances are exaggerated and misleading," they wrote. "For example, Google’s claim that we have mis-issued 30,000 SSL/TLS certificates is not true. In the event Google is referring to, 127 certificates—not 30,000—were identified as mis-issued, and they resulted in no consumer harm. We have taken extensive remediation measures to correct this situation, immediately terminated the involved partner’s appointment as a registration authority (RA), and in a move to strengthen the trust of Symantec-issued SSL/TLS certificates, announced the discontinuation of our RA program."

No offense, but where are the numbers of other CA's so we have some comparison? I have heard Google use the word "transparency" but this is looking more like a witch hunt at this point.

[Ryan Sleevi]

Post by b***@gmail.com
I have read a few articles about this issue and read statements from both
parties and all I have seen from Google seems to be inflated numbers
without complete information about the 127 certificates that you seem to
inflate to 30,000. Can you even explain where you get this 30,000 number
from when Symantec's statement reads

https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/i70m8ptvCQAJ
hopefully sufficiently explains this.

Post by b***@gmail.com
No offense, but where are the numbers of other CA's so we have some
comparison? I have heard Google use the word "transparency" but this is
looking more like a witch hunt at this point.

I'm uncertain as to how to interpret your question, but I encourage you to
re-read the original message that explains the principles and concerns.

[g***@gmail.com]

If I understand correctly all existing Symantec-issued certificates with a 2 years validity period will be untrusted with September 12th Chrome release, whatever their Not Before date is. Am I right?

I yes, will that generate a big red untrusted certificate error, or will it just not show a green padlock ?

[Ryan Sleevi]

Post by g***@gmail.com
If I understand correctly all existing Symantec-issued certificates with a
2 years validity period will be untrusted with September 12th Chrome
release, whatever their Not Before date is. Am I right?
I yes, will that generate a big red untrusted certificate error, or will
it just not show a green padlock ?

Does https://github.com/sleevi/explainer/blob/master/README.md help explain
the proposed algorithm?

[g***@gmail.com]

Post by Ryan Sleevi
Does https://github.com/sleevi/explainer/blob/master/README.md help
explain the proposed algorithm?

Yes it does. Thanks!

I guess that by "return that the certificate is not valid" you mean big
ugly red alert?

[c***@gmail.com]

Google Chrome 浏览噚将敎治所有赛闚铁克 SSL/TLS 证乊
圚䞀仜[声明]䞭Google Chrome 团队匀发者 Ryan Sleevi 称发现赛闚铁克错误颁发䞉䞇倚䞪 SSL 证乊并䞔知晓后圚长蟟䞀䞪月的䞍䜜䞺Chrome 立即将赛闚铁克及其所属 CA 的颁发的 SSL EV 证乊浏览噚地址栏星瀺绿锁降级到普通证乊灰锁并圚未来几䞪版本的浏览噚曎新䞭逐步过期所有赛闚铁克证乊。赛闚铁克证乊占所有掻跃证乊数量的 30%45%劂果䞍是考虑到倧规暡瘫痪敎䞪眑络的风险Chrome 应该䞀倜闎吊销所有赛闚铁克证乊。
歀次事件圱响极倧囜内的䞃牛和阿里云等眑络巚倎已经圚过去䞀段时闎里颁发了无数䞪免莹赛闚铁克证乊。颁发及䜿甚赛闚铁克证乊的公叞应该立刻采取行劚曎换证乊。
Google的声明原文https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs

圚 2017幎3月24日星期五 UTC+8䞊午12:03:20Ryan Sleevi写道

Post by Ryan Sleevi
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)
Chrome 62 (Dev, Beta, Stable): 15 months validity (465 days)
Chrome 63 (Dev, Beta): 9 months validity (279 days)
Chrome 63 (Stable): 15 months validity (465 days)
Chrome 64 (Dev, Beta, Stable): 9 months validity (279 days)
The proposed schedule attempts to avoid making changes in Chrome 63
Stable, as that would be released during the winter holiday production
freeze many organizations undergo. This is solely to reduce disruption for
site operators and users, and attempts to resume with Chrome 64 following
the holiday season. Further, the practical impact of the changes in Chrome
59 and 60 are relatively minimal, due to many of the certificates issued
during that period of time being issued using SHA-1, which is no longer
supported for certificates in Chrome.
In addition, we propose to require that all newly-issued certificates must
have validity periods of no greater than 9 months (279 days) in order to be
trusted in Google Chrome, effective Chrome 61. This ensures that the risk
of any further misissuance is, at most, limited to nine months, and more
importantly, that if any further action is warranted or necessary, that the
entire ecosystem can migrate within that time period, thus minimizing the
risk of further compatibility issues.
By combining these two steps, we can ensure that the level of assurance in
Symantec-issued certificates is able to match what is expected by Google
Chrome and the ecosystem, and that the risks posed both from past and
possible future misissuance is minimized as much as possible.
Given the nature of these issues, and the multiple failures of Symantec to
ensure that the level of assurance provided by their certificates meets the
requirements of the Baseline Requirements or Extended Validation
Guidelines, we no longer have the confidence necessary in order to grant
Symantec-issued certificates the “Extended Validation” status. As
documented with both the current and past misissuance, Symantec failed to
ensure that the organizational attributes, displayed within the address bar
for such certificates, meet the level of quality and validation required
for such display. Therefore, we propose to remove such indicators,
effective immediately, until Symantec is able to demonstrate the level of
sustained compliance necessary to grant such trust, which will be a period
no less than a year. After such time has passed, we will consider requests
from Symantec to re-evaluate this position, in collaboration with the
broader Chromium community.
Compatibility and Interoperability Risk
As with any reduction in trust in a Certificate Authority, this poses a
non-trivial degree of compatibility risk. This is because site operators
desire to have their certificates recognized in all client browsers, and if
one or more browsers fail to trust a given CA, this is prevented from
happening.
On the other hand, all site operators expect that certificates will only
be issued for their domains upon their request, and the failure to have
that assurance significantly undermines the security of HTTPS for both site
operators and users.
This compatibility risk is especially high for Symantec-issued
certificates, due to their acquisition of some of the first CAs, such as
Thawte, Verisign, and Equifax, which are some of the most widely supported
CAs. Distrusting such CAs creates further difficulty for providing secure
connections to both old and new devices alike, due to the need to ensure
the CA a site operator uses is recognized across these devices.
Further, the immediate distrust of a CA, as has been necessary in the
past, can significantly impact both site operators and users. Site
operators are forced to acquire certificates from other CAs, without having
the opportunity and time to research which CAs best meet their needs, and
users encounter a substantial number of errors until those site operators
act, conditioning them to ignore security warnings. In the event that only
a single browser distrusts such a CA, the error is often seen as the
browser’s fault, despite it being a failure of the CA to provide the
necessary level of assurance, and the site operator to respond in a timely
fashion.
Assessing the compatibility risk with both Edge and Safari is difficult,
because neither Microsoft nor Apple communicate publicly about their
changes in trust prior to enacting them.
While Mozilla conducts their discussions regarding Certificate Authorities
in public, and were the first to be alerted of these latest issues, they
have not yet begun discussion of the next steps to how best to protect
their users. Our hope is that this proposal may be seen as one that
appropriately balances the security and compatibility risks with the needs
of site operators, browsers, and users, and we welcome all feedback.
Alternative implementation suggestion for web developers
This proposal allows for web developers to continue to use Symantec issued
certificates, but will see their validity period reduced. This ensure that
web developers are aware of the risk and potential of future distrust of
Symantec-issued certificates, should additional misissuance events occur,
while also allowing them the flexibility to continue using such
certificates should it be necessary.
Usage information from UseCounter
<https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>
For a variety of non-technical reasons, we do not currently instrument the
usage of CAs. Further, few public metrics exist for intersecting usage
information with the validity period, since only certificates valid greater
than nine months will be affected outside of their normal replacement
cycle. From Mozilla Firefox’s Telemetry, we know that Symantec issued
certificates are responsible for 42% of certificate validations. However,
this number is not strictly an indicator for impact, as this number is
biased towards counting certificates for heavily-trafficked sites, and
whose issuance is fully automated and/or whose validity periods will be
unaffected, thus significantly overstating impact. By phasing such changes
in over a series of releases, we aim to minimize the impact any given
release poses, while still continually making progress towards restoring
the necessary level of security to ensure Symantec issued certificates are
as trustworthy as certificates from other CAs.

[t***@tobireif.com]

Thank you for working towards trust and security.

I hope Symantec et al will fulfill the requirements in the future.

[p***@gmail.com]

Post by Ryan Sleevi
Summary
Since January 19, the Google Chrome team has been investigating a series
of failures by Symantec Corporation to properly validate certificates. As.

While I understand it is probably difficult to get consensus support for
punitive measures against an organisation that has entrenched itself so
deeply into the CA landscape by means of acquisition ('too big to fail'
mentality), care should be taken to try to avoid accusations of abuse of
market power by Google/the Chrome project, and so far Chrome seems to be
taking unilateral action. Is this the result of failed discussions within
the CA Browser Forum, or just a decision that the forum is moving too
slowly, or?

Has Symantec stopped the on-going abusive issuances?

Given a central plank of the justification for this proposal is how
Symantec have responded, what was unsatisfactory - specifically - about
Symantec's responses VS what was expected and is this documented anywhere
that can be reviewed?

[Ryan Sleevi]

Is this the result of failed discussions within the CA Browser Forum, or
just a decision that the forum is moving too slowly, or?

Please see https://cabforum.org/bylaws/

The CA/Browser Forum does not discuss such matters. It is an industry
organization devoted to facilitating communication between independent root
stores and the CA participants in those root stores in the collaborative
development of guidelines that can serve as a non-conflicting baseline for
certain types of issuance.

Each Browser member makes independent decisions about the trust afforded to
certificates they encounter and the certificate authorities they trust to
issue such certificates. For example, each member has their own distinct
policies regarding the certificates they trust, but all collectively agree
and collaborate on the minimum set of requirements for how certificates are
issued. These are subtle but significant distinctions.

Has Symantec stopped the on-going abusive issuances?

We should be careful here with such loaded questions. As worded, it's not
something I feel comfortable responding to.

Given a central plank of the justification for this proposal is how
Symantec have responded, what was unsatisfactory - specifically - about
Symantec's responses VS what was expected and is this documented anywhere
that can be reviewed?

This is available at
http://dev.chromium.org/Home/chromium-security/root-ca-policy

The information and replies, to the best of my knowledge at this time, are
available at the following URLs:
*
https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/yvjS5leYCAAJ
* https://bugzilla.mozilla.org/show_bug.cgi?id=1334377
* https://www.symantec.com/connect/blogs/symantec-backs-its-ca

[c***@gmail.com]

How do we get someone from google legal department involved?

It's not my job to reign in vigilantes, but it seems reasonable to expect
that much of the responses in this thread would make for troublesome
reading in a lawsuit which might well come from this action. Far too many
unsubstantiated allegations, and refusals to consider options, and other
worrying remarks: I don't know which ones are internet strangers or google
employees... if any are the latter: that's a huge problem.

[g***@devzero.com]

Post by Ryan Sleevi
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)
Chrome 62 (Dev, Beta, Stable): 15 months validity (465 days)
Chrome 63 (Dev, Beta): 9 months validity (279 days)
Chrome 63 (Stable): 15 months validity (465 days)
Chrome 64 (Dev, Beta, Stable): 9 months validity (279 days)

Is the intention to remove Symantec's CAs entirely in version 65, or do you
propose that Chromium continue to trust them to a degree despite their Root
Certificate Policy violations? The "too big to fail" argument above
explains the difference in approach from the last time
<https://bugs.chromium.org/p/chromium/issues/detail?id=661003> Chromium
dropped a CA, but it is not clear whether this is a gradual phase-out or a
special case in which Symantec retains a level of trust.

[Ryan Sleevi]

Post by g***@devzero.com
Is the intention to remove Symantec's CAs entirely in version 65, or do
you propose that Chromium continue to trust them to a degree despite their
Root Certificate Policy violations? The "too big to fail" argument above
explains the difference in approach from the last time
<https://bugs.chromium.org/p/chromium/issues/detail?id=661003> Chromium
dropped a CA, but it is not clear whether this is a gradual phase-out or a
special case in which Symantec retains a level of trust.

As (perhaps incompletely) explained in the initial message,
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ
, this only proposes a change in trust status related to the "existing"
Symantec-issued certificates, and describes a proposal on how to restore
that trust to sufficient levels, so as to avoid the need to distrust any
root CAs. Distrusting the root CA keys involved carries with it a
non-trivial degree of compatibility and interoperability risk, as
explained, and so this proposal is an attempt to find a balance between
that risk and the security needs of users and site operators - both those
that have Symantec-issued certificates and those that do not.

As explained earlier on this thread, while the set of 30,000 certificates
relate to those improperly validated by improperly supervised delegated
third parties, the inability to technically identify these certificates or
sufficiently independently assess that the issues are limited to these
certificates make it necessary to either accept an unknown security risk,
or to take appropriate measures, as proposed, to balance that risk. As
Symantec has already indicated they have terminated their relationship with
these partners regarding new certificate issuance, we have some degree of
assurance that new certificates will comply with the expected policies and
practices. As with any CA, there is an element of trust inherent in making
such a decision, but anything short of distrust inherently means to trust.
This proposal attempts to restore that trust to the sufficient and
necessary level, by describing a process and set of changes that can be
made to Chrome to provide a sufficient level of assurance, and to mitigate
further risks should that trust be found to be misplaced.

[r***@gmail.com]

So with both companies "reviewing" this...how much of this post is still
true? and where are the corresponding updates to reflect the current state
of this announcement?

Post by Ryan Sleevi
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)
Chrome 62 (Dev, Beta, Stable): 15 months validity (465 days)
Chrome 63 (Dev, Beta): 9 months validity (279 days)
Chrome 63 (Stable): 15 months validity (465 days)
Chrome 64 (Dev, Beta, Stable): 9 months validity (279 days)
The proposed schedule attempts to avoid making changes in Chrome 63
Stable, as that would be released during the winter holiday production
freeze many organizations undergo. This is solely to reduce disruption for
site operators and users, and attempts to resume with Chrome 64 following
the holiday season. Further, the practical impact of the changes in Chrome
59 and 60 are relatively minimal, due to many of the certificates issued
during that period of time being issued using SHA-1, which is no longer
supported for certificates in Chrome.
In addition, we propose to require that all newly-issued certificates must
have validity periods of no greater than 9 months (279 days) in order to be
trusted in Google Chrome, effective Chrome 61. This ensures that the risk
of any further misissuance is, at most, limited to nine months, and more
importantly, that if any further action is warranted or necessary, that the
entire ecosystem can migrate within that time period, thus minimizing the
risk of further compatibility issues.
By combining these two steps, we can ensure that the level of assurance in
Symantec-issued certificates is able to match what is expected by Google
Chrome and the ecosystem, and that the risks posed both from past and
possible future misissuance is minimized as much as possible.
Given the nature of these issues, and the multiple failures of Symantec to
ensure that the level of assurance provided by their certificates meets the
requirements of the Baseline Requirements or Extended Validation
Guidelines, we no longer have the confidence necessary in order to grant
Symantec-issued certificates the “Extended Validation” status. As
documented with both the current and past misissuance, Symantec failed to
ensure that the organizational attributes, displayed within the address bar
for such certificates, meet the level of quality and validation required
for such display. Therefore, we propose to remove such indicators,
effective immediately, until Symantec is able to demonstrate the level of
sustained compliance necessary to grant such trust, which will be a period
no less than a year. After such time has passed, we will consider requests
from Symantec to re-evaluate this position, in collaboration with the
broader Chromium community.
Compatibility and Interoperability Risk
As with any reduction in trust in a Certificate Authority, this poses a
non-trivial degree of compatibility risk. This is because site operators
desire to have their certificates recognized in all client browsers, and if
one or more browsers fail to trust a given CA, this is prevented from
happening.
On the other hand, all site operators expect that certificates will only
be issued for their domains upon their request, and the failure to have
that assurance significantly undermines the security of HTTPS for both site
operators and users.
This compatibility risk is especially high for Symantec-issued
certificates, due to their acquisition of some of the first CAs, such as
Thawte, Verisign, and Equifax, which are some of the most widely supported
CAs. Distrusting such CAs creates further difficulty for providing secure
connections to both old and new devices alike, due to the need to ensure
the CA a site operator uses is recognized across these devices.
Further, the immediate distrust of a CA, as has been necessary in the
past, can significantly impact both site operators and users. Site
operators are forced to acquire certificates from other CAs, without having
the opportunity and time to research which CAs best meet their needs, and
users encounter a substantial number of errors until those site operators
act, conditioning them to ignore security warnings. In the event that only
a single browser distrusts such a CA, the error is often seen as the
browser’s fault, despite it being a failure of the CA to provide the
necessary level of assurance, and the site operator to respond in a timely
fashion.
Assessing the compatibility risk with both Edge and Safari is difficult,
because neither Microsoft nor Apple communicate publicly about their
changes in trust prior to enacting them.
While Mozilla conducts their discussions regarding Certificate Authorities
in public, and were the first to be alerted of these latest issues, they
have not yet begun discussion of the next steps to how best to protect
their users. Our hope is that this proposal may be seen as one that
appropriately balances the security and compatibility risks with the needs
of site operators, browsers, and users, and we welcome all feedback.
Alternative implementation suggestion for web developers
This proposal allows for web developers to continue to use Symantec issued
certificates, but will see their validity period reduced. This ensure that
web developers are aware of the risk and potential of future distrust of
Symantec-issued certificates, should additional misissuance events occur,
while also allowing them the flexibility to continue using such
certificates should it be necessary.
Usage information from UseCounter
<https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>
For a variety of non-technical reasons, we do not currently instrument the
usage of CAs. Further, few public metrics exist for intersecting usage
information with the validity period, since only certificates valid greater
than nine months will be affected outside of their normal replacement
cycle. From Mozilla Firefox’s Telemetry, we know that Symantec issued
certificates are responsible for 42% of certificate validations. However,
this number is not strictly an indicator for impact, as this number is
biased towards counting certificates for heavily-trafficked sites, and
whose issuance is fully automated and/or whose validity periods will be
unaffected, thus significantly overstating impact. By phasing such changes
in over a series of releases, we aim to minimize the impact any given
release poses, while still continually making progress towards restoring
the necessary level of security to ensure Symantec issued certificates are
as trustworthy as certificates from other CAs.

[Ryan Sleevi]

Post by r***@gmail.com
So with both companies "reviewing" this...how much of this post is still
true? and where are the corresponding updates to reflect the current state
of this announcement?

Could you clarify your question? What do you mean by "reviewing" this? What
do you believe to be inaccurate?

Perhaps there's confusion related to the Blink Process, described broadly
at https://www.chromium.org/blink and more specifically
https://www.chromium.org/blink#TOC-Web-Platform-Changes:-Process as to how
the Blink API owners seek to balance the compatibility and interoperability
risks to the Web Platform, based on the available data.

As Rick Byers captured in
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/SsLH5haOCQAJ
, and as explained in the Note in
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ
, this is an attempt to explore using this process for Web PKI changes, as
has been done for other aspects of the Web Platform that affect the various
constituencies (users, authors/site operators, implementors/browsers, spec
authors, theoretical purity)

This process is designed to ensure the principles captured in
https://www.w3.org/TR/html-design-principles/ are best adhered to. While
this document may have been written in the context of the HTML
specification, it broadly captures the concerns of user agents, which as a
result touches on a variety of systems and teams, which include both that
of networking and security. It may be that the Blink Process is not a
suitable process for these types of security policy changes, but the hope
is that this public process that allows sharing of data that informs and
assesses the compatibility and interoperability risk from any change in any
part of the Web Platform may be useful for both this and potentially future
incidents.

[r***@gmail.com]

I think your post at 3:12p provides the context I was looking for. It
seems this post was made,then Symantec had a response which Google said was
appreciated and discussion would continue. I wanted to get the current
status of this topic.

From 3:12p....
"As (perhaps incompletely) explained in the initial message,
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ ,
this only proposes a change in trust status related to the "existing"
Symantec-issued certificates, and describes a proposal on how to restore
that trust to sufficient levels, so as to avoid the need to distrust any
root CAs. ..."

Thank you for all of your responses since the original post.

Post by Ryan Sleevi

Post by r***@gmail.com
So with both companies "reviewing" this...how much of this post is still
true? and where are the corresponding updates to reflect the current state
of this announcement?

Could you clarify your question? What do you mean by "reviewing" this?
What do you believe to be inaccurate?
Perhaps there's confusion related to the Blink Process, described broadly
at https://www.chromium.org/blink and more specifically
https://www.chromium.org/blink#TOC-Web-Platform-Changes:-Process as to
how the Blink API owners seek to balance the compatibility and
interoperability risks to the Web Platform, based on the available data.
As Rick Byers captured in
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/SsLH5haOCQAJ
, and as explained in the Note in
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ
, this is an attempt to explore using this process for Web PKI changes, as
has been done for other aspects of the Web Platform that affect the various
constituencies (users, authors/site operators, implementors/browsers, spec
authors, theoretical purity)
This process is designed to ensure the principles captured in
https://www.w3.org/TR/html-design-principles/ are best adhered to. While
this document may have been written in the context of the HTML
specification, it broadly captures the concerns of user agents, which as a
result touches on a variety of systems and teams, which include both that
of networking and security. It may be that the Blink Process is not a
suitable process for these types of security policy changes, but the hope
is that this public process that allows sharing of data that informs and
assesses the compatibility and interoperability risk from any change in any
part of the Web Platform may be useful for both this and potentially future
incidents.

[p***@gmail.com]

Apologies if my input is not wanted, but in the role as a regular user:
I'd like a quicker _permanent_ discontinuation of the Symantec
certificates. They've clearly not lived up to their responisibility as CA.
As a user i'd like to see them loose the ability to issue trusted
certificates. They clearly have the responsibility for erroneously issued
certificates which they should have caught in internal reviews.
Might i suggest i accordance with ***@gmail.com's post that EV status
is removed from Symantecs' certificates immediately (or chrome 58), and
that "secure" stuatus is removed from chrome 59. Insecure status for all Symantec
certificates after chrome 60.
This would provide a somewhat resonable timeframe to migrate to another CA.
Symantec seems to me a clear case of a CA that is untrustworthy.
Ive read all the reponses from symantech, and all it amounts to is blaming
E&Y for the responsibilities which symantech should bear.
Regards

Post by Ryan Sleevi
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)
Chrome 62 (Dev, Beta, Stable): 15 months validity (465 days)
Chrome 63 (Dev, Beta): 9 months validity (279 days)
Chrome 63 (Stable): 15 months validity (465 days)
Chrome 64 (Dev, Beta, Stable): 9 months validity (279 days)
The proposed schedule attempts to avoid making changes in Chrome 63
Stable, as that would be released during the winter holiday production
freeze many organizations undergo. This is solely to reduce disruption for
site operators and users, and attempts to resume with Chrome 64 following
the holiday season. Further, the practical impact of the changes in Chrome
59 and 60 are relatively minimal, due to many of the certificates issued
during that period of time being issued using SHA-1, which is no longer
supported for certificates in Chrome.
In addition, we propose to require that all newly-issued certificates must
have validity periods of no greater than 9 months (279 days) in order to be
trusted in Google Chrome, effective Chrome 61. This ensures that the risk
of any further misissuance is, at most, limited to nine months, and more
importantly, that if any further action is warranted or necessary, that the
entire ecosystem can migrate within that time period, thus minimizing the
risk of further compatibility issues.
By combining these two steps, we can ensure that the level of assurance in
Symantec-issued certificates is able to match what is expected by Google
Chrome and the ecosystem, and that the risks posed both from past and
possible future misissuance is minimized as much as possible.
Given the nature of these issues, and the multiple failures of Symantec to
ensure that the level of assurance provided by their certificates meets the
requirements of the Baseline Requirements or Extended Validation
Guidelines, we no longer have the confidence necessary in order to grant
Symantec-issued certificates the “Extended Validation” status. As
documented with both the current and past misissuance, Symantec failed to
ensure that the organizational attributes, displayed within the address bar
for such certificates, meet the level of quality and validation required
for such display. Therefore, we propose to remove such indicators,
effective immediately, until Symantec is able to demonstrate the level of
sustained compliance necessary to grant such trust, which will be a period
no less than a year. After such time has passed, we will consider requests
from Symantec to re-evaluate this position, in collaboration with the
broader Chromium community.
Compatibility and Interoperability Risk
As with any reduction in trust in a Certificate Authority, this poses a
non-trivial degree of compatibility risk. This is because site operators
desire to have their certificates recognized in all client browsers, and if
one or more browsers fail to trust a given CA, this is prevented from
happening.
On the other hand, all site operators expect that certificates will only
be issued for their domains upon their request, and the failure to have
that assurance significantly undermines the security of HTTPS for both site
operators and users.
This compatibility risk is especially high for Symantec-issued
certificates, due to their acquisition of some of the first CAs, such as
Thawte, Verisign, and Equifax, which are some of the most widely supported
CAs. Distrusting such CAs creates further difficulty for providing secure
connections to both old and new devices alike, due to the need to ensure
the CA a site operator uses is recognized across these devices.
Further, the immediate distrust of a CA, as has been necessary in the
past, can significantly impact both site operators and users. Site
operators are forced to acquire certificates from other CAs, without having
the opportunity and time to research which CAs best meet their needs, and
users encounter a substantial number of errors until those site operators
act, conditioning them to ignore security warnings. In the event that only
a single browser distrusts such a CA, the error is often seen as the
browser’s fault, despite it being a failure of the CA to provide the
necessary level of assurance, and the site operator to respond in a timely
fashion.
Assessing the compatibility risk with both Edge and Safari is difficult,
because neither Microsoft nor Apple communicate publicly about their
changes in trust prior to enacting them.
While Mozilla conducts their discussions regarding Certificate Authorities
in public, and were the first to be alerted of these latest issues, they
have not yet begun discussion of the next steps to how best to protect
their users. Our hope is that this proposal may be seen as one that
appropriately balances the security and compatibility risks with the needs
of site operators, browsers, and users, and we welcome all feedback.
Alternative implementation suggestion for web developers
This proposal allows for web developers to continue to use Symantec issued
certificates, but will see their validity period reduced. This ensure that
web developers are aware of the risk and potential of future distrust of
Symantec-issued certificates, should additional misissuance events occur,
while also allowing them the flexibility to continue using such
certificates should it be necessary.
Usage information from UseCounter
<https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>
For a variety of non-technical reasons, we do not currently instrument the
usage of CAs. Further, few public metrics exist for intersecting usage
information with the validity period, since only certificates valid greater
than nine months will be affected outside of their normal replacement
cycle. From Mozilla Firefox’s Telemetry, we know that Symantec issued
certificates are responsible for 42% of certificate validations. However,
this number is not strictly an indicator for impact, as this number is
biased towards counting certificates for heavily-trafficked sites, and
whose issuance is fully automated and/or whose validity periods will be
unaffected, thus significantly overstating impact. By phasing such changes
in over a series of releases, we aim to minimize the impact any given
release poses, while still continually making progress towards restoring
the necessary level of security to ensure Symantec issued certificates are
as trustworthy as certificates from other CAs.

[v***@gmail.com]

Hi there,

In your post, you mentioned customer using Symantec EV cert will be
downgrade to standard cert and advice customer to change CA or replace the
certificate.
Since Google is not a CA, could you please explain how did Google identify
this issue and what exactly is the problem?
Is the certificate not safe or compromised?
What could be the harmful if we continue use Symantec certificate?
Considering the time and effort it takes to replace the certificate on all
our servers/applications, we'd prefer to keep the existing certificates.
So far other Browsers such as IE or Firefox have not posted any comment
about this misissuance issue, does it mean if we inform the customer to use
IE and Firefox, our certificate will continue to work?
Besides how do we know which CA is trusted, did GOOGLE only find issue with
Symantec not any other CA?

cheers

[t***@tobireif.com]

Post by v***@gmail.com
[...]
Since Google is not a CA

Google is a CA:

https://encrypted.google.com/search?q=google+certificate+authority
https://pki.goog/index.html

Post by v***@gmail.com
[...]

So far other Browsers such as [...] Firefox have not posted any comment

Post by v***@gmail.com
about this misissuance issue

"mozilla.dev.security.policy
<https://groups.google.com/forum/#!forum/mozilla.dev.security.policy>":

https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/fyJ3EK2YOP8/yvjS5leYCAAJ

https://bugzilla.mozilla.org/show_bug.cgi?id=1334377

Tobi

[p***@gmail.com]

Hi Ryan

Symantec's Root CAs have also signed their intermediate Managed PKI
service, used for issuing internally-facing SSL certificates (several of my
past and current customers use them). The operational impact for these
customers could be substantial (particularly where those customers have yet
to implement automation processes).

Is there any consideration for lowering the impacts on the Managed PKI
intermediate authorities?

Regards

- Skip

Post by Ryan Sleevi
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)
Chrome 62 (Dev, Beta, Stable): 15 months validity (465 days)
Chrome 63 (Dev, Beta): 9 months validity (279 days)
Chrome 63 (Stable): 15 months validity (465 days)
Chrome 64 (Dev, Beta, Stable): 9 months validity (279 days)
The proposed schedule attempts to avoid making changes in Chrome 63
Stable, as that would be released during the winter holiday production
freeze many organizations undergo. This is solely to reduce disruption for
site operators and users, and attempts to resume with Chrome 64 following
the holiday season. Further, the practical impact of the changes in Chrome
59 and 60 are relatively minimal, due to many of the certificates issued
during that period of time being issued using SHA-1, which is no longer
supported for certificates in Chrome.
In addition, we propose to require that all newly-issued certificates must
have validity periods of no greater than 9 months (279 days) in order to be
trusted in Google Chrome, effective Chrome 61. This ensures that the risk
of any further misissuance is, at most, limited to nine months, and more
importantly, that if any further action is warranted or necessary, that the
entire ecosystem can migrate within that time period, thus minimizing the
risk of further compatibility issues.
By combining these two steps, we can ensure that the level of assurance in
Symantec-issued certificates is able to match what is expected by Google
Chrome and the ecosystem, and that the risks posed both from past and
possible future misissuance is minimized as much as possible.
Given the nature of these issues, and the multiple failures of Symantec to
ensure that the level of assurance provided by their certificates meets the
requirements of the Baseline Requirements or Extended Validation
Guidelines, we no longer have the confidence necessary in order to grant
Symantec-issued certificates the “Extended Validation” status. As
documented with both the current and past misissuance, Symantec failed to
ensure that the organizational attributes, displayed within the address bar
for such certificates, meet the level of quality and validation required
for such display. Therefore, we propose to remove such indicators,
effective immediately, until Symantec is able to demonstrate the level of
sustained compliance necessary to grant such trust, which will be a period
no less than a year. After such time has passed, we will consider requests
from Symantec to re-evaluate this position, in collaboration with the
broader Chromium community.
Compatibility and Interoperability Risk
As with any reduction in trust in a Certificate Authority, this poses a
non-trivial degree of compatibility risk. This is because site operators
desire to have their certificates recognized in all client browsers, and if
one or more browsers fail to trust a given CA, this is prevented from
happening.
On the other hand, all site operators expect that certificates will only
be issued for their domains upon their request, and the failure to have
that assurance significantly undermines the security of HTTPS for both site
operators and users.
This compatibility risk is especially high for Symantec-issued
certificates, due to their acquisition of some of the first CAs, such as
Thawte, Verisign, and Equifax, which are some of the most widely supported
CAs. Distrusting such CAs creates further difficulty for providing secure
connections to both old and new devices alike, due to the need to ensure
the CA a site operator uses is recognized across these devices.
Further, the immediate distrust of a CA, as has been necessary in the
past, can significantly impact both site operators and users. Site
operators are forced to acquire certificates from other CAs, without having
the opportunity and time to research which CAs best meet their needs, and
users encounter a substantial number of errors until those site operators
act, conditioning them to ignore security warnings. In the event that only
a single browser distrusts such a CA, the error is often seen as the
browser’s fault, despite it being a failure of the CA to provide the
necessary level of assurance, and the site operator to respond in a timely
fashion.
Assessing the compatibility risk with both Edge and Safari is difficult,
because neither Microsoft nor Apple communicate publicly about their
changes in trust prior to enacting them.
While Mozilla conducts their discussions regarding Certificate Authorities
in public, and were the first to be alerted of these latest issues, they
have not yet begun discussion of the next steps to how best to protect
their users. Our hope is that this proposal may be seen as one that
appropriately balances the security and compatibility risks with the needs
of site operators, browsers, and users, and we welcome all feedback.
Alternative implementation suggestion for web developers
This proposal allows for web developers to continue to use Symantec issued
certificates, but will see their validity period reduced. This ensure that
web developers are aware of the risk and potential of future distrust of
Symantec-issued certificates, should additional misissuance events occur,
while also allowing them the flexibility to continue using such
certificates should it be necessary.
Usage information from UseCounter
<https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>
For a variety of non-technical reasons, we do not currently instrument the
usage of CAs. Further, few public metrics exist for intersecting usage
information with the validity period, since only certificates valid greater
than nine months will be affected outside of their normal replacement
cycle. From Mozilla Firefox’s Telemetry, we know that Symantec issued
certificates are responsible for 42% of certificate validations. However,
this number is not strictly an indicator for impact, as this number is
biased towards counting certificates for heavily-trafficked sites, and
whose issuance is fully automated and/or whose validity periods will be
unaffected, thus significantly overstating impact. By phasing such changes
in over a series of releases, we aim to minimize the impact any given
release poses, while still continually making progress towards restoring
the necessary level of security to ensure Symantec issued certificates are
as trustworthy as certificates from other CAs.

[l***@gmail.com]

On windows you are using system trusted root CA list. You moved certificate
info of current session to very not obvious place. It looks strange that
you are worrying about Symantec now.

Post by Ryan Sleevi
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)
Chrome 62 (Dev, Beta, Stable): 15 months validity (465 days)
Chrome 63 (Dev, Beta): 9 months validity (279 days)
Chrome 63 (Stable): 15 months validity (465 days)
Chrome 64 (Dev, Beta, Stable): 9 months validity (279 days)
The proposed schedule attempts to avoid making changes in Chrome 63
Stable, as that would be released during the winter holiday production
freeze many organizations undergo. This is solely to reduce disruption for
site operators and users, and attempts to resume with Chrome 64 following
the holiday season. Further, the practical impact of the changes in Chrome
59 and 60 are relatively minimal, due to many of the certificates issued
during that period of time being issued using SHA-1, which is no longer
supported for certificates in Chrome.
In addition, we propose to require that all newly-issued certificates must
have validity periods of no greater than 9 months (279 days) in order to be
trusted in Google Chrome, effective Chrome 61. This ensures that the risk
of any further misissuance is, at most, limited to nine months, and more
importantly, that if any further action is warranted or necessary, that the
entire ecosystem can migrate within that time period, thus minimizing the
risk of further compatibility issues.
By combining these two steps, we can ensure that the level of assurance in
Symantec-issued certificates is able to match what is expected by Google
Chrome and the ecosystem, and that the risks posed both from past and
possible future misissuance is minimized as much as possible.
Given the nature of these issues, and the multiple failures of Symantec to
ensure that the level of assurance provided by their certificates meets the
requirements of the Baseline Requirements or Extended Validation
Guidelines, we no longer have the confidence necessary in order to grant
Symantec-issued certificates the “Extended Validation” status. As
documented with both the current and past misissuance, Symantec failed to
ensure that the organizational attributes, displayed within the address bar
for such certificates, meet the level of quality and validation required
for such display. Therefore, we propose to remove such indicators,
effective immediately, until Symantec is able to demonstrate the level of
sustained compliance necessary to grant such trust, which will be a period
no less than a year. After such time has passed, we will consider requests
from Symantec to re-evaluate this position, in collaboration with the
broader Chromium community.
Compatibility and Interoperability Risk
As with any reduction in trust in a Certificate Authority, this poses a
non-trivial degree of compatibility risk. This is because site operators
desire to have their certificates recognized in all client browsers, and if
one or more browsers fail to trust a given CA, this is prevented from
happening.
On the other hand, all site operators expect that certificates will only
be issued for their domains upon their request, and the failure to have
that assurance significantly undermines the security of HTTPS for both site
operators and users.
This compatibility risk is especially high for Symantec-issued
certificates, due to their acquisition of some of the first CAs, such as
Thawte, Verisign, and Equifax, which are some of the most widely supported
CAs. Distrusting such CAs creates further difficulty for providing secure
connections to both old and new devices alike, due to the need to ensure
the CA a site operator uses is recognized across these devices.
Further, the immediate distrust of a CA, as has been necessary in the
past, can significantly impact both site operators and users. Site
operators are forced to acquire certificates from other CAs, without having
the opportunity and time to research which CAs best meet their needs, and
users encounter a substantial number of errors until those site operators
act, conditioning them to ignore security warnings. In the event that only
a single browser distrusts such a CA, the error is often seen as the
browser’s fault, despite it being a failure of the CA to provide the
necessary level of assurance, and the site operator to respond in a timely
fashion.
Assessing the compatibility risk with both Edge and Safari is difficult,
because neither Microsoft nor Apple communicate publicly about their
changes in trust prior to enacting them.
While Mozilla conducts their discussions regarding Certificate Authorities
in public, and were the first to be alerted of these latest issues, they
have not yet begun discussion of the next steps to how best to protect
their users. Our hope is that this proposal may be seen as one that
appropriately balances the security and compatibility risks with the needs
of site operators, browsers, and users, and we welcome all feedback.
Alternative implementation suggestion for web developers
This proposal allows for web developers to continue to use Symantec issued
certificates, but will see their validity period reduced. This ensure that
web developers are aware of the risk and potential of future distrust of
Symantec-issued certificates, should additional misissuance events occur,
while also allowing them the flexibility to continue using such
certificates should it be necessary.
Usage information from UseCounter
<https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>
For a variety of non-technical reasons, we do not currently instrument the
usage of CAs. Further, few public metrics exist for intersecting usage
information with the validity period, since only certificates valid greater
than nine months will be affected outside of their normal replacement
cycle. From Mozilla Firefox’s Telemetry, we know that Symantec issued
certificates are responsible for 42% of certificate validations. However,
this number is not strictly an indicator for impact, as this number is
biased towards counting certificates for heavily-trafficked sites, and
whose issuance is fully automated and/or whose validity periods will be
unaffected, thus significantly overstating impact. By phasing such changes
in over a series of releases, we aim to minimize the impact any given
release poses, while still continually making progress towards restoring
the necessary level of security to ensure Symantec issued certificates are
as trustworthy as certificates from other CAs.

[Mary Hart]

I am contacting you because Michelle Sanchez is illegally accessing my apps
accounts and everything that i use on my phone illegally!! I need someone
to contact me, i have a harassment order on her here in Omaha Nebraska
because of the illegal activity and access too my phone and accounts!!
Please contact me

Post by Ryan Sleevi
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)
Chrome 62 (Dev, Beta, Stable): 15 months validity (465 days)
Chrome 63 (Dev, Beta): 9 months validity (279 days)
Chrome 63 (Stable): 15 months validity (465 days)
Chrome 64 (Dev, Beta, Stable): 9 months validity (279 days)
The proposed schedule attempts to avoid making changes in Chrome 63
Stable, as that would be released during the winter holiday production
freeze many organizations undergo. This is solely to reduce disruption for
site operators and users, and attempts to resume with Chrome 64 following
the holiday season. Further, the practical impact of the changes in Chrome
59 and 60 are relatively minimal, due to many of the certificates issued
during that period of time being issued using SHA-1, which is no longer
supported for certificates in Chrome.
In addition, we propose to require that all newly-issued certificates must
have validity periods of no greater than 9 months (279 days) in order to be
trusted in Google Chrome, effective Chrome 61. This ensures that the risk
of any further misissuance is, at most, limited to nine months, and more
importantly, that if any further action is warranted or necessary, that the
entire ecosystem can migrate within that time period, thus minimizing the
risk of further compatibility issues.
By combining these two steps, we can ensure that the level of assurance in
Symantec-issued certificates is able to match what is expected by Google
Chrome and the ecosystem, and that the risks posed both from past and
possible future misissuance is minimized as much as possible.
Given the nature of these issues, and the multiple failures of Symantec to
ensure that the level of assurance provided by their certificates meets the
requirements of the Baseline Requirements or Extended Validation
Guidelines, we no longer have the confidence necessary in order to grant
Symantec-issued certificates the “Extended Validation” status. As
documented with both the current and past misissuance, Symantec failed to
ensure that the organizational attributes, displayed within the address bar
for such certificates, meet the level of quality and validation required
for such display. Therefore, we propose to remove such indicators,
effective immediately, until Symantec is able to demonstrate the level of
sustained compliance necessary to grant such trust, which will be a period
no less than a year. After such time has passed, we will consider requests
from Symantec to re-evaluate this position, in collaboration with the
broader Chromium community.
Compatibility and Interoperability Risk
As with any reduction in trust in a Certificate Authority, this poses a
non-trivial degree of compatibility risk. This is because site operators
desire to have their certificates recognized in all client browsers, and if
one or more browsers fail to trust a given CA, this is prevented from
happening.
On the other hand, all site operators expect that certificates will only
be issued for their domains upon their request, and the failure to have
that assurance significantly undermines the security of HTTPS for both site
operators and users.
This compatibility risk is especially high for Symantec-issued
certificates, due to their acquisition of some of the first CAs, such as
Thawte, Verisign, and Equifax, which are some of the most widely supported
CAs. Distrusting such CAs creates further difficulty for providing secure
connections to both old and new devices alike, due to the need to ensure
the CA a site operator uses is recognized across these devices.
Further, the immediate distrust of a CA, as has been necessary in the
past, can significantly impact both site operators and users. Site
operators are forced to acquire certificates from other CAs, without having
the opportunity and time to research which CAs best meet their needs, and
users encounter a substantial number of errors until those site operators
act, conditioning them to ignore security warnings. In the event that only
a single browser distrusts such a CA, the error is often seen as the
browser’s fault, despite it being a failure of the CA to provide the
necessary level of assurance, and the site operator to respond in a timely
fashion.
Assessing the compatibility risk with both Edge and Safari is difficult,
because neither Microsoft nor Apple communicate publicly about their
changes in trust prior to enacting them.
While Mozilla conducts their discussions regarding Certificate Authorities
in public, and were the first to be alerted of these latest issues, they
have not yet begun discussion of the next steps to how best to protect
their users. Our hope is that this proposal may be seen as one that
appropriately balances the security and compatibility risks with the needs
of site operators, browsers, and users, and we welcome all feedback.
Alternative implementation suggestion for web developers
This proposal allows for web developers to continue to use Symantec issued
certificates, but will see their validity period reduced. This ensure that
web developers are aware of the risk and potential of future distrust of
Symantec-issued certificates, should additional misissuance events occur,
while also allowing them the flexibility to continue using such
certificates should it be necessary.
Usage information from UseCounter
<https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>
For a variety of non-technical reasons, we do not currently instrument the
usage of CAs. Further, few public metrics exist for intersecting usage
information with the validity period, since only certificates valid greater
than nine months will be affected outside of their normal replacement
cycle. From Mozilla Firefox’s Telemetry, we know that Symantec issued
certificates are responsible for 42% of certificate validations. However,
this number is not strictly an indicator for impact, as this number is
biased towards counting certificates for heavily-trafficked sites, and
whose issuance is fully automated and/or whose validity periods will be
unaffected, thus significantly overstating impact. By phasing such changes
in over a series of releases, we aim to minimize the impact any given
release poses, while still continually making progress towards restoring
the necessary level of security to ensure Symantec issued certificates are
as trustworthy as certificates from other CAs.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an

[PhistucK]

Mary, as I replied to you before, this group is unrelated to you being
hacked, it is off topic and I did provide you with links and basic guidance
for the right places where you should post this.
We have no idea who this "Michelle Sanchez" is and there is nothing anyone
in this group can do about it.
Please, stop posting those unrelated messages to this group.

Good luck.


☆*PhistucK*

Post by Mary Hart
I am contacting you because Michelle Sanchez is illegally accessing my
apps accounts and everything that i use on my phone illegally!! I need
someone to contact me, i have a harassment order on her here in Omaha
Nebraska because of the illegal activity and access too my phone and
accounts!! Please contact me

Post by Ryan Sleevi
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)
Chrome 62 (Dev, Beta, Stable): 15 months validity (465 days)
Chrome 63 (Dev, Beta): 9 months validity (279 days)
Chrome 63 (Stable): 15 months validity (465 days)
Chrome 64 (Dev, Beta, Stable): 9 months validity (279 days)
The proposed schedule attempts to avoid making changes in Chrome 63
Stable, as that would be released during the winter holiday production
freeze many organizations undergo. This is solely to reduce disruption for
site operators and users, and attempts to resume with Chrome 64 following
the holiday season. Further, the practical impact of the changes in Chrome
59 and 60 are relatively minimal, due to many of the certificates issued
during that period of time being issued using SHA-1, which is no longer
supported for certificates in Chrome.
In addition, we propose to require that all newly-issued certificates
must have validity periods of no greater than 9 months (279 days) in order
to be trusted in Google Chrome, effective Chrome 61. This ensures that the
risk of any further misissuance is, at most, limited to nine months, and
more importantly, that if any further action is warranted or necessary,
that the entire ecosystem can migrate within that time period, thus
minimizing the risk of further compatibility issues.
By combining these two steps, we can ensure that the level of assurance
in Symantec-issued certificates is able to match what is expected by Google
Chrome and the ecosystem, and that the risks posed both from past and
possible future misissuance is minimized as much as possible.
Given the nature of these issues, and the multiple failures of Symantec
to ensure that the level of assurance provided by their certificates meets
the requirements of the Baseline Requirements or Extended Validation
Guidelines, we no longer have the confidence necessary in order to grant
Symantec-issued certificates the “Extended Validation” status. As
documented with both the current and past misissuance, Symantec failed to
ensure that the organizational attributes, displayed within the address bar
for such certificates, meet the level of quality and validation required
for such display. Therefore, we propose to remove such indicators,
effective immediately, until Symantec is able to demonstrate the level of
sustained compliance necessary to grant such trust, which will be a period
no less than a year. After such time has passed, we will consider requests
from Symantec to re-evaluate this position, in collaboration with the
broader Chromium community.
Compatibility and Interoperability Risk
As with any reduction in trust in a Certificate Authority, this poses a
non-trivial degree of compatibility risk. This is because site operators
desire to have their certificates recognized in all client browsers, and if
one or more browsers fail to trust a given CA, this is prevented from
happening.
On the other hand, all site operators expect that certificates will only
be issued for their domains upon their request, and the failure to have
that assurance significantly undermines the security of HTTPS for both site
operators and users.
This compatibility risk is especially high for Symantec-issued
certificates, due to their acquisition of some of the first CAs, such as
Thawte, Verisign, and Equifax, which are some of the most widely supported
CAs. Distrusting such CAs creates further difficulty for providing secure
connections to both old and new devices alike, due to the need to ensure
the CA a site operator uses is recognized across these devices.
Further, the immediate distrust of a CA, as has been necessary in the
past, can significantly impact both site operators and users. Site
operators are forced to acquire certificates from other CAs, without having
the opportunity and time to research which CAs best meet their needs, and
users encounter a substantial number of errors until those site operators
act, conditioning them to ignore security warnings. In the event that only
a single browser distrusts such a CA, the error is often seen as the
browser’s fault, despite it being a failure of the CA to provide the
necessary level of assurance, and the site operator to respond in a timely
fashion.
Assessing the compatibility risk with both Edge and Safari is difficult,
because neither Microsoft nor Apple communicate publicly about their
changes in trust prior to enacting them.
While Mozilla conducts their discussions regarding Certificate
Authorities in public, and were the first to be alerted of these latest
issues, they have not yet begun discussion of the next steps to how best to
protect their users. Our hope is that this proposal may be seen as one that
appropriately balances the security and compatibility risks with the needs
of site operators, browsers, and users, and we welcome all feedback.
Alternative implementation suggestion for web developers
This proposal allows for web developers to continue to use Symantec
issued certificates, but will see their validity period reduced. This
ensure that web developers are aware of the risk and potential of future
distrust of Symantec-issued certificates, should additional misissuance
events occur, while also allowing them the flexibility to continue using
such certificates should it be necessary.
Usage information from UseCounter
<https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>
For a variety of non-technical reasons, we do not currently instrument
the usage of CAs. Further, few public metrics exist for intersecting usage
information with the validity period, since only certificates valid greater
than nine months will be affected outside of their normal replacement
cycle. From Mozilla Firefox’s Telemetry, we know that Symantec issued
certificates are responsible for 42% of certificate validations. However,
this number is not strictly an indicator for impact, as this number is
biased towards counting certificates for heavily-trafficked sites, and
whose issuance is fully automated and/or whose validity periods will be
unaffected, thus significantly overstating impact. By phasing such changes
in over a series of releases, we aim to minimize the impact any given
release poses, while still continually making progress towards restoring
the necessary level of security to ensure Symantec issued certificates are
as trustworthy as certificates from other CAs.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
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

[j***@gmail.com]

If you are so concerned about certificate security, WHY ON EARTH did you
remove the ability to view the certificate that a page uses by clicking on
the "Secure" link next to the address bar?
Why do I have to go to Developer tools to view the certificate?

I like to check the certificate a site is using quite often, yet you make
it harder to do this basic security check?

[PhistucK]

Please, stay on topic.


☆*PhistucK*

Post by j***@gmail.com
If you are so concerned about certificate security, WHY ON EARTH did you
remove the ability to view the certificate that a page uses by clicking on
the "Secure" link next to the address bar?
Why do I have to go to Developer tools to view the certificate?
I like to check the certificate a site is using quite often, yet you make
it harder to do this basic security check?

--

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