プログラム要件 - Microsoft の信頼できるルートプログラム

1.イントロダクション

Microsoftルート証明書プログラムは、ルート証明書の配布をサポートし、お客様がWindows製品を信頼できるようにします。 このページでは、プログラムの一般的要件と技術的要件について説明します。

2. 継続プログラムの要件

監査の要件

1. プログラムの参加者は、商業運用を実施する前、およびそれ以降 1 年ごとに、各ルート、制限のない下位 CA、およびクロス署名証明書についての適格監査 (https://aka.ms/auditreqs を参照) の証拠を、Microsoft に提供する必要があります。
2. プログラム参加者は、すべての制約のない下位CAと交差署名証明書がプログラム監査要件を満たすことを保証する責任を負わなければなりません。
3. CAは、制約のない下位CAのすべての監査報告書を公開する必要があります。
4. CA プロバイダーは、S/MIME が有効なルート CA と、S/MIME 証明書を発行できるすべての下位 CA が最新バージョン (少なくとも 以下の基準一式のいずれか) に対して監査を継続していることを確認する必要があります。 この監査は、少なくとも年に 1 回行う必要があります。 最初の監査期間は、2023 年 9 月 1 日までに開始する必要があります。
   
   • WebTrust Principles and Criteria for Certification Authorities – S/MIME
     
   • ETSI EN 119 411-6 LCP、NCP、または NCP+
     

コミュニケーションおよび開示要件

4. プログラム参加者は、プログラムの代表者および一般的な電子メールエイリアスとして、Microsoftに少なくとも2つの「信頼されたエージェント」のIDを提供する必要があります。 プログラムの参加者は、信頼されたエージェントとしての担当者の削除または追加について、Microsoft に通知する必要があります。 プログラムの参加者は、電子メールによる通知の受け取りに同意し、正式な通知を受け取るための電子メール アドレスを Microsoft に提供する必要があります。 プログラムの参加者は、Microsoft が電子メールまたは公式な書簡を送ったときに、通知が有効であることに同意する必要があります。 指定された連絡先またはエイリアスの少なくとも1つは、要求の取り消しまたはその他のイベント管理状況のために24時間年中無休で監視される通信チャネルである必要があります。

5. プログラム参加者は、CCADB内外の第三者によって運営されているCAに発行された証明書を含む、完全なPKI階層（非限定スレーブCA、クロスシグネチャ非登録ルートCA、スレーブCA、EKU、証明書制約）を毎年Microsoftに開示する必要があります。 プログラム参加者は、変更が発生した場合に、この情報をCCADBで正確に保つ必要があります。 下位 CA が公開されておらず、監査もされていない場合は、ドメインの制約を受ける必要があります。

6. プログラムの参加者は、登録されたルートまたは登録されたルートにチェーンする下位 CA の所有権を別のエンティティまたは人に譲渡する少なくとも 120 日前に、Microsoft に電子メールで通知する必要があります。

7. 中間証明書の失効には、理由コードを含める必要があります。 CAは、3 0日以内に中間証明書を失効する場合、CCADBを更新しなければならない。

8. プログラム参加者は、Microsoftが、保留中のルートCAのプログラムからの削除によって実質的な影響を受ける可能性があるとMicrosoftが考える顧客に連絡することに同意するものとします。

その他の要件

9. 商用CAは、組織内で主に信頼されることを意図したプログラムにルートCAを登録することはできません(つまり、エンタープライズCA)。

10. CAが事業のいずれかの側面を実行するために下請け業者を使用する場合、CAは下請け業者の事業運営に責任を負います。

11. Microsoft が、その独自の判断で、使用法または属性が信頼されたルート プログラムの目的に反していると判断される証明書を特定した場合、Microsoft は責任を担う CA に通知し、証明書の失効を要求します。 CA は、Microsoft の通知を受け取ってから 24 時間以内に、証明書を失効させるか、Microsoft に例外を要求する必要があります。 マイクロソフトは、提出された資料をレビューし、独自の判断で、例外を許可または拒否する最終的な決定を CA に伝えます。 Microsoft が例外を許可しない場合、CA は、例外が拒否されてから 24 時間以内に、証明書を失効させる必要があります。

3. プログラムの技術要件

プログラム内のすべてのCAは、プログラム技術要件に準拠する必要があります。 Microsoft は、CA が以下の要件に準拠していないと判断した場合、その CA をプログラムから除外します。

A. ルート要件

1. ルート証明書は、x.509 v3 証明書である必要があります。
   1. CN 属性は、発行元を一意に示すものである必要があります。
   2. CN属性は、CAの市場に適した言語であり、その市場の典型的な顧客が読めるものでなければなりません。
   3. 基本的な制約拡張: cA=trueでなければなりません。
   4. キー使用拡張が存在し、重大とマークされている必要があります。 KeyCertSign と cRLSign のビット位置が、設定されている必要があります。 OCSP 応答の署名にルート CA の秘密キーが使用されている場合は、digitalSignature ビットが設定されている必要があります。
      • ルート キーのサイズは、"キーの要件" で詳しく説明されている要件を満たしている必要があります。
2. 信頼されたルート ストアに追加される証明書は、自己署名ルート証明書である必要があります。
3. 新しく作成されるルート CA の有効期間は、送信日から 8 年以上 25 年以下である必要があります。
4. 参加するルートCAは、これらの要件の対象となるルートから新しい1024ビットRSA証明書を発行してはならない。
5. すべてのエンドエンティティ証明書には、有効なOCSP URLを持つAIA拡張子が含まれている必要があります。 これらの証明書には、有効な CRL URL を含む CDP 拡張を含めることもできます。 他のすべての証明書の種類には、AIA 拡張と OCSP URL、または CDP 拡張と有効な CRL URL のいずれかが、含まれている必要があります
6. プライベート鍵とサブジェクト名は、ルート証明書ごとに一意である必要があります。同じCAによる後続のルート証明書でのプライベート鍵またはサブジェクト名の再利用は、予期しない証明書の連鎖問題を引き起こす可能性があります。 CA は、Microsoft による配布の前に新しいルート証明書を生成するときは、新しいキーを生成し、新しいサブジェクト名を適用する必要があります。
7. 政府CAは、サーバー認証を政府が発行したトップレベルドメインに制限し、その国が主権管理下にあるISO 3166国コードにのみ追加の証明書を発行する必要があります（「政府CA」の定義については、セクションIIIをhttps://aka.ms/auditreqs参照してください）。 これらの政府発行の TLD は、各 CA のコントラクトで参照されます。
8. 参加しているルート CA にチェーンする発行元 CA 証明書では、サーバー認証、S/MIME、コード署名、およびタイムスタンプの使用を別にする必要があります。 つまり、単一の発行元 CA で、サーバー認証と S/MIME、コード署名、タイムスタンプ EKU を組み合わせることはできません。 各ユースケースには別々の中間を使用する必要があります。
9. エンドエンティティ証明書は、https://cabforum.org/baseline-requirements-documents/ CAB フォーラム ベースライン要件の付録 Aに記載されている加入者証明書のアルゴリズムタイプとキー体格の要件を満たす必要があります。
10. CA は、証明書ポリシー拡張のエンドエンティティ証明書で、次のいずれかのポリシー OID を宣言する必要があります。
    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 年 8 月以降、信頼されたルート プログラムとそれぞれのツールによって管理されているすべてのカスタム EV SSL OID が削除され、CA/B Forum 準拠の EV SSL OID (2.23.140.1.1) に置き換えられます。 Microsoft Edge チームは、ブラウザーで EV SSL OID (2.23.140.1.1) のチェックを実装します。そのため、他の EV SSL OID は、Edge と連携して互換性を回避するために受け入れられなくなります。
12. CA では、ルート証明書に 2 つ以上の OID を適用することはできません。
13. IETF RFC 5280 に従って基本制約拡張を含むエンドエンティティ証明書では、cA フィールドを FALSE に設定し、pathLenConstraint フィールドが存在しなようにする必要があります。
14. CAは技術的にOCSPレスポンダーを制限し、許可されるEKUがOCSP署名のみであるようにする必要があります。
15. CAは、Microsoftの要求に応じて、特定の日付に証明書を取り消すことができる必要があります。

B. 署名の要件

注: ECDSA などの楕円曲線暗号 (ECC) を使用する署名は、Windows および新しい Windows セキュリティ機能ではサポートされていません。 これらのアルゴリズムと証明書を使用しているユーザーは、さまざまなエラーや潜在的なセキュリティ リスクに直面します。 Microsoft の信頼されたルート プログラムでは、この既知の非互換性とリスクのために、ECC/ECDSA 証明書をサブスクライバーに発行しないことをお勧めします。

C: 取り消しの要件

1. CA は、文書化された失効ポリシーを用意する必要があり、発行したすべての証明書を失効できる必要があります。
2. サーバー認証証明書を発行する CA は、次の OCSP レスポンダー要件の両方をサポートする必要があります:
   1. 最小有効期間 8 時間、最大有効期間 7 日。
   2. 次の更新プログラムは、現在の期間が終了する少なくとも8時間前に利用できる必要があります。 有効期間が 16 時間より長い場合は、有効期間が半分過ぎた時点で、次の更新が利用可能でなければなりません。
3. ルート CA から発行されるすべての証明書では、CRL 配布ポイント拡張と、OCSP レスポンダー URL を含む AIA の、いずれか一方または両方をサポートする必要があります。
4. CAはルート証明書を使用してエンドエンティティ証明書を発行してはいけません。
5. CAがコード署名証明書を発行する場合は、RFC 3161準拠のタイムスタンプ機関を使用する必要があります。「インターネットX.509公開鍵インフラストラクチャタイムスタンププロトコル（TSP）。」

D. ルート証明書のコード署名要件

1. コード署名の使用をサポートするルート証明書は、置換ロールオーバー ルート証明書の配布日から 10 年以内、またはCAが要求した場合はそれ以前に、プログラムによって配布から削除される可能性があります。
2. アルゴリズムのセキュリティ有効期間を超えてコード署名のみをサポートするルート証明書(例: RSA 1024=2014、RSA 2048=2030)は、Windows 10 OSで「無効」に設定される場合があります。
3. 2024 年 2 月以降、Microsoft は EV コード署名証明書を受け入れたり認識したりしなくなり、CCADB は EV コード署名監査の受け入れを停止します。 2024 年 8 月以降、すべての EV コード署名 OID が Microsoft 信頼されたルート プログラムの既存のルートから削除され、すべてのコード署名証明書が均等に扱われます。

E. EKU の要件

1. CA は、ルート証明書に割り当てられたすべてのEKUのビジネス上の正当性を提供する必要があります。 正当性は、ある種類の証明書を発行する現在のビジネスの公的証拠、または近い将来(プログラムによるルート証明書の配布から1年以内)にそれらの証明書を発行する意図を示すビジネスプランの形である可能性があります。

2. Microsoftは次のEKUのみを有効にします。

   1. サーバー認証 = 1.3.6.1.5.5.7.3.1
   2. クライアント認証 = 1.3.6.1.5.5.7.3.2
   3. セキュアEメール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にカーネルモードドライバを含めることを希望するすべての開発者は、Microsoftハードウェア開発チームによって概説された手順に従う必要があります。 詳細については、Windows ハードウェアのパートナー センターを参照してください。