On Fri, 11 Jul 2025 23:06:34 GMT, Mark Powers <[email protected]> wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java
>> line 162:
>>
>>> 160: DerValue kdf = pBMAC1_params.data.getDerValue();
>>> 161: var kdfParams = new PBKDF2Parameters();
>>> 162: String kdfAlgo = kdfParams.parseKDF(kdf);
>>
>> Maybe just use a `PBKDF2Parameters(DerValue) `constructor? Then retrieve the
>> algorithm via a separate getter method.
>
> That constructor doesn't exist. I don't know how I would do what you suggest.
I see it now. Fixed.
>> src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Parameters.java
>> line 174:
>>
>>> 172: throw new IOException("PMAC1 parameter parsing error: "
>>> 173: + "missing keyLength field");
>>> 174: }
>>
>> Where is these requirements on `keyLength` documented? I found them inside
>> RFC 9579. But no such restriction in RFC 8018. If this is PKCS12-specific
>> requirement, I am not sure if these checks should be enforced inside
>> `PBMAC1Parameters` class. They can be done in the `PKCS12KeyStore` class
>> when using this object, right?
>
> You are right. The check belongs in the `PKCS12KeyStore` class.
Since I've replaced usage of the `PBMAC1ParameterSpec` with `PBEParameterSpec`,
there is no longer a way to pass keyLength to `PKCS12KeyStore`. I think the
HMAC output size check can be removed since it is a SHOULD. The keyLength is
present check should stay for now since it is a MUST. We can revisit this later
if we switch to a different parameter spec.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353274015
PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2353273005
