(Writing in a Google capacity) In [1], we removed support in Camerfirma certificates, as previously announced [2]. This included removing support for any subordinate CAs. As announced, this was planned to roll out as part of the Chrome 90 release schedule, scheduled to hit stable on 2021-04-06.
As with any CA removal, we’ve continued to examine ecosystem progress. When appropriate, we've also reached out to specific organizations to understand any challenges that might significantly impact our users. While we actively discourage CAs and site operators from directly contacting us to request exceptions, we do reach out to organizations that may significantly affect a non-trivial number of users. This situation is particularly unique due to the global pandemic, as several Portugese and Spanish government websites related to COVID-19 are affected. We've received confirmation from these organizations that they are on track to migrate. These organizations have requested 1-2 additional weeks to replace their certificates, beyond the three months since the original announcement. Normally, we would not honor such requests, given the industry standard expectations around certificate replacement being doable in five days or less. However, the global pandemic has brought unique and unprecedented challenges. Given the importance of these websites in helping resolve this global health crisis, we’re inclined to provide that additional migration support under these circumstances. We plan to temporarily suspend the Camerfirma removal for at least the first Chrome 90 release, to provide that additional time to migrate these pandemic-related websites. Although we considered other technical approaches, we believe this approach to be the least risky for this situation. We’ll continue to work directly with these COVID-19 related websites on their migration. We plan to remove trust no later than Chrome 91, but may remove it sooner, such as part of a Chrome 90 security update, based on these migration efforts. This will not affect Chrome Beta, Dev, and Canary channels, as they will continue to block certificates from the Camerfirma hierarchy. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=1173547 [2] https://groups.google.com/g/mozilla.dev.security.policy/c/dSeD3dgnpzk/m/iAUwcFioAQAJ On Thu, Jan 28, 2021 at 10:39 PM Eric Mill via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Just to build on what Ryan said, and to clarify any confusion around the > scope of Chrome’s action here - Chrome is no longer accepting Camerfirma > certificates that are specifically used for *TLS server authentication* for > websites. > > Our planned action is related to the certificates Chrome uses and > verifies, which are only those used for TLS server authentication. This > does include any type of certificate used in Chrome for TLS server > authentication, including Qualified Website Authentication Certificates > (QWACs) and certificates used to comply with the Revised Payment Services > Directive (PSD2). However, it does not cover other use cases, such as TLS > client certificates or the use of Qualified Certificates for digital > signatures. > > In order to ensure Chrome’s response is comprehensive, the list of > affected roots includes all of those operated by Camerfirma that have the > technical capability to issue TLS server authentication certificates, even > if those roots are not currently being used to issue TLS server > authentication certificates. But please note that the changes we announced > for Chrome will not impact the validity of these roots for other types of > authentication, only current and future use of those roots for TLS server > authentication in Chrome. > > > On Monday, January 25, 2021 at 12:01:42 AM UTC-8, Ryan Sleevi wrote: > > (Writing in a Google capacity) > > > > I personally want to say thanks to everyone who has contributed to this > > discussion, who have reviewed or reported past incidents, and who have > > continued to provide valuable feedback on current incidents. When > > considering CAs and incidents, we really want to ensure we’re > considering > > all relevant information, as well as making sure we’ve got a correct > > understanding of the details. > > > > After full consideration of the information available, and in order to > > protect and safeguard Chrome users, certificates issued by AC Camerfirma > SA > > will no longer be accepted in Chrome, beginning with Chrome 90. > > > > This will be implemented via our existing mechanisms to respond to CA > > incidents, via an integrated blocklist. Beginning with Chrome 90, users > > that attempt to navigate to a website that uses a certificate that > chains > > to one of the roots detailed below will find that it is not considered > > secure, with a message indicating that it has been revoked. Users and > > enterprise administrators will not be able to bypass or override this > > warning. > > > > This change will be integrated into the Chromium open-source project as > > part of a default build. Questions about the expected behavior in > specific > > Chromium-based browsers should be directed to their maintainers. > > > > To ensure sufficient time for testing and for the replacement of > affected > > certificates by website operators, this change will be incorporated as > part > > of the regular Chrome release process. Information about timetables and > > milestones is available at https://chromiumdash.appspot.com/schedule. > > > > Beginning approximately the week of Thursday, March 11, 2021, website > > operators will be able to preview these changes in Chrome 90 Beta. > Website > > operators will also be able to preview the change sooner, using our Dev > and > > Canary channels, while the majority of users will not encounter issues > > until the release of Chrome 90 to the Stable channel, currently > targeting > > the week of Tuesday, April 13, 2021. > > > > When responding to CA incidents in the past, there have been a variety > of > > approaches taken by different browser vendors, determined both by the > facts > > of the incident and the technical options available to the browsers. Our > > particular decision to actively block all certificates, old and new > alike, > > is based on consideration of the details available, the present > technical > > implementation, and a desire to have a consistent, predictable, > > cross-platform experience for Chrome users and site operators. > > > > For the list of affected root certificates, please see below. Note that > we > > have included a holistic set of root certificates in order to ensure > > consistency across the various platforms Chrome supports, even when they > > may not be intended for TLS usage. However, please note that the > > restrictions are placed on the associated subjectPublicKeyInfo fields of > > these certificates. > > > > Affected Certificates (SHA-256 fingerprint) > > > > - 04F1BEC36951BC1454A904CE32890C5DA3CDE1356B7900F6E62DFA2041EBAD51 > > - 063E4AFAC491DFD332F3089B8542E94617D893D7FE944E10A7937EE29D9693C0 > > - 0C258A12A5674AEF25F28BA7DCFAECEEA348E541E6F5CC4EE63B71B361606AC3 > > - C1D80CE474A51128B77E794A98AA2D62A0225DA3F419E5C7ED73DFBF660E7109 > > - 136335439334A7698016A0D324DE72284E079D7B5220BB8FBD747816EEBEBACA > > - EF3CB417FC8EBF6F97876C9E4ECE39DE1EA5FE649141D1028B7D11C0B2298CED > > On Thu, Dec 3, 2020 at 1:01 PM Ben Wilson via dev-security-policy < > > dev-secur...@lists.mozilla.org> wrote: > > > > > All, > > > > > > We have prepared an issues list as a summary of Camerfirma's > compliance > > > issues over the past several years. The purpose of the list is to > collect > > > and document all issues and responses in one place so that an overall > > > picture can be seen by the community. The document is on the Mozilla > wiki: > > > https://wiki.mozilla.org/CA:Camerfirma_Issues. > > > <https://wiki.mozilla.org/CA:Camerfirma_Issues> > > > > > > I will now forward the link above to Camerfirma to provide them with a > > > proper opportunity to respond to the issues raised and to ask that > they > > > respond directly in m.d.s.p. with any comments, corrections, inputs, > or > > > updates that they may have. > > > > > > If anyone in this group believes they have an issue appropriate to add > to > > > the list, please send an email to certif...@mozilla.org. > > > > > > Sincerely yours, > > > Ben Wilson > > > Mozilla Root Program > > > _______________________________________________ > > > dev-security-policy mailing list > > > dev-secur...@lists.mozilla.org > > > https://lists.mozilla.org/listinfo/dev-security-policy > > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
