crypto/x509: missing support for EC parameter encoding

LetsEncrypt's "Boulder" server, the backend for processing CSRs, apparently uses

go1.6.2 linux/amd64

and specifically

the upstream Golang x509 package ... to process CSRs.

If a CSR submitted to LetsEncrypt service references a PrivKey that has ec parameters explicitly encoded, e.g.,

openssl ecparam \
 -genkey \
 -param_enc explicit \
...

, perfectly valid under Openssl, the Boulder server process fails with a server error

Err: asn1: structure error: tags don't match (16 vs {class:0 tag:13 length:45 isCompound:true}) {optional:false explicit:false application:false defaultValue:<nil> tag:<nil> stringType:0 timeType:0 set:false omitEmpty:false} certificateRequest @2
Req: (*x509.CertificateRequest)(nil)

This is claimed as a result of GoLang's X509 pkg lacking support

The upstream x509 library does not support explicit parameter encoding 

Despite their befuddling insistence that

regardless of whether it is added there we likely won't support it in Boulder.

it'll be useful for GoLang's X509 pkg to implement feature parity with Openssl in supporting the explicit parameter encoding

More detail's provided in the original bug post there

Certbot “Exiting abnormally” if CSR uses PrivKey with ec parameters encoded (=param_enc explicit)

https://community.letsencrypt.org/t/certbot-exiting-abnormally-if-csr-uses-privkey-with-ec-parameters-encoded-param-enc-explicit/18814

I can provide additional info here as requested

[bradfitz]

To @agl for a decision.

[agl]

I don't believe that we want to support this. Arbitrary EC curves were an old, excessive generality and Go doesn't have generic EC code in any case. Sometimes the explicit parameters happen to match a well-known curve and we could recognise those, but then it's just a waste of bytes and the generating code should have used a named curve instead.