Kathleen, I believe that certificate authorities should be content-neutral. They should not be required to assess "misuse" or "fraud," nor be required to revoke certificates except upon request of the owner of a domain listed in the certificate.
Requiring CAs to police website content is incompatible with Mozilla's goal of deprecating non-secure HTTP. Requiring HTTPS for all sites is only attainable if all sites can easily obtain certificates, and content policing by CAs undermines that. As the operator of an automated certificate reseller, I have witnessed countless cases of certificate authorities flagging certificate requests as "High Risk" due to the DNS name being supposedly similar to a popular brand name. Without exception, every time has been a false positive. The best outcome is a multi-hour delay as a human reviews the website, and the worst outcome is an outright rejection of the request. Either way, it creates uncertainty: you don't know if or when you can get a certificate, which makes it hard to automate certificate deployment, which makes it hard to deploy HTTPS. Given that CAs have only the DNS name on which to base their decision, a high false positive rate seems inevitable. Requiring CAs to revoke certificates based on website content creates another way for websites to be taken offline. What recourse does a site operator have when their certificate is erroneously revoked by a CA? How can websites that host user-uploaded content operate? These are difficult questions which will need adequate answers if HTTPS is to become mandatory for all websites. It would be much better if CAs weren't required to police content and instead focused solely on what certificates are meant to do: certify that a public key belongs to a particular entity. Protecting users from malicious content should be left to the software processing the content (e.g. Firefox), which can do a better job than a CA ever could. Firefox already uses Google Safe Browsing to protect users from phishing and malware. It works for content delivered over both HTTPS and HTTP, doesn't suffer from the multi-day delay inherent with certificate revocation, and can operate on a per-file level, using the URL or the hash of the file. Thus, a known malware file can be blocked even when it appears on a brand new domain, and if only a single file on a domain is malicious, only that file is blocked instead of the entire site, which would cause collateral damage in the case of a site like GitHub which serves user-uploaded content. Regards, Andrew _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
