基本思想是策略描述整个路径的认证过程，而不仅仅是在给定 CA 的级别。在给定的证书C中，Certificate Policies扩展提供了一组策略，导致创建C的过程符合这些策略。

在验证期间（参见RFC 5280 的第 6.1 节），验证者计算“策略树”。在简单的情况下（有关可能的复杂情况，请参见下文），valid_policy_tree处理结束时的叶子将是路径中所有证书中策略集的交集（“修剪策略树”的步骤是真正计算交集的步骤）。简而言之，您最终获得的策略集将是路径中所有证书中出现的策略集。这很合乎逻辑：只有当路径中的所有证书都以与策略 1.2.3.4.5 兼容的方式颁发时，您才能说给定路径符合策略 1.2.3.4.5，证书本身通过包含策略来宣传的属性1.2.3.4.5 在他们的Certificate Policies扩展。

不要求每个证书仅使用来自上级 CA 的证书子集。这将是不明确的，因为路径可能会合并（给定的 CA 可能会从多个 über-CA 获得多个证书，并且它们可能包含不同的策略）。当考虑单个路径时，交叉工作在验证时完成。从概念上讲，在验证之前没有路径。

可能的并发症：

• 可以有没有Certificate Policies扩展名的证书。
• 可以有策略映射，允许沿路径用其他策略替换一些策略。
• 有一个特殊的策略叫做anyPolicy改变处理。
• 从给定的路径深度开始，有些扩展可以禁止anyPolicy和/或需要明确的策略。

我遇到过很多 CA 在政策方面弄错了；也就是说，它们在每个证书中都包含一个（非关键）Certificate Policies扩展，其中放置了特定于该 CA 的唯一策略。最终结果是，在验证后，valid_policy_tree它是空的（这不是致命的，因为这些证书不包含任何需要显式策略的扩展）。这是将扩展名用作一种美化评论。

我在这里找到了一个比您引用的文本更详细的示例：

https://www.rfc-editor.org/rfc/rfc2527

第 3.2 和 3.3 节。这似乎与第 3.3.1 节特别相关——

在处理证书路径时，证书使用应用程序可接受的证书策略必须出现在路径中的每个证书中，即 CA 证书和终端实体证书中。

阅读它，听起来它们可能不是数学上完美的子集（无论如何，我见过的通常是用英语编写的），但是当应用程序选择信任给定的最终实体时，整个路径的策略相关。

在实践中，我相信一个常见的例子是让主 CA 链引用一个相当通用的给定策略，但随后专门的 CA 及其颁发的证书可能会引用一个更严格的策略，该策略适合通用策略，用于特殊用途。