All, On March 21, 2023, we began a six-week, public discussion [1] on the request from SSL.com for inclusion of its root certificate(s):
- SSL.com TLS RSA Root CA 2022 <https://crt.sh/?q=8FAF7D2E2CB4709BB8E0B33666BF75A5DD45B5DE480F8EA8D4BFE6BEBC17F2ED> - SSL.com TLS ECC Root CA 2022 <https://crt.sh/?q=C32FFD9F46F936D16C3673990959434B9AD60AAFBB9E7CF33654F144CC1BA143> - SSL.com Client ECC Root CA 2022 <https://crt.sh/?q=AD7DD58D03AEDB22A30B5084394920CE12230C2D8017AD9B81AB04079BDD026B> - SSL.com Client RSA Root CA 2022 <https://crt.sh/?q=1D4CA4A2AB21D0093659804FC0EB2175A617279B56A2475245C9517AFEB59153> The public discussion period ended on May 2, 2023. Summary of Discussion Discussion Item #1: Concerns were raised about SSL.com’s lack of urgency in detecting, handling, and responding to weak public keys and their ability to comply with the BRs in areas without specific guidelines, especially when it comes to security and revocation timelines. SSL.com Response to Discussion Item #1: SSL.com believes their actions in [2], [3] and [4] demonstrate their ability to monitor, analyze, and make informed decisions in accordance with the BRs. It was pointed out that the actions in [3] demonstrate a commitment to addressing concerns, and the context in which the issue was reported influenced the decision to perform a more in-depth analysis. It was also mentioned that this incident is being used as a learning opportunity to test and improve processes, and the experience has informed their research and contributions to Ballot SC-59. Discussion Item #1 Continued: It was stressed that CAs must respond to certificate issues promptly per Section 4.9.1.1, regardless of how they discover the problem. An interpretation of the timeline in Incident Report 1800753 [5] was provided, and it was suggested that SSL.com should have known of a certificate’s vulnerability and revoked it within 24 hours. Discussion Item #2: Ben Wilson commented on the SSL.com CP/CPS v. 1.16. [6] SSL.com Response to Discussion Item #2: SSL.com is updating the CP/CPS to version 1.17 with expected publication on or before May 15, 2023. [7] ========================== We thank community members for their review and consideration during this period. Root Store Programs will make final inclusion decisions independently, on their own timelines, and based on each Root Store Member’s inclusion criteria. Further discussion may take place in the independently managed Root Store community forums (i.e., MDSP). [1] https://groups.google.com/a/ccadb.org/g/public/c/mTUkK-gkHPE/m/bBl1fCN5AAAJ [2] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/TlhjCJm610I/m/LmlR3tJCBAAJ [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1800753#c2 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1800753#c6 [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1800753 [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1799533#c6 [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1799533#c11 Thank you, - Chris, on behalf of the CCADB Steering Committee On Tue, May 2, 2023 at 4:17 PM Ben Wilson <[email protected]> wrote: > All, > I have reviewed SSL.com's updates to its CP/CPS based on my comments and > find them acceptable. > Ben > > On Tue, Apr 25, 2023 at 10:50 AM Leo Grove <[email protected]> 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/CA%2B1gtaaoGgHOrPNwp7R-Uj9%3DC_vDiiq9f9NhbuqBjOGQ8JJi3g%40mail.gmail.com > <https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaaoGgHOrPNwp7R-Uj9%3DC_vDiiq9f9NhbuqBjOGQ8JJi3g%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/CAAbw9mA0TML4EK%3DPVExhuqS-gPWfaGQM6OhXgvXgXPmGo6fDbw%40mail.gmail.com.
