エクスポート (0) 印刷
すべて展開

ルート証明書プログラム

アーカイブされたコンテンツです。技術的な正確さに関する保証はいたしません。コンテンツには、公開当初には有効でしたが、現在存在していない Web サイトまたは Web ページへリンクする URL が含まれる場合があります。

最終更新日: 2009 年 1 月 15 日

この文書は Microsoft ルート証明書プログラム (「プログラム」) の詳細と要件を説明しています。現在このプログラムのメンバーである証明機関 (「CA」) を http://support.microsoft.com/kb/931125 に記載しています。

トピック

はじめに

Microsoft ルート証明書プログラムはルート証明書の配布をサポートし、Windows クライアントが互いに信頼できるようにします。現在まで、マイクロソフトは 100 近くもの商用の CA および政府の CA のこのプログラムへの参加を承認してきました。ここでは、参加の条件を説明し、新しい CA がこのプログラムに申し込むことを支援します。

ルート証明書配布の機能方法

ルート証明書は Windows Vista で自動的に更新されます。ユーザーがセキュリティ保護された Web サイト (つまり HTTPS を使用) にアクセスしたり、セキュリティ保護された電子メール (つまり S/MIME) を読んだり、署名 (コード署名) 済みの ActiveX コントロールをダウンロードしたりする場合、新しいルート証明書が提示されると、Windows 証明書チェーン検証ソフトウェアがルート証明書の適切な Microsoft Update のロケーションをチェックします。見つかった場合、検証ソフトウェアがコンピューターにルート証明書をダウンロードします。これはユーザー側ではシームレスに実行され、セキュリティ ダイアログ ボックスや警告などは一切表示されません。ダウンロードもバックグラウンドで自動的に行われます。

また、ルート証明書は Windows XP およびそれ以前のオペレーティング システムに Microsoft Update カタログによっても配布されます。Microsoft Update カタログで、「ルート証明書の更新プログラム」または「サポート技術情報 931125」を検索し、最新のルート証明書の更新プログラムのパッケージをダウンロードすることができます。ルートの更新プログラムは累積的であるため、最新の更新プログラムをインストールすれば、プログラムのすべてのルート証明書が入手できます。

ユーザーまたは「証明書利用者」が特定用途のため、ルート証明書を信頼すべきかどうかは、難しい問題である場合もあります。CA は、悪用を目的とした人物に対する証明書の発行を防ぐ必要があります。(たとえば、このような人物は、悪意のあるソフトウェアに署名して、受け入れられるもののように見せようとします。) CA にはこのような証明書を適切に処理するための効果的な失効ポリシーや手順があります。また、ユーザーは証明書を信頼すると決める前に、たとえば、証明書を受け入れた場合、ユーザーのセキュリティに過度の危険がもたらされないようにするため、CA の認証実施規定 (CPS) を確認すると考えられます。このようなドキュメントは数 100 ページにも及ぶ場合があり、ユーザーの信頼の決定を複雑にしかねません。マイクロソフトの役割は、ルート証明書を配布できるようにする前に、プログラムの要件により、CA を評価し、資格を与えることです。マイクロソフトは、既に信頼したCA内部の監査人または、公的な評価基準による監査結果を信頼します。マイクロソフトのレビューの範囲は比較的狭く、事前に検証できるパラメーターに限定されていますが、マイクロソフトは困難な信頼に関する決定を行うにあたり、お客様を支援することを意図しています。

一般的要件

  1. CA (証明機関) は下記の要求された情報 (「マイクロソフトに連絡する」のステップ 1 をご覧ください) を提供し、プログラムのメンバーシップの予備承認を受ける必要があります。

  2. テスト目的のために、CA は CA のルート証明書から発行されたテスト証明書を提供する必要があります。任意で、CA はその CA のルート証明書が確認できる公にアクセス可能なサーバーの URL をマイクロソフトに送信することを推奨します。(詳細はよく寄せられる質問をご覧ください。)

  3. CA は Microsoft CA Agreement に合意する必要があります。申し込みのプロセスのステップ 1 を完了し、その申し込みの予備承認を受けてから、初めて契約が結ばれます。

  4. ルート証明書は下記の技術的要件に準拠している必要があります。具体的には、マイクロソフトはすべてのルートおよび発行 CAに暗号キーの最少サイズとして RSA 2048 ビット モジュールを要求しています。マイクロソフトは期限切れの RSA 1024-bit モジュールのルート証明書を今後受け付けません。マイクロソフトは新しいルートは提出日から少なくとも 8 年間有効で、特に 2048 ビット RSA モジュールを持つ場合、2030 年より前に期限満了となることを望んでいます。

  5. ルート証明書から発行された証明書は CRL 配布ポイント拡張をサポートする必要があります。CRL 配布ポイントは、公にアクセス可能な場所を指し示す必要があります。

  6. CA は失効ポリシーを文書化している必要があり、また CA は自身が発行するすべての証明書を失効できる必要があります。

  7. CA は監査を完了し、監査結果をマイクロソフトに 12 か月ごとに提出する必要があります。監査は、拡張キー使用法 (EKU) の割り当てで、マイクロソフトにより有効とされる PKI 階層を対象とする必要があります。マイクロソフトが有効にするすべての証明書の使用は定期的に監査される必要があります。監査レポートは監査の対象となっている特定の種類の証明書を発行するサブ CA を含むすべての範囲の PKI 階層を文書化する必要があります。適格な監査には次が含まれます。

これらは政府以外の CA について現時点で受け付けている監査です。マイクロソフトは今後上記に記述している監査を変更および/またはその他の類似した監査を受け付ける権利を留保します。

技術的要件

新しいルート証明書は次の技術的要件を満たしている必要があります。

  1. ルート証明書は x.509 v3 証明書である必要があります。

  2. サブジェクトは CA の意味のある名前を含む必要があります。(例: “Root” または “CA1” などは不可。)

  3. 基本制約拡張機能: cA=true

  4. キー使用法 (存在している場合): keyCertSign および cRLSign のみ

  5. ルート キーのサイズの要件は NIST SP 800-57 に基づきます:

    • RSA 2048-bit モジュール以上または同等

    • ECC P256 モジュール以上または同等

  6. ハッシュ アルゴリズムは少なくとも SHA1 である必要があります。MD2、MD4 または MD5 ハッシュは受け入れられません。

  7. RSA 2048 ビット モジュール以上または同等のルート キーのサイズについて、ルート証明書は提出後、少なくとも 8 年間まで、また 2030 年まで、期限切れになってはいけません。ルート キーのサイズが大きい場合、これよりも長い有効期限が許可される場合もあります。

  8. 中間 CA 証明書は、ルート CA プログラムから除外されています。(詳細はよく寄せられる質問をご覧ください。)

  9. CA は 2009 年 1 月 15 日から実施されているプログラムにより配布されるルート証明書から MD2、MD4 または MD5 の下位またはエンド エンティティ証明書を発行しません。

  10. 既存の (「レガシー」の) 1024 ビット RSA ルート証明書は、マイクロソフトにより提供される場合を除き、2010 年 12 月 31 日の NIST の期限切れまで、このプログラムにより引き続き配布される場合があります。

  11. CA は 2010 年 12 月 31 日の NIST の期限切れまで、このプログラムにより配布されるルート証明書から 1024 ビット RSA を発行する場合があります。

政府の CA

ますます国や地方政府は、主に政府対政府または市民対政府 (電子政府) の取引向けに証明機関を設立しています。これらの政府 CA は実際の政府機関、または政府の証明書実践 (CPS) に従って運営している民間団体である場合もあります。政府の CA は、プログラムに含まれるために、監査を除いたすべての一般的な、および技術的要件を満たす必要があります。マイクロソフトは政府の CA から次の監査と同等なものを承認する場合があります。

監査と同等なもの - 政府対政府、または市民対政府の取引を安全にするための証明書を発行する政府の CA について、マイクロソフトは CA の監査状況を証明し、その監査ガイドラインの名前と参照、最終監査日、運用基準 (例: WebTrust For CAs、ETSI TS 102 042、ETSI 101 456、ISO 21188) と同等の監査基準を提供する政府または民間団体からの報告書を承認します。

Extended Validation (EV) の CA

CA は Extended Validation (EV) 証明書と呼ばれる新しい強化されたデジタル証明書の発行を開始しました。マイクロソフトはプログラム参加資格のある CA が正規の EV 監査を完了した場合のみ、EV デジタル証明書の発行について、ルート証明書をマークします。現在、唯一の正規の EV 監査は、認可された WebTrust 監査者 (監査機関) からの WebTrust for CAs – WebTrust Extended Validation Criteria です。WebTrust for CAs EV 監査では、基本の監査を正常に完了することも必要となります。上記の一般的要件をご覧ください。

コード署名証明書

CA がコード署名の EKU をルート証明書に適用することをリクエストした場合、次の要件を満たすルート CA 契約への補足契約が必要となる場合があります。

  1. 加入者契約では、CA は申し込み者または加入者に、各自が提供するアプリケーションの詳細 (アプリケーション名、情報 URL、アプリケーションの説明) が間違いの無い、正しいものであり、誤解を与えないものでなければなりません。また、サブジェクトも検証済みの組織名で確認できる必要があります。加入者が従わなかった場合、または不正確な情報を直ちに修正しなかった場合、コード署名証明書は失効になります。

  2. 加入者契約では、悪意のあるコード (ユーザーの承諾なしでダウンロードされたスパイウェアやその他の悪意のあるソフトウェア、マルウェアなど) をデジタル署名するために証明書を使用した加入者に対し発行した証明書を失効する場合、それを通知する必要があることが定められています。

プログラムからの除外

マイクロソフトは、相対的な規模や市場でのシェアを問わず、すべての地域からの CA をこのプログラムの対象としています。しかし、マイクロソフトは現在、次の種類の CA をプログラムから除外しています。

  • エンタープライズ CA: 組織内、またはパートナー間で (例: 大規模な企業やビジネス) 内部的に使用されているルート証明書は、このプログラムでは受け付けられません。

  • CA 証明書の使用は公共のものである必要があります。つまり、CA は一般人にとって受け入れられる使用の目的で証明書を発行しなければなりません。

  • 監査を怠った CA、マイクロソフトへの監査結果の提出を怠った CA または一般的な、または技術的な要件を満たしていない CA

  • マイクロソフトのお客様への提示の広範なビジネス上の価値の立証責任を果たさない CA

これらは現在、プログラムで除外されています。しかし、マイクロソフトは、これらのガイドラインに当てはまらない可能性はあっても、正当であるお客様のニーズに対応する CA については考慮します。マイクロソフトが直面している問題や変更に関するマイクロソフトのポリシーについて、よく寄せられる質問でその一部を説明していますので、ご覧ください。マイクロソフトは、プログラムのニーズに対応して、いつでも上記に記載した除外を変更する権利を留保します。

申し込み方法

マイクロソフトは、プログラムへの申し込みを行う CA にこれらの手順を順番に完了することを推奨します。

  1. プログラム申し込みのプロセスを開始するためには、次の情報を casubmit@microsoft.com に電子メールで送信してください。

    • 企業名および住所

    • 企業の Web ページのアドレス (URL)

    • 企業の連絡先 2 件 (氏名、電子メール アドレスおよび電話番号)

    • 提出を希望するルート数 – 最多 3 件。ルートが追加されるごとにダウンロード時間が長くなり、ユーザーにマイナスの影響が出るため、このプログラムで受け付けられるルートは CA ごとに 3 件となっています。

    • ルート証明書に関する以下の質問に回答します。

      • ルート証明書から発行される証明書の事業目的は何ですか?

      • 証明書の発行先となる対象者は誰ですか? たとえば、一般向けやある特定の組織のメンバーなど。

      • ルートが必要とするのはどのような拡張キー使用法 (EKU) ですか? たとえば、SSL サーバーまたはクライアント認証、セキュリティで保護された電子メールまたはコード署名など。(このプログラムが許可している、また許可してない EKU については、よく寄せられる質問をご覧ください。)

      • 誰かがこのルートから発行された証明書を要求している際、その身元を確認するために何を実行しますか?

    • 証明機関業務明細へのポインター (URL)。

    • 貴社の CA 業務が受けるサード パーティの監査一覧。

    • 貴社ルートを使用するサービスが、いかにマイクロソフトの顧客に幅広いバリューをもたらすか説明してください。

  2. 申し込みの予備承認を取得する:マイクロソフトは、受信確認後、商取引上妥当な時間内で皆さんからの電子メールに対応します。電子メールで、質問や懸念が寄せられたり、また申し込みの予備承諾やプログラム参加のための次の手順が含まれている場合もあります。

  3. 監査者 (監査機関) を参画させる: 資格を持った監査者 (監査機関) を従事させ、その担当者の評価基準にしたがって監査してください。( 一般的要件をご覧ください。) 通常業務を行う上で監査者 (監査機関) を従事させない場合、マイクロソフトは、皆さんがメンバーシップへの申し込みの予備承認を受け取るまで、このプログラムに参加する目的で監査者 (監査機関) を従事させることは推奨しません。

  4. マイクロソフトの CA 契約を完了する: マイクロソフトの CA 契約を完了し、上記のプログラムの要件の陳情書を提出します。(組織の正式に許可された代表者による) 署名済みの複写を 2 部、次の宛先にマイクロソフトまで返信してください。

    Microsoft Root Certificate Program
    Attn: Tom Albertson
    Program Manager, Windows Security
    Bldg 9/1342
    Microsoft Corporation
    One Microsoft Way
    Redmond , WA 98052- 6399
    Ph 425-882-8080

    マイクロソフトは提出された CA 契約を検討し、受理した場合、下記のステップ 5 および 6 が完了した後、その契約に副署して返送します。

  5. ルート証明書を送信する: ルート証明書を電子メールの添付ファイルとしてマイクロソフト casubmit@microsoft.com まで送信してください。マイクロソフトのメール フィルターを回避するために、.zip 形式でパッケージされた .cer または .der ファイルで送信するとよいでしょう。

  6. 6. Windows Update によるルートの発行: マイクロソフトは定期的に新しいルートの更新プログラムを配布します。通常、年間で 3、4 回またはルート証明書の配布を確保するために必要な場合です。マイクロソフトに受理されたルート証明書は Windows Update および Microsoft Update カタログ を介し Windows Vista および Windows XP クライアントに利用可能となります。

年間更新

マイクロソフトは各 CA がプログラムに参加した後、期限 (12 か月間) が満了となる約 3 か月前に CA に連絡するよう努めます。プログラムに参加すると、次の事項を 1 年ごとに更新する必要であることを念頭に置いてください。

  • CA は正規の監査を完了し、監査報告をマイクロソフトに 12 か月ごとに提出する必要があります。

  • CA はマイクロソフト CA 契約を必要に応じて完了、または延長する必要があります。

CA は、マイクロソフトがここに記載しているような連絡を CA に行う、行わないに関わらず、タイムリーにその運営についての正規の監査を行う責任があります。

ルート証明書に影響を及ぼすアルゴリズムへの攻撃が発生した場合 [2009 年 1 月 15 日 追記]

MD5 証明書に対する MD5 衝突攻撃が実行されている最近の進展を考慮し、マイクロソフトは即時有効で、このプログラムのメンバーである証明機関に、プログラムにより配布されたすべてのルート証明書からの MD2、MD4 または MD5 証明書の発行を停止するよう忠告してきました。また、マイクロソフトは証明機関にその下位の証明書およびエンド エンティティ証明書を 2048 ビット RSA 証明書に移行し、このプログラムにより配布されたすべてのルート証明書について、この移行を 2010 年 12 月 31 までに完了するよう忠告してきました。また、マイクロソフトはプログラムの技術的要件を明確にし、1024 ビット ルート証明書をこのプログラムで配布する証明書から (マイクロソフトにより規定されている場合を除き) 2010 年 12 月 31 日までに削除することを発表しました。

このセクションでは、1024 ビット RSA キーに対するファクタリング攻撃、SHA-1 証明書に対する衝突攻撃が実際に行われた場合、また、MD5 衝突攻撃が続行された場合、影響を受ける 1024 ビットまたは 2048 ビット RSA ルート証明書を配布から削除するというマイクロフトの危機管理計画の概要を述べます。マイクロソフトは RSA、MD5 または SHA アルゴリズムに対する特定の攻撃を確認していませんが、MD5 衝突攻撃はこれらのアルゴリズムの侵害に著しい興味を示しています。プログラムの CA メンバーや一般の Windows ユーザーの利益となるよう、このような攻撃に対するマイクロソフトの緩和策の戦略を可能な限り透過的にすることをマイクロソフトは望んでいます。

1024 ビット RSA 侵害攻撃が行われた場合

1024 ビット RSA が侵害された場合、ルート証明書に加え、エンド エンティティおよび下位の CA 証明書に影響が及ぶと考えられます。NIST は 2010 年 12 月 31 日以降 1024 ビット RSA に依存しないよう促す一般向けのガイダンスを提供しています。マイクロソフトの主な戦略として、可能な限り迅速に CA が 1024 ビット証明書から 2048 ビット RSA に移行、または、より強力な証明書に NIST のガイダンスの期日よりも前に移行することを求めています。現在でも 1024 ビット RSA 証明書に依存している CA は、1024 ビット RSA 侵害攻撃が行われた場合、その業務が混乱する可能性があります。

1024 ビット RSA が侵害された場合、マイクロソフトは次の措置をとります。

  1. 特定の攻撃に対する脆弱性について、プログラムのルート証明書を評価します。

  2. 影響を受ける CA に連絡をとり、その CA のルート証明書に関連する攻撃および予測される結果について知らせます。これには、マイクロソフトが影響を受けるルート証明書を配布から削除する意向があることやその削除を行う仮のスケジュールが含まれる見込みです。

  3. 最長 1 か月以内にすべての影響を受けるルート証明書をプログラムによる配布から削除します。

    • 1024 ビット RSA ルート証明書はプログラムによる配布から即座に削除されます。マイクロソフトは Windows Update のメカニズムを使用してこれらの証明書を利用可能であれば 2048 ビット ルート証明書に更新します。

    • 2048 ビット RSA または ECC と同等なルート証明書も、1024 ビット RSA 証明書を発行している場合、1024 ビット RSA 攻撃による影響を受ける可能性があります。マイクロソフトは CA がすべての影響を受ける証明書を失効するためのプロセスを開始したかどうかを知る必要があります。CA はマイクロソフトにすべての 1024 ビット RSA 証明書の失効日を最長 1 か月以内に知らせる必要があります。失効が行われない場合、2048 ビット RSA ルート証明書も削除される可能性があります。

  4. この種の攻撃が行われている間は、コミュニケーションが不可欠です。マイクロソフトが CA に対し、1024 ビット RSA の侵害が一般に公開されてから 72 時間以内に連絡がつかなかった場合、無関心であると仮定し、その CA のルート キーが強力であるという記録にかかわらず、影響を受けるルート証明書を削除します。マイクロソフト側については、マイクロソフトが別の連絡先を特に指定していない場合、侵害が行われている間の外部の連絡先は casubmit@microsoft.com です。

SHA-1 衝突攻撃が行われた場合

MD-5 衝突攻撃が近年行われたことを考えると、CA がその SHA-1 ルート証明書の発行を辞める前に SHA-1 に対する衝突攻撃が今後行われることを予測するに難くはありません。SHA-1 が侵害された場合、CA には次のいずれかのオプションがあります。

  1. すべての新しい証明書に大きな任意のシリアル番号が含まれるようにする、または

  2. 直ちに SHA-2 ルート証明書に切り替える

    マイクロソフトは 1024 ビット RSA 侵害攻撃について定義している措置を使用し、脆弱性について証明書を評価し、影響を受ける CA に連絡し、影響を受ける証明書を削除し、新しい証明書を配布します。

MD5 原像攻撃が切迫している場合

MD5 原像攻撃が切迫している場合、マイクロソフトは Windows を更新し、すべての MD2、MD4 または MD5 のエンド エンティティおよび下位の CA 証明書を拒否する場合があります。そのような場合、マイクロソフトは 1024 ビット RSA 侵害攻撃について定義された措置を使用し、脆弱性について証明書を評価し、影響を受ける CA に連絡し、Windows を更新して影響を受ける証明書を拒否するようにします。

よく寄せられる質問

  • プログラムの費用はどのくらいですか?

    マイクロソフトは現在ルート証明書プログラムについての料金は請求していません。しかし、CA が年間の監査の要件に関連する査定人に支払う費用があります。CA は、プログラムの要件を満たすことに関連するすべての財務費用やその他の費用、義務について全責任を負い、負担します。

  • WebTrust または ETSI に対する監査/監査者 (監査機関) に同等なものはどのように確立できますか?

    監査と同等であることを証明する責務は CA が負います。通常、マイクロソフトは政府の CA 以外、監査と同等なものは受け付けていません。政府の CA の場合、マイクロソフトは、政府の CA の監査者 (監査機関) から、対象となる監査の基礎に見合う、または超える、不足する点を記載している監査と同等の文書を受け付ける場合があります。

    監査はこのプログラムの義務的な部分かつ、マイクロソフトの要件が最も柔軟な分野でもあります。CA 業界は比較的新しく、法律も様々で、CA の通常の PKI オペレーションを確認するための具体的な監査はほとんど存在していません。徐々に、マイクロソフトは受け付けられる CA の監査の一覧を拡大してきており、ETSI 102 042、ETSI 101 456、WebTrust for CA、WebTrust EV Readiness 監査および ISO 21188 が含まれています。また、政府の CA からの、または政府に指定された CPS により運営されている私的団体からの監査と同等な報告書も認めています。現時点で、マイクロソフトは ISO 27001 の証明書を、主に CA の運営に焦点があてられていないという理由のため、受け付けていません。しかし、マイクロソフトは今後 ISO 27001 を調査し、特に CA PKI を評価する目的の使用についての追加情報がある場合、それを喜んで聞くつもりです。マイクロソフトの要件が変更されるまで、皆さんがマイクロソフトのプログラムへの参加にご興味がある場合、マイクロソフトは皆さんの監査者 (監査機関) に連絡し、その他の監査の 1 つを続行されることを推奨します。

  • ルート証明書登録の最終期限はいつですか?

    マイクロソフトは継続的にルート証明書を受け付けていますので、厳密な期限はありません。マイクロソフトはルートの更新プログラムを 年間 3、4 回発行しています。これは Windows Update のセキュリティ以外の更新のスケジュールとして知られており、その月の第 4 火曜日に公開されます。ルートの更新プログラムは Windows Update のため、月初近くに、マイクロソフトはルートの更新プログラムを公開する前に少なくとも 2 週間ルートの更新プログラムのパッケージをテストする時間が必要です。一般的に、マイクロソフトが次の月 (1 月) にルートの配布を見込んでいる場合、CA は前月 (12 月) の 15 日までにマイクロソフトで承認され、すべての構成要素が揃っている必要があります。しかし、マイクロソフトは定期的なスケジュールで、または特定の月にルートの更新プログラムを配布するという保証はできません。この理由は Windows Update はさらに注意が必要となる更新プログラムの公開の準備をするために、間際にセキュリティ以外の更新の公開をキャンセルする場合があるためです。

    メンバーシップについて予備承認を受けている CA には、配布の次回の期限を常にお知らせしています。ルート証明書に特定の公開についての期限がある場合、マイクロソフトにお知らせください。マイクロソフトはその期限に間に合うよう皆さんを支援します。多くのことが伴いますが、大体がコミュニケーションと準備で行えます。マイクロソフトは Windows Update により CA がルート証明書を利用可能にする日を調整するにあたり、業務上妥当な努力はしますが、マイクロソフトは Windows Update または Microsoft Update カタログで実際に利用可能となる日付について、何の表明、保証、またその他の約束はしません。   

  • 「ルートが使用されるサービスはどのようにマイクロソフトのお客様に広範な価値を提供しますか?」とはどのような意味ですか?

    概略を言えば、ルート証明書を含むことの利益がマイクロソフトのお客様に対する危険を上回るという意味です。潜在的な利益には、マイクロソフトの戦略による CA の証明書の発行の調整があります。

  • 「監査は、拡張キー使用法 (EKU) の割り当てで、マイクロソフトにより有効とされる PKI 階層を対象とする必要があります。」とはどのような意味ですか?

    マイクロソフトがこのプログラムにより有効にしているすべての証明書の使用は監査される必要があります。監査レポートで、監査の対象となる特定の種類の証明書を発行するサブ CA を含む、PKI の階層のすべての範囲を文書化する必要があります。証明書の使用について、この監査の要件は CA に責任が課されます。過去に、CA はその PKI の選択された部分のみを対象とする監査レポートを作成していましたが、マイクロソフトは 監査されていない多数の使用について CA のルート証明書を有効にするよう依頼を受けていました。さらに、CA が [コード署名] について有効にされることを希望する場合、その CA は [コード署名] について監査される必要があります。クライアント認証およびサーバーの認証 (SSL) また、S/MIME についても同様です。

    この監査が欠落していることにより、失効ポリシーにも影響が及びました。特定の証明書の使用についての失効ポリシーの定義を怠り、証明書を発行した後の CA が負う実際の責任について証明書利用者がはっきり分からないままとなっている CA もある可能性があります。さらに、CA は CA がそのルート証明書について指定する EKU を明確にしている失効ポリシーを利用者契約に盛り込む必要があります。すべての証明書ポリシーには失効ポリシーが含まれている必要があります。マイクロソフトは年ごとの監査中に失効ポリシーの証拠を見つけ、これらの監査を信頼してルート証明書に適用する EKU を決定します。

    これは、ほとんどの規則のフレームワークで、PKI がその使用という観点で、監査なしで機能することは許可されないという理にかなった監査の要件であるとマイクロソフトは確信しています。

  • 「CA は明確なポリシーを持ち、発行したすべての証明書を失効することができる必要がある」とはどのような意味ですか? マイクロソフトはこれをどのように監視するのですか?

    CA は CA がそのルート証明書について指定する EKU を明確に扱っている失効ポリシーを利用者契約に盛り込む必要があります。すべての証明書ポリシーには失効ポリシーが含まれている必要があります。マイクロソフトは年ごとの監査中に失効ポリシーの証拠を見つけます。

  • 適用のプロセスの一部として、テスト証明書の発行についてもう少し説明してください。ルート証明書についての証明書ポリシーによって、テスト証明書の発行ができません。

    マイクロソフトは Windows との互換性について証明書を徹底的にテストすることはしませんが、Windows XP およびそれ以降のオペレーティング システムでの自動ルート更新機能を確認するためにテスト証明書が使用されます。CA の CPS により許可された場合、テスト証明書はプロダクション ルートの階層で発行される必要があり、また証明書チェーンがマイクロソフトに送信される必要があります。任意で、CA はテスト中に接続でき、ルート証明書に対し適切なチェーンを確認できる HTTPS URL を提供できます。

  • なぜ中間ルート CA を配布しないのですか? 中間ルート CA がないと、ルート証明書へのチェーンを作成するにあたり問題があります。

    このプログラムが負う責任はルート証明書の更新のみです。現在中間証明書が Windows に含まれているのは単にレガシーに関する理由のためです。CA は頻繁に業務上またライフサイクル上の理由により中間 CA を追加、削除するため、ルート プログラムにおけるすべての CA についての中間証明書の配布の管理は測定できるものではありません。一般的に中間 CA 証明書は 2 つの方法で配布できます。

    • SSL、S/MIME および Microsoft Authenticode などの PKI アプリケーションは中間証明書の配布を促進するために常にエンド エンティティ証明書とともに中間 CA 証明書を送信しています。これが望ましいソリューションです。

    • CA は Windows CryptoAPI が発行元の証明書をダウンロードする手掛かりとして機能する機関情報アクセス拡張機能 (RFC 3280) により、証明書に URL を指定するオプションがあります。今日のほとんどの CA は AIA 拡張機能を持つ証明書を発行し、発行元証明書の検索を可能にします。

  • このプログラムで配布を検討したいルート証明書が 3 つ以上ありますが、これらをどのようにしたらいいですか?

    一般的に、このプログラムではルートのロール オーバーまたはレガシーの状況を除き、1 つの CA につき 3 つ以上のルートを所有することはできません。複数のルートを提出する CA は追加の各ルートがなぜ必要であるのかを正当化する必要があります。たとえば、特定の政府の規則、レガシーの適用、アクセス制御の要件などに対応するために作成された、などです。レガシー ルートを削除する日付に同意できれば、マイクロソフトは 3 つ以上のルートの追加の証明書を「ロールオーバー ルート」(既存のルート証明書を置き換えることを目的としている) として受け入れます。一般的に、マイクロソフトはこれらの日付について CA と協力していますが、期限切れのルート証明書は、期限から 6 – 12 か月後に、また既存のルート証明書はロールオーバー ルート証明書の配布開始後 6 – 12 か月後に削除することを望んでいます。

  • なぜルートに EKU を指定する必要があるのですか?

    このプログラムの目的は、電子商取引、安全な電子メールおよびコード署名など大規模なコンシューマー市場に PKI のシナリオを有効にすることです。エンタープライズのみのシナリオを有効にすることは意図していません。

    Windows の EKU はルート証明書からエンド エンティティ証明書に継承されます。これにより、このルート配下の CA により発行された証明書が定められた使用の一覧にのみ使用されるようにします。マイクロソフトは EKU メタデータを Windows 証明書ストアのメタデータとして証明書に添付するため、EKU 拡張機能でルート証明書を再生成する必要がなくなります。

どの EKU が許可されますか?

許可されている EKU は次の通りです。その他の EKU は、応募者が正当化される理由を提供できれば許可される場合があります。

  • Server Authentication =1.3.6.1.5.5.7.3.1

  • Client Authentication =1.3.6.1.5.5.7.3.2

  • Secure E-mail EKU=1.3.6.1.5.5.7.3.4

  • Code Signing EKU=1.3.6.1.5.5.7.3.3

  • Time stamping EKU=1.3.6.1.5.5.7.3.8

  • OCSP EKU=1.3.6.1.5.5.7.3.9

  • Encrypting File System EKU=1.3.6.1.4.1.311.10.3.4

  • IPSec (Tunnel, User) EKU=1.3.6.1.5.5.7.3.6, 1.3.6.1.5.5.7.3.7

一般的にどのような EKU が許可されないのですか?

次の EKU はプログラムの基準に合わないか、または現在では必要とされていません。

  • スマート カード ログオン

    Active Directory の適用が必要で、ルートが Active Directory の NTAuth ストアに追加される必要があるため、これはエンタープライズのみのシナリオです。詳細は次のサポート技術情報をご覧ください。http://support.microsoft.com/kb/281245

  • デジタル著作権

    • この EKU は旧式です。Windows Media DRM はそれ独自の XML 形式をライセンスに使用し、X.509 を使用しません。

  • 限定従属

    • この EKU は旧式で Windows により無視されます。

  • キー回復

    • エンタープライズ CA のシナリオ

  • ファイルの回復

    • この EKU は旧式で、Windows 暗号化ファイル システム (EFS) により無視されます。

  • すべてのアプリケーションのポリシー

    • マイクロソフトは「すべての使用」を許可できません。この理由はこれはかならずしもエンタープライズのみ、またその他の受け入れられない EKU を認めるわけではないためです。

  • ディレクトリ サービスの電子メールの複製

    • エンタープライズのシナリオ

  • 証明書の要求エージェント

    • エンタープライズ CA のシナリオ

  • キー回復エージェント

    • エンタープライズ CA のシナリオ

  • CA の暗号化の証明書

    • エンタープライズの CA のシナリオ

  • このプログラムに加えられるルートの最大件数はありますか? マイクロソフトがいかなるルート証明書も受け付けないようになる時は来ますか?

    はい、あります。すべてのルート証明書が証明書を使用するすべてのプロセスでメモリにデコードされるため、このプログラムにより利用可能になるルート証明書の数が増加すると、Windows のパフォーマンスにマイナスの影響を及ぼす可能性があります。実際のパフォーマンスの低下は Windows のバージョンやハードウェアの種類により異なる可能性がありますが、マイクロソフトは各決定の長期的な影響を考慮し、新しいルート証明書および CA の新しいクラスを取り入れます。マイクロソフトは、パフォーマンスが影響を受ける可能性のあるルート証明書の数には達していませんが、長期的なことを念頭に入れ、個々の申し込みの決定を行います。マイクロソフトは、これらの基準に基づく独自の決定権におけるメンバーの決定を行い、これらの基準を Windows のパフォーマンスへの混乱が発生した場合に、通知せずに変更する権利を留保します。

  • また、すべての追加のルート証明書により、何億人もの世界中の Windows ユーザーに対する CA の間違いのため、キーの侵害の危険や悪い証明書が増加することになります。その結果、マイクロソフトは世界中のセキュリティ コミュニティからの増大するプレッシャーと直面し、マイクロソフトが CA に配布するルート証明書の数を制限しています。マイクロソフトは、世界中の、または国内や地域の Microsoft Windows ユーザーの大多数に価値を提供する CA のみを受け入れています。ゆくゆくは、マイクロソフトは PKI と協力し、CA の慣習を改善し、マイクロソフトが追加の CA を認める決定を正当化する監査体制および査定人のガイドラインについてコミュニティを監査するつもりです。

MD5 衝突攻撃にはどのような意味がありますか? (2009 年 1 月)

2008 年 12 月後半、研究がセキュリティ カンファレンスで発表され、MD5 ハッシュ アルゴリズムを使用して署名された X.509 デジタル証明書に対し、攻撃が成功することを証明しました。この攻撃の方法により、攻撃者は、元の証明書と同じデジタル署名を持っていますが、コンテンツが異なる追加のデジタル証明書を生成することができる可能性があります。MD5 アルゴリズムは影響を受けるとされましたが、実際の攻撃のデモは行われませんでした。マイクロソフトはこの問題を悪用した攻撃は確認していません。また、証明機関と積極的に協力し、証明機関にこの研究を知らせ、新しい SHA-1 および SHA-2 アルゴリズムに移行するよう推奨しています。

  • レガシーの 1024 ビット RSA ルート証明書をあとどのくらいの期間配布する予定ですか? (2009 年 1 月)

    ほとんどの場合、マイクロソフトは 2010 年 12 月 31 日の NIST の最終日までレガシーの 1024 ビット RSA ルート証明書の配布を継続する予定です。しかし、マイクロソフトは、ルート証明書を脅かすアルゴリズムへの攻撃が発生した場合には、1024 ビット RSA ルート証明書を削除する可能性もあります。また、マイクロソフトは 1024 ビット RSA ルート証明書に依存する期限切れのエンド エンティティ証明書が存在し、そのルート証明書を脅かす攻撃が存在しないのであれば、NIST の期限を過ぎてからでも CA の要請により 1024 ビット RSA ルート証明書の配布を継続する可能性もあります。これはいくつかの重要な状況によります。

    マイクロソフトはここ数年間、配布するための新しい 1024 ビット RSA ルート証明書を受け付けていませんが、多数の 1024 ビット ルート証明書が Web サイトを安全にするために一般的に使用されています。マイクロソフトは、2010 年 12 月 31 日以降は 1024 ビット RSA キーおよび証明書への依存は打ち切ることを推奨する NIST 800-57 の指導に基づき、新しい 1024 ビット ルート証明書の受け付けを停止しました。1996 年以降リリースされたすべてのバージョンの Microsoft Windows は 2048 ビット RSA またはそれ以降をサポートします。ここ数年でプログラムに受け付けたすべてのルート証明書は 2048 ビット RSA または 4096 ビット RSA または ECC に相当するもので、現在の NIST のガイダンスによると少なくとも 2030 年まで、配布に適しています。ほとんどの場合、レガシーの 1024 ビット ルート証明書に依存する期限の切れていないエンド エンティティ証明書が存在する限り、3 つの重要な状況により、マイクロソフトは NIST の期限を過ぎているレガシーの 1024 ビット ルート証明書を配布し続ける予定です。

  • MD2、MD4、MD5 で、またはルート CA、ルート下の下位 CA により発行される新しい証明書はありません。

  • 2010 年 12 月 31 日の NIST の期限以降、CA はルート証明書からの 1024 ビット RSA 証明書の発行を停止します。

  • 1024 ビット RSA が 2010 年 12 月 31 日以降推奨されなくなることを考えると、エンド エンティティ証明書への依存が終了するまでの期間は不当に長いものではありません。

  • 最も重要なことは、1024 ビット RSA または MD5 (1024 ビット RSA ルート証明書のサブセットにより使用されます。) に対し、成功した攻撃がないことです。

CA は、条件を満たせば、1024 ビット ルート証明書の削除についての 2010 年 12 月 31 日の期限を延長するよう要求し、それが受け入れられる場合もあります。マイクロソフトは、いずれの、またはすべての証明書の期限を考慮していない証明書削除の異なる日付を割り当てる可能性があります。特に、マイクロソフトは、アルゴリズムへの攻撃が行われた場合など、ルート証明書が安全でなくなった場合、ルート証明書を削除する権利を留保します。特に、CA がその CA の 1024 ビット RSA ルート証明書の配布期間の延長を得ることを要求した場合、CA は 1024 ビットの侵害の攻撃が行われた場合、そのルート証明書は依存している下位およびエンド エンティティ証明書の数に関わらず、自動的に配布の停止を受ける対象となることを認識している必要がります。このプログラムのメンバーである CA は 2048 ビットのエンド エンティティ証明書の発行に移行し、2048 ビット RSA 証明書チェーンを NIST の期限である 2010 年 12 月 31 日までに完了させるよう勧告されています。CA はより早急に 2048 ビット証明書への移行を検討する必要があります。この理由は、これにより、1024 ビット RSA で攻撃が行われた場合、CA の運営および顧客に対する危険が低減されるためです。マイクロソフトは NIST の期限の前と後の両方についての他の日付も検討しますが、NIST の期限後の日付についての要求は期限が有効でサポートを必要とする可能性がある依存する下位およびエンド エンティティ証明書の種類と数に関する情報でサポートされる必要があります。

例 1: 2018 年 1 月 1 日に期限切れとなる 1024 ビット RSA ルート証明書の場合。マイクロソフトは NIST の期限である 2010 年 12 月 31 日を既定のルート証明書の削除日とします。CA が 2 年間有効なエンド エンティティ証明書を発行しており、2010 年 12 月 31 日の NIST の期限を止める場合、その CA はルート証明書の削除日を 2012 年 12 月 31 日に延長することを願い出ることができ、マイクロソフトもこの日を削除日とすることを許可します。CA により、前回の有効なエンド エンティティ証明書がその日付よりも前に期限切れとなることを通知された場合、マイクロソフトはそのエンド エンティティ証明書の期限切れの日に対応するルート証明書の削除日を割り当てます。

例 2: 2009 年 1 月 1 日に期限切れとなる 1024 ビット RSA ルート証明書 の場合。マイクロソフトは NIST の期限 である 2010 年 12 月 31 日を既定のルート証明書の削除日とします。CA が 2 年間有効なエンド エンティティ証明書を発行しており、2009 年 1 月 1 日まで発行を続ける場合、その CA はルート証明書の削除日を 2011 年 1 月 1 日に延長することを願い出ることができ、マイクロソフトもこの日を削除日とすることを許可します。CA により、前回の有効なエンド エンティティ証明書がその日付以前に期限切れとなることを通知された場合、マイクロソフトはそのエンド エンティティ証明書の期限切れの日に対応するルート証明書の削除日を割り当てます。

この情報は役に立ちましたか。
(残り 1500 文字)
フィードバックをいただき、ありがとうございました
表示:
© 2014 Microsoft