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

1. 概要

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

2. 継続的なプログラム要件

監査要件

  1. プログラム参加者は、商用業務を実施する前に、各ルート、非トレーニング下位 CA、、および署名されていない証明書の認定監査 (参照) の証拠を Microsoft に提出する必要があります。 https://aka.ms/auditreqsその後、年単位で実施する必要があります。
  2. プログラム参加者は、すべてのトレーニングされていない下位 CA と署名されていない証明書がプログラム監査要件を満たしていることを確認する責任を負う必要があります。
  3. CA は、トレーニングされていない下位の CA のすべての監査レポートを公開する必要があります。

コミュニケーションと情報開示の要件

  1. プログラム参加者は、プログラムの代表として機能し、1 つの一般的なメール エイリアスとして機能するために、少なくとも 2 つの "信頼できるエージェント" の ID を Microsoft に提供する必要があります。 プログラム参加者は、信頼できるエージェントとしての人員の削除または追加について Microsoft に通知する必要があります。 プログラム参加者は、電子メールで通知を受け取することに同意し、公式通知を受け取る電子メール アドレスを Microsoft に提供する必要があります。 プログラム参加者は、Microsoft が電子メールまたは公式の手紙を送信するときに通知が有効な場合に、その通知に同意する必要があります。 提供される連絡先またはエイリアスの少なくとも 1 つは、取り消し要求や他のインシデント管理状況について、24 時間 365 日監視される通信チャネルである必要があります。

  2. プログラム参加者は、CCADB 内の外部サード パーティが運営する CA に発行された証明書を含め、PKI の完全な階層 (制限されていない下位 CA、クロス署名された登録されていないルート CA、下位 CA、EKUs、証明書の制約) を年単位で Microsoft に公開する必要があります。 プログラム参加者は、変更が発生した場合、CCADB でこの情報を正確に保つ必要があります。 下位 CA が一般に公開または監査されていない場合は、ドメインの制約を受けなければならない。

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

  4. 理由 コードは、中間証明書の失効に含める必要があります。 CA は、30 日以内に中間証明書を取り出す際に CCADB を更新する必要があります。

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

その他の要件

  1. 商用 CA は、組織内で主に信頼される (つまり、CA を含む) 主に信頼されるプログラムにルート CA を登録Enterpriseがあります。

  2. CA が協力会社を使用して業務を行う場合、CA は協力会社の業務に対して責任を負います。

  3. Microsoft が単独の判断で、使用または属性が信頼されたルート プログラムの目的に反すると判断された証明書を特定した場合、Microsoft は責任ある CA に通知し、証明書を取り消す要求を行います。 CA は、Microsoft の通知を受け取った後 24 時間以内に証明書を取り消すか、Microsoft に例外を要求する必要があります。 Microsoft は、提出された資料を確認し、独自の裁量で例外を許可または拒否する最終的な決定を CA に通知します。 Microsoft が例外を付与しない場合、CA は例外が拒否された 24 時間以内に証明書を取り消す必要があります。


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

プログラム内のすべての CAS は、プログラムの技術要件に準拠する必要があります。 Microsoft が CA が以下の要件に準拠していないと判断した場合、Microsoft は、その 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 拡張機能が含まれている場合があります。 他のすべての証明書の種類には、OCSP URL を含む AIA 拡張機能または有効な CRL URL を持つ CDP 拡張機能が含まれている必要があります。
  6. プライベート キーとサブジェクト名は、ルート証明書ごとに一意である必要があります。同じ CA による後続のルート証明書でのプライベート キーまたはサブジェクト名の再利用により、予期しない証明書チェーンの問題が発生する可能性があります。 CA は、Microsoft が配布する前に新しいルート証明書を生成するときに、新しいキーを生成し、新しいサブジェクト名を適用する必要があります。
  7. 政府機関の CA は、サーバー認証を政府発行のトップ レベル ドメインに制限する必要があります。また、国が主権を持つ ISO3166 国コードに対して発行できるのは他の証明書のみです ( https://aka.ms/auditreqs 「Government CA」の定義については、セクション III を参照してください)。 これらの政府機関が発行した TLD は、各 CA のそれぞれの契約で参照されます。
  8. 参加しているルート CA にチェーンする CA 証明書を発行するには、サーバー認証、S/MIME、コード署名、タイム スタンプの使用を分離する必要があります。 つまり、1 つの発行元 CA がサーバー認証と S/MIME、コード署名、またはタイム スタンプ EKU を組み合わせない必要があります。 各使用例には、個別の中間者を使用する必要があります。
  9. エンド エンティティ証明書は、 にある CAB フォーラムベースライン要件の付録 A に記載されているサブスクライバー証明書のアルゴリズムの種類とキー サイズの要件を満たす必要があります https://cabforum.org/baseline-requirements-documents/
  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.3
    6. EV 以外のコード署名 2.23.140.1.4.1
  11. IETF RFC 5280 に従って Basic Constraints 拡張機能を含むエンド エンティティ証明書には、cA フィールドが FALSE に設定され、pathLenConstraint フィールドが存在しない必要があります。
  12. CA は技術的に OCSP レスポンダーを制約し、許可される EKU は OCSP 署名のみである必要があります。
  13. CA は、Microsoft の要求に応じて、特定の日付に証明書を失効できる必要があります。

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. CA には文書化された失効ポリシーが必要であり、発行した証明書を取り消す機能が必要です。
  2. サーバー認証証明書を発行する CA は、次の OCSP レスポンダー要件をサポートする必要があります。
    1. 最小有効期間は 8 時間です。最大有効期間は 7 日です。そして
    2. 次回の更新プログラムは、現在の期間の有効期限が切れる少なくとも 8 時間前に利用できる必要があります。 有効期間が 16 時間を超える場合は、次の更新プログラムを有効期間の 1/2 に使用できる必要があります。
  3. ルート CA から発行される証明書はすべて、CRL 配布ポイント拡張機能または OCSP レスポンダー URL を含む AIA をサポートする必要があります。
  4. CA は、ルート証明書を使用して、エンド エンティティ証明書を発行することはできません。
  5. CA がコード署名証明書を発行する場合は、RFC 3161"インターネット X.509 公開キー インフラストラクチャ Time-Stamp プロトコル (TSP)" に準拠するタイム スタンプ機関を使用する必要があります。

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

  1. コード署名の使用をサポートするルート証明書は、交換ロールオーバー ルート証明書の配布日から 10 年後 (CA によって要求された場合) から、プログラムによって配布から削除される可能性があります。
  2. コード署名のみをサポートするために配布されたルート証明書は、アルゴリズムのセキュリティ有効期間 (RSA 1024 = 2014、RSA 2048 = 2030 など) を超えて、Windows 10 OS で "disable" に設定できます。

E. EKU 要件

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

  2. Microsoft では、次の EKUs のみを有効にしています。

    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 にカーネル モード ドライバーを含める必要があるすべての開発者は、Microsoft ハードウェア開発チームが説明する手順に従う必要があります。 プログラムのドキュメントについては、こちらを参照 してください。