共用方式為

程式需求 - Microsoft受信任的根程式

  • 發行項

1. 簡介

Microsoft跟證書計劃支援發佈跟證書，讓客戶能夠信任 Windows 產品。 此頁面描述程式的一般和技術需求。

注意

2. 持續計劃需求

稽核需求

  1. 計劃參與者必須針對每個根、不受限制的次級 CA 和交叉簽署憑證，提供Microsoft合格稽核的證據 https://aka.ms/auditreqs，然後再進行商業作業，之後再每年進行一次。
  2. 計劃參與者必須承擔責任，以確保所有不受限制的次級 CA 和交叉簽署憑證都符合計劃稽核需求。
  3. CA 必須公開披露不受限制的次級 CA 的所有稽核報告。
  4. CA 提供者必須確保其已啟用 S/MIME 的根 CA，以及能夠發出 S/MIME 憑證的所有次級 CA，並將繼續根據最新版本 的其中一組準則進行稽核。 此稽核必須至少每年進行一次。 初始稽核期間不得晚於 2023 年 9 月 1 日開始。
    • 證書頒發機構單位的 WebTrust 準則和準則 – S/MIME
    • ETSI EN 119 411-6 LCP、NCP 或 NCP+

通訊和披露需求

  1. 計劃參與者必須提供至少兩個「受信任的代理程式」的身分識別 Microsoft，才能作為計劃的代表，以及一個一般電子郵件別名。 計劃參與者必須通知Microsoft將人員移除或新增為受信任的代理程式。 計劃參與者同意透過電子郵件接收通知，且必須提供電子郵件位址Microsoft，才能接收官方通知。 計劃參與者必須同意，當Microsoft傳送電子郵件或官方信件時，通知有效。 提供至少一個聯繫人或別名應該是 24/7 監視的通訊通道，以撤銷要求或其他事件管理情況。

  2. 計劃參與者必須公開其完整的 PKI 階層（非有限次級 CA、跨簽署的非註冊根 CA、次級 CA、次級 CA、EKU、憑證限制），以每年Microsoft，包括向 CCADB 內外部第三方所操作的 CA 簽發的憑證。 當發生變更時，計劃參與者必須在CCADB中保持此資訊正確無誤。 如果未公開或稽核次級 CA，則必須受到網域限制。

  3. 計劃參與者必須透過電子郵件通知Microsoft至少 120 天，才能將已註冊根或次級 CA 的擁有權轉移至另一個實體或人員。

  4. 原因程式代碼必須包含在中繼憑證的撤銷中。 在 30 天內撤銷任何中繼憑證時，CA 必須更新 CCADB。

  5. 計劃參與者同意，Microsoft可能會連絡Microsoft認為可能會受到計劃暫止移除根 CA 的影響。

其他需求

  1. 商業 CA 可能不會向計劃註冊根 CA，該計劃主要是在組織內部信任（亦即企業 CA）。

  2. 如果 CA 使用轉包商操作其業務的任何層面，CA 將負責轉包商的業務營運。

  3. 如果Microsoft單獨判斷其使用方式或屬性與受信任根計劃的目標背道而馳的憑證，Microsoft會通知負責任的 CA，並要求撤銷憑證。 CA 必須在收到Microsoft通知的 24 小時內撤銷憑證或向Microsoft要求例外狀況。 Microsoft將審查提交的材料，並通知 CA 其最終決定授與或拒絕例外狀況，由其自行決定。 如果Microsoft未授與例外狀況，CA 必須在拒絕例外狀況的 24 小時內撤銷憑證。

3. 計劃技術需求

計劃中的所有 CA 都必須符合計劃技術需求。 如果Microsoft判斷 CA 不符合下列需求，Microsoft將會從計劃排除該 CA。

A. 根需求

  1. 跟證書必須是 x.509 v3 憑證。
    1. CN 屬性必須識別發行者，而且必須是唯一的。
    2. CN 屬性必須是適合 CA 市場的語言，且可由該市場中的典型客戶讀取。
    3. 基本條件約束延伸：必須是 cA=true。
    4. 密鑰使用延伸模組必須存在，且必須標示為嚴重。 必須設定 KeyCertSign 和 cRLSign 的位位置。 如果根 CA 私鑰用於簽署 OCSP 回應，則必須設定 digitalSignature 位。
      • 根密鑰大小必須符合下列「簽章需求」中詳述的需求。
  2. 要新增至受信任根存放區的憑證必須是自我簽署的跟證書。
  3. 從提交日期起，新 MIM 的根 CA 必須至少有效八年，最多 25 年。
  4. 參與的根 CA 可能不會從這些需求涵蓋的根目錄發行新的 1024 位 RSA 憑證。
  5. 所有發行 CA 憑證都必須包含具有有效 CRL 和/或 OCSP 回應程式 AIA 延伸模組的 CDP 延伸模組。 端點實體憑證可能包含具有有效 OCSP URL 和/或指向包含 CRL 之有效 HTTP 端點的 AIA 延伸模組。 如果未包含具有有效 OCSP URL 的 AIA 延伸模組，則產生的 CRL 檔案應為 <10MB。
  6. 私鑰和主體名稱每個跟證書必須是唯一的;相同 CA 在後續跟證書中重複使用私鑰或主體名稱，可能會導致非預期的憑證鏈結問題。 CA 必須產生新的金鑰，並在Microsoft散發之前產生新的跟證書時套用新的主體名稱。
  7. 政府 CA 必須將伺服器驗證限制為政府發行的最上層網域，而且只能向該國擁有主權控制權的ISO3166國家/地區代碼頒發其他憑證（請參閱 https://aka.ms/auditreqs 第三節，以取得“政府 CA”的定義）。 這些政府發行的 TLD 會在每個 CA 的個別合約中參考。
  8. 發行鏈結至參與根 CA 的 CA 憑證，必須個別使用伺服器驗證、S/MIME、程式代碼簽署和時間戳。 這表示單一發行 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.4.1。
    6. S/MIME 信箱已驗證舊版 2.23.140.1.5.1.1。
    7. S/MIME 信箱已驗證多重用途 2.23.140.1.5.1.2。
    8. S/MIME 信箱已驗證 Strict 2.23.140.1.5.1.3。
    9. S/MIME 組織已驗證舊版 2.23.140.1.5.2.1。
    10. S/MIME 組織已驗證多重用途 2.23.140.1.5.2.2。
    11. S/MIME 組織已驗證 Strict 2.23.140.1.5.2.3。
    12. S/MIME 贊助者已驗證舊版 2.23.140.1.5.3.1。
    13. S/MIME 贊助者已驗證多重用途 2.23.140.1.5.3.2。
    14. S/MIME 贊助者已驗證嚴格 2.23.140.1.5.3.3。
    15. S/MIME 個別驗證的舊版 2.23.140.1.5.4.1。
    16. S/MIME 個別驗證的多用途 2.23.140.1.5.4.2。
    17. S/MIME 個人驗證的 Strict 2.23.140.1.5.4.3。
  11. 從 2024 年 8 月開始，由受信任根計劃管理的所有自定義 EV SSL OID，我們的個別工具將會移除，並以 CA/B 論壇相容的 EV SSL OID （2.23.140.1.1.1） 取代。 Microsoft Edge 小組會在瀏覽器中實作 EV SSL OID （2.23.140.1.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. 簽章需求

演算法 除了程式代碼簽署和時間戳以外，所有用途 程式代碼簽署和時間戳使用
摘要演算法 SHA2 （SHA256、SHA384、SHA512） SHA2 （SHA256、SHA384、SHA512）
RSA 2048 4096 （僅限新根）
ECC / ECDSA NIST P-256、P-384、P-521 不支援

請注意：

  • Windows 和較新的 Windows 安全性功能不支援使用橢圓曲線加密的簽章（ECC，例如 ECDSA）。 使用這些演算法和憑證的使用者將面臨各種錯誤和潛在的安全性風險。 Microsoft信任的根計劃建議 ECC/ECDSA 憑證不應該因為這個已知的不相容和風險而發給訂閱者。
  • 程式代碼簽署不支援 ECC 或金鑰 > 4096

C. 撤銷需求

  1. CA 必須有記載的撤銷原則，而且必須能夠撤銷它所簽發的任何憑證。

  2. OCSP 回應程式需求：a。 最低有效期為八（8）小時：有效期上限為七（7）天：和 b. 下一個更新必須在目前期間到期前至少提供八（8）小時。 如果有效時間超過 16 小時，則下一個更新必須在有效期間 1/2 提供。

  3. 當 OCSP 不存在時，CRL 建議：a。 應包含Microsoft特定延伸模組 1.3.6.1.4.1.311.21.4 （下一個 CRL 發佈）。 b. 新的CRL應該會在下一個CRL發佈時間取得。 c. CRL 檔案的大小上限（完整 CRL 或分割的 CRL）不應超過 10M。

    注意

    當 OCSP 不存在時，第 3.C.3- CRL 建議一節的目標是在大規模撤銷的情況下為終端使用者提供涵蓋範圍。

  4. CA 不得使用跟證書來發出結束實體憑證。

  5. 如果 CA 發出程式碼簽署憑證，則必須使用符合 RFC 3161「因特網 X.509 公鑰基礎結構時間戳通訊協定（TSP）的時間戳授權單位」。

D. 程式代碼簽署跟證書需求

  1. 如果 CA 要求，支援程式代碼簽署使用的跟證書，可以從散發 10 年後從散發取代變換跟證書的日期移除。
  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 提供業務理由。 理由可能是目前發行類型或類型的憑證業務的公開證據形式，或示範短期內發行這些憑證的商業計劃（計劃在跟證書散發後的一年內）。

  2. Microsoft只會啟用下列 EKU：

    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硬體開發小組概述的程式。 如需詳細資訊，請參閱 Windows 硬體合作夥伴中心。