Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8254709

TLS support for the EdDSA signature algorithm

    XMLWordPrintable

    Details

    • Type: CSR
    • Status: Closed
    • Priority: P3
    • Resolution: Approved
    • Fix Version/s: 16
    • Component/s: security-libs
    • Labels:
      None
    • Subcomponent:
    • Compatibility Risk:
      low
    • Compatibility Risk Description:
      Hide
      These new signature schemes will be in addition to a plethora of other current signature schemes that are widely supported by virtually all TLS servers. If a server cannot support ed25519 or ed448 they will skip over these unsupported signature schemes and use a scheme that they can support (which will be often be determined by their certificate key/signature type and in this case would not be EdDSA anyway).
      Show
      These new signature schemes will be in addition to a plethora of other current signature schemes that are widely supported by virtually all TLS servers. If a server cannot support ed25519 or ed448 they will skip over these unsupported signature schemes and use a scheme that they can support (which will be often be determined by their certificate key/signature type and in this case would not be EdDSA anyway).
    • Interface Kind:
      System or security property
    • Scope:
      SE

      Description

      Summary

      Add support for EdDSA signatures in the JDK TLS implementation. EdDSA will now be a supported signature algorithm for certificates and on handshake messages that are digitally signed. This applies to TLS versions 1.0 through 1.3.

      Problem

      Support for EdDSA signatures was added to JCE through JEP 339, but this did not include TLS support. Like XDH (i.e. x25519/x448), these curves have many desirable properties, including resistance to side channel attacks and great performance. There are specifications that document support for EdDSA signatures in TLS 1.2 and earlier (RFC 8422) and TLS 1.3 (RFC 8446). Currently the SunJSSE provider does not provide support for these signature schemes.

      Solution

      We will add support for EdDSA signature schemes to the SunJSSE provider. The support will be for signatures on specific TLS handshake messages as well as support for validating signatures on presented certificates and for use in certificate selection for certificate messages. We will support the use of certificates with EdDSA keys for client and server authentication for TLS versions 1.0 through 1.3. Certificates with EdDSA signatures on them are supported for all TLS versions.

      Within the handshake itself, the documented signature schemes ed25519 and ed448 will now show up in signature_algorithms and signature_algorithms_cert following the ecdsa schemes that use the traditional three NIST curves:

      Pre-EdDSA support:

          "signature_algorithms (13)": {
            "signature schemes": [
                    ecdsa_secp256r1_sha256,
                    ecdsa_secp384r1_sha384,
                    ecdsa_secp521r1_sha512,
                    rsa_pss_rsae_sha256,
                    rsa_pss_rsae_sha384,
                    rsa_pss_rsae_sha512,
                    rsa_pss_pss_sha256,
                    rsa_pss_pss_sha384,
                    rsa_pss_pss_sha512,
                    rsa_pkcs1_sha256,
                    ...]
          },
          "signature_algorithms_cert (50)": {
            "signature schemes": [
                    ecdsa_secp256r1_sha256,
                    ecdsa_secp384r1_sha384,
                    ecdsa_secp521r1_sha512,
                    rsa_pss_rsae_sha256,
                    rsa_pss_rsae_sha384,
                    rsa_pss_rsae_sha512,
                    rsa_pss_pss_sha256,
                    rsa_pss_pss_sha384,
                    rsa_pss_pss_sha512,
                    rsa_pkcs1_sha256,
                    ...]
          },

      With EdDSA support included:

          "signature_algorithms (13)": {
            "signature schemes": [
                    ecdsa_secp256r1_sha256,
                    ecdsa_secp384r1_sha384,
                    ecdsa_secp521r1_sha512,
                    ed25519,
                    ed448, 
                    rsa_pss_rsae_sha256,
                    rsa_pss_rsae_sha384,
                    rsa_pss_rsae_sha512,
                    rsa_pss_pss_sha256,
                    rsa_pss_pss_sha384,
                    rsa_pss_pss_sha512,
                    rsa_pkcs1_sha256,
                    ...]
          },
          "signature_algorithms_cert (50)": {
            "signature schemes": [
                    ecdsa_secp256r1_sha256,
                    ecdsa_secp384r1_sha384,
                    ecdsa_secp521r1_sha512,
                    ed25519,
                    ed448, 
                    rsa_pss_rsae_sha256,
                    rsa_pss_rsae_sha384,
                    rsa_pss_rsae_sha512,
                    rsa_pss_pss_sha256,
                    rsa_pss_pss_sha384,
                    rsa_pss_pss_sha512,
                    rsa_pkcs1_sha256,
                    ...]
          },

      Specification

      While it does not constitute a change to the API, the String EdDSA (case-sensitive) may now be used for the keyType parameter used in various methods found in javax.net.ssl.X509KeyManager and javax.net.ssl.X509ExtendedKeyManager. When EdDSA is provided as a key type, aliases corresponding to Ed25519 and Ed448 keys will be returned (assuming they meet all other criteria required of the other parameters used in those methods). This should also be documented in the Standard Algorithm Names document under the Key Types section.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              jnimeh Jamil Nimeh
              Reporter:
              xuelei Xue-Lei Fan
              Reviewed By:
              Bradford Wetmore
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: