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/CA%2B1gtabwPZjFrCNc92FRg3_9DsznGvOgPVE2AhL-3PwT%2BNXjrg%40mail.gmail.com.
