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

[Jonathan Hammell <[e-mail]>]

Hi Hubert,

Note that there was a lengthy thread last year debating updating PKCS
#12 or the use of alternative structures for private key protection:
https://mailarchive.ietf.org/arch/msg/spasm/v-xapjceJ4i6uvCgUAe_nOhYbm8/

Looking at your I-D draft-kario-pkcs12-pbmac1, it seems to be a simple
proposal.  However, I'm not sure what you are referring to in the
rationale when you state that you considered "extending the PKCS #5 by
a new field allowing integrity protection".  What structure were you
considering in PKCS #5?  For example, in PBES2-params you could use
authenticated encryption like AES-GCM for the encryptionScheme to get
integrity protection.  That said, the solution proposed in the I-D has
the benefit of protecting the entire AuthenticatedSafe, including any
certificates.

Best regards,
Jonathan

On Wed, Jun 22, 2022 at 11:41 AM Russ Housley <[e-mail]> wrote:
>
> 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 <[e-mail]> 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 <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/spasm
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm