On Thu, 13 Mar 2025 20:15:42 GMT, Weijun Wang <wei...@openjdk.org> wrote:
>> src/java.base/share/conf/security/java.security line 671: >> >>> 669: # jdk.hpke.disabledAlgorithms=kem_id=0x10,kdf_id=0x01,aead_id=0xffff >>> 670: # >>> 671: jdk.hpke.disabledAlgorithms= >> >> Do you expect that these algorithm ids would be embedded in some higher >> level network protocols or artifacts and thus could potentially be leveraged >> that way? Trying to understand the motivation/need for this property, as we >> have not (as of yet) disabled algorithms at the JCE layer, with the >> rationale that it is up to the developer to understand the security risks of >> directly using a weak crypto algorithm. >> >> There may also be some overlap with Red Hat's proposed Security Providers >> Filter. > > You’re right. I can remove this part if there’s no requirement yet. For TLS, > we already enforce constraints through the existing TLS security property. > Perhaps another usage scope is enough when we start supporting Encrypted > ClientHello. Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r1995642460
