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

encoding/asn1: Marshal fails with ECDSA public keys #32541

Closed
andrewmbenton opened this issue Jun 11, 2019 · 4 comments
Closed

encoding/asn1: Marshal fails with ECDSA public keys #32541

andrewmbenton opened this issue Jun 11, 2019 · 4 comments

Comments

@andrewmbenton
Copy link
Contributor

What version of Go are you using (go version)?

$ go version
go version go1.12.5 linux/amd64

Does this issue reproduce with the latest release?

The latest stable release, yes.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"

What did you do?

I attempted to use the asn1 package to encode the public portion of an ECDSA key.

Here's a link to the playground: https://play.golang.org/p/Kwfs67b4KaI

What did you expect to see?

Encoded bytes.

What did you see instead?

An error.

@FiloSottile
Copy link
Contributor

ecdsa.PublicKey is a complex type that includes values that can't be serialized, and encoding/asn1 does not have special cases for known types, so it tries to serialize everything.

Use crypto/x509.MarshalPKIXPublicKey or create your own struct to pass to Marshal if you need a specific encoding.

@andrewmbenton
Copy link
Contributor Author

Yeah in retrospect this makes sense. crypto/x509.MarshalPKIXPublicKey adds PKIX format overhead though, which you have to then unpack if you just want the public key bytes.

Ideally the x509 package would export its marshalPublicKey func name. Any reason not to do that?

For now I have to essentially replicate the internals of that func and use crypto/elliptic.Marshal directly.

@FiloSottile
Copy link
Contributor

Feel free to open a proposal issue for it. The two main reasons I can think of that might not get it accepted are if there is no reference for its format, or if it's not invertible without knowing the type in advance (that is, we can't write a corresponding Parse function). If you to address those, it will help getting it approved.

@mathieudevos
Copy link

I'm entirely opposed to opening marshalPublicKey, instead I suggested we split its functionality in 2 to increase type-safety in the program.

Proposal: #32657

@golang golang locked and limited conversation to collaborators Jun 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants