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

  • 發行項

1. 簡介

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

注意

2. 持續計劃需求

稽核需求

  1. 計劃參與者必須針對每個根、不受限制的次級 CA 和交叉簽署憑證，提供合格稽核的 https://aka.ms/auditreqsMicrosoft 證據，然後再進行商業作業，之後再每年進行一次。
  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 傳送電子郵件或官方信件時，通知有效。 提供至少一個聯繫人或別名應該是 24/7 監視的通訊通道，以撤銷要求或其他事件管理情況。

  2. 計劃參與者必須每年向 Microsoft 披露其完整的 PKI 階層（非有限次級 CA、跨簽署的非註冊根 CA、次級 CA、EKU、憑證限制），包括向 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. 所有結束實體憑證都必須包含具有有效 OCSP URL 的 AIA 延伸模組。 這些憑證也可能包含包含有效 CRL URL 的 CDP 延伸模組。 所有其他憑證類型都必須包含具有 OCSP URL 的 AIA 擴充功能，或是具有有效 CRL URL 的 CDP 擴充功能
  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。
  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 NIST P-256、P-384、P-521

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

C. 撤銷需求

  1. CA 必須有記載的撤銷原則，而且必須能夠撤銷它所簽發的任何憑證。
  2. 發出伺服器驗證憑證的 CA 必須支援下列兩個 OCSP 回應程式需求：
    1. 最低有效時間為 8 （8） 小時：最長有效期為七（7）天。
    2. 下一個更新必須在目前期間到期前至少提供八（8）小時。 如果有效時間超過 16 小時，則必須在有效期間 1/2 提供下一個更新。
  3. 從根 CA 簽發的所有憑證都必須支援 CRL 發佈點延伸和/或包含 OCSP 回應程式 URL 的 AIA。
  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 硬體合作夥伴中心。