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
