Summary

  • RFC 9879 places PBMAC1 and its complete parameter set in the MacData DigestAlgorithmIdentifier.
  • PBKDF2 with HMAC-SHA-256, an explicit keyLength, and direct UTF-8 password bytes provide the interoperability baseline.
  • The RFCs define syntax and validation, not universal implementation support, product certification, or proof that any cost setting suits every threat model.

The PFX integrity boundary is the MAC over authSafe content. In PBMAC1 mode, the DigestAlgorithmIdentifier in MacData identifies PBMAC1. Its nested parameters carry two separate choices: the password-based key-derivation function and the message-authentication scheme. A reader must parse that structure as security-relevant input rather than infer behavior from the older MacData macSalt and iterations fields.

RFC 9879 says those legacy fields are ignored for PBMAC1 processing, while advising writers to encode nonempty and nonzero values because some older readers may enforce the old field shape before inspecting the algorithm. Such a compatibility field can help an old parser reach the algorithm identifier; it cannot become an active PBMAC1 salt or iteration count. Treating it as one produces divergent keys and failed verification.

The mandatory baseline is PBKDF2 using HMAC-SHA-256. PBKDF2 parameters must carry an explicit keyLength; a missing value must not be accepted or silently invented. Passwords are encoded directly as UTF-8 bytes, with neither a terminating null character nor a byte-order mark. This differs from the legacy PKCS #12 password representation, so changing the algorithm while retaining the old conversion can still break interoperability.

The KDF and MAC choices are separate. Implementations must validate both algorithm identifiers and their parameters. HMAC-SHA-1 is discouraged, digest algorithms with output of 160 bits or fewer are forbidden for PBMAC1, and derived keys shorter than 20 octets should be rejected. These are input checks, not a claim that a weak password becomes strong or that PBMAC1 supplies confidentiality; this briefing concerns integrity protection.

Scrypt is optional. Where it is accepted, its parameters and resource cost must still be validated, including memory, computation, parallelism and operational limits. The RFCs do not establish one cost as adequate for every environment, and they do not prove that deployed PKCS #12 implementations support PBMAC1.

The migration decision is bounded. Writers should emit nested PBMAC1 parameters, an explicit PBKDF2 keyLength, direct UTF-8 password bytes and policy-compliant algorithms. They may retain nonempty legacy-shaped fields for compatibility, but must not use them as PBMAC1 security inputs. Readers should validate the nested structure before derivation, reject omitted or weak parameters, and bound resource cost. A coordinated rollout can preserve a defined legacy window without accepting ambiguity as security.

Sources