Кратко

  • В режиме PBMAC1 DigestAlgorithmIdentifier в MacData идентифицирует алгоритм и содержит KDF и схему MAC во вложенных параметрах.
  • Базовый профиль — PBKDF2 с HMAC-SHA-256, явно заданным keyLength и прямым представлением пароля в UTF-8.
  • RFC задают синтаксис и проверки, но не доказывают повсеместную поддержку, сертификацию продукта или достаточность для любой модели угроз.

Граница целостности PFX — это MAC, вычисленный над содержимым authSafe. В PBMAC1 параметры внутри DigestAlgorithmIdentifier поля MacData задают две независимые настройки: функцию выработки ключа по паролю и схему аутентификации сообщения. Читатель должен разобрать и проверить обе, а не восстанавливать их по старым полям.

Поля macSalt и iterations в старой форме MacData при обработке PBMAC1 игнорируются. RFC 9879 всё же советует записывать непустые и ненулевые значения, чтобы пройти предварительную проверку реализаций, ожидающих прежнюю структуру. Это не превращает поля в действующие входы PBMAC1. Если одна сторона использует их как соль или число итераций, а другая — вложенные параметры, проверка перестаёт совпадать.

Обязательная поддержка включает PBKDF2 с HMAC-SHA-256. В параметрах PBKDF2 keyLength должен быть указан явно: отсутствие значения нельзя принимать, а читатель не должен молча подставлять его. Пароль кодируется непосредственно как байты UTF-8, без завершающего нулевого символа и без BOM. Это не тот же формат, который применялся в традиционном PKCS #12, поэтому частичная миграция легко оставляет скрытую несовместимость.

Выбор KDF и выбор MAC не сливаются в одну настройку. Нужно проверять идентификаторы алгоритмов, параметры и длину ключа. HMAC-SHA-1 не рекомендуется, а дайджесты с результатом длиной 160 бит или меньше запрещены для PBMAC1. Производный ключ короче 20 октетов рекомендуется отклонять. Такие правила не делают слабый пароль сильным и не обеспечивают конфиденциальность: речь идёт о целостности.

scrypt может поддерживаться по желанию. При его принятии следует заранее проверять параметры и стоимость ресурсов: память, вычисления, параллелизм и временные пределы. RFC не объявляют один уровень стоимости подходящим для всех моделей угроз и не подтверждают поддержку PBMAC1 конкретными развёрнутыми реализациями PKCS #12.

Переход должен быть согласован между сторонами, формирующими и читающими файлы. Сторона, создающая файл, записывает вложенные параметры PBMAC1, явно указывает keyLength, использует прямые UTF-8-байты и выбирает разрешённые алгоритмы. Старые поля можно сохранять ради совместимости, но нельзя считать их входами безопасности PBMAC1. Сторона, читающая файл, сначала проверяет структуру до затратного получения ключа, отклоняет слабые и неполные значения и ограничивает стоимость. Приём старой формы должен иметь установленный срок и заранее определённое условие прекращения.

Источники