Re: [lamps] [EXTERNAL] Proposal for PBMAC1 in PKCS#12

[Mike Ounsworth <[e-mail]>]

Hi Hubert,

About these two changes:


> 3. if the PBMAC1 algorithm is used, the macSalt value MUST be ignored, for backwards compatibility it SHOULD NOT be empty

> 4. if the PBMAC1 algorithm is used, the iteration value MUST be ignored, for backwards compatibility it SHOULD have a non-zero positive value

I assume the reason for ignoring these is that they are already specified in the id-PBMAC1 params "PBKDF2-params", and so you're proposing to have the copy in the PKCS#12 MacData be ignored and the copy in PBKDF2-params be used?



About the backwards compatibility discussion; I think I agree with Russ that encouraging no integrity protection check is worse than supporting old algorithms -- though your FIPS lab may not agree :/  That means a "flag day" is almost preferrable if a client is not able to parse a p12 with new crypto.
I wonder if this is substantial enough to be worth bumping the version field of the p12 object to v4?
And if you're doing that ... then might as well clean up the ASN.1 to make MacData.macSalt and MacData.Iterations OPTIONAL.

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[e-mail]> On Behalf Of Hubert Kario
Sent: June 22, 2022 5:35 AM
To: [e-mail]
Subject: [EXTERNAL] [lamps] Proposal for PBMAC1 in PKCS#12

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________
Hello everybody,

The work on the new NIST FIPS 140-3 implementations made us aware that the current PKCS #12 specification uses a legacy PBKDF for the calculation of the whole-file MAC value: PBKDF1. The PKCS #12 standard also doesn't provide a way to specify any alternative KDF. Since PBKDF1 isn't an approved mechanism in FIPS, the whole file becomes FIPS non-compliant.

While deciding how to modify the PFX structure we considered two options:
change the structure completely, so that the whole macData is extensible and allows for use of PBMAC1, or by placing the PBMAC1 as as "hash"
in the existing structure. The first option is much cleaner, but it has the unintended consequence of making the file completely unreadable by any of the popular software able to process PKCS#12 files that exists now.
The second option does on the other hand create files that even old versions of OpenSSL (like 1.0.1) can read when the user specifies the -nomacver option. Allowing for a relatively easy workaround for interoperability with old systems.

With those two things in mind I'd like to propose the following I-D to specify use of PBMAC1 in PKCS#12:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-kario-pkcs12-pbmac1/__;!!FJ-Y8qCqXTj2!dYb2eaF0MwC-dRJr3A_dd2ATl_kQPOjYAJEJlT3c4I0Oez8iCwGlmHLIcYFF20iyPJzspaK9tNfd80wg-2LxBOUcxg$
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: https://urldefense.com/v3/__http://www.cz.redhat.com__;!!FJ-Y8qCqXTj2!dYb2eaF0MwC-dRJr3A_dd2ATl_kQPOjYAJEJlT3c4I0Oez8iCwGlmHLIcYFF20iyPJzspaK9tNfd80wg-2LywBbDYQ$
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

_______________________________________________
Spasm mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!dYb2eaF0MwC-dRJr3A_dd2ATl_kQPOjYAJEJlT3c4I0Oez8iCwGlmHLIcYFF20iyPJzspaK9tNfd80wg-2IU-16RvA$
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.