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

1. Введение

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

Примечание

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

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

  1. Участники программы должны предоставлять корпорации Майкрософт доказательства квалифицированного аудита ( https://aka.ms/auditreqsсм. ) для каждого корневого, неподдерживанного подчиненного ЦС и сертификата с перекрестной подписью, перед проведением коммерческих операций, а затем в дальнейшем на ежегодной основе.
  2. Участники программы должны взять на себя ответственность за то, чтобы все неподдержанные подчиненные ЦС и сертификаты с перекрестной подписью соответствуют требованиям аудита программы.
  3. ЦС должны публично раскрыть все отчеты аудита для неподдержанных подчиненных ЦС.

Требования к связи и раскрытию данных

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

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

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

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

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

Другие требования

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

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

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


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

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

A. Корневые требования

  1. Корневые сертификаты должны иметь сертификаты X.509 v3.
    1. Атрибут CN должен определять издателя и быть уникальным.
    2. Атрибут CN должен быть языком, подходящим для рынка ЦС и читаемым типичным клиентом на этом рынке.
    3. Расширение базовых ограничений: должно быть cA=true.
    4. Расширение "Использование ключа" ДОЛЖНО быть присутствует, и его необходимо пометить как критическое. Позиции бита для keyCertSign и cRLSign ДОЛЖНЫ быть установлены. Если для подписания ответов OCSP используется закрытый ключ корневого ЦС, необходимо установить бит digitalSitureture.
      • Размер корневого ключа должен соответствовать требованиям, подробным в "Требованиях к ключам".
  2. Сертификаты, которые нужно добавить в доверенный корневой магазин, должны быть самозаверять корневые сертификаты.
  3. Новые корневые ЦС должны быть действительны не менее 8 лет и не более 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 базового плана на форуме, https://cabforum.org/baseline-requirements-documents/расположенном по адресу .
  10. ЦС должны объявить одну из следующих политик OIDs в сертификате конечной сущности расширения политики сертификатов:
    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.3
    6. Подписывка 2.23.140.1.4.1 без кода ОО
  11. Сертификаты конечных организаций, которые включают расширение Basic Constraints в соответствии с IETF RFC 5280, должны иметь значение ЛОЖЬ для поля cA, а поле pathLenConstraint должно быть отсутствовать.
  12. ЦС должен технически ограничить возможности средства ответа OCSP таким образом, чтобы единственным разрешенным EKU было подписание OCSP.
  13. ЦС должен иметь возможность отопросить сертификат до определенной даты, как это запрашивается корпорацией Майкрософт.

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

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

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

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

  1. Корневые сертификаты, которые поддерживают использование подписи кода, могут быть удалены из распространения программой через 10 лет с даты распространения нового корневого сертификата при запросе ЦС.
  2. Корневые сертификаты, которые остаются в распространении для поддержки только подписи кода, используют вне срока действия алгоритма защиты (например, RSA 1024 = 2014, RSA 2048 = 2030) может быть настроено на отключение в Windows 10 OS.

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

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

  2. Корпорация Майкрософт включает только следующие продукты EKUs:

    1. Проверка подлинности сервера =1.3.6.1.5.5.7.3.1
    2. Проверка подлинности клиента =1.3.6.1.5.5.7.3.2
    3. Secure EKU электронной почты=1.3.6.1.5.5.7.3.4
    4. Time stamping 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 требования к проверке драйверов в режиме ядра. Драйверы должны быть подписаны корпорацией Майкрософт и партнером программы с помощью расширенных требований к проверке. Все разработчики, которые хотят включить в Windows драйверы в режиме ядра, должны следовать процедурам, описанным командой разработчиков оборудования Корпорации Майкрософт. Документацию по программам можно найти здесь