On Tuesday, August 8, 2017 at 6:31:34 AM UTC+9, Jakob Bohm wrote: > On 07/08/2017 23:05, Vincent Lynch wrote: > > Jakob, > > > > I don't see what is wrong with Jonathan reporting these issues. The authors > > and ratifiers of the BRs made the choice to specify these small details. > > While a minor encoding error is certainly not as alarming as say, issuing > > an md5 signed certificate, it is still an error and is worth reporting. > > > > I believe it is decidedly off-topic to debate what BR violations are worth > > reporting. > > > > If you think certain BR rules are outdated or sub-par, I am sure the > > community would welcome that discussion but it should be its own thread. > > > > 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. > > Do we really want the CA community to be filled with bureaucratic > enforcement of harsh punishments for every slight misstep? This is the > important question that any organization (in this case this community) > needs to ask itself whenever new surveillance abilities make it possible > to catch microscopic infractions. > > Do we want to be the kind of place where people are punished for not > polishing their boots perfectly or having a picture of their wife on > their desk? (To mention other rules that some organizations have > overzealously enforced a long time ago). > > > > 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
As mentioned earlier, you would be best to start your own thread. As a peer for the module, I greatly appreciate the work Jonathan is doing, and encourage him to do more. If you feel otherwise, it may be best if you simply don't participate in those discussions, since the contrariness or explanations are not providing significant value to these discussions. As others suspected, the use of an HTTPS URI for OCSP effectively prevents clients from being able to check, as clients including NSS, CryptoAPI, Chrome, and SecureTransport all refuse to check OCSP via HTTPS due to circular dependencies. This means that the inclusion of such a URL does not provide revocation services, and as those are presently required by the BRs, fails to meet those objectives. Your proposed approach - of dividing things you feel are serious or minor - are actively harmful to the efforts of this community, in part due to seeming to lack sufficient context to assess the seriousness or minorness of the impact (as shown in this week's threads). Issues you have felt were minor are, in fact, serious, and the prevalence of a myriad of minor issues has historically been and continues to be a reasonable signal for more serious issues in either policy or practice. Perhaps it may be worth holding back on sharing opinions at first, so that these technical details can be shared and a better sense of serious and minor developed. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
