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" > 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" _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
