On Thu, 13 Mar 2025 19:52:10 GMT, Sean Mullan <mul...@openjdk.org> wrote:
>> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> switch to Asserts.assertThrows in test; use traditional javadoc style > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r1994245601
