Disabling support of explicit curves in OpenSSL via compilation options

How does the German government deal with this? They use their own curve from memory and it needs to be specified via explicit parameters.

It's an option, not mandatory

@ppzgs1 they use brainpool curves, those are well-defined (have both OIDs and TLS codepoints)

I seem to remember that it was left in specifically for that reason (as was noted by @mspncp), and @romen mentioned it being used for researchers?. That doesnt seem to exclude it from becoming a configurable option. The decision then is it on by default or not.

I was more interested in how people in Germany use RHEL for government work.

If the OS doesn't support explicit curves, that hurts some people. How do they cope?

@Paul Dale We have disabled it 4 years ago and I recall only one request during this time. in Fedora.

@Paul Dale I think the German government uses Brainpool curves (I got requests to enable those in protocols that have no specification for them yet), not arbitrary parameters ones.

@Shane Lontis It would still be usable for research purposes

What specific APIs are being proposed for removal as part of this?

@Matt Caswell compile-time definition doesn't need any API modification, we just get errors in case when we have an explicit curve if its support is disabled

@Dmitry Belyavsky Then I'm confused as to what exactly you are proposing. At the moment I can call (for example) `EC_GROUP_new_curve_GFp` and create an explicit curve. Does this function exist but just fail if explicit curve support is disabled?

I propose dropping support of explicit curves in X.509/PKCS#8/etc

https://github.com/beldmit/openssl/commit/6a2b78bca595435fcbf72d7b2c8bec004d555016

@Matt Caswell ^^

@Dmitry Belyavsky so, if I understand correctly, the proposed patch prevents EC Keys and Parameters using an explicit curve from being decoded, and prevents providers from creating keys based on such curves - but does not block applications from using the legacy low level functions to create them directly via `EC_GROUP_new_curve_GFp` and `EC_GROUP_new_curve_GF2m`

@Matt Caswell Correct

@beldmit wait... wasn't our code allowing for use of explicit parameters if and only if the parameters specified one of the well-known curves?

@Alicja Kario 

The check

EC_GROUP_check_named_curve(group, 0, NULL) == NID_undef

stands explicitly for this

As said elsewhere I think we get the real benefit (for users) if we disable by default.

If not, then the benefit of the option allows distributions to have one less patch to maintain so that is also useful (even if disabled).