On Thu, Mar 7, 2019 at 8:29 PM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Past analysis and discussion have shown the interpretation is hardly > specific to a single CA. It was a problem quite literally publicly > discussed during the drafting and wording of the ballot. References were > provided to those discussions. Have you gone and reviewed them? It might be > helpful to do so, before making false statements that mislead. > The actual text of the guideline is quite clear -- in much the same manner that frosted glass is. "Effective September 30, 2016, CAs SHALL generate non-sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG. " [1] Irrespective of the discussion underlying the modifications of the BRs to incorporate this rule, there are numerous respondent CAs of varying operational vintage, varying size, and varying organizational complexity. The history underlying a rule should not be necessary to implement and faithfully obey a rule. And yet... Rather than have us theorize as to why non-compliance with this rule seems to be so widespread, even by a number of organizations which have more typically adhered to industry best practices, would you be willing to posit a plausible scenario for why all of this non-compliance has gone on for so long and by so many across so many certificates? Additionally, assuming a large CA with millions of issued certificates using an actual 64-bit random serial number... Should the CA also do an exhaustive issued-serial-number search to ensure that the to-be-signed serial number is not off-by-one in either direction from a previously issued certificate serial number? However implausible, if it occurred, this would indeed result in having participated in the issuance of 2 certificates with sequential serial numbers. I agree with Peter Gutmann's statement. Whatever the cause for the final language in BR 7.1, the language as presently presented is awful and needs to be fixed in such a manner as will eliminate ambiguity within the rules. I cannot imagine that would hurt compliance, but I rather suspect it may improve it. [1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.3.pdf _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
