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

Thanks.  I'll take a careful look at page 24 of RFC 7292.

At this point, I am not suggesting any document changes.  Rather, I am saying that the existing structure has the necessary algorithm agility.  The problem comes from the text you reference from RFC 2315, where the context is always a message digest.

Russ

> On Jun 22, 2022, at 11:14 AM, Hubert Kario <hkario@redhat.com> wrote:
> 
> On Wednesday, 22 June 2022 16:58:18 CEST, Russ Housley wrote:
>> Hubert:
>> 
>> Please point to the text in RFC 7292 that is causing your concern.
>> 
>> The PFX structure is:
>> 
>>   PFX ::= SEQUENCE {
>>       version     INTEGER {v3(3)}(v3,...),
>>       authSafe    ContentInfo,
>>       macData     MacData OPTIONAL
>>   }
>> 
>>   MacData ::= SEQUENCE {
>>       mac         DigestInfo,
>>       macSalt     OCTET STRING,
>>       iterations  INTEGER DEFAULT 1
>>       -- Note: The default is for historical reasons and its
>>       --       use is deprecated.
>>   }
>> 
>>  -- IMPORT FROM RFC 2315
>> 
>>   DigestInfo ::= SEQUENCE {
>>     digestAlgorithm DigestAlgorithmIdentifier,
>>     digest Digest }
>> 
>>   Digest ::= OCTET STRING
>> 
>> It seems to me that DigestInfo would be better named macInfo.
> 
> Sorry, I don't follow... You're suggesting I should rename the fields in
> ASN.1 definitions or you're stating that the existing standard is confusing?
> 
>> It carries the MAC algorithm identifier (and optional parameters) as the MAC itself.
> 
> Correct, the problem is that the DigestAlgorithmIdentifier is specified in
> RFC 2315 as:
> 
>  The DigestAlgorithmIdentifier type identifies a message-digest
>  algorithm. Examples include MD2 and MD5. A message-digest algorithm
>  maps an octet string (the message) to another octet string (the
>  message digest).
> 
> I would not classify PBMAC1 as a "message-digest algorithm".
> 
> Moreover, the RFC 7292 is quite explicit that the PBMAC1 can't be placed
> in the PFX structure (see page 24):
> 
>  This document recommends that future definitions of
>  the PFX structure replace the existing MacData object, optionally
>  present in password integrity mode, with a new object definition that
>  holds a MAC based on PKCS#5 [13] [22] PBMAC1 message authentication
>  scheme.  This change would simplify the requirements for key
>  derivation functions used across all parts of the PFX structure.
> 
>>> On Jun 22, 2022, at 6:35 AM, Hubert Kario <hkario@redhat.com> wrote:
>>> 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 ...
>> 
> 
> -- 
> 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
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm