Требования к программе - Программа доверенных корневых сертификатов Майкрософт

  • Статья

1. Введение

Программа корневых сертификатов Microsoft поддерживает распространение корневых сертификатов, позволяя клиентам доверять продукции Windows. На данной странице описаны общие и технические требования Программы.

Примечание.

  • Для получения информации о самых последних поставленных обновлениях см. https://aka.ms/rootupdates
  • Добавьте данную страницу в закладки как: https://aka.ms/RootCert

2. Постоянные требования программы

Требования аудита

  1. Участники программы должны предоставить Майкрософт свидетельство Квалифицированного аудита (см. https://aka.ms/auditreqs) для каждого корневого, неограниченного подчиненного ЦС и перекрестно подписанного сертификата до начала коммерческих операций, а затем на ежегодной основе.
  2. Участники программы должны взять на себя ответственность за обеспечение соответствия всех неограниченных подчиненных центров сертификации и перекрестно подписанных сертификатов Требованиям аудита программы.
  3. Центры сертификации должны публично раскрывать все отчеты аудита для неограниченных подчиненных центров сертификации.
  4. Поставщики ЦС должны убедиться, что их корневые ЦС с поддержкой S/MIME и все подчиненные ЦС, способные выдавать сертификаты S/MIME, будут проверяться в отношении последней версии, как минимум, одного из следующих наборов критериев. Этот аудит должен выполняться по крайней мере один раз в год. Начальный период аудита должен начинаться не позднее 1 сентября 2023 года.
    • Принципы и критерии WebTrust для центров сертификации — S/MIME
    • ETSI EN 119 411-6 LCP, NCP или NCP+

Требования к коммуникации и раскрытию информации

  1. Участники Программы должны предоставить Microsoft идентификационные данные по крайней мере двух «Доверенных агентов», которые выступают в качестве представителей Программы, и один общий псевдоним электронной почты. Участники программы должны сообщить Майкрософт об удалении или добавлении персонала в качестве доверенного агента. Участники программы соглашаются получать уведомления по электронной почте и должны предоставить Майкрософт адрес электронной почты для получения официальных уведомлений. Участники программы должны согласиться с тем, что уведомление вступает в силу, когда Майкрософт отправляет электронное или официальное письмо. По крайней мере, один из предоставленных контактов или псевдонимов должен быть круглосуточным контролируемым каналом связи для запросов на отзыв или других ситуаций управления инцидентами.

  2. Участник программы должен ежегодно раскрывать Microsoft полную иерархию PKI (неограниченный подчиненный ЦС, перекрестно подписанные незарегистрированные корневые ЦС, подчиненные ЦС, EKU, ограничения сертификатов), включая сертификаты, выданные ЦС, управляемым внешними третьими сторонами в рамках CCADB. Участники программы должны хранить эту информацию в CCADB в точности, когда происходят изменения. Если подчиненный ЦС не раскрывается или не проверяется публично, он должен быть ограничен доменом.

  3. Участники программы должны проинформировать Майкрософт по электронной почте не менее чем за 120 дней до передачи права собственности на зарегистрированный корневой или подчиненный ЦС, который связан с зарегистрированным корневым центром, другому юридическому или физическому лицу.

  4. Код причины должен быть включен в отзывы для промежуточных сертификатов. При отзыве любых промежуточных сертификатов центры сертификации должны обновить CCADB в течение 30 дней.

  5. Участники программы соглашаются с тем, что Майкрософт может связываться с клиентами, на которых, по мнению Майкрософт, может существенно повлиять ожидающее удаление корневого центра сертификации из Программы.

Прочие требования

  1. Коммерческие ЦС не могут регистрировать корневой ЦС в Программе, которая предназначена в первую очередь для внутреннего доверия внутри организации (т. е. ЦС предприятия).

  2. Если ЦС использует субподрядчика для управления каким-либо аспектом своего бизнеса, ЦС берет на себя ответственность за бизнес-операции субподрядчика.

  3. Если корпорация Майкрософт, на своем усмотрении, определяет сертификат, использование или атрибуты которого определяются как противоположные целям доверенной корневой программы, корпорация Майкрософт уведомит ответственный ЦС и запросит, что он отменяет сертификат. Центр сертификации должен либо отозвать сертификат, либо запросить исключение у Майкрософт в течение 24 часов с момента получения уведомления Майкрософт. Майкрософт рассмотрит представленные материалы и сообщит ЦС о своем окончательном решении предоставить или отклонить исключение по своему собственному усмотрению. Если Майкрософт не предоставляет исключение, центр сертификации должен отозвать сертификат в течение 24 часов после отклонения исключения.

3. Технические требования к программе

Все центры сертификации в программе должны соответствовать Техническим требованиям программы. Если Майкрософт определит, что ЦС не соответствует приведенным ниже требованиям, Майкрософт исключит данный ЦС из Программы.

А. Требования к корневому сертификату

  1. Корневые сертификаты должны быть сертификатами x.509 версии 3.
    1. Атрибут CN должен идентифицировать издателя и быть уникальным.
    2. Атрибут CN должен быть на языке, который подходит для рынка CA и читается типичным покупателем на этом рынке.
    3. Расширение базовых ограничений: значение должно быть cA = true.
    4. Расширение использования ключа ДОЛЖНО присутствовать и ДОЛЖНО быть помечено как критически важное. ДОЛЖНЫ быть установлены битовые позиции для KeyCertSign и cRLSign. Если закрытый ключ корневого CA используется для подписи ответов OCSP, то ДОЛЖЕН быть установлен бит digitalSignature.
      • Размеры корневых ключей должны соответствовать требованиям, описанным в разделе "Ключевые требования".
  2. Сертификаты, добавляемые в доверенное корневое хранилище, ДОЛЖНЫ быть самозаверяющими корневыми сертификатами.
  3. Новоиспеченные корневые ЦС должны быть действительными как минимум на восемь лет, и не более 25 лет с даты отправки.
  4. Участвующие корневые центры сертификации не могут выдавать новые 1024-битные сертификаты RSA от корневых центров, на которые распространяются указанные требования.
  5. Все сертификаты конечных объектов должны содержать расширение AIA с действительным URL-адресом OCSP. Данные сертификаты также могут содержать расширение CDP, которое содержит действительный URL-адрес CRL. Все остальные типы сертификатов должны содержать либо расширение AIA с URL-адресом OCSP, либо расширение CDP с действительным URL-адресом CRL
  6. Закрытые ключи и имена субъектов должны быть уникальными для каждого корневого сертификата; повторное использование закрытых ключей или имен субъектов в последующих корневых сертификатах одним и тем же ЦС может привести к неожиданным проблемам с цепочкой сертификатов. Центры сертификации должны сгенерировать новый ключ и применить новое имя субъекта при создании нового корневого сертификата перед его распространением корпорацией Майкрософт.
  7. Центры сертификации государственных организаций должны ограничить проверку подлинности сервера доменами верхнего уровня, выданными правительством, и могут выдавать только другие сертификаты в коды стран ISO3166, над которыми страна имеет суверенный контроль (см https://aka.ms/auditreqs . раздел III определения "ЦС правительства"). Данные TLD, выданные правительственными органами, упоминаются в соответствующем контракте каждого ЦС.
  8. Выдача сертификатов ЦС, связанных с участвующим корневым ЦС, должна разделять использование проверки подлинности сервера, S/MIME, подписи кода и меток времени. Это означает, что один выдающий ЦС не должен сочетать проверку подлинности сервера с S/MIME, подписыванием кода или меткой времени EKU. Для каждого варианта использования необходимо использовать отдельный промежуточный продукт.
  9. Сертификаты конечных объектов должны соответствовать требованиям к типу алгоритма и размеру ключа для сертификатов подписчика, перечисленным в Приложении A Базовых требований CAB Forum, расположенных по адресу https://cabforum.org/baseline-requirements-documents/.
  10. Центры сертификации должны объявлять один из следующих идентификаторов политики в сертификате конечной сущности расширения политики сертификатов.
    1. DV 2.23.140.1.2.1.
    2. OV 2.23.140.1.2.2.
    3. EV 2.23.140.1.1.
    4. IV 2.23.140.1.2.3.
    5. Подписывание кода, отличного от EV 2.23.140.1.4.1.
  11. Начиная с августа 2024 года все пользовательские OID SSL EV, управляемые доверенной корневой программой, будут удалены и заменены на CA/B Forum, совместимые с SSL OID (2.23.140.1.1.1). Команда Microsoft Edge будет реализовывать проверка для OID SSL EV (2.23.140.1.1.1) в браузере, поэтому другие ssl-идентификаторы EV больше не будут приниматься, чтобы выровняться с Edge и избегать несовместимости.
  12. ЦС могут иметь не более 2 OID, примененных к корневому сертификату.
  13. Сертификаты конечных объектов, которые включают расширение базовых ограничений в соответствии с IETF RFC 5280, должны иметь поле cA, установленное на FALSE, а поле pathLenConstraint должно отсутствовать.
  14. ЦС должен технически ограничивать ответчик OCSP таким образом, чтобы единственным разрешенным EKU была подпись OCSP.
  15. Центр сертификации должен иметь возможность отозвать сертификат до определенной даты по запросу Майкрософт.

B. Требования к подписи

Алгоритм Все виды использования, за исключением подписи кода и отметки времени Использование подписи кода и отметки времени
Алгоритмы дайджеста SHA2 (SHA256, SHA384, SHA512) SHA2 (SHA256, SHA384, SHA512)
RSA 2048 4096 (только новые корни)
ECC / ECDSA NIST P-256, P-384, P-521 NIST P-256, P-384, P-521

Обратите внимание: подписи с помощью эллиптической кривой шифрования (ECC), например ECDSA, не поддерживаются в Windows и более новых функциях безопасности Windows. Пользователи, использующие эти алгоритмы и сертификаты, сталкиваются с различными ошибками и потенциальными рисками безопасности. Программа доверенных корневых служб Майкрософт рекомендует не выдавать сертификаты ECC/ECDSA подписчикам из-за этой известной несовместимости и риска.

C. Требования к отзыву

  1. Центры сертификации должны иметь документированную политику отзыва и иметь возможность отзыва любого сертификата, который он выдает.
  2. Центры сертификации, которые выдают сертификаты проверки подлинности сервера, должны поддерживать оба следующих требования ответа OCSP:
    1. Минимальная допустимость восьми часов (8) часов; максимальный срок действия в семь (7) дней.
    2. Следующее обновление должно быть доступно как минимум за восемь (8) часов до истечения текущего периода. Если срок действия превышает 16 часов, то следующее обновление должно быть доступно через ½ периода действия.
  3. Все сертификаты, выданные корневым центром сертификации, должны поддерживать расширение точки распространения CRL и/или AIA, содержащую URL-адрес ответчика OCSP.
  4. ЦС не должен использовать корневой сертификат для выдачи сертификатов конечных объектов.
  5. Если центр сертификации выдает сертификаты подписи кода, он должен использовать центр меток времени, соответствующий RFC 3161, «Протокол временных меток инфраструктуры открытых ключей Интернета X.509».

D. Требования к корневому сертификату для подписи кода

  1. Корневые сертификаты, поддерживающие использование подписи кода, могут быть удалены Программой из распространения через 10 лет с даты распространения заменяющего корневого сертификата одновременного нажатия клавиш или раньше, если этого потребует ЦС.
  2. Корневые сертификаты, которые остаются в дистрибутиве для поддержки использования только подписи кода после срока их защиты алгоритма (например, RSA 1024 = 2014, RSA 2048 = 2030), могут быть отключены в ОС Windows 10.
  3. Начиная с февраля 2024 года корпорация Майкрософт больше не будет принимать или распознавать сертификаты подписывания кода EV, а CCADB перестанет принимать аудит подписывания кода EV. Начиная с августа 2024 года все идентификаторы подписывания кода EV будут удалены из существующих корней в доверенной корневой программе Майкрософт, а все сертификаты подписывания кода будут рассматриваться одинаково.

Е. Требования EKU

  1. Центры сертификации должны предоставить бизнес-обоснование для всех EKU, назначенных их корневому сертификату. Обоснование может быть в форме публичного свидетельства текущего бизнеса по выдаче сертификатов определенного типа или типов или бизнес-плана, демонстрирующего намерение выпустить эти сертификаты в ближайшем будущем (в течение одного года с момента распространения корневых сертификатов Программой).

  2. Майкрософт будет включать только следующие EKU:

    1. Проверка подлинности сервера = 1.3.6.1.5.5.7.3.1
    2. Проверка подлинности клиента = 1.3.6.1.5.5.7.3.2
    3. Защищенная электронная почта EKU = 1.3.6.1.5.5.7.3.4
    4. Отметка времени EKU = 1.3.6.1.5.5.7.3.8
    5. Подписание документа EKU = 1.3.6.1.4.1.311.10.3.12
    • Данный EKU используется для подписания документов в Office. Это не требуется для других целей подписания документов.

F. Требования к подписи кода режима ядра Windows 10 (KMCS)

Windows 10 предъявляет повышенные требования к проверке драйверов режима ядра. Драйверы должны быть подписаны как Microsoft, так и партнером по программе с использованием требований расширенной проверки. Все разработчики, которые хотят, чтобы их драйверы режима ядра были включены в Windows, должны следовать процедурам, изложенным группой разработки оборудования Майкрософт. Дополнительные сведения см. в Центре партнеров для оборудования Windows.