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

[Hubert Kario <[e-mail]>]

On Friday, 1 July 2022 00:04:36 CEST, Mike Ounsworth wrote:
> 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?

Yes, since those values are not enough to derive correct keys with PBKDF2,
it's better to ignore them than to try to have two copies of those 
parameters.
The other limitations are for backwards compatibility only (as applications
still expect values there, even if they don't recognise the Algorithm OID).

> 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 :/  

Reading those files without checking the integrity protection isn't FIPS
compliant behaviour; it's not really what lab requests, it's just about
what users will find more convenient to work with.

> 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?

For FIPS compliance we have two options:
 1. use AES-KW, and have PKCS#12 files with an AEAD algorithm, but without
    whole-file MAC; then only the newest software can do anything with the
    file (both because of atypical, and in practical terms completely new,
    encryption algorithm and atypical MAC omission)
 2. use PBMAC1, and use exactly the same algorithms any modern PKCS#12
    implementation needs to support anyway (AES-128-CBC, PBKDF2, HMAC with
    SHA-1 or SHA-256), with limited backwards compatibility for 
applications
    that can skip MAC check

Now, thinking of users, I consider the 2nd option to be the best option, 
both
because backwards compatibility is already deployed and because 
implementing
it will be easiest, thus most likely to be quickly supported.
With an engineer hat on, redefining the PFX structure or using the 1st 
option
is definitely much "nicer looking".

> ---
> 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
>

-- 
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic