I’m chiming in, Dimtris, as it sounds like you may have unintentionally misrepresented the discussion and positions, and I want to provide you, and possibly HARICA, the guidance and clarity it needs in this matter.
On Sat, Mar 9, 2019 at 12:46 AM Dimitris Zacharopoulos via dev-security-policy <[email protected]> wrote: > I am personally shocked that a large part of this community considers > that now is the time for CAs to demonstrate "agility to replace > certificates", as lightly as that, without considering the significant > pain that Subscribers will experience having to replace hundreds of > thousands of certificates around the globe. It is very possible that > Relying parties will also suffer availability issues. I believe this significantly misunderstands the discussion and motivation. Having read all of the discussion to date, I do not believe this is at all an accurate framing of the expectations or motivations. I would humbly ask that you provide citations to back this claim. You are correct if you were to say one or two people have provided such a goal, but that’s certainly not consistent with the majority of the discussion to date from the root program participants. Indeed, the expectation expressed is that, *as with every other incident*, the CA consistently follow the expectations. I highlight this, because I don’t think it’s reasonable to conflate existing expectations, which have been repeatedly clarified, as somehow motivated by some other motivation based on one or two participants’ views. If you truly feel this way, please revisit the discussion in https://groups.google.com/forum/m/#!topic/mozilla.dev.security.policy/S2KNbJSJ-hs , as I hope that mine and Wayne’s responses can demonstrate this. Judging by that thread, only a single voice has expressed something remotely as to how you’ve phrased it. I don't know if others share the same view about the interpretation of > 7.1 but it seems that some highly respected members of this community > did. If we have to count every CA that had this interpretation, then I > suppose all CAs that were using EJBCA with the default configuration > have the same interpretation. I believe this also misunderstands the discussion to date, and as a consequence misrepresents this. I don’t believe it is reasonable or fact based to suggest that the CAs that had incidents necessarily shared the interpretation. The incident reports demonstrate that there are a myriad reasons, beyond interpretive differences, that one can find themselves in such a situation. Avoiding conflating the two is necessary, although if you feel it is justified, then I would implore you when summarizing others views to support your view, that you provide the direct links and references. This makes it easier to respond to and provide CAs the necessary clarity of expectations, as well as allows other participants to evaluate and judge themselves the accuracy of the summary. BTW, the configuration in EJBCA that we are talking about, as the > default number of bytes, had the number "8" in the setting, resulting in > 64-bits, not 63. So, as far as the CA administrator was concerned, this > setting resulted in using 64 random bits from a CSPRNG. One would have > to see the internal code to determine that the first bit was replaced by > a zero. This is exactly the point. CAs have an obligation to understand the code they’re using, regardless of the software platform. The failing is not with EJBCA, it is with the CAs that have done so. While there are a number of considerable and profound benefits to using EJBCA - most notably, it seems, in the dearth of issues the CAs presently reporting have had compared to those using closed-source platforms or home-grown platforms - the strength of that platform is not a reasonable mitigation for the CAs not being thorough. Every CA, when Ballot 164 was passed, had a clear obligation to review how they construct serial numbers, from the technical implementation to the policy configuration. CAs that did so could have placed in a request for the newly announced functionality, or, given the open source nature, contributed such a change themselves. That is guidance that stands regardless of the serial number, and trying to conflate it as somehow a unique response to this incident only does it a disservice. IMO, Mozilla should also treat this as an incident and evaluate the > specific parameters (strict interpretation of section 7.1, CAs did not > deliberately violate the requirement, a globally-respected software > vendor and other experts had a different allowable interpretation of a > requirement, the security impact on Subscribers and Relying Parties for > 1 bit of entropy is negligible), and consider treating this incident at > least as the underscore issue. In the underscore case, there was a SCWG > ballot with an effective date where CAs had to ultimately revoke all > certificates that included an underscore. The response from Wayne in https://groups.google.com/forum/m/#!topic/mozilla.dev.security.policy/S2KNbJSJ-hs already sets the clear expectations, which are and have been consistent with how we handle incidents. It’s thoroughly unproductive to have this discussion every time there is an incident, especially when the principles and goals are quite sound and to the benefit of users. There is nothing punitive about them, and rather clear guidance about the expectations. While a point-by-point comparison to underscores could be made, with the result being a very clear diverengence in the material facts, the end result would still be the consistent application of principles. I don’t think treating misissuances as popularity contests is indeed productive - that same logic would have us ignore many of the requirements, given https://wiki.mozilla.org/CA/Incident_Dashboard . > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
