RFR: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1) [v3]

[Mark Powers]

On Wed, 17 Sep 2025 14:32:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 180:
>> 
>>> 178:     private int macSaltLength = -1;
>>> 179:     private byte[] extraSalt = null;
>>> 180:     private int extraIterationCount = -1;
>> 
>> I don't think it's necessary to break the user-provided mac algorithm like "PBEWithHmacSHA256" into `macAlgorithm == "PBMAC1"` and `pbmac1Hmac == "HmacSHA256"`. Keep a single one no matter what kind of mac algorithm it is.
>
> How necessary is it to remember `macSaltLength`? Before this change, we always generate a new salt of 20 bytes without looking at the old one. Also, what about `extraSalt`, and `extraIterationCount`? Since they are useless for PBMAC1, why cannot we just always hardcode them in the encoding?

Imagine reading a PBMAC1 protected keystore with a 32 byte salt. Now it's time to write it out. You have to remember the salt length of whatever PBMAC1 you just read in order to generate a new salt of the same length. It doesn't seem right to always generate 20 bytes of salt.

We could hardcode the extras, but it seems better to me to return the original values if you're upgrading an old MAC protected keystore to a PBMAC1 protected keystore. It's is a nice touch but the code complexity might not be worth it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24429#discussion_r2361550737