附錄B（規范性附錄） 必選的PKI管理消息結構

本附錄包含了遵循本標準的實現必須支持的PKI消息的詳細描述（參見第8章）。

在以下PKI管理操作中使用的PKIMessage的結構如下：

—— 初始的注冊/認證；

—— 基本認證方案；

—— 證書請求；

—— 密鑰更新。

B.1　大綱結構解釋的通用規則

a) 當個人單獨的大綱描述中沒有可選（OPTIONAL）或缺省（DEFAULT）字段時，相關的消息中也不能有（例如：接收者可以以語法錯誤為由來丟棄包含這些字段的消息）。如果必須強制字段具備一些很明顯的值，那么文中也不會特別提及（例如：在本標準中pvno總是為2）。

b) 當結構中不止一個消息時，將分別進行描述。

c) PKIMessage結構的algorithmIdentifiers將分別描述。

d) 存在一種”特殊”的 X.500 DN被稱為”NULL-DN”；這表明DN 包含長度為0的SEQUENCE OF RelativeDistinguishedNames（它的DER編碼為‘3000’H）。

e) 當某字段需要GeneralName，但是又沒有合適的值時（例如：終端實體在知道它的名字之前產生了一個請求），GeneralName就為X.500 NULL-DN（例如：CHOICE的Name字段含有NULL-DN）。這種特殊的值也稱為“NULL-GeneralName”。

f) 當描述某大綱沒有給GeneralName規定值時，相關PKIMessage字段的值就為NULL-GeneralName。這種情況通常發生在某些消息的PKI Header的sender字段。

g) 在字段命名發生歧義的時候，描述名字就使用“點”號（例如：“certTemplate.subject”表示subject字段在certTemplate字段中）。

h) 當“SEQUENCE OF types”作為消息的一部分時，我們使用以0為基數的數組符號來描述SEQUENCE OF中的字段。（例如：crm[0].certReq.certTemplate.subject是指請求消息中第一個certReqMsg的子字段。）

i) 在第B.4~B.6章中所有的PKI消息交換需要由發送實體發送certConf消息，同時由響應實體發送PKIConfirm消息。在某些描述大綱中，由于包體為NULL，而包頭的內容參照上下文非常清楚，所以沒有包括PKIConfirm，因為它的體為NULL，頭內容在上下文中很清楚。對于protectionAlg可以使用任何認證方法（例如：如果知道共享的秘密信息可以使用基于口令的MAC，或者簽名）。

B.2　算法使用參數

表B.1包含了在PKI管理協議中使用的算法定義。

當需要證明擁有請求的證書中與驗證公鑰相應的簽名私鑰時，使用POP字段（在ProofOfPossession結構中的pop字段中的signature字段）。

字段 值 說明

algorithmIdentifier MSG_SIG_ALG 這個證明只允許采用簽名保護

signature present 使用MSG_SIG_ALG計算比特位

證明擁有請求的證書中與加密公鑰相應的解密私鑰時不按照這種結構；而是使用certConf消息的CertHash字段來代替。

在帶內認證請求協議中，不是每一個CA/RA都需要所有權證明（簽名密鑰，解密密鑰或密鑰一致密鑰）。（如何進行POP基本上是一個策略問題，每一個CA都會在公布的Policy OID 和Certification Practice Statement中表示清楚）。然而，本標準要求CA/RA實體把POP（通過某些方法）作為認證過程的一部分。所有的終端實體都必須能夠提供POP（例如：PKIX-CMP協議的組件必須支持）。

B.4　初始的注冊/認證（基本認證方案）

（未初始化的）終端實體向CA請求（第一個）證書。當CA返回包含有證書的消息時，終端實體會發送證書確認。CA再發回PKIConfirm，關閉交易。所有的消息都進行了認證。

本方案允許終端實體請求對本地產生公鑰的認證（典型地為簽名密鑰）。終端實體也可以選擇請求集中產生并且認證另一個密鑰對（典型地為加密密鑰對）。

請求認證只能用于一個本地產生的公鑰（對于更多的公鑰，需要使用獨立的PKIMessage）。

終端實體必須支持對與本地產生公鑰相關聯的私鑰的所有權證明。

前提：

—— 終端實體可以驗證基于帶外方法的CA簽名；

—— 終端實體和CA共享對稱MACing密鑰。

消息流：

步驟 終端實體 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:

字段 值

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)

– 僅支持一個或兩個CertReqMsg

– 如果請求更多的證書，那么請求就要求被打包在獨立的PKIMessages中

CertReqMsg one or two present

–見下面的詳細資料細節, 注意: crm[0]表示第一個(這是必須有的)

– crm[1]表示第二個 (這是可選的，并且用于請求集中產生的密鑰)

crm[0].certReq.certReqId fixed value of zero

– 消息中模板的索引

crm[0].certReq. certTemplate present

– 必須包含對象公鑰值,否則就不受強制。其它的（值）不受限制

crm[0].pop. POPOSigningKey optionally present if public key

 from crm[0].certReq.certTemplate is

                   a signing key

– 在交換中可能要求所有權證明POP (見第B.3章)

crm[0].certReq.controls.archiveOptions optionally present

– 終端實體可以請求獲得本地產生被歸檔的私鑰

crm[0].certReq.controls.publicationInfo optionally present

– 終端實體可以要求公布結果證書

crm[1].certReq.certReqId fixed value of one

– 消息中模板的索引

crm[1].certReq. certTemplate present

crm[1].certReq.controls.protocolEncrKey present

– [object identifier MUST be PROT_ENC_ALG]

– 如果CA支持集中產生密鑰, CA將用這個短期的非對稱加密密鑰

– (由終端實體產生)來加密（用對稱密鑰來加密）CA為終端實體產生的私鑰

– 代表終端實體來加密 (用于加密的對稱密鑰) CA產生的私鑰

crm[1].certReq.controls.archiveOptions optionally present

crm[1].certReq.controls.publicationInfo optionally present

protection present

– 使用 MSG_MAC_ALG計算比特位

ip:

字段 值

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].certReqId fixed value of zero

– 必須包含對相應ir消息中第一個請求的響應

crc[0].status. status present, positive values allowed:

status “accepted”, “grantedWithMods”

                 negative values allowed:

                      "rejection"

crc[0].status. failInfo present if and only if

             crc[0].status.status is "rejection"

crc[0]. certifiedKeyPair present if and only if

 crc[0].status.status 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].certReqId fixed value of one

– 必須包含對相應ir消息中第二個請求的響應

crc[1].status.status present, positive values allowed:

                "accepted", "grantedWithMods"

                   negative values allowed:

                      "rejection"

crc[1].status. failInfo present if and only if

           crc[0].status.status is "rejection"

crc[1]. certifiedKeyPair present if and only if

crc[0].status.status 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:

字段 值

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

– 見3.3.18中certConf字段內容

– 注意: 如果發送了加密和簽名的證書，那么

– 需要兩個CertStatus結構

protection present

– 使用MSG_MAC_ALG計算比特位

PKIConf:

字段 值

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計算比特位

B.5　證書請求

（已經初始化的）終端實體（由于某種原因）向CA請求證書。當CA返回包含有證書的消息時，終端實體會發送證書確認。CA再發回PKIConfirm，關閉交易。所有的消息都進行了認證。

本大綱中的消息交互流程與第B.4章中的基本一樣，但是有以下不同：

—— 發送者名字應該存在；

—— 在request，response，certConfirm和PKIConfirm消息中必須支持MSG_SIG_ALG的 protectionAlg（也要支持MSG_MAC_ALG）；

—— senderKID和recipKID僅在請求消息驗證時才存在；

—— body為cr或cp；

—— body可能包含一種或兩種CertReqMsg結構；

—— 保護比特根據protectionAlg字段來計算。

B.6　密鑰更新請求

（已經初始化的）終端實體向CA請求證書（用于更新密鑰對和/或已經擁有的相應證書）。當CA返回包含有證書的消息時，終端實體會發送證書確認。CA再發回PKIConfirm，關閉交易。所有的消息都進行了認證。

本大綱中的消息交互流程與第B.4章中的基本一樣，但是有以下不同：

—— 發送者名字應該存在；

—— 在request，response，certConfirm和PKIConfirm消息中必須支持MSG_SIG_ALG的 protectionAlg（也要支持MSG_MAC_ALG）；

—— senderKID和recipKID僅在請求消息驗證時才存在；

—— body為kur或kup；

—— body可能包含一種或兩種CertReqMsg結構；

—— 保護比特根據protectionAlg字段來計算。