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

[Hubert Kario <[e-mail]>]

On Tuesday, 28 June 2022 19:33:48 CEST, Jonathan Hammell wrote:
> 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.

Ah, sorry, I was thinking about PKCS#8, I keep mixing them up.

More specifically, I was thinking of something like

     EncryptedPrivateKeyInfo ::= SEQUENCE {
       encryptionAlgorithm  EncryptionAlgorithmIdentifier,
       encryptedData        EncryptedData,
       hmacAlgorithm        HmacAlgorithmIdentifier,
       hmacData             HmacData}

(i.e. add hmacAlgorithm and hmacData fields) with HmacAlgorithmIdentifier
allowing PBMAC1 only, with HmacData defined like

HmacData ::= OCTET STRING



While PBES2 does allow for AES-GCM, to our knowledge, NIST does not allow
use of AES-GCM for protection of key data, at least not in the way it's
defined for use inside PBES2.
Secondly, no popular open source cryptographic library implements AES-GCM
support inside PKCS#12. So such files would be completely unreadable
by all but the newest implementations.

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

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