3
$\begingroup$

What are the valid key types which can get signed (or generated and signed) by a CA to constitute an SSL certificate?

For the keys used in TLS, the key types I have seen are RSA and EC. Anything else?

For non-TLS use cases, are there any other key types that could be used? DH sounds like an option, but I don't think I have ever came across a certificate built upon DH public key.

$\endgroup$
2
  • $\begingroup$ For which version? $\endgroup$
    – kelalaka
    Commented Oct 28, 2020 at 19:44
  • 2
    $\begingroup$ For TLS1.0-1.2 see RFC2246/4346/5246 7.4.2 and 7.4.6 plus RFC4492/8422 as modified by RFC5246 A.7. For TLS1.3 see RFC8446 4.4.2.2 combined with 4.2.3. $\endgroup$ Commented Oct 29, 2020 at 0:06

1 Answer 1

2
$\begingroup$

RFC 5280 is the relevant standard for X.509 PKI certificates. Per section 4.1.2.7 of that standard:

The object identifiers for the supported algorithms and the methods for encoding the public key materials (public key and parameters) are specified in RFC3279, RFC4055, and RFC4491.

RFC 3279 specifies the following public key types:

  • RSA
  • DSA
  • Diffie-Hellman Key Exchange (DHKE)
  • Key Exchange Algorithm (KEA)
  • Elliptic curve DSA (ECDSA)
  • Elliptic curve Diffie-Hellman (ECDH)

RSA 4491 adds the following public key types:

  • GOST R 34.10-94
  • GOST R 34.10-2001

RFC 4055 adds some signature and other algorithms, but no additional key types.

Finally, section 4.2 of RFC 8692 adds that "certificates conforming to RFC5280 can convey a public key for any public key algorithm", so other types seem possible, although obviously certificates containing more exotic keys may not be interoperable.

Specifically for public-trust TLS certificates, the CA/Browser Forum Baseline Requirements restrict the key types to RSA and ECDSA (section 6.1.5), with additional restrictions appropriate to the type. For TLS more generally, the public key in the server certificate should be compatible with the selected key exchange algorithm.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.