JDK-7192189 : Support endpoint identification algorithm in RFC 6125
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-08-17
  • Updated: 2022-03-10
  • Resolved: 2022-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 19
19 b13Fixed
Related Reports
CSR :  
JDK-8282630 - Support endpoint identification algorithm in RFC 6125
Relates :  
JDK-8282843 - sun/security/util/Pem/encoding.sh fails after JDK-7192189
Relates :  
JDK-8062515 - Migrate use of sun.security.** to supported API
Relates :  
JDK-8282832 - Update file path for HostnameMatcher/cert5.crt in test sun/security/util/Pem/encoding.sh
Sub Tasks
JDK-8282800 :  
Release Note: Support endpoint identification algorithm in RFC 6125 - New
Description
See http://mail.openjdk.java.net/pipermail/security-dev/2012-August/005371.html

Hello,

Looking at the Javadoc for X509ExtendedTrustManager, it seems that the
algorithms supported by
SSLParameters.setEndpointIdentificationAlgorithm(...) are "HTTPS" and
"LDAPS". ... <deleted>...

I'm not sure if there is much awareness for it, but there is an RFC
that aims to harmonise the best practices for server name
identification across protocols: RFC 6125, "Representation and
Verification of Domain-Based Application Service Identity within
Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in
the Context of Transport Layer Security (TLS)". (In practice, it's
actually quite close to the HTTPS rules from RFC 2818.)

I'd just like to suggest that further versions of the JDK/JRE could
support an "RFC6125" algorithm in addition to the existing ones, since
it's meant to be independent of the application protocol (perhaps all
this could be enabled by default too, to prevent cases where users
don't verify the host name at all).

Best wishes,
Bruno.
Comments
Changeset: 72e987e3 Author: Sean Mullan <mullan@openjdk.org> Date: 2022-03-08 18:18:57 +0000 URL: https://git.openjdk.java.net/jdk/commit/72e987e3b49b81f2f66d125c18ab459d9ed572b6
08-03-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/7697 Date: 2022-03-04 14:59:54 +0000
04-03-2022
The only case I can see where our TLS implementation is not compliant with RFC 6125 is the first wildcard rule in https://datatracker.ietf.org/doc/html/rfc6125#appendix-B.2: 1. The client SHOULD NOT attempt to match a presented identifier in which the wildcard character comprises a label other than the left-most label (e.g., do not match bar.*.example.net). Although this type of wildcard is acceptable per RFC 2818, I think we should comply with RFC 6125 and not allow a wildcard of this type, and I think the compatibility risk should be fairly low. A CSR and release note should be filed, however.
03-03-2022
There a couple of cases involving wildcarded domains where we are not strictly compliant (i.e. not following SHOULD NOT rules) with RFC 6125. Will add details later.
16-02-2022
Would consider it in a future release.
11-04-2013