On Monday, March 16, 2020 at 2:46:46 PM UTC-5, Ryan Sleevi wrote: > On Mon, Mar 16, 2020 at 3:12 PM Chris Kemmerer via dev-security-policy < > [email protected]> wrote: > > > > It would appear that SSL.com is a member in good standing of the CA/B > > Forum. > > > Is there any intention on the part of SSL.com to propose this change as a > > > ballot? While you're at it, if you could include a fix for the issue > > > described in https://github.com/cabforum/documents/issues/164, that > > would be > > > appreciated, since it is the same sentences that need modification, and > > for > > > much the same reasons. > > > > Yes, this is reasonable, and we treated such key as compromised, revoking > > it within 24 hours. > > > > We would support a ballot that makes this clear. We also monitor the > > discussion in https://github.com/cabforum/documents/issues/164. > > > > While you answered "Yes", you followed with a different clarification. "We > would support" seems different from "Is there any intention on SSL.com to > propose"
Yes, we are happy to propose a ballot change to the BR language pertaining to this issue. > > > We have responded as to how we interpreted and implemented this > > requirement. Our blacklist did not include the entire set of Debian weak > > keys. We have been completely transparent about this issue and we have > > improved our weak key detection mechanism to include the openssl-blacklist > > package. > > > > We examined similar failures/incidents, such as: > > > > - https://bugzilla.mozilla.org/show_bug.cgi?id=1472052 > > - https://bugzilla.mozilla.org/show_bug.cgi?id=1435770 > > - > > https://community.letsencrypt.org/t/2017-09-09-late-weak-key-revocation/42519 > > > > The last one shows that at least one more CA had a similar interpretation > > of the BRs. > > > > Having read these, while I appreciate SSL.com highlighting them, I fail to > see them supporting the claim being made here. Could you please elaborate > why/how you believe this statement to be true? They seem rather remarkably > different, and certainly, the last one highlights a CA actively working to > be comprehensive, while much of SSL.com's reply seems to be "We shouldn't > have to be comprehensive" We were merely pointing out previous discussions on this topic. I can see why you may have such an impression, but "we shouldn't have to be comprehensive" is not what we are thinking or believe. On the contrary, we've increased our efforts to be as comprehensive as possible, and we will continue to expand our weak keys list even after this issue is closed. We believe in a robustly secure ecosystem, not in half measures. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
