Ideally we would just no longer decode the explicit curve parameters block at all.

However this may be problematic

• Botan until 2.2.0 (2017) used explicit curve encodings by default
• BoringSSL still maintains support for explicit curves, with a comment that OpenSSL sometimes generates keys using it
• Explicit curves have been prohibited in certs since forever, but certs also live a long time.

It's pretty likely that some non-zero number of live keys/certs exist which would no longer be parseable if support for explicit curves was completely removed.

Alternate plan

• All support for encoding with explicit curves is still removed.
• Continue to decode the parameters block but only accept it if it matches an existing group; you cannot create a new group implicitly by reading it. This also lets us skip all the expensive validation, since we only accept curves that are either builtin or that an application explicitly opted into. BoringSSL basically does this.
• Require the generator to be uncompressed; this avoids having to do a modular square root prior to checking the parameters. Botan has never encoded explicit curve params using compressed points. It looks like OpenSSL might use compressed points in some circumstances, but the code is such a tangle it's hard to say. BoringSSL has rejected compressed points for the curve generator since 2016, so this seems safe enough to me.