All, Please note that we have replied to the remaining remarks from Ben's review of our CP/CPS in https://bugzilla.mozilla.org/show_bug.cgi?id=1799533#c11. This was posted yesterday, April 26, 2023. Thank you, Tom for SSL.com
On Tuesday, 25 April 2023 at 11:50:46 UTC-5 Leo Grove wrote: > Thank you for the reminder Chris, we plan on replying to the root > inclusion application tomorrow with updates on our CPS changes based on > Ben's remarks. > > Regards, > Leo > ------------------------------ > *From:* 'Chris Clements' via CCADB Public <[email protected]> > *Sent:* Tuesday, April 25, 2023 8:07 AM > *To:* Thomas Zermeno <[email protected]> > *Cc:* CCADB Public <[email protected]>; Ben Wilson <[email protected]> > *Subject:* Re: Public Discussion of SSL.com CA Inclusion Request > > > All, > > This is a reminder that the public discussion period on the inclusion > application of SSL.com will close next Tuesday, on May 2, 2023. > > Thank you, > > Chris, on behalf of the CCADB Steering Committee > > On Fri, Apr 21, 2023 at 4:37 PM Thomas Zermeno <[email protected]> wrote: > > All, We have responded to Ben's comments in Bug #1799533 at > https://bugzilla.mozilla.org/show_bug.cgi?id=1799533#c10. Kind Regards, > Tom > > On Friday, 7 April 2023 at 12:14:57 UTC-5 Ben Wilson wrote: > > All, > > I have just completed a CP/CPS review of SSL.com's CP/CPS v. 1.16 and > attached it to Bugzilla Bug #1799533 (https://bugzilla.mozilla.org/ > show_bug.cgi?id=1799533). See > https://bugzilla.mozilla.org/attachment.cgi?id=9327554 (Excel > Spreadsheet). > > I would like SSL.com to read through my comments and respond to them in > Bug # 1799533. > > Thanks, > > Ben > > On Fri, Mar 31, 2023 at 2:58 PM Thomas Zermeno <[email protected]> wrote: > > In response to > https://groups.google.com/a/ccadb.org/g/public/c/mTUkK-gkHPE/m/WBaf7QUnAwAJ, > starting from the Matthias’ last statement we would like to point to our > actions as explained in [1], [2] and [3], which demonstrate SSL.com’s > ability to monitor, analyze and take informed decisions, addressing > particular cases in accordance with the BRs. > > More specifically, our immediate actions demonstrate: > > i) active monitoring of industry channels such as m.d.s.p., which > allowed capturing a case which was not reported via the required channels, > as published in our CP/CPS section 4.9.3 per provisions of BRs section > 4.9.3; > > ii) ability to respond swiftly with expedited deployment and testing > of technical control updates (pre-issuance linting), effectively blocking > any similar issuances; > > iii) provident care to retrospectively test against the entire corpus > of certificates, confirming no other occurrences exist; > > iv) due diligence by promptly analyzing the technical and compliance > aspects of the issue at hand, considering the relevant literature and the > applicable requirements, thus leading to informed decisions instead of > acting hastily; > > v) eagerness to test our processes and identify possible improvements > by handling the issue as a real-world case, acting in communication with > the subscriber and reporter (in this case, the same person). > > In our opinion, completing the above-mentioned actions (analysis, > decision, notification, revocation, retrospection and mitigation) within 26 > hours, is not a sign of “SSL.com's lack of urgency regarding detecting, > handling, and responding” as stated in Matthias opening statement. > > It is worth explaining the rationale of our actions, and more specifically > why we didn’t make an earlier revocation decision. Context played a > decisive role here. If we had received a Certificate Problem Report (CPR) > per section 4.9.5 of the BRs, we would be forced to follow the exact > deadlines specified in the CPR procedure (confirmation, revocation decision > and execution within 24 hours of receipt of the CPR). We would have a > significantly different approach (lower level of analysis depth, lower > priority in updating preventive controls, etc.). Since this case was > reported in a public mailing list, we considered it better to do a more > in-depth analysis as due diligence and use this time to prioritize other > equally important actions (preventive controls, retrospection). > > Overall, we would like to state that this is not a case of a CA trying to > escape its obligations. With [3] we made clear that, in our opinion, and in > accordance with the expectations of the industry, a CA may not arbitrarily > extend the period of investigation and use it as an excuse to delay > revocation. We have also been completely transparent and tried to detail > the rationale of our actions. As stated in [2], if the root store owners > considered this a violation or found any value in filing an incident > report, we would do so. However, no such request was made (for the more > than two months after our December response, which further explained our > rationale); on the contrary, [4] is a clear indication that our actions > were considered reasonable and compliant. > > As a publicly-trusted CA, we have handled numerous cases of CPRs reporting > vulnerable or other forms of compromised keys and we have followed the > requirements to the letter. Our annual audits confirm our compliance with > these requirements. > > However, we are using this case as a learning opportunity. Handling it as > a real-world report, rather than as a security researcher’s exercise, > allowed us to test our processes and draw useful conclusions which will > improve our understanding and the maturity of our processes going forward. > For example, this allowed us to do further research on weak keys, which is > shortly presented in [6] and which will be used in delivering Ballot SC-59. > > [1] > https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/TlhjCJm610I/m/LmlR3tJCBAAJ > > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1800753#c2 > > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1800753#c6 > > [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1800753#c7 > > [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1800753#c8 > > [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1800753#c11 > > > On Wednesday, 29 March 2023 at 11:43:00 UTC-5 Matthias van de Meent wrote: > > 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/5c8a49d2-914f-4019-8cd4-fd2487271ad9n%40ccadb.org > > <https://groups.google.com/a/ccadb.org/d/msgid/public/5c8a49d2-914f-4019-8cd4-fd2487271ad9n%40ccadb.org?utm_medium=email&utm_source=footer> > . > > -- > 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/6a8dca06-087e-4818-b41a-5e5212271ffcn%40ccadb.org > > <https://groups.google.com/a/ccadb.org/d/msgid/public/6a8dca06-087e-4818-b41a-5e5212271ffcn%40ccadb.org?utm_medium=email&utm_source=footer> > . > > -- > 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/CAAbw9mCKFij5JEgfSoQZUC7%2BOn8R_mTjo9WSTfYCzq3YU4Zmmg%40mail.gmail.com > > <https://groups.google.com/a/ccadb.org/d/msgid/public/CAAbw9mCKFij5JEgfSoQZUC7%2BOn8R_mTjo9WSTfYCzq3YU4Zmmg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/46dece95-f85b-4b8f-8f4a-baff852e471cn%40ccadb.org.
