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

[Jonathan Hammell <[e-mail]>]

Hi Hubert,

On Tue, Jun 28, 2022 at 2:48 PM Hubert Kario <[e-mail]> wrote:
> 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

If you were to do that, you may not want to be specific to HMAC (e.g.
CMAC or KMAC could be used) and you may want to make the MAC fields
optional:

EncryptedPrivateKeyInfo ::= SEQUENCE {
        encryptionAlgorithm  EncryptionAlgorithmIdentifier,
        encryptedData        EncryptedData,
        macAlgorithm     [0] IMPLICIT
MessageAuthenticationCodeAlgorithmIdentifier OPTIONAL,
        macData          [1] IMPLICIT MessageAuthenticationCode OPTIONAL}

where MessageAuthenticationCodeAlgorithm and MessageAuthenticationCode
are defined in RFC 5652.  However, if macAlgorithm and macData are
provided, legacy clients would likely bork on the ASN.1 parsing since
there was no extension marker in the original SEQUENCE.

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

Indeed, in that case you may actually want to use AES Key Wrap (RFC
5649).  It has implicit integrity protection, thus still avoiding
changes to PKCS #8 or PKCS #12.

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

I'm curious how many of these legacy implementations would allow you
to ignore PBMAC1 integrity protection and decrypt the key.  And even
if it did, would no integrity protection not be worse than the legacy
password integrity mode?

Best regards,
Jonathan