Fix test_pkcs12.rb in FIPS.

[junaruga]

This PR is working in progress.

I see the test failures on LibreSSL and AWS-LC cases.

---

• Use the AES-256-CBC using PBKDF2 which is FIPS-approved, instead of the PBE-SHA1-3DES using PKCS12KDF which is not FIPS-approved. See also the man page openssl-pkcs12(1).
• OpenSSL::PKCS12.create calling the PKCS12_create has the argument mac_iter which uses a MAC key using PKCS12KDF which is not FIPS-approved. In the FIPS case, set the mac_iter = -1 to omit the MAC key. See also the man page PKCS12_create(3).
• As the test data OpenSSL::PKCS12.new calling PKCS12_parse verifies the MAC using PKCS12KDF which is not FIPS-approved, I created the test data without MAC by the openssl pkcs12 -nomac.

[rhenium]

I feel these existing tests should simply be skipped. My impression is that PKCS#12 is currently effectively unsupported in FIPS environments as I doubt password-based PKCS#12 is actually used without a MAC.

I think PKCS12_create() allows omitting the MAC mainly so that users can set a MAC with non-default parameters later, for example as shown in #772.

On a side note, RFC 9579 / RFC 9879 introduced an alternative MAC algorithm based on PBMAC1 from PKCS#5v2, which I think is FIPS-compatible. However, this is still pretty new and we don't have a wrapper for it yet: https://docs.openssl.org/master/man3/PKCS12_gen_mac/

[junaruga]

I feel these existing tests should simply be skipped. My impression is that PKCS#12 is currently effectively unsupported in FIPS environments as I doubt password-based PKCS#12 is actually used without a MAC.

Okay. That makes sense. I think we want to test popular use cases.

I rebased the PR without MAC less key.

I am still using the AES-256-CBC as much as possible. Because I feel the AES-256-CBC is more modern and more typical. The AES-256-CBC is also used as openssl pkcs12's default algorithm according to the man page openssl-pkcs12(1).

However, LibreSSL's OpenSSL::PKCS12.create didn't accept the pass: nil in the case of the AES-256-CBC in the test_create_no_pass. The folllowing LibreSSL man page PKCS12_newpass shows a hint not to accept the NULL.

https://man.openbsd.org/PKCS12_newpass.3

If the PKCS#12 structure does not have a password, use the empty string "" for oldpass. Passing NULL for oldpass results in a PKCS12_newpass() failure.

And AWS-LC's OpenSSL::PKCS12.create raised "UNKNOWN_ALGORITHM" in AWS-LC with AES-256-CBC. So, I added some conditional logic.

If you don't like this conditional logic, I can change this PR's source code back to use the PBE-SHA1-3DES as value of the DEFAULT_PBE_PKEYS and DEFAULT_PBE_CERTS used in the master branch.

What do you think?

[rhenium]

However, LibreSSL's OpenSSL::PKCS12.create didn't accept the pass: nil in the case of the AES-256-CBC in the test_create_no_pass. The folllowing LibreSSL man page PKCS12_newpass shows a hint not not to accept the NULL.

https://man.openbsd.org/PKCS12_newpass.3

This is interesting. It appears that the underlying function in OpenSSL, EVP_PBE_CipherInit_ex() accepts NULL to mean an empty password, as an undocumented behavior. It doesn't make sense to me, but I think it might be just for historical reason.

I also think using PBES2/AES is better, but I'd prefer to reduce conditionals because I'm not very familiar with PKCS#12 and want to keep it simple.

[junaruga]

I also think using PBES2/AES is better, but I'd prefer to reduce conditionals because I'm not very familiar with PKCS#12 and want to keep it simple.

Yes your preference makes sense to me. I will revert the conditional logic to the original logic.

[junaruga]

I rebased this PR, fixing mentioned from you. Now there are 2 commits in the PR. The first commit is to the main. The 2nd commit is to update the comments. Could you review the PR again? Thanks.

[junaruga]

I rebased this PR again, updating the following part of the comment and commit message, reflecting our conversation. Could you review the PR again? Thank you.

+# PBE-SHA1-3DES uses PKCS12KDF which is not FIPS-approved according to the RFC
+# 7292 PKCS#12.
+# https://datatracker.ietf.org/doc/html/rfc7292#appendix-C
+# > The PBES1 encryption scheme defined in PKCS #5 provides a number of
+# > algorithm identifiers for deriving keys and IVs; here, we specify a
+# > few more, all of which use the procedure detailed in Appendices B.2
+# > and B.3 to construct keys (and IVs, where needed).  As is implied by
+# > their names, all of the object identifiers below use the hash
+# > function SHA-1.
+# > ...
+# > pbeWithSHAAnd3-KeyTripleDES-CBC  OBJECT IDENTIFIER ::= {pkcs-12PbeIds 3}
+#
+# Note that the pbeWithSHAAnd3-KeyTripleDES-CBC (pkcs12-pbeids 3) in the RFC
+# 7292 PKCS#12 means PBE-SHA1-3DES in OpenSSL. PKCS12KDF is used in PKCS#12.
+# https://oidref.com/1.2.840.113549.1.12.1.3
+# https://github.com/openssl/openssl/blob/ed57d1e06dca28689190e00d9893e0fd7ecc67c1/crypto/objects/objects.txt#L385