Luckily we have tools like certlint, which can be run on certificates to catch this stuff!
I'd feel very differently if CAs were starting these threads because they'd caught issues with certlint, than the fact that independent researchers are noticing. Alex On Tue, Aug 8, 2017 at 7:52 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 08/08/2017 12:54, Nick Lamb wrote: > >> On Monday, 7 August 2017 22:31:34 UTC+1, Jakob Bohm wrote: >> >>> Since the CT made it possible, I have seen an increasing obsession with >>> enforcing every little detail of the BRs, things that would not only >>> have gone unnoticed, but also been considered unremarkable before CT. >>> >> >> Even if I had no other reason to be concerned about violations of the BRs >> (and I do have plenty, as we saw here in this case it looks like the >> certificate can be revoked but it effectively can't) the Brown M&M Rider >> reason is enough, >> >> The rider (hospitality and technical requirements for a performing >> artist) can be pretty detailed, some venues may glance at it and agree to >> whatever is inside without knowing the details. This is a _huge_ problem, >> and Van Halen is famous for a clause in their rider (requiring a bowl of >> M&Ms but with the brown ones removed) which they say existed not out of >> spite but precisely to check that the venue had actually read the rider in >> full and not just skimmed it, so that they would have early warning if a >> particular venue were sloppy and might cause surprise problems with >> technical implementation. >> >> We need CAs to be detail oriented. It is not enough to "kinda, mostly" >> get this job right. If you can't do _exactly_ what it says in the BRs, >> don't bother doing it at all. Neither Mozilla nor any other trust store >> compel CAs to stay in this business, if they decide they'd rather sell >> pancakes or mow lawns, that's up to them. So long as they want to be >> trusted public CAs, they need to obey the rules that are in place to make >> that safe for everybody. >> >> > While the Brown M&M Rider argument would be good if, like the van Halen > clause, there was only a small number of such intentional gotcha rules, > in this case we are dealing with a large corpus of rules, some explicit, > some in documents referenced from other documents etc. > > That makes the situation much more like the situation with other large > sets of rules for people to follow, which means that there will, in > practice, always be rules more important than others. And hence a > natural expectation that those tasked with enforcing the rules actually > know the difference and don't issue large penalties for what is > obviously minor infractions. > > Now in this *specific* case, it has been found that Mozilla's NSS > doesn't handle HTTPS OCSP URLs in a good way, and thus Mozilla has a > specific need to prevent their public use until NSS gains the ability to > handle them safely (because there is a benefit to it). Discussing that > benefit and planning appropriate transition plans is an issue for > another thread, possibly in another forum. > > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
