RFR: 8343232: PKCS#12 KeyStore support for RFC 9579: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v2]
Mark Powers
mpowers at openjdk.org
Tue Sep 16 18:11:41 UTC 2025
On Fri, 11 Jul 2025 23:06:34 GMT, Mark Powers <mpowers at openjdk.org> 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
More information about the security-dev
mailing list