CMP（Certificate Management Protocol）是由IETF开发的协议，用于证书管理，包括证书申请、更新、撤销等。CMP协议的标准由IETF的RFC 4210定义。CMP协议消息的格式基于ASN.1（Abstract Syntax Notation One）描述，并使用DER（Distinguished Encoding Rules）进行编码。
RFC4210定义的是CMP V2，最新的CMP V3(RFC9480)也已经发布了。
以下是关于CMP协议格式的详细说明：
1. CMP协议消息的基本结构
CMP协议消息的基本结构由以下几个部分组成：
1.1. PKIMessage
PKIMessage是CMP协议的基本消息类型，包含了所有CMP消息的通用结构。其ASN.1描述如下：
“`asn.1
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL
}
<pre><code class="line-numbers">- **header**：PKIHeader，包含消息的元数据，如消息类型、发送者和接收者信息等。
– **body**：PKIBody，包含实际的消息内容，如证书请求、证书响应等。
– **protection**：PKIProtection，可选字段，用于保护消息的完整性和真实性。
– **extraCerts**：SEQUENCE OF CMPCertificate，可选字段，包含额外的证书。
### 1.2. PKIHeader
PKIHeader包含消息的元数据，其ASN.1描述如下：
“`asn.1
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,
freeText [7] PKIFreeText OPTIONAL,
generalInfo [8] SEQUENCE SIZE (1..MAX) OF InfoTypeAndValue OPTIONAL
}
- pvno：协议版本号。
- sender：发送者的标识。
- recipient：接收者的标识。
- messageTime：消息的时间戳（可选）。
- protectionAlg：用于保护消息的算法标识符（可选）。
- senderKID：发送者的密钥标识符（可选）。
- recipKID：接收者的密钥标识符（可选）。
- transactionID：事务ID（可选）。
- senderNonce：发送者的随机数（可选）。
- recipNonce：接收者的随机数（可选）。
- freeText：自由文本（可选）。
- generalInfo：一般信息（可选）。
1.3. PKIBody
PKIBody包含实际的消息内容，其ASN.1描述如下：
“`asn.1
PKIBody ::= CHOICE {
ir [0] CertReqMessages, — Initialization Request
ip [1] CertRepMessage, — Initialization Response
cr [2] CertReqMessages, — Certification Request
cp [3] CertRepMessage, — Certification Response
p10cr [4] CertificationRequest, — PKCS #10 Certificate Request
popdecc [5] POPODecKeyChallContent, — Proof-of-Possession Challenge
popdecr [6] POPODecKeyRespContent, — Proof-of-Possession Response
kur [7] CertReqMessages, — Key Update Request
kup [8] CertRepMessage, — Key Update Response
krr [9] CertReqMessages, — Key Recovery Request
krp [10] KeyRecRepContent, — Key Recovery Response
rr [11] RevReqContent, — Revocation Request
rp [12] RevRepContent, — Revocation Response
ccr [13] CertReqMessages, — Cross-Certification Request
ccp [14] CertRepMessage, — Cross-Certification Response
ckuann [15] CAKeyUpdAnnContent, — CA Key Update Announcement
cann [16] CertAnnContent, — Certificate Announcement
rann [17] RevAnnContent, — Revocation Announcement
crlann [18] CRLAnnContent, — CRL Announcement
pkiconf [19] PKIConfirmContent, — Confirmation
nested [20] NestedMessageContent, — Nested Message
genm [21] GenMsgContent, — General Message
genp [22] GenRepContent, — General Response
error [23] ErrorMsgContent, — Error Message
certConf [24] CertConfirmContent, — Certificate Confirmation
pollReq [25] PollReqContent, — Polling Request
pollRep [26] PollRepContent — Polling Response
}
<pre><code class="line-numbers">- **ir**：初始化请求（Initialization Request）。
– **ip**：初始化响应（Initialization Response）。
– **cr**：认证请求（Certification Request）。
– **cp**：认证响应（Certification Response）。
– **p10cr**：PKCS #10证书请求（PKCS #10 Certificate Request）。
– **popdecc**：证明密钥拥有权挑战（Proof-of-Possession Challenge）。
– **popdecr**：证明密钥拥有权响应（Proof-of-Possession Response）。
– **kur**：密钥更新请求（Key Update Request）。
– **kup**：密钥更新响应（Key Update Response）。
– **krr**：密钥恢复请求（Key Recovery Request）。
– **krp**：密钥恢复响应（Key Recovery Response）。
– **rr**：撤销请求（Revocation Request）。
– **rp**：撤销响应（Revocation Response）。
– **ccr**：交叉认证请求（Cross-Certification Request）。
– **ccp**：交叉认证响应（Cross-Certification Response）。
– **ckuann**：CA密钥更新公告（CA Key Update Announcement）。
– **cann**：证书公告（Certificate Announcement）。
– **rann**：撤销公告（Revocation Announcement）。
– **crlann**：CRL公告（CRL Announcement）。
– **pkiconf**：确认（Confirmation）。
– **nested**：嵌套消息（Nested Message）。
– **genm**：一般消息（General Message）。
– **genp**：一般响应（General Response）。
– **error**：错误消息（Error Message）。
– **certConf**：证书确认（Certificate Confirmation）。
– **pollReq**：轮询请求（Polling Request）。
– **pollRep**：轮询响应（Polling Response）。
## 2. CMP协议消息的保护
CMP协议消息可以通过PKIProtection字段进行保护，确保消息的完整性和真实性。PKIProtection字段的ASN.1描述如下：
“`asn.1
PKIProtection ::= BIT STRING
- PKIProtection：包含消息的保护信息，通常是消息的签名或MAC（消息认证码）。
3. CMP协议消息的编码
CMP协议消息使用ASN.1描述，并通过DER（Distinguished Encoding Rules）进行编码。DER是一种二进制编码规则，确保消息的唯一编码。
4. 示例：CMP协议消息
以下是一个简单的CMP协议消息示例，展示了初始化请求（Initialization Request）的结构：
“`asn.1
PKIMessage ::= SEQUENCE {
header PKIHeader {
pvno cmp2000,
sender GeneralName { directoryName { rdnSequence { commonName "Client" } } },
recipient GeneralName { directoryName { rdnSequence { commonName "CA" } } },
messageTime GeneralizedTime "20230101000000Z",
senderNonce OCTET STRING "1234567890abcdef",
transactionID OCTET STRING "abcdef1234567890"
},
body PKIBody {
ir CertReqMessages {
CertReqMsg {
certReq CertRequest {
certReqId INTEGER 1,
certTemplate CertTemplate {
version Version v3,
subject Name { rdnSequence { commonName "Client" } },
publicKey SubjectPublicKeyInfo { algorithm { algorithm rsaEncryption }, subjectPublicKey BIT STRING "…" }
}
},
popo ProofOfPossession { raVerified },
regInfo SEQUENCE { }
}
}
},
protection PKIProtection "…"
}
<pre><code class="line-numbers">## PKI管理模型
### PKI实体
– 最终实体(End Entities,EE)
最终实体就是subject字段所代表的主体。后面最终实体都用EE表示。
– 证书颁发机构(Certification Authority,CA)
CA是issuer字段所代表的主体，CA可以是第三方主体，也可以是与EE相同的主体，可以是离线的也可以是在线的。root CA是EE需要直接信任的CA。
– 注册机构(Registration Authority，RA)
许多环境需要独立于CA的注册机构。
注册机构可能执行的功能因情况而异，但可能包括个人身份验证、令牌分发、撤销报告、名称分配、密钥生成、密钥对存档等。
RA是可选的，当没有RA时CA完成RA的所有功能。
RA本身也是一个EE，RA其实就是具有可以签名私钥(签名CSR)的经过认证的EE，CA把哪体EE识别为RA取决于具体实现。一个RA可以属于多个CA。
### PKI管理操作
管理操作的流程图
“`ascii
+—+ cert. publish +————+ j
| | <——————— | End Entity | <——-
| C | g +————+ “out-of-band”
| e | | ^ loading
| r | | | initial
| t | a | | b registration/
| | | | certification
| / | | | key pair recovery
| | | | key pair update
| C | | | certificate update
| R | PKI “USERS” V | revocation request
| L | ——————-+-+—–+-+——+-+——————-
| | PKI MANAGEMENT | ^ | ^
| | ENTITIES a | | b a | | b
| R | V | | |
| e | g +——+ d | |
| p | <———— | RA | <—–+ | |
| o | cert. | | —-+ | | |
| s | publish +——+ c | | | |
| i | | | | |
| t | V | V |
| o | g +————+ i
| r | <————————| CA |——->
| y | h +————+ “out-of-band”
| | cert. publish | ^ publication
| | CRL publish | |
+—+ | | cross-certification
e | | f cross-certificate
| | update
| |
V |
+——+
| CA-2 |
+——+
PKI管理操作包括：
- CA建立
生成自签名证书或者中间CA证书，生成初始CRL，生成证书序列号文件，生成证书数据库
-
EE初始化
导入CA证书，获取CA的其它信息
-
Certification(创建新证书的各种操作)
3.1. initial registration/certification
生成密钥对，注册或生成自己的证书请求
3.2. key pair update
更新密钥对并颁发新的证书
3.3. certificate update
证书过期时如果环境没有任何其它的变化则会refreshed证书
3.4. CA key pair update
与EE一样，CA密钥对也需要进行更新，但是会使用不同的机制
3.5. cross-certification request
一个CA向另一个CA请求交叉证书
3.6. cross-certificate update
同普通证书update
-
Certificate/CRL discovery operations
后面具体讲
-
Recovery operations
主要是key pair recovery，如果EE丢失了自己的私钥并且CA备份了EE的私钥的情况下可以请求CA恢复私钥
-
Revocation operations
证书吊销
-
PSE operations
PSE是啥RFC4210中也没说，我想指的应该是发布证书的时候确保提供一个安全渠道。
Assumptions and Restrictions
rfc4210中是叫这个标题，我也不知道啥意思
- Initiation of Registration/Certification
第一条PKI消息的产生意味着触发Initiation of Registration/Certification，这可以发生在任何地方，包括EE，RA，CA。
-
End Entity Message Origin Authentication
EE与RA或CA通信时需要经过身份认证，也可以不认证。本规范中是通过secret value(用于生成保护字段的MAC，同时用于初始化请求的身份验证，华为的文档中叫秘密值)和reference value(就是senderKID的referenceNum，华为的文档中叫参考值)来认证的，secret value和reference value由CA生成并通过带外途径发送给EE。
-
Location of Key Generation
密钥生成的位置等同于PKI消息中首次出现密钥的地方，这可以是EE,RA,CA。
-
Confirmation of Successful Certification
CA生成证书后，可以让EE明确接收或不接受证书。
Mandatory Schemes
-
Centralized Scheme
即中心化方案
- Initiation of Registration/Certification由CA完成
- 不需要End Entity Message Origin Authentication
- Location of Key Generation生成在CA
- 不需要Confirmation of Successful Certification
- Basic Authenticated Scheme
- Initiation of Registration/Certification由EE完成
- 需要End Entity Message Origin Authentication
- Location of Key Generation生成在EE
- 需要Confirmation of Successful Certification
Proof-of-Possession (POP) of Private Key
EE持有的私钥，需要向CA/RA证明自己是对应公钥的私钥持有者，这包括用自己的私钥对证书请求进行签名，向CA/RA发送私钥，使用私钥加密一个值。对于Key Agreement Keys，例如DH密钥，可以通过生成一个共享密钥来证明。
POP证明有很多种，包括包含私钥，直接法(质询响应)，间接法(公钥加密证书)，后面还有更多说明。
Root CA Key Update
更新root CA的密钥是一个比较麻烦的事，因为需要所有EE，RA都要同步处理。
需要执行的操作包括：
- Generate a new key pair;
-
Create a certificate containing the old CA public key signed with
the new private key (the “old with new” certificate); -
Create a certificate containing the new CA public key signed with
the old private key (the “new with old” certificate); -
Create a certificate containing the new CA public key signed with
the new private key (the “new with new” certificate); -
Publish these new certificates via the repository and/or other
means (perhaps using a CAKeyUpdAnn message); -
Export the new CA public key so that end entities may acquire it
using the “out-of-band” mechanism (if required).
The old CA private key is then no longer required. However, the old
CA public key will remain in use for some time. The old CA public
key is no longer required (other than for non-repudiation) when all
end entities of this CA have securely acquired the new CA public key.
The “old with new” certificate must have a validity period starting
at the generation time of the old key pair and ending at the expiry
date of the old public key.
The “new with old” certificate must have a validity period starting
at the generation time of the new key pair and ending at the time by
which all end entities of this CA will securely possess the new CA
public key (at the latest, the expiry date of the old public key).
The “new with new” certificate must have a validity period starting
at the generation time of the new key pair and ending at or before
the time by which the CA will next update its key pair.
数据结构
总体PKI消息
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
protection 就是消息的签名或者完整性验证
extraCerts 如果颁发证书的CA不是rootCA,则需要一个证书链来验证证书的有效性，所以这就是新证书的证书链(如果有的话)。在证书请求中还可以用于包含当前用于签名验证的证书。Root CA Key Update消息中则用于发布证书。所以这个字段在不同场景下用途也不一样。
PKI消息头
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,
freeText [7] PKIFreeText OPTIONAL,
generalInfo [8] SEQUENCE SIZE (1..MAX) OF
InfoTypeAndValue OPTIONAL
}
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
pvno 就是cmp协议的版本号，对于rfc4210来说始终是2
sender 发送者的DN名称
recipient 接收者的DN名称
messageTime 消息发送时间
protectionAlg protection字段的算法标识符
senderKID，recipKID DH算法的密钥标识符，有多对密钥时才需要，在初始化请求中senderKID就是用于身份认证的referenceNum(参考值)
transactionID 事务ID，也就是会话ID，一般由发起会话者生成，后面保持不变
senderNonce，recipNonce 每个报文生成一个随机数(为什么不用递增序列?)，用于防重放攻击
freeText 包含人类可读信息(可以由多个)，回复消息时使用与第一个Text相同的语言。
generalInfo 向对方发送附加的机器可处理信息，这是一个generalInfo类型的数组，一共定义了以下generalInfo扩展:
- ImplicitConfirm
implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} ImplicitConfirmValue ::= NULL如果存在这个generalInfo扩展则不发送证书确认
-
ConfirmWaitTime
confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} ConfirmWaitTimeValue ::= GeneralizedTime证书确认的超时时间，如果超时则撤销证书并删除会话。
PKI消息体
PKIBody ::= CHOICE {
ir [0] CertReqMessages, --Initialization Req
ip [1] CertRepMessage, --Initialization Resp
cr [2] CertReqMessages, --Certification Req
cp [3] CertRepMessage, --Certification Resp
p10cr [4] CertificationRequest, --PKCS #10 Cert. Req.
popdecc [5] POPODecKeyChallContent --pop Challenge
popdecr [6] POPODecKeyRespContent, --pop Response
kur [7] CertReqMessages, --Key Update Request
kup [8] CertRepMessage, --Key Update Response
krr [9] CertReqMessages, --Key Recovery Req
krp [10] KeyRecRepContent, --Key Recovery Resp
rr [11] RevReqContent, --Revocation Request
rp [12] RevRepContent, --Revocation Response
ccr [13] CertReqMessages, --Cross-Cert. Request
ccp [14] CertRepMessage, --Cross-Cert. Resp
ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann.
cann [16] CertAnnContent, --Certificate Ann.
rann [17] RevAnnContent, --Revocation Ann.
crlann [18] CRLAnnContent, --CRL Announcement
pkiconf [19] PKIConfirmContent, --Confirmation
nested [20] NestedMessageContent, --Nested Message
genm [21] GenMsgContent, --General Message
genp [22] GenRepContent, --General Response
error [23] ErrorMsgContent, --Error Message
certConf [24] CertConfirmContent, --Certificate confirm
pollReq [25] PollReqContent, --Polling request
pollRep [26] PollRepContent --Polling response
}
一共27种报文，还是比较多的。
具体描述在下在面。
Common Data Structures
在说明具本的PKIBody前要先说一下通用的数据结构
- 发送证书
当需要包含证书内容时使用CertTemplate语法，CA/RA可能修改证书请求的内容，EE也可以选择拒绝CA签置的证书(如果内容被修改)。
- Encrypted Values
通常是私钥和证书(接收新证书)，需要使用EncryptedValue数据结构，要求双方事先有能解密秘密数据的密钥。
- 状态码和故障信息
状态码
PKIStatus ::= INTEGER {
accepted (0),
grantedWithMods (1),
rejection (2),
waiting (3),
revocationWarning (4),
revocationNotification (5),
keyUpdateWarning (6)
}
故障
PKIFailureInfo ::= BIT STRING {
badAlg (0),
badMessageCheck (1),
badRequest (2),
badTime (3),
badCertId (4),
badDataFormat (5),
wrongAuthority (6),
incorrectData (7),
missingTimeStamp (8),
badPOP (9),
certRevoked (10),
certConfirmed (11),
wrongIntegrity (12),
badRecipientNonce (13),
timeNotAvailable (14),
unacceptedPolicy (15),
unacceptedExtension (16),
addInfoNotAvailable (17),
badSenderNonce (18),
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数据结构
- root CA
OOBCert ::= Certificate
# or
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
}
对于Certificat要求:
- 证书是自签名的，即可以使用SubjectPublicKeyInfo中的公钥验证签名
- subject和issuer相同
- 如果subject为空则要求SubjectAltName和issuerAltNames相同
- key identifiers for subject and issuer相同
OOBCertHash用途是通过带外方式获取root CA时对root CA进行验证。
- Archive Options
请求者希望PKI使用PKIArchiveOptions结构存档私钥
- Publication Information
请求者希望PKI通过PKIPublicationInfo结构发布证书
- Proof-of-Possession Structures
如果请求的是一个签名证书，私钥的所有权证明是通过POPOSigningKey结构完成的。
参考附录 C and [CRMF] for POPOSigningKey 语法,
POPOSigningKey ::= SEQUENCE { poposkInput [0] POPOSigningKeyInput OPTIONAL, algorithmIdentifier AlgorithmIdentifier, signature BIT STRING #这个签名是用私钥对poposkInput的DER编码的签名，如果EE能用公钥验证这个签名就完成了私钥所有权证明 } POPOSigningKeyInput ::= SEQUENCE { authInfo CHOICE { sender [0] GeneralName, publicKeyMAC PKMACValue }, publicKey SubjectPublicKeyInfo }另一方面, 如果请求的是一个加密证书, 那么私钥的所有权证明可以用下面三种方法中的一个(包含私钥，直接法，间接法)
-
Inclusion of the Private Key
在CertRequest请求的POPOPrivKey的thisMessage，或者通过PKIArchiveOptions字段包含私钥，这取决于是否需要私钥存档
POPOPrivKey ::= CHOICE { thisMessage [0] BIT STRING, -- ********** -- * the type of "thisMessage" is given as BIT STRING in -- * [CRMF]; it should be "EncryptedValue" (in accordance -- * with Section 5.2.2, "Encrypted Values", of this specification). -- * Therefore, this document makes the behavioral clarification -- * of specifying that the contents of "thisMessage" MUST be encoded -- * as an EncryptedValue and then wrapped in a BIT STRING. This -- * allows the necessary conveyance and protection of the -- * private key while maintaining bits-on-the-wire compatibility -- * with [CRMF]. -- ********** subsequentMessage [1] SubsequentMessage, dhMAC [2] BIT STRING } - Indirect Method
返回公钥加密的证书，只有用EE的私钥才能解密。
-
Challenge-Response Protocol(direct method)
通过Challenge-Response Protocol证明EE私钥的POP
-
PoP选项总结
下面列出了代表各种POP技术的选项. Using “SK” for “signing key”, “EK” for “encryption key”,and “KAK” for “key agreement key”, 总结如下：
RAVerified; SKPOP; EKPOPThisMessage; KAKPOPThisMessage; KAKPOPThisMessageDHMAC; EKPOPEncryptedCert; KAKPOPEncryptedCert; EKPOPChallengeResp; and KAKPOPChallengeResp.考虑到这一系列选项，自然会问EE如何知道CA/RA支持什么选项/技术（即，在请求证书时可以使用哪些选项）。以下指南应该为EE实现者澄清这种情况。
- RAVerified
这是RA向CA请求是用的，EE不需要考虑
-
SKPOP
如果EE有一个签名密钥对，则这是唯一可用选项
-
EKPOPThisMessage and KAKPOPThisMessage
如果决定向CA/RA公开私钥，则只有这里的方法可以做到，根据密钥类型选择EKPOPThisMessage 还是 KAKPOPThisMessage
-
KAKPOPThisMessageDHMAC
仅当CA有可用于此目的的DH证书，以及EE已经有此证书的副本时，EE才能使用此方法。如果这两个条件都成立，那么这种技术就得到了明确的支持。
-
EKPOPEncryptedCert, KAKPOPEncryptedCert, EKPOPChallengeResp, KAKPOPChallengeResp
EE在请求消息中选择其中一个（在subsequentMessage字段中），具体取决于偏好和密钥对类型。EE在此处没有做POP；它只是向CA/RA指示要使用哪种方法。因此，如果CA/RA回复“badPOP”错误，则EE可以使用在后续消息中选择的其他POP方法重新请求。但是，请注意，本规范鼓励使用EncryptedCert选项，并且还指出，当涉及RA并进行POP验证时，通常会使用质询响应。间接方法需要发送的消息更少，也比较简单是EE尽可能使用这种方法，如果是向RA提交POP证明则会使用直接方法(质询响应)
- RAVerified
特定操作的数据结构
一共定义了27个操作类型，怪不得CMP是最复杂的证书协议
- Initialization Request
一个Initialization请求包含CertReqMessages数据结构作为PKI Body,该数据结构指定要请求的证书(CRMF格式(RFC4211)，类似于PKCS#10),通常会包含SubjectPublicKeyInfo、KeyId和Validity字段。此消息用于首次初始化PKI实体时。
因为是首次请求证书需要带外方式获取身份验证信息，使用MSG_MAC_ALG进行身份验证，MAC信息是用共享的Secret加了盐的。senderKID就是参考值。
一个请求可以包含多个证书，证书模板(要请求的证书)放在CertTemplate字段中。CertReqMessages在Rfc4211中定义，很复杂，以下是ASN.1代码：
-- Core definitions for this module CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg CertReqMsg ::= SEQUENCE { certReq CertRequest, popo ProofOfPossession OPTIONAL, -- content depends upon key type regInfo SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL } CertRequest ::= SEQUENCE { certReqId INTEGER, -- ID for matching request and reply certTemplate CertTemplate, -- Selected fields of cert to be issued controls Controls OPTIONAL } -- Attributes affecting issuance CertTemplate ::= SEQUENCE { version [0] Version OPTIONAL, serialNumber [1] INTEGER OPTIONAL, signingAlg [2] AlgorithmIdentifier OPTIONAL, issuer [3] Name OPTIONAL, validity [4] OptionalValidity OPTIONAL, subject [5] Name OPTIONAL, publicKey [6] SubjectPublicKeyInfo OPTIONAL, issuerUID [7] UniqueIdentifier OPTIONAL, subjectUID [8] UniqueIdentifier OPTIONAL, extensions [9] Extensions OPTIONAL } OptionalValidity ::= SEQUENCE { notBefore [0] Time OPTIONAL, notAfter [1] Time OPTIONAL } -- at least one MUST be present Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue AttributeTypeAndValue ::= SEQUENCE { type OBJECT IDENTIFIER, value ANY DEFINED BY type } ProofOfPossession ::= CHOICE { raVerified [0] NULL, -- used if the RA has already verified that the requester is in -- possession of the private key signature [1] POPOSigningKey, keyEncipherment [2] POPOPrivKey, keyAgreement [3] POPOPrivKey } POPOSigningKey ::= SEQUENCE { poposkInput [0] POPOSigningKeyInput OPTIONAL, algorithmIdentifier AlgorithmIdentifier, signature BIT STRING } -- The signature (using "algorithmIdentifier") is on the -- DER-encoded value of poposkInput. NOTE: If the CertReqMsg -- certReq CertTemplate contains the subject and publicKey values, -- then poposkInput MUST be omitted and the signature MUST be -- computed over the DER-encoded value of CertReqMsg certReq. If -- the CertReqMsg certReq CertTemplate does not contain both the -- public key and subject values (i.e., if it contains only one -- of these, or neither), then poposkInput MUST be present and -- MUST be signed. POPOSigningKeyInput ::= SEQUENCE { authInfo CHOICE { sender [0] GeneralName, -- used only if an authenticated identity has been -- established for the sender (e.g., a DN from a -- previously-issued and currently-valid certificate) publicKeyMAC PKMACValue }, -- used if no authenticated GeneralName currently exists for -- the sender; publicKeyMAC contains a password-based MAC -- on the DER-encoded value of publicKey publicKey SubjectPublicKeyInfo } -- from CertTemplate PKMACValue ::= SEQUENCE { algId AlgorithmIdentifier, -- algorithm value shall be PasswordBasedMac {1 2 840 113533 7 66 13} -- parameter value is PBMParameter value BIT STRING } PBMParameter ::= SEQUENCE { salt OCTET STRING, owf AlgorithmIdentifier, -- AlgId for a One-Way Function (SHA-1 recommended) iterationCount INTEGER, -- number of times the OWF is applied mac AlgorithmIdentifier -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], } -- or HMAC [HMAC, RFC2202]) POPOPrivKey ::= CHOICE { thisMessage [0] BIT STRING, -- Deprecated -- possession is proven in this message (which contains the private -- key itself (encrypted for the CA)) subsequentMessage [1] SubsequentMessage, -- possession will be proven in a subsequent message dhMAC [2] BIT STRING, -- Deprecated agreeMAC [3] PKMACValue, encryptedKey [4] EnvelopedData } -- for keyAgreement (only), possession is proven in this message -- (which contains a MAC (over the DER-encoded value of the -- certReq parameter in CertReqMsg, which MUST include both subject -- and publicKey) based on a key derived from the end entity's -- private DH key and the CA's public DH key); SubsequentMessage ::= INTEGER { encrCert (0), -- requests that resulting certificate be encrypted for the -- end entity (following which, POP will be proven in a -- confirmation message) challengeResp (1) } -- requests that CA engage in challenge-response exchange with -- end entity in order to prove private key possession -- Object identifier assignments -- -- Registration Controls in CRMF id-regCtrl OBJECT IDENTIFIER ::= { id-pkip 1 } id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 } --with syntax: RegToken ::= UTF8String id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 } --with syntax: Authenticator ::= UTF8String id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 } --with syntax: PKIPublicationInfo ::= SEQUENCE { action INTEGER { dontPublish (0), pleasePublish (1) }, pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL } -- pubInfos MUST NOT be present if action is "dontPublish" -- (if action is "pleasePublish" and pubInfos is omitted, -- "dontCare" is assumed) SinglePubInfo ::= SEQUENCE { pubMethod INTEGER { dontCare (0), x500 (1), web (2), ldap (3) }, pubLocation GeneralName OPTIONAL } id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 } --with syntax: PKIArchiveOptions ::= CHOICE { encryptedPrivKey [0] EncryptedKey, -- the actual value of the private key keyGenParameters [1] KeyGenParameters, -- parameters that allow the private key to be re-generated archiveRemGenPrivKey [2] BOOLEAN } -- set to TRUE if sender wishes receiver to archive the private -- key of a key pair that the receiver generates in response to -- this request; set to FALSE if no archival is desired. EncryptedKey ::= CHOICE { encryptedValue EncryptedValue, -- Deprecated envelopedData [0] EnvelopedData } -- The encrypted private key MUST be placed in the envelopedData -- encryptedContentInfo encryptedContent OCTET STRING. EncryptedValue ::= SEQUENCE { intendedAlg [0] AlgorithmIdentifier OPTIONAL, -- the intended algorithm for which the value will be used symmAlg [1] AlgorithmIdentifier OPTIONAL, -- the symmetric algorithm used to encrypt the value encSymmKey [2] BIT STRING OPTIONAL, -- the (encrypted) symmetric key used to encrypt the value keyAlg [3] AlgorithmIdentifier OPTIONAL, -- algorithm used to encrypt the symmetric key valueHint [4] OCTET STRING OPTIONAL, -- a brief description or identifier of the encValue content -- (may be meaningful only to the sending entity, and used only -- if EncryptedValue might be re-examined by the sending entity -- in the future) encValue BIT STRING } -- the encrypted value itself -- When EncryptedValue is used to carry a private key (as opposed to -- a certificate), implementations MUST support the encValue field -- containing an encrypted PrivateKeyInfo as defined in [PKCS11], -- section 12.11. If encValue contains some other format/encoding -- for the private key, the first octet of valueHint MAY be used -- to indicate the format/encoding (but note that the possible values -- of this octet are not specified at this time). In all cases, the -- intendedAlg field MUST be used to indicate at least the OID of -- the intended algorithm of the private key, unless this information -- is known a priori to both sender and receiver by some other means. KeyGenParameters ::= OCTET STRING id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 } --with syntax: OldCertId ::= CertId CertId ::= SEQUENCE { issuer GeneralName, serialNumber INTEGER } id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 } --with syntax: ProtocolEncrKey ::= SubjectPublicKeyInfo -- Registration Info in CRMF id-regInfo OBJECT IDENTIFIER ::= { id-pkip 2 } id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= { id-regInfo 1 } --with syntax UTF8Pairs ::= UTF8String id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 } --with syntax CertReq ::= CertRequest -- id-ct-encKeyWithID is a new content type used for CMS objects. -- it contains both a private key and an identifier for key escrow -- agents to check against recovery requestors. id-ct-encKeyWithID OBJECT IDENTIFIER ::= {id-ct 21} EncKeyWithID ::= SEQUENCE { privateKey PrivateKeyInfo, identifier CHOICE { string UTF8String, generalName GeneralName } OPTIONAL } PrivateKeyInfo ::= SEQUENCE { version INTEGER, privateKeyAlgorithm AlgorithmIdentifier, privateKey OCTET STRING, attributes [0] IMPLICIT Attributes OPTIONAL } Attributes ::= SET OF Attribute - Initialization Response
初始化请求的响应，返回请求的证书
CertRepMessage数据结构作为PKIBody，该数据结构为每个请求的证书提供一个PKIStatusInfo字段、一个主题证书，可能还有一个私钥（通常使用会话密钥加密，会话密钥本身使用ProtocolEncrey加密。
CertRepMessage的asn.1代码CertRepMessage ::= SEQUENCE { caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL, response SEQUENCE OF CertResponse } CertResponse ::= SEQUENCE { certReqId INTEGER, -- to match this response with corresponding request (a value -- of -1 is to be used if certReqId is not specified in the -- corresponding request) status PKIStatusInfo, certifiedKeyPair CertifiedKeyPair OPTIONAL, rspInfo OCTET STRING OPTIONAL -- analogous to the id-regInfo-utf8Pairs string defined -- for regInfo in CertReqMsg [CRMF] } CertifiedKeyPair ::= SEQUENCE { certOrEncCert CertOrEncCert, privateKey [0] EncryptedValue OPTIONAL, -- see [CRMF] for comment on encoding 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, -- allows requester to specify as much as they can about -- the cert. for which revocation is requested -- (e.g., for cases in which serialNumber is not available) crlEntryDetails Extensions OPTIONAL -- requested crlEntryExtensions } RevRepContent ::= SEQUENCE { status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, -- in same order as was sent in RevReqContent revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, -- IDs for which revocation was requested -- (same order as status) crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL -- the resulting CRLs (there may be more than one) } CAKeyUpdAnnContent ::= SEQUENCE { oldWithNew CMPCertificate, -- old pub signed with new priv newWithOld CMPCertificate, -- new pub signed with old priv newWithNew CMPCertificate -- new pub signed with new priv } CertAnnContent ::= CMPCertificate RevAnnContent ::= SEQUENCE { status PKIStatus, certId CertId, willBeRevokedAt GeneralizedTime, badSinceDate GeneralizedTime, crlDetails Extensions OPTIONAL -- extra CRL details (e.g., crl number, reason, location, etc.) } CRLAnnContent ::= SEQUENCE OF CertificateList CertConfirmContent ::= SEQUENCE OF CertStatus CertStatus ::= SEQUENCE { certHash OCTET STRING, -- the hash of the certificate, using the same hash algorithm -- as is used to create and verify the certificate signature certReqId INTEGER, -- to match this confirmation with the corresponding req/rep statusInfo PKIStatusInfo OPTIONAL } CMPCertificate ::= CHOICE { x509v3PKCert Certificate } - Certification Request(证书请求)
现有PKI EE获得其它证书(用已有证书提供身份验证)，报文格式同Initialization Request。
PKI主体可以是CertificationRequest（此结构由[PKCS10]中给出的ASN.1结构CertificationRequest完全指定，用于支持PKCS #10证书请求）。当需要与遗留系统进行互操作时，签名密钥对的证书请求可能需要此结构，但如果不是绝对必要，强烈建议不要使用此结构(为什么不建议呢？)。 -
Certification Response
报文格式同Initialization Response
-
Key Update Request Content
仍然使用CertReqMessages PKI Body,但是要包括SubjectPublicKeyInfo、KeyId和Validity字段，此消息用于请求对现有（未吊销和未过期）证书的更新（因此，有时称为“Certificate Update”操作）。更新是包含新subject公钥或当前subject公钥的替换证书（尽管后一种做法可能不适用于某些环境）。
-
Key Update Response Content
报文格式同Initialization Response
-
Key Recovery Request Content
报文格式同Initialization Request，但SubjectPublicKeyInfo和KeyId是必选字段可用于提供需要证书的签名公钥
-
Key Recovery Response Content
使用以下结构作为Key Recovery Request Content的响应
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 } - Revocation Request Content
请求吊销证书
PKI Body结构:RevReqContent ::= SEQUENCE OF RevDetails RevReqContent ::= SEQUENCE OF RevDetails RevDetails ::= SEQUENCE { certDetails CertTemplate, crlEntryDetails Extensions OPTIONAL } - Revocation Response Content
撤销响应是对上述消息的响应。如果生成，则发送给撤销请求者。（可向请求撤销的证书主体发送单独的撤销公告消息。）
RevRepContent ::= SEQUENCE { status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL } - Cross Certification Request Content
请求交叉认证证书
交叉认证请求使用与普通认证请求相同的语法（CertReqMessages），但有一个限制，即密钥对必须由请求CA生成，并且私钥不得发送到响应CA。下级CA也可以使用此请求来获取由父CA签名的证书。 -
Cross Certification Response Content
交叉认证响应使用与正常认证响应相同的语法（CertRepMessage），但限制不能发送加密的私钥。
-
CA Key Update Announcement Content
当CA更新其自己的密钥对时，可以使用以下数据结构来宣布此事件。
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew Certificate,
newWithOld Certificate,
newWithNew Certificate
}
-
Certificate Announcement
此结构可用于宣布证书的存在。 请注意，此消息旨在用于没有其它证书发布方法的情况；例如，如果X.500(LDAP)是发布证书的方法，则不打算使用该方法。
CertAnnContent ::= Certificate - Revocation Announcement
当CA已撤销或即将撤销特定证书时，它可能会发布此事件的公告。
RevAnnContent ::= SEQUENCE { status PKIStatus, certId CertId, willBeRevokedAt GeneralizedTime, badSinceDate GeneralizedTime, crlDetails Extensions OPTIONAL }CA可以使用此类公告警告（或通知）主体其证书即将（或已）被吊销。这通常用于撤销请求并非来自相关主体的情况。
willBeRevokedAt字段包含将新条目添加到相关CRL的时间。- CRL Announcement
当CA发布新的CRL（或一组CRL）时，可以使用以下数据结构来宣布此事件。
CRLAnnContent ::= SEQUENCE OF CertificateList - CRL Announcement
- PKI Confirmation Content
此数据结构在协议交换中用作最终PKI消息。它的内容在所有情况下都是相同的——实际上没有内容，因为PKI头包含所有必需的信息。
PKIConfirmContent ::= NULL不建议将此消息用于证书确认；应改用certConf。在收到证书响应的PKIConfirm后，接收方可以将其视Certificate Confirmation Content，并接受所有证书。
-
Certificate Confirmation Content
客户端使用此数据结构向CA/RA发送确认以接受或拒绝证书。
CertConfirmContent ::= SEQUENCE OF CertStatus CertStatus ::= SEQUENCE { certHash OCTET STRING, certReqId INTEGER, statusInfo PKIStatusInfo OPTIONAL }对于任何特定的CertStatus，省略statusInfo字段表示接受指定的证书。或者，可以在statusInfo字段中提供明确的状态详细信息（关于接受或拒绝），可能用于CA/RA的审计目的。
在CertConfirmContent中，省略与前一响应消息中提供的证书对应的CertStatus结构表示拒绝证书。因此，空CertConfirmContent（零长度序列）可用于指示拒绝所有提供的证书。有关占有证明的certHash字段的讨论，请参见第5.2.8节第（2）项。 -
PKI General Message Content
InfoTypeAndValue ::= SEQUENCE { infoType OBJECT IDENTIFIER, infoValue ANY DEFINED BY infoType OPTIONAL } -- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4} GenMsgContent ::= SEQUENCE OF InfoTypeAndValue没有归类的估计都放这了吧，这部分又包含了13种报文结构
- CA Protocol Encryption Certificate
用于EE向CA获取证书用于保护CMP会话
GenMsg: {id-it 1}, < absent > GenRep: {id-it 1}, Certificate | < absent >这里面的absent应该表示的是只有表示infoType的oid，没有infoValue(猜测)’
-
Signing Key Pair Types
获取CA支持的签名算法
GenMsg: {id-it 2}, < absent > GenRep: {id-it 2}, SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier - Encryption/Key Agreement Key Pair Types
获取CA的加密或KAK算法列表
GenMsg: {id-it 3}, < absent > GenRep: {id-it 3}, SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier - Preferred Symmetric Algorithm
获取CA的首选对称加密算法
GenMsg: {id-it 4}, < absent > GenRep: {id-it 4}, AlgorithmIdentifier - Updated CA Key Pair
CA可用此消息宣布CA密钥对更新GenMsg: {id-it 5}, CAKeyUpdAnnContent - CRL
EE用此报文获取最新的CRLGenMsg: {id-it 6}, < absent > GenRep: {id-it 6}, CertificateList - Unsupported Object Identifiers
服务器使用它从客户端提交的列表中返回它不识别或不支持的对象标识符列表。
GenRep: {id-it 7}, SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER -
Key Pair Parameters
这可由EE用于请求域参数以用于生成特定公钥算法的密钥对。例如，它可以用于请求适当的P、Q和G以生成DH/DSA密钥，或者请求一组众所周知的椭圆曲线。
GenMsg: {id-it 10}, OBJECT IDENTIFIER -- (Algorithm object-id) GenRep: {id-it 11}, AlgorithmIdentifier | < absent >GenRep中缺少infoValue表示不支持GenMsg中指定的算法。
EEs必须确保参数是可接受的，并且GenRep消息经过身份验证（以避免替代攻击）。
跟openssl genpkey的-genparam选项是不是有点类似 -
Revocation Passphrase
这可由EE用于向CA/RA发送密码短语，以便认证稍后的撤销请求（在适当的签名私钥不再可用于认证请求的情况下）。有关此机制使用的更多详细信息，请参见附录B。
GenMsg: {id-it 12}, EncryptedValue GenRep: {id-it 12}, < absent > - ImplicitConfirm
不发送确认消息，这个前面通用部分已经说过
-
ConfirmWaitTime
确认超时时间，前面通用部分已经说过
-
Original PKIMessage
RA如果修改了EE的请求，再向CA发关请求时携带的原始PKIMessage(EE向RA发送消息)
-
Supported Language Tags
这可用于确定在后续消息中使用的适当语言标记。发送方发送其支持的语言列表（按顺序，从最优先到最不优先）；接收者返回它想要使用的那个。（注意：每个UTF8String必须包含一个语言标记。）如果不支持任何提供的标记，则必须返回错误。
GenMsg: {id-it 16}, SEQUENCE SIZE (1..MAX) OF UTF8String GenRep: {id-it 16}, SEQUENCE SIZE (1) OF UTF8String
- CA Protocol Encryption Certificate
- PKI General Response Content
对General Message的响应
InfoTypeAndValue ::= SEQUENCE { infoType OBJECT IDENTIFIER, infoValue ANY DEFINED BY infoType OPTIONAL } -- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4} GenMsgContent ::= SEQUENCE OF InfoTypeAndValue - Error Message Content
EE、CA或RA可以使用此数据结构来传递错误信息ErrorMsgContent ::= SEQUENCE { pKIStatusInfo PKIStatusInfo, errorCode INTEGER OPTIONAL, errorDetails PKIFreeText OPTIONAL }此消息可在PKI交易期间的任何时间生成。如果客户端发送此请求，服务器必须使用PKIConfirm响应进行响应，如果标头的任何部分无效，则必须使用另一个ErrorMsg进行响应。双方必须将此消息视为会话的结束（如果会话正在进行）。
如果需要对消息进行保护，则客户端必须使用与Initialization Request相同的技术（即签名或MAC）对其进行保护。CA必须始终使用签名密钥对其进行签名。 -
Polling Request and Response
这对消息用于处理客户端需要轮询服务器以确定未完成的ir、cr或kur会话的状态（即，当收到“waiting”PKIStatus时）的场景。PollReqContent ::= SEQUENCE OF SEQUENCE { certReqId INTEGER } PollRepContent ::= SEQUENCE OF SEQUENCE { certReqId INTEGER, checkAfter INTEGER, -- time in seconds reason PKIFreeText OPTIONAL }以下子句描述何时使用轮询消息以及如何使用它们。假定在事务期间可以发送多个certConf消息。对于包含已颁发证书的CertStatus的每个ip、cp或kup，将发送一个响应。
- 如果EE收到对ip、cp或kup消息的响应，将为所有已颁发的证书发送certConf，并在确认之后为所有待定证书发送pollReq。
- 如果CA收到pollReq，如果一个或多个挂起证书就绪，CA/RA将返回ip、cp或kup的响应；否则，它将返回一个pollRep。
- 如果EE收到一个pollRep，它将在发送另一个pollReq之前等待至少与checkAfter值相同的时间。
- 如果在pollReq响应期间接收到ip、cp或kup，会按initial response相同的方法处理
START | v Send ir | ip v Check status of returned <------------------------+ certs | | |+————————>|<——————+ |
| | | |
| (issued) v (waiting) | |
Add to <----------- Check CertResponse ------> Add to |
conf list for each certificate pending list |
/ |
/ |
(conf list) / (empty conf list) |
/ ip |
/ +—————-+
(empty pending list) / | pRep
END <---- Send certConf Send pReq------------>Wait
| ^ ^ |
| | | |
+—————–+ +—————+
(pending list)
在以下交互中，EE在一个请求中注册两个证书。
Step End Entity PKI -------------------------------------------------------------------- 1 Format ir 2 -> ir -> 3 Handle ir 4 Manual intervention is required for both certs. 5 <- ip <- 6 Process ip 7 Format pReq 8 -> pReq -> 9 Check status of cert requests 10 Certificates not ready 11 Format pRep 12 <- pRep <- 13 Wait 14 Format pReq 15 -> pReq -> 16 Check status of cert requests 17 One certificate is ready 18 Format ip 19 <- ip <- 20 Handle ip 21 Format certConf 22 -> certConf -> 23 Handle certConf 24 Format ack 25 <- pkiConf <- 26 Format pReq 27 -> pReq -> 28 Check status of certificate 29 Certificate is ready 30 Format ip 31 <- ip <- 31 Handle ip 32 Format certConf 33 -> certConf -> 34 Handle certConf 35 Format ack 36 <- pkiConf <-
强制性的PKI功能
这些功能是EE，RA，CA必须实现的
- Root CA初始化
Root CA证书必须是自签名证书，为了支持EE通过带外方式获取Root CA证书还需要生成证书指纺，用OOBCertHash结构表示
-
Root CA密钥更新
CA密钥（与所有其他密钥一样）具有有限的生存期，必须定期更新。CA可颁发证书NewWithNew、NewWithOld和OldWithNew（见第4.4.1节），以帮助持有当前自签名CA证书（OldWithOld）的现有终端实体安全地过渡到新自签名CA证书（NewWithNew），并帮助持有NewWithNew的新终端实体安全地获取OldWithOld，以验证现有数据。
-
下级CA(中间CA)的初始化
从PKI管理协议的角度来看，下级CA的初始化与终端实体的初始化相同。唯一的区别是下级CA还必须生成初始吊销列表.
-
CRL生成
新成立的CA在颁发任何证书之前必须生成每个 CRL 的“空”版本，这些版本将定期生成。
-
PKI信息请求
当PKI实体（CA、RA或EE）希望获取有关CA当前状态的信息时，它可以向该CA发送获取此类信息的请求。请求是通过一般消息中的PKI General Message Content消息实现的，响应是通过PKI General Response Content。
-
交叉认证
请求者CA是将成为交叉证书subject的CA；响应者CA将成为交叉证书的issuer。
-
EE初始化
包括获取PKI信息(Root CA证书和其它信息)，和Root CA的带外验证(指纹)
-
证书请求(为什么不是初始化请求)
已初始化的EE可随时（出于任何目的）请求额外的证书。此请求将使用证书请求（cr）消息发出。如果EE已经拥有签名密钥对（具有相应的验签证书），则该cr消息通常将受到EE数字签名的保护。CA在CertRepMessage中返回新证书（如果请求成功）。
-
密钥更新
当密钥对到期时，相关EE可请求密钥更新；也就是说，它可以请求CA为新密钥对颁发新证书（或者，在某些情况下，为同一密钥对颁发新证书）。使用密钥更新请求（kur）消息发出请求（在某些环境中称为“Certificate Update”操作）。如果EE已经拥有签名密钥对（具有相应的验证证书），则该消息通常将受到EE数字签名的保护。CA在密钥更新响应（kup）消息中返回新证书（如果请求成功），该消息在语法上与CertRepMessage相同。