Центр принимает решения о выпуске и подписи, а процедура создания ключа регулирует получение и защиту его ключевого материала. Эти роли не сводятся к покупке устройства.
Практический смысл
Почему это важно
Наличие устройства само не описывает всю процедуру. Нужно установить, кто участвует, каким требованиям отвечает модуль, как фиксируются действия и как защищается материал вне него.
Доказательная часть
Что подтверждено
При создании ключевой пары центра в области серверных Baseline Requirements обязательны физически защищённая среда, описанная в политике или регламенте центра, и участники доверенных ролей с контролем несколькими людьми и разделением знания.
Граница применимости: CA/Browser Forum, 6.1.1.1, пункты 1–2. Требования к созданию ключа CA в публичной серверной PKI; не правило для всякого пользовательского ключа или каждой частной CA.
Ключевую пару CA создают внутри криптографического модуля, соответствующего применимым техническим и организационным требованиям, указанным в политике или регламенте центра. Пункт 6.1.1.1 сам не задаёт марку устройства или числовой уровень FIPS.
Граница применимости: CA/Browser Forum, 6.1.1.1, пункт 3. Этот пункт не является полным перечнем требований к модулю: специальные уровни требуют отдельного чтения 6.2.7.
Центр обязан вести журнал действий по созданию своей ключевой пары. Для корневой пары и пары подчинённого центра вне группы оператора корня предусмотрены дополнительные материалы церемонии: сценарий, наблюдение аудитора либо полная видеозапись и заключение аудитора.
Граница применимости: CA/Browser Forum, 6.1.1.1 в проверенной редакторской выписке; дополнительные условия относятся к указанным ролям центров, а не к каждому конечному сертификату.
Защита закрытого ключа CA вне указанной правилами проверенной системы или устройства должна предотвращать раскрытие ключа. Раздел 6.2 допускает физическую защиту, шифрование либо их сочетание; это не безусловное требование одновременно применить оба способа.
Граница применимости: CA/Browser Forum, 6.2. Условия допустимости конкретного экспорта, резервного копирования и режима модуля должны проверяться по полному применимому профилю отдельно.
Сведения о модуле подтверждают только часть организации защиты ключа. Полномочия участников, профиль выпуска, журнал и процедуры управления проверяют отдельно; само наличие модуля не доказывает невозможность ошибочно разрешённой подписи.
Граница применимости: Практический вывод из обязательных отдельных мер CA/Browser Forum 6.1.1.1 и управления ключами NIST SP 800-57 Part 2. Не утверждает неизвлекаемость ключа без проверки конкретного режима.
Граница терминов
Не путать
Запрос конечного заявителя и создание ключа CA относятся к разным участникам. Требования к церемонии ключа центра не переносятся автоматически на любой CSR.
Перед спецификацией
Что проверить
- Определите профиль PKI и роль центра.
- Сверьте требования с политикой и регламентом центра.
- Проверьте защищённую среду, доверенные роли и контроль несколькими участниками.
- Зафиксируйте модель, версию и применимый режим модуля.
- Проверьте журнал и требуемые материалы церемонии.
- Установите разрешённую защиту материала вне модуля.
- Проверяйте полномочия на подпись отдельно от защиты ключевых байтов.
Открытые основания
Первоисточники
Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates
CA/Browser Forum · Server Certificate BR: проверенный редактором срез 8 сентября 2026 года
Редакторские выписки из 6.3.2, 1.6.1, 6.1.1.1 и 6.2. Номер редакции и commit среза не предоставлены; уровень модуля по 6.2.7 не проверен.
Открыть первоисточникRecommendation for Key Management: Part 2 — Best Practices for Key Management Organizations
National Institute of Standards and Technology · NIST SP 800-57 Part 2 Rev. 1, March 2019
Описывает organizational key-management practices, CA/RA roles, PKI operations и certification path building.
Открыть первоисточникInternet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile
Internet Engineering Task Force · RFC 5280, May 2008
Определяет Internet X.509 certificate и CRL profiles, PKI entities, extensions и certification path validation.
Открыть первоисточникPKCS #10: Certification Request Syntax Specification Version 1.7
Internet Engineering Task Force · RFC 2986, November 2000
Определяет структуру PKCS #10 CSR и подпись request information private key заявителя.
Открыть первоисточник