PKCS#8 provides two encryption schemes (PBES1 and PBES2) and one message authentication scheme (PBMAC1). It seems like a combined method (eg. authenticated encryption) would be ideal but whatever.
Anyway, my question is... are there any tools in the wild that can create a PBMAC1 PKCS#8 encoded private key?
The man pages for OpenSSL make me think that OpenSSL doesn't support this:
Your link (2898) is actually PKCS5 which defines those two encryption schemes (with predefined cases for 1) and the MAC scheme. PKCS8 uses the ASN.1-flexible way (AlgorithmIdentifier) to identify the encryptionAlgorithm, but for specific values references the older PKCS5 v1.5 which had only the scheme now called PBES1 and PBKDF1. OpenSSL also supports the PBES2/PBKDF2 schemes from PKCS5 v2 and the PBE schemes defined in PKCS12 (see below).
PKCS8 does not support a separate authentication algorithm. All defined PBES1 and PBES2 schemes and most pkcs12PBE ones do use CBC mode with padding, which provides some protection against accidental corruption but not tampering.
PKCS12 is now the more common and arguably better way of transporting privatekeys plus usually related certificate(s). It does have a PBMAC on the whole container (technically optional but usually present) and PBE on the KeyBag and CertBag items in the container; even though certificates shouldn't need to be secret, by convention (or just custom) the CertBag is encrypted with weak 40-bit encryption, although OpenSSL has an undocumented option -certpbe none to leave it clear. PKCS12 originally referred to the older PKCS5 (effectively PBES1/PBKDF1) and added its own PBE/PBKDF scheme again with several predefined cases, plus its own PBMAC scheme. PKCS12 v1.1 changes this to prefer PBES2/PBKDF2 from newer PKCS5 for encryption while still documenting its own PBE schemes in Appendix C for backward compatibility, and still using its own PBMAC scheme.
If I had to speculate why the need for integrity protection wasn't appreciated at first, it might be that by 1990 most industry experience had been with wrapping symmetric keys, mostly for transport -- rarely storage, which was in special hardware instead -- and that customarily used a manually verified Key Check Value.
