A couple of thoughts:
1) I'm not sure why you believe Option 2 is likely to result in a quicker 
2) Option 2 starts "Add code to Firefox..". What's the plan for non-firefox 
users of the Mozilla root list? Isn't there a pretty substantial risk that 
others users don't correctly implement the partial distrust, resulting in a 
trust/security risk?


On Monday, October 16, 2017 at 6:32:54 PM UTC+1, Gervase Markham wrote:
> 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

Reply via email to