On Tuesday, August 8, 2017 at 8:52:54 PM UTC+9, Jakob Bohm 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.

While you may feel this way, it is again inaccurate to present it as such. It 
is an intentional design decision by the NSS and Firefox developers, made 
independently by folks at Apple, Google, and Microsoft as well for nearly two 
decades. This isn't "oops, NSS doesn't support it" - it is "this is a terrible 

I realize you are trying to present it as a bug, in order to justify the 
presence of brown M&Ms as "not important," but you are failing to recognize 
such URLs DO break implementations and are forbidden for legitimate reasons.

But certainly, further arguments on this point are best suited for another 
forum, because there is no good reason to change here.
dev-security-policy mailing list

Reply via email to