proposal: crypto/x509: support extracting X25519 public keys from certificates

[EdSchouten]

Proposal Details

Even though X25519 key pairs (not to be confused with Ed25519 key pairs) can't be used to establish TLS connections, there are still cases in which you want to use them in combination with X.509 certificates. For example, if X25519 is used to perform public key authenticated encryption (e.g., NaCl's crypto_box), X.509 certificates may be used to authenticate the identity of the peer before encrypting/decrypting. RFC 8410 added the ability to embed X25519 public keys into X.509 certificates for such use cases.

Right now x509.ParseCertificate() completes successfully when presented with a certificate containing an X25519 public key. Unfortunately, it does end up discarding the public key, as Certificate.PublicKeyAlgorithm and Certificate.PublicKey will be set to UnknownPublicKeyAlgorithm and nil, respectively.

The proposal here is to actually let x509.ParseCertificate() extract the public key from the certificate and return it in the form of an *ecdh.PublicKey. The PublicKeyAlgorithm enumeration will be extended to include an additional element for this public key algorithm, which will simply be called X25519.

Code changes can be found here: https://go-review.googlesource.com/c/go/+/632875

[gabyhelp]

Related Issues

• proposal: crypto/tls, crypto/x509: EdDSA certificates support #25355 (closed)
• crypto/tls: create certs w/o KeyEncipherment KU for non-RSA keys in generate_cert.go #36500 (closed)

Related Code Changes

• crypto/x509: add support for PKCS8/PKIX X25519 key encodings

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[ianlancetaylor]

CC @golang/security

[rolandshoemaker]

Per the crypto/x509 package documentation "the primary goal of the package is to provide compatibility with the publicly trusted TLS certificate ecosystem and its policies and constraints".

Since X25519 is not supported by TLS, and X25519 keys are not allowed in certificates issued by publicly trusted CAs, per the CABF baseline requirements, I'm not sure there is a strong reason for us to add explicit support for these certificates.

As you say, ParseCertificate does parse these certificates. If you do need to use them for whatever purpose, you can still manually extract the key from the Certificate.RawSubjectPublicKeyInfo field and use it for your purposes. This is slightly more complex, but I think a worthwhile trade off to prevent people from accidentally misusing these certificates for purposes they are not intended for.

[FiloSottile]

We could probably include an Example for how to use cryptobyte to extract a public key from RawSubjectPublicKeyInfo.

[EdSchouten]

That sounds fine to me. That said, I am also interested in generating certificates. It looks like CreateCertificate() doesn’t respect RawSubjectPublicKeyInfo right now. Would it make sense to extend CreateCertificate() to do so?

[EdSchouten]

@rolandshoemaker @FiloSottile Friendly ping.

[rolandshoemaker]

I'm not sure I'd be comfortable blindly copying the contents of RawSubjectPublicKeyInfo into a certificate. Currently CreateCertificate will always result in a correctly encoded certificate, regardless of the way you populate the Certificate fields. With the proposed change we could end up producing a certificate that could not be parsed.

We could plausibly attempt to decode the RawSubjectPublicKeyInfo to check it's mostly valid, before inserting it into the certificate, but I'm not particularly convinced this is functionality we should be supporting regardless.

crypto/x509 is, like I said, very much focused on the basic use-case of the webpki, and we try to limit the amount of fiddling the user can do in order to reduce the complexity of the API surface and of our underlying implementation. I think in general, for experimentation, crypto/x509 is not the right library to be using.