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
certificates.
But certainly, further arguments on this point are best suited for another
forum, because there is no good reason to change here.
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
