Go: proposal: crypto/tls, crypto/x509: EdDSA certificates support

[FiloSottile]

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: https://github.com/golang/go/compare/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

4) 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

[arunjohn99]

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]

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.

[arunjohn99]

@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]

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

[arunjohn99]

Bummer! Any thoughts on when this would be supported?

[FiloSottile]

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]

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.

[gopherbot]

Change https://golang.org/cl/174945 mentions this issue: crypto/ed25519: promote from golang.org/x/crypto/ed25519

[FiloSottile]

Discussed with @rsc, we're promoting crypto/ed25519 to the standard library. o/

[gopherbot]

Change https://golang.org/cl/175478 mentions this issue: crypto/x509: add support for Ed25519 certificates and keys

[jackivanov]

@FiloSottile In what version would it be included?

[lorenz]

@jackivanov Ed25519 is going to be available in the standard library as of 1.13 (unless something drastic happens), the certificate support is still being reviewed, but will most likely end up in 1.13 too.

[gopherbot]

Change https://golang.org/cl/177698 mentions this issue: crypto/tls: add support for Ed25519 certificates in TLS 1.2 and 1.3

[gopherbot]

Change https://golang.org/cl/182698 mentions this issue: ed25519: turn into a wrapper for crypto/ed25519 beginning with Go 1.13

[odiferousmint]

Any progress on the Ed448 implementation? Perhaps https://github.com/otrv4/ed448 might help. I would rather have it in the official crypto library. Might want to take a look at SUPERCOP's implementation and https://sourceforge.net/p/ed448goldilocks/wiki/Home/ as well. The two may be identical, the author is Mike Hamburg in both cases.

By the way, is there a chance of integrating (and using it throughout the library of course) memguard (https://github.com/awnumar/memguard) into the crypto library?

[FiloSottile]

We don't really see enough adoption for Ed448 to justify carrying a full implementation in the standard library.

I discuss how effectively applying memguard would be a much larger effort (and carry a large complexity cost) in #21865.