Кратко

  • PrivateKeyInfo из RFC 5208 и OneAsymmetricKey из RFC 5958 задают переносимое представление секретного материала. Незашифрованная форма не подтверждает конфиденциальность, контроль доступа, HSM или удаление копий.
  • Расшифрование, математическая проверка, соответствие открытому ключу, импорт, авторизация, операция и принятие приложением — разные квитанции. Успешный parser отвечает только за синтаксис.

Контейнер решает задачу совместимости

PKCS #8 даёт общий внешний формат ключам с разным внутренним устройством. RFC 5208 включает версию, идентификатор алгоритма, OCTET STRING с закрытым ключом и необязательные атрибуты. Значение внутренних октетов определяет регистрация алгоритма.

Граница точна: формат не знает, где байты созданы, лежали ли они во временном файле, кто их скопировал и в какой backup они попали. Корректный ASN.1 доказывает соответствие грамматике, а не непрерывную цепочку хранения.

RFC 5958 заменяет RFC 5208, называет структуру OneAsymmetricKey, допускает открытый ключ и пакет из нескольких ключей. Спецификация прямо говорит, что содержимое пакета не защищено. Его можно завернуть в защитный CMS-тип. Значит защита — отдельное действие с отдельным результатом.

Два заголовка обозначают два состояния

RFC 7468 использует PRIVATE KEY для незашифрованной формы, а ENCRYPTED PRIVATE KEY — для EncryptedPrivateKeyInfo. Последняя содержит идентификатор шифрования и ciphertext. Сначала кодируется информация о ключе, затем полученные байты шифруются.

Журнал должен сохранить оба события: разбор защищённой оболочки и расшифрование с конкретными KDF, salt, стоимостью, cipher, credential и проверкой целостности. Статус imported скрывает место и время появления открытого текста.

RFC 8018 напоминает, что пароли часто выбираются из малого пространства. Один OID не подтверждает стойкость. Нужны параметры, ограничения попыток, политика и фактическая реализация.

Риск меняется, структура остаётся

Один объект PKCS #8 может пройти память генератора, диск, систему заявок, software keystore, облачный KMS и HSM. Формат останется прежним, но владелец, юрисдикция, число копий и возможность экспорта изменятся.

Расширение .p8, тип application/pkcs8 и правильный PEM не доказывают HSM residency. Идентификатор объекта в HSM тоже не исключает прежнюю открытую копию, exportable policy или менее защищённую реплику.

Квитанция хранения связывает исходный hash, канал, импортёра, slot, object ID, export policy, репликацию, audit и удаление временных файлов. Эти факты создаёт running system, а не parser.

Синтаксически верный ключ может быть чужим

RFC 5958 может включать открытый ключ; отдельные алгоритмические структуры также несут публичные компоненты. Но систему всё равно надо заставить вывести или проверить public key и сравнить с независимым certificate, account или trust record.

RFC 8479 сохраняет inputs для последующей проверки генерации некоторых RSA/DSA параметров. Наличие seed и hash algorithm не доказывает, что validator запускался и дал положительный verdict.

После соответствия остаётся разрешение. Политика может запретить использование. Созданная подпись может не пройти из-за сообщения, контекста, времени, цепочки или algorithm policy. Каждый переход может остановить успех.

Номер новой RFC не обновляет парк

RFC 5208 опубликована в 2008 году как Informational. Standards Track RFC 5958 заменила её в 2010 году, добавив новое имя, public-key field, version rule и CMS type. При этом совместимость сохраняет старую v1-форму.

Строка RFC 5958 в inventory не доказывает единое поведение exporter, importer, backup и restore. Нужны наблюдаемые encoding, negative tests, version handling, round trip и реальное восстановление. Ссылка сообщает намерение; работающий код — поведение.

Не сжимать доказательства

Раздельно хранить: исходные байты; текстовое декодирование; ASN.1; plaintext/protected type; KDF и cipher; расшифрование/целостность; математическую проверку; public-key match; место и exportability; авторизацию; операцию; проверку результата; принятие приложением; отзыв и удаление.

PRIVATE KEY называет представление. Расшифрование показывает доступ к открытому тексту. Public-key comparison — соответствие. HSM log — действие внутри границы. Signature verification — результат над одним сообщением. Ни одна квитанция не наследует полномочия следующей.

Руководству следует оставить общую спецификацию минимальной, явно назначить локальные правила хранения и считать проверяемый результат работающего кода первичным доказательством. Provenance объясняет путь, но не заменяет эффект.

Источники

  1. Сведения RFC 5208
  2. RFC 5208 HTML
  3. Текст RFC 5208
  4. IETF Datatracker: RFC 5208
  5. История RFC 5208
  6. Ссылки RFC 5208
  7. Errata RFC 5208
  8. Сведения RFC 5958
  9. RFC 5958 HTML
  10. Текст RFC 5958
  11. IETF Datatracker: RFC 5958
  12. История RFC 5958
  13. Ссылки RFC 5958
  14. Errata RFC 5958
  15. RFC 8018 — парольная криптография
  16. RFC 8351 — media type EncryptedPrivateKeyInfo
  17. RFC 7468 — текстовые кодировки
  18. RFC 8479 — параметры проверки PKCS #8
  19. RFC 5915 — структура EC private key
  20. Heng Lu — слои реальности
  21. Heng Lu — минимальная начальная спецификация
  22. Heng Lu — приоритет работающего кода