For interoperability it makes the most sense to include the curve parameters in the CSR with an ECC (elliptic curve) certificate. This way, a capable agent can validate a signature without foreknowledge of the key’s curve.
Let’s Encrypt seems to balk, though, at such CSRs?
Error parsing certificate request. Extensions in the CSR marked critical can cause this error: https://github.com/letsencrypt/boulder/issues/565 (The request message was malformed)” (400, “Bad Request”, urn:acme:error:malformed)
None of the extensions requested in the CSR is marked critical.
I'm not sure if this is a concern here. Publicly-trusted CAs are not allowed to accept just any public key type; right now, they're limited to RSA and some NIST curves. In other words, the CA software knows exactly which curves it's willing to accept anyway, so this flexibility is not particularly useful (and - worse - such a flexible implementation might be more error-prone). I'm pretty sure you'll at least need to add the named curve OID for whatever curve you're trying to use since that's what the CA server will use to identify the key type; not sure if the rest of the curve parameters will cause issues if you keep them in the CSR as well.
The CA software is relatively easy to update, and it’s trivial for CAs to compare given curve parameters against their white-list to verify a curve’s identity.
My thinking isn’t that arbitrary curves are desirable; the point is backward compatibility. If, for example, the powers-that-be decide that any of the brainpool curves that OpenSSL 1.0.2 knows about are acceptable, then any OpenSSL 1.0.1 clients out there will be unable to work with certs/CSRs that use this curve but identify it by name only.
I suppose the CA could just decide to issue the cert using the explicit parameters, too.
I don't think there's a big demand for this given the speed at which new curves are added to the Baseline Requirements. If and when this happens, I suppose it could be (carefully) implemented for those new curves. Meanwhile, I think it makes more sense to be conservative and rely on the OID (which is actually something Go's x509 library does in Let's Encrypt's case, rather than code in the CA software itself).
Not sure what client support for that looks like. Go certainly relies on the OID alone (relevant code at line 855); I'm not much of a C developer, but I think NSS does too.
Given the state of library support, yes, you’re probably right; the flexibility of explicit curve parameters seems to be something that the format foresees as potentially useful but that no one has immediate plans to use.