Hi Clint, I think my latest proposal [1] is essentially what you are proposing in option #2, the only difference being that we would add repositories containing weak keys to https://cabforum.org/resources/tools/ (and we can do that without a ballot). If you are instead proposing that we require CAs to check for a specified weak keys contained in one or more repositories, then that is similar to Aaron's proposal except that I understand you want to require CAs to also check for weak keys even if they sign non-standard key sizes that are not included in the repository of weak keys.
The more I think about the two approaches, the more I prefer my current proposal [1] that does not require CAs to check for specific keys found in one or more repositories. The reason is that I believe CAs already have Debian weak key checks in place and would likely prefer not to have to change their systems to use different logic/data to meet the same requirement as before. Thanks, Wayne [1] https://github.com/wthayer/servercert/pull/1/files On Tue, Apr 9, 2024 at 2:26 PM Clint Wilson <cli...@apple.com> wrote: > Hi Wayne, > > I think this does seem like it could be a tractable solution, however I’d > like to understand why one of the proposals I’ve brought up a couple times > on the calls isn’t also a suitable option. From what I can gather, they’re > nearly identical in practical impact, but one provides a much more defined > boundary for relying parties. > > Option 1: > The CA/BF creates or mirrors a repository of pre-computed Debian Weak keys > for the following key sizes (representing those most commonly issued > against): RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521. The TBRs > stipulate that CAs must not issue certificates containing keys in this > repository. > > Option 2: > The CA/BF creates or mirrors a repository of pre-computed Debian Weak keys > for the following key sizes (representing those most commonly issued > against): RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521. The TBRs > stipulate that CAs must not issue certificates containing weak keys, with a > pointer to the repository of the most common key sizes of Debian Weak keys > among other similar/relevant pointers for other vulnerabilities. > > The reason these 2 proposals are so nearly identical in practice is that > there are only a very tiny number of certificates issued against key sizes > that are not RSA 2048, 3072, 4096, or 8192; or ECC 256, 384, or 521. By > my count, somewhere around 80 certificates out of roughly 750 million > (though I really only took a quick glance, so perhaps this is off to an > extent… but probably not by huge quantities). > > Under Option 2, if a CA wants to allow for Certificate requests containing > a key size other than these 7, they’re fully free to do so; they must > merely ensure the key is not a Debian Weak key. For every other CA, they > can limit the accepted key sizes to those in the repository and the result > is functionally the same as Option 1, but without the possibility of > “certificates can be issued that are weak and CAs are under no obligation > to prevent that if it’s not one of 7 key sizes”. > > Concretely, is there a reason Option 2 is intractable for CAs? If so, I > would greatly appreciate help understanding how that approach meaningfully > differs from Option 1. > > Thanks, > -Clint > > On Apr 9, 2024, at 11:43 AM, Rob Stradling via Servercert-wg < > servercert-wg@cabforum.org> wrote: > > > * Aaron Gable commented in the PR with a suggestion that we require CAs > to reject any key found in Hanno Bock's repository at > https://github.com/badkeys/debianopenssl. This includes RSA > 1024/2048/3072/4096 and EC P256/P384 keys. > > Some of the EC key files in Hanno's repository have ASN.1 encoding issues > (see > https://www.mail-archive.com/dev-security-policy@mozilla.org/msg00911.html); > whereas the equivalent files in > https://github.com/CVE-2008-0166/private_keys are correctly encoded. > > > * Roman Fischer suggested that we limit the requirement to check Debian > weak keys only with sizes up to RSA 4096 under the logic that no one would > “accidentally” create an 8192 bit RSA key on a system vulnerable to Debian > Weak keys > > FWIW, https://github.com/CVE-2008-0166/private_keys already has all of > the possible 8192-bit RSA Debian weak keys. > > ------------------------------ > *From:* Servercert-wg <servercert-wg-boun...@cabforum.org> on behalf of > Wayne Thayer via Servercert-wg <servercert-wg@cabforum.org> > *Sent:* 05 April 2024 23:47 > *To:* CA/B Forum Server Certificate WG Public Discussion List < > servercert-wg@cabforum.org> > *Subject:* Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and know > the content is safe. > > Two new alternatives have been proposed in addition to the one I proposed > below: > > * Aaron Gable commented in the PR with a suggestion that we require CAs to > reject any key found in Hanno Bock's repository at > https://github.com/badkeys/debianopenssl. This includes RSA > 1024/2048/3072/4096 and EC P256/P384 keys. We might prefer to reference a > clone in the CAB Forum GitHub org (or some other source of the actual > generated weak keys) but that's a detail we can work out if others like > this approach. > * Roman Fischer suggested that we limit the requirement to check Debian > weak keys only with sizes up to RSA 4096 under the logic that no one would > “accidentally” create an 8192 bit RSA key on a system vulnerable to Debian > Weak keys > > Each of these methods has the benefit of adding clarity to the Debian > requirement rather than just maintaining the existing language, but they > also [arguably] allow CAs to issue certs containing abnormally sized Debian > weak keys. > > I would like to hear from other members (especially Apple) if you prefer > or object to either of these alternatives? > > Thanks, > > Wayne > > On Thu, Mar 28, 2024 at 4:13 PM Wayne Thayer via Servercert-wg < > servercert-wg@cabforum.org> wrote: > > There was further discussion of this ballot proposal on today's > teleconference. It was suggested that rather than omitting any reference to > Debian weak keys, the ballot should retain the current language. > Unfortunately, the ballot restructures the language in such a way that this > is challenging. My new proposal is that TLS BR Section 6.1.1.3(5) be > updated to read as follows ( > https://github.com/wthayer/servercert/pull/1/files): > ===== > 5. The Public Key corresponds to an industry-demonstrated weak Private > Key. For requests submitted on or after November 15, 2024, at least the > following precautions SHALL be implemented: > 1. The CA SHALL reject Debian weak keys ( > https://wiki.debian.org/SSLkeys). > 2. In the case of ROCA vulnerability, the CA SHALL reject keys > identified by the tools available at https://github.com/crocs-muni/roca or > equivalent. > 3. In the case of Close Primes vulnerability ( > https://fermatattack.secvuln.info/), the CA SHALL reject weak keys which > can be factored within 100 rounds using Fermat’s factorization method. > > Suggested tools for checking for weak keys can be found here: > https://cabforum.org/resources/tools/ > ===== > I would greatly appreciate feedback from any member that finds this > language unacceptable, or that has suggestions to improve it. > > Thanks, > > Wayne > > > On Fri, Mar 15, 2024 at 11:19 AM Wayne Thayer via Servercert-wg < > servercert-wg@cabforum.org> wrote: > > On yesterday's SCWG teleconference, Mads suggested that a way forward > would be to leave the existing requirements in place for Debian weak keys. > I've interpreted that to mean that we would just remove references to > Debian, resulting in this: > https://github.com/wthayer/servercert/pull/1/files > > I'm not satisfied by this approach because it doesn't achieve the clarity > intended to result from the original weak keys ballot and will seemingly > result in CAs continuing to have varying interpretations of the specific > requirements for rejecting Debian weak keys, but perhaps this is the best > we can all agree to. > > What do others think? Should we proceed with this approach? > > Thanks, > > Wayne > > On Sat, Mar 9, 2024 at 9:15 AM Dimitris Zacharopoulos (HARICA) via > Servercert-wg <servercert-wg@cabforum.org> wrote: > > FWIW, I think in the recent years, it was mostly security researchers that > attempted to request certificates with Debian weak keys to test if a CA was > properly blocking them. > > If an Applicant uses an outdated OS that generates weak keys, imagine the > actual web server or other software that runs on that server, putting > Relying Parties at risk. CAs don't have control over that but they could > have control over a common set of weak keys using common > parameters/algorithms which could be enforced by all CAs. > > Dimitris. > > On 9/3/2024 12:05 π.μ., Wayne Thayer via Servercert-wg wrote: > > Hi Clint, > > Thank you for your response. Unfortunately, it leads me to the conclusion > that there is not a path forward and we're stuck with the status quo. > Having said that, I'll reply to a few of your points below and encourage > others to do the same if there is a desire to move forward with an update > to our weak keys requirements. > > On Thu, Mar 7, 2024 at 12:59 AM Clint Wilson <cli...@apple.com> wrote: > > Hi Wayne, > > Thank you for carrying this work item forward. I have a few concerns > regarding the proposed removal of Debian weak key checking, outlined below. > > I don’t believe there has been sufficient explanation or data presented to > justify the removal of the requirement to check for Debian weak keys. It > seems to me there are feasible methods for CAs to continue performing this > check. Similar to what Martijn has pointed out, the reasoning provided is > lacking (hasty generalization, fallacy of composition, etc.). > > > The argument that I find compelling is that any system capable of > generating a Debian weak key in 2024 is also riddled with a decade of > vulnerabilities, so preventing the use of said weak key in a certificate is > security theater. In what scenario do you envision the rejection of a > Debian weak key having a meaningful impact on the security of a service > that relies on it? It's just not obvious to me that these checks continue > to provide any practical value at this point in time. > > > I don’t believe a compromise where Debian weak keys only need be checked > for specific key sizes addresses the core issue, unless tied together with > a restriction from accepting key sizes which are not included in such a > list (which I do see as reasonable and something I’m under the impression > is already being done by some CAs). > > > My understanding is that the objections some CAs had to the original > ballot was the requirement to maintain a sizable database of Debian weak > keys for every key size they support. Limiting the requirement to the most > popular key sizes would resolve that issue and be more inline with my > understanding of some current practices. This approach would also greatly > reduce the threat of the accidental use of a Debian weak key. > > > The removal of this check seems to shift a burden currently placed on CAs > to a risk (long assumed resolved) for Relying Parties and Subscribers. From > my reading of the ballot, the requirement that a CA revoke Certificates > with Debian weak keys remains in effect, serving only to remove the > pre-issuance “blocking” requirement, but retaining an expectation that > certificates are checked post-issuance based on the CA’s awareness of this > method of compromising a Private Key; this generally seems a significantly > worse experience for Subscribers. Have I missed something regarding the > intent of the changes in this regard? > > > This is a great point. It makes no sense to allow a CA to issue a cert > that is then immediately subject to a revocation requirement. I am open to > either exempting Debian weak keys from BR 4.9.1.1(4) or for CAs to be > required to revoke a certificate containing a Debian weak key only if they > are "made aware" using the mechanism specified in 4.9.3. > > Thanks, > > Wayne > > > There have been incidents involving certificates issued to Debian weak > keys in recent years; some CAs have indicated that they don’t receive > Debian weak keys in requests, but evidence exists to the contrary for the > ecosystem as a whole. > > Thank you! > -Clint > > > _______________________________________________ > Servercert-wg mailing > listServercert-wg@cabforum.orghttps://lists.cabforum.org/mailman/listinfo/servercert-wg > > > _______________________________________________ > Servercert-wg mailing list > Servercert-wg@cabforum.org > https://lists.cabforum.org/mailman/listinfo/servercert-wg > > _______________________________________________ > Servercert-wg mailing list > Servercert-wg@cabforum.org > https://lists.cabforum.org/mailman/listinfo/servercert-wg > > _______________________________________________ > Servercert-wg mailing list > Servercert-wg@cabforum.org > https://lists.cabforum.org/mailman/listinfo/servercert-wg > > _______________________________________________ > Servercert-wg mailing list > Servercert-wg@cabforum.org > https://lists.cabforum.org/mailman/listinfo/servercert-wg > > >
_______________________________________________ Servercert-wg mailing list Servercert-wg@cabforum.org https://lists.cabforum.org/mailman/listinfo/servercert-wg
