4、策略CA（Policy CA）的设计

策略CA，说白了就是PKI体系里的“立法机构”。根CA把权力下放给它，它不直接给用户发证，而是负责制定规则、审核下级CA的资质。我刚开始接触多层CA时，总觉得策略CA有点“虚”，好像就是个盖章的。直到有一次，一个下级CA的CPS写得漏洞百出，差点让整个体系的证书被浏览器拒信……嗯，从那以后，我再也不敢小看策略CA了。

4.1 策略CA的定位与职责

策略CA处于根CA和颁发CA之间。它的核心职责不是“干活”，而是“定规矩”和“管人”。

• 制定证书策略（CP）：定义证书适用于哪些场景，安全等级多高。
• 审核认证实践声明（CPS）：检查下级CA的操作流程是否符合CP要求。
• 签发CA证书：为下级颁发CA（颁发CA）签发证书，并设定路径长度约束。
• 交叉认证：与其他PKI体系的策略CA建立信任桥接。

我个人习惯把策略CA比作“质量监督局”。它不生产产品，但产品合不合格，它说了算。你想想看，如果没有这个监督层，每个颁发CA都按自己的理解写CPS，那整个体系就乱套了。

4.2 证书策略（CP）与认证实践声明（CPS）的定义

这两个文档是策略CA的核心产出。很多人分不清CP和CPS的区别，我简单解释一下。

维度	CP（证书策略）	CPS（认证实践声明）
定位	“法律条文”	“操作手册”
受众	依赖方、审计方	CA运营人员、审核员
内容	证书用途、安全等级、责任划分	密钥生成流程、身份验证步骤、CRL发布周期
粒度	粗粒度，原则性	细粒度，可执行
变更频率	低，通常一年或更久	高，随运营流程调整

举个例子：CP里写“所有证书申请者必须通过实名认证”，这就是原则。CPS里就要写清楚“实名认证需要提交身份证原件扫描件，并通过视频核身，核身时长不超过3个工作日”。

策略CA在签发下级CA证书时，会把CP的OID（对象标识符）写入证书的证书策略扩展项。这样，依赖方在验证证书链时，就能知道这张证书适用于哪些策略。

# 示例：OpenSSL配置文件中的策略映射
[ policy_mapping ]
1.2.3.4.5.6.1 = 1.2.3.4.5.6.1   # 映射到自身策略
1.2.3.4.5.6.2 = 1.2.3.4.5.6.1   # 其他策略映射到本策略

4.3 策略CA的密钥管理

策略CA的密钥管理，比根CA灵活一些，但比颁发CA严格得多。它处于中间位置，既要保证安全，又要兼顾效率。

4.3.1 密钥生成与存储

• 密钥长度：我个人建议至少使用RSA 4096位或ECC P-384。别用2048位了，审计那边不好过。
• 存储介质：必须使用硬件安全模块（HSM）。别想着用软密钥，我曾经见过一个项目，策略CA的私钥放在服务器硬盘上，结果被拖库了……那场面，惨不忍睹。
• 密钥备份：策略CA的私钥需要备份，但必须采用多方控制（M of N）。比如5个人持有碎片，至少3人同时在场才能恢复。

4.3.2 密钥使用周期

阶段	操作	责任人
生成	在HSM内生成，私钥不出卡	安全官 + 审计员
使用	仅用于签发下级CA证书和CRL	CA操作员
轮换	每3-5年轮换一次，同时生成新密钥对	安全官
归档	旧私钥导出加密归档，用于验证历史签名	审计员
销毁	HSM内执行销毁操作，出具销毁证明	安全官 + 审计员

这里有个细节：策略CA的私钥轮换时，旧密钥对不能直接删除。因为下级CA的证书是用旧密钥签发的，如果旧密钥没了，那些证书的签名就无法验证。所以，旧密钥要归档，但归档后的私钥必须标记为“仅用于验证”，不能再用来签名。

4.3.3 访问控制

策略CA的密钥使用，必须遵循“双人控制”原则。也就是说，任何一次签名操作，都需要两个人同时授权。我见过一些方案，用智能卡+PIN码实现双人控制，效果不错。

# 双人控制流程示例
1. 操作员A插入智能卡，输入PIN码，发起签名请求
2. 系统锁定，等待操作员B授权
3. 操作员B插入智能卡，输入PIN码，确认签名
4. HSM验证两个授权，执行签名操作
5. 记录审计日志：谁、什么时间、签发了哪张证书

你想想看，如果一个人就能操作策略CA的私钥，那内部作案的风险就太大了。双人控制虽然麻烦，但这是底线。

4.4 策略CA的核心逻辑图

下面这张图展示了策略CA在整个层级中的位置，以及它与CP、CPS、下级CA的关系。

从图中可以看出，策略CA是承上启下的关键节点。它从根CA获得授权，向下管理多个颁发CA。同时，它输出的CP和CPS文档，是整个PKI体系合规性的基石。

好了，策略CA的设计就聊到这里。记住，策略CA的核心是“定规矩”和“管密钥”。规矩定好了，密钥管住了，整个PKI体系就稳了一半。