On 08/08/2017 19:44, Ryan Sleevi wrote:
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 idea"
> 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.

Actually I have long considered it a bug/errata in the PKIX standards.
Thus I was somewhat triggered when this suddenly became an enforced
rule.  I wasn't making this up to defend the CA that issued those

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


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

Reply via email to