Add support for parsing PKCS#1 priv/pub keys, SEC1 priv keys

[haydentherapper]

This adds support for parsing RSA public and private keys, and SEC 1 EC
private keys. This should reduce unexpected format errors for library
users.

Signed-off-by: Hayden Blauzvern hblauzvern@google.com

Summary

Release Note

Added support for parsing PKCS#1 private and public keys, and SEC 1 private keys

Documentation

[dekkagaijin]

"PRIVATE KEY" can begin blocks for arbitrary key types, yes? Is there an RFC which disambiguates them?

[haydentherapper]

PKCS#8 encoding is typically associated with "PRIVATE KEY", which the code should already be doing for marshalling.

[haydentherapper]

It doesn't look like I have the permission to retrigger the Action workflow, can a maintainer? I can't repro the test failure locally.

[dlorenc]

"PRIVATE KEY" can begin blocks for arbitrary key types, yes? Is there an RFC which disambiguates them?

There's no RFC here, it's very much just convention unfortunately. From this amazing blog post:
https://smallstep.com/blog/everything-pki/

If you’re lucky RFC 7468 will give good guidance to figure out what your PEM payload is. Elliptic curve keys are usually labeled as such, though there doesn’t seem to be any standardization. Other keys are simply “PRIVATE KEY” by PEM. This usually indicates a PKCS#8 payload, an envelope for private keys that includes key type and other metadata. Here’s an example of a PEM-encoded elliptic curve key:

[dekkagaijin]

Fair enough. Security libraries can have a little parsing ambiguity, as a treat :p