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

Support the certificate_authorities extension

    Details

    • Type: CSR
    • Status: Closed
    • Priority: P3
    • Resolution: Approved
    • Fix Version/s: 15
    • Component/s: security-libs
    • Labels:
      None
    • Subcomponent:
    • Compatibility Risk:
      minimal
    • Compatibility Risk Description:
      The compatibility should be minimal as we did not change the behavior comparing to TLS 1.2.
    • Interface Kind:
      System or security property
    • Scope:
      JDK

      Description

      Summary

      Add support of the certificate_authorities extension for TLS 1.3 in JDK.

      Problem

      The "certificate_authorities" extension is an optional extension introduced in TLS 1.3 and used to indicate the certificate authorities (CAs) which an endpoint supports and which SHOULD be used by the receiving endpoint to guide certificate selection.

      In TLS 1.2, this function is built into the CertificateRequest handshake message.

      This function is supported in TLS 1.2 and prior versions. However, it is not implemented in the TLS 1.3 implementation. Without this function, the authentication certificate selected may be not the one the peer could accepted, when there are multiple certificates available.

      There are compatibility and interoperability impact when applications upgrade to use TLS 1.3 if there are multiple certificates available in the connection context.

      Solution

      With this update, the certificate_authorities extension will be supported for TLS 1.3 in both client and server sides in JDK.

      As old releases are also impacted, the update will also be backported to JDK 8 and 11 as well.

      Specification

      1. Support the certificate_authorities extension for client certificate selection.

        The certificate_authorities extension for client certificate selection is present in the CertificateRequest handshake message.

        With this update, this extension is always present in the CertificateRequest handshake message to indicate the client certificate selection. This behavior is consistent with what we did for TLS 1.2.

      2. Support the certificate_authorities extension for server certificate selection.

        The certificate_authorities extension for server certificate selection is present in the ClientHello handshake message.

        In practice, if the server certificate cannot be validated by the underlying programs, the user may manually check the certificate in order to access the service. The certificate could be accepted manually, and the handshake continues. For example, the browsers provide the manual option to accept untrusted server certificate. If this extension is enabled in the ClientHello handshake message, and the server's certificate does not chain back to any of the CAs in the extension, then the server will terminate the handshake and close the connection. There is no chance for the client to perform the manual check. Therefore, enabling this extension in ClientHello may lead to unexpected compatibility issues for such cases.

        With this update, this extension could be enabled in the ClientHello handshake message to indicate the server certificate selection. But by default, it is not enabled for compatibility.

      3. The extension is not used when there is too much certificate authorities.

        According to TLS 1.3 specification [RFC 8446] the maximum size of the certificate_authorities extension is 2^16 bytes. if the client or server trusts more CAs such that it exceeds the size limit of the extension, enabling this extension does not really make sense as there is no way to indicate the peer certificate selection accurately. In such cases, the extension is just not used, rather than an exception is thrown, for better compatibility and interoperability.

      4. The known interoperability issues

        According to TLS 1.3 specification [RFC 8446] the maximum size of the certificate_authorities extension is 2^16 bytes. The maximum TLS record size is 2^14 bytes. If the handshake message is bigger than maximum TLS record size, it should be splitted into several records. In fact, some server implementations do not allow ClientHello messages bigger than the maximum TLS record size and will immediately abort the connection with a fatal alert. Therefore, if the client trusts too many certificate authorities, there may be unexpected interoperability issues.

        With this update, this extension could be enabled in the ClientHello handshake message to indicate the server certificate selection. But by default, it is not enabled for interoperability.

      5. Add a new System Property to turn on the certificate_authorities extension for server certificate selection.

        If there is no requirement for manually checking the certificate, applications may want to enable the extension for server certificate selection, which could mitigate the compatibility and interoperability impact when the server have multiple certificates.

        A new System Property, "jdk.tls.client.enableCAExtension", is added for this purpose. The default value is "false". If it is set to "true", the certificate_authorities extension will be present in the the ClientHello handshake message to indicate the server certificate selection.

      6. Documentation the System Properties and the size limit in the JSSE Reference Guide.

        Note that the System Properties are currently used by the SunJSSE provider, but it is not guaranteed to be examined and used by other implementations. If it is examined by another implementation, then that implementation should handle it in the same manner as the SunJSSE provider does.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                xuelei Xue-Lei Fan
                Reporter:
                xuelei Xue-Lei Fan
                Reviewed By:
                Sean Mullan
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: