Bugzilla

Assignee

Comment 1

•

1 year ago

We acknowledge receiving notification for this submitted bug (after proper tags were applied) and we plan to update it with our opinion no later than November 30.

Assignee

Comment 2

•

1 year ago

Apologies for the long post.

We would like to thank the security researcher Hanno Böck for bringing a potentially vulnerable certificate to our attention, even through the m.d.s.p. list which we periodically monitor. In future cases, we kindly ask that such issues are at least reported to the corresponding CA through their standard revocation channels, disclosed in their CP/CPS. In particular, Certificate Problem Report mechanisms and other revocation request methods specified in section 4.9.3 of CP/CPS documents are specifically designed to alert CAs and allow proper handling of revocation requests for the security of internet users and the ecosystem.

Clause 4.9.1.1 par.1 item (4) of the BRs lacks guidance on what is considered “a demonstrated or proven method that can easily compute the Subscriber’s Private Key”. In our opinion, when a not clear-cut case (more details on this below) is reported to a publicly-trusted CA, the best course of action is to analyze the issue and consider all risks involved (e.g. a possible certificate revocation-based DoS attack), and not just revoke immediately.

This was the approach SSL.com followed. The moment we were informed about the post on m.d.s.p., our compliance team got involved to analyze the issue and determine the proper course of action. As posted in m.d.s.p., our response did not just address this particular certificate, but we also:

expedited the already-scheduled update of our zlint to v3.4.0 to prevent similar issuances;
tested our issuing systems to confirm the effectiveness of these updated pre-issuance linting controls; and
retroactively tested against our entire corpus of certificates , confirming no other certificates were affected by this issue.

With regards to the handling of the certificate in question, the following took place:

We performed an analysis of BRs regarding weak keys language, in consultation with CA engineers.
Several technical issues were discussed during this analysis, including the Fermat’s factorization method as a Close Primes vulnerability per https://nvd.nist.gov/vuln/detail/CVE-2022-26320, and the community-accepted threshold regarding the rounds needed to factor the key.
These confirmed that the current BRs do a poor job in guiding CAs for which exact cases (algorithms, configurations, parameters, etc) should be considered weak keys.

In an abundance of caution, we decided to take action based on the preliminary findings of these discussions, and proceed with notification of the subscriber (despite the fact that he was the security researcher who reported the issue in m.d.s.p.) and revocation of the certificate.

This action was misunderstood as acknowledgment that the certificate contains vulnerable key material per BRs 4.9.1.1 par.1 item (4), which specifies:

“The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber's Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys)”.

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”.

Considering all the above, we believe that our actions were reasonable. Our monitoring of public discussions (Bugzilla, m.d.s.p., CA/B Forum mailing lists) allowed us to discover an issue which was not reported to us through methods provided per our CP/CPS (via Section 4.9.3). We took immediate actions to ensure no other occurrences are possible and to confirm there are no other affected certificates. As part of our due diligence, we engaged the proper teams (compliance, CA engineers) to analyze the issue from all aspects and took informed and balanced decisions. For the above, we have been fully transparent with the community.

In our opinion, revocation of this particular certificate 25 hours and 50 minutes after our post on m.d.s.p. to inform the community does not constitute a violation of our CP/CPS or the BRs. If the root store owners consider that the above does constitute a violation of the BRs, and that we should have treated this revocation within a 24 hour revocation timeline, in particular per 4.9.1.1 par.1 item (4), we will file an incident report and handle this bug according to our Incident Management Policy. Otherwise, we consider this bug should be closed as INVALID.

Regardless of this bug, we would like to again direct attention to our CA/B Forum ballot proposal, which provides clearer guidance to CAs for handling Debian weak keys and similar vulnerabilities, including (at the suggestion of Martijn Katerbarg from SECTIGO) language specifically addressing the Fermat attack issue. We have also incorporated other suggestions from the community in the course of developing this proposal and consider the ballot language as complete on our part (see attachment). We sincerely believe that the greatest value of this discussion lies in focusing our energy on this proposed ballot to forestall future similar issues. We have secured one endorsement for this proposed ballot and would welcome a second endorsement so that it may be submitted to the CA/B Forum SCWG and proceed to a vote.

Assignee

Comment 3

•

1 year ago

Attached file DRAFT SCXX Debian weak key ballot 20221130.docx — Details

Reporter

Comment 4

•

1 year ago

While I agree that m.d.s.p. should not be considered the certificate problem report contact, I don't think that matters for BR 4.9.1.1 par.1 (4): you still were made aware that the certificate was vulnerable to Fermat factorization (which implies the private key could be derived from the public key in an easy and known manner). That awareness must have appeared before your first reply email.

Because m.d.s.p. was a public forum, and both the attack and the certificate were mentioned directly, I would consider that certificate's keys to be compromised (which is also the revocation reason), not just 'created using a flawed method', because in that case the Debian keys would also fall under that clause.

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

Fermat factorization is a known and proven vulnerability (https://nvd.nist.gov/vuln/detail/CVE-2022-26320 attests to that). In the case of this certificate, it took only one round of Fermat factorization before a and b were found. If this is not covered under "a demonstrated or proven method that can easily compute the Subscriber's Private Key", then I don't know what RSA vulnerability is; as the Debian keys require the user to install a very specific version of Debian to generate the private keys, whereas this public key's private parts can be computed on any OS with any language that supports operations on large integers.

Reporter

Comment 5

•

1 year ago

I don't think that matters for BR 4.9.1.1 par.1 (4)

Allow me to clarify. In hindsight, that doesn't quite convey what I was trying to tell.

I meant that the 24h revocation period applies regardless of how a CA is made aware of an issue under BR 4.9.1.1 par.1.
The Certificate Problem Report contact is somewhat special because the period starts when they are contacted by the user. However, other methods of 'being made aware' still count: in this case, you were aware of the issue at least 24h50m before the revocation (as shown by the date of the reply mail and the revocation time stamp), and probably were aware of the issue significantly earlier, considering the actions that were listed in the mail.

Assignee

Comment 6

•

1 year ago

Thank you for your comments. They are greatly appreciated and shed more light regarding your point of view.

In our opinion, the context has to be taken into account for a more accurate interpretation.

In this particular context, being "made aware of" entails more than capturing a post in m.d.s.p. claiming issuance of certificate based on weak key. The issue must be confirmed so that a CA establishes clear, actionable knowledge in the case at hand before starting the revocation clock and taking action.[1]

Should this be a Certificate Problem Report (CPR) as specified in BRs, further specific requirements would apply, in particular section “4.9.5 Time within which CA must process the revocation request”, and all actions (investigation, conclusions, notifications, revocations) would have to be completed within 24 hours from the very moment the CA received the request (i.e. not from the moment it was “made aware of”).

Specific wording was added to 4.9.5 to address exactly this issue and specify in detail the timeline expectations (emphasis ours):

Within 24 hours after receiving a Certificate Problem Report, the CA SHALL investigate the facts and circumstances related to a Certificate Problem Report and provide a preliminary report on its findings to both the Subscriber and the entity who filed the Certificate Problem Report.
[...]
The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation MUST NOT exceed the time frame set forth in Section 4.9.1.1.

Furthermore, CAs are required to have well-established CPR procedures to be able to maintain a 24x7 ability to investigate, decide and respond.

In the context of the issue at hand, CPR requirements did not apply. Different teams had to be engaged in an ad hoc manner to analyze facts versus requirements and confirm the claim before taking action, even though it was clearly a test case by a security researcher [2].

We believe that further guidance in the BRs regarding weak keys would remove the need for thorough, multi-disciplinary analysis when handling similar cases, thus expediting and harmonizing the process regardless of whether the case is filed as a CPR or otherwise discovered by the CA. In our opinion, this is the systemic issue which needs to be addressed, and for which we have drafted and discussed a ballot to strengthen this guidance. We are pleased to inform the community that the necessary number of endorsers has now been found, ballot number SC 59 reserved [3], and this ballot shall be submitted for consideration by the CA/B Forum's Server Certificate Working Group.

[1] This does NOT mean that a CA may arbitrarily extend the period of investigation and use it as an excuse to delay revocation. A prudent CA is expected to apply reasonable timeframes and proceed with required actions without undue delay. SSL.com completed its actions, including analysis, decision, notification, revocation, retrospection and mitigation swiftly, and definitely within reasonable timeframes.

[2] It would of course have been quicker, more convenient and required fewer resources for SSL.com to have gone ahead and revoked the certificate in question the moment we identified that the Subscriber was also the security researcher who reported the issue in m.d.s.p. However, this would have been an “in-vitro” response of very low value. Per industry’s good practices, SSL.com treats requests from security researchers as if they were real world cases, not “experiments”. This approach allows us to evaluate the effectiveness of our policies and practices, and also the completeness of the standards/guidelines as written.

[3] See: https://wiki.cabforum.org/scwg/scwg_ballots

Updated

•

1 year ago

Whiteboard: [ca-compliance] [leaf-revocation-delay]

Comment 7

•

1 year ago

I think the underlying facts and circumstances for SSL.com that gave rise to this bug have been adequately addressed, and that we should not hold this bug open for something that may or may not occur with a ballot in the CA/Browser Forum. I'll close this on or about 1-March-2023 unless there is another reason to keep this bug open.

Flags: needinfo?(bwilson)

Reporter

Comment 8

•

1 year ago

Ben, I don't think that referring to a potential future ballot of which the text nor direction is not available is enough to resolve the question that is being asked here:

Does a novel - or otherwise not previouly considered - but proven method to easily compute the Subscriber's Private Key qualify as "a demonstrated or proven method that can easily compute the Subscriber's Private Key based on the Public Key in the Certificate", even if that method is not explicitly mentioned by the BR?

I think the answer to that question is "yes", because I think novel public key derivation attacks need to be handled by CAs immediately and without going through a lengthy BR ballot process. In contrast, Chris Kemmerer seems to believe that the answer is "no":

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".

I don't think that argument holds because (arguably) all weak keys are generated using a flawed method, but this doesn't mean you can just pick and choose which revocation timeline to use.

As an example, if there was some way to factor a subset of RSA public keys by repeatedly shredding a printed version of the public key, then I don't think the response of a CA should be "we don't know how many times we should shred prints, so let's revoke it when we have time in the next 5 days and let someone at the CA/B Forum know to update guidelines because this is a new situation we're not ready to deal with ourselves", but rather "let's validate the claim, and revoke ASAP (within 24h) if it was really that easy".

I would have understood the point of "we don't know how many rounds would imply "easily derived from public keys", so let's go with 'insecure key generation'-based revocation timelines" if the key material needed many iterations before the attack yields results, but this certificate instead only needed 1 round of Fermat factorization, which was trivial to check.

Comment 9

•

1 year ago

There appears to be benefit from more discussion on this topic, so I'll leave this open, but should we take this discussion to a broader audience?

Aaron Gable

Comment 10

•

1 year ago

(Speaking solely on behalf of myself, not my employer.)

I concur that Fermat Factorization (especially with just a single round of computation) counts as a "proven method that can easily compute the Subscriber's Private Key". Fermat Factorization is proven. Doing only one round of the algorithm is quite fast and easy.

There is of course room for interpretation here. How many rounds can be required and still have it count as "easy"? What about when a truly novel (e.g. quantum) factorization method arises? I think these are questions that we will have to address eventually, but I don't think they have to be addressed in this particular case.

Updated

•

1 year ago

Flags: needinfo?(bwilson)

[1] https://groups.google.com/a/ccadb.org/g/public/c/mTUkK-gkHPE/m/WBaf7QUnAwAJ

Assignee

Comment 11

•

1 year ago

In response to https://bugzilla.mozilla.org/show_bug.cgi?id=1800753#c10, in this update we will try to address only the technical aspects of the issue. For a more complete and multifaceted analysis, the interested reader is referred to the public discussion of SSL.com's CA Inclusion Request, where this bug was used to raise concerns [1].

With regards to these technical aspects:

We agree that at face value, the “Fermat Factorization” method is a “demonstrated or proven method that can easily compute the Subscriber's Private Key based on the Public Key in the Certificate” as described in the Baseline Requirements section 4.9.1.1 sub-item 4.

The problem with that requirement (as discussed at length by the CA/B Forum) is that there is no minimum set of explicitly enumerated faulty methods and, most importantly, their parameters. Even the specific call-out for the long-known Debian weak key method has sparked an ongoing discussion regarding the proper parameters to match the community’s expectations. In particular, Ballot SC-59, into which SSL.com has put much effort, is still to reach consensus, exactly because of these different expectations.

In addition, CAs are aware that there is active research for methods “that can easily compute the Subscriber's Private Key based on the Public Key in the Certificate”. Some of those methods might be more successful or effective than others. CAs need to be aware of these methods, parameters should be discussed, and the minimum expectations should be placed in normative documents that will hold all publicly-trusted CAs to the same standards. In this particular case, as explained in https://bugzilla.mozilla.org/show_bug.cgi?id=1800753#c2, SSL.com was still trying to identify the community-accepted threshold regarding the parameters for the Fermat Factorization method, including the rounds needed to factor the key.

SSL.com will continue to monitor this bug for questions or suggestions.

Reporter

Comment 12

•

1 year ago

We agree that at face value, the “Fermat Factorization” method is a “demonstrated or proven method that can easily compute the Subscriber's Private Key based on the Public Key in the Certificate” as described in the Baseline Requirements section 4.9.1.1 sub-item 4.

Then what basis do you use to claim that you don't need to comply with these requirements? I agree that all RSA public keys can be factored through the use of Fermat Factorization, but that for some public keys, it'll take essentially forever and thus shouldn't be considered "vulnerable". Yet for certificates explicitly being called out as Vulnerable, isn't it normal to validate the claim with at least the bare minimum amount of rounds, which seems to be 1?

The problem with that requirement (as discussed at length by the CA/B Forum) is that there is no minimum set of explicitly enumerated faulty methods and, most importantly, their parameters.

I can agree that this lack of parameters is problematic, but I hope you can agree that for single-parameter attacks (like "number of rounds" for Fermat's), the claim "certificate is vulnerable to <attack X>" should be validated by the CA with at least the most trivial parameter of that attack, which for Fermat's should be 1 round, right?

In this particular case, as explained in https://bugzilla.mozilla.org/show_bug.cgi?id=1800753#c2, SSL.com was still trying to identify the community-accepted threshold regarding the parameters for the Fermat Factorization method, including the rounds needed to factor the key.

I think that SSL.com should have considered that the community would consider zero rounds as the threshold, especially considering that the threshold number of rounds the CA needs to run is 100 in the proposed ballot. If the CA must actively scan for close primes with 100 rounds of FFM when ballot SC-59 passes, why would a public key which is factored in one round of FFM right now not count as vulnerable? Even more so if the public already knows the key can be factored in reasonable time using FFM?

Assignee

Comment 13

•

1 year ago

A public key that can be factored by FFM within one round is considered vulnerable; we can all agree to this. However, in order to be able to examine a specific public key and confirm such a report, a CA needs to have already implemented and incorporated the relevant controls/mechanisms into its processes. If these are in place, then unarguably the time to run FFM and confirm a report claiming that a key is vulnerable to factorization by FFM, is negligible.

Such an implementation must take place beforehand and not in the course of a specific request, as it entails time-consuming tasks such as research to understand the problem and its parameters, design decisions, in-house code development for executing FFM or evaluation of third-party tools (e.g. linters with integrated FFM), documentation, testing and integration into production systems and processes before use. SSL.com had identified this issue and was working on updating its controls to detect and block keys that could be factored by FFM. That process was still in progress when we discovered the report in the m.d.s.p. mailing list.

In our opinion, with the current BRs, CAs are left with a catch-all statement and an incomplete reference to the Debian weak keys method (mentioned as an example without any parameters), without references to other methods which would need to be addressed by respective controls by CAs. This is exactly why we consider it necessary to update the BRs and call out the specific weak key methods and parameters which need to be handled, thus providing guidance for all CAs and making this requirement realizable.

Without this update, adoption of mechanisms to address weak keys will continue to take place incrementally, on a per CA and per method basis, resulting in a slow and non-harmonized implementation across CAs. To that end, we would be grateful for any contributions to the suggested SC-59 ballot language to reach the required consensus.

Reporter

Comment 14

•

1 year ago

(In reply to Thomas Zermeno from comment #13)

[...] However, in order to be able to examine a specific public key and confirm such a report, a CA needs to have already implemented and incorporated the relevant controls/mechanisms into its processes.

This feels disingenuous. A CA could just as well make someone validate a claim about a weak public key without first formalizing the CA's processes regarding handling that specific weakness.

Note that this issue concerns (perceived) non-compliance with BR section 4.9.1.1 (revoking existing certificates), while section 6.1.1.3 (not signing new certificates) has not been mentioned before. Although they are related sections, they are not the same, and the current issue is about failing to comply with 4.9.1.1 (which also happens to be a failure to comply with section 6.1.1.3).

If these are in place, then unarguably the time to run FFM and confirm a report claiming that a key is vulnerable to factorization by FFM, is negligible.

Sure, I can see that being the case. But 4.9.1.1 does not put any limit on the ease of an attack on the key material, and I think that's

Such an implementation must take place beforehand and not in the course of a specific request, as it entails time-consuming tasks such as research to understand the problem and its parameters, design decisions, in-house code development for executing FFM or evaluation of third-party tools (e.g. linters with integrated FFM), documentation, testing and integration into production systems and processes before use.

I fail to see how this relates to an existing certificate's problem handling under 4.9.1.1. Once I decided to try to validate the claim made in the e-mail, it took me 30 minutes with Wikipedia, StackOverflow, and some Python to validate the claim that the key was weak / FFM would factor the key. If "weak public key"-claims for a specific class of attacks appear frequently, then I'd agree that implementing a process would be useful (well, required under 6.1.1.3), but the frequency of FFM-vulnerable public keys is unlikely to have been a driving factor, especially considering that this was only the second Bugzilla issue related to close primes in a year (Bug 1766525 is from last year, and Bug 1744795 has been closed for well over a year) and that the processes were only now being implemented. In addition,

SSL.com had identified this issue and was working on updating its controls to detect and block keys that could be factored by FFM. That process was still in progress when we discovered the report in the m.d.s.p. mailing list.

In our opinion, with the current BRs, CAs are left with a catch-all statement and an incomplete reference to the Debian weak keys method (mentioned as an example without any parameters),

And rightfully so. If a novel (or otherwise not previously considered) public key weakness appears, the CA must be required to revoke vulnerable certificates within the 24-hour window; it should not be up to the willingness of the CA and/or the swiftness of the CA/B Forum to incorporate this attack vector into the BR's "revoke within 24 hours if the key is weak to attack X, Y, or Z" section. A catch-all is the only solution available when the list of attacks on public keys is likely incomplete.

To stay with the Debian Weak Keys example, the vulnerable version of OpenSSL could generate ECC keys, which could mean the private keys are computable [0]. Limiting the consideration of vulnerability to a pre-specified list is essentially equivalent to fooling yourself that no new vulnerabilities will be discovered such that already issued certificates need to be revoked in the next 24 hours. Sure, that may be true for certificates issued today, but there will likely be a day in which a new vulnerability is discovered and applied, and it's unlikely to happen at an opportune time where the BR can be updated immediately.

Without this update, adoption of mechanisms to address weak keys will continue to take place incrementally, on a per CA and per method basis, resulting in a slow and non-harmonized implementation across CAs. To that end, we would be grateful for any contributions to the suggested SC-59 ballot language to reach the required consensus.

I'm all for updating the BR with more examples of weak keys that should not be signed. I just don't think that including a list in the BR and assuming that list to be exhaustive for revocation is OK, and that seems to be what you've been arguing - you seem to argue that the BR contains (or should contain) an exhaustive list of weaknesses in keys that the CA needs to take into account when considering 4.9.1.1(4). I understand adding such a list for 6.1.1.3 as a baseline checklist for CAs before they issue certificates, but 4.9.1.1 needs to be a catch-all to make sure vulnerabilities are not denied by the CA, which would leave the end user vulnerable.

[0] https://github.com/CVE-2008-0166/key_generator#pregenerated-keys-and-blocklists, both secp256r1 and secp384r1 are available in vulnerable versions

Flags: needinfo?(support)

Comment 15

•

1 year ago

We haven't been able to make progress through debate. It seems that Matthias believes that subsection 4 of section 4.9.1.1. of the Baseline Requirements is clear enough, and that SSL.com wants a revision that makes subsection 4 of section 4.9.1.1. of the Baseline Requirements more clear. Am I correct?

Reporter

Comment 16

•

1 year ago

Yes, I think that 4.9.1.1 is clear enough. Although I agree with SSL.com that adding additional known attack vectors to the item in "(such as a Debian weak key, [...])" is not a bad idea per se, I do think any such modification must not decrease the scope of 4.9.1.1 item 4.

I can go on about what I think about SSL.com's handling of this issue, but that's probably quite clear from my earlier comments.