我正在研究具有不同保证级别的 SMIME 和浏览器证书的颁发政策。
对于 S/MIME 和浏览器证书，我是否应该使用保证策略？
保证政策应适用于最终实体证书还是 CA？... 两个都？
我应该如何生成我的 OID？
2.5.29.32.0还是1.3.6.1.4.1.311.21.8.x.y.z.1.400（来源）最后，我假设我不应该将保证标记为关键，特别是如果我使用自定义 OID。
Microsoft 所谓的“颁发策略”或“保证”在X.509中称为证书策略（请参阅第 4.2.1.4 节）。证书策略定义如下：
在最终实体证书中，这些策略信息术语指示颁发证书所依据的策略以及证书的使用目的。在 CA 证书中，这些策略信息条款限制了包含此证书的证书路径的策略集。
OID的整个想法是在全球命名层次结构中唯一且明确地标识“对象”（实际上可以是任何东西，包括抽象概念）。因此，随机生成的 OID 完全违背了目的，不能宽恕。在证书策略的情况下，OID 应该“指向”一个特定的策略，即一个文件，它定义了证书的颁发条件和证书的用途。您应该获得一个 OID 子树：任何组织都可以从 IANA获得自己的子树（它是免费且永久的）。然后，您以任何您认为合适的方式在该子树中分配 OID。
话虽如此，证书策略作为RFC 5280 第 6 节中描述的证书验证过程的一部分是有意义的（具体参见 6.1.2 的步骤 (a)、6.1.3 的 (d)、(e) 和 (f) , 和 6.1.5 的步骤 (g))。验证过程计算对整个路径有效的证书策略集，即出现在路径中的每个证书中。有各种微妙之处，特别是在特殊通配符anyPolicy（即 2.5.29.32.0，Microsoft 称之为“所有发行”）和策略映射方面。但是，如果路径中的 CA 证书之一根本没有任何Certificate Policies扩展名，那么vallid_policy_tree将是NULL，即一切都化为乌有。证书路径将被“通用”验证，但不会产生任何具体确定的策略。
可悲的事实是，许多 CA 以 Microsoft 宣传的方式使用证书，即完全错误地认为他们应该做什么；相反，他们使用证书策略作为一种花哨的注释，软件将始终忽略（策略可以是相邻的限定符，可以是纯文本或指向可能是或可能不是可读文档的 URL）。
由于证书策略被如此彻底地滥用，因此使扩展至关重要是没有用的。在实践中，您添加带有指向 200 多页认证实践声明作为 PDF 文件的 URL 的扩展名，这至少表明您对您的 CA 业务是认真的，以至于您愿意沉迷于一些沉重的法律术语. 有关编写 CPS 的指南，请参阅RFC 3647。