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

[Hubert Kario <[e-mail]>]

On Wednesday, 29 June 2022 22:50:46 CEST, Jonathan Hammell wrote:
> 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, ...
>
> 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.

precisely

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

True, though support for it is also limited (I know of no software package
that supports it).
The other problem is that also means that such file would need to
drop the mac section, which also many tools don't like...

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

As I've said, OpenSSL does, now. Which means that even if some application 
or
appliance doesn't, it wouldn't be hard to convert PBMAC1 PKCS#12 to legacy
PKCS#12 file. Also, implementing a similar switch in any library should be
fairly simple...
Similarly, I'd expect implementation/addition of PBMAC1 support to be 
easier
than introducing AES key wrap, so compatibility for PBMAC1 solution is 
likely
to be higher overall.
-- 
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