https://bz.apache.org/bugzilla/show_bug.cgi?id=69800
--- Comment #8 from Christopher Schultz <[email protected]> --- I think it would be rare for someone to want to customize the named groups based upon the certificate itself. Sure, some certificate types narrow-down the list of named groups available for the handshake, but I think we can leave that to the crypto engine to figure out. I think that there are two major use-cases for manually-setting the named groups for a TLS connector: 1. Removing something the operator thinks is "bad" (e.g. if NIST suddenly announces that x25519 is vulnerable) 2. Adding something the operator wants to use that isn't standard out of the box (e.g. ML-KEM) In both of these cases, I think we can restrict (or expand) the list of named groups at the SSLHostConfig level and not bother interfering with the handshake itself by manually adjusting the named groups to match the operator's (server) configuration and the contents of the client-hello. The crypto engine should handle this for us. I did see that OpenJDK does not have support for any of these new named groups, so you will have to have both Java 20+ and BC for the time being. I don't know enough about the OpenSSL-backed crypto provider to know how complicated it would be to wire this through to OpenSSL, but it looks like using BC as a JSSE provider would work with very little code -- assuming we just copy a new namedGroups attribute into the SSLParameters. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
