プログラムの要件-Microsoft 信頼されたルートプログラムProgram Requirements - Microsoft Trusted Root Program

1.はじめに1. Introduction

Microsoft ルート証明書プログラムでは、ルート証明書の配布がサポートされているため、お客様は 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 商用業務を実施する前に、各ルート、制限のない下位 CA、、およびクロス署名証明書について、Microsoft が認定した監査 (を参照) に提供する必要があります。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. プログラムの参加者は、制限のないすべての下位 Ca とクロス署名証明書がプログラムの監査要件を満たしていることを前提としている必要があります。Program Participants must assume responsibility to ensure that all unconstrained subordinate CAs and cross-signed certificates meet the Program Audit Requirements.
  3. Ca は、無制限の下位 Ca のすべての監査レポートを公開する必要があります。CAs must publicly disclose all audit reports for unconstrained subordinate CAs.

通信と開示の要件Communication and Disclosure Requirements

  1. プログラムの参加者は、少なくとも2つの "信頼されたエージェント" の id を Microsoft に提供して、プログラムの代表者として、また一般的な電子メールエイリアスを提供する必要があります。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. プログラムの参加者は、信頼されたエージェントとしての担当者の削除または追加について Microsoft に通知する必要があります。Program Participants must inform Microsoft upon the removal or addition of personnel as a Trusted Agent. プログラムの参加者は、電子メールによる通知の受信に同意し、正式な通知を受け取るために Microsoft に電子メールアドレスを提供する必要があります。Program Participants agree to receive notices by e-mail and must provide Microsoft with an email address to receive official notices. プログラムの参加者は、Microsoft が電子メールまたは公式レターを送信するときに、通知が有効であることに同意する必要があります。Program Participants must agree that notice is effective when Microsoft sends an email or official letter. 指定された連絡先またはエイリアスの少なくとも1つは、失効要求またはその他のインシデント管理状況に対して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. プログラムの参加者は、CCADB 内の外部サードパーティが運用する Ca に発行された証明書など、完全な PKI 階層 (非限定の下位 CA、クロス署名されたルート Ca、下位 Ca、Eku、証明書の制約) を Microsoft に開示する必要があります。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. プログラムの参加者は、変更が発生したときに、この情報を CCADB で正確に保持する必要があります。Program Participants must keep this information accurate in the CCADB when changes occur. 下位 CA が公開または監査されていない場合は、ドメインに制限されている必要があります。If a subordinate CA is not publicly disclosed or audited, it must be domain-constrained.

  3. プログラムの参加者は、登録されたルートまたは下位 CA の所有権を別のエンティティまたはユーザーに転送する前に、少なくとも120日以内に Microsoft に電子メールで通知する必要があります。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. Ca は、30日以内に中間証明書を失効させるときに CCADB を更新する必要があります。CAs must update the CCADB when revoking any intermediate certificates within 30 days.

  5. プログラムの参加者は、プログラムからルート CA を削除することによって大きな影響を受ける可能性があることをマイクロソフトがお客様に連絡できることに同意します。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. 商用 Ca では、主に組織内で内部的に信頼されるように意図されたルート CA をプログラムに登録することはできません (エンタープライズ Ca など)。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. CA が下請け業者を使用してビジネスのあらゆる側面を運営している場合、CA は、下請業者のビジネス運営を担当します。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. マイクロソフトがその唯一の裁量として、信頼されたルートプログラムの目的に反して使用法または属性が決定されている証明書を特定する場合、Microsoft は責任を持つ CA に通知し、証明書を失効することを要求します。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. CA は、証明書を失効させるか、Microsoft の通知を受け取ってから24時間以内に Microsoft からの例外を要求する必要があります。The CA must either revoke the certificate or request an exception from Microsoft within 24 hours of receiving Microsoft's notice. マイクロソフトは、送信された資料をレビューし、その裁量で例外を許可または拒否するための最終的な決定を CA に伝えます。Microsoft will review submitted material and inform the CA of its final decision to grant or deny the exception at its sole discretion. Microsoft が例外を許可しない場合、CA は、例外が拒否される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

プログラムのすべての Ca は、プログラムの技術的な要件に準拠している必要があります。All CAs in the Program must comply with the Program Technical Requirements. CA が以下の要件に準拠していないと判断した場合、Microsoft はその ca をプログラムから除外します。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 属性は、CA の市場に適した言語である必要があり、その市場の典型的な顧客によって読み取れるようにする必要があります。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. KeyCertSign と cRLSign のビット位置を設定する必要があります。Bit positions for KeyCertSign and cRLSign MUST be set. OCSP 応答の署名にルート CA の秘密キーが使用されている場合は、Digitalsignature ビットビットを設定する必要があります。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. 新しく期限があるルート Ca は、少なくとも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. 参加しているルート Ca は、これらの要件の対象となるルートから新しい1024ビット RSA 証明書を発行することはできません。Participating Root CAs may not issue new 1024-bit RSA certificates from roots covered by these requirements.
  5. すべてのエンドエンティティ証明書には、有効な OCSP URL を持つ AIA 拡張機能が含まれている必要があります。All end-entity certificates must contain an AIA extension with a valid OCSP URL. これらの証明書には、有効な CRL URL を含む CDP 拡張機能を含めることもできます。These certificates may also contain a CDP extension that contains a valid CRL URL. 他のすべての証明書の種類には、OCSP URL を持つ AIA 拡張機能、または有効な CRL URL を持つ CDP 拡張機能のいずれかが含まれている必要がありますAll other certificate types must contain either an AIA extension with an OCSP URL or a CDP extension with a valid CRL URL
  6. 秘密キーとサブジェクト名は、ルート証明書ごとに一意である必要があります。同じ CA によるその後のルート証明書で秘密キーまたはサブジェクト名を再利用すると、予期しない証明書チェーンの問題が発生する可能性があります。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. Microsoft による配布の前に新しいルート証明書を生成する場合、Ca は新しいキーを生成し、新しいサブジェクト名を適用する必要があります。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 です ("GOVERNMENT ca" の定義については、セクション 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"). 政府によって発行されたこれらの Tld は、各 CA のコントラクトで参照されます。These government-issued TLDs are referred to in each CA's respective contract.
  8. 参加しているルート CA にチェーンされている CA 証明書を発行するには、サーバー認証、S/MIME、コード署名、およびタイムスタンプを分離する必要があります。Issuing CA certificates that chain to a participating Root CA must separate Server Authentication, S/MIME, Code Signing, and Time Stamping uses. つまり、単一の発行元の CA は、サーバー認証と 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 フォーラムのベースライン要件の「付録 A」に記載されている、サブスクライバー証明書のアルゴリズムの種類とキーサイズの要件を満たす必要があり 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. Ca は、証明書ポリシー拡張のエンドエンティティ証明書で、次のいずれかのポリシー 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-ES 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. EV コード署名2.23.140.1.3EV Code Signing 2.23.140.1.3
    6. 非 EV コード署名2.23.140.1.4.1Non-EV Code Signing 2.23.140.1.4.1
  11. IETF RFC 5280 に従って基本制限の拡張機能を含むエンドエンティティ証明書では、cA フィールドを FALSE に設定し、pathLenConstraint フィールドを存在させることはできません。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. CA は、許可されている EKU のみが OCSP 署名であるように、OCSP レスポンダーを技術的に制限する必要があります。A CA must technically constrain an OCSP responder such that the only EKU allowed is OCSP Signing.
  13. CA は、Microsoft によって要求された特定の日付に証明書を失効させることができる必要があります。A CA must be able to revoke a certificate to a specific date as requested by Microsoft.

B.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.C. 失効要件Revocation Requirements

  1. CA は、ドキュメント化された失効ポリシーを持つ必要があり、発行されるすべての証明書を失効させることができる必要があります。The CA must have a documented revocation policy and must have the ability to revoke any certificate it issues.
  2. サーバー認証証明書を発行する Ca は、次の OCSP レスポンダー要件をサポートする必要があります。CAs that issue Server Authentication certificates must support the following OCSP responder requirements:
    1. 最小有効期間は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. ルート CA から発行されるすべての証明書は、CRL 配布ポイントの拡張機能と OCSP レスポンダーの URL を含む AIA のいずれかをサポートする必要があります。All certificates issued from a root CA must support either the CRL distribution point extension and/or AIA containing an OCSP responder URL.
  4. CA は、ルート証明書を使用してエンドエンティティ証明書を発行することはできません。The CA must not use the root certificate to issue end-entity certificates.
  5. CA がコード署名証明書を発行する場合は、RFC 3161 の "Internet x.509 公開キー基盤 Time-Stamp プロトコル (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.D. コード署名のルート証明書の要件Code Signing Root Certificate Requirements

  1. コード署名の使用をサポートするルート証明書は、置換ロールオーバールート証明書の配布日から10年後に、または、CA によって要求された場合は、すぐに配布から削除される可能性があります。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 OS で ' 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.E. EKU の要件EKU Requirements

  1. Ca は、ルート証明書に割り当てられているすべての Eku に対して、業務上の正当な理由を提供する必要があります。CAs must provide a business justification for all of the EKUs assigned to their root certificate. 理由としては、ある種類の証明書を発行する現在の業務の公的証拠の形式、または近い期間 (プログラムによるルート証明書の配布の1年以内) にそれらの証明書を発行することを意図したビジネス計画が考えられます。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. Microsoft では、次の 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 は、Office 内のドキュメントの署名に使用されます。This EKU is used for signing documents within Office. 他のドキュメント署名を使用する場合は必要ありません。It is not required for other document signing uses.

F.F. Windows 10 カーネルモードコード署名 (KMCS) の要件Windows 10 Kernel Mode Code Signing (KMCS) Requirements

Windows 10 では、カーネルモードドライバーを検証するための要件が強化されています。Windows 10 has heightened requirements to validate kernel-mode drivers. ドライバーは、拡張された検証要件を使用して、Microsoft とプログラムパートナーの両方によって署名されている必要があります。Drivers must be signed by both Microsoft and a Program partner using Extended Validation requirements. Windows に含まれるカーネルモードドライバーを必要とするすべての開発者は、Microsoft ハードウェア開発チームによって規定されている手順に従う必要があります。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