Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
2027: Encode only the public key information r=jaredkerim a=glasserc Refs #1890. Fixes #2021. In #2009 I hacked up generation of a public key by serializing a complete certificate. However, `fastecdsa` expects only a public key, which is just one part of the certificate. That the code in #2009 ever worked at all is accidental and almost miraculous. It seems that `fastecdsa` doesn't really do full parsing of the ASN.1 in its input -- it just kind of does a "good enough" job (probably for speed?) and plucks the last vaguely-parametric-looking things out of the file. This means that depending on the other contents of the certificate, it might actually grab the correct `x` and `y` and function correctly. But it can also grab other bit strings and fail catastrophically. I was able to reproduce this failure by running the contract tests against stage. This patch fixes the tests. However, we've come to this point because I committed code that merely "seemed to work", so I wanted to be much more thorough in my work this time. The cert that we have is an X.509 certificate, described in [RFC 5280](https://tools.ietf.org/html/rfc5280). RFC 7468 [explains](https://tools.ietf.org/html/rfc7468#section-13) that a PEM-encoded public key corresponds to the subject public key information field from RFC 5280, so retrieving this field from the cert and serializing it is correct. Just to confirm, we can also see that `fastecdsa` specifies in https://github.com/AntonKueltz/fastecdsa/blob/master/fastecdsa/encoding/pem.py#L109 that it accepts elliptic-curve key data in [RFC 5480](https://tools.ietf.org/html/rfc5480) format. This RFC is the one that adds a format for encoding elliptic-curve keys to RFC 3279, which is the RFC referred to by RFC 5280 as defining the methods for encoding public key materials in X.509 certificates. So again, the public key data from the certificate should be the format that this library expects. /cc @mozbhearsum @jvehent Co-authored-by: Ethan Glasser-Camp <ethan@betacantrips.com>
- Loading branch information