G’day Folks, I want to thank Ryan for sharing the relevant discussion history regarding the change that precipitated the current language for serialNumber entropy in the BRs. Based on this background, it is clear to DM what is required for expected compliance with this control and that this was unilaterally applied across all CAs. (I will save the discussion for when we should take the BRs at face value and when we must delve into the history of each specific ballot precipitating a change to another time – this is a potentially difficult challenge for newly applying members who do not have the benefit of a history of participation to fall back on). DM has already committed to updating our platform with double the required entropy for serialNumber as soon as practically possible. We have determined that with the help of our vendor, we can achieve this within the next 24 hours. DM has currently stopped issuance of any public trust TLS certificates until the serialNumber entropy is updated. DM has compiled a list of all certificates issued that are still valid and have a 64-bit serialNumber. We have begun contacting each certificate owner to advise them that their certificate will be revoked within 24 hrs, and that DM will provide a replacement cert for them. A challenge we face is that it is end of day Wednesday here, and Thursday is the end of the Work Week in UAE. It may not be possible to contact all certificate admins in the next 24 hours, and scheduling emergency updates in infrastructures at short notice may have a low probability of success. Since the vulnerability associated with the entropy of serialNumber I believe should only manifest during issuance and not for operation of the certificates, we may potentially hold off revoking the affected certificate until the appropriate admin can be reached so as to minimize risk to our customers and their services. We expect the majority of active certificates to be replaced within 24 hours as required, and will inform the Group if there are any outstanding revocations that do not meet this timeline. In terms of our Root submission to Mozilla (and other browsers) we will need to re-engage our WebTrust Auditors to be present before replacement hierarchies can be established. This may take up to a couple of weeks. Updated hierarchies will be resubmitted to the root inclusion process once they are available.
Further, we will post a bug report to capture these actions and subsequent updates. Regards, -- Scott Rea On 2/27/19, 11:55 AM, "dev-security-policy on behalf of Ryan Sleevi via dev-security-policy" <[email protected] on behalf of [email protected]> wrote: 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 < [email protected]> 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 < > [email protected]> 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" <[email protected] on > > behalf of [email protected]> 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 > > [email protected] > > > > 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. > > > > > > > > > > > > > > > > > > Scott Rea | Senior Vice President - Trust Services Tel: +971 2 417 1417 | Mob: +971 52 847 5093 [email protected] 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 > > [email protected] > > https://lists.mozilla.org/listinfo/dev-security-policy > > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
