On Thursday, May 19, 2016 at 5:21:05 PM UTC-7, Peter Bowen wrote: > I think you misinterpreted the responses, at least if that is the take > away you have. Kathleen asked specific questions and I think the > responses were to those specific questions. The question "MUST CAs > investigate and revoke certificates for websites that are reported to > them for injecting malware on Relying Parties clients?" was not one of > the questions. > > As a few example of where the specific questions are important: > > [KW Question] What does "misused" mean in Section 4.9.1.1? > > You correctly point out there are 15 different things in 4.9.1.1. > This is specifically asking about #4. I would suggest that items #5, > #9, #10, and #14 all could cover the "injecting malware" case you > propose.
[KH] Peter - the term "misuse" is used in multiple places, and I think you need to look at all uses to understand what it is intended to mean at Sec. 4.9.1.1. In any event, it appears we agree that certs used for malware injection should be revoked by the CA, unless the subscriber gives an adequate explanation and/or cleans up the website after the CA asks. But the CA is supposed to ask under the existing BRs. > > [KW Question] If a website is using its SSL certificate to mask > injection of malware and evidence of that is presented to the issuing > CA, is that sufficient misuse for the CA to be required to revoke the > certificate? > > I think that there should be an option for the website to show they > had cleaned up their website (e.g. if they had a breach) and keep > their certificate rather than requiring revocation. [KH] Agreed. The CA should ask the subscriber for an explanation and/or cleanup, and then does not need to revoke if the response is adequate. But under the BRs, the CA must revoke if there is no adequate response from a site using the cert to inject malware. > > [KW Question] Does a website who is known to an issuing CA to inject > malware count as high risk? > > The BRs only reference High Risk in the section called "Performing > Identification and Authentication Functions" and say "The CA SHALL > develop, maintain, and implement documented procedures that identify > and require additional verification activity for High Risk Certificate > Requests prior to the Certificate’s approval, as reasonably necessary > to ensure that such requests are properly verified under these > Requirements." This explicitly attaches High Risk to verification of > subject identity and domain control validation. > > I don't think the concept of whether a CA chooses to issue a > certificate should be commingled with the identity validation -- I > think it is clear that a site serving malware might pass all > identification and authentication steps. [KH] But Peter, how do you explain the provisions of the High Risk Certificate Definition, which suggests CAs should look at the following when processing a new certificate request? “BR 4.2.1 The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate’s approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements.” "High Risk Certificate Request: A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, which may include [a] names at higher risk for phishing or other fraudulent usage, [b] names contained in previously rejected certificate requests or revoked Certificates, [c] names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or [d] names that the CA identifies using its own risk‐mitigation criteria.” Under this BR and related definition, the CA is supposed to look for much more than just possible name/identity confusion. Plus it's never safe to use a general section title to try to limit the meaning of a specific subsection - BR 4.2.1 has four paragraphs which covers lots of requirements, and the requirement as to High Risk Certificate Requests stands on its own and is very specific. (Plus I think the Section title you reference came from RFC 3647, the template for CPSs, and was not created by the Forum -- the Forum just stuffed a lot of requirements under that specific pre-determined heading). > > [KW Question] Are CAs required to maintain a list/database to prevent > issuance of SSL certificates for websites that are known to them to > inject malware? > > This is clearly about the CA maintaining a list/database. As you > point out there are external databases that are frequently used by CAs > to determine if they want to issue a certificate, so I don't see value > in requiring the CA to maintain another database themselves. [KH] See response above - yes, CAs can and should use multiple outside databases of bad actors. The High Risk Certificate Request defininition also suggests the following two databases, which the CA necessarily must establish and maintain for itself: [b] names contained in previously rejected certificate requests or revoked Certificates, *** [d] names that the CA identifies using its own risk‐mitigation criteria > > Overall you bring up many good points, but I think most of the > responses were trying to directly address the questions asked. Given > they are about interpretations of specific audit criteria, it is > important that the responses are correctly scoped. If this had been > about the question you asked, the more generic one about how to handle > malware-distributing sites, that would have been different. > > Thanks, > Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
