I have been asked a few times recently what my largest issues are with Firefox and it’s PKI/TLS implementations, here is the short-list:
725351 – Support enforcing nested EKU constraints, do so by default.
579606 – Multiple OCSP requests should be performed in parallel
565047 – Implement TLS 1.1 (RFC 4346)
436414 – OCSP client should be able to use HTTP GET as well as POST
360420 – Implement OCSP Stapling in libSSL
399324 – Fetch missing intermediate certs (use AIA extension for incomplete cert chains)
378098 – Do not expire OCSP responses that say “revoked”
48597 – OCSP needs offline cache (persistent on-disk)
Kathleen at Mozilla has recently set up a page to track revocation related issues here.
The conclusion of the post notes that Google “may also decdie to take additional action after further discussion and careful consideration,” which to me hints that the Chrome team, as others, are likely considering whether to continue including TURKTRUST root. While I fully appreciate the ramifications of the breach, I would inveigh upon the community to take time to consider subsequent actions. Unfortunately, due to banking embargoes against sanctioned states, there are very few CAs that accept customers from Iran and Syria. TRUSTTRUST and ipsCA (not trusted) are likely the primary CAs for these audiences. Unfortunately if this CA is removed, it is likely that the decision will push many sites into the national, not-trusted and completely compromised CA ParsSign.
While unrelated to this particular post this is still a good point in that the consequences of the removal of a CA who may have behaved badly can have potentially worse side effects.
That said in the referenced case, TurkTrust was able to convince the appropriate parties they did not act maliciously and made changes to prevent such acts from happening again. As for CA ParsSign, since they are not trusted by browsers I would be interested to know how relying parties end up getting their root installed?