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

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

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

—— 根CA密鑰更新；

—— 信息請求/響應；

—— 交叉認證請求/響應；

—— 使用外部實體證書的帶內初始化；

—— 撤銷請求；

—— 證書發布；

—— CRL發布。

C.1　結構解釋的通用規則

（與第B.1章相同。）

C.2　算法使用參數

（與第B.2章相同。）

C.3　自簽名證書

自簽名證書結構用于分發“根”CA的公鑰。采用以下三種方式中的一種（2.4中有這些結構的用法描述）：

類型 功能

newWithNew 真正的自簽名證書；所包含的公鑰必須能用于驗證

 簽名（盡管這只提供了完整性，并且沒有任何認證）

oldWithNew 用新的私鑰對以前的根CA公鑰簽名

newWithOld 用以前的私鑰對新的根CA公鑰簽名

C.4　根CA密鑰更新

根CA更新密鑰對。而后它將產生（通過某些傳輸機制）相關終端實體能夠獲得的CA密鑰更新聲明消息。并且不需要從終端實體那里獲得確認消息。

ckuann message:

字段        值                         注釋

sender CA name CA名稱

body         ckuann(CAKeyUpdAnnContent)

oldWithNew   必須存在                見第C.3章

newWithOld   必須存在              見第C.3章

newWithNew   必須存在              見第C.3章

extraCerts 可選 用于發布證書（例如使用新私鑰簽發的證書）

C.5　PKI信息請求/響應

終端實體發送general通用消息給PKI，以請求隨后的PKI管理操作中所需要的細節。RA/CA用general通用通常的響應消息來響應。如果RA產生響應，那么它將簡單地將從CA那里收到的消息向前傳轉發，可能還會在PKIMessage中的extraCerts字段中加上證書。本消息不需要從終端實體處獲得確認消息。

消息流：

步驟 終端實體 PKI

1 format genm

2 -> genm ->

3 handle genm

4 produce genp

5 <- genp <-

6 handle genp

genM:

字段 值

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:

字段 值

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可以把它的證書加在這里

C.6　交叉認證請求/響應（單向）

單個交叉證書的產生（例如：不要立刻產生兩個不同時產生兩個）。請求CA可以通過使用PKIPublicationInfo控制來選擇由誰來負責發布響應CA產生的交叉證書。

前提：

—— 響應CA在處理請求之前能夠驗證請求的來源（可能請求要求帶外方法）；

—— 請求CA在處理響應之前可以鑒別響應源的真實性（可能請求要求帶外方法）。

PKIHeader中的generalInfo字段決定是否使用證書確認和相應的服務器確認（見3.1.1）。以下流程不要求支持任何一種確認。

消息流：

步驟 請求發起CA 請求響應CA

1 format ccr

2 -> ccr ->

3 handle ccr

4 produce ccp

5 <- ccp <-

6 handle ccp

ccr:

字段 值

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 任何有效值

body ccr (CertReqMessages)

                    只允許一個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

– 見第B.3章

protection present

– 使用MSG_SIG_ALG計算比特位

extraCerts optionally present

– 可以包含請求者想要包括的任何額外證書

ccp:

字段 值

sender 響應CA的名字

– 產生消息的CA的名字

recipient 發起請求CA的名字

– 被要求產生證書的CA的名字

messageTime 產生消息的時間

– 響應CA的當前時間

protectionAlg MSG_SIG_ALG

– 這個消息只允許簽名保護

senderKID present if required

–如果在要求對消息保護進行驗證的情況下時需要則必須存在

recipKID present if required

transactionID present

– 相應ccr消息中的值

senderNonce present

– 128 比特(偽)隨機數 比特

recipNonce present

– 相應ccr消息中的senderNonce

freeText 任何有效值

body ccp (CertRepMessage)

                    只允許一個CertResponse

– 如果請求多個交叉證書，那么就要就必須打包在不同的PKIMessage中

response present

status present

PKIStatusInfo.status present

– 如果PKIStatusInfo.status為下面兩種情況之一

– accepted,或grantedWithMods

– 那么 certifiedKeyPair必須存在，同時failInfo缺省

failInfo present depending on

                   PKIStatusInfo.status

– 如果PKIStatusInfo.status為

– rejection

– 那么certifiedKeyPair缺省，同時 failInfo必須存在

– 而且設置了相應的比特位

certifiedKeyPair present depending on

                    PKIStatusInfo.status

certificate present depending on

                    certifiedKeyPair

– 在發布之前由請求CA必須檢查的實際證書的內容

protection present

– 使用MSG_SIG_ALG計算的比特位

extraCerts optionally present

– 可以包含響應者想要包括的任何額外證書

C.7　使用外部身份證書進行帶內初始化

（未初始化的）終端實體希望初始化為CA/PKI的一員。為了鑒別身份，它使用原來一個已經存在的由另一個（外部）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中信任的另一個證書公鑰相對應的私鑰來簽名）。

消息交互流程與B.4中的一樣，但是有以下不同：

—— EE和CA-1不共享對稱MACing密鑰（在這些實體之間沒有帶外共享的秘密信息）；

—— ir中發送者sender名字必須存在（并且與外部身份證書中對象subject名字一樣）；

—— 在所有消息的protectionAlg中必須使用MSG_SIG_ALG的protectionAlg；

—— 在ir的extraCerts字段中必須攜帶外部身份證書；

—— 不使用senderKID和recipKID；

—— body為ir或ip；

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