Требования к программе — программа доверенного корня МайкрософтProgram Requirements - Microsoft Trusted Root Program

1. Введение1. Introduction

Программа корневых сертификатов Майкрософт поддерживает распределение корневых сертификатов, позволяя клиентам доверять продуктам Windows.The Microsoft Root Certificate Program supports the distribution of root certificates, enabling customers to trust Windows products. На этой странице описываются общие и технические требования программы.This page describes the Program's general and technical requirements.

Примечание

2. продолжение выполнения требований программы2. Continuing Program Requirements

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

  1. Участники программы должны предоставить корпорации Майкрософт свидетельство квалифицированного аудита (см. https://aka.ms/auditreqs ) для каждого корневого, неограниченного подчиненного ЦС и межзнакового сертификата, прежде чем выполнять коммерческие операции и затем ежегодно.Program Participants must provide to Microsoft evidence of a Qualified Audit (see https://aka.ms/auditreqs) for each root, unconstrained subordinate CA, , and cross-signed certificate, before conducting commercial operations and thereafter on an annual basis.
  2. Участники программы должны принять ответственность за то, чтобы все неограниченные подчиненные ЦС и сертификаты с перекрестной подписью соответствовали требованиям аудита программы.Program Participants must assume responsibility to ensure that all unconstrained subordinate CAs and cross-signed certificates meet the Program Audit Requirements.
  3. CAs должен публично раскрывать все отчеты аудита о неограниченных подчиненных ЦС.CAs must publicly disclose all audit reports for unconstrained subordinate CAs.

Требования к связи и раскрытиюCommunication and Disclosure Requirements

  1. Участники программы должны предоставить корпорации Майкрософт удостоверения по крайней мере двух надежных агентов, чтобы служить представителями программы и одним общим псевдонимом электронной почты.Program Participants must provide Microsoft the identities of at least two "Trusted Agents" to serve as representatives to the Program and one general email alias. Участники программы должны сообщать корпорации Майкрософт об удалении или добавлении персонала в качестве доверенного агента.Program Participants must inform Microsoft upon the removal or addition of personnel as a Trusted Agent. Участники программы согласны получить уведомления по электронной почте и должны предоставить корпорации Майкрософт адрес электронной почты для получения официальных уведомлений.Program Participants agree to receive notices by e-mail and must provide Microsoft with an email address to receive official notices. Участники программы должны согласиться с тем, что уведомление вступает в силу, когда корпорация Майкрософт отправляет электронное письмо или официальное письмо.Program Participants must agree that notice is effective when Microsoft sends an email or official letter. По крайней мере один из указанных контактов или псевдонимов должен быть каналом связи с отслеживанием 24/7 для запросов отзыва или других ситуаций управления инцидентами.At least one of the contacts or aliases provided should be a 24/7 monitored communications channel for revocation requests or other incident management situations.

  2. Участник программы должен раскрывать свою полную иерархию PKI (не ограниченный подчиненный ЦС, незарегистрированные корневые центры сертификации, подчиненные ЦС, EKU, ограничения сертификата) в корпорацию Майкрософт, включая сертификаты, выданные ЦС, которые используются внешними сторонними сторонами в ККАДБ.The Program Participant must disclose its full PKI hierarchy (non-limited subordinate CA, cross-signed non-enrolled root CAs, subordinate CAs, EKUs, certificate constraints) to Microsoft on an annual basis, including certificates issued to CAs operated by external third parties within the CCADB. Участники программы должны точно держать эти сведения в ККАДБ, когда происходят изменения.Program Participants must keep this information accurate in the CCADB when changes occur. Если подчиненный ЦС не был открыт или подлежит аудиту, он должен быть ограничен доменами.If a subordinate CA is not publicly disclosed or audited, it must be domain-constrained.

  3. Участники программы должны сообщать корпорации Майкрософт по электронной почте не менее 120 дней, прежде чем передавать владение зарегистрированным корневым или подчиненным ЦС, связанным с зарегистрированным корнем, другим лицом или человеком.Program Participants must inform Microsoft via email at least 120 days before transferring ownership of enrolled root or subordinate CA that chains to an enrolled root to another entity or person.

  4. Код причины должен быть добавлен в отзыв для промежуточных сертификатов.Reason Code must be included in revocations for intermediate certificates. CAs должен обновлять ККАДБ при отмене каких бы то ни было промежуточных сертификатов в течение 30 дней.CAs must update the CCADB when revoking any intermediate certificates within 30 days.

  5. Участники программы согласились с тем, что корпорация Майкрософт может обращаться к клиентам, которые, возможно, могут оказать существенное влияние на удаление корневого центра сертификации из программы.Program Participants agree that Microsoft may contact customers that Microsoft believes may be substantially impacted by the pending removal of a root CA from the Program.

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

  1. Коммерческие центры сертификации могут не регистрировать корневой ЦС в программе, которая должна быть в основном доверенной для внутреннего использования внутри организации (т. е. ЦС предприятия).Commercial CAs may not enroll a root CA into the Program that is intended to be primarily trusted internally within an organization (i.e. Enterprise CAs).

  2. Если центр сертификации использует субподрядчик для работы с любыми аспектами своего бизнеса, центр сертификации несет ответственность за бизнес-операции субподрядчика.If a CA uses a subcontractor to operate any aspect of its business, the CA will assume responsibility for the subcontractor's business operations.

  3. Если корпорация Майкрософт по собственному усмотрению определяет сертификат, использование или атрибуты которого не влияют на цели доверенной корневой программы, корпорация Майкрософт будет уведомлять ответственный ЦС и запросить отзыв сертификата.If Microsoft, in its sole discretion, identifies a certificate whose usage or attributes are determined to be contrary to the objectives of the Trusted Root Program, Microsoft will notify the responsible CA and request that it revoke the certificate. Центр сертификации должен отозвать сертификат или запросить исключение от корпорации Майкрософт в течение 24 часов после получения уведомления от Майкрософт.The CA must either revoke the certificate or request an exception from Microsoft within 24 hours of receiving Microsoft's notice. Корпорация Майкрософт просматривает отправленные материалы и уведомляет центр сертификации о его окончательном решении, чтобы предоставить или отклонить исключение по своему усмотрению.Microsoft will review submitted material and inform the CA of its final decision to grant or deny the exception at its sole discretion. В случае, если корпорация Майкрософт не предоставляет исключение, центр сертификации должен отозвать сертификат в течение 24 часов, если исключение запрещено.In the event that Microsoft does not grant the exception, the CA must revoke the certificate within 24 hours of the exception being denied.


3. технические требования для программы3. Program Technical Requirements

Все ЦС в программе должны соответствовать техническим требованиям программы.All CAs in the Program must comply with the Program Technical Requirements. Если корпорация Майкрософт определяет, что центр сертификации не соответствует приведенным ниже требованиям, корпорация Майкрософт исключит этот ЦС из программы.If Microsoft determines that a CA is not in compliance with the below requirements, Microsoft will exclude that CA from the Program.

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

  1. Корневые сертификаты должны быть сертификатами x. 509 v3.Root certificates must be x.509 v3 certificates.
    1. Атрибут CN должен определять издателя и должен быть уникальным.The CN attribute must identify the publisher and must be unique.
    2. Атрибут CN должен быть на языке, подходящем для рынка ЦС и читаемом обычным клиентом на этом рынке.The CN attribute must be in a language that is appropriate for the CA's market and readable by a typical customer in that market.
    3. Расширение "Основные ограничения": должно быть cA = true.Basic Constraints extension: must be cA=true.
    4. ДОЛЖНО быть указано расширение использования ключа, которое должно быть помечено как критическое.Key Usage extension MUST be present and MUST be marked critical. НЕОБХОДИМО задать битовые позиции для Кэйцертсигн и Крлсигн.Bit positions for KeyCertSign and cRLSign MUST be set. Если закрытый ключ корневого ЦС используется для подписи ответов OCSP, необходимо установить бит Дигиталсигнатуре.If the Root CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set.
      • Размеры корневых ключей должны соответствовать требованиям, описанным в разделе "требования к ключам".Root Key Sizes must meet the requirements detailed in "Key Requirements".
  2. Сертификаты, добавляемые в доверенное корневое хранилище, должны быть самозаверяющими корневыми сертификатами.Certificates to be added to the Trusted Root Store MUST be self-signed root certificates.
  3. Новые корневые центры сертификации подписывая должны быть допустимыми в течение не менее 8 лет и не более 25 лет с даты отправки.Newly minted Root CAs must be valid for a minimum of 8 years, and a maximum of 25 years, from the date of submission.
  4. Участвующие корневые ЦС могут не выдавать новые 1024-разрядные сертификаты RSA из корней, охваченных этими требованиями.Participating Root CAs may not issue new 1024-bit RSA certificates from roots covered by these requirements.
  5. Все сертификаты конечного объекта должны содержать расширение AIA с допустимым URL-адресом OCSP.All end-entity certificates must contain an AIA extension with a valid OCSP URL. Эти сертификаты также могут содержать расширение CDP, которое содержит допустимый URL-адрес списка отзыва сертификатов.These certificates may also contain a CDP extension that contains a valid CRL URL. Все остальные типы сертификатов должны содержать расширение AIA с URL-адресом OCSP или расширением CDP с допустимым URL-адресом списка отзыва сертификатов.All other certificate types must contain either an AIA extension with an OCSP URL or a CDP extension with a valid CRL URL
  6. Закрытые ключи и имена субъектов должны быть уникальными для каждого корневого сертификата. повторное использование закрытых ключей или имен субъектов в последующих корневых сертификатах одного ЦС может привести к непредвиденным проблемам с цепочкой сертификатов.Private Keys and subject names must be unique per root certificate; reuse of private keys or subject names in subsequent root certificates by the same CA may result in unexpected certificate chaining issues. ЦС должен создать новый ключ и применить новое имя субъекта при создании нового корневого сертификата перед распространением корпорацией Майкрософт.CAs must generate a new key and apply a new subject name when generating a new root certificate prior to distribution by Microsoft.
  7. Центры сертификации для государственных организаций должны ограничивать проверку подлинности сервера для доменов верхнего уровня и могут выдавать только другие сертификаты для кодов стран ISO3166, которые независимых контролировать (см https://aka.ms/auditreqs . раздел III для определения "центра сертификации для государственных организаций").Government CAs must restrict server authentication to government-issued top level domains and may only issue other certificates to the ISO3166 country codes that the country has sovereign control over (see https://aka.ms/auditreqs section III for the definition of a "Government CA"). Эти доменов, выданные правительственными органами, упоминаются в соответствующем контракте каждого ЦС.These government-issued TLDs are referred to in each CA's respective contract.
  8. Выдача сертификатов ЦС, которые связаны с корневым ЦС, должны разделять проверку подлинности сервера, S/MIME, подписывание кода и отметку времени.Issuing CA certificates that chain to a participating Root CA must separate Server Authentication, S/MIME, Code Signing, and Time Stamping uses. Это означает, что один выдающий ЦС не должен сочетать проверку подлинности сервера с S/MIME, подписью кода или EKU отметки времени.This means that a single Issuing CA must not combine server authentication with S/MIME, code signing or time stamping EKU. Для каждого варианта использования должен использоваться отдельный промежуточный уровень.A separate intermediate must be used for each use case.
  9. Сертификаты конечного субъекта должны соответствовать требованиям к типу алгоритма и размеру ключа для сертификатов подписчиков, перечисленных в приложении а о базовых требованиях на форуме CAB-файлов, расположенных по адресу https://cabforum.org/baseline-requirements-documents/ .End-entity certificates must meet the requirements for algorithm type and key size for Subscriber certificates listed in Appendix A of the CAB Forum Baseline Requirements located at https://cabforum.org/baseline-requirements-documents/.
  10. CAs должен объявить один из следующих идентификаторов OID политики для сертификата конечного субъекта расширения политики сертификатов:CAs must declare one of the following policy OIDs in its Certificate Policy extension end-entity certificate:
    1. DV 2.23.140.1.2.1DV 2.23.140.1.2.1
    2. OV 2.23.140.1.2.2OV 2.23.140.1.2.2
    3. EV 2.23.140.1.1.EV 2.23.140.1.1.
    4. IV 2.23.140.1.2.3IV 2.23.140.1.2.3
    5. 2.23.140.1.3 подписывания кода EVEV Code Signing 2.23.140.1.3
    6. 2.23.140.1.4.1 подписывания кода без EVNon-EV Code Signing 2.23.140.1.4.1
  11. Сертификаты конечных сущностей, включающие расширение базовых ограничений в соответствии с IETF RFC 5280, должны иметь значение FALSE для поля cA, а поле Пасленконстраинт должно отсутствовать.End-entity certificates that include a Basic Constraints extension in accordance with IETF RFC 5280 must have the cA field set to FALSE and the pathLenConstraint field must be absent.
  12. Центр сертификации должен технически ограничивать ответчик OCSP, так что единственным допустимым EKU является подписывание OCSP.A CA must technically constrain an OCSP responder such that the only EKU allowed is OCSP Signing.
  13. Центр сертификации должен иметь возможность отзывать сертификат на определенную дату согласно запросу корпорации Майкрософт.A CA must be able to revoke a certificate to a specific date as requested by Microsoft.

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

АлгоритмAlgorithm Все применения, за исключением подписывания кода и отметок времениAll Uses Except for Code Signing and Time Stamping Использование подписи кода и отметок времениCode Signing and Time Stamping Use
Алгоритмы дайджестаDigest Algorithms SHA2 (SHA256, SHA384, SHA512)SHA2 (SHA256, SHA384, SHA512) SHA2 (SHA256, SHA384, SHA512)SHA2 (SHA256, SHA384, SHA512)
RSARSA 20482048 4096 (только для новых корней)4096 (New roots only)
ECC/ECDSAECC / ECDSA ДИРЕКТИВА NIST P-256, P-384, P-521NIST P-256, P-384, P-521 ДИРЕКТИВА NIST P-256, P-384, P-521NIST P-256, P-384, P-521

В.C. Требования отзываRevocation Requirements

  1. Центр сертификации должен иметь документированную политику отзыва и должен иметь возможность отзывать все вызываемые сертификаты.The CA must have a documented revocation policy and must have the ability to revoke any certificate it issues.
  2. Центры сертификации, выдающие сертификаты проверки подлинности сервера, должны поддерживать следующие требования к ответчику OCSP:CAs that issue Server Authentication certificates must support the following OCSP responder requirements:
    1. Минимальная допустимость в 8 (8) часах; Максимальная допустимая продолжительность семь (7) дней; перетаскиваниMinimum validity of eight (8) hours; Maximum validity of seven (7) days; and
    2. Следующее обновление должно быть доступно по крайней мере из восьми (8) часов до истечения текущего периода.The next update must be available at least eight (8) hours before the current period expires. Если срок действия превышает 16 часов, то следующее обновление должно быть доступно в 1/2 периода действия.If the validity is more than 16 hours, then the next update must be available at ½ of the validity period.
  3. Все сертификаты, выданные корневым ЦС, должны поддерживать расширение точки распространения списков отзыва сертификатов и (или) AIA, содержащие URL-адрес ответчика OCSP.All certificates issued from a root CA must support either the CRL distribution point extension and/or AIA containing an OCSP responder URL.
  4. ЦС не должен использовать корневой сертификат для выдаче сертификатов конечных сущностей.The CA must not use the root certificate to issue end-entity certificates.
  5. Если центр сертификации выдает сертификаты для подписи кода, он должен использовать центр меток времени, соответствующий стандарту RFC 3161, "Internet X. 509 инфраструктуры открытого ключа Time-Stamp Protocol (TSP)".If a CA issues Code Signing certificates, it must use a Time Stamp Authority that complies with RFC 3161, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)."

Г.D. Требования к корневому сертификату подписывания кодаCode Signing Root Certificate Requirements

  1. Корневые сертификаты, которые поддерживают использование подписывания кода, могут быть удалены из распространения программой через 10 лет с момента распространения замещающего корневого сертификата смены или более ранних, если запрошены центром сертификации.Root certificates that support code signing use may be removed from distribution by the Program 10 years from the date of distribution of a replacement rollover root certificate or sooner, if requested by the CA.
  2. Корневые сертификаты, которые остаются в дистрибутиве, поддерживают только использование подписывания кода за пределами жизненного цикла безопасности алгоритма (например, RSA 1024 = 2014, RSA 2048 = 2030) в ОС Windows 10 могут иметь значение Disable.Root certificates that remain in distribution to support only code signing use beyond their algorithm security lifetime (e.g. RSA 1024 = 2014, RSA 2048 = 2030) may be set to 'disable' in the Windows 10 OS.

Д.E. Требования к расширению EKUEKU Requirements

  1. Центры сертификации должны предоставлять Деловое обоснование для всех EKU, назначенных их корневому сертификату.CAs must provide a business justification for all of the EKUs assigned to their root certificate. Обоснование может быть общедоступным свидетельством текущего бизнеса выдачи сертификатов типа или типов или бизнес-планом, демонстрирующим намерение выдачи этих сертификатов в ближайшем термине (в течение одного года с распределением корневого сертификата программой).Justification may be in the form of public evidence of a current business of issuing certificates of a type or types, or a business plan demonstrating an intention to issue those certificates in the near term (within one year of root certificate distribution by the Program).

  2. Корпорация Майкрософт будет включать только следующие расширения EKU:Microsoft will only enable the following EKUs:

    1. Проверка подлинности сервера = 1.3.6.1.5.5.7.3.1Server Authentication =1.3.6.1.5.5.7.3.1
    2. Проверка подлинности клиента = 1.3.6.1.5.5.7.3.2Client Authentication =1.3.6.1.5.5.7.3.2
    3. Безопасное письмо EKU = 1.3.6.1.5.5.7.3.4Secure E-mail EKU=1.3.6.1.5.5.7.3.4
    4. EKU меток времени = 1.3.6.1.5.5.7.3.8Time stamping EKU=1.3.6.1.5.5.7.3.8
    5. EKU для подписи документов = 1.3.6.1.4.1.311.10.3.12Document Signing EKU=1.3.6.1.4.1.311.10.3.12
    • Это EKU используется для подписывания документов в офисе.This EKU is used for signing documents within Office. Он не требуется для других подписывания документа.It is not required for other document signing uses.

Е.F. Требования подписывания кода режима ядра Windows 10 (КМКС)Windows 10 Kernel Mode Code Signing (KMCS) Requirements

Windows 10 обладает повышенными требованиями для проверки драйверов в режиме ядра.Windows 10 has heightened requirements to validate kernel-mode drivers. Драйверы должны быть подписаны как корпорацией Майкрософт, так и партнером программы с помощью расширенных требований к проверке.Drivers must be signed by both Microsoft and a Program partner using Extended Validation requirements. Все разработчики, желающие использовать драйверы режима ядра в Windows, должны следовать процедурам, описанным в группе разработчиков оборудования Майкрософт.All developers who wish to have their kernel-mode drivers included in Windows must follow the procedures outlined by the Microsoft Hardware Development Team. Документацию по программе можно найти здесь .Program documentation can be found here