Summary

  • RFC 9879 permits PBMAC1 inside PKCS #12, mandates an interoperable PBKDF2/HMAC-SHA-256 profile and corrects the PBMAC1 password encoding inherited from RFC 9579.
  • The compatibility design can let a legacy reader reach encrypted key material after an unsupported MAC check, while weak KDF parameters and weak passwords remain separate risks.
  • A defensible migration records the exact parameter set, verification result, failure policy and key-custody outcome instead of treating the algorithm identifier as a security verdict.

A portable key container has more than one success condition. It can be syntactically readable. Its encrypted contents can be decrypted. Its integrity check can verify. Its parameters can satisfy local policy. The imported private key can remain inside the intended custody boundary. Those results are related, but none substitutes for the next.

RFC 9879 addresses one of those layers. Published as an Informational IETF document in September 2025, it obsoletes RFC 9579 and updates the PKCS #12 and PKCS #5 specifications. It permits id-PBMAC1 as the integrity algorithm in the PKCS #12 DigestInfo. When that identifier is present, the PBMAC1 parameters must also be present and consistent, and the digest must be calculated over authSafe using them.

The change breaks an old coupling. Under the original PKCS #12 password-integrity construction, the container-specific derivation method constrained how the MAC key was produced. PBMAC1 makes the KDF and the underlying message-authentication function explicit. Every conforming implementation must support PBKDF2 with HMAC-SHA-256 for both the integrity calculation and PBKDF2 pseudorandom function. Other SHA-2 HMACs are recommended; other choices, including scrypt as a KDF, may be implemented.

That flexibility moves authority into the parameters. The derived-key length must be encoded explicitly. A PBKDF2 parameter set that omits keyLength must be rejected, and a SHA-256 HMAC profile should derive 32 octets. PBKDF2 with SHA-1 HMAC should not be used, while other digest functions producing 160 bits or less are prohibited.

Two familiar-looking outer fields cease to govern the calculation. When PBMAC1 is selected, the PKCS #12 macSalt and iterations values must be ignored. RFC 9879 nevertheless recommends keeping them non-empty and non-zero for backwards compatibility. An audit that extracts those outer values without following the selected algorithm into PBMAC1-params can therefore report a convincing but irrelevant iteration count.

The compatibility provision is sharper. The new syntax was designed so that legacy software may still decrypt the key material even when it cannot interpret the new integrity protection, if that software can ignore the MAC verification failure. That is useful during transition: a new envelope need not make old encrypted contents automatically unreachable. It is also a clean demonstration that “the file opened” is not equivalent to “the integrity check passed.” RFC 9879 does not identify a product that behaves this way, and this report does not infer one.

Password encoding shows why running evidence matters. RFC 9579 required a terminated BMPString for PBMAC1. Its verified erratum explains that the implementation used to create the test vectors had actually left the password in UTF-8. RFC 9879 resolves the divergence by requiring UTF-8 without a NULL terminator or byte-order mark. The episode is not proof that implementation always outranks specification. It is evidence that a standards transition must name the exact bytes produced and consumed, not merely the human-visible password.

The included vectors establish bounded facts. There are valid examples using SHA-256 and SHA-512 combinations, and invalid examples for the wrong iteration count, wrong salt and missing key length. Passing them demonstrates that a particular implementation follows those computations. It does not demonstrate that production passwords are strong, that local parameter floors are enforced, that unknown algorithms fail closed, or that imported keys remain in approved storage.

RFC 9879 itself makes the parameter boundary explicit. KDFs can permit very short outputs—even one octet—and their parameters are not cryptographically protected. Such values can make brute-force attacks against the HMAC easier. The document recommends rejecting derived-key lengths below 20 octets and permits rejection of weak parameters. That recommendation is a floor for a local decision, not evidence that every reader enforces it.

The deeper password limit comes from PKCS #5. PBMAC1 verification is a deterministic sequence: obtain salt, iteration count and key length; derive a key from the password; recompute the MAC; output correct or incorrect. Yet password-based cryptography still permits offline guessing. Salt and work factors raise the cost; they do not manufacture entropy in the password. Scrypt offers a memory-hard alternative intended to reduce the advantage of parallel hardware, but RFC 9879 makes its support optional. A label saying “PBMAC1” therefore identifies a mechanism, not one universal strength level.

The evidence chain for an import should read: container received; algorithm and actual parameters parsed; parameter policy accepted; password bytes encoded under the intended rule; MAC verified; decryption separately succeeded; key-use policy accepted; key imported into a named custody boundary; re-export behavior observed. A gap in that chain should remain a gap.

Sources