扩展（Key Usage如果存在）包含公钥允许的使用类型的详尽列表。当系统处理证书时，它是出于给定目的这样做的，因此必须验证Key Usage扩展（如果存在）是否允许该使用。具体来说，当系统分析 CA 证书并想要使用其公钥来验证另一个证书（据称是 CA 颁发的证书）上的签名时，这是一种“证书签名”用法；因此如果 CA 证书包含Key Usage扩展，那么系统将要求扩展包含keyCertSign标志。

没有什么可以阻止Key Usage扩展包含其他标志！验证仅是肯定的：系统检查他们想要的标志是否确实存在；他们从不检查他们不想要的标志是否缺席。

由于 CA 应该颁发证书和 CRL，因此一般来说，它应该具有keyCertSign和cRLSign标志。这两个标志就足够了。如果 CA 不打算签署自己的 CRL，那么它可以省略该cRLSign标志；但是，没有标志的 CA 没有keyCertSign什么意义。如果 CA 密钥还用于执行其他操作，则可能希望包含其他标志（尽管不建议这样做：一般规则是加密密钥应仅用于一件事）。可以想象，例如，通过使用 CA 的公钥加密已颁发证书的私钥来进行一些密钥托管，以便 CA 可以在某些条件下恢复私钥（当用户的密钥意味着用于数据加密）。

因此，没有什么可以阻止Key Usage扩展包含其他标志。或者，Key Usage扩展名可能完全丢失；这相当于“允许所有用途”。

微软的“离线 CRL 签名”只是“CRL 签名”的别称。实际上，您链接到的页面是这样说的：

若要在请求 CA 证书时应用此密钥用法，请在命令提示符处键入以下内容，然后按 Enter：

回声 03 02 01 06>File_Name.txt

我们在这里识别BIT STRING长度为 7 位的 ASN.1/DER 编码，其中第 5 位和第 6 位设置，第 0 到 4 位清零；这是Key Usage带有标志keyCertSign和cRLSign. 尽管他们使用自己的术语，但微软实际上符合这一点的标准（他们没有为“离线 CRL 签名”发明一个新的、非标准的密钥使用标志）。

以上都是对证书的正常解释。碰巧，就标准而言，“根 CA 证书”并不存在。“根”称为信任锚，主要由名称 (DN) 和公钥组成。将信任锚编码为“证书”是传统的做法，即遵循证书编码规则的字节序列（此类证书通常是自签名的，因为证书的格式具有用于“签名”的非可选插槽，所以那个槽里一定有东西）。

由于这是非标准的，因此在这种类似证书的结构中对证书扩展的解释对本地变体是开放的。一些实现以Key Usage上述方式解释根证书中的扩展。有些人完全忽略了这个扩展。

一般来说，如果“证书”是真实的，而不是为信任锚提供方便的编码容器，那么用内容填充根 CA 证书是安全的（对于互操作性），这些内容将是完全有效的。