Here's a reference to the issue with the German government ID cards I mentioned: https://bugzilla.redhat.com/show_bug.cgi?id=2228325#c48

That isn't really fixable, they use a custom generator with a named brainpool curve, which makes the entire thing a custom curve. I don't think that's something we should support, and fortunately, there is a workaround by entering the PIN on the smartphone that's used as the card reader in this context.

@James Bourne I'm not sure I get your arguments. Users in this context are distros who have to be aware by definitions. I also don't get point B) at all, could you please elaborate?

I agree about configuration complexity, and agree that support of explicit curves should be switched off by default, if this switch is implemented

@Dmitry Belyavsky No worries. If there is a level of pre-assumed knowledge from a packaging perspective, then it lowers risk. However,

A) Configuration complexity. There is already concerning given the plethora of CLI options. See https://openssl-communities.org/d/hT3LIM4H/complexity-of-compile-time-disableables-makes-it-hard-to-contribute-code-to-openssl.

One of my arguments at the first BAC meeting in 2025 is that obsolete/vulnerable/deprecated code and algorithms should be removed from the code base or at the very least placed in separate libraries. This means less CLI exclusion options. However, given the conservative nature of the project, code has to be retained for backward compatibility. But when does that end?

So with that in mind, specific ECs should be removed permanently from the code base and not merely excluded by an optional compile time option. From a vulnerability management perspective, the code is literally not present. When the code is not present there is no need for CLI options and you reduce complexity. It also mitigates inclusion of incorrect CLI compile time specifications which we at FireDaemon had been pulled up on, on a few occasions, by users of our OpenSSL binaries (e.g. forgetting ASM and zlib, including SSLv3).

Summary: Secure By Default. Avoid CLI and documentation overhead. Avoid code base complexity. Just delete the offending code and algorithms. Or worst case disabled by default. So no user intervention or pre-assumed knowledge is required.

B) By leaving the vulnerable code and algorithms in the code base and by introducing an enabled by default option (i.e. disable on demand), we still haven't solved the problem of removing vulnerable code and algorithms from the code base. Secure by design (SbD) principles and various SSDLC frameworks mandate evisceration or fixing of vulnerable code. There might be an edge case or compile time combinations that haven't been evaluated correctly or refactored that means that vulnerable code and algorithms (i.e. regressions) are still available (i.e. the unforeseen code path) in binary form.

What is OpenSSL's strategy in regard to that? It should be mitigation and incremental refactoring to minimise the attack surface via threat modelling (STRIDE, PASTA, LINDDUN or kill chains or attack trees). For example, you implement curves disabled by default in v4.0. The rationalisation is explicit based no longer "security reasons" but "because NIST says do not use this" or "mathematical proof" or some other form of validation. In v4.1 you refactor and place that code in a separate library. In v4.2 you now physically remove that code and deprecate/remove the compile time options.

Summary: Secure By Default. Similar reasons per A). This requires a strategy to to secure legacy code. Securing legacy code should be a temporary measure where insecure code is eventually removed.

C) Disabled by default should partially mitigate the need for developer/maintainer/contributor developer knowledge. This brings up another point regarding release notes and documentation. The release notes are summaries and don't dig into the underlying reasons why a decision was made to make the change. I bought this up at the second BAC meeting. Need to tie release notes to PRs. Be explicit about the consequences of these changes. Write release notes that are user friendly and really explain who is affected by the change.

Anyway ... I probably gone off on a bit of a tangent. But what would be the coolest option would be simplified security CLI options when building the library. For example:

• perl ..\Configure --enable-all-features-and-options

• perl ..\Configure --remove-obsolete-deprecated-features

• perl ..\Configure --hardened-for-distribution

Coupled with a handy to read table of features. So in summary:

1. The need to remove insecure ECs is valid

2. Implement via disabled by default

3. Plan to remove all insecure ECs in a future release.

So should I change my vote?!

@James Bourne I added a link to our implementation for clarity

@James Bourne I'm happy that we gotna consensus, thank you very much