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.
