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