| Hi Gerv, I would recommend against asking CA's to necessarily judge "malicious intent" on their own. Many CA's have enough to worry about just making sure they issue certs properly that I would question their ability to take on this extra work and perform it sufficiently well. That said, it may be worthwhile bringing up for discussion the idea of malicious intent and what roles or responsibilities are reasonable for a CA. There are undoubtedly parallels here to how anti-spam and IP address blacklisting services go about their functions as well as Microsoft's response to malicious code that is signed with a cert that is recognized by their code signing program. Perhaps there are lessons learned there or good practices that could be adopted. Possible talking points: * In simplest terms I imagine most all CA's would agree that "we have the right to refuse service to anyone for any reason, up to and including revocation of already-issued certs". Certainly, something that can be seen as harmful to the reputation of a CA would qualify as one such reason? * If a CA is notified that a cert under their purview is being used for malicious intent, what will their response be and what should it be? Can a CA individually specify what they might consider malicious, how a judgment might be reached, any notifications made? Certainly each case and situation will have its own considerations but maybe some general guidelines could still be documented. Even if the best a CA can do is revoke the cert, that still has value. At least we might have some assurance that future encounters with the malicious activity will have limited effect. Thanks.
On 17/05/16 22:41, Kathleen Wilson wrote:
> On Monday, May 16, 2016 at 9:20:56 AM UTC-7, Kathleen Wilson wrote: >> I am wondering if the BRs need to be updated to: >> + Define what is meant by "Certificate misuse, or other types of fraud". (e.g. being used for a purpose outside of that contained in the cert, or applicant provided false information.) >> + Add text similar to what is in the EV Guidelines stating that TLS/SSL certificates focus only on the ownership of the domain name(s) included in the certificate, and not on the behavior of the website. Note that the BRs already have section 9.6.1 about certificate warranties. > > Would someone please volunteer to take this up with the CA/Browser Forum? To be clear: you would like the CA/Browser Forum to define more explicitly what is meant by "Certificate misuse, or other types of fraud" in the definition of "Certificate Problem Report"? And your initial proposal for a definition is "being used for a purpose outside of that contained in the cert, or applicant provided false information"? If we can be clear by the end of the week what we are asking, I can bring this up in the CAB Forum face-to-face meeting next week. > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ > "4. We reserve the right to not include a particular CA certificate in our software products. This includes (but is not limited to) cases where we believe that including a CA certificate (or setting its "trust bits" in a particular way) would cause undue risks to users’ security, for example, with CAs that > - knowingly issue certificates without the knowledge of the entities whose information is referenced in the certificates; or > - knowingly issue certificates that appear to be intended for fraudulent use." > > What is meant by "fraudulent use"? I think the bullet as a whole could mean that we reserve the right to not include CAs who happily issue certs to "www.paypalpayments.com" to just anyone without any checks or High Risk string list or anything. Such a cert, unless issued to Paypal, Inc., is clearly to be used for fraud, IMO, and a CA is negligent in issuing it given that it's not hard to flag for manual review any cert containing the names of major banks and payment companies. Gerv _______________________________________________ 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
