Hi m.d.s.p., Google have posted their updated plan for Symantec in the blink-dev forum (copied below). https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ
Insofar as it pertains to Google's actions, you should go over and discuss it there. But of course, this plan has significant overlap with Mozilla's draft proposal here: https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit# I have passed that document to Kathleen, and I hope she will be endorsing this general direction soon, at which point it will no longer be a draft. Assuming she does, this will effectively turn into a 3-way conversation between Symantec, Google and Mozilla, to iron out the details of what's required, with the Google proposal as a base. (Which I'm fine with as a starting point.) Comments are therefore invited on what modifications to the plan or additional requirements Mozilla might want to suggest/impose, and (importantly) why those suggestions/impositions are necessary and proportionate. Gerv -------- Forwarded Message -------- Subject: Re: [blink-dev] Intent to Deprecate and Remove: Trust in existing Symantec-issued Certificates Date: Fri, 19 May 2017 10:27:41 -0400 From: Ryan Sleevi <rsle...@chromium.org> Reply-To: rsle...@chromium.org To: blink-dev <blink-...@chromium.org> CC: Ryan Sleevi <rsle...@chromium.org>, awhal...@chromium.org Overview / Background Here's an update on the discussions about Symantec-issued certificates and the steps Chrome is proposing to move forward. Thank you to everybody who has contributed to the discussion so far. On May 12, members of the Chrome team met with Symantec to discuss the set of concerns and our proposed remedy for them. These discussions were an expansion on a proposal previously shared with Symantec in April, and later shared on the mozilla.dev.security.policy list <https://groups.google.com/d/msg/mozilla.dev.security.policy/lOHrTr97Qx0/2IkcSGq9AQAJ>. When the original Intent to Deprecate was posted, I proposed <https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ>a plan that tried to best address issues we were aware of and provide a long-term path for comprehensive protections. We received a lot of great feedback from the Blink and wider PKI communities regarding the impact this plan would have and further issues to consider. In light of this feedback, we would like to propose a new plan that we believe ensures users are sufficiently secured while trying to minimize disruption to site operators, and providing an objective and reasonable path forward for those that have critical dependencies on certificates that chain to Symantec-operated roots. We want to share an overview of this plan with the broader community, with more specific, detailed requirements at the end. The high-level overview of the plan is: * Symantec will modernize their platform and PKI dedicated to website certificate issuance. Symantec has previously posted <https://www.symantec.com/connect/blogs/symantec-ca-continues-public-dialogue> that this in their current roadmap, and we require that the modernized platform adheres to best practices for CAs in security, design, and process as part of that modernization process. * Until the modernized platform is ready and accepted into major trust stores, certificates would need to be issued through one or more independently operated third-party CAs (aka “Managed CAs”) that Symantec would partner with. * The Managed CAs could be cross signed by an agreed upon set of existing Symantec roots, to take advantage of the existing roots' ubiquity in trust stores. * EV certificates can be issued by Managed CAs, provided that they meet the validation requirements. * Validity period of new certificates can be up to 39 months, or to the maximum allowed by Chrome for all CAs (currently specified in the Baseline Requirements and EV Guidelines), provided that a Managed CA fully revalidates the information. During a bridge period, Managed CAs can reuse existing validation information but lifetimes must be limited to 13 months. * Existing certificates issued on or after June 1st 2016 would still be trusted, provided they comply with the Chrome CT policy. EV certificates issued on or after this date will continue to be granted EV treatment. * Existing certificates issued before June 1st 2016 would go through a phased distrust based on notBefore dates. * Chrome will offer an Enterprise Policy to allow older certificates to be trusted to help with migration to the new PKI. While the plan is not final, we believe it is converging on one that strikes a good balance of addressing security risk and mitigating interruption. We still welcome any feedback about it, as prior feedback has been valuable in helping shape this plan. Transition to a New Symantec PKI Chrome will require that by 2017-08-08 all new Symantec-chaining certificates be issued by independently operated third-parties (aka “Managed CAs”). Chrome will implement a check, on-or-after 2017-08-08, to enforce this by ensuring that the certificate chain contain a whitelist of intermediates (independently operated sub-CAs or the Managed CAs). If a Managed CA has fully revalidated the information, the validity period of new certificates can be up to the maximum allowed by Chrome for all CAs, which is currently specified as the maximum allowed by the Baseline Requirements and EV SSL Guidelines. During a transition period, validation information can be reused, provided that the certificate is issued by the new infrastructure. However, the validity period of such certs must be no longer than 13 months. If Symantec needs this flexibility, the following deadlines apply: * 2017-08-08 - Certificates must be issued by the Managed CA, but can re-use existing validation information (up to the limits imposed by the Baseline Requirements). * 2017-11-01 - Certificates must be issued and have domains revalidated by the Managed CA, but can use re-use existing organization validation information (up to the limits imposed by the Baseline Requirements). * 2018-02-01 - Certificates must be issued and have all validation performed by the Managed CA. The use of existing or new validation information in a certificate should be signalled by using new OID in the Certificate Policies extension. See the Technical Details section for more information. If the managed CA is unable to validate the information by such milestones, then such certificates will not be able to be issued or trusted. Existing Certificates Chrome will continue to trust certificates issued after 2016-06-01, provided they are “CT Qualified” as defined in the Chrome CT Policy <https://sites.google.com/a/chromium.org/dev/Home/chromium-security/certificate-transparency>. Enterprise Chrome users will be given a policy to allow certificates issued before 2016-06-01. This will give enterprise administrators the ability to control Chrome behavior for their organizations. This can be specified both at device-level <https://support.google.com/chrome/a/answer/187202?hl=en>as well as at user-level <https://support.google.com/chrome/a/answer/2657289?hl=en>. We’re proposing a phased distrust of all website certificates issued prior to 2016-06-01, which is the date in which Chrome both required and enforced Certificate Transparency. This provides a degree of assurance for site operators that certificates issued for the improper domain have a reasonable chance of being detected. With this, our goal is to attempt to minimize disruption to site operators, ensure reasonable notice of these changes, and avoid particularly sensitive holiday disruptions. These plans represent target dates, which may need to be adjusted based on interoperability or compatibility risk or additional information coming to light that may accelerate such distrust. * On 2017-08-31, no longer trust any certificate whose notBefore was prior to 2015-06-01. This corresponds with an expected Chrome 62 date. * On 2018-01-18, no longer trust any certificate whose notBefore was prior to 2016-06-01. This corresponds with an expected Chrome 65 date. Technical Details Operations * These sub-CAs must be operated by a non-affiliated organization that operates roots currently trusted in the Android and Chrome OS trust stores that have been trusted for a period of at least two years. * The non-affiliated organization must accept full responsibility for the operation of these sub-CAs and agree that any misissuance from these sub-CAs will be treated as if it was misissuance from any of the other CAs the organization operates. Similarly, any misissuance from the other CAs the organization operates will be treated as if it was misissuance from these sub-CAs. Because the basis for trust in these intermediates will be based on chaining to the existing Symantec root certificates, rather than to a different organization’s CA certificates, Symantec must also accept responsibility for the operation of these sub-CAs and agree that any misissuance from these sub-CAs will be treated as if it was misissuance from any of the other CAs that Symantec operates. * Symantec and its affiliates must not participate in any of the information verification roles permitted under the Baseline Requirements, such as Delegated Third Parties, including that of Enterprise RAs, or as Validation Specialists. That is, the non-affiliated organization bears full responsibility to perform all information verification controls related to the issuance of the certificates. Symantec and its affiliates may, however, seek to collect and aggregate all of the information as part of the Certificate Request process in order to expedite and simplify the verification process. * These sub-CAs must not be used to certify any Symantec-operated or -controlled CAs, but may themselves be certified by existing Symantec-operated or -controlled CAs. That is, they can be cross-signed by the existing infrastructure, but they must not cross-sign any of the existing infrastructure or certificates. * No Delegated Third Parties shall be used to perform the information verification functions of domain verification (Section 3.2.2.4 of the Baseline Requirements) or IP address verification (Section 3.2.2.5 of the Baseline Requirements) * The Certificate Policy and Certification Practice Statements (CP/CPS) for the sub-CAs may use Symantec’s domains for purposes of CAA verification, as they are operating on behalf of Symantec. Audits * Within 90 days of the first certificate being issued by any of these sub-CAs, the operating organization shall provide a Period of Time audit report according to the “Trust Service Principles and Criteria for Certification Authorities” and the “WebTrust Principles and Criteria for Certification Authorities - SSL Baseline with Network Security.” If Symantec desires for these sub-CAs to be recognized as capable of issuing EV certificates, Symantec shall also provide a “WebTrust Principles and Criteria for Certification Authorities - Extended Validation SSL.” All audits shall use the current version of the criteria appropriate for the audit engagement date. The period of time must include the moment of the Key Generation Ceremony, must not exceed 120 days in duration, and must not be less than 30 days in duration. Note that 90 days represents when the report shall be provided, not the end of the period of time. * The audit report scope must include all Principles and Criteria and include all locations in which the key material exists. If a Principle or Criteria is excluded from the scope due to the non-performance of that function, the audit report and management’s assertion letter must attest that no organizations, including the operating organization, performed that role or function for the Period of Time under audit. * An unbroken sequence of such audit reports shall be posted publicly and provided to Google no more than 90 days after the conclusion of the audit period. For the first year following the issuance of the first certificate, the audit period shall not exceed 90 days. For the second year, the audit period shall not exceed 6 months. For third and subsequent years, the audit period shall not exceed 12 months. * Any and all subordinate CAs certified by these sub-CAs must be covered by the same CP/CPS, management’s assertion, and audit reports as the sub-CA itself. That is, any sub-CAs beneath these sub-CAs must be part of the same infrastructure and operation of the non-affiliated organization. Certificate Details * In order to be trusted, issued certificates must be “CT Qualified”, as defined in the Certificate Transparency in Chrome Policy <https://www.chromium.org/Home/chromium-security/certificate-transparency>. * Each certificate must clearly identify the degree of information that has been revalidated. To accomplish this, we propose that Symantec make use of three newly-defined OIDs, to be allocated by Symantec, and to be placed within the Certificate Policies extension, with a distinct OID for each of the following scenarios: o Issued on new infrastructure, but reusing existing information previously validated or obtained by Symantec. + Certificates bearing this policy OID MUST NOT be valid for longer than 400 days. o Issued on new infrastructure, with domain information having been validated by the organization operating the Managed CA for Symantec, but containing and reusing organizational information validated previously by Symantec. + Certificates bearing this policy OID MUST NOT be valid for longer than 400 days. + As DV certificates do not contain organization information, no DV certificates should bear this policy OID. o Issued on new infrastructure, with all information contained having been validated by the organization operating the Managed CA for Symantec. + Certificates bearing this policy OID MUST NOT be valid for longer than the maximum time permitted by Chrome for all CAs at the time of issuance, which is currently defined within the CA/Browser Forum’s Baseline Requirements. Transition to New Infrastructure * Until such a time as Symantec’s new infrastructure has been accepted as trusted for TLS server certificate issuance in the root stores used by the Stable version of Chrome on the most recently released, generally available version of the supported OS platform Chrome is running on, the sub-CAs must continue to be operated according to the requirements outlined here. o At this time, this includes the root stores of Microsoft (Chrome on Windows), Apple (Chrome on macOS and Chrome on iOS), Mozilla (Chrome on Linux) and Google (Chrome on Android and Chrome on Chrome OS). And would include any future Google root store program used by Google products and services. * In continued collaboration with CPA Canada and the WebTrust Task Force in determining the feasibility and appropriateness of such reports, as part of the determination for acceptability of the new infrastructure, Symantec may be requested to provide a report on controls at the Certification Authority that includes a description of the auditor’s tests of controls and results, covers a period of time, and includes a description of the system. The intended users of the report must include persons who assist in decisions related to the trusted status of Certification Authorities within Chrome and Google products. -- You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group. To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/eUAKwjihhBs/unsubscribe. To unsubscribe from this group and all its topics, send an email to blink-dev+unsubscr...@chromium.org <mailto:blink-dev+unsubscr...@chromium.org>. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACvaWvYUvGZA1-LBpYBWaAAz_MopmO9SivWiDJGS1ousS3-srg%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACvaWvYUvGZA1-LBpYBWaAAz_MopmO9SivWiDJGS1ousS3-srg%40mail.gmail.com?utm_medium=email&utm_source=footer>. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
