Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: crypto/tls, crypto/x509: EdDSA certificates support #25355

Open
FiloSottile opened this Issue May 11, 2018 · 7 comments

Comments

Projects
None yet
6 participants
@FiloSottile
Copy link
Member

FiloSottile commented May 11, 2018

Ed25519 and Ed448 certificates are finally coming.

https://tools.ietf.org/html/draft-ietf-curdle-pkix-07 is the draft for X.509, and Ed25519/Ed448 are supported directly by TLS 1.3.

The implementation is not hard and I have a branch of it already: master...FiloSottile:filippo/ed25519

The problem is that we'll have to vendor golang.org/x/crypto/ed25519 for the primitive functionality (like we did with golang.org/x/crypto/curve25519), but that will mismatch the PublicKey and PrivateKey types, which are exposed to the user in tls.Certificate.PrivateKey and x509.Certificate.PublicKey. A user-supplied ed25519.PrivateKey would not type-assert to the vendored ed25519.PrivateKey, and a parsed ed25519.PublicKey would not type-assert to the application side one.

I can think of three decent solutions off the top of my head:

  1. define Ed25519PublicKey and Ed25519PrivateKey types in crypto/x509, which are easy to cast to/from, as they're nothing but []byte; if/when we promote ed25519 to the stdlib, alias and deprecate them

  2. use []byte for both types, document it

  3. simply promote ed25519 to the stdlib

We also need to decide if we want to bring Ed448 on board at the same time. We don't have a Ed448 implementation yet.

See also: https://groups.google.com/forum/#!topic/golang-dev/FNfJzm-BDno

@FiloSottile FiloSottile added this to the Go1.12 milestone May 11, 2018

@gopherbot gopherbot added the Proposal label May 11, 2018

@arunjohn99

This comment has been minimized.

Copy link

arunjohn99 commented May 11, 2018

Thanks, @FiloSottile . I really like option 3, clean and consistent with existing approach. Followed your footsteps and ported the changes for ed25519 under crypto package to support option 3

@mattghali

This comment has been minimized.

Copy link

mattghali commented Oct 24, 2018

hi there, i am trying to get Wireguard key generation going inside terraform, using terraform-provider-tls, and ed25519 support in the x509 module would make it really easy.

@ianlancetaylor ianlancetaylor modified the milestones: Go1.12, Proposal Dec 21, 2018

@FiloSottile FiloSottile self-assigned this Jan 24, 2019

@arunjohn99

This comment has been minimized.

Copy link

arunjohn99 commented Feb 11, 2019

@FiloSottile Given that we are probably 2-3 weeks away from 1.12 release, can you confirm whether this would make it to 1.12

@FiloSottile

This comment has been minimized.

Copy link
Member Author

FiloSottile commented Feb 11, 2019

Definitely not, the proposal is not decided yet, and 1.12 has been in feature freeze for months.

@arunjohn99

This comment has been minimized.

Copy link

arunjohn99 commented Feb 11, 2019

Bummer! Any thoughts on when this would be supported?

@FiloSottile

This comment has been minimized.

Copy link
Member Author

FiloSottile commented Feb 11, 2019

The more detailed reports of how this would be used we have, the more likely it is that it will be soon. It's a matter of prioritization, and of making sure we are not adding to the stdlib something we don't really need.

@lorenz

This comment has been minimized.

Copy link

lorenz commented Feb 11, 2019

I would definitely switch over most internal certificate issuance if EdDSA (specifically Ed25519) is supported since its design is much more robust than ECDSA and RSA and it performs better than both.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.