GB/T —200×
GB/T —200×
目 次
IV前 言
V引 言
证书管理协议
11 范围
12 规范性引用文件
13 定义
14 缩略语
25 PKI管理概述
PKI管理模型
PKI实体的定义
PKI管理要求
PKI管理操作
56 前提与限制
终端实体初始化
初始注册/认证
私钥拥有证明
根CA的更新
107 数据结构
PKI消息综述
公共数据结构
与操作相关的数据结构
288 必需的PKI管理功能
根CA初始化
根CA密钥更新
下级CA初始化
CRL产生
PKI信息请求
交叉认证
终端实体初始化
证书请求
密钥更新
309 版本协商
支持的RFC 2510执行行为
32附 录 A （资料性附录） RA存在的原因
32附 录 B （资料性附录） PKI管理消息结构大纲（必须的）
大纲结构解释的通用规则
算法使用参数
所有权证明大纲结构
初始的注册/认证（基本认证方案）
证书请求
密钥更新请求
40附 录 C （资料性附录） PKI管理消息结构（可选的）
结构解释的通用规则
算法使用参数
自签名证书
根CA密钥更新
PKI信息请求/响应
交叉认证请求/响应（单向）
使用外部身份证书进行In-band带内初始化
46附 录 D （资料性附录） 请求消息行为说明
47附 录 E （资料性附录） 使用"口令短语"
48附 录 F （规范性附录） “可编译”的使用1988语法的模型
58附 录 G （资料性附录） 用于E-MAIL或者HTTP的MIME类型
前 言
本标准描述了PKI证书管理协议，定义了与证书产生和管理相关的各方面所需要的协议消息，主要包括：
申请证书
撤销证书
密钥更新
密钥恢复
交叉认证
本标准对应于RFC草案2510bis06。(英文版)
本部分的附录F为规范性附录，附录A、附录B、附录C、附录D、附录E、附录G为资料性附录。
附录A不是本标准的组成部分，它描述了RA存在的原因。
附录B不是本标准的组成部分，它详细描述了遵循本标准的实现必须支持的PKI消息。
附录C不是本标准的组成部分，它详细描述了遵循本标准的实现可以支持的PKI消息。
附录D不是本标准的组成部分，它说明了请求消息行为。
附录E不是本标准的组成部分，它描述了撤销请求中使用的"口令短语"。
附录F是本标准的组成部分，它提供模块，该模块包含了与证书管理协议相关的定义。
附录G不是本标准的组或部分，它描述了采用E-MAIL/HTTP传输协议时使用的MIME类型。
本部分由中国电子技术标准化研究所提出。
本部分由全国信息安全标准化技术委员会（TC260）归口。
本部分主要起草单位：北京创原天地科技有限公司。
本部分主要起草人：王炳艳、陈震琦、张科研。
本标准责任专家：吴亚非
引 言
公钥基础设施中总共有四类实体：CA、RA、终端实体、证书/ CRL库，如何保证四实体之间的通信安全、在证书业务中如何对四类实体进行管理，这些问题是本标准解决的主要问题。
本标准中如果存在与国家现行安全管理政策不一致的地方，以国家现行安全管理政策为准。国家现行安全管理政策中没有说明的部分，以本标准为准。
实现者应该注意到缺陷解决过程的存在以及校正可以用技术勘误表的形式施加到本标准。相同的校正可用实现者指南的形式施加到本标准。
信息技术 安全技术 公钥基础设施
证书管理协议
1 范围
本标准描述了PKI证书管理协议，定义了与证书产生和管理相关的各方面所需要的协议消息，主要包括：
申请证书
撤销证书
密钥更新
密钥恢复
交叉认证
本标准主要适用于在安全或不安全环境中实施PKI组件并实施管理，可用于PKI运营机构、PKI组件开发者的参考指南。
2 规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。
- 互联网证书请求消息格式(draft-ietf-pkix-rfc2511bis-04)
3 定义
下列术语在x509V4术语中定义：
a) 公钥基础设施(PKI - Public Key Infrastructure)
b) 认证机构 (CA – Certification Authority)
c) 终端实体(EE – End Entity)
d) 证书撤销列表（CRL – Certificate Revocation List ）
e) 单向函数(OWF – one-way function)
f) 注册机构(RA – Registration Authority)
其它术语：
a) 交叉证书(cross-certificate)
b) 主体(subject)
c) 签发者(issuer)
d) 个人安全环境（PSE – Personal Security Environment）
e) 拥有证明(POP – Proof of Possession)
f) 轻型目录访问协议(LDAP – Lightweight Directory Access Protocol)
g) 初始认证密钥（IAK – Initial Authentication Key）
h) 消息认证码(MAC – Message Authentication Code)
4 缩略语
下列缩略语适用于本标准：
CA 认证机构
RA 注册机构
CRL 证书撤销列表
PKI
公钥基础设施
PSE 个人安全环境
POP 拥有证明
PKCS 公钥密码体制
5 PKI管理概述
PKI的建设必须能够满足不同类型的管理者的要求。给予管理员们无限制的选择，不仅会增加软件的复杂程度，而且还增加了管理员或软件开发者犯一些令人费解的错误的可能性，并因此而导致极大的安全隐患。同样，如果你用烦琐的机制限制管理员的行为，那么他们就不会再用你的PKI了。
PKI管理协议需要支持PKI实体间的在线交互。例如：在CA系统和具有密钥对的客户系统之间，在两个彼此签发交叉证书的CA之间，都可能使用这样的管理协议。
PKI管理模型
在详细阐述特定的消息格式和流程之前，我们首先要定义一下PKI管理中所涉及到的实体以及它们之间的交互行为（根据PKI管理所需的功能）。然后我们再对这些功能进行归类，以包含可以确定的不同类型的终端实体。
PKI实体的定义
PKI管理中所涉及到的实体包括终端实体和认证机构。注册机构也可以被包括在内。
主体和终端实体
终端实体是不以签署证书为目的而使用其私钥的证书主体或者是依赖（证书）方。
“主体”在此处是指被授予证书的实体，一般在证书的主体或主体可替换名字段中指定。当要区分主体所使用的工具和/或软件（例如：一个本地的证书管理模块），我们使用术语“主体设施”。 通常，我们优先使用术语“终端实体”而不是“主体”，以防止与证书字段名中的主体相混淆。
需要着重指出的是：终端实体在此处不仅包括应用软件的使用者，也包括软件本身（例如IPSec的情况）。这一因素影响着PKI管理操作所使用的协议；例如，与个人用户相比，应用软件更有可能确切知道需要使用证书中的哪个扩展项。PKI管理实体也被看作为一个终端实体，因为他们有时候也在证书（或交叉证书）的主体或主体可替换名字段中被指定。如无特殊说明，术语“终端实体”将不会被用来指代PKI管理实体。
所有的终端实体都需要安全可靠的访问一些本地信息，至少包括：实体自己的名字和私钥，被该实体直接信任的CA的名字及其公钥（或公钥指纹，如果可以通过其它的方式得到自签名证书）。软件实现可以使用安全本地存储机制存储上述信息，但不限于上述信息（例如：还可以包括用户自己的证书以及应用软件特有的信息）。存储方式也可以不同，例如普通的文件或抗攻击的密文存储介质。象这样安全的本地存储在这里被称之为终端实体的个人安全环境。
尽管有关PSE格式的内容已经超出的本文的范围（与设备及其他信息相关），但这里定义了一种通用的PSE数据交换格式 – 认证响应消息。
认证机构
认证机构是负责创建和分配证书，受用户信任的权威机构。用户可以选择该机构为其创建密钥。
从终端实体的角度出发，CA可以是，也可以不是一个事实上真正的“第三方”。绝大多数情况下，CA与其所服务的终端实体属于同一个机构。
同样，我们使用术语“CA”指代证书中签发者(issuer)字段所代表的实体。当需要与CA所使用的软硬件工具相区分时，我们使用术语“CA设施”。
CA设施一般包括离线模块和在线模块，只有CA的离线模块可以使用CA的私钥。尽管是否这样做与CA的政策相关，但这取决于软件实现者。
我们使用术语“根CA”来指代被终端实体直接信任的CA；即安全地获取根CA的公钥需要一些带外的步骤。这一术语并不意味着根CA必须处于CA体系层次的顶层，它只是说明该CA是被终端实体直接信任的。
“下级CA”（子CA）不是终端实体的根CA。通常，下级CA不是任何实体的根CA，但这并不是强制的。
注册机构
注册机构是为用户办理证书申请，身份审核，证书下载、更新、注销以及密钥恢复等实际业务的办事机构工业务受理点，也叫证书注册审核中心。
除了终端实体和CA之外，很多应用环境要求把注册机构从认证机构中独立出来。RA所具有的功能将因情况不同而有所不同,可能包括个人身份鉴定，介质分发，作废报告，名称分配，密钥产生，密钥归档等等。
本文将RA作为可选的组成部分，当RA不存在时，假定CA可以实现RA的功能，所以，从终端实体的观点看，它们都使用相同的PKI管理协议。
同样，当需要区分RA和RA所使用的工具时，我们使用“RA设施”这个术语。
应该注意到RA本身也是一个终端实体。我们进一步假设RA是一个被验证了的终端实体，它有可用于数字签名的私钥。CA设施如何把某些终端实体认定为RA则是一个实现问题（本文不阐述特定的RA认证操作）。我们并不强制RA必须可以被与其正通信的CA所认证（所以一个RA可以只被认证一次，与多个CA协同工作）。
在某种情况下，即使存在RA，终端实体可能仍然需要和CA直接通信。例如，在RA进行登记和接受审核，而直接与CA通信来更新证书。
PKI管理要求
本协议将适应以下PKI要求：
1、 PKI管理必须符合ISO 9594-8 标准及相关改进意见（指证书扩展项）。
2、 PKI管理必须符合PKI系列草案的其他标准。
3、 必须能够在不影响其他密钥对的前提下定期地更新任意密钥对。
4、 为了使调整简单易行，在PKI管理协议中应尽可能少的使用加密。
5、 PKI管理协议必须允许使用不同的工业标准加密算法（特别是RSA，DSA，MD5，SHA-1）。这意味着，原则上，任何给定的CA、RA或终端实体，可以使用任何适合其所拥有的密钥对的算法。
6、 PKI管理协议一定不能排除密钥对由相关的终端实体或RA或CA产生。密钥产生也可以在其它地方完成，出于PKI管理的目的，我们可以认为密钥生成发生在密钥第一次出现在的地方：终端实体、RA或CA。
7、 PKI管理协议必须能够支持相关终端实体或RA、CA进行证书发布。在不同实现和不同的环境下可以采用上面任何一种方法。
8、 PKI管理协议必须允许通过认证的终端实体请求作废证书，以签发CRL。这一功能必须能够尽可能防止拒绝服务攻击。
9、 PKI管理协议必须能够使用各种不同的传输机制，特别是邮件传输协议、HTTP、TCP/IP和FTP。
10、签发证书的最终决定权属于CA。RA或终端实体都不能假定CA签发出来的证书就是符合他们的全部要求。CA可以根据其运营政策，改变一个证书字段的值，或者添加、删除、修改证书扩展项。换句话说，所有的PKI实体（终端实体、RA、CA）都必须能够处理那些与其请求不一致的证书响应（例如：CA可能会缩短你的证书有效期）。CA政策可能作出规定，在证书请求者检查并接受新签发的证书之前，CA机构不能发布或分发该证书（通常使用证书确认(certConf)消息完成这一功能）。
11、 PKI管理协议必须能够支持未泄密的CA密钥对的更新（即CA密钥更新）（注意：如果CA发生密钥泄露，那么该CA所辖的全部实体都必须重新进行初始化操作）。在CA密钥更新以后，PSE中包含CA新公钥的终端实体，必须仍然能够验证使用旧的CA公钥能够验证的证书。直接信任旧的CA密钥对的终端实体，也必须能够验证新的CA私钥所签发的证书（CA的旧公钥被物理地写入终端实体的加密设施的情况下要求做到这一点）。
12、在某些实现或情况下，RA的功能可能会由CA来承担。PKI管理协议的设计，必须满足下面的条件：终端实体不管与CA还是RA通信都应该使用相同的协议。
13、当终端实体发出的证书请求带有公钥时，它必须能够证明它拥有相应的私钥。可以用不同方法完成此项工作，究竟采用哪一种取决于认证请求的类型。关于证书管理协议消息中定义的带内方法完成以上工作的详细内容，请参阅节“私钥拥有证明”。
PKI管理操作
下图描述了PKI管理操作所定义的各个实体间的关系。可以沿着字母标明的线路发送PKI消息。
图1 PKI实体
在上层，各种PKI操作可以按下列方式分组：
1、 CA的建立。当建立一个新的CA时，需要完成某些必要的操作（例如：发布初始CRL，导出CA公钥）。
2、 终端实体初始化：包括导入根CA公钥，以及获得PKI管理实体所支持的可选项信息。
3、 认证：各种操作都将导致创建新的证书：
初始注册和认证：这一过程用于终端实体在CA为它签发证书之前第一次向CA或RA表明自己的身份。这一过程的最终结果（成功时）是CA为终端实体的公钥签发证书，将该证书返回给那个终端实体和/或将该证书发布到公共的数据仓库中。这一过程通常包括多个“步骤”，还可能包括终端实体设施的初始化过程。例如，终端实体设施必须能够安全的导入CA公钥，以用来验证证书路径。此外，终端实体通常还需要导入自己的密钥对。
密钥对更新：任何密钥对都需要定期更新（即用新的密钥对替换旧的密钥对），相应的需要签发一个新的证书。
证书更新：由于证书会过期，如果其他相关信息没有变化，那么证书就可以被“刷新”。
CA密钥对更新：同终端实体一样，CA密钥对也需要定期更新，但需要不同的机制。
交叉认证请求：一个CA请求另一个CA签发一个交叉证书。为了达到这一目的，我们定义了下面的术语。一个“交叉证书”是这样一个证书：主体CA与签发者CA完全不同，主体公钥信息(SubjectPublicKeyInfo)字段包含着验证密钥（即该证书是为主体CA的签名密钥对签发的）。当需要更细致的区分时，我们使用下面的术语：“域间交叉证书” - 如果交叉证书的主体CA和签发者CA属于不同的管理域；其它的交叉证书则称作“域内交叉证书”。
注意1：上面所定义的“交叉证书”与X509中定义的“CA证书”是并列的。注意不要把“交叉证书”同X509中的“cACertificate”属性相混淆，它们之间没有联系。
注意2：除非特别说明，否则一般认为术语“交叉证书”指的就是“域间交叉证书”。
注意3：交叉证书的签发可以是相互的（但并非必须这样做）；换句话说，两个CA可能彼此为对方签发交叉证书。
交叉证书更新：与普通证书更新类似，不同之处就在于它操作的是交叉证书。
4、 证书/CRL搜索操作：某些PKI管理操作将导致发布证书或CRL。
证书发布：产生证书之后，就需要某些方法发布这些证书。PKIX中定义的方法可以是中规定的消息，或者是[RFC2559, RFC2585]（PKIX系列规范的“操作协议”方案）中描述的其他方法（例如：LDAP）。
CRL发布：与证书发类似。
5、 恢复操作：当一个PKI实体“丢失”它的PSE时，需要某些PKI操作完成恢复工作。
密钥对恢复：作为可选操作，用户密钥资料（例如用户的解密密钥）可以由CA、RA或与CA或RA相关的密钥备份系统进行备份。如果一个实体需要恢复它已经备份的密钥资料（例如忘记了私钥保护密码或丢失了密钥链文件），就需要一个支持密钥恢复的协议消息。
6、 撤销操作：某些PKI操作将需要创建新的CRL条目或新的CRL。
撤销请求：一个经过授权的人向CA发出异常情况警告并要求撤销证书。
7、 PSE操作：PSE操作（例如转移PSE、更改口令等）的定义超出了本规范的范围，这里我们还是定义了一个PKI消息（CertRepMessage），它可以作为该操作的基础。
注意：在线协议并非实现以上操作的唯一途径。对任何一个操作来说，离线方法可以达到同样的效果，本规范也并不强制使用在线协议。例如：当使用硬件介质时，很多操作都通过物理介质传送的来完成。
后面的章节定义了一组支持以上操作的标准消息。用于在不同环境中传送这些消息的传输协议（基于文件的、在线、E-mail和WWW）的定义，已经超出了本文的范围，将在其它文档中单独说明。
6 前提与限制
终端实体初始化
对于每一个终端实体，在与PKI管理实体进行交互之前，首先要申请获得一些信息，包括获得PKI系统所支持的功能、安全获得相关根CA的公钥。
初始注册/认证
终端实体的初始化注册和认证有很多种方案。由于CA执行的政策各不相同，并且终端实体的类型也有所不同，因此没有一种方案能适应所有的环境。
然而，我们可以对本规范支持的初始化注册和认证方案进行分类。注意在上面的描述中，‘初始(initial)’这个词非常关键 – 这种情况下讨论中的终端实体与PKI还没有任何的联系。当终端实体已经拥有认证过的密钥对时，就可以进行简化或选择其它的方案。
在对本规范支持的方案分类后，我们可以规定一些方案为强制性的，一些为可选择的。目的是使强制性的方案能够覆盖到大多数的实际应用，而可选方案满足一些不是很常用的应用。这样，我们在系统的灵活性和系统实现的简便上进行了折衷。
下面，我们就要详细介绍初始化注册和认证方案的分类。
使用的标准
注册/认证的启动
就产生的PKI消息而言，我们可以认为初始化注册/认证的启动发生在产生第一条与终端实体相关的PKI消息的地点。注意，在现实世界中，注册/认证流程的启动可能发生在别的地方（比如，可能是人事部门打电话给一个RA操作员）。
可能的场所是在终端实体，RA或者CA。
终端实体消息来源的认证
终端实体产生的请求证书的在线消息可以是通过认证的，也可以是没通过的。这里要求认证从终端实体发给PKI(CA/RA)的任何消息的来源。
在本规范中， 这种认证由PKI（CA/RA）通过带外方式向终端实体发放秘密数据（初始认证密钥）和参考数据（用于识别密钥）来完成。然后，初始认证密钥就可以用来保护相关的PKI消息了。
因此，我们可以通过判断终端实体发送给PKI系统的在线消息是否经过认证对初始注册/认证方案进行分类。
注解 1: 我们不讨论对PKI系统发给终端实体的消息的认证，因为这是必需的。在所有情况下，在终端实体设施安装根CA的公钥或基于初始认证密钥都可以实现这一认证。
注解 2: 如果终端实体发送的消息通过带外方式被认证，那么可以认为初始注册/认证流程是安全的。
密钥产生的地点
在本规范中, 认为“密钥产生”的地点是密钥（无论是公钥还是私钥）第一次在PKI消息中出现的地方。注意，这不排除有一个密钥集中产生的服务 - 密钥可以在其他地方产生然后使用一个（自定义的或者标准的）密钥产生请求/响应协议（该协议不在本规范的讨论范围之内）导入到终端实体、RA或CA/KM中。
密钥产生的地点有三种可能：终端实体、RA或者CA/KM。
成功认证的确认
在为一个终端实体创建初始证书以后, 通过让终端实体显式确认成功地接收到了包含证书（或表明证书已生成）的消息，可以得到附加的保证。当然，这个确认消息必须受到保护（通过初始认证密钥或者其他方式）。
这又提供了两种可能性: 确认的或者未确认的。
强制的方案
上面的标准考虑到了大多数的初始注册/认证方案。要求符合本规范的CA设施，RA设施和终端实体设施必须支持下面的第二种方案。如果需要的话，任何实体还可以支持其它的方案。
集中方案
按照上面的分类标准，这种方案可能是最简单的：
- 启动发生在进行认证的CA；
- 不要求在线消息的认证；
- 密钥由进行认证的CA产生(参见 )；
- 不要求确认消息。
从消息流的角度来看，本方案意味着只要求一个由CA发送给终端实体的消息。这个消息必须包含终端实体的全部PSE信息。必须提供一些带外方式以便终端实体认证接收到的消息并解密加密数据。
基本认证方案
按照上面的分类标准，本方案如下：
- 启动发生在终端实体；
- 要求进行消息认证；
- 密钥由终端实体产生(参见)；
- 要求确认消息。
从消息流的角度来看，基本认证方案如下：
终端实体 RA/CA
========== =============
带外方式分发初始认证密钥（IAK）和参考数据（RA/CA -> EE）
产生密钥
生成认证请求
利用IAK保护请求
-->>----------认证请求---------->>--
验证请求
处理请求
生成认证响应
--<<------认证响应---------<<--
处理响应
生成确认消息
-->>--------证书确认消息-------->>--
验证确认消息
生成响应
--<<--- 确认 ack (可选的) ----<<--
处理响应
在验证证书确认消息失败的情况下，如果新签发的证书已经发布或者可以由其它的方式获得，那么CA/RA必须撤销该证书。
私钥拥有证明
为了防止某些攻击，使CA和RA能够有效地验证终端实体和密钥对间的绑定是否合法，这里定义一种PKI管理操作，终端实体可以通过这种操作证明自己拥有(即能够使用)与为之申请证书的公钥相对应的私钥。一个 CA/RA在认证交换时可以自由选择如何实现POP（例如带外方式或带内方式），即如何实现是一个政策问题。然而, 要求CA/RA必须通过某种方式实现POP，因为目前有很多非PKIX的操作协议在用（例如各种电子邮件协议），而这些协议并不显式验证终端实体和私钥间的绑定。除非验证绑定(签名、加密和密钥协商密钥对)的操作协议的确存在，而且广泛存在，否则只能假设绑定被RA/CA验证。因此，如果绑定没有被RA/CA验证，那么PKI证书就会因为没有什么意义而终止。
按照证书申请中的密钥对类型的不同，POP通过不同的方式完成。如果是一个多种用途的密钥（比如RSA密钥），那么，任意一种适当的方法都可以使用(例如，如果一个密钥可以用于签名以及其它应用，那么就不能将它送到CA/RA去验证POP)。
本规范允许下列情况，终端实体向RA提供相关证明，随后RA向CA说明需要的证明已经完成(并验证)。例如：一个想要申请签名证书的终端实体向RA送去签名信息，RA随后通知CA终端实体已经提供了要求的证明。当然，某些政策可能不允许这种情形（例如，CA可能是认证过程中唯一可以验证POP的实体）。
签名密钥
对于签名密钥，终端实体通过对一个数据签名来证明拥有私钥。
加密密钥
对于加密密钥， 终端实体可以将私钥提供给CA/RA，或者通过解密一段数据来证明对私钥的拥有（参见）。 解密数据可以是直接方式也可以是间接方式。
直接的方式是RA/CA给终端实体发送一个随机的挑战数，同时要求终端实体立即返回响应。
间接的方式是给终端实体返回加密的证书（让终端实体在确认消息中证明它能解开这个证书）。这使得CA签发的证书只有预期的终端实体才能使用。
本规范鼓励使用间接方式，因为这种方式不需要发送额外的消息 （即可以使用消息三元组{请求,响应,确认}来证明）。
协商密钥
对于协商密钥，为了证明终端实体拥有私钥，终端实体和PKI实体（RA或者CA）必须建立一个共享的密钥。
注意，这种方法并不需要对CA可以认证的密钥做什么限制 - 对于Diffie-Hellman 密钥，终端实体可以自由选择它的算法参数 – 只要CA 可以在需要时可以利用适当的参数生成短期(或一次性)的密钥。
根CA的更新
这里只描述对某些终端实体来说是根CA的情况。
这里所描述流程的基础是CA利用旧私钥保护新私钥同时利用新私钥保护旧私钥。因此，当CA更新密钥对时，如果证书要在目录服务器发布，则必须生成两个额外的cACertificate属性值(这样共有四个：OldWithOld; OldWithNew; NewWithOld; 以及 NewWithNew)。
当一个CA更改密钥对的时候，那些已经通过带外方式持有该CA旧公钥的终端实体受到的影响最大。这些终端实体需要访问由旧私钥保护的CA新公钥。然而，他们只在一个有限的时间段需要这一证书（直到他们通过带外方式获得新的CA公钥）。通常，当这些终端实体的证书到期的时候，这自然便实现了。
用来保护新旧CA公钥的数据结构不是新的数据结构，是标准的证书结构（也可能包含扩展项）。
注意 1. 为了支持v1版本证书，目前的方案没有利用任何 v3的证书扩展项。密钥标识(KeyIdentifier) 扩展项的存在是为了提高效率。
注意 2. 可以将这一方案进行推广，以适应CA在它的任一终端实体证书的有效期内多次更新自己密钥对的情形，但这种推广似乎没有什么价值。不作这种推广仅仅意味着CA密钥对的有效期必须比用这对密钥签发的所有证书的有效期都长。
注意 3. 本方案确保终端实体最晚将在它所拥有的由CA旧公钥签发的最后一个证书过期时获得CA新公钥(通过带外方法)。发生在其它时候的证书和/或密钥更新操作并不要求这一点（这依赖于终端实体设施）。
CA操作员的行为
要更新CA的密钥，CA操作员要完成以下操作：
1. 产生新密钥对；
2. 产生一个用新私钥为旧公钥签名的证书 (“old with new”证书)；
3. 产生一个用旧私钥为新公钥签名的证书 (“new with old”证书)；
4. 产生一个用新私钥为新公钥签名的证书 (“new with new”证书)；
5. 通过数据仓库或其它方式发布这些新证书(可能使用CAKeyUpdAnn消息)；
6. 导出CA新公钥，这样终端实体就可以通过带外方式获得 (如果需要的话)。
旧CA私钥将不再使用。但旧CA公钥还会延续使用一段时间。当CA所属的终端实体都已经安全地获得了CA新公钥的时候，旧公钥就不再使用了（防抵赖除外）。
"old with new"证书的有效期必须从旧密钥生成的时间开始，到旧公钥到期的时候结束。
"new with old"证书的有效期必须从新密钥对生成的时间开始，到足以保证所有终端实体都得到了新的CA公钥时结束（最晚到旧公钥到期的时候）。
"new with new"证书的有效期必须从新密钥对生成的时间开始，到CA下一次更新其密钥时或CA下一次更新其密钥之前结束。
验证证书
通常在验证签名的时候，验证者要验证包含签名者公钥的证书。 然而，一旦允许CA更新密钥，就会出现很多新的可能性，如下表所示：
密钥库包含了新的和旧的公钥
密钥库只包含旧公钥(例：推迟发布)
PSE包含新公钥
PSE包含旧公钥
PSE包含新公钥
PSE包含旧公钥
签名者的证书由新公钥来保护
情况1: 这是一种标准的情况，验证者不需要访问数据仓库，可以直接验证证书
情况3: 这种情况下验证者必须访问数据仓库以获得新公钥
情况5: CA操作员没有更新数据仓库，但验证者可以直接验证证书(与第一种情况相同)
情况7: 在这样的情况之下CA操作员没有更新数据仓库,因此验证过程将会失败
签名者的证书由旧公钥来保护
情况2: 在这样的情况下,验证者要提必须访问数据仓库获取旧公钥
情况4: 在这样的情况下，验证者不需要访问数据仓库，可以直接验证
情况6: 验证者认为这种情况和情况2是一样的，会访问数据仓库，但是验证会失败
情况8: CA操作员没有更新数据仓库，但验证者可以直接验证，与情况4相同
在情况1, 4, 5和8下的验证
在这样的情况下，验证者拥有CA公钥的一份本地拷贝，可以用来直接验证证书。这种情况与没有密钥更新时是一样的。
注意 第8种情况会在CA操作员已经生成了新密钥和将新密钥导入系统之间的时候出现。情况5当上面的间隙期间CA操作员已经发布了签名者和验证者的证书的时候会出现（CA操作员要尽量避开这样的情况）
在情况2下的验证。
在情况2下，验证者必须得到CA的旧公钥。验证者执行下列操作：
1. 在数据仓库中查找caCertificate属性，获得OldWithNew证书（基于有效期来判断，注意主体和签发者字段必须匹配）；
2. 利用CA新密钥（验证者本地拥有的）验证该证书是否正确；
3. 如果正确，利用CA旧密钥验证签名者的证书。
当CA操作员先为签名者签发了证书，更新CA密钥后，又为验证者签发证书时，会发生这种情况，因此这是一种很典型的情况。
在情况3的验证
在第3种情况下，验证者必须要取得CA的新公钥，验证者执行下列操作：
1. 在数据仓库中查找caCertificate属性，获得NewWithOld证书（基于有效期来判断，注意主体和签发者字段必须匹配）；
2. 利用CA旧密钥（验证者本地拥有的）验证该证书是否正确；
3. 如果正确，利用CA新密钥验证签名者的证书。
当CA操作员先为验证者签发了证书，更新CA密钥后，又为签名者签发证书时，会发生这种情况，因此这也是一种很典型的情况。
在情况6下的验证失败。
在这种情况下CA已经为验证者签发了包含新密钥的PSE但尚未更新数据仓库中的属性。这意味着验证者无法得到可信赖的CA的旧密钥，所以验证失败。
注意，失败是由CA操作员的错误造成的。
在情况7下的验证失败。
在这种情况下，CA已经用新密钥为签名者签发了证书但尚未更新数据仓库中的属性。这意味着验证者无法得到可信赖的CA旧密钥，所以验证失败。
注意，失败仍然是由CA操作员的错误造成的。
作废 – CA密钥的改变
如上所述，一旦允许更改CA密钥，那么证书的验证将变得更为复杂。对于作废检查也有同样的问题，因为CA可能利用新私钥而不是用户PSE中已经存在的私钥签发CRL。
对各种情形的分析与证书验证相同。
7 数据结构
本节描述PKI 管理消息所需要的数据结构。第8节描述每一种管理操作对值的限制和事件的发生顺序。
PKI消息综述
本规范中所有用于PKI管理的消息都采用下面的结构：
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL
}
PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage
PKIHeader包含许多PKI消息公有的信息。
PKIBody包含与具体消息相关的信息。
PKIProtection字段是可选的，包含对PKI消息进行保护的比特串。
extraCerts字段可以包含对接收者来说可能有用的证书。例如，CA或RA可以利用这一字段向终端实体提供它验证自己的新证书时所需要的证书(例如，如果签发终端实体证书的CA对它来说不是一个根CA)。注意，这个字段不一定包含一个证书链 –为了使用证书接收者可能需要对这些证书进行分类、选择或其它处理。
PKI消息头
所有的PKI消息都要求某些头信息用于寻址和交易标识。某些这样的信息同时出现在与传输相关的信封中；不管采用哪种方法，如果PKI消息受到保护，那么这些信息将同样受到保护(即我们不做安全传输的假定)。
下面的数据结构用于保存这些信息：
PKIHeader ::= SEQUENCE {
pvno INTEGER { cmp1999(1), cmp2000(2) },
sender GeneralName,
-- 标识发送者
recipient GeneralName,
-- 标识预期的接收者
messageTime [0] GeneralizedTime OPTIONAL,
--产生这个消息的时间(当发送者认为该时间的传输合适时使用，
--即接收方接收到消息时这个时间仍有意义）
protectionAlg [1] AlgorithmIdentifier OPTIONAL,
-- 用于计算protection比特的算法
senderKID [2] KeyIdentifier OPTIONAL,
recipKID [3] KeyIdentifier OPTIONAL,
-- 标识用于保护的特定密钥
transactionID [4] OCTET STRING OPTIONAL,
-- 标识交易；即在相关的请求、响应和确认消息中，该字段值相同
senderNonce [5] OCTET STRING OPTIONAL,
recipNonce [6] OCTET STRING OPTIONAL,
-- 用于防止重放攻击的随机数，senderNonce由消息的创建者赋值，
-- recipNonce是由本消息的预期接收者先前插入到相关消息中的随
-- 机数
freeText [7] PKIFreeText OPTIONAL,
-- 可以用于表示上下文相关的说明（本字段主要由人工使用）
generalInfo [8] SEQUENCE SIZE (1..MAX) OF
InfoTypeAndValue OPTIONAL
-- 可以用于表示上下文相关的说明
-- (本字段不是供人工使用的)
}
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
-- 按UTF-8[RFC2279]编码的文本(注意：每一个UTF8String都可以包含
-- 一个RFC 1766/RFC 3066语言标签，用于表示所包含文本属于哪一种语
-- 言–详情请参见[RFC2482])
对于该版本pvno字段取固定值2。
sender字段包含PKIMessage发送者的名字。这个名字(与senderKID一起，如果提供的话)应当能够标识出对这一消息的保护进行验证所需要的密钥。如果发送方实体并不清楚自己的任何信息(例如：在初始化请求消息中，终端实体并不清楚自己的DN、电子邮件、IP地址等)，那么"sender"字段必须包含一个"NULL"值；即一个长度为0的SEQUENCE OF。在这种情况下，senderKID字段必须包含一个标识符(即一个参考数)，这个标识符能够向接收者表明验证消息所用共享密钥信息。
recipient字段包含PKIMessage接收者的名字。这个名字(与recipKID一起，如果提供的话)应当可以用于验证对消息的保护。
protectionAlg字段指明保护消息所用的算法。如果没有提供保护比特位(注意PKIProtection是可选的)，那么必须省略这个字段；如果提供了比特位，那么必须提供这个字段。
senderKID和recipKID用于标识使用了哪个密钥保护消息(recipKID通常仅在使用Diffie-Hellman密钥保护消息时才要求)。如果要求唯一标识一个密钥就必须使用这些字段(例如：如果一个发送者的名字与多个密钥相关联)，否则就应当省略这些字段。
消息头中的transactionID字段用于使消息的接收者将这个消息与正在进行的交易相关联。所有仅通过一个请求/响应对不能完成操作的交易都需要使用这个字段。 对于通过一个请求/响应对能够完成操作的交易规则如下。客户端可以对请求中的transactionID赋值。如果服务器接收到设置了transactionID字段的请求，那么它必须在响应中设置相同的值；如果服务器接收到一个没有设置transactionID字段的请求，那么它可以在响应中设置这个字段。
对于包含多请求/响应对的交易来说规则如下。客户端应当为第一个请求产生一个transactionID。如果服务端接收到到设置了transactionID字段的请求，那么它必须在响应中设置相同的值；如果服务器接收到一个没有设置transactionID字段的请求，那么它必须为响应中的transactionID设置一个服务端产生的ID值。后续的请求和响应都必须设置为按前面的规则确定的值。在所有使用transactionID的情况下，客户端在任何时候都不可以为正在进行中的不同交易设置相同的transactionID(到一个给定的服务器)。服务器是否要求transactionID唯一可以自由选择，但必须能够正确地将消息与交易关联起来。这意味着服务器要求{client, transactionID}对唯一，甚至要求transactionID唯一（如果它不能够基于传输层信息来区分不同的客户端）。一个服务器接收到交易(要求多请求/响应对)的第一个包含transactionID但不符合上述限制的消息时(尤其是transactionID已经在使用的情况下)，它必须返回一个PKIFailureInfo设置为transactionIdInUse的ErrorMsgContent。建议客户端在交易开始时为transactionID设置128字节的(伪)随机数以减少服务器端transactionID在用的可能性。
senderNonce和recipNonce字段保护PKIMessage免受重放攻击。SenderNonce通常是一个由发送方产生的128比特的(伪)随机数，而recipNonce是从本交易的前一个消息的senderNonce字段拷贝的。
messageTime字段包含发送者创建这个消息的时间。可以由终端实体用于校正/检查自己的本地时间以便与中央系统的时间保持一致。
freeText字段可以用于发送一个人可读的消息给接收者(用任意多种语言)。这个序列中的第一种语言表明响应期望使用的语言。
generalInfo字段可以用于向接收方发送机器可读的额外的数据。可以支持下面定义的generalInfo扩展项。
隐式确认
由终端实体用于通知CA它不想为签发的证书发送证书确认。
implicitConfirm OBJECT IDENTIFIER ::= {id-it 13}
ImplicitConfirmValue ::= NULL
如果CA同意终端实体的请求，它必须在响应中的PKIHeader中设置相同的扩展项。如果终端实体在响应中没有找到这个扩展项，它必须发送证书确认。
确认等待时间
由CA用于通知终端实体，它最多等待多长时间来接收证书确认而不作废证书和删除交易。
confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14}
ConfirmWaitTimeValue ::= GeneralizedTime – CA将要等待的时间
PKI消息体
PKIBody ::= CHOICE { -- 与消息类型相关的消息体和参考章节
ir [0] CertReqMessages, --初始化请求 ()
ip [1] CertRepMessage, --初始化响应()
cr [2] CertReqMessages, --认证请求()
cp [3] CertRepMessage, --认证响应()
p10cr [4] CertificationRequest, --PKCS #10认证清求 [PKCS10]
popdecc [5] POPODecKeyChallContent --POP挑战 ()
popdecr [6] POPODecKeyRespContent, --POP响应 ()
kur [7] CertReqMessages, --密钥更新请求 ()
kup [8] CertRepMessage, --密钥更新响应()
krr [9] CertReqMessages, --密钥恢复请求 ()
krp [10] KeyRecRepContent, --密钥恢复响应 ()
rr [11] RevReqContent, --作废请求()
rp [12] RevRepContent, --作废响应()
ccr [13] CertReqMessages, --交叉认证请求()
ccp [14] CertRepMessage, --交叉认证响应 ()
ckuann [15] CAKeyUpdAnnContent, --CA密钥更新公告()
cann [16] CertAnnContent, --证书公告 ()
rann [17] RevAnnContent, --作废公告 ()
crlann [18] CRLAnnContent, --CRL公告 ()
pkiconf [19] PKIConfirmContent, --确认 ()
nested [20] NestedMessageContent,--嵌套消息 ()
genm [21] GenMsgContent, --通用消息 ()
genp [22] GenRepContent, --通用响应 ()
error [23] ErrorMsgContent, --错误消息 ()
certConf [24] CertConfirmContent, --证书确认 ()
pollReq [25] PollReqContent, --轮询请求 ()
pollRep [26] PollRepContent --轮询响应 ()
}
每一种类型将在中描述。
PKI消息保护
某些PKI消息需要保护完整性。(注意，如果使用非对称算法保护消息并且相应公钥部分已经被认证，那么消息的来源也可以被证明。另一方面，如果公钥部分未被认证，那么消息来源不能自动被证明，但可以通过带外方式被认证。)
protection的结构如下：
PKIProtection ::= BIT STRING
计算PKIProtection时输入的是下面数据结构的DER编码：
ProtectedPart ::= SEQUENCE {
header PKIHeader,
body PKIBody
}
在有些情况下，故意不采用PKIProtection比特串来保护消息(即省略这个可选的字段)，因为将采用PKIX以外的其它保护方法。本规范允许选择这种方法。这种外部保护的例子包括对PKIMessage(或仅对PKIBody(省略CHOICE标签)封装，如果相关的PKIHeader信息由外部机制安全的传输)的PKCS #7 [PKCS7]和Security Multiparts [RFC1847]封装。然而需要注意的是，许多这样的外部机制要求终端实体已经拥有一个公钥证书、和/或一个唯一的DN、和/或其它与基础结构相关的信息。这样，这些方法对于初始注册、密钥恢复或其它具有"boot-strapping"特性的过程来说就不合适。对这些情况，可能必须使用PKIProtection。将来，如果/当外部机制进行修改，可以适用于具有"boot-strapping"特性的场景时，PKIProtection的使用将会变得很少或根本就不再使用。
根据环境不同，PKIProtection比特可以包含一个消息认证码(MAC)或签名。只有下面的几种情况：
- 共享密钥信息
在这种情况下，发送方和接收方共享(通过带外方法或前一个PKI管理操作建立的)密钥信息。PKIProtection将包含一个MAC值，protectionAlg如下(参见附录B2)：
id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
--单向算法标识(建议为SHA-1)
iterationCount INTEGER,
-- OWF的应用次数
mac AlgorithmIdentifier
-- MAC算法标识 (如：DES-MAC, Triple-DES-MAC [PKCS11],
} -- 或 HMAC [RFC2104, RFC2202])
在上面的protectionAlg中，在共享密钥的后面将追加上salt值。然后应用iterationCount 次OWF算法，其中，追加了salt值的密钥作为第一次迭代的输入，对后续的每一次迭代，其输入都是前一次迭代的输出。最后一次迭代的输出(为了方便引用称作"BASEKEY"，其长度为"H")用于形成对称密钥。如果MAC算法要求一个K-比特的密钥而且K <= H，那么密钥就取BASEKEY的前K比特。如果K > H，那么BASEKEY的全部H比特将作为密钥的前H比特，OWF("1" || BASEKEY)所得结果将作为密钥的下一H比特，OWF("2" || BASEKEY) 所得结果将作为密钥的再下一H比特，依此类推，直到得到所有的K比特为止。[这里，"N"代表数字N的ASCII字节编码，"||"代表串联。]
注意：建议PBMParameter字段在一个交易的所有消息中(例如ir/ip/certConf/pkiConf)保持不变，这样可以降低计算PasswordBasedMac的负荷。
- DH密钥对
当发送者和接收者拥有相容的DH参数的DH证书时，为了保护消息，终端实体必须基于自己的DH私钥值和PKI消息接收方的DH公钥值产生一个对称密钥。PKIProtection将包含由这个对称密钥计算出的MAC值，protectionAlg如下：
id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30}
DHBMParameter ::= SEQUENCE {
owf AlgorithmIdentifier,
-- 单向算法ID(建议为SHA-1)
mac AlgorithmIdentifier
-- MAC算法ID (如：DES-MAC, Triple-DES-MAC [PKCS11],
} -- 或 HMAC [RFC2104, RFC2202])
在上面的protectionAlg中，对D-H计算的结果应用OWF。OWF的输出(为了方便引用称作"BASEKEY"，其长度为"H")用于形成对称密钥。如果MAC算法要求一个K-比特的密钥而且K <= H，那么密钥就取BASEKEY的前K比特。如果K > H，那么BASEKEY的全部H比特将作为密钥的前H比特，OWF("1" || BASEKEY)所得结果将作为密钥的下一H比特，OWF("2" || BASEKEY) 所得结果将作为密钥的再下一H比特，依此类推，直到得到所有的K比特为止。[这里，"N"代表数字N的ASCII字节编码，"||"代表串联。]
- 签名
在这种情况下，发送方拥有一个签名密钥对，对PKI消息进行签名即可。PKIProtection将包含签名值，protectionAlg为一种用于数字签名的算法(例如：md5WithRSAEncryption或dsaWithSha-1)。
- 多重保护
当终端实体发送一个保护的PKI消息到RA，RA可以追加自己的保护(可以是MAC或签名，取决于RA和CA之间共享的信息和证书)后将消息转发到CA。这种保护通过将终端实体发送的消息整个嵌套到一个新的PKI消息中实现。使用的结构如下。
NestedMessageContent ::= PKIMessages
(使用PKIMessages - SEQUENCE OF PKIMessage可以使RA将多个终端实体的请求打包到一个单独的新消息中。为了简单起见，一个NestedMessageContent 中的所有消息必须具有相同的类型(如ir))。如果RA希望修改消息(如，增加特定的字段值或新的扩展项), 那么它可以创建自己的PKIBody。终端实体最初发送的PKIMessage 可以包含在PKIHeader的generalInfo字段中(以适应下面的情况，例如CA希望自己来验证原始消息的POP或其它信息)。这种情况下infoType的取值为{id-it 15} (id-it的值参见)，infoValue的取值为PKIMessages (内容的次序必须与PKIBody 中请求的次序一致。)。
公共数据结构
在定义PKIBody中的特定类型之前，我们先定义一些多处使用的数据结构。
被申请的证书内容
各种PKI管理消息都要求消息的发起者指明证书里存放的某些字段的值。CertTemplate结构体使得EE或者RA可以尽可能地指定它们所希望申请到的证书里的内容。CertTemplate结构体与证书的内容完全一致，但所有的字段都是可选的。
注意，即使消息的发起者指明了它所申请的证书的所有内容，CA机构仍然可以自由改动实际发放的证书的字段值。如果申请者不能接受被修改后的证书，那么申请者必须回送一个certConf消息，其中或者不包括该证书（通过一个CertHash），或者包含该证书（通过一个CertHash）但同时状态置为“rejected”。CertHash和certConf消息的定义以及使用参见。
CertTemplate语法参见附件D和[rfc2511bis]。
加密值
在PKI消息中发送加密值（在本规范中，加密值限于私钥或者证书）时采用EncryptedValue数据结构。
EncryptedValue的语法参见[rfc2511bis]。
使用该数据结构要求创建者和期望的接收者分别都能够进行加密和解密操作。典型情况下，这意味着发送者和接收者拥有，或者能够产生共享的秘密密钥。
如果PKIMessage的接收者已经拥有用于解密的私钥，则encSymmKey字段可以包含用接收者的公钥加密的会话密钥（session key）。
PKI消息的状态编码和失败信息
所有的响应消息都包含某些状态信息。下面定义了相应的值：
PKIStatus ::= INTEGER {
accepted (0),
-- 表示得到了所要求的数据
grantedWithMods (1),
-- 得到的数据与所要求的类似，但申请者有责任确定有无差别
rejection (2),
-- 无法得到的数据，在该消息的其它地方有更多的信息
waiting (3),
-- 请求的包体尚未被处理，期望稍后将获取结果（注意：对具有该状态的响应，恰当的处理方式可以是使用中定义的轮询请求/响应PKIMessages；使用底层的传输层轮询机制也是一种可行的方法。
revocationWarning (4),
-- 本消息包含一个即将作废的警告信息
revocationNotification (5),
--通知已经作废
keyUpdateWarning (6)
--在密钥更新请求消息中oldCertId指示的密钥已经更新
}
响应者可以使用下列语法以提供有关失败状况的更多信息。
PKIFailureInfo ::= BIT STRING {
-- 因为多种情况可能导致失败，所以在需要时可以加入更多的代码
badAlg (0),
-- 不可识别或者不支持的算法标识符
badMessageCheck (1),
-- 完整性检查失败（例如，签名验证不成功）
badRequest (2),
-- 不允许或不支持的交易
badTime (3),
-- 根据本地策略，请求中的messageTime与系统时间不够接近
badCertId (4),
--无法找到与提供的条件匹配的证书
badDataFormat (5),
-- 提交的数据格式错误
wrongAuthority (6),
-- 请求中指明的权威机构与本响应的创建者不同
incorrectData (7),
-- 申请者的数据错误 (用于公证服务)
missingTimeStamp (8),
-- 在要求存在时戳的时候没有提供（根据政策要求）
badPOP (9),
-- 拥有证明失败
certRevoked (10),
-- 证书已经被作废
certConfirmed (11),
-- 证书已经被确认
wrongIntegrity (12),
--无效的完整性，应当使用基于口令方式但采用了签名方式或反之
badRecipientNonce (13),
-- 无效的接收者随机数，没有提供RecipientNonce或取值错误
timeNotAvailable (14),
-- TSA服务的时钟源无法得到
unacceptedPolicy (15),
-- 请求的TSA政策不被TSA服务支持
unacceptedExtension (16),
-- 要求的扩展项不被TSA服务支持
addInfoNotAvailable (17),
-- 无法理解要求的附加信息或者该附加信息无法得到
badSenderNonce (18),
--无效的接收者信息，没有提供SenderNonce或取值错误
badCertTemplate (19),
-- 无效的证书模板，或者缺少强制信息
signerNotTrusted (20),
-- 消息的签发者不可知或者不被信任
transactionIdInUse (21),
-- 交易标识符已经在用
unsupportedVersion (22),
-- 消息版本号不支持
notAuthorized (23),
-- 发送者未被授权发出前面的请求或者执行前面的操作
systemUnavail (24),
-- 系统不可用，所以请求无法被处理
systemFailure (25),
-- 系统失败，所以请求无法被处理
duplicateCertReq (26)
-- 由于同样的证书已经存在，所以证书不能发放
}
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL
}
证书标识
CertId数据结构用于鉴别特定的证书。
CertId的语法参见[rfc2511bis]。
“带外”根证书公钥
每个根CA必须能够通过一些“带外”方式来发布它的当前公钥。虽然这样的方法不在本文描述的范围之内，我们定义了支持这种方法的数据结构。
一般而言，有两种可能的方法：CA机构直接发布它的自签名证书；或者可以通过目录服务器（或其他类似方式）获得自签名证书，同时CA发布自签名证书的哈希值用于（由使用者）在使用（CA证书）之前进行完整性校验。
OOBCert ::= Certificate
该证书中的值域有如下限制：
- 证书必须是自签名的(即，签名必须可以用SubjectPublicKeyInfo中的值来验证)；
- 主体字段和签发者字段的值必须完全相同；
- 如果主体字段为空，则主体可替换名和签发者可替换名扩展项必须同时存在，并且具有完全相同的值；
- 所有其他扩展项的值必须符合自签名证书的要求（比如，主体和签发者的密钥标识符必须完全相同）
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
-- hashVal是对由certID所标识的自签名证书进行运算得出的值
}
哈希值的目的在于：任何（通过带外方式）安全获取到哈希值的用户都能验证该CA的自签名证书。
归档选项
请求者可以用PKIArchiveOptions结构体来指明他们希望PKI归档某私钥。
PKIArchiveOptions的语法参见[rfc2511bis]。
发布信息
请求者可以用PKIPublicationInfo结构体来指明他们希望PKI发布证书。
PKIPublicationInfo的语法参见[rfc2511bis]。
拥有证明结构体
如果是为签名密钥对申请证书（即申请一个验证证书），则可以使用POPOSigningKey结构体来证明对签名私钥的拥有。
POPOSigningKey的语法参见附录D和[rfc2511bis]，但注意本规范中POPOSigningKeyInput存在下面的语义约定：
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
-- 取自PKIHeader (仅当发送者的身份鉴别已通过某种方式（如以前发布的、当前处于有效状态的证书中的DN）建立之后使用)
publicKeyMAC PKMACValue
-- 发送者当前没有已鉴别通过的通用名（GeneralName）存在时使用；publicKeyMAC包含一个基于口令的针对公钥的DER编码的MAC值(使用PKIHeader 中的protectionAlg算法标识)
},
publicKey SubjectPublicKeyInfo
-- 取自CertTemplate
}
另一方面，如果为加密密钥对申请证书（即申请一个加密证书），则可以使用下列三种方式之一来证明对解密私钥的拥有。
1) 通过在证书请求中包含加密后的私钥（可以包含在POPOPrivKey中的thisMessage字段（参见附录D）或者包含在PKIArchiveOptions控制结构体中），采取哪种方式包含取决于是否同时要求归档该私钥。
2) CA不直接返回证书，而是返回加密后的证书（即，返回的证书用一个随机产生的对称密钥加密，而对称密钥本身用证书请求中包含的公钥来加密）――这是前面中提到的“间接”方式。终端实体通过在certConf消息中提供正确的该证书的CertHash值来向CA机构证明它对解密私钥的拥有。因为终端实体只有在能够恢复出证书的情况下才能计算出正确的CertHash值，而它仅在能够用相应的私钥解密出对称密钥的情况下才能恢复出证书，因此这种方式能够证明POP。显然，要保证这种方式有效，CA机构在收到certConf之前（此时certHash值用于验证POP）绝对不能发布证书。更详细的描述请参考。
3) 让EE在CertReqMessages和CertRepMessage 之间参与挑战－响应协议（使用POPODecKeyChall和POPODecKeyResp消息；参照下文）—这是前面中提到的“直接”方式。 [这种方式典型的应用环境是RA验证POP，然后代表终端实体向CA发送认证请求。在这种情况下，CA相信RA在为终端实体申请证书之前已经正确地验证了POP。]完整地协议如下所示（注意req'不一定要将req封装为嵌套消息）：
EE RA CA
---- req ---->
<--- chall ---
---- resp --->
---- req' --->
<--- rep -----
---- conf --->
<--- ack -----
<--- rep -----
---- conf --->
<--- ack -----
这一协议显然比前面的方式2中给定的3次交换要长，但它允许本地注册机构（LRA）介入，并使得POP验证通过之前并不真正生成证书。在某些环境下，上述的消息可能要求有不同的顺序（由政策决定）：
EE RA CA
---- req ---->
<--- chall ---
---- resp --->
---- req' --->
<--- rep -----
<--- rep -----
---- conf --->
---- conf --->
<--- ack -----
<--- ack -----
如果为密钥协商密钥对（KAK）申请证书，则POP的验证可以使用对加密密钥对验证的三种方式中的任何一种，但要做下列变化： (1) 前面描述的第二种方式中的括号中的文本变为：（即，证书由根据CA的KAK私钥和认证请求中的公钥生成的对称密钥加密）； (2)下面Challenge结构描述中的challenge字段的第一个括号中的文本改为：（使用PreferredSymmAlg（参见和附录C5）和一个对称密钥，该密钥基于CA的KAK私钥和认证请求中的公钥而产生）。此外，如果CA已经拥有一个为终端实体所知的D-H证书，POP可以使用[rfc2511bis]中定义的POPOSigningKey结构体(其中，alg 字段取值为DHBasedMAC，签名字段取值为MAC)作为证明POP的第四种方式。
用于解密私钥POP的挑战－响应消息定义如下(细节参见[MvOV97, ])。注意，挑战－响应交换通过PKIHeader中的transactionID以及对PKIMessage的保护（MAC或签名）与前面的认证请求消息（以及后续的认证响应和确认消息）相关联。
POPODecKeyChallContent ::= SEQUENCE OF Challenge
-- 每个加密密钥认证请求对应一个Challenge（次序与请求出现在CertReqMessages中的次序保持一致）
Challenge ::= SEQUENCE {
owf AlgorithmIdentifier OPTIONAL,
-- 在第一个Challenge中必须存在；而在POPODecKeyChallContent随后的Challenge中可以省略。（如果省略的话，则使用前一个Challenge中的owf字段。）
witness OCTET STRING,
-- 对随机产生的整数A应用单向函数(owf)的结果。[注意每个Challenge都必须使用不同的整数。
challenge OCTET STRING
-- 加密后的Rand（使用认证请求中的公钥加密），Rand定义如下
-- Rand ::= SEQUENCE {
-- int INTEGER,
-- 上面提到的随机产生的整数A
-- sender GeneralName
-- 发送者的名称(与PKIHeader中的相同)
}
}
注意Rand的大小应适合使用请求者的公钥进行加密的需要。假设该“int”一般不会超过64比特，那么当模长为1024比特时，为“sender”发送者字段留下了约100字节以上的空间。在某些环境中，如果名称太长以至于无法放下（如DN非常长），则使用（尺寸相当的）任何部分（只要它至少包括了通用名common name，并且只要接收者能够利用该缩略以后的部分清楚地进行处理）。
POPODecKeyRespContent ::= SEQUENCE OF INTEGER
-- 每个加密密钥认证请求对应一个整数 (这些整数的顺序与请求出现在CertReqMessages中的顺序保持一致)。收到的整数（上面提到的A）被返回给相应Challenge的发送者。
本部分的内容提供了与POP技术相关的多种可能实现方式。如果用“SK”代表签名密钥，用“EK”代表加密密钥，用“KAK”代表密钥交换密钥，上面的技术方式概括如下：
RAVerified；
SKPOP；
EKPOPThisMessage；
KAKPOPThisMessage；
KAKPOPThisMessageDHMAC；
EKPOPEncryptedCert；
KAKPOPEncryptedCert ；
EKPOPChallengeResp ；
KAKPOPChallengeResp。
给定了上述可选方式之后，很自然就会出现这样的问题：终端实体如何得知CA/RA支持哪种方式呢？（即在申请证书时可以使用哪种方式）。下面的指南可以为终端实体的实现者澄清这一问题。
RAVerified。 本方式不由EE决定；RA仅在它向CA系统转发请求之前已经验证过POP时才使用这种方式，所以该机制不可能由EE来选择。
SKPOP。如果EE有一对签名密钥对，则在申请相应的证书时，本方式是唯一的POP验证方式。
EKPOPThisMessage和KAKPOPThisMessage。 是否将其私钥提交给CA或RA是由EE来决定的。如果EE决定提供它的密钥，那么在本规范中，使用EKPOPThisMessage和KAKPOPThisMessage消息是能够达到该目的的唯一的POP方式（到底使用哪个消息根据密钥对类型来决定）。
KAKPOPThisMessageDHMAC。EE仅在下列条件都满足的情况下可以使用该方式：(1)CA拥有用于该目的的DH证书。(2)EE已经拥有该证书的一份拷贝。如果这两个条件都有效，那么CA系统支持本方式，并且EE在需要时可以使用。
EKPOPEncryptedCert、KAKPOPEncryptedCert、EKPOPChallengeResp、KAKPOPChallengeResp。EE根据自身情况和密钥对类型，在请求消息中选择其中之一（在subsequentMessage字段中）。此时EE不是在完成POP，而仅仅是指明它希望采用哪种方式。因此，如果CA/RA回送一个“badPOP”错误，EE可以重新发送一个请求，在subsequentMessage中选择其他的POP方法。注意：本规范鼓励使用EncryptedCert的方式，此外，挑战－响应方式通常用于RA参与并完成POP验证的情况。因此，EE可以根据情况，充分考虑后决定在请求消息中使用何种POP方式。
与操作相关的数据结构
初始化请求
一个初始化请求消息的PKIBody包含的是一个CertReqMessages数据结构体，这个结构体详细说明了所请求的证书。通常，可以为每一个申请的证书提供下列模板字段：SubjectPublicKeyInfo、KeyId和Validity (详细信息参见附录B)。此消息用于实体在PKI体系中的最初初始化。
CertReqMessages的语法参见附录D及[rfc2511bis]
初始化响应
一个初始化响应消息的PKIBody包含的是一个CertRepMessage数据结构体，这个结构体对应每个证书请求均包括一个PKIStatusInfo字段、一个主题证书及可能存在的一个私钥（这个私钥通常由会话密钥加密，而会话密钥本身由protocolEncrKey来加密）。
CertRepMessage的语法参见。注意：如果PKI消息的保护方式是“共享秘密信息”（参见），则caPubs字段内的任何证书都可以被消息发起者作为根CA证书来直接信任。
认证请求
一个认证请求消息的PKIBody包含的是一个CertReqMessages数据结构体，这个结构体详细说明了所请求的证书。当已存在于PKI体系中实体想获取额外的证书时使用此消息。
CertReqMessages的语法参见附录D及[rfc2511bis]。
PKIBody也可以包含一个CertificationRequest结构体(此结构体在[PKCS10]的结构CertificationRequest部分有完全详细的说明)。当需要与遗留系统进行一些交互操作时，申请签名密钥证书的请求中可以使用该结构体，若不是在绝对必要的情况下强烈建议不使用此结构体。
认证响应
一个认证响应消息的PKIBody包含的是一个CertRepMessage数据结构体，这个结构体包含了与每个证书请求对应的状态值，同时根据情况还可能包含一个CA的公钥，失败信息，一个主题证书和一个加密后的私钥。
CertRepMessage ::= SEQUENCE {
caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
response SEQUENCE OF CertResponse
}
CertResponse ::= SEQUENCE {
certReqId INTEGER,
-- 使用此项使响应与请求对应 (若相对应的请求中未指明certReqId ，则此项应填-1）
status PKIStatusInfo,
certifiedKeyPair CertifiedKeyPair OPTIONAL,
rspInfo OCTET STRING OPTIONAL
-- 类似于[rfc2511bis]中CertReqMsg结构中为regInfo定义的id-regInfo-utf8Pairs字符串
}
CertifiedKeyPair ::= SEQUENCE {
certOrEncCert CertOrEncCert,
privateKey [0] EncryptedValue OPTIONAL,
-- 参见 [rfc2511bis]中编码的说明
publicationInfo [1] PKIPublicationInfo OPTIONAL
}
CertOrEncCert ::= CHOICE {
certificate 0] Certificate,
encryptedCert [1] EncryptedValue
}
在每个CertResponse中failInfo（在PKIStatusInfo中）和certificate（在CertifiedKeyPair中）两个字段只能出现一个（取决于状态）。在某些状态值（例如：waiting）的情况下，两者都不会出现。
给定了EncryptedCert和相关的解密私钥就可以获得证书。这种方式的目的是允许CA返回证书值，但只有预期的接收者才能够获得实际的证书。这种方法的好处在于CA在无法证明请求者就是拥有相应私钥的终端实体的情况下依然可以返回证书(注意：直到CA收到返回的certConf消息后才能证明)。因此，在POP验证出错时CA并不是必须作废该证书（但也可作废，这由政策决定）。
密钥更新请求内容
对于密钥更新请求使用CertReqMessages语法结构。通常，可以为每一个要更新的密钥提供下列模板字段：SubjectPublicKeyInfo, KeyId及Validity。这个消息用于请求更新已存在的证书（未作废且未过期）。（所以，它有时被称作“证书更新”操作）。所谓更新证书就是使用新的公钥或原有公钥的证书替换现有的证书（虽然在某些情况下后一种方式并不恰当）。
CertReqMessages的语法参见附录D及[rfc2511bis]
密钥更新响应内容
密钥更新响应使用CertRepMessage语法结构。该响应与初始化响应相同。
CertRepMessage的语法参见。
密钥恢复请求内容
密钥恢复请求的语法与初始化请求中的CertReqMessages相同。通常，可以为一个签名公钥申请证书时提供下列模板字段：SubjectPublicKeyInfo和KeyId（进一步的信息参见附录B）。
CertReqMessages的语法参见附录D及[rfc2511bis]。注意：如果需要密钥历史，请求者必须在请求消息中加入协议加密密钥。
密钥恢复响应内容
密钥恢复响应使用下列语法。对于某些状态值（如：waiting）,所有的可选项均不会出现。
KeyRecRepContent ::= SEQUENCE {
status PKIStatusInfo,
newSigCert [0] Certificate OPTIONAL,
caCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
CertifiedKeyPair OPTIONAL
}
撤销请求内容
当请求撤销一个证书（或多个）时，使用下列数据结构。请求者的名字出现在PKIHeader结构体中。
RevReqContent ::= SEQUENCE OF RevDetails
RevDetails ::= SEQUENCE {
certDetails CertTemplate,
-- 允许请求者尽可能多的指明请求撤销的证书的资料
-- (例如：在无法获得序列号的情况下)
crlEntryDetails Extensions OPTIONAL
-- 所请求的 crlEntryExtensions
}
撤销响应内容
撤销响应是对上述消息的响应，生成该响应后将发送给撤销请求者。（可以向请求作废证书的拥有者发送一个撤销公告消息）。
RevRepContent ::= SEQUENCE {
status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
--与RevReqContent中发送的顺序相同
revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
-- 撤销请求的IDs (与status的顺序相同)
crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL
-- 结果CRL (可能不止一个)
}
交叉认证请求内容
交叉认证请求与一般认证请求使用的语法相同(CertReqMessages)，但具有下列限制：密钥对必须由请求CA产生且私钥一定不能发送给响应CA。这个请求也可以由子CA用于获取父CA为其签发的证书。
CertReqMessages的语法参见附录D及[rfc2511bis]。
交叉认证响应内容
交叉认证响应与一般认证响应使用的语法相同(CertRepMessage)，其约束是不会发送加密的私钥。
CertRepMessage的语法参见。
CA 密钥更新公告内容
当CA更新了自己的密钥对后，可以使用下列数据结构宣布这一事件。
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew Certificate, -- 用新私钥签名的旧证书
newWithOld Certificate, -- 用旧私钥签名的新证书
newWithNew Certificate --用新私钥签名的新证书
}
证书公告
这个结构体可以用于公告证书的存在。
注意：此消息适用于下列情况（如果有的话）：没有已存在的证书发布方法；下列情况不建议使用此消息：例如利用目录服务发布证书。
CertAnnContent ::= Certificate
撤销公告
当CA已作撤销或即将撤销一个证书时，可以公告这一事件（或将要来临的事件）。
RevAnnContent ::= SEQUENCE {
status PKIStatus,
certId CertId,
willBeRevokedAt GeneralizedTime,
badSinceDate GeneralizedTime,
crlDetails Extensions OPTIONAL
-- 额外的CRL 细节(如：crl 序列号、作废原因、位置等)
}
CA可以使用这个消息来警告（或通知）一个证书持有者他的证书将要（或已经）被撤销。这主要用于证书的撤销请求并不来自于其持有者的情况。
willBeRevokedAt字段包含的是一个新的条目将加入到相应CRLs的时间。
CRL 公告
当CA签发了一个新的CRL（或一批CRL）时，可以使用以下数据结构宣布这一事件。
CRLAnnContent ::= SEQUENCE OF CertificateList
PKI 确认内容
这个消息在协议数据交换中作为最后的PKIMessage。在所有情况下它的内容均相同——实际上由于PKIHeader中已包含了所有必需的消息，它没有内容。
PKIConfirmContent ::= NULL
不建议使用该消息来作为证书确认，而应该使用certConf。如果在发送证书响应之后接收到一个PKIConfirm消息，那么接收者可以将它视为所有证书都被接受的一条certConf消息。
证书确认内容
本数据结构用于客户端向CA/RA发送接受或拒绝证书的确认消息。
CertConfirmContent ::= SEQUENCE OF CertStatus
CertStatus ::= SEQUENCE {
certHash OCTET STRING,
-- 证书的HASH，其算法与创建及验证证书签名的算法相同
certReqId INTEGER,
--使确认与相应的请求/响应匹配
statusInfo PKIStatusInfo OPTIONAL
}
对于每一个CertStatus，省略statusInfo字段表示接受指定的证书。此外，也可以在statusInfo字段内提供显式的状态细节（接受或拒绝），可能出于CA/RA的审核目的。
在CertConfirmContent中，省略对应于前一个响应消息中的证书的CertStatus结构意味着拒绝该证书。因此。可以用一个空的CertConfirmContent（序列长度为零）表示拒绝所有提供的证书。与POP相关的CertHash字段的讨论参见的(2)。
PKI 通用消息内容
InfoTypeAndValue ::= SEQUENCE {
infoType OBJECT IDENTIFIER,
infoValue ANY DEFINED BY infoType OPTIONAL
}
-- InfoTypeAndValue的内容包含但不限于下列值（更多的细节见后续章节，
-- 语法描述参见附录F）：
-- { CAProtEncCert = {id-it 1}, Certificate }
-- { SignKeyPairTypes = {id-it 2}, SEQUENCE OF AlgorithmIdentifier }
-- { EncKeyPairTypes = {id-it 3}, SEQUENCE OF AlgorithmIdentifier }
-- { PreferredSymmAlg = {id-it 4}, AlgorithmIdentifier }
-- { CAKeyUpdateInfo = {id-it 5}, CAKeyUpdAnnContent }
-- { CurrentCRL = {id-it 6}, CertificateList }
-- 其中，{id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}，这个构造也可用于定义
-- 新的PKIX证书管理协议的请求和相应消息或通用目的消息（例如公告）
-- 以满足未来或特定环境的要求。
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
-- EE，RA，或者CA都可以发送该消息（取决于消息的内容）。对于上面的
-- 给出的某些例子，GenMsg 中InfoTypeAndValue的可选参数infoValue通
-- 常会被省略（即它只应用于相关的GenRep消息中）。接收方有权忽略它
-- 不能识别的对象标识符。如果消息由EE发往CA，若结构内容为空的表
-- 明CA可以发送其希望发送的任意或所有信息。
CA协议加密证书
此消息可用于EE从CA获取一个证书，并使用它来保护协议交互过程中的敏感信息。
GenMsg: {id-it 1}, <absent>
GenRep: {id-it 1}, Certificate | <absent>
EE必须确保正确的证书被用于此目的。
签名密钥对类型
此消息可用于EE获取CA支持的签名算法列表（如RSA，DSA）。注意在该消息中，比如rsaEncryption和rsaWithSHA1，将被认为是相同的；提出了这样一个问题：CA是否同意认证一个RSA公钥？
GenMsg: {id-it 2}, <absent>
GenRep: {id-it 2}, SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier
加密/密钥协商密钥对类型
此消息可用于客户端获取CA支持的加密/密钥协商算法列表。
GenMsg: {id-it 3}, <absent>
GenRep: {id-it 3}, SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier
首选的对称算法
此消息可用于客户端获取CA首选的对称加密算法，用以保护EE和CA间交换的机密信息（比如，EE会向CA发送其解密私钥用于密钥归档）。
GenMsg: {id-it 4}, <absent>
GenRep: {id-it 4}, AlgorithmIdentifier
更新的CA 密钥对
CA可用此消息声明一个CA密钥对更新事件。
GenMsg: {id-it 5}, CAKeyUpdAnnContent
CRL
此消息用于客户端获取一份最新的CRL的副本。
GenMsg: {id-it 6}, <absent>
GenRep: {id-it 6}, CertificateList
不支持的对象标识符
此消息用于服务器返回不能识别或不支持的客户端提交的对象标志符列表。
GenRep: {id-it 7}, SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
密钥对参数
此消息用于EE请求域参数，EE用此参数来产生基于特定公钥算法的密钥对。比如，EE可用此消息来请求适当的P，Q和G，用以产生DH/DSA密钥，或者，用以请求一套椭圆曲线。
GenMsg: {id-it 10}, OBJECT IDENTIFIER -- (Algorithm object-id)
GenRep: {id-it 11}, AlgorithmIdentifier | <absent>
消息GenRep中缺少某个infoValue表明不支持GenMsg中指定的相应算法。
EE必须保证这些参数自己是能接受的，并且GenRep消息是验证过的（目的是防止替代攻击）。
撤销口令
此消息用于EE向CA或RA发送一个口令用于验证后续的撤销请求（在无法得到相应的签名密钥验证该请求的情况下）。如何使用这种机制的更多细节请见附录E。
GenMsg: {id-it 12}, EncryptedValue
GenRep: {id-it 12}, <absent>
隐式确认
参见中的{id-it 13}的定义和使用。
确认等待时间
参见中的{id-it 14}的定义和使用。
原始PKI消息
参见中的{id-it 15}的定义和使用。
支持的语言标签
此消息用于决定在后续消息中使用的语言标签。发送者将其支持的语言列表发送给对方（按其选择的优先顺序高低排列）；接收方选择一个希望使用的标签返回。（注意：每个UTF8String必须包含一个语言标签。）如果发送方给出的语言标签接收方都不支持，则必须返回一个错误消息。
GenMsg: {id-it 16}, SEQUENCE SIZE (1..MAX) OF UTF8String
GenRep: {id-it 16}, SEQUENCE SIZE (1) OF UTF8String
PKI通用响应消息
GenRepContent ::= SEQUENCE OF InfoTypeAndValue
-- 接收方可以忽略其不能识别的OID。
支持的GenRep消息包括小节的消息。
错误消息内容
这个数据结构可以由EE，CA，或者RA用于传送错误信息。
ErrorMsgContent ::= SEQUENCE {
pKIStatusInfo PKIStatusInfo,
errorCode INTEGER OPTIONAL,
-- 与实现相关的错误码
errorDetails PKIFreeText OPTIONAL
-- 与实现相关的错误描述
}
这个消息可在一个PKI交易中的任意时间产生。如果客户端发送此请求，服务端必须响应一个PKIConfirm消息，或者是错误消息（如果消息头的任一部分不正确）。通信双方必须将此消息视为交易的结束（如果事务处于进行中）。
如果本消息要求被保护，客户端必须用与交易的第一个消息相同的保护机制来保护此消息（即签名或MAC）。CA必须用其签名密钥来对消息进行签名。
轮询请求和响应
这一对消息用于处理如下情形：客户端需要轮询服务器以明确初始化请求，认证请求或者密钥更新请求交易的状态（即，当客户端接收到PKI Status为“等待”的响应时）。
PollReqContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER }
PollRepContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER,
checkAfter INTEGER, -- 以秒为单位的时间
reason PKIFreeText OPTIONAL }
下面将描述何时以及如何使用轮询消息。我们假定在交易中，可以发送多个CertConf消息。对于每个包含状态为接受证书的CertStatus的初始化响应、认证响应或密钥更新响应，都需要发送一个CertConf消息作为响应。
1． 作为对ip、cp或者kup消息的响应，EE要为所有接受的证书发送一个certConf消息，并且，在收到应答后，对于所有处于等待状态的证书发送pollReq消息。
2． 如果一个或多个等待的证书状态变成“已准备好”，作为对pollReq消息的响应，CA/RA会返回ip、cp或者kup消息；否则，它返回一个pollRep。
3． 收到pollRep后，EE将等待至少checkAfter规定的时间后，再发送下一pollReq消息。
4． 如果ip、cp或者kup消息被作为pollReq的响应被返回，则视之同初始化响应消息。
图2 未决链表
在下面的交换中，EE在一个认证请求中申请两个证书。
Step End Entity PKI
--------------------------------------------------------------------
1 生成 ir
2 -> ir ->
3 处理ir
4 两个证书都需要人工干预
5 <- ip <-
6 处理ip
7 生成 pReq
8 -> pReq ->
9 检查认证请求的状态
10 证书尚未产生
11 生成pRep
12 <- pRep <-
13 等待
14 生成pReq
15 -> pReq ->
16 检查认证请求的状态
17 已经产生一个证书
18 生成ip
19 <- ip <-
20 处理ip
21 生成certConf
22 -> certConf ->
23 处理certConf
24 生成ack
25 <- pkiConf <-
26 生成pReq
27 -> pReq ->
28 检查证书状态
29 证书已经产生
30 生成ip
31 <- ip <-
31 处理ip
32 生成 certConf
33 -> certConf ->
34 处理certConf
35 生成ack
36 <- pkiConf <-
8 必需的PKI管理功能
本节将对第一节中提出的一部分PKI管理功能进行描述。
本节所描述的功能都是必需的，也就是说所有的终端实体和CA/RA实现都要能够提供所描述的功能。这部分概述了必须支持的PKI管理功能。值得注意的是，如果对某特定的环境采用适用别的方法，那么可以不必使用第7节中定义的PKI消息来实现本节中描述的管理功能（参看附录B中必需支持的PKI消息结构）。
根CA初始化
【参看本文档节中根CA的定义。】
新建立的根CA要求能够产生自己的自签名证书，这个证书结构与根CA密钥更新后发布的"newWithNew"证书结构相同。
为了使CA自己的证书对的自签名证书对那些不通过带外方法来获得这个证书的终端实体有用，CA要为它的公钥产生一个指纹。终端实体通过带外方法安全地获得这个指纹，然后就可以验证CA的证书以及证书里面的其它属性。
传递指纹的数据结构是OOBCertHash。
根CA密钥更新
CA密钥（与其他的所有密钥一样）的生命期是有限的，因此需要进行周期性的更新。CA发布NewWithNew, NewWithOld, 和 OldWithNew证书（参看节）用以帮助现存的终端实体将拥有的自签名CA证书（OldWithOld）安全地转变为新的自签名CA证书（NewWithNew），同时也帮助新的即将获得拥有NewWithNew证书的终端实体安全地取得OldWithOld证书来验证现存的数据。
下级CA初始化
【参看本文档节中下级CA的定义。】
从PKI管理协议的角度来看，下级CA 的初始化与终端实体的初始化是一样的。唯一的区别在于下级CA必须同时产生初始的撤销列表。
CRL产生
新建立的CA（它能发布CRL）在发布证书之前必须首先产生空的CRL。
PKI信息请求
当PKI实体（CA，RA，或EE）希望获得关于CA当前状态的信息时，它可以向CA发送对这种信息的请求。CA必须向请求者提供至少请求者要求的所有所请求的信息。如果某些信息不能提供，则必须给请求者返回错误。
如果使用PKI消息来请求和提供PKI相应的信息，那么请求就是必须使用GenMsg消息，响应就使用是GenRep消息，错误使用为Error错误消息。这些消息使用基于共享秘密信息的MAC（如：PasswordBasedMAC）或者别的认证方法（如果终端实体拥有证书）来进行保护。
交叉认证
请求者CA作为交叉证书的主体，而响应者CA作为交叉证书的发布者。
请求者CA在发起交叉认证操作之前必须已建立并在运行中。
单向请求－响应方案模式
交叉认证方案基本上是单向的操作；也就是说，当成功时，这个操作会导致一个新的交叉证书的产生。如果需要产生“双向”的交叉证书，那么每一个CA都要发起一个交叉认证操作（或者使用另一种方案）。
这个方案适合于下面两种情况：两个CA已经验证过对方的签名（他们有共同的信任点）；或者能对认证请求起源进行带外验证。
详细描述：
交叉认证由作为响应者的CA发起。作为响应者的CA管理员鉴别它想交叉认证的CA，同时由响应者CA设备产生授权码。响应者的CA管理员用带外方法把授权码传递给请求者的CA管理员。请求者的CA管理员在请求者CA处输入授权码来发起在线交换。
授权码用于认证和完整性目的验证。它是这样实现的，：利用授权码产生对称密钥，然后使用此对称密钥对所有的交换消息产生消息认证码（MAC）。（如果CA可以通过某些方法检索和验证请求的公钥，那么认证也可以通过使用签名来代替MAC。）
请求者CA用一个新的随机数（请求者随机数）产生交叉认证请求（ccr）以发起交换。然后，请求者CA给响应者CA发送ccr消息。消息字段使用基于认证码的MAC来防止修改。
收到ccr消息之后，响应者CA验证消息和MAC，保存请求者随机数，并且产生自己的随机数（响应者随机数）。然后产生（如果需要就存档）一个新的包含请求者CA公钥的请求者证书，同时用响应者CA签名私钥进行签名。响应者CA用交叉认证响应（ccp）消息进行响应。消息中的字段使用基于认证码的MAC来防止修改。
收到ccp消息之后，请求者CA验证消息（包括收到的随机数）和MAC。请求者CA用certConf消息进行响应。消息中的字段使用基于认证码的MAC来防止修改。请求者CA把请求者的该（交叉认证）证书写入证书库为今后的证书路径构建提供帮助。
收到certConf消息之后，响应者CA验证消息和MAC，同时使用PKIConfirm消息发回一个确认。它也会公布请求者的（交叉认证）证书为今后路径构建提供帮助。
注释：
1. ccr消息必须包含一个“完整”的认证请求，也就是说，请求者CA必须规定好除了序列号的所有的字段（包括，例如：BasicConstraints扩展）。
2. ccp消息应该包含响应者CA的验证证书－如果存在，请求者CA必须验证这个证书（例如，通过带外机制）。
（可以设想一种更为简单的非交互式的交叉认证模型，在这个模型中发布者CA从证书库中获得主体CA的公钥，并通过带外机制进行验证，然后产生和公布交叉证书而不需要主体CA的参与。在很多环境中这个模型是非常合理的，但是因为它不需要任何协议消息交换，所以详细描述不在本规范的范围之内。）
终端实体初始化
和CA一样，终端实体也需要初始化。终端实体的初始化至少有两个步骤：
-获得PKI信息
-对根CA公钥的带外验证
（可能还会有别的步骤，包括：检索信任条件信息和对别的CA公钥的带外验证）。
获得PKI信息
需要获得的信息：
-当前根CA的公钥
-（假如认证CA不是根CA）包括适当的撤销列表的从根CA到认证CA以及适当的撤销列表的认证路径
-认证CA支持的每一种相关应用的算法和算法变量
为了能产生一个成功的认证请求可能需要一些附加的信息（例如：支持的扩展或者CA策略信息）。然而，为了简单化我们不强制终端实体通过PKI消息获得这些信息。最终的结果有可能导致一些认证请求的失败（例如，如果终端实体想产生自己的加密密钥但是CA不允许）。
需要的信息可以按照节所描述的来获得。
根CA密钥的带外验证
终端实体必须安全地持有根CA的公钥。为了保证安全，可以通过一些安全的"带外"方法给终端实体提供CA的证书指纹。这样终端实体就可以安全地使用CA的证书。
参看节可以得到更进一步的细节。
证书请求
经过初始化的终端实体可以在任何时候（为了任何目的）请求一个额外的证书。这个请求使用认证请求(cr)消息。如果终端实体已经拥有一对签名密钥（带有相应的验证证书），那么这个cr消息就使用实体的数字签名来保护。CA用CertRepMessage返回新的证书（如果请求成功）。
密钥更新
当密钥对过期时相关的终端实体就会请求密钥更新－也就是说，它可以请求CA为新密钥对发布新的证书（或者，在特定情况下，给相同的密钥对一个新证书）。这个请求使用密钥更新请求（kur）消息（参考，在某些情况下和“证书更新”操作一样）。如果终端实体已经拥有了签名密钥对（带有相应的验证证书），那么这个消息就使用实体的数字签名来保护。CA用密钥更新响应（kup）消息返回新的证书（如果请求成功），这个消息在语法构成上与CertRepMessage一样。
9 版本协商
本节定义的版本协商是用于支持较老的客户端和服务器之间的较老的协议。
如果客户端知道服务器支持的协议版本（例如：从前一个PKIMessage交换中得到或者通过带外方法），那么它就要发送带有双方支持的最高版本信息的PKIMessage。如果客户端不知道服务器支持的版本，那么它将发送带有它自己支持的最高版本信息的PKIMessage。
如果服务器接收到的信息中的版本是它所支持的，带有它所支持的版本信息的消息，那么响应消息的版本就要与就使用它接收到的版本一致。如果服务器接收到的版本信息带有比它所支持的版本高或者低的信息的消息，那么它将返回unsupportedVersion比特位（在pKIStatusInfo的failureInfo字段里）置位的ErrorMsg。如果接收的版本比所支持的最高版本还要高，那么错误消息里的版本必须是服务器支持的最高版本；如果接收的版本比所支持的最低版本还要低，那么错误消息里的版本必须是服务器所支持的最低版本。
如果客户端收到unsupportedVersion 比特位置位的ErrorMsgContent，并且其中的版本信息是它所支持的版本的ErrorMsgContent，那么它将可以使用那个版本重新发出请求。
支持的RFC 2510执行行为
当接收到不能理解的版本时，RFC 2510不指定执行的动作，因为事实上只有一个版本存在，所以当接收到不能理解的版本时，RFC 2510不指定执行行为。目前的规范修订推荐以下的版本协商办法。
客户端与RFC 2510服务器对话
如果在发送cmp2000消息之后，客户端收到带有版本cmp1999的ErrorMsgContent，那么它必须终止当前的交易。它可以接下来使用版本cmp1999消息重试交易。
如果客户端接收到版本cmp1999的非错误PKIMessage，那么它将可以（MAY）使用RFC 2510语义继续交易（如果此时交易没有尚未结束）。如果在交易没有未结束的时候客户端没有不选择这样做，那么它必须终止交易并且返回带有版本cmp1999的ErrorMsgContent。
服务器接收到版本cmp1999的PKIMessage
如果服务器接收到版本cmp1999的消息，那么它必须回复RFC 2510行为，并用cmp1999消息进行响应。如果它没有不选择那样做，那么它必须返回ErrorMsgContent，就和上面描述的一样。
安全注意事项
在这里提出一些加密注意事项需要特别讲清楚。在以上规定的协议中，当终端实体被要求证明拥有解密密钥的时候，它通常需要解密某些东西（如它自己的证书）。在这种情况下，如果密钥的所有者被攻击者诱骗来解密某个东西并把明文返回给攻击者，在这种情况下这个方案（还有很多别的方案也如此）很容易受到攻击。尽管在这个规范中要使攻击成功还需要很多别的安全缺陷，但是将来的业务还是潜在地有可能防止不了遭受这种攻击。由于这个原因，我们重申执行的通常规则：应该对解密任意的“密文”并显示恢复的“明文”非常小心，因为这种行为可能会导致严重的安全攻击。
同时还要注意的是，将私钥暴露给CA/RA来作为所有权证明的技术也会带来安全方面的危险（依赖于是否信任CA/RA能合理地处理这些私钥）。我们建议在选择和使用这些特定的POP机制的时候要小心。
在Diffie-Hellman密钥交换中可能存在以下的攻击行为。恶意的终端实体可能会精心选择D-H变量，那样可以使他或她在密钥档案或密钥恢复操作中从CA处得到（大量比特位的）D-H私钥。具备这些知识后，在另一终端实体－终端实体2与该CA进行合法密钥档案和密钥恢复操作时，终端实体可以检索这个信任的终端实体2的解密私钥。为了避免这种攻击，可以采用两种行为路线。（1）CA为与它交互的每一个终端实体产生一对新的D-H密钥对作为协议加密密钥对。（2）CA与每一个请求的终端实体参与密钥确认协议（本文没有做出规定）用以保证终端实体加密密钥对不易受到攻击。选择（1）显然要简单一些（不需要双方进行额外的协议交换），因此推荐选择（1）。
附 录 A
（资料性附录）
RA存在的原因
RA存在有技术和组织两方面的原因。技术原因包括下述几点：
－ 如果使用硬件令牌，那么有可能不是所有的终端实体都有对其令牌进行初始化的设备；RA设备就必须包括相应的功能（这是一个策略问题）。
－ 有些终端实体不能发布证书；同样，RA可以帮助实现这个功能。
－ 当终端实体不能发布签名的撤销请求（如果完全丢失了密钥对）时，RA就代表与其关联的终端实体进行发布。
RA存在的组织原因如下：
－ 把功能集中在RA设备中比给所有的终端实体提供功能要有效得多（特别是需要用到特殊的令牌初始化设备时）。
－ 在组织内建立RA可以减少CA的数量，这在有些情况下是很重要的。
－ RA可以更好地鉴别人们的“电子”名字，特别是当CA在物理上远离终端实体的情况下。
－ 对于很多应用，在适当的位置已经存在了管理结构，因此很容易产生RA角色（这可能不适用于CA）。
附 录 B
（资料性附录）
PKI管理消息结构大纲（必须的）
本附录包含了遵循本标准的实现必须支持的PKI消息的详细描述（参见第6节）。
在以下PKI管理操作中使用的PKIMessage的结构如下：
－ 初始的注册/认证
－ 基本认证方案
－ 证书请求
－ 密钥更新
大纲结构解释的通用规则
1、 当个人单独的大纲描述中没有可选（OPTIONAL）或缺省（DEFAULT）字段时，相关的消息中也不能有（例如：接收者可以以语法错误为由来丢弃包含这些字段的消息）。如果必须强制字段具备一些很字段很明显的值，那么文中也不会提出来特别提及（例如：在本版本的规范中，pvno总是为2）。
2、 当结构中不止一个消息时，将分别进行描述。
3、 PKIMessage结构的algorithmIdentifiers将分别描述。
4、 存在一种"特殊"的 DN被，称为"NULL-DN"；这表明DN 包含长度为0的SEQUENCE OF RelativeDistinguishedNames（它的DER编码为‘3000’H）。
5、 当某字段需要GeneralName，但是又没有合适的值时（例如：终端实体在知道它的名字之前产生了一个请求），那么GeneralName就为 NULL-DN（例如：CHOICE的Name字段含有NULL-DN）。这种特殊的值也称为“NULL-GeneralName”。
6、 当描述某大纲没有给GeneralName规定值时，相关PKIMessage字段的值就为NULL-GeneralName。这种情况通常发生在某些消息的PKI Header的sender字段。
7、 在字段命名发生歧义的时候，描述名字就使用“点”号（例如：“”表示subject字段在certTemplate字段中）。
8、 当“SEQUENCE OF types”作为消息的一部分时，我们使用以0为基的数组符号来描述SEQUENCE OF中的字段。（例如：crm[0].是指请求消息中第一个certReqMsg的子字段）。
9、 在B4-B6节中所有的PKI消息交换需要由发送实体发送certConf消息，同时由响应实体发送PKIConfirm消息。在某些描述大纲中，由于包体为NULL，而包头的内容参照上下文非常清楚，所以没有包括PKIConfirm，因为它的体为NULL，头内容在上下文中很清楚。对于protectionAlg可以使用任何认证方法（例如：如果知道共享的秘密信息可以使用基于口令的MAC，或者签名）。
算法使用参数
下表包含了在PKI管理协议中使用的算法定义。表中的各列如下：
Name：消息结构使用的标识符
Use：算法使用的原因和地方
Mandatory：相容设备执行行为必须支持的AlgorithmIdentifier
Others：必须强制型的AlgorithmIdentifier的替代
Name Use Mandatory Others
MSG_SIG_ALG 用签名保护 PKI DSA/SHA-1 RSA/MD5,
消息 ECDSA, ...
MSG_MAC_ALG 用MAC保护 PKI PasswordBasedMac HMAC,
消息 ...
SYM_PENC_ALG 使用带外 方式发布对 3-DES (3-key- RC5,
称密钥时对称加 EDE, CBC mode) CAST-128...
密终端实体的私钥
PROT_ENC_ALG 用于加密在PKIMessages D-H RSA,
中传输的（用于加密的 ECDH, ...
对称密钥中的）私钥的
非对称算法
PROT_SYM_ALG 用于加密私钥的比特 3-DES (3-key- RC5,
位（这种类型的密钥 EDE, CBC mode） CAST-128...
使用PROT_ENC_ALG进行
加密）的对称加密算法
必须的AlgorithmIdentifiers和规范说明：
DSA/SHA-1:
AlgId: {1 2 840 10040 4 3};
NIST, FIPS PUB 186: Digital Signature Standard, 1994;
Public Modulus size: 1024 bits.
PasswordBasedMac:
{1 2 840 113533 7 66 13}, with SHA-1 {1 3 14 3 2 26} as the owf
parameter and HMAC-SHA1 {1 3 6 1 5 5 8 1 2} as the mac parameter;
(this specification), along with
NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995;
H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message
Authentication", Internet Request for Comments 2104, February 1997.
HMAC key size: 160 bits (., "K" = "H" in Section , "Shared
secret information")
3-DES:
{1 2 840 113549 3 7};
(used in RSA's BSAFE and in S/MIME).
D-H:
AlgId: {1 2 840 10046 2 1};
ANSI ;
Public Modulus Size: 1024 bits.
DomainParameters ::= SEQUENCE {
p INTEGER, -- odd prime, p=jq +1
g INTEGER, -- generator, g^q = 1 mod p
q INTEGER, -- prime factor of p-1
j INTEGER OPTIONAL, -- cofactor, j>=2
validationParms ValidationParms OPTIONAL
}
ValidationParms ::= SEQUENCE {
seed BIT STRING, -- seed for prime generation
pGenCounter INTEGER -- parameter verification
}
所有权证明大纲结构
当需要证明拥有请求的证书中与验证公钥相应的签名私钥时，使用POP字段（在ProofOfPossession结构中的pop字段中的signature字段）。
Field Value Comment
algorithmIdentifier MSG_SIG_ALG 这个证明只允许采用签名保护
signature present 使用MSG_SIG_ALG计算比特位
<<证明拥有请求的证书中与加密公钥相应的解密私钥时不按照这种结构；而是使用certConf消息的CertHash字段来代替。>>
在PKIX-CMP in-band认证请求协议中，不是每一个CA/RA都需要所有权证明（签名密钥，解密密钥或密钥一致密钥）。（如何进行POP基本上是一个策略问题，每一个CA都会在公布的Policy OID 和Certification Practice Statement中表示清楚）。然而，本规范要求CA/RA实体把POP（通过某些方法）作为认证过程的一部分。所有的终端实体都必须能够提供POP（例如：PKIX-CMP协议的组件必须支持）。
初始的注册/认证（基本认证方案）
（未初始化的）终端实体向CA请求（第一个）证书。当CA返回包含有证书的消息时，终端实体会发送证书确认。CA再发回PKIConfirm，关闭交易。所有的消息都进行了认证。
本方案允许终端实体请求对本地产生公钥的认证（典型地为签名密钥）。终端实体也可以选择请求集中产生并且认证另一个密钥对（典型地为加密密钥对）。
请求认证只能用于一个本地产生的公钥（对于更多的公钥，需要使用独立的PKIMessage）。
终端实体必须支持对与本地产生公钥相关联的私钥的所有权证明。
前提：
终端实体可以验证基于带外方法的CA签名
终端实体和CA共享对称MACing密钥
消息流：
Step# End entity PKI
1 format ir
2 -> ir ->
3 handle ir
4 format ip
5 <- ip <-
6 handle ip
7 format certConf
8 -> certConf ->
9 handle certConf
10 format PKIConf
11 <- PKIConf <-
12 handle PKIConf
在本大纲中，我们要求终端实体在一个PKIMessage中包含所有的（例如：一个或者两个）CertReqMsg，同时PKI（CA）必须产生一个包含完整响应的响应PKIMessage（例如：在请求发生进行了相应请求，并且支持集中密钥产生密钥的情况下，终端实体在一个PKIMessage中还要包括OPTIONAL可选的次第二对密钥对）。为了简化，我们要求这些消息必须是最后一个（例如：不使用“waiting”状态值）。
终端实体与CA/RA有带外交互作用。这个交易建立了共享秘密，、referenceNumber参考号码和用于证书模板中sender和subject name的可选的（OPTIONALLY）distinguished name可识别名称DN。建议共享秘密至少长12个字符。
ir:
Field Value
recipient CA name
-- 被要求产生证书的CA的名字
protectionAlg MSG_MAC_ALG
-- 这个本请求只允许MAC保护, 基于
-- 初始的认证密钥
senderKID referenceNum
-- 索引号，由CA预先发给
-- 终端实体(同时还有MACing密钥)
transactionID present
-- 特定执行的值, 对终端实体有意义。
-- [如果已经该值在CA中已经使用，那么要发送由CA产生的丢弃将发送拒绝消息]
senderNonce present
-- 128 (伪)随机比特
freeText any valid value
body ir (CertReqMessages)
only one or two CertReqMsg
are allowed
-- 如果请求更多的证书，那么要求请求就要求被打包在独立的PKIMessages中
CertReqMsg one or two present
-- 看参见下面的详细资料细节, 注意: crm[0]表示第一个(这是必须有的)
-- crm[1]表示第二个 (这是可选的，并且用于请求集中产生的密钥)
crm[0].certReq. fixed value of zero
certReqId
--消息中模板的索引
crm[0].certReq present
certTemplate
-- 必须包含对象公钥值,否则就不受强制其他的（值）不受限制
crm[0].pop... optionally present if public key
POPOSigningKey from crm[0]. is
a signing key
-- 在交换中可能要求所有权证明POP (参看
-- B3 可以得到详细描述)
crm[0].certReq. optionally present
-- 终端实体可以请求获得本地产生的私钥被归档
crm[0].certReq. optionally present
-- 终端实体可以要求公布发布结果证书.
crm[1].certReq fixed value of one
certReqId
-- 消息中模板的索引
crm[1].certReq present
certTemplate
-- 不一定要求包含实际的公钥比特, 其他的（值）不受限制否则就不受强制
-- (例如：名字不一定要和crm[0]的一样)。 注意
-- subjectPublicKeyInfo 可能存在并且包含
-- AlgorithmIdentifier，在它后面接着一个长度为0的BIT STRING作为
-- subjectPublicKey，这种情况发生在需要通知传达CA/RA与要产生的密钥对相关的算法信息和
-- 关于要产生的密钥对的变量参数选择信息的时候。
crm[1].certReq. present [object identifier MUST be PROT_ENC_ALG]
-- 如果CA支持集中地密钥产生, CA将用这个
-- 短期的非对称加密密钥 (由终端实体产生)来加密（用对称密钥来加密）CA为终端实体产生的私钥
-- 代表终端实体来加密 (用于加密的对称密钥)
-- CA产生的私钥
crm[1].certReq. optionally present
crm[1].certReq. optionally present
protection present
-- 使用 MSG_MAC_ALG计算比特位
ip:
Field Value
sender CA name
-- 产生消息的CA的名字
messageTime present
-- CA产生消息的时间
protectionAlg MS_MAC_ALG
-- 这个本响应只允许MAC保护
senderKID referenceNum
-- 索引号，由CA预先发给
-- 终端实体(同时还有MACing密钥)
transactionID present
-- 相应ir消息中的值
senderNonce present
-- 128 (伪)随机比特
recipNonce present
-- 相应ir消息中 senderNonce的值
freeText any valid value
body ip (CertRepMessage)
contains exactly one response
for each request
-- PKI (CA) 适当地对一个或者两个请求的响应。
-- crc[0] 表示第一个（一直存在）；crc[1]表示
-- 第二个(仅存在于ir消息包含两个请求并且
-- CA支持集中地密钥产生)。
crc[0]. fixed value of zero
certReqId
-- 必须包含对相应ir消息中第一个请求的响应
crc[0].status. present, positive values allowed:
status "accepted", "grantedWithMods"
negative values allowed:
"rejection"
crc[0].status. present if and only if
failInfo crc[0]. is "rejection"
crc[0]. present if and only if
certifiedKeyPair crc[0]. is
"accepted" or "grantedWithMods"
certificate present unless end entity's public
key is an encryption key and POP
is done in this in-band exchange
encryptedCert present if and only if end entity's
public key is an encryption key and
POP done in this in-band exchange
publicationInfo optionally present
-- 表明证书已经发布(由
-- CA决定它的存在)
crc[1]. fixed value of one
certReqId
-- 必须包含对相应ir消息中第二个请求的响应
crc[1].status. present, positive values allowed:
status "accepted", "grantedWithMods"
negative values allowed:
"rejection"
crc[1].status. present if and only if
failInfo crc[0]. is "rejection"
crc[1]. present if and only if
certifiedKeyPair crc[0]. is "accepted"
or "grantedWithMods"
certificate present
privateKey present (see Appendix D)
publicationInfo optionally present
-- 表明证书已经发布(由
-- CA决定它的存在)
protection present
-- 使用MSG_MAC_ALG计算比特位
extraCerts optionally present
-- CA可以给终端实体提供额外附加的其他的证书
certConf:
Field Value
sender present
-- 与ir中的相同
recipient CA name
-- 被要求产生证书的 CA的名字
transactionID present
-- 相应 ir 和 ip 消息中的值
senderNonce present
-- 128 (伪)随机 比特
recipNonce present
-- 相应ip消息中senderNonce的值
protectionAlg MSG_MAC_ALG
-- 这个消息只允许MAC保护。MAC是
-- 基于EE和CA共享的初始的auth'n 密钥。
senderKID referenceNum
-- 索引号，由CA预先发给
-- 终端实体(同时还有MACing密钥)
body certConf
-- 参看 节中certConf字段内容
-- 注意: 如果发送了加密和签名的证书，那么
-- 需要两个CertStatus结构。
protection present
-- 使用MSG_MAC_ALG计算比特位
PKIConf:
Field Value
sender present
-- 与ip中的相同
recipient present
-- certConf中发送者的名字
transactionID present
-- 从certConf消息中得到值
senderNonce present
-- 128 (伪)随机 比特
recipNonce present
-- certConf 消息中senderNonce的值
protectionAlg MSG_MAC_ALG
-- 这个消息只允许 MAC保护。
senderKID referenceNum
body PKIConf
protection present
-- 使用MSG_MAC_ALG计算比特位
证书请求
（已经初始化的）终端实体（由于某种出于任何原因）向CA请求证书。当CA返回包含有证书的消息时，终端实体会发送证书确认。CA再发回PKIConfirm，关闭交易。所有的消息都进行了认证。
除了下面的差别之外，本大纲中的消息交互流程与B4节中的一样，但是有以下不同：
－ 发送者名字应该存在
－ 在request，response，certConfirm和PKIConfirm消息中必须支持MSG_SIG_ALG的protectionAlg（也要支持MSG_MAC_ALG也可以被支持）；
－ senderKID和recipKID仅在请求消息验证时才存在；
－ body为cr或cp；
－ body可能包含一种或两种CertReqMsg结构，但是CertReqMsg只用可用于请求认证为本地的产生密钥申请证书，也可用于为或者集中产生的密钥申请证书（例如：B4节中位置独立与位置相关的要求可以去除）
－ 保护比特根据protectionAlg字段来计算。
密钥更新请求
（已经初始化的）终端实体向CA请求证书（用于更新密钥对和/或已经拥有的相应证书）。当CA返回包含有证书的消息时，终端实体会发送证书确认。CA再发回PKIConfirm，关闭交易。所有的消息都进行了认证。
除了下面的差别之外，本大纲中的消息交互流程与B4节中的一样，但是有以下不同：
－ 发送者名字应该存在
－ 在request，response，certConfirm和PKIConfirm消息中必须支持MSG_SIG_ALG的protectionAlg（也要支持MSG_MAC_ALG也可以被支持）；
－ senderKID和recipKID仅在请求消息验证时才存在；
－ body为kur或kup；
－ body可能包含一种或两种CertReqMsg结构，但是CertReqMsg只用于请求认证既可用于为本地产生的密钥生成证书，又可用于为或者集中产生的密钥生成证书（例如：B4节中与位置独立相关的要求可以去除）
－ 保护比特根据protectionAlg字段来计算；
－ 要求使用regCtrl OldCertId（除非sender和receiver对这此都很清楚明确－在本文档中不指定双方明确的方法－否则此时可以就不需要它了）。
附 录 C
（资料性附录）
PKI管理消息结构（可选的）
本附录包含了遵循本标准的实现可以支持的PKI消息的详细描述（必须要支持的消息－参看第4节和附录B）。
在以下PKI管理操作中使用的PKIMessage的结构大纲如下：
－ 根CA密钥更新
－ 信息请求/响应
－ 交叉认证请求/响应
－ 使用外部实体证书的带内in-band初始化
<<本文档的以后版本将扩展以上的结构描述，并包括以下所列操作的结构大纲（如果需要还可以包括别的结构操作）。>>
－ 撤销请求
－ 证书发布
－ CRL发布
结构解释的通用规则
（与附录B1相同。）
算法使用参数
（与附录B2相同。）
自签名证书
介绍自签名证书结构。这些结构用于分发“根”CA的公钥。这发生于三种方式中的一种（参见节可以得到这些结构的用法的描述）：
类型 功能
newWithNew 真正的自签名证书；所包含的公钥必须能用于验证
签名（尽管这只提供了完整性，并且没有任何认证）
oldWithNew 用新的私钥对以前的根CA公钥签名
newWithOld 用以前的私钥对新的根CA公钥签名
<<这种证书 (包括相关扩展) 必须在所有字段中包含"敏感的（sensible）"值。例如：在当前如果 subjectAltName存在，则必须与issuerAltName的值相同的时候, 以及在当前如果keyIdentifiers存在，则必须包含合适的值时,等等。>>
根CA密钥更新
根CA更新密钥对。而后它将产生（通过某些传输机制）相关终端实体能够获得的CA密钥更新声明消息。并且不需要从终端实体那里获得确认消息。
ckuann message:
字段 值
注释
sender CA name
CA名称
body ckuann(CAKeyUpdAnnContent)
oldWithNew 必须存在 参见如上C3
newWithOld 必须存在
参见如上C3
newWithNew 必须存在
参见如上C3
extraCerts
可选
用于发布证书（例如使用新私钥签发的证书）
PKI信息请求/响应
终端实体发送general通用消息给PKI，以请求今后随后的PKI管理操作中所需要的细节。RA/CA用general通用通常的响应消息来响应。如果RA产生响应，那么它将简单地将从CA那里收到的消息向前传转发，可能还会在PKIMessage中的extraCerts字段中加上证书。本消息不需要从终端实体处获得确认消息。
消息流：
Step# End entity PKI
1 format genm
2 -> genm ->
3 handle genm
4 produce genp
5 <- genp <-
6 handle genp
genM:
Field Value
recipient CA name
-- 证书中issuerAltName扩展或issuer字段包含的CA 的名字
protectionAlg MSG_MAC_ALG or MSG_SIG_ALG
-- 任何一种鉴别保护算法。
SenderKID present if required
-- 在需要验证消息保护的情况下必须存在
freeText any valid value
body genr (GenReqContent)
GenMsgContent empty SEQUENCE
-- 所有请求的相关信息
protection present
-- 使用MSG_MAC_ALG 或 MSG_SIG_ALG计算比特位
genP:
Field Value
sender CA name
-- 产生消息的 CA的名字
protectionAlg MSG_MAC_ALG or MSG_SIG_ALG
-- 任何一种鉴别保护算法。
senderKID present if required
-- 在需要验证消息保护的情况下必须存在
body genp (GenRepContent)
CAProtEncCert present (object identifier one
of PROT_ENC_ALG), with relevant
value
-- 在终端实体为CA加密信息时使用
-- (例如, 用于私钥恢复)
SignKeyPairTypes present, with relevant value
-- CA为对象公钥验证的签名算法标识符集合
EncKeyPairTypes present, with relevant value
-- CA为对象公钥验证的加密/密钥一致算法标识符集合
PreferredSymmAlg present (object identifier one
of PROT_SYM_ALG) , with relevant
value
-- CA希望在随后以后的PKI消息（为了加密）中使用的对称算法
CAKeyUpdateInfo optionally present, with
relevant value
-- CA使用这个字段提供关于相关根CA密钥对的信息
-- (注意这并不表示响应的CA为所讨论的根CA)
CurrentCRL optionally present, with relevant value
-- CA提供CRL的完整拷贝 (例如,最可能完整)
protection present
-- 使用MSG_MAC_ALG或MSG_SIG_ALG计算比特位
extraCerts optionally present
-- 可用于给终端实体发送证书。
-- RA可以把它的证书加在这里。
交叉认证请求/响应（单向）
单个交叉证书的产生（例如即：不要立刻产生两个不同时产生两个）。请求CA可以通过使用PKIPublicationInfo控制来选择由谁来负责发布响应CA产生的交叉证书。
前提：
1、 响应CA在处理请求之前能够验证请求的来源（可能请求要求带外方法）。
2、 请求CA在处理响应之前可以鉴别响应源的真实性（可能请求要求带外方法）。
PKIHeader中的generalInfo字段决定是否使用证书确认和相应的服务器确认（参看节）。以下流程不要求支持任何一种确认。
消息流：
Step# Requesting CA Responding CA
1 format ccr
2 -> ccr ->
3 handle ccr
4 produce ccp
5 <- ccp <-
6 handle ccp
ccr:
Field字段 Value值
sender Requesting CA name请求CA
-- 产生消息的CA的名字
recipient Responding CA name响应CA
-- 被要求产生证书的CA的名字
messageTime time of production of message产生消息的时间
-- 请求CA的当前时间
protectionAlg MSG_SIG_ALG
-- 这个请求只允许签名保护
senderKID present if required
-- 如果在要求对消息保护进行验证的情况下时需要则必须存在
recipKID present if required
-- 如果在要求对消息保护进行验证的情况下时需要则必须存在
transactionID present
-- 执行特定与实现相关的值, 对请求CA有意义。
-- [如果已经在响应CA中使用，那么要发送由响应CA必须产生的丢弃一个拒绝消息]
senderNonce present
-- 128比特 (伪)随机 比特数
freeText any valid value任何有效值
body ccr (CertReqMessages)
only one CertReqMsg
allowed只允许一个CertReqMsg
-- 如果请求多重多个交叉证书，那么就要就必须打包在不同的PKIMessage中打包
certTemplate present
-- 后面是细节如下
version v1 or v3
-- <<强烈建议v3 >>
signingAlg present
-- 请求CA必须事先知道用什么算法来对证书签名
subject present
-- 仅在提议使用subjectAltNames扩展项时可以为NULL-DN
validity present
-- 必须完全指定(例如即，两个字段都存在)
issuer present
-- 仅在提议使用issuerAltNames扩展项时可以为NULL-DN
publicKey present
-- 需要鉴定认证的密钥 (用于必须是一种签名算法的密钥)
extensions optionally present
-- 请求CA必须为要求出现在交叉证书中请求的所有扩展建议取值
POPOSigningKey present
-- 参看 "所有权证明结构" (B3节)
protection present
-- 使用MSG_SIG_ALG计算比特位
extraCerts optionally present
-- 可以包含请求者想要包括的任何额外证书
ccp:
Field字段 Value值
sender Responding CA name响应CA的名字
-- 产生消息的CA的名字
recipient Requesting CA name请求CA的名字
-- 被要求产生证书的CA的名字
messageTime time of production of message产生消息的时间
-- 响应CA的当前时间
protectionAlg MSG_SIG_ALG
-- 这个消息只允许签名保护
senderKID present if required
--如果在要求对消息保护进行验证的情况下时需要则必须存在
recipKID present if required
transactionID present
-- 相应ccr消息中的值
senderNonce present
-- 128 比特(伪)随机数 比特
recipNonce present
-- 相应ccr消息中的senderNonce
freeText any valid value任何有效值
body ccp (CertRepMessage)
only one CertResponse allowed只允许一个CertResponse
-- 如果请求多重多个交叉证书，那么就要就必须打包在不同的PKIMessage中打包
response present
status present
present
-- 如果为下面两种情况之一:
-- accepted,或
-- grantedWithMods,
-- 那么 certifiedKeyPair必须存在同时failInfo必须缺省省略
failInfo present depending on
-- 如果为:
-- rejection
-- 那么certifiedKeyPair必须缺省省略同时 failInfo必须存在
-- 而且设置了相应的比特位
certifiedKeyPair present depending on
certificate present depending on
certifiedKeyPair
-- 在发布之前由请求CA必须检查的实际证书的内容
protection present
-- 使用MSG_SIG_ALG计算的比特位
extraCerts optionally present
-- 可以包含响应者想要包括的任何额外证书
使用外部身份证书进行In-band带内初始化
（未初始化的）终端实体希望初始化为CA的PKI，CA-1 PKI(CA为CA-1)的一员。为了鉴别身份，它使用原来一个已经存在的由另一个（外部）CA，CA-X发布签发的身份证书。在CA-1和CA-X之间必须已经建立信任关系，这样CA-1才能使验证EE的由CA-X签名的证书生效。另外，在EE的个人安全环境（PSE）中必须建立一些机制，使得以允许终端实体可以鉴别和验证由CA-1签名的PKIMessage（例如，PSE包含为CA-1公钥发布签发的证书，这个证书由终端实体信任的另一个CA在带外验证技术基础上签名，这种信任建立在带外认证技术基础上）。
终端实体发送初始化请求来开始启动交易。当CA-1用包含新证书的消息响应时，终端实体返回证书确认。CA-1发送PKIConfirm来结束交易。所有的消息都经过签名（EE消息使用与外部身份证书中的公钥相对应的私钥来签名；CA-1消息用与EE的PSE中信任的另一个证书公钥相对应的私钥来签名）。
消息交互流程与B4节中的一样，但是有以下不同：
－ EE和CA-1不共享对称MACing密钥（例如即，在这些实体之间没有out-of-band的带外共享的秘密信息）；
－ ir中发送者sender名字必须存在（并且与外部身份证书中对象subject名字一样）
－ 在所有消息的protectionAlg中必须使用MSG_SIG_ALG的protectionAlg；
－ 在ir的extraCerts字段中必须携带外部身份证书
－ 不使用senderKID和recipKID；
－ body为ir或ip；
－ 保护比特数根据protectionAlg字段来计算。
附 录 D
（资料性附录）
请求消息行为说明
以下的定义从来自rfc2511bis来。包含在这里主要是为了使对请求消息中的行为说明进行编码更系统； 另外，所有的语法和语义与rfc2511bis中的一样。
CertRequest ::= SEQUENCE {
certReqId INTEGER,
certTemplate CertTemplate,
controls Controls OPTIONAL }
-- 如果certTemplate为空序列(例如即, 省略所有字段),
-- 那么controls中可以要包括id-regCtrl-altCertTemplate控制,
-- 用于指定不同于一个非公钥证书的证书模板。
-- 相反地，如果certTemplate不为空 (例如即，至少存在一个字段),
-- 那么controls中不一定不能要包括id-regCtrl-altCertTemplate控制。
-- 新的control控制定义如下:
id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= {id-regCtrl 7}
AltCertTemplate ::= AttributeTypeAndValue
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
-- **********
-- * 本规范目的为, 在rfc2511bis 所作的注释不仅适合于适用于
-- * certTemplate，同时也适合于适用于altCertTemplate控制。
-- * 即,
-- **********
-- * 签名(使用 "algorithmIdentifier")在poposkInput的DER编码值上进行
-- * (例如即，POPOSigningKeyInput的 DER编码的“value”字节)。
-- * 注意: 如果 CertReqMsg .certReq .certTemplate(或者altCertTemplate control)
-- * 包含对象subject和公钥publicKey的值,那么必须省略poposkInput
-- * 同时签名必须在CertReqMsg .certReq (或者AltCertTemplate的 DER编码的值)
-- * 的DER编码的值的基础上计算。
-- * 如果certTemplate/altCertTemplate不同时包含对象和公钥的值subject和publicKey值
-- * (例如即，它只包含其中之一，或者均不包括),
-- * 那么poposkInput必须存在，同时对其DER编码进行签名。
-- **********
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING,
-- **********
-- * "thisMessage"的类型在rfc2511bis为BIT STRING；
-- * 它应该为 "EncryptedValue" (与本规范中的节一致)。
-- * 因此,本文档使行为说明指定"thisMessage"的内容必须按编码为
-- * EncryptedValue进行编码，然后包装为BIT STRING。
-- * 这允许在保持比特在线与rfc2511bis兼容的时候， 同时
-- * 传输和保护私钥。
-- **********
subsequentMessage [1] SubsequentMessage,
dhMAC [2] BIT STRING }
附 录 E
（资料性附录）
使用"口令短语"
撤销请求必须合并采用合适的安全机制，包括恰当的验证，用于减少拒绝服务攻击发生成功的可能性。对请求的数字签名－（在本规范中在如果支持撤销请求的情况下必须支持－）能够满足验证要求，但是在某些情况下需要有替代机制（例如，私钥已经不能访问，但是终端实体希望在重新认证另一个密钥对之前请求撤销）。为了满足这些情况，在本规范中，同时如果支持撤销请求并且在需要撤销之前请求者和响应者之间可以建立共享的秘密信息，那么在本规范中要求必须支持对请求的PasswordBasedMAC（以符合给定环境的本地安全策略）。
"Revocation Passphrase"是已经在某些环境中使用的一种机制，在这种机制中，一个足够平均的值（例如，相对长的passphrase而不是短的password）在撤销之前就在且仅在实体和CA/RA之间共享，并且在以后用于验证撤销请求。
在本规范中，是否支持下列用于建立共享秘密信息（例如，revocation passphrase）的技术是可选的。在CMP消息中的准确使用如下：
－ OID以及在节中指定的OID以及值可在任何时间在GenMsg消息中发送，或者也可以在任何时间任何一个PKIMessage的PKIHeader的generalInfo字段中发送。（特别地，EncryptedValue可以在certConf消息头中发送EncryptedValue，certConf该消息是用于确认已经接受了在初始化请求和证书请求消息中所请求的证书。）这表明表示revocation passphrase由终端实体（例如即，encValue字段的解密后的字节）选择给为相关的CA/RA选择的revocation passphrase；另外，传输也使用适当的加密机制来完成秘密字符进行传输（因为passphrase使用CA/RA的protocolEncryptionKey加密）。
－ 如果CA/RA在GenMsg中接收到revocation passphrase（OID以及在节中指定的OID以及值），它必须构造并发送GenRep消息，这个消息包含了在节中指定OID（值为空）。如果CA/RA在任何一个PKIMessage的PKIHeader的generalInfo字段中接收到revocation passphrase，它必须包含在相应响应PKIMessage的PKIHeader的generalInfo字段中的包含该OID（值为空）。如果CA/RA由于某种原因不能返回适当的响应消息，那么它必须返回状态为“rejection”的错误消息，同时可以给出选的一组failInfo原因 reason set。
－ EncryptedValue 的valueHint字段可以包含了一个密钥标识符（由实体选择，同时还带有passphrase本身）用于帮助以后获得对正确的passphrase的检索（例如，当撤销请求由实体构造并且由CA/RA接收）。
－ 撤销请求消息用PasswordBasedMAC来保护，用revocation passphrase作为密钥。如果合适的话，PKIHeader中的senderKID字段可以包含valueHint中的值。
使用以上技术，revocation passphrase可以在任何时候在不请求额外消息或者带外交互的情况下进行初始化建立和更新，而不要求额外消息或带外交互。例如，撤销请求消息本身（通过使用revocation passphrase作为密钥的MAC来保护和验证，使用revocation passphrase作为密钥）可以在PKIHeader中包含一个新的revocation passphrase以用于验证以后对实体的别的其它证书的撤销请求。在某些情况下，这种机制优于其它一些有些机制可能会在撤销请求消息中显示会暴露passphrase的机制，因为但是这可能会引起允许拒绝服务攻击，在这种情况下显示暴露的passphrase会被未授权的第三方用于验证对实体别的证书的撤销请求。然而，由于在请求消息中没有显示暴露passphrase，因此不要求在产生撤销请求的时候总是更新passphrase（也就是说，在不同的时候对不同证书的撤销请求的验证可以使用同一个passphrase）。
另外，以上技术可以在不使用签名的情况下依然对整个撤销请求消息提供强加密保护。简单显示通过暴露revocation passphrase来验证撤销请求的技术不对请求消息的字段提供加密保护（因此请求撤销一个证书的请求可能会被未授权的第三方修改，而请求撤销该实体的另一个证书）。
附 录 F
（规范性附录）
“可编译”的使用1988语法的模型
PKIXCMP {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp2000(16)}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
Certificate, CertificateList, Extensions, AlgorithmIdentifier,
UTF8String – 如果需要; otherwise, comment out否则掉
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit-88(1)}
GeneralName, KeyIdentifier
FROM PKIX1Implicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit-88(2)}
CertTemplate, PKIPublicationInfo, EncryptedValue, CertId,
CertReqMessages
FROM PKIXCRMF {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-crmf(5)}
-- 也参见本规范的附录D中行为说明编码
CertificationRequest
FROM PKCS-10 {iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-10(10) modules(1) pkcs-10(1)}
-- (在RFC 2986中指定，使用1993 语法和IMPLICIT标记)。
-- 作为选择, 执行实现者可以在这个模型模块中直接包括[PKCS10]语法；
-- 这个模型本模块的剩下其余部分包含本地定义的OID和结构 --
CMPCertificate ::= CHOICE {
x509v3PKCert Certificate
}
--当比特在线与标准对“证书”的定义兼容时，这个语法允许在本证书管理协议中使--用将来的证书类型（比如属性证书，WAP WTLS证书或者别种证书），现在已经产生--了对通用性支持的需求。对于没有预见到需要支持别的证书类型的执行实现，如果它们希望的话，可以在编译这个模型模块之前注释掉以上的结构并且“不注释”以下的结构。（注意：与没有进行这种该操作的执行实现的互操作性将不受这个改变的影响。）
-- CMPCertificate ::= Certificate
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL
}
PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage
PKIHeader ::= SEQUENCE {
pvno INTEGER { cmp1999(1), cmp2000(2) },
sender GeneralName,
-- 标识发送者
recipient GeneralName,
-- 标识预期的接收者
messageTime [0] GeneralizedTime OPTIONAL,
-- 产生这个消息的时间
-- （当发送者认为该时间的传输合适时使用；即，时间对接收来说有意义)
protectionAlg [1] AlgorithmIdentifier OPTIONAL,
-- 用于计算保护比特位的算法
senderKID [2] KeyIdentifier OPTIONAL,
recipKID [3] KeyIdentifier OPTIONAL,
-- 识别用于保护的特定密钥
transactionID [4] OCTET STRING OPTIONAL,
-- 标识交易；即在相关的请求、响应和确认消息中，该字段值相同
senderNonce [5] OCTET STRING OPTIONAL,
recipNonce [6] OCTET STRING OPTIONAL,
-- 用于防止重放攻击的随机数，senderNonce由消息的创建者赋值，
-- recipNonce是由本消息的预期接收者先前插入到相关消息中的随机数
freeText [7] PKIFreeText OPTIONAL,
-- 可以用于表示上下文相关的说明（本字段主要由人工使用）
generalInfo [8] SEQUENCE SIZE (1..MAX) OF
InfoTypeAndValue OPTIONAL
-- 可以用于表示上下文相关的说明(本字段不是供人工使用的)
}
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
-- 按UTF-8[RFC2279]编码的文本(注意：每一个UTF8String都可以包含
-- 一个RFC 1766/RFC 3066语言标签，用于表示所包含文本属于哪一种语
-- 言–详情请参见[RFC2482])
PKIBody ::= CHOICE { -- message-specific body elements
ir [0] CertReqMessages, --初始化请求
ip [1] CertRepMessage, --初始化响应
cr [2] CertReqMessages, --认证请求
cp [3] CertRepMessage, --认证响应
p10cr [4] CertificationRequest, --从[PKCS10]导入
popdecc [5] POPODecKeyChallContent, --pop 挑战
popdecr [6] POPODecKeyRespContent, --pop 响应
kur [7] CertReqMessages, --密钥更新请求
kup [8] CertRepMessage, --密钥更新响应
krr [9] CertReqMessages, --密钥恢复请求
krp [10] KeyRecRepContent, --密钥恢复响应
rr [11] RevReqContent, --作废请求
rp [12] RevRepContent, --作废响应
ccr [13] CertReqMessages, --交叉认证请求
ccp [14] CertRepMessage, --交叉认证响应
ckuann [15] CAKeyUpdAnnContent, --CA密钥更新公告
cann [16] CertAnnContent, --证书公告
rann [17] RevAnnContent, --作废公告
crlann [18] CRLAnnContent, --CRL公告
pkiconf [19] PKIConfirmContent, --确认
nested [20] NestedMessageContent, --嵌套消息
genm [21] GenMsgContent, --通用消息
genp [22] GenRepContent, --通用响应
error [23] ErrorMsgContent, --错误消息
certConf [24] CertConfirmContent, --证书确认
pollReq [25] PollReqContent, --轮询请求
pollRep [26] PollRepContent --轮询响应
}
PKIProtection ::= BIT STRING
ProtectedPart ::= SEQUENCE {
header PKIHeader,
body PKIBody
}
id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
-- 注释注意：为了减少拒绝服务攻击的可能性，执行实现可能会限制这个串的可接受的串的长度以符合自己的
环境中的取值，
-- 这样可以减少拒绝服务攻击
owf AlgorithmIdentifier,
-- 单向算法ID (建议SHA-1)
iterationCount INTEGER,
-- OWF的应用次数
-- 注释注意：为了减少拒绝服务攻击的可能性，实现执行可能会限制这个整数的可接受的整数的大小以符合自己的环境中的取值，这样可以减少拒绝服务攻击
mac AlgorithmIdentifier
--单向算法ID (例如, DES-MAC, Triple-DES-MAC [PKCS11],
} -- 或者HMAC [RFC2104, RFC2202])
id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30}
DHBMParameter ::= SEQUENCE {
owf AlgorithmIdentifier,
--单向算法ID (建议SHA-1)
mac AlgorithmIdentifier
-- MAC算法ID (例如，DES-MAC, Triple-DES-MAC [PKCS11],
} -- 或者 HMAC [RFC2104, RFC2202])
NestedMessageContent ::= PKIMessages
PKIStatus ::= INTEGER {
accepted (0),
--表示得到了所要求的数据
grantedWithMods (1),
--得到的数据与所要求的类似，但申请者有责任确定有无差别
rejection (2),
-- 无法得到数据，在该消息的其它地方有更多的信息
waiting (3),
-- 请求的包体尚未被处理，期望稍后将获取结果（注意：对具有该状态的响应，恰当的处理方式可以是使用中定义的轮询请求/响应PKIMessages；使用底层的传输层轮询机制也是一种可行的方法。
revocationWarning (4),
--本消息包含一个即将作废的警告信息
revocationNotification (5),
--通知已经作废
keyUpdateWarning (6)
--在密钥更新请求消息中oldCertId指示的密钥已经更新
}
PKIFailureInfo ::= BIT STRING {
-- 因为多种情况可能导致失败，所以在需要时可以加入更多的代码
badAlg (0),
--不可识别或者不支持的算法标识符
badMessageCheck (1),
-- 完整性检查失败 (例如，签名验证不成功)
badRequest (2),
--不允许或不支持的交易
badTime (3),
--根据本地策略，请求中的messageTime与系统时间不够接近
badCertId (4),
--无法找到与提供的条件匹配的证书
badDataFormat (5),
--提交的数据格式错误
wrongAuthority (6),
--请求中指明的权威机构与本响应的创建者不同
incorrectData (7),
--申请者的数据错误 (用于公证服务)
missingTimeStamp (8),
--在要求存在时戳的时候没有提供（根据政策要求）
badPOP (9),
--拥有证明失败
certRevoked (10),
--证书已经被作废
certConfirmed (11),
-- 证书已经被确认
wrongIntegrity (12),
--无效的完整性，应当使用基于口令方式但采用了签名方式或反之
badRecipientNonce (13),
--无效的接收者随机数，没有提供RecipientNonce或取值错误
timeNotAvailable (14),
-- TSA服务的时钟源无法得到
unacceptedPolicy (15),
--请求的TSA政策不被TSA服务支持
unacceptedExtension (16),
--要求的扩展项不被TSA服务支持
addInfoNotAvailable (17),
--无法理解要求的附加信息或者该附加信息无法得到
badSenderNonce (18),
--无效的接收者信息，没有提供SenderNonce或取值错误
badCertTemplate (19),
--无效的证书模板，或者缺少强制信息
signerNotTrusted (20),
--消息的签发者不可知或者不被信任
transactionIdInUse (21),
--交易标识符已经在用
unsupportedVersion (22),
-- 消息版本号不支持
notAuthorized (23),
--发送者未被授权发出前面的请求或者执行前面的操作
systemUnavail (24),
--系统不可用，所以请求无法被处理
systemFailure (25),
--系统失败，所以请求无法被处理
duplicateCertReq (26)
--由于同样的证书已经存在，所以证书不能发放
}
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL
}
OOBCert ::= CMPCertificate
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
-- hashVal 在相应证书的subjectPublicKey字段的 DER编码之上计算
}
POPODecKeyChallContent ::= SEQUENCE OF Challenge
-- 每个加密密钥认证请求对应一个Challenge（次序与请求出现在CertReqMessages中的次序保持一致）
Challenge ::= SEQUENCE {
owf AlgorithmIdentifier OPTIONAL,
--在第一个Challenge中必须存在；而在POPODecKeyChallContent随后的Challenge中可以省略。（如果省略的话，则使用前一个Challenge中的owf字段。）
witness OCTET STRING,
--对随机产生的整数A应用单向函数(owf)的结果。[注意每个Challenge都必须使用不同的整数。
challenge OCTET STRING
-- 加密后的Rand（使用认证请求中的公钥加密），Rand定义如下
-- Rand ::= SEQUENCE {
-- int INTEGER,
-- 上面提到的随机产生的整数A
-- sender GeneralName
-- 发送者的名称(与PKIHeader中的相同)
-- }
}
POPODecKeyRespContent ::= SEQUENCE OF INTEGER
--每个加密密钥认证请求对应一个整数 (这些整数的顺序与请求出现在CertReqMessages中的顺序保持一致)。收到的整数（上面提到的A）被返回给相应Challenge的发送者。
CertRepMessage ::= SEQUENCE {
caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL,
response SEQUENCE OF CertResponse
}
CertResponse ::= SEQUENCE {
certReqId INTEGER,
-- 使用此项使响应与请求对应 (若相对应的请求中未指明certReqId ，则此项应填-1)
status PKIStatusInfo,
certifiedKeyPair CertifiedKeyPair OPTIONAL,
rspInfo OCTET STRING OPTIONAL
--类似于[rfc2511bis]中CertReqMsg结构中为regInfo定义的id-regInfo-utf8Pairs字符串
}
CertifiedKeyPair ::= SEQUENCE {
certOrEncCert CertOrEncCert,
privateKey [0] EncryptedValue OPTIONAL,
-- 参看 [rfc2511bis]中编码的说明
publicationInfo [1] PKIPublicationInfo OPTIONAL
}
CertOrEncCert ::= CHOICE {
certificate [0] CMPCertificate,
encryptedCert [1] EncryptedValue
}
KeyRecRepContent ::= SEQUENCE {
status PKIStatusInfo,
newSigCert [0] CMPCertificate OPTIONAL,
caCerts [1] SEQUENCE SIZE (1..MAX) OF
CMPCertificate OPTIONAL,
keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
CertifiedKeyPair OPTIONAL
}
RevReqContent ::= SEQUENCE OF RevDetails
RevDetails ::= SEQUENCE {
certDetails CertTemplate,
-- 允许请求者尽可能多的指明请求作废的证书的资料
-- (例如：在无法获得序列号的情况下)
crlEntryDetails Extensions OPTIONAL
-- 请求的crlEntryExtensions
}
RevRepContent ::= SEQUENCE {
status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
--与RevReqContent中发送的顺序相同
revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
--作废请求的IDs (与status的顺序相同)
crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL
--结果CRL (可能不止一个)
}
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew CMPCertificate, --用新私钥签名的旧证书
newWithOld CMPCertificate, --用旧私钥签名的新证书
newWithNew CMPCertificate --用新私钥签名的新证书
}
CertAnnContent ::= CMPCertificate
RevAnnContent ::= SEQUENCE {
status PKIStatus,
certId CertId,
willBeRevokedAt GeneralizedTime,
badSinceDate GeneralizedTime,
crlDetails Extensions OPTIONAL
--额外的CRL 细节(如：crl 序列号、作废原因、位置等)
}
CRLAnnContent ::= SEQUENCE OF CertificateList
CertConfirmContent ::= SEQUENCE OF CertStatus
CertStatus ::= SEQUENCE {
certHash OCTET STRING,
--证书的HASH，其算法与创建及验证证书签名的算法相同
certReqId INTEGER,
--使确认与相应的请求/响应匹配
statusInfo PKIStatusInfo OPTIONAL
}
PKIConfirmContent ::= NULL
InfoTypeAndValue ::= SEQUENCE {
infoType OBJECT IDENTIFIER,
infoValue ANY DEFINED BY infoType OPTIONAL
}
-- 实例 InfoTypeAndValue 的内容包括以下方面，但是不是限制在这些方面，InfoTypeAndValue的内容包含但不限于下列值(对给定的环境，将本模块的注释去掉并恰当地使用):
-- （不对模型进行注释，同时对给定的环境进行恰当的使用）：
--
-- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1}
-- CAProtEncCertValue ::= CMPCertificate
-- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2}
-- SignKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier
-- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3}
-- EncKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier
-- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4}
-- PreferredSymmAlgValue ::= AlgorithmIdentifier
-- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5}
-- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent
-- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6}
-- CurrentCRLValue ::= CertificateList
-- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7}
-- UnsupportedOIDsValue ::= SEQUENCE OF OBJECT IDENTIFIER
-- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10}
-- KeyPairParamReqValue ::= OBJECT IDENTIFIER
-- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11}
-- KeyPairParamRepValue ::= AlgorithmIdentifer
-- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12}
-- RevPassphraseValue ::= EncryptedValue
-- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13}
-- ImplicitConfirmValue ::= NULL
-- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14}
-- ConfirmWaitTimeValue ::= GeneralizedTime
-- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15}
-- OrigPkiMessageValue ::= PKIMessages
-- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16}
-- SuppLangTagsValue ::= SEQUENCE OF UTF8String
--
-- where
--
-- id-pkix OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
-- dod(6) internet(1) security(5) mechanisms(5) pkix(7)}
-- and
-- id-it OBJECT IDENTIFIER ::= {id-pkix 4}
--
--
-- 这个构造也可用于定义新的PKIX证书管理协议的请求和相应消息或通用目的消息（例如公告）以满足未来或特定环境的要求。
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
-- EE，RA，或者CA都可以发送该消息（取决于消息的内容）。对于上面给出的某些例子，GenMsg 中InfoTypeAndValue的可选参数infoValue通常会被省略（即它只应用于相关的GenRep消息中）。接收方有权忽略它不能识别的对象标识符。如果消息由EE发往CA，若结构内容为空的表明CA可以发送其希望发送的任意或所有信息。
GenRepContent ::= SEQUENCE OF InfoTypeAndValue
-- 接收方可以忽略其不能识别的OID。
ErrorMsgContent ::= SEQUENCE {
pKIStatusInfo PKIStatusInfo,
errorCode INTEGER OPTIONAL,
--与实现相关的错误码
errorDetails PKIFreeText OPTIONAL
--与实现相关的错误描述
}
PollReqContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER
}
PollRepContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER,
checkAfter INTEGER, --以秒为单位的时间
reason PKIFreeText OPTIONAL
}
END -- of CMP module
附 录 G
（资料性附录）
用于E-MAIL或者HTTP的MIME类型
MIME类型
MIME 媒体类型名字：application
MIME 图标子类型名字：pkixcmp
编码注意事项：
内容里面会包含任意的八位字节值 (对PKI消息的 DER 编码，与在IETF PKIX Working Group specifications中定义的一样)。采用MIME e-mail时 需要base64编码；对于采用HTTP时不需要编码。
安全注意事项：
本MIME类型用于在PKI实体中传输Public-Key Infrastructure(PKI) 消息。消息由IETF PKIX 工作组来定义同时，用于建立和维护互联网 PKI。如果PKI消息本身得到了与PKIX规范中所定义的保护，那么在这一级别不要求采用特定的安全机制。
使用本媒体类型的应用软件：
应用使用证书管理，操作或者辅助的协议（IETF PKIX工作组定义的）通过E-Mail或者HTTP来发送PKI消息的应用软件。
PKI管理实体
CA
j
g
g
b
a
b
a
b
a
d
c
i
f
e
h
g
带外方式装载
初始化注册/验证
密钥对恢复
密钥对更新
证书更新
作废请求
交叉认证
交叉证书更新
带外发布
证书发布
CRL发布
证书发布
证书发布
CA-2
RA
终端实体
证书/ CRL
库
PKI“用户”
结束
发送pReq
增加到未决链表
接受
增加到确认链表
检查CertResponse获得每一个证书
检查返回证书的状态
发送ir
ip
等待
确认链表
确认链表为空
未决链表为空
发送certConf
ip
等待
pRep
国家质量技术监督局 发布
××××-××-××实施
××××-××-××发布
信息技术 安全技术 公钥基础设施
证书管理协议
Information Technology-Security Technology - Internet Public Key Infrastructure-
Certificate Management Protocol
GB/T —200×
中华人民共和国国家标准
ICS
Lxx
IV
V
