On Tue, 15 Apr 2025 18:37:40 GMT, Sean Mullan <mul...@openjdk.org> wrote:
>> src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line
>> 136:
>>
>>> 134: * {@snippet lang=java class="PackageSnippets"
>>> region="hpke-spec-example"}
>>> 135: *
>>> 136: * @implNote
>>
>> Making this implementation specific means that other providers could in
>> theory choose different defaults, which reduces compatibility but an
>> application could never be sure, or even know if this is for algorithms in
>> RFC 9180. These are probably the most reasonable defaults for RFC 9180
>> compliant implementations. Did you consider making these defaults a
>> requirement of HPKE implementations? I also wonder if "HPKE" is too general.
>> If there is ever a new HPKE spec with say a new KEM or KDF algorithm for
>> EC/XDH keys, would it be called "HPKE2"?
>
> Consider adding a String or Enum argument to `of()` with the name of the
> profile, ex "RFC9180".
I can add a sentence saying if an implementation does not support default
numeric algorithm identifiers then an exception will be thrown.
I still think it's useful to provide defaults. Now that the recipient requires
the numeric algorithm identifiers to be provided, at least this will no longer
be an interop issue between implementations. As for future new KEM or KDF
algorithms for EC/XDH keys, I believe they will have different numeric
algorithm identifiers and users can just specify them so there will be need for
"HPKE2".
In fact, suppose the current kem_id for XDH is found insecure one day and a new
one is defined, we can update the `@implNote` to make the new one the default.
Those using `of()` will automatically switch to the safer one and there is no
need to update the code. That said, this does need both sides supporting the
new kem_id.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2052587728
