摘要

  • 使用 PBMAC1 时，MacData 的 DigestAlgorithmIdentifier 标识 PBMAC1，并携带嵌套的 KDF 与消息认证方案。
  • PBKDF2/HMAC-SHA-256、明确的 keyLength 以及不带终止符和 BOM 的直接 UTF-8 密码字节构成基线。
  • 这些 RFC 规定语法和验证要求，并不证明所有实现都支持 PBMAC1，也不构成产品认证或通用安全保证。

PFX 的完整性边界是对 authSafe 内容计算的 MAC。PBMAC1 的关键在于，MacData 中的 DigestAlgorithmIdentifier 的参数同时表达基于密码的密钥派生函数和消息认证方案。两者是分开的选择，接收方必须把它们作为安全相关输入解析和校验。

传统 MacData 的 macSalt 和 iterations 字段容易造成误读。RFC 9879 在 PBMAC1 处理中忽略这些字段，同时建议写入方仍编码非空、非零值，以便先检查旧字段形状的旧读入方继续处理对象。兼容字段不能因此变成 PBMAC1 的活动盐值或迭代次数。若一方使用它们，另一方使用嵌套参数，最终就会验证失败。

规范要求实现支持使用 HMAC-SHA-256 的 PBKDF2。PBKDF2 参数必须明确包含 keyLength；缺失时不得接受，也不得由读入方静默猜测或补齐。密码应直接编码为 UTF-8 字节，不附加结尾空字符或字节顺序标记。这不同于传统 PKCS #12 密码表示，迁移时不能把旧转换规则带入 PBMAC1。

KDF 与 MAC 的选择彼此独立，因此算法标识符、参数和密钥长度都要验证。规范不鼓励 HMAC-SHA-1，并禁止输出长度为 160 位或更短的摘要算法用于 PBMAC1；派生密钥短于 20 字节时建议拒绝。这些是输入和策略控制，不意味着弱密码会变强，也不提供机密性；本文讨论的是完整性保护。

scrypt 是可选能力，不是所有读写方都必须支持的共同假设。接受它时仍要检查参数和资源成本，包括内存、计算量、并行度及本地时间预算。规范没有宣称某个成本适合所有威胁模型，也没有证明现有 PKCS #12 部署普遍支持 PBMAC1。

迁移应由写入方和读取方共同安排。写入方生成嵌套 PBMAC1 参数、明确的 keyLength、直接 UTF-8 字节和符合策略的算法；可以保留非空传统字段以照顾兼容性，但不能把它们当作 PBMAC1 安全输入。读取方先验证再派生，拒绝缺失、弱化或成本失控的参数。接受旧格式应有明确范围、监测方式和退出条件。

来源