[
https://issues.apache.org/jira/browse/CXF-9229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095042#comment-18095042
]
Freeman Yue Fang edited comment on CXF-9229 at 7/9/26 4:34 PM:
---------------------------------------------------------------
sent PR here
https://github.com/apache/cxf/pull/3299
The new <sec:namedGroups> XML configuration element (and the corresponding
TLSParameterBase.setNamedGroups() Java API) is needed because neither the JDK
nor CXF previously exposed a way to control the TLS key-exchange groups
per-endpoint at the CXF configuration level.
Without this API, the only option is the JVM-wide system property
jdk.tls.namedGroups, which is a global setting that affects every TLS
connection in the process and must be set before any SSLContext is created.
That is not suitable for production deployments where different endpoints may
need different group preferences, or where setting a JVM-wide property is not
acceptable.
The new API allows users to declare the preferred named groups declaratively in
the existing CXF security XML configuration:
{code}
<httpj:tlsServerParameters jsseProvider="BCJSSE">
<sec:namedGroups>
<sec:namedGroup>X25519MLKEM768</sec:namedGroup>
<sec:namedGroup>x25519</sec:namedGroup>
</sec:namedGroups>
</httpj:tlsServerParameters>
{code}
On SunJSSE this is applied via SSLParameters.setNamedGroups() (JDK 20+,
silently ignored on older JDKs). On BC JSSE it is applied via
BCSSLParameters.setNamedGroups() through a reflection-based helper to avoid a
compile-time dependency on bctls-jdk18on.
Note: for BC JSSE, jdk.tls.namedGroups still needs to be set at JVM startup to
register the group at the SSLContext level — the per-engine API can only
restrict or reorder groups already present in the context-level map, not add
new ones. This is a BC JSSE constraint, not a CXF one.
was (Author: ffang):
sent PR here
https://github.com/apache/cxf/pull/3299
The new <sec:namedGroups> XML configuration element (and the corresponding
TLSParameterBase.setNamedGroups() Java API) is needed because neither the JDK
nor CXF previously exposed a way to control the TLS key-exchange groups
per-endpoint at the CXF configuration level.
Without this API, the only option is the JVM-wide system property
jdk.tls.namedGroups, which is a global setting that affects every TLS
connection in the process and must be set before any SSLContext is created.
That is not suitable for production deployments where different endpoints may
need different group preferences, or where setting a JVM-wide property is not
acceptable.
The new API allows users to declare the preferred named groups declaratively in
the existing CXF security XML configuration:
<httpj:tlsServerParameters jsseProvider="BCJSSE">
<sec:namedGroups>
<sec:namedGroup>X25519MLKEM768</sec:namedGroup>
<sec:namedGroup>x25519</sec:namedGroup>
</sec:namedGroups>
</httpj:tlsServerParameters>
On SunJSSE this is applied via SSLParameters.setNamedGroups() (JDK 20+,
silently ignored on older JDKs). On BC JSSE it is applied via
BCSSLParameters.setNamedGroups() through a reflection-based helper to avoid a
compile-time dependency on bctls-jdk18on.
Note: for BC JSSE, jdk.tls.namedGroups still needs to be set at JVM startup to
register the group at the SSLContext level — the per-engine API can only
restrict or reorder groups already present in the context-level map, not add
new ones. This is a BC JSSE constraint, not a CXF one.
> Prove that CXF can support Post-Quantum Cryptography TLS using the
> X25519MLKEM768 hybrid key-encapsulation mechanism (KEM).
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: CXF-9229
> URL: https://issues.apache.org/jira/browse/CXF-9229
> Project: CXF
> Issue Type: Sub-task
> Components: Transports
> Reporter: Freeman Yue Fang
> Assignee: Freeman Yue Fang
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
