Certificate vulnerable to fermat factorization

[Hanno Böck]

Hi,

https://crt.sh/?id=7581884753&opt=ocsp
is a certificate with a private key that can be broken with fermat
factorization [1] as the two RSA primes are close to each other. It has
been issued in September and is currently unrevoked.

I am not sure if there's currently an expectation to check for this
type of vulnerability (though I've been CCed on a few mails back in
July where there was a proposal to have more clarity on what weak keys
to check in the cabforum rules, and this was one of the things in it,
but I don't know what the current status there is). But I would
recommend that all CAs implement this check. There have been a few such
certificates in the wild and the check is easy to do (see [2] for the
badkeys code doing the check).


[1] https://fermatattack.secvuln.info/
[2]
https://github.com/badkeys/badkeys/blob/main/badkeys/rsakeys/fermat.py

--
Hanno Böck
https://hboeck.de/

[Aaron Gable]

Zlint also has a check for this in version 3.4.0 (released this month), and on master since July.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20221029214539.182e35be%40computer.

[Chris Kemmerer]

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.

Chris Kemmerer
SSL.com

[Matthias van de Meent]

On Wed, Nov 2, 2022 at 4:00 PM Chris Kemmerer <cskem...@gmail.com> 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