我正在考虑如何设计和构造CP和CPS,以便以分层的方式构建多个CA,并与RFC 3647兼容。
从一个根CA构建到多个从属CA的CA结构,每个CA提供不同的PKI服务和证书配置文件:
根CA -> CP0和CPS0
现在,我知道了什么是OID,以及如何在证书中定义CP,以及CPS的URL。目前只有根CA使用OID 2.5.29.32.0定义了“任何策略”。每个从属CA都有自己的OID定义,因此对于它提供的PKI服务,应该有自己的CP和CPS。但是随着越来越多的Sub CP的出现,很难维护所有这些CP和CPS。
从CP和CPS的角度看,如何处理复杂的PKI环境的最佳实践是什么?
我应该开始在证书配置文件级别而不是在Sub CA上使用OID吗?在这种情况下,创建一个或两个CP,定义与可以颁发的证书相关的所有OID?
在这种情况下,可以有一个CP与:
因此,我只能维护CP的一个版本和与PKI服务相关的几个版本的CPS,或者只为整个环境维护一个CPS?
发布于 2017-10-16 19:54:30
嗯,你的设计对我来说是有意义的,而且可能是有效的。如果每个策略都有自己独特的过程(在CPS中定义),那么您可能需要创建与定义的不同策略一样多的策略。即使他们在同一个PKI管理机构下运作。
您的问题需要进行一些研究,以检查每种证书类型的程序。例如,issuing VPN certificates和issuing certificates for authentication with custom extension之间有什么区别吗?有什么不同?通常,最重要的区别包括(但不限于):
换句话说,对于单个PMA部分,§4.3和§4.4可以是不同的(其余段落在所有策略中通常是相同的),并且每个集合都需要单独的CP。然后,如果两个或多个can在相同的CPS下工作(对于可能呈现多个证书的软件来说没有重大差异,但只有特定的证书是基于策略接受的),那么您可以合并并将相同的CP/CPS分配给这些can。
例如,在CP1和CP4之间似乎没有明显的区别。您可以考虑将它们合并到一个CP中。就CP而言,CP3没有什么意义。证书包含一些额外的扩展实际上并不意味着什么,因为它(很可能)没有采用不同的实践和过程。你可以考虑完全摆脱这个CP。CP2可以与CP1和/或CP4合并。CP5是唯一一个似乎需要单独的CP的策略,因为这些证书(很可能)属于最高的保险级别和最严格的要求。
当您检查所有策略时,您可能只得到两个策略:分配给SubCA1-SubCA4的CP1和分配给带有相应OID2的SubCA5的CP2 (OID1和OID2)。
关于CP和CPS之间的映射。您可以创建单个CPS文档,并在同一文档中描述所有策略。如前所述,大多数章节(除第4.3节和第4.4节外)在所有政策中都是相同的,因为它们在相同的PMA下运作。并分别为每项政策提供第4.3节和第4.4节。
此外,我将检查CP5的条目。每个条目可能有不同的策略OID。用于商人访问和支付授权的证书看起来可能是一样的,但是会有一个软件来检查所提供的证书是否属于指定的类别(即使它们是在相同的CP和CPS下颁发的)。不确定它们是如何在您的环境中使用的。
提示:您不应该在根CA级别定义Certificate Policies扩展。根证书上缺少Certificate Policies扩展意味着它的Any Policy。首先,Certificate Policies外观应该在层次结构中的第2级。最有可能的是,所有CA都处于相同的管理控制之下,不需要为CA制定单独的策略。但是,如果根CA (或从属CA )是外包的,则可能需要迁移到根下具有专用策略CA的3层层次结构,该层次结构定义了归属于3级CA的策略。
https://security.stackexchange.com/questions/171411
复制相似问题