Ed25519 certificates

[Filippo Valsorda]

Hello all,

I recently played with implementing Ed25519 certificates in crypto/x509 (and crypto/tls).

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

https://github.com/golang/go/compare/master...FiloSottile:filippo/ed25519

The code is straightforward enough, but I have one main problem: 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. 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 four bad solutions off the top of my head:

1) define Ed25519 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 them

2) use []byte for both types, document it as such

3) use reflect in some clever way to detect the type on the way in and convert it; not sure this works at all on the way out (that is, when returning a ed25519.PublicKey in a parsed certificate)

4) simply promote ed25519 to the stdlib

Anyone with better ideas or comments?

[mikioh...@gmail.com]

but that will mismatch the PublicKey and PrivateKey types. 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.

5) fix #17326 first, then refactor crypto/{tls,x509} along with the go2 march

sooner or later, we'll probably face the similar issue when people want to use net+crypto in stdlib and x/{net,crypto} together for some fancy stuff such as dns-over-https.

[Filippo Valsorda]

2017-12-20 18:49 GMT-0800 mikioh...@gmail.com:

>> but that will mismatch the PublicKey and PrivateKey types. 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.
>
> 5) fix #17326 first, then refactor crypto/{tls,x509} along with the go2 march

I don't think #17326 is relevant: even with the same name, the ed25519 package vendored by the stdlib would be a different package with different types from the one vendored by the application.

[mikioh...@gmail.com]

i think that the mentioned use case is just to make multiple identical copies from a single source without modifying the language specification especially the package clause. for now, cmd/go takes account of such manipulation by using import comment for package clause. i feel like it's fine to make import comment a bit more flexible for accommodating both a) single source to multiple different copies and b) single source to multiple identical copies.

[top...@quorumcontrol.com]

Hi! I realize i'm slightly off topic, but is this x509 code available anywhere as its own package while we wait for a stdlib merge? I've been googling all day for x509 ed25119 :).

Topper

[ajtk...@gmail.com]

Hi Filippo,

The changes look awesome. I followed your change set and used option 4. Cherry-picked your changes for https://github.com/golang/go/issues/23995

Any thoughts on when the changes will be officially supported?

Regards,

Arun