As Matthew highlights, this is not a new or novel interpretation. It was introduced in Ballot 164 - https://cabforum.org/2016/03/31/ballot-164/
The first discussion of this in the CA/B Forum as a Ballot was https://cabforum.org/pipermail/public/2016-February/006893.html . This discussion continues through June of that year, when it went to a vote. During those discussions, there were concerns raised regarding entropy - which, admittedly, I raised initially, but you can see others sharing similar concerns. You can also see, however, in the discussions of GUIDs how those concerns turned out to be well-founded. Indeed, if you go to April, https://cabforum.org/pipermail/public/2016-April/007245.html , you can find discussion about how the maximum legally possible entropy was 159 bits, precisely for the reason we’re discussing. While Scott’s proposed language (“entropy”) has problems that the Forum discussed rather extensively, as to why it would be problematic, the question of the high but was also discussed during the ballot process. I believe the conclusion from that discussion was that it would be unlikely for CAs to rest on exactly 64-bit serials, as they would be able to avoid any ambiguity or confusion by simply increasing the serial number space (say, to 65 bits). Following this ballot, subsequent discussion was had regarding some CAs that included serials of exactly 64 bits, and how those could not be compliant. https://groups.google.com/forum/m/#!msg/mozilla.dev.security.policy/YequotPYLdc/J0K3lUyzBwAJ is such an example. On Wed, Feb 27, 2019 at 12:15 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > The issue I see with that interpretation is that the very same matter has > previously been discussed on this list and resolved quite vocally in the > favor of the other position: that making careful choices about the CSPRNG > output to conform it to mask out the high order bit makes the output of at > least that bit not truly the output of the CSPRNG but rather the output of > the mask. > > Pedantically speaking, I actually favor your analysis. But that probably > will do you no favors as to public perception at a time point when your > request for inclusion is at a crucial phase. > > On Wed, Feb 27, 2019 at 12:56 AM Scott Rea via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > G’day Wayne et al, > > > > I am not sure why members of the group keep making the claim that these > > certificates are misused under the BRs. > > Corey pointed to the following paragraph in Section 7.1 of the BRs as the > > source of the control that DM is accused of not complying with: > > > > “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.” > > > > DarkMatter has responded to show that we have actually followed this > > requirement exactly as it is written. Furthermore, since there seems to > be > > a number of folks on the Group that believe more stringent controls are > > needed, DM has agreed to move all its public trust certificates to random > > serialNumbers with double the required entropy following our next change > > control in the coming week. > > > > It is not a requirement of Section 7.1 that serialNumber contain random > > numbers with 64-bit entropy – which appears to be the claim you are > making. > > If this was the intention of this section in the BRs then perhaps we can > > propose such a change to the BRs. perhaps something like the following > > could be proposed: > > > > “Effective September 30, 2016, CAs SHALL generate non-sequential > > Certificate serial numbers greater than zero (0) and output from a CSPRNG > > such that the resulting serialNumber contains at least 64 bits of > entropy.” > > > > However, once again, I want to reiterate the current practice of DM for > > the public trust certificates that we have generated to date: > > 1. all serial numbers are non-sequential; > > 2. all serial numbers are greater than zero; > > 3. all serial numbers contain at least 64 bits of output from a CSPRNG > > > > As such, all DM certificates that Corey specifically highlighted were > > issued in compliance with the BRs and specifically in compliance with > > Section 7.1 that Corey quoted. > > > > If there is another requirement in the BRs in respect to serial numbers > > where it states that they must contain 64 bits of entropy then can you > > please point this out? > > > > > > Regards, > > > > -- > > > > Scott Rea > > > > On 2/26/19, 7:41 PM, "dev-security-policy on behalf of Wayne Thayer via > > dev-security-policy" <dev-security-policy-boun...@lists.mozilla.org on > > behalf of dev-security-policy@lists.mozilla.org> wrote: > > > > >I assume you are referring to those certificates containing a serial > > number with effectively 63-bits of entropy? They are misissued. BR > > section > > 4.9.1.1 provides guidance. > > > > > > > > > > Scott Rea | Senior Vice President - Trust Services > > Tel: +971 2 417 1417 | Mob: +971 52 847 5093 > > scott....@darkmatter.ae > > > > The information transmitted, including attachments, is intended only for > > the person(s) or entity to which it is addressed and may contain > > confidential and/or privileged material. Any review, retransmission, > > dissemination or other use of, or taking of any action in reliance upon > > this information by persons or entities other than the intended recipient > > is prohibited. If you received this in error, please contact the sender > and > > destroy any copies of this information. > > > > > > > > > > > > > > > > > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
