Could you refer which issue that obsolete all these curve parameters? Thanks.

Those 2 repos were created in the last week. If there are no real world applications using these, I don't see why they should be included in standard library, especially if they are obsolete.

First, I may not have expressed myself well, none of them are obsolete. They are just out of use. I created the library a week ago but I've been looking for them for years.

Regarding FiloSottile's comment, he must have been referring to bn158, bn190, bn222, bn254, bn286, bn318, bn350 etc. But I don't know precisely in which proposal this was denied. The ones I asked to include Fp256BN and Fp512BN are not obsolete, see:

https://tools.ietf.org/id/draft-kasamatsu-bncurves-01.html
https://www.iso.org/standard/80241.html

Obviously there won't be applications that use them, because in practice they don't exist yet. They are in disuse.

To be more specific:

Fp256BN (2014) ISO/IEC 15946-5:2022
Fp512BN (2014) ISO/IEC 15946-5:2022
FRP256v1 (?) ANSSI 21 November 2011
GOST2012_512-A/B (2012) RFC 7836
NUMS (2014) ?
Sm2p256v1 (2012) GM/T 0003-2012
Sm9p256v1 (2016) GM/T 0044-2016

I need TLS 1.2 support for these, without needing to fork some version of Go, so I need to patch each update to use unconventional algorithms that are more secure than Secp256r1/Secp256k1 (1985-2001).

One way would be providing the OID in the *elliptic.CurveParams..

CC @golang/security

I need TLS 1.2 support for these, without needing to fork some version of Go

Why do you need TLS 1.2 support for these?
What other systems support them?
Do web browsers? Does OpenSSL?

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Greetings!

I need it because they are newer. I mean, the French government released the curve FRP256v1 for this purpose: to be free and utilised. They are free and already exist in my repository. It is difficult to understand why the algorithms around the world are discarded.

The question must be:
Why only three algorithm choices for TLS?
What other systems/languages has just three options of algorithms for TLS?
Does the OpenSSL? See.
Everyone that uses Go becomes obliged to use only RSA, ECDSA and Curve25519, not because they are the best options, but because they are the only options. These algorithms must be among all algorithm options and not be the only options.

I am just proposing that the new generation of curves be included and not replace the existing ones. But just in TLS and x509 libraries; In fact they all have an elliptic.Curve/*ecdsa.PrivateKey interface. We would only need to add the OIDs to avoid the "unknown curve" error, the other components of the library remain intact.

Sm2 already exists on OpenSSL as GOST2012_512
Fp256BN is not used except github.com/hyperledger/fabric-amcl and C applications.

Like I said, it's very recent, there's no applications, You will be pioneer

Cheers and sorry bad English

The algorithms Go chooses to support is part of a balance that attempts to provide the highest level of security we can for the lowest cost of complexity and operational burden. Generally our stance is that an algorithm or signature scheme should not be included simply because it exists, but because there is an exigent need for it, or because it truly offers a significantly higher level of security than what is currently available and that there is a industry wide move towards supporting it.

Since it is much harder to remove support for an algorithm than it is to add one, and without significant users of these algorithms, I think we would be extremely reluctant to support them.

@rolandshoemaker ECDSA and RSA isn't highest level of security and lowest cost of complexity. RSA is broken depending on the key size and at a high cost compared to elliptic curves, and ECDSA is authored by the NSA, which says a lot about its security. With only one algorithm left that would survive the Post-Quantum era, it's a tough choice.

Like I said, it's very recent, there's no applications, You will be pioneer

I don't know whether we should do this or not, I just want to note that being a pioneer is not a goal of the Go standard library.

This sounds quite strange even because it's an innovative language in which I'm able to write and compile programs from my windows 7 to run on linux machines, Android phones and Raspberry Pi (and vice-versa). There is no other language that does this without the need to install toolchains, which is why I chose it.

(I humbly ask those who don't want to help not to get in the way, it's been hard enough to get here.)

It sounds like we are not ready to commit to having these in our tree (making them very hard to remove). It should be possible to maintain them out of tree as needed.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No coments.

This proposal has been declined as retracted.
— rsc for the proposal review group

Greetings, I want to rectify my last comment and reopen the proposal with only the Koblitz SecP256k1, SM2, Brainpool and FRP256v1 algorithms (which is already in use in OpenSSL and LibreSSL).

Thanks

Based on the comments above (#52778 (comment)) I think the decision stands.

An unwise decision, sounds like censorship yes, not rule of minimum effort. I could perfectly close the proposal after the negative, I appreciate at least this effort.