Unsurpisingly, I agree with this proposed course of action, and would go further to suggest utilizing OneCRL to ensure the prompt and widespread removal of trust, in addition to removing from NSS.
On Sat, Mar 17, 2018 at 2:26 AM Eric Mill via dev-security-policy < [email protected]> wrote: > In TurkTrust's 2016 email noting that they were suspending their TLS > certificate business, they noted it stemmed mainly from not being accepted > to all major root stores (Apple did not accept them). > > Therefore, the sites using these certificates are not trusted by some major > client bases, which is likely why some of the few existing sites that have > TurkTrust certificates, such as http://www.enpos.com.tr and > http://www.turktrust.com.tr/tr/, do not redirect clients to HTTPS. This > lack of reliance on using the certificates for HTTPS reduces the impact to > Mozilla's users of suspending trust in the remaining certificates. > > Even if this were not the case, I would agree and recommend prompt removal > of this explicitly unmaintained, unaudited hierarchy to protect Mozilla's > users. The above only makes it even more obviously the right decision. > > -- Eric > > On Fri, Mar 16, 2018 at 8:23 PM, Wayne Thayer via dev-security-policy < > [email protected]> wrote: > > > TURKTRUST has the "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5" > > root included in the Mozilla program with the 'websites' trust bit > enabled > > (not EV). Crt.sh identifies one unexpired and unrevoked subordinate CA > [1], > > and 13 unexpired end-entity certificates signed by this root [2]. The > > audits for this root are either already expired (based on audit date) or > > nearly expired (based on the ETSI certificate expiration date) [3] [4]. > > > > TURKTRUST announced the suspension of their SSL business in 2016 [5]. > > > > TURKTRUST failed to respond to the January 2018 CA Communication. After > > repeated attempts, they did respond to my emails and posted a statement > in > > the bug [6] including the following: > > > > The strategic decision mentioned above is actually suspending all SSL > > > business supporting activities that incur direct costs for TURKTRUST, > > > including suspending the ETSI and BR audits or OV and EV SSL related > > > insurance policies. We have also ceased our investment and studies on > CT > > > and CAA requirements for the time being that are actually mandatory > > > criteria set by the CA/Browser Forum. > > > > > > > TURKTRUST has chosen not to request removal of the root, but I believe > this > > is a clear case in which prompt removal of the root is necessary. > > > > I would appreciate everyone's constructive input on what action should be > > taken. > > > > - Wayne > > > > [1] https://crt.sh/?Identity=%25&iCAID=5766&exclude=expired > > [2] https://crt.sh/?Identity=%25&iCAID=5767&exclude=expired > > <https://crt.sh/?Identity=%25&iCAID=5767&exclude=expired> > > [3] https://bug1332435.bmoattachments.org/attachment.cgi?id=8828490 > > [4] > > > https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/6749UE_s.pdf > > <https://cabforum.org/pipermail/public/2016-September/008475.html> > > [5] https://cabforum.org/pipermail/public/2016-September/008475.html > > <https://cabforum.org/pipermail/public/2016-September/008475.html> > > [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1439127 > > _______________________________________________ > > dev-security-policy mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-security-policy > > > > > > -- > konklone.com | @konklone <https://twitter.com/konklone> > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
