PKCS#12: AES-GCM PBES2 emits AlgorithmIdentifier without GCMParameters — openssl import fails

[dotCooCoo]

When constructing a PKCS#12 PFX with contentEncryptionAlgorithm: { name: "AES-GCM", length: 256 } for either PKCS8ShroudedKeyBag.makeInternalValues or AuthenticatedSafe.makeInternalValues, pkijs 3.4.0 emits the AlgorithmIdentifier with parameters absent (or NULL) instead of the required GCMParameters SEQUENCE. The resulting P12 file fails to import in openssl 3.5.5 with PKCS5_v2_PBE_keyivgen_ex: cipher parameter error.

RFC 5084 §3.2 requires:

GCMParameters ::= SEQUENCE {
  aes-nonce        OCTET STRING,
  aes-ICVlen       AES-GCM-ICVlen DEFAULT 12 }
AES-GCM-ICVlen ::= INTEGER (12 | 13 | 14 | 15 | 16)

in the parameters field of the AlgorithmIdentifier for any AES-GCM OID.

Reproducer

const pkijs = require("pkijs");
// ... build a PFX with:
await pfx.parsedValue.authenticatedSafe.parsedValue.safeContents[0]
  .value.safeBags[0].bagValue.makeInternalValues({
    password: passwordBuf,
    contentEncryptionAlgorithm: { name: "AES-GCM", length: 256 },
    hmacHashAlgorithm: "SHA-512",
    iterationCount: 600000,
  });
// ... then pipe pfx.toSchema().toBER() through:
//   openssl pkcs12 -info -in client.p12 -passin pass:...
// → PKCS5_v2_PBE_keyivgen_ex: cipher parameter error

Same construction with { name: "AES-CBC", length: 256 } works correctly — the OCTET STRING IV that PBES2/AES-CBC expects matches what pkijs emits, but AES-GCM needs the GCMParameters SEQUENCE instead.

Related

• GCMParams in EnvelopedData required to be OCTET STRING instead of SEQUENCE #287 — same encoder bug, CMS EnvelopedData scope.
• Emit GCMParameters SEQUENCE for AES-GCM AlgorithmIdentifier (RFC 5084) #487 — PR that fixes both by introducing a GCMParams class (RFC 5084 §3.2) and routing AES-GCM AlgorithmIdentifier emission through it on both the PBES2 and CMS code paths, with an OCTET-STRING legacy decrypt fallback so previously-produced pkijs output still decrypts.

[dotCooCoo]

Correcting the premise of this report. The encoding complaint stands, but fixing it does not produce the openssl import this issue asks for, and the title promises more than the parameters can deliver.

Testing #487 against the reproducer above on openssl 3.5.7: a PFX built through AuthenticatedSafe.makeInternalValues with { name: "AES-GCM", length: 256 } now carries

30 11 04 0C <12-octet nonce> 02 01 10

which is the GCMParameters SEQUENCE of RFC 5084 §3.2, and openssl reads far enough to name the cipher:

PKCS7 Encrypted data: PBES2, PBKDF2, id-aes256-GCM, Iteration 2048, PRF hmacWithSHA256

It then fails exactly as before:

evp_cipher_asn1_to_param_ex:cipher parameter error
PKCS5_v2_PBE_keyivgen_ex:cipher parameter error

The same PFX built with { name: "AES-CBC", length: 256 } imports cleanly, so the cipher is the only variable. The reason is not the parameter encoding:

openssl pkcs8 -topk8 -v2 aes-256-gcm -in key.pem -passout pass:...

pkcs8: AEAD ciphers not supported

openssl declines AEAD ciphers in PBES2 in both directions, so no GCMParameters encoding makes that import succeed.

This is the same shape as #287. RFC 5084 scopes AES-GCM to the RFC 5083 AuthEnvelopedData content type, which carries the ICV in a mac field. PBES2 has nowhere to put it, so AES-GCM inside PBES2 is outside what RFC 5084 defines and outside what openssl accepts.

What #487 does is narrower than this issue asked for: it replaces a bare OCTET STRING with the GCMParameters an RFC 5084 reader expects, validates aes-ICVlen against the INTEGER (12 | 13 | 14 | 15 | 16) the RFC permits rather than passing it to WebCrypto as a tag length unchecked, and keeps previously-produced output decryptable. It is a conformance fix, not an interoperability one, so it references this issue rather than closing it.