On Tue, 21 Mar 2023 at 21:29, 'Chris Clements' via CCADB Public <[email protected]> wrote: > > All, > > This email commences a six-week public discussion of SSL.com’s request to > include the following certificates as publicly trusted root certificates in > one or more CCADB Root Store Member’s program. This discussion period is > scheduled to close on May 2, 2023. > > The purpose of this public discussion process is to promote openness and > transparency. However, each Root Store makes its inclusion decisions > independently, on its own timelines, and based on its own inclusion criteria. > Successful completion of this public discussion process does not guarantee > any favorable action by any root store. > > Anyone with concerns or questions is urged to raise them on this CCADB Public > list by replying directly in this discussion thread. Likewise, a > representative of the applicant must promptly respond directly in the > discussion thread to all questions that are posted. > > [...] > > Incident Summary (Bugzilla incidents from previous 24 months): [...] > > - 1800753: SSL.com: Delayed revocation of certificate with weak key
In this issue I expressed my concerns about SSL.com's lack of urgency regarding detecting, handling, and responding to reports about, and awareness of, weak public keys in the timelines required by BRs 4.9.1.1 par.1 item (4). The issue itself concerns the revocation timeline of a certificate that contains a public key vulnerable to Fermat Factorization, where the problem wasn't reported through the CA's normal certificate problem report flow, but instead was reported on the public forum of [email protected]. After SSL.com publicly acknowledged that there could be problems with the certificate (and thus had become aware of the existence of the problem), they still took more than 24 hours to revoke the certificate without considering that timeline problematic, with their reasoning being as follows: > However, as the current BRs and our CP/CPS remain silent about characterizing > the Fermat’s factorization method as “a demonstrated or proven method that > can easily compute the Subscriber’s Private Key”, especially without > additional details about the number of rounds needed to factor the key, we > did not consider that the 24h revocation timeline applied. In particular, we > proceeded with revocation within the 5-days timeline defined in BRs 4.9.1.1 > par.2 item (11), which says (emphasis ours): > > “The CA is made aware of a demonstrated or proven method that exposes the > Subscriber's Private Key to compromise or **if there is clear evidence that > the specific method used to generate the Private Key was flawed** ”. To me, this argument doesn't hold, because the problem report nor the certificate identified any information about what way the private key was generated. I find it concerning that the CA does not do due diligence and validate the claims of a report on a potentially problematic certificate, but instead states that Fermat Factorization is not mentioned by name in the BR and that the CA thus doesn't have to revoke the certificate in the 24-hour time window: according to the first mail from SSL.com in the dev-security-policy mail, the certificate was to be revoked "out of an abundance of caution", and not due to the requirements agreed upon in the BR. Because the relevant public key is factored in 1 round of Fermat's Factorization Method, this makes it difficult to believe that SSL.com did any work on validating the claims of the post on the forum: They acknowledged that the certificate's public key could have problems but did not effectively act on that suspicion. This issue makes me wonder whether SSL.com is able to handle reports on novel weaknesses in public keys appropriately, as they don't seem to be able to handle knowledge about known vulnerabilities like close primes/Fermat Factorization without waiting for a CA/B Forum ballot to get through the approval process. Note that I don't advocate that all CAs must run hours of Fermat's on each certificate's public keys, but that when a CA is confronted with the knowledge that a certificate's public key may be weak to a certain attack, then it should do its due diligence by testing at the very least the most trivial version of the attack to check whether the claim that the PK is vulnerable might be true. In this case, that was apparently too much for SSL.com. All in all, I am concerned about SSL.com's ability to comply with the BR in those places where the BR describes only the broad ideas without specifics, like those in section 4.9.1.1 par.1 item (4), especially when it concerns security, key material, and/or revocation timelines of certificates. Kind regards, Matthias van de Meent -- You received this message because you are subscribed to the Google Groups "CCADB Public" 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/ccadb.org/d/msgid/public/CAAT_OQuUCVC9%2BXN%3DsaKYWNiv_aOkCsyFbE8F%3DQW0_JcnPzDsjQ%40mail.gmail.com.
