This has been a very surprising discussion to me. If most CAs were asked “Do you think CAs are supposed to investigate and revoke one of your certificates that is reported to you for injecting malware on Relying Parties clients?” their answer would be “Yes, of course – that’s required under the Baseline Requirements (BRs) and related WebTrust audit requirements.” So I’m very surprised to see some on this list say CAs have no duties at all to protect Relying Parties, or that their duties are somehow limited to “identity” issue.
Kathleen’s list of applicable BR sections should also include BR 4.9.3:
4.9.3. Procedure for Revocation Request
"*** The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means."
1. Breakdown of BR Requirements
This is a long post, but the subject is very important.
Looking at the BR requirements quoted in Kathleen’s initial message, it’s clear they deal with two separate processes and requirements for CAs: (a) CA’s must follow a process to revoke certificates already issued (and perhaps do other things, like report the subscriber to law enforcement), and (b) CAs must follow a process for refusing to issue new certificates to a subscriber.
2. Provisions requiring a CA to revoke a certificate
Looking at (a) first as a logical workflow, here is what the BRs require a CA to do concerning revocation of certificates already issued.
(A) Provide Relying Parties and other third parties “with clear [online] instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates.” BR 4.9.3. This is a separate requirement from the provisions using the term “Certificate Problem Reports”.
[Why would the BRs require this unless the CA is supposed to do something about reported misuse, fraud, inappropriate conduct, or “any other matter related to Certificates”?]
(B) This is supplemented by new BR 4.9.2, added just three months ago, in February 2016:
“4.9.2 Who Can Request Revocation. *** Subscribers, Relying Parties, Application Software Suppliers, and other third parties may submit Certificate Problem Reports informing the issuing CA of reasonable cause to revoke the certificate.”
Note that this is pretty wide open – a relying party can request revocation of a certificate issued to a subscriber upon any “reasonable cause.”
(C) The CA shall maintain a “continuous 24x7 ability to respond internally to a high-priority Certificate Problem Report, and where appropriate, forward such a complaint to law enforcement authorities, and/or revoke a Certificate that is the subject of such a complaint.” BR 4.10.2 on Service Availability.
Note that CAs “shall” revoke a certificate and/or report to law enforcement where appropriate.
This section uses the term Certificate Problem Report, which is defined as “Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates.” That is pretty broad, and ties fairly closely to the reporting language in BR 4.9.3.
(D) The process that the CA “shall” follow after receiving a “Complaint of Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates” is laid out with some specificity in BR 4.9.5. This is not optional, but mandatory:
"The CA SHALL begin investigation of a Certificate Problem Report within twenty-four hours of receipt, and decide whether revocation or other appropriate action is warranted based on at least the following criteria:
1. The nature of the alleged problem;
2. The number of Certificate Problem Reports received about a particular Certificate or Subscriber;
3. The entity making the complaint (for example, a complaint from a law enforcement official that a Web site is engaged in illegal activities should carry more weight than a complaint from a consumer alleging that she didn’t receive the goods she ordered); and
4. Relevant legislation. ***"
Clearly the CA must investigate, make judgments, and take action (for example, if the Web site is “engaged in illegal activities” the CA should probably act and revoke the certificate, while if a consumer complains about missing goods the CA probably doesn’t need to act or revoke). Once the CA has completed the process of investigation and analysis, the CA must “decide whether revocation or other appropriate action is warranted.”
Those who say that CAs have no duty to investigate and act after receiving complaints covering “Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates“ are not correct.
(E) There’s another independent requirement for revocation (BR 4.9.1.1), but this does not limit or override the stronger provisions quoted above:
"The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: ***
4. The CA obtains evidence that the Certificate was misused;"
It’s not very useful to play the dictionary game, but here is the first definition I found for the word misused: “to treat badly or abusively; maltreat.” That seems pretty close to the string “Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates” used in other sections on revocation of a certificate, and it certainly would encompass things like a website that engages in illegal activities or injects malware on relying parties’ clients.
2. Provisions requiring a CA to follow checking procedures before issuing a certificate
The other provisions quoted by Katherine do not relate to revocation of issued certificates, but instead list checks that CAs must do before issuing a new certificate and which may result in refusal to issue the new certificate. These are separate and independent CA requirements from certificate revocation (note that the decision whether to issue a new certificate to a subscriber depends in part on whether the CA has previously revoked a subscriber’s certificate).
Here are those relevant provisions:
“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.” BR 4.2.1
So what are High Risk Certificate Requests? Here is the definition, broken down by individual criteria for easier reading:
“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.”
All certificate requests received by a CA are potentially “high risk certificate requests” at the start – the CA will only know after running each and every certificate request through the types of tests listed at [a] through [d] above. Note that under BR 4.2.1 the CA is required to perform “additional verification activity” once a high risk certificate has been identified – the CA can’t just close its eyes and issue the certificate.
Note also that criteria [b] includes names (presumably both identity names and domain names) contained in previously rejected requests or revoked certificates – so certificate revocation is very important under BR 4.2.1 to the later decision on whether to issue a new certificate to the same subscriber (or in the same name).
3. Is “misuse” limited to “identity”?
Some postings have suggested that revocation is only required for “misuse,” and that misuse is limited to cases where the CA made a vetting mistake and issued a certificate to the wrong party (and/or with the wrong identity information inside).
Clearly this is not the case – many sections of the BRs go way beyond “misuse” and require revocation for “Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates”. Note that the word “identity” never shows up in any of the applicable BR sections, although errors by the CA in issuing to the wrong party or with the wrong information inside could clearly be one form of misuse justifying or even requiring revocation. (I would say that revocation for improper authentication is required by other BR sections instead, including the CA warranties section.)
4. Response to Kathleen’s questions
So here are my responses to Kathleen’s questions (representing my personal opinion only, not those of my company).
1) What does "Certificate misuse, or other types of fraud" in the definition of Certificate Problem Report actually mean?
[KH] See discussion above. It includes “Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates”, and could potentially involve “illegal activities,” “phishing or other fraudulent usage,” and other types of bad activity that puts a subscriber on the “Miller Smiles phishing list or the Google Safe Browsing list.” (Please forgive all the quotation marks, but these are all mentioned in the relevant BRs quoted above – they must mean something.)
Note that these provisions do not make CAs the Internet Police – instead, the BRs require CAs to set up and follow procedures and make reasonable judgments about revocation and refusal to issue. It’s not that hard to do, and most CAs are doing it today – and their WebTrust auditors want to see that they have a process in place and are following it.
In the past, fraudsters didn’t need to use SSL to do their work – but with the move to “https everywhere,” soon the fraudster websites won’t work without a certificate as the browsers require SSL to render a “normal” UI instead of a warning. Internet security works best when everyone helps fight the fraudsters – starting with the CAs (who can revoke or refuse to issue, thereby making it hard or impossible for fraudsters to maintain their malware sites), and continuing with browsers (through such features as Microsoft SmartScreen and Google Safe Browsing - although not all users will be protected by these features, and some bad sites may never be reported) and security software companies. No one line of defense can block every fraudster, so it’s important to have many lines of defense, including CAs.
2) What does "misused" mean in Section 4.9.1.1?
[KH] See my comments at (5) above – Section 4.9.1.1 is a relatively unimportant provision, as certificate misuse is just one of 15 listed “Reasons for Revoking a Subscriber Certificate.” Section 4.9.1.1 may function mainly to fill in that part of RFC 3647, which lists the provisions that should be in a CA’s CPS. The more important BR provisions on required revocation are as described at 2(A) through (D) above, which go far beyond the word “misused”.
However, as discussed at 2(E) above, I think “misused” at 4.9.1.1 should be interpreted as the same as “Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates” used in the other applicable BR sections on revocation of a certificate. There’s no reason to limit misuse to something narrower, such as identity only.
3) 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?
[KH] Absolutely yes. It falls within “Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates” as well as “illegal activities”.
How can CAs know if a subscriber site is injecting malware? In most cases they can’t know independently (although if the subscriber website is listed with the Anti-Phishing Working Group, Microsoft SmartScreen, Google Safe Browsing, etc. that’s a pretty conclusive reason for refusing to issue the certificate – in the past, CAs I have been associated with have required a subscriber to get its name off a blacklist before we would issue a certificate).
In addition, security software companies are constantly looking for bad sites (such as those injecting malware) and are notifying the CAs who issued the certificate to request revocation. See, for example, the following report from Trend Micro:
http://blog.trendmicro.com/trendlabs-security-intelligence/lets-encrypt-now-being-abused-by-malvertisers/
The TrendLabs group found two websites (later five) apparently compromised by bad actors using a technique called “domain shadowing” who obtained certificates for legitimate websites. The bad actors then placed their encrypted ads on the websites that led to sites hosting the Angler Exploit Kit, which would download a banking Trojan onto the affected user machines.
One point of the TrendLabs report is that with the increasing availability of DV certs from many CAs, and the difficulty that security software can have in scanning encrypted web content for malware, these types of exploits are likely to increase. This is especially true as browsers start to require https everywhere, which pushes fraudsters to encrypt their malware. So revocation by CAs of certificates used to hide malware has become even more important. Why wouldn’t a CA want to help protect users??
In cases such as this, I think the CA could confidently rely on a security company’s research, and after requesting a response from the subscriber (that’s basic due process), must proceed and revoke the certificate under the BRs and add the name to its High Risk Certificate Request database so it will never issue a certificate to the subscriber in the future.
4) Does a website who is known to an issuing CA to inject malware count as high risk?
Yes. See discussion at Section 2 above concerning procedures that CAs must follow for High Risk Certificate Requests and refusal to issue a certificate to a subscriber. These requirements include checking the following types of criteria and databases, and refusal to issue if appropriate based on the information found by the issuing CA:
"[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, ***"
What can put a “name” (domain name or identity name) on one of these blacklists? Certainly for being a website known to an issuing CA to inject malware. Such malicious activity is very much “high risk” and should prevent a subscriber from receiving a certificate from the CA.
5) Are CAs required to maintain a list/database to prevent issuance of SSL certificates for websites that are known to them to inject malware?
Yes. See discussion in prior paragraph. Websites that are known for injecting malware will end up on one or more of the blacklists listed above, which the CA must consult before issuing a certificate to a subscriber. In addition, once a CA revokes a certificate for a site it knows has injected malware, it must add that subscriber to its own blacklist and refuse to issue any more certificates in the future.
5. Conclusion
Looking at some of the prior postings on this string, I think some people are not actually reading the BRs and WebTrust/ETSI requirements on certificate revocation, but instead are just stating their personal opinion of what the rules *should* be – namely, that a CA should do nothing, just issue certificates when requested, and never revoke anything. That’s just not what the BRs and related audit requirements say – and CAs will be tested on that by their auditors.
While the language of the BRs could have been written better the intent is very clear, and I don’t think the BRs need any clarification as to the necessity of revoking a certificate known to be used for injecting malware – it must be done. I can say this as a person who has worked with several CAs on compliance and WebTrust audit issues over many years – this is the common interpretation and the common practice among CAs.
If people want to remove the current BR revocation requirements for certificates used to hide malware, they can ask to amend the BRs to strip out the current revocation provisions, but the proposal is unlikely to pass – most CAs think they have an important role to play in fighting malware injection and other types of certificate misuse.