On Wed, Nov 2, 2022 at 4:00 PM Chris Kemmerer <[email protected]> wrote: > > We thank you for bringing this to our attention and are looking into this > issue. In the meantime: > > - We have completed the update of our zlint to v3.4.0. Since pre-issuance > linting is being used, this prevents similar issuances. Note that per our > standard change management processes, this update was caught by our > monitoring tools and was originally planned to be deployed in production in > early November. > - We have completed testing of our entire database of existing certificates > (retrospection) using the new version of zlint and confirmed no other > certificates are affected by this issue. > - In an abundance of caution, we are planning to replace the certificate in > coordination with the subscriber. > - A CA/B Forum ballot we proposed, intended to provide guidance to CAs for > handling Debian weak keys and similar vulnerabilities, includes (at the > suggestion of Martijn Katerbarg) language addressing the Fermat attack issue.
Isn't there already guidance in BR section 4.9.1.1, as item 4 in the list of "revoke within 24 hours", and in section 6.1.1.3 sub 5 for "reject certificate requests with this"? What other guidance would you need? On that topic: At what day or time did you receive (or start actions for) this mail? > - We have completed the update of our zlint to v3.4.0. Since pre-issuance > linting is being used, this prevents similar issuances. Note that per our > standard change management processes, this update was caught by our > monitoring tools and was originally planned to be deployed in production in > early November. > - We have completed testing of our entire database of existing certificates > (retrospection) using the new version of zlint and confirmed no other > certificates are affected by this issue. > - In an abundance of caution, we are planning to replace the certificate in > coordination with the subscriber. Following BRs4.9.1.1 (a)(4), this certificate should have been revoked within 24 hours of detection, but as of right now (2022-11-03 13:01:44 UTC) the certificate status in OCSP remains "Good". Unless you only detected the original mail and it's implications at 2022-11-03T13:00Z (or later) and were able to take all these actions within the following 2 hours, I doubt that the 24h requirement is being met. Will you create a bugzilla issue for the delayed revocation? Kind regards, Matthias van de Meent -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAAT_OQstnd%2B64_vzpy0czY3%2BaA1oYzEtPHE3TiJkfD2HeDYorg%40mail.gmail.com.
