On Thu, May 19, 2016 at 09:15:00AM -0700, kirkhall...@gmail.com wrote: > “Yes, of course – that’s required under the Baseline Requirements (BRs) > and related WebTrust audit requirements.”
That's an issue to be taken up with the CA/B Forum and the progenitors of the audit requirements. It's irrelevant for a discussion of Mozilla policy. > 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. CAs have an absolute duty to protect Relying Parties from misidentification. Everything else is marketing. > http://blog.trendmicro.com/trendlabs-security-intelligence/lets-encrypt-now-being-abused-by-malvertisers/ Aaaaand here's the real motivation. You're out to protect the DV revenue stream of legacy CAs by loading more and more irrelevant bureaucracy on top of the *necessary* activities required to issue DV certificates. I find it rather disingenuous (and disappointing) that you didn't disclose your affiliation with Trend Micro when citing their marketing material in support of your arguments. You're hardly a disinterested observer in these discussions. > 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. If you believe that Lets Encrypt failed in their duties under the BRs, then I'd recommend presenting that evidence in the relevant Mozilla inclusion discussion, and to the organization(s) which have cross-signed their certs. On the other hand, if they *haven't* contravened the BRs, then as demonstrated by your own research, the controls in the BRs are insufficient to meaningfully protect users from malware, and they shouldn't be considered a valuable contribution to a Mozilla policy discussion. Which way are you going to go? > 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?? Why, indeed? I wonder that every time another report of misissuance from a CA comes out, whether that's certificates mistakenly issued for well-known sites, or collusion between CAs and unspecified organisations attempts to subvert the strenuous efforts of browsers parties to improve the security of *all* users by removing known weak algorithms from the web PKI. > 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. What's that got to do with Mozilla policy? > 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, Except we can't in any meaningful fashion, because the CA/B Forum isn't open to public participation, but instead only pre-approved voices are allowed to meaningfully participate in the debate. But that's irrelevant for a discussion of *Mozilla* policy. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
