As per previous discussions and https://wiki.mozilla.org/CA:Symantec_Issues, a consensus proposal[0] was reached among multiple browser makers for a graduated distrust of Symantec roots.
Here is Mozilla’s planned timeline for the graduated distrust of Symantec roots (subject to change): * January 2018 (Firefox 58): Notices in the Developer Console will warn about Symantec certificates issued before 2016-06-01, to encourage site owners to migrate their TLS certs. * May 2018 (Firefox 60): Websites will show an untrusted connection error if they have a TLS cert issued before 2016-06-01 that chains up to a Symantec root. * October 2018 (Firefox 63): Removal/distrust of Symantec roots, with caveats described below. Mozilla’s release calendar is here: https://wiki.mozilla.org/RapidRelease/Calendar However, there are some subCAs of the Symantec roots that are independently operated by companies whose operations have not been called into question, and they will experience significant hardship if we do not provide a longer transition period for them. For both technical and non-technical reasons, a year is an extremely unrealistic timeframe for these subCAs to transition to having their certificates cross-signed by another CA. For example, the subCA may have implemented a host of pinning solutions in their products that would fail with non-Symantec-chaining certificates, or the subCA may have large numbers of devices that would need to be tested for interoperability with any potential future vendor. And, of course contractual negotiations may take a significant amount of time. The subCAs that we know of that fall into this category belong to Google and Apple. If there are any other subCAs that fall into this category, please let us know immediately. Google has one such subCA; Apple has seven. There are two ways that we can provide a smoother transition for these subCAs. Option 1) Temporarily treat these subCAs as directly-included trust-anchors. Mozilla prefers *not* to take this approach, because even if clearly explained up front that it is a temporary solution with deadlines, it would be very easy for people to start treating such a subCA as a regular trust anchor, and thereby have that subCA become a de facto included CA. Additionally, it could become very complicated to remove such subCAs in the future, especially if they have not performed the recommended transitions. Option 2) Add code to Firefox to disable the root such that only certain subCAs will continue to function. So, the final dis-trust of Symantec roots may actually involve letting one or two of the root certs remain in Mozilla’s trust store, but having special code to distrust all but specified subCAs. We would document the information here: https://wiki.mozilla.org/CA/Additional_Trust_Changes And Mozilla would add tooling to the CCADB to track these special subCAs to ensure proper CP/CPS/audits until they have been migrated and disabled, and the root certs removed. Mozilla will need to also follow up with these subCAs to ensure they are moving away from these root certificates and are getting cross-signed by more than one CA in order to avoid repeating this situation. According to option 2 and the plan listed above, here is how the currently-included Symantec root certs will be treated in Firefox 63: = Symantec roots to be disabled via code, *not* removed from NSS = GeoTrust Global CA GeoTrust Primary Certification Authority - G2 GeoTrust Primary Certification Authority - G3 = Symantec roots that will be fully removed from NSS = GeoTrust Primary Certification Authority GeoTrust Universal CA GeoTrust Universal CA 2 Symantec Class 1 Public Primary Certification Authority - G4 Symantec Class 1 Public Primary Certification Authority - G6 Symantec Class 2 Public Primary Certification Authority - G4 Symantec Class 2 Public Primary Certification Authority - G6 thawte Primary Root CA thawte Primary Root CA - G2 thawte Primary Root CA - G3 VeriSign Class 1 Public PCA - G3 VeriSign Class 2 Public PCA - G3 VeriSign Class 3 Public Primary Certification Authority - G3 VeriSign Class 3 Public Primary Certification Authority - G4 VeriSign Class 3 Public Primary Certification Authority - G5 VeriSign Universal Root Certification Authority As always, we appreciate your thoughtful and constructive feedback on this. Gerv [0] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs%5B251-275%5D _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
