From the current flow:

I think of injecting custom functions something like:

type OIDToCurveFunc func(oid asn1.ObjectIdentifier) elliptic.Curve
type CurveToOIDFunc func(curve elliptic.Curve) (asn1.ObjectIdentifier, bool)

var (
	CustomIOIDToCurveFunc OIDToCurveFunc
	CustomCurveToOIDFunc CurveToOIDFunc
)

func namedCurveFromOID(oid asn1.ObjectIdentifier) elliptic.Curve {
	switch {
	case oid.Equal(oidNamedCurveP224):
		return elliptic.P224()
	case oid.Equal(oidNamedCurveP256):
		return elliptic.P256()
	case oid.Equal(oidNamedCurveP384):
		return elliptic.P384()
	case oid.Equal(oidNamedCurveP521):
		return elliptic.P521()
	}
	if CustomIOIDToCurveFunc != nil {
		return CustomIOIDToCurveFunc(oid)
	}
	return nil
}

func oidFromNamedCurve(curve elliptic.Curve) (asn1.ObjectIdentifier, bool) {
	switch curve {
	case elliptic.P224():
		return oidNamedCurveP224, true
	case elliptic.P256():
		return oidNamedCurveP256, true
	case elliptic.P384():
		return oidNamedCurveP384, true
	case elliptic.P521():
		return oidNamedCurveP521, true
	}
	if CustomCurveToOIDFunc != nil {
		return CustomCurveToOIDFunc(curve)
	}
	return nil, false
}

Globals are probably not the right answer here. Perhaps there should be an x509.Parser that can be configured with extra hooks, a bit like there is an xml.Decoder to configure the XML parser.

Or perhaps unrecognized curves should be exposed in some general way and client code can just post-process.

/cc @FiloSottile

Agreed with globals. There might be breaking changes once introducing x509.Parser as x509.ParseCertifcate() is used in number of places.

crypto/x509 primarily serves the WebPKI, and there is no use of custom curves there. X.509 is a sprawling standard, so it's critical for the crypto/x509 package to stay focused on its use case.

I will keep this open to collect feedback about use cases, as things of course change over time, but we are not going to support this for now.

I stumble more & more on brainpool curves (https://datatracker.ietf.org/doc/html/rfc5639).
It makes it impossible to parse certificates with this standard. In germany, a lot of big tech-companies are using these curves.
It would be really great to make an Parser configurable / make 2 new functiona which take an callback for deserialization & serialization.
I don't see that big of an issue in providing this functionallity, it should not break any existant implementations.

Is there any update on this, especially when 1.20 will deprecate custom curve implementations? Still no way to provide a workaround?

cc @FiloSottile

Strange to exclude over half of supported openssl curves. Running into this myself and I am having to inject the four Brainpool OIDs and their curves from another library. It'd be fairly trivial to support these, either the regular or both regular and twisted curves.

Any news on this issue?

I would like to support certificates signed with ECDSA keys using brainpool curves in the application I'm working on. I'd prefer to do that without relying on OpenSSL, or by parsing the cert bytes myself in order to get hold of the artifacts needed to use a 3rd party module with brainpool support.

Would really appreciate support for custom curves.

We have the same problem here with the brainpool curves. Yes, it's a german thing but unfortunately we have no choice here as we just have to support this.

Does anyone have an example how to even do this? I'm at a loss. Do I have to replace the x509 package (or the methods I need to read a certificate) and do the same with the tls package when it comes to a TLS handshake?

@ZackaryWelch mentioned that he has to inject the brainpoool curves. I would like to know how and where to inject them.

We are interested in this as well. ICAO 9303 (which defines eMRTDs including NFC data structure and signatures inside all worldwide travel documents incl. passwords and ID cards) mandates custom curves with explicit parameters as part of Document Signing Certificate inside eMRTD NFC chips.

I wonder what is the best way forward for us given that we'd like to consider the option of validating these crypto signatures using native Go crypto.

+1 for custom curves or atleast brainpool... Otherwise I will be just copy/pasting the x509 package and adding my required OIDs...

Just wondering if anyone has found a solution to the issue with eMRTDs and using the native Go crypto?

Just wondering if anyone has found a solution to the issue with eMRTDs and using the native Go crypto?

Fork the existing go-crypto and add your OIDs, the curves used also need to implement the elliptic.Curve interface.

The only functions I had to adjust were namedCurveFromOID and oidFromNamedCurve inside x509/x509.go

for future versions you could also prepare a patch file for these changes.

Other languages can parse these curves, but Go can't. It's really uncomfortable to use it now.

I would like to point out that if go wanted to also support brainpool elliptic curves in a certificate (you can generate one with openssl), the tls module would also need to be updated. Modifying x509 only suffices if you use the curves to manually generate a hash or check a signature or something like that.