计划要求 - Microsoft 受信任的根计划

  • 项目

1.简介

Microsoft 根证书计划支持根证书分发，这样做让客户能够信任 Windows 产品。 本页介绍该计划的一般要求要求和技术要求。

注意

2. 继续介绍程序要求

审核要求

  1. 开展商业运营之前以及今后每年，计划参与者必须向 Microsoft 提供每个根、不受约束的从属 CA 和交叉签名证书的合格审核（请参阅 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 发送电子邮件或公函时，计划参与者必须同意通知有效。 提供的联系人或别名中至少有一个应作为全天候受监视信道，以便应对吊销请求和其他事件管理情况。

  2. 计划参与者必须每年将其完整的 PKI 层次结构（不受限制的从属 CA、交叉签名的非注册根 CA、从属 CA、EKU、证书约束）披露给 Microsoft，其中包括颁发给 CCADB 中由外部第三方运营的 CA 的证书。 如有更改，计划参与者必须确保 CCADB 中的此等信息准确无误。 如果未公开披露或审核从属 CA，则该 CA 必须受域约束。

  3. 计划参与者必须在将链接到已注册根的已注册根 CA 或从属 CA 的所有权转移给另一实体或个人之前 120 天通知 Microsoft。

  4. 原因代码必须包含在中间证书的吊销请求中。 吊销任何中间证书时，CA 必须在 30 天内更新 CCADB。

  5. 计划参与者同意，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. Basic Constraints 扩展必须为 cA=true。
    4. Key Usage 扩展必须存在并且必须标记为“关键”。 必须设置 KeyCertSign 位和 cRLSign 位的位置。 如果根 CA 私钥可用于对 OCSP 响应进行签名，则必须设置 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 在后续根证书中重复使用私钥或使用者名称的行为可能会导致意外的证书链问题。 在 Microsoft 分发之前生成新的根证书时，CA 必须生成新的密钥并应用新的使用者名称。
  7. 政府 CA 必须将服务器身份验证限制到政府颁发的顶级域范围内，并且只能向拥有主权控制的 ISO3166 国家/地区代码颁发其他证书（请参阅 https://aka.ms/auditreqs 第 III 部分，了解“政府 CA”的定义）。 每个 CA 各自的合同中均提及了这些政府颁发的 TLD。
  8. 链接到参与根 CA 的颁发 CA 证书必须单独使用服务器身份验证、S/MIME、代码签名和时间戳。 这意味着单个颁发 CA 不得将服务器身份验证和 S/MIME、代码签名或时间戳 EKU 结合起来。 必须对每个用例使用单独的中间 CA。
  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 论坛的 EV SSL OID (2.23.140.1.1)。 Microsoft Edge 团队将在浏览器中实现对 EV SSL OID (2.23.140.1.1) 的检查，因此将不再接受其他 EV SSL OID 与 Edge 保持一致并避免不兼容。
  12. CA 应用于其根证书的 OID 不得超过 2 个。
  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) 小时最短有效时间；七 (7) 天最长有效时间。
    2. 下一次更新必须在当前期间到期前至少八 (8) 小时内提供。 如果有效时间超过 16 个小时，则下一次更新必须在有效时间达到一半时提供。
  3. 通过根 CA 颁发的所有证书均须支持 CRL 分发点扩展和/或包含 OCSP 响应程序 URL 的 AIA。
  4. CA 不得使用根证书颁发最终实体证书。
  5. 如果 CA 颁发代码签名证书，则该 CA 必须使用符合 RFC 3161“Internet X.509 公钥基础结构时间戳协议 (TSP)”的时间戳颁发机构。

D. 代码签名根证书要求

  1. 如果 CA 请求，则支持使用代码签名的根证书可能会在发布替换版滚动更新根证书之日起 10 年或更短时间内从计划分发中将其删除。
  2. 在 Windows 10 操作系统中，在发布中保留且仅支持代码签名的根证书（例如 RSA 1024 = 2014、RSA 2048 = 2030）可能会被设置为“禁用”。
  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 中对文档进行签名。 其他文档签名不需要使用此 EKU。

F. Windows 10 内核模式代码签名 (KMCS) 要求

Windows 10 提高了验证内核模式驱动程序的要求。 驱动程序必须经 Microsoft 和采用扩展验证要求的计划合作伙伴签名。 希望在 Windows 中纳入内核模式驱动程序的所有开发者都必须遵循 Microsoft 硬件开发团队所述的过程。 有关详细信息，请参阅适用于 Windows 硬件的合作伙伴中心。