6.6 PKI事務

6.6.1　PKI事務概述

本條詳細介紹了PKI的具體功能：注冊請求、更新和撤銷證書。也簡要描述了訪問目錄服務的事務。
CA、RA和證書持有者應能實現本條描述的所有事務。

6.6.2　RA發起的注冊請求

RA可以請求CA為一個終端實體頒發簽名證書。這個事務分五步執行。第一步，終端實體通過帶外事務（例如通過實際呈交一個磁盤）在一個簽名消息中向RA提供一個公鑰。第二步，RA通過一個簽名消息向CA請求證書。第三步，CA通過一個含有證書或錯誤代碼的簽名消息回應RA。第四步RA通過帶外方式向終端實體提供CA的公鑰和所頒發的證書（若是集中產生密鑰對則還包括相應私鑰），終端實體也可以直接從CA獲得。第五步RA向CA發出確認消息。在這個過程中包括三條消息。
a) 從RA到CA的證書請求
RA建立一個PKIBody為cr的PKIMessage。其PKIHeader包括下列信息：
·　pvno是1；
·　transactionID是該RA賦予這個事務的唯一整數；
·　messageTime是當前精確到秒的時間；
·　sender是RA的可辨別名；
·　recipient是CA的可辨別名；
·　protectionAlg是用來保護該消息的簽名算法的算法標識符。
這個消息的消息體是CertReqMessages，它是一個或多個CertReqMessage 字段的序列。對于這個事務，CertReqMessages是一個CertReqMessage 的序列。這個CertReqMessage將包括如下信息：
·　certReq含有請求者希望包含在證書中的信息；
·　pop證明了對新證書私鑰的擁有。
本標準中只支持終端實體產生簽名密鑰對，不支持終端實體產生加密密鑰對。在進行簽名私鑰的擁有性證明時，如果由RA來實現，那么RA修改了主體名，popoSKInput域出現，并且包含了原來的主體名。否則，RA不修改主體名，那么pop域與請求者提交的主體名一致。詳細原理見6.5.3。
certReq是CertRequest，它是一個certReqID、一個CertTemplate和controls 的序列。對于這個事務，certReqID可以是任何整數。
CertTemplate將含有如下信息：
·　version是v3（2）；
·　subject是用戶的名字；
·　publicKey提供了新證書的公鑰，若用集中方式產生密鑰對則不包括該字段；
·　extensions至少指定了與證書有關的證書策略的OID。
如下的信息可以被包含在CertTemplate 中：
·　signingAlg指定了首選簽名算法；
·　subject指定了潛在證書持有者的可辨別名。
請求不應該包括如下信息：
·　issuerUID；
·　subjectUID。
PKIProtection字段含有根據消息頭和消息體的DER編碼序列計算的RA的簽名。
b) 從CA到RA的證書回應
CA將返回以元素cp為PKIBody的PKIMessage 給RA。
PKIHeader包括如下信息：
·　pvno是1；
·　transactionID與cr消息中的transactionID相同；
·　messageTime是當前精確到秒的時間；
·　sender是CA的可辨別名；
·　recipient是RA的可辨別名；
·　protectionAlg是用來保護該消息的簽名算法的算法標識符。
如果senderNonce在證書請求中被提供了，那么這個回應的消息頭應該將其作為recipNonce。
PKIBody元素cp是CertRepMessage類型。對于這個事務，CertRepMessage將含有唯一的response字段。該response字段是一個certReqId、status和certifiedKeyPair 的序列。如果CA頒發了一個證書，消息體將含有如下消息：
·　certReqId將與請求中的certReqId 匹配；
·　status將是granted或者是grantedWithMods；
·　certifiedKeyPair序列將至少含有一個字段——certificate，其將含有GB/T 16264.8-200X的證書。
證書必須滿足如下性質：
·　version 號應該是v3（2）；
·　publicKey字段應該與證書請求中相同或者是由CA所產生的公鑰；
·　主體可辨別名應該與證書請求中相同；
·　頒發者名字應該是CA的可辨別名；
·　如果notBefore出現在證書請求中，證書應該從頒發日和notBefore所指之日的較晚者 之后生效；
·　如果notAfter出現在證書請求中，證書應該在該日或之前期滿。
證書應該包括如下擴展（extensions）：
·　subjectKeyIdentifier域；
·　在certificatePolicies字段中至少包括一個證書策略的OID；
·　包括KeyIdentifier字段的權威密鑰標識符。
如果在證書請求消息中指定一個特定的密鑰標識符，那么證書的subjectKeyIdentifier字段應該就是該密鑰標識符。如果沒有具體指明密鑰標識符，CA將用主體公鑰的低96位SHA-1散列函數作為subjectKeyIdentifier字段中的KeyIdentifier。散列函數是通過對證書中主體公鑰字段的值（不包括標簽和長度）進行計算得到的。
如果頒發者的證書或是CRLs不提供X.500目錄服務，證書就應含有issuerAltName擴展中的URLs以及CRLDistributionPoints擴展中的distributionPoint字段。
如果status是granted和grantedWithMods，那么failInfo字段可以不存在。
若CA拒絕了請求，則正文中包含以下信息：
·　status 將是 rejected；
·　failInfo 字段包含相應的錯誤碼：
badAlg 說明CA不能驗證簽名，因為算法標識符無法識別或者不支持，
badMessageCheck 說明PKIProtection字段中的mac被檢驗，但是不匹配，
badPoP 說明popoSigningKey字段中的簽名已經被檢驗，但是不匹配，
badRequest 說明響應者不允許或不支持該事務請求，
badTime 說明消息頭中的messageTime字段中的時間與響應者的系統時間差別太大；
如果status是rejected，那么certifiedKeyPair字段可以不出現。
PKIProtection字段含有根據消息頭和消息體的DER編碼序列計算的CA的簽名。
c) 確認消息
一旦接收到cp，RA應該產生PKIConfirm消息。確認消息的PKIHeader中的數據除了messageTime之外，應該與證書請求消息的PKIHeader中的數據相同。

6.3 新實體的自我注冊請求

一個新的實體如果從來沒有從一個特定CA獲得證書，他可以直接向那個CA申請一個新的證書。請求實體生成一個PKI ir消息來請求新證書，并在消息中包含和證書請求中公鑰相對應的私鑰的擁有證明。實體利用RA提供的一個秘密密鑰和SHA-1 HMAC算法保護PKI消息。
如果CA接受自我注冊請求，它將返回一個ip消息給證書持有者。該消息包含證書或者事務出錯的原因代碼。
a) RA與實體的帶外事務
自我注冊申請證書的過程以RA和實體之間交換一個共享的秘密密鑰開始。通過從共享的秘密中產生一個消息認證碼，CA能夠對實體進行認證。
這里不指定這個帶外事務的明確的內容和格式。但是秘密的密鑰和可信CA的公鑰信息應該以一種可信的方式傳遞給實體。
b) 從證書持有者到CA的自我注冊請求
請求者建立一個PKIBody為ir的PKIMessage。PKIHeader包括如下信息：
·　pvno是1；
·　messageTime是當前精確到秒的時間；
·　sender是請求者的可辨別名或一個電子郵件地址；
·　recipient是CA的可辨別名；
·　protectionAlg是用來保護消息的簽名算法的算法標識符。
這個消息的消息體是CertReqMessages，它是一個或多個CertReqMessage 字段的序列。對于這個事務，CertReqMessages是一個CertReqMessage 的序列。這個CertReqMessage將包括如下信息：
·　certReq含有請求者希望包含在證書中的信息；
·　popoSKInput包含公鑰的mac值；
·　pop證明了對證書私鑰的擁有。
其中pop 域通過與CertTemplate中的公鑰相對應的私鑰來產生，產生pop的輸入數據包括popoSKInput中的公鑰mac值和CertTemplate中的公鑰。
certReq是一個CertRequest，它是一個certReqID，一個CertTemplate和controls的序列。對于這個事務：
·　certReqID是任何整數；
·　certTemplate是一個CertTemplate，其至少包括為新證書提供公鑰的publicKey字段；
·　controls被省略。
CertTemplate將含有如下信息：
·　version是v3（2）；
·　publicKey提供了新證書的公鑰。
如下的信息可以被包含在CertTemplate 中：
·　signingAlg指定了首選簽名算法；
·　subject指定了潛在證書持有者的可辨別名；
·　extensions至少指定了與證書有關的證書策略的OID。
請求不應該包括如下信息：
·　issuerUID；
·　subjectUID。
PKIProtection域包含一個請求者利用從RA獲得的秘密產生的值。實體利用RA提供的秘密密鑰產生一個96bit的SHA1-HMAC。protectionAlg域應該設成SHA1-HMAC，PKIProtection的值應該是96位的消息認證碼。計算PKIProtection的輸入是如下數據結構的DER編碼：
ProtectedPart::=SEQUENCE {
PKIHeader,
PKIBody}
c) 從CA到證書請求者的自我注冊請求的回應
CA將返回給證書持有者一個PKIBody為ip的PKIMessage消息。PKIHeader包含如下信息：
·　pvno是1；
·　messageTime是當前精確到秒的時間；
·　sender是CA的可辨別名；
·　recipient是證書請求消息頭中sender域的值；
·　protectionAlg是用來保護消息的簽名算法的算法標識符。
如果ir消息中提供了transactionID，這個回應的消息頭中將包括同樣的transactionID。如果ir消息中提供了senderNonce，這個回應的消息頭中將包含recipNonce。
PKIBody元素ip是CertRepMessage類型。如果CA頒發了一個證書，消息體將含有如下信息：
·　status將是granted或者是grantedWithMods；
·　certificate包含新的GB/T 16264.8-200X的證書。
如果status是granted或者是grantedWithMods，failInfo域可以不存在。
如果CA拒絕了請求，消息體將含有如下信息：
·　status將是rejected；
·　failInfo包含適當的錯誤代碼：
badAlg 說明CA不能驗證簽名，因為算法標識符無法識別或者不支持，
badMessageCheck 說明PKIProtection字段中的mac被檢驗，但是不匹配，
badPoP 說明popoSigningKey字段中的簽名已經被檢驗，但是不匹配，
badRequest 說明響應者不允許或不支持該事務請求，
badTime 說明消息頭中的messageTime字段中的時間與響應者的系統時間差別太大，
badCertID 表明CertDetails 中的信息無法確定一個未過期、未撤銷的證書；
如果status是rejected，certificate域可能不存在，如果存在證書應該遵從于6.2.1中定義的證書輪廓。
證書應該包括如下擴展（extensions）：
·　subjectKeyIdentifier域；
·　在certificatePolicies字段中至少包括一個證書策略的OID；
·　包括KeyIdentifier字段的權威密鑰標識符。
如果在ir消息中指定一個特定的密鑰標識符，那么證書的subjectKeyIdentifier字段應該就是該密鑰標識符。如果沒有具體指明密鑰標識符，CA將用主體公鑰的低96位SHA-1散列函數作為subjectKeyIdentifier字段中的KeyIdentifier。散列函數是對證書中主體公鑰字段的值（不包括標簽和長度）計算得到的。
如果ir消息中包含了除subjectKeyIdentifier之外的其它擴展，CA將修改或者忽略該擴展。
如果頒發者的證書或是CRLs不提供X.500目錄服務，證書就應含有issuerAltName擴展中的URLs以及CRLDistributionPoints擴展中的distributionPoint字段。
PKIProtection字段含有根據消息頭和消息體的DER編碼序列計算的CA的簽名。
d) 確認消息
一旦接收到ip，證書持有者應該產生一個PKIConfirm消息。確認消息的PKIHeader中的數據除了messageTime之外，應該與證書請求消息的PKIHeader中的數據相同。
如果請求被接受，PKIProtection域包含證書持有者的數字簽名，利用與新的簽名證書對應的私鑰對消息頭和消息體的DER編碼序列計算簽名。如果請求被拒絕，PKIProtection域包含SHA-1 HMAC，利用共享秘密對消息頭和消息體的DER編碼計算。
一旦接收到PKIConfirm，CA應該產生一個PKIConfirm消息。確認消息的PKIHeader中的數據除了messageTime之外，應該與證書請求消息的PKIHeader中的數據相同。

6.4 已知實體的自我注冊請求

一個實體不是當前的證書持有者，但是以前曾經從一個特定CA獲得過證書，他可以直接向那個CA申請一個新的證書。請求實體生成一個PKI cr消息來請求新證書，并在消息中包含與證書請求中公鑰所對應的私鑰的擁有證明。實體利用RA提供的一個秘密密鑰和SHA-1 HMAC算法保護PKI消息。
如果CA接受自我注冊請求，它將返回一個cp消息給證書持有者。該消息包含證書或者事務出錯的原因代碼。
a) RA與實體的帶外事務
自我注冊申請證書的過程以RA傳遞一個共享的秘密密鑰給實體開始。通過從共享的秘密中產生的一個消息認證碼，CA能夠對實體進行認證。
這里不指定這個帶外事務的明確的內容和格式。但是秘密的密鑰和可信CA的公鑰信息應該以一種可信的方式傳遞給實體。
b) 從證書持有者到CA的自我注冊請求
請求者建立一個PKIBody為cr的PKIMessage。PKIHeader包括如下信息：
·　pvno是1；
·　messageTime是當前精確到秒的時間；
·　sender是請求者的可辨別名或一個電子郵件地址；
·　recipient是CA的可辨別名；
·　protectionAlg是用來保護消息的簽名算法的算法標識符。
這個消息的消息體是CertReqMessages，它是一個或多個CertReqMessage 字段的序列。對于這個事務，CertReqMessages是一個CertReqMessage 的序列。這個CertReqMessage將包括如下信息：
·　certReq含有請求者希望包含在證書中的信息；
·　popoSKInput包含公鑰的mac值；
·　pop證明了對證書私鑰的擁有。
其中pop 域通過與CertTemplate中的公鑰相對應的私鑰來產生，產生pop的輸入數據包括popoSKInput中的公鑰mac值和CertTemplate中的公鑰。
certReq是一個CertRequest，它是一個certReqID，一個CertTemplate和controls的序列。對于這個事務：
·　certReqID是任何整數；
·　certTemplate是一個CertTemplate，其至少包括為新證書提供公鑰的publicKey字段。
CertTemplate將含有如下信息：
·　version是v3（2）；
·　publicKey提供了新證書的公鑰。
如下的信息可以被包含在CertTemplate 中：
·　signingAlg指定了首選簽名算法；
·　subject指定了潛在證書持有者的可辨別名。
·　extensions至少指定了與證書有關的證書策略的OID。
請求不應該包括如下信息：
·　issuerUID；
·　subjectUID。
PKIProtection域包含一個請求者利用從RA獲得的秘密產生的值。實體利用RA提供的秘密密鑰產生一個96bit的SHA1-HMAC。protectionAlg域應該設成SHA1-HMAC，PKIProtection的值應該是96位的消息認證碼。計算PKIProtection的輸入是如下數據結構的DER編碼：
ProtectedPart::=SEQUENCE {
PKIHeader,
PKIBody}
c) 從CA到證書請求者的自我注冊請求的回應
CA將返回給證書持有者一個PKIBody為cp的PKIMessage消息。PKIHeader包含如下信息：
·　pvno是1；
·　messageTime是當前精確到秒的時間；
·　sender是CA的可辨別名；
·　recipient是證書請求消息頭中sender域的值；
·　protectionAlg是用來保護消息的簽名算法的算法標識符。
如果cr消息中提供了transactionID，這個回應的消息頭中將包括同樣的transactionID。如果cr消息中提供了senderNonce，這個回應的消息頭中將包含recipNonce。
PKIBody元素cp是CertRepMessage類型。如果CA頒發了一個證書，消息體將含有如下信息：
·　status將是granted或者是grantedWithMods；
·　certificate包含新的GB/T 16264.8-200X的證書。
如果status是granted或者是grantedWithMods，failInfo域可以不存在。
如果CA拒絕了請求，消息體將含有如下信息：
·　status將是rejected；
·　failInfo包含適當的錯誤代碼：
badAlg 說明CA不能驗證簽名，因為算法標識符無法識別或者不支持，
badMessageCheck 說明PKIProtection字段中的mac被檢驗，但是不匹配，
badPoP 說明popoSigningKey字段中的簽名已經被檢驗，但是不匹配，
badRequest 說明響應者不允許或不支持該事務請求，
badTime 說明消息頭中的messageTime字段中的時間與響應者的系統時間差別太大，
badCertID 表明CertDetails 中的信息無法確定一個未過期、未撤銷的證書；
如果status是rejected，certificate域可能不存在，如果存在證書應該遵從于6.2.1中定義的證書輪廓。
證書應該包括如下擴展（extensions）：
·　subjectKeyIdentifier域；
·　在certificatePolicies字段中至少包括一個證書策略的OID；
·　包括KeyIdentifier字段的權威密鑰標識符。
如果在cr消息中指定一個特定的密鑰標識符，那么證書的subjectKeyIdentifier字段應該就是該密鑰標識符。如果沒有具體指明密鑰標識符，CA將用主體公鑰的低96位SHA-1散列函數作為subjectKeyIdentifier字段中的KeyIdentifier。散列函數是對證書中主體公鑰字段的值（不包括標簽和長度）計算得到的。
如果cr消息中包含了除subjectKeyIdentifier之外的其它擴展，CA將修改或者忽略該擴展。
如果頒發者的證書或是CRLs不提供X.500目錄服務，證書就應含有issuerAltName擴展中的URLs以及CRLDistributionPoints擴展中的distributionPoint字段。
PKIProtection字段含有根據消息頭和消息體的DER編碼序列計算的CA的簽名。
d) 確認消息
一旦接收到cp，證書持有者應該產生一個PKIConfirm消息。確認消息的PKIHeader中的數據除了messageTime之外，應該與證書請求消息的PKIHeader中的數據相同。
如果請求被接受，PKIProtection域包含證書持有者的數字簽名，利用與新的簽名證書對應的私鑰對消息頭和消息體的DER編碼序列計算簽名。如果請求被拒絕，PKIProtection域包含SHA-1 HMAC，利用共享秘密對消息頭和消息體的DER編碼計算。
一旦接收到PKIConfirm，CA應該產生一個PKIConfirm消息。確認消息的PKIHeader中的數據除了messageTime之外，應該與證書請求消息的PKIHeader中的數據相同。

6.6.5　證書更新

擁有當前有效（指在有效期內、未被撤銷）證書的PKI實體可以直接向該證書的簽發CA要求簽發一份新的證書。PKI實體生成PKI kr（Key update Request密鑰更新申請）消息，信息中包括了證書申請和相應的pop。然后PKI實體使用有效證書的對應私鑰對PKI kr消息進行簽名。
如果CA的CPS支持證書更新，則CA返回kp（Key update response密鑰更新響應）消息。kp消息包含了新生成的證書或者是事務失敗的代碼。
如果新證書成功生成，則可能還有兩個可選的消息。分別是：PKI實體在收到新的證書后，給CA發出確認；然后CA也可回應一個確認消息。
a) 從證書持有者到CA的證書更新申請
證書持有者生成PKIBody是kr的PKIMessage，PKIMessage中的PKIHeader包括了如下信息：
·　pvno是1；
·　messageTime是精度到秒的當前時間；
·　sender是證書持有者的可辨別名；
·　recipient是CA的可辨別名；
·　protectionAlg是用于保護消息簽名算法ID。
消息體是CertReqMessages，是一個或者多個CertReqMessage組成的序列。對于證書更新事務，CertReqMessages只能是包括了一個CertReqMessage的序列。在消息CertReqMessage中包括了如下信息：
·　certReq包含了申請者要求包括在證書中的各種信息；
·　pop是新證書公鑰的對應的pop證明。
pop必須是由publicKey域的公鑰對應的私鑰產生的。
certReq是CertRequest，CertRequest是由一個certReqID、一個certTemplate和controls所組成的序列。對于證書更新事務：
·　version必須是v3(2)；
·　publicKey中是新證書的公鑰。
CertTemplate中可能包括了如下信息：
·　signingAlg指明了首選的簽名算法；
·　subject則是預期的證書持有者的可辨別名。
如果消息中沒有signingAlg，那么CA必須使用終端實體的公鑰對應的算法簽名。
申請中不應該包括如下信息：
·　issuerUID；
·　subjectUID。
PKIProtection域是使用當前有效證書的對應私鑰對消息頭和消息體的DER編碼信息的簽名結果。
b) 從CA到證書持有者的證書更新響應
CA生成PKIBody是kp的PKIMessage，PKIMessage中的PKIHeader包括了如下信息：
·　pvno是1；
·　messageTime是精度到秒的當前時間；
·　sender是CA的可辨別名；
·　recipient是證書持有者的可辨別名，也就是kr消息的sender；
·　protectionAlg是用于保護消息簽名算法ID。
如果在kr消息中具有transtionID，則CA回應消息的消息頭中包括同樣的transtionID。如果在senderNonce消息中具有senderNonce，則CA回應消息的消息頭中應該包括同樣的recipNonce。
在PKIBody中，是kp元素。kp是CertRepMessage格式。如果CA簽發了新證書，在消息體中應包括如下信息：
·　status是granted或者grantedWithMods；
·　certificate是新生成的GB/T 16264.8-200X證書。
新生成的證書應該包括如下擴展：
·　subjectKeyIdentifier域；
·　在certificatePolicies字段中至少包括一個證書策略OID；
·　在KeyIdentifier域中有一個機構密鑰標識符。
certificatePolicies擴展應該和當前有效證書一致。如果在kr消息中包含了密鑰標識符信息，則證書中應該將其包含在subjectKeyIdentifier；如果沒有提供密鑰標識符信息，則CA應該對證書公鑰信息計算低96 bit的SHA-1摘要值作為subjectKeyIdentifier的值。摘要值是對證書中的主體公鑰進行計算的，不包括標簽和長度。
如果kr信息中包括了subjectKeyIdentifier之后的擴展，則CA可以對其它的擴展信息進行修改或者忽略。
如果發布者的證書和CRL不能夠從已知的X.500目錄中得到，則新證書中應該在issuerAltName中包括URLs信息，在CRLDistributionPoints控制中包括distributionPoint域。
如果status是granted或者grantedWithMods，則failInfo域不存在。
如果CA拒絕用戶的申請，消息體包括如下信息：
·　status是rejected；
·　failInfo包括了合適的代碼，可以是：
badAlg表示CA不支持或者不認識kr指定的簽名算法，
badPop表示popoSigningKey域中的簽名有誤，
badMessageCheck表示PKIProtection域中的簽名有誤，
badRequest表示回應者不支持或者不允許該事務，
badTime表示消息頭中的messageTime的時間和回應者的系統時間相差太大，
badCertId表示證書序號不能是serial域中所填的非零值；
如果status是rejected，certifcate域不存在。
PKIProtection域包含了CA對于消息頭和消息體的DER編碼的簽名。
c) 確認消息
收到kp的時候，證書持有者應該產生PKIConfirm消息。PKIHeader中的信息和利用RA向CA申請證書的情況下的PKIHeader一致，除了messageTime是當前時間。
如果證書更新申請被接受，則PKIProtection是證書持有者使用新證書的對應私鑰，對于消息頭和消息體的DER編碼的簽名。如果申請被拒絕，則PKIProtection是證書持有者使用當前有效證書的對應私鑰，對于消息頭和消息體的DER編碼的簽名。
收到PKIConfirm的時候，CA應該產生PKIConfirm消息。PKIHeader中的信息和kp一致，除了messageTime是當前時間。

6.6.6　PKCS#10自我注冊請求

目前不是證書持有者的實體可以用RFC 2314定義的證書請求語句直接向CA申請證書。請求實體產生PKCSReq類型的PKIMessage消息來申請證書，在證書請求中的正文里包括相應私鑰的擁有證明，并用RA以帶外方式提供的密鑰來加密該PKIMessage.
CA返回一個證書請求響應消息給證書申請者。該消息將包含證書或處理失敗原因代碼。
證書請求者和RA之間需用帶外方式完成一個秘密消息的交換。
a) 從證書持有者到CA的自我注冊請求
請求者產生一個包含PKIBody元素p10cr 的PKIMessage, PKIHeader包含以下信息：
·　pvno 是1；
·　messageTime 當前精確到秒時間；
·　sender 請求者的可辨別名或電子郵件地址；
·　recipient CA的可辨別名；
·　protectionAlg 用來保護該消息的簽名算法的算法標識符。
PKIBody是PKCS10CertReqMessages類型，此類型是一個certificationRequestlnfo、signatureAlgorithm和signature的序列。certificationRequestinfo 包含以下信息：
·　version 是V3(2)；
·　subject 當且僅當serial為零時才出現，指明證書持有者的可辨別名；
·　subjectPublicKeyInfo 指明了新證書的公鑰和相應的算法標識符。
signatureAlgorithm 字段包含用來生成signature字段的私鑰的相應算法標識符；簽名是對DER編碼后的certficationRequestInfo 進行的。
PKIProtection 字段包含一個請求者用從RA獲得的秘密信息生成的一個值。實體用RA提供的密鑰產生一個MAC。 protectionAlg字段應為所用的消息認證算法的OID, 并且PKIProtection的值就是消息認證碼。PKIProtection的輸入是如下數據結構的DER編碼：
ProtectedPart::=SEQUENCE{
header PKIHeader,
body PKIBody}
b) 從CA到證書申請者的PKCS證書請求響應
CA會返回一個包含PKIBody元素cp 的PKIMessage給證書持有者。 PKIHeader 包含以下信息：
·　pvno 是1；
·　messageTime 當前精確到秒的時間；
·　sender CA的可辨別名；
·　recipient 證書請求頭消息中的sender的值；
·　protectionAlg 用來保護該消息的簽名算法的算法標識符。
如果PKCSReq中有transactionID, 則響應的PKIHeader中應包含相同的transactionID。
PKIBody的元素是一個CerRepMessage類型的cp。若CA發放了證書，PKIBody將包含以下信息：
·　status為granted或grantedWithmods，
·　certificate 包含新的GB/T 16264.8-200X證書。
若p10cr消息中指定了特定的密鑰標識符，證書將在subjectKeyIdentifier字段包含該密鑰標識符。如果沒有指明具體的密鑰標識符，CA將用主體公鑰的低96位SHA-1散列函數作為subjectKeyIdentifier字段中的KeyIdentifier。散列函數是對證書中主體公鑰字段的值（不包括標簽和長度）計算得到的。
如果status為granted或grantedWithmods，failInfo將不出現；若CA拒絕請求，正文將包含以下信息：
·　status為rejected；
·　failInfo 包含相應的錯誤代碼：
badAlg 指明算法的標識符不被識別或不被支持，因此CA無法驗證簽名，
badpop 指明pk10cr 的 signature字段的簽名被校驗，但是不匹配，
badMessageCheck 指明PKIMessage的PKIProtection字段里的MAC 被拒絕，
badrequest 指明響應者不允許或不支持請求，
badtime 指明消息頭中的messageTime字段中的時間與響應者的系統時間差別太大；
若status字段為rejected，certifitate字段將不出現。
證書還要包括以下擴展：
·　一個 subjectKeyIdentifier 字段；
·　在certificatePolicies字段中至少包括一個證書策略OID；
·　一個authority 密鑰標識符，包括一個KeyIdentifier字段。
若cr消息中還包括除subjectKeyIdentifier以外的其它擴展，CA就可以修改或忽略請求擴展。
如果頒發者的證書或是CRLs不提供X.500目錄服務，證書就應含有issuerAltName擴展中的URLs以及CRLDistributionPoints擴展中的distributionPoint字段。

6.6.7　撤銷請求

證書持有者可以請求撤銷自己的證書。證書持有者產生一個RevReq消息，對該消息進行簽名并發送給相應RA，并在RA審查通過用戶的身份后向CA發出相應撤銷信息。該簽名必須用未過期、未被撤銷的簽名證書的相應私鑰產生（可以是要撤銷的證書）。 RevReq消息要標識出想撤銷的證書以及要撤銷的原因。CA回應RA一個RevRep消息，RA再回應證書持有者相應的RevRep消息。
如果消息rr (RevReq)中包含transactionID，則CA和RA所響應的rp (RevRep) 消息中也應包含相同的transactinID，注意其中從證書持有者所發出的rr和RA所發出的rr消息中的transactinID可以不同。rp消息至少要包含status字段以反映請求的狀態和revDetails字段以表示欲撤銷的證書。
a) 從證書持有者到RA的撤銷請求
證書持有者生成一個包含一個PKIBody元素rr的 PKIMessage。 PKIHeader包含以下信息：
·　pvno是1；
·　transactionID 與終端實體名一起唯一標識一個終端實體與RA之間事務的整數；
·　messageTime為當前精確到秒的時間；
·　sender為證書持有者的可辨別名；
·　recipient為RA的可辨別名；
·　protectionAlg為保護消息而使用的簽名算法標識符。
消息的正文PKIBody為RevReqContent，RevReqContent是RevDetails的序列。RevDetails是由CertDetails和三個可選字段組成的序列：原因標志；懷疑或丟失的日期和時間；以及crlEntryDetails（一個CRL Entry擴展的序列）。CertDetails被定義為一個CertTemplate。在本標準中，RevReqContent是一個RevDetails的序列。CertDetails，最少包括以下信息：
·　serial 證書序列號；
·　issuer 證書發放者的標識名。
或是
·　subject 證書持有者的標識名；
·　issuer 證書發放者的標識名。
CertDetails 還可在extensions字段中包含一個subjectKeyIdentifier。 (如果請求者希望撤銷頒發給某個主體的所有證書， CertDetails 就應僅含有subject 和 issuer。 也就是說，僅希望撤銷單個證書的請求就只含有相應的序列號或是subjectKeyIdentifier )。
RevDetails 要包括帶有reasonCode擴展的crlEntryDetails, 也可以包括 invalidityDate 擴展來說明何時該證書作廢。原因代碼也可以不是 removeFromCRL。
PKIProtection 字段含有請求者的簽名，即對頭和正文的DER編碼進行簽名。終端實體要用相應CA所頒發的當前有效簽名證書的相應私鑰進行簽名。
b) 從RA到CA的撤銷請求
RA或證書持有者生成一個包含一個PKIBody元素rr的 PKIMessage。 PKIHeader包含以下信息：
·　pvno是1；
·　transactionID 標識RA名一起唯一標識一個RA與CA之間事務的整數；
·　messageTime為當前精確到秒的時間；
·　sender為RA的可辨別名；
·　recipient為CA的可辨別名；
·　protectionAlg為保護消息而使用的簽名算法標識符。
消息體與從證書持有者到RA的撤銷請求相同。
PKIProtection 字段含有RA的簽名，即對頭和正文的DER編碼進行簽名。RA要用相應CA所頒發的當前有效簽名證書的相應私鑰進行簽名。
c) 從CA到RA的撤銷響應
CA返回一個含有PKIBody元素rp 的PKIMessage給請求者。 PKIHeader包含以下信息：
·　pvno是1；
·　transactionID 和從RA到CA的撤銷請求rr 消息中的transactionID字段一樣；
·　messageTime為當前精確到秒的時間；
·　sender為CA的可辨別名；
·　recipient為RA的可辨別名；
·　protectionAlg為保護消息而使用的簽名算法標識符。
如果相應從RA到CA的撤銷請求中有senderNonce , 則響應的PKIHeader中應把它作為recipNonce 。
PKIBody是RpContent，如果CA撤銷了證書，正文將包含以下信息：
·　status 是 granted 或是 grantedWithMods；
·　revDetails 將包含已撤銷證書的 CertId ；
·　如果 status 是 granted 或 grantedWithMods,failInfo 字段也可以不出現。
如果CA 拒絕了請求，正文就要包括如下信息：
·　status為rejected；
·　faillnfo 包含相應的失敗代碼:
badAlg 指明CA不能驗證簽名，因為算法的標識符不被識別或不被支持，
badMessageCheck指明PKIProtection字段里的簽名得到驗證，但是不匹配，
badRequest字段指明響應者不允許或不支持請求，
badTime字段指明消息頭中的messageTime字段中的時間與響應者的系統時間差別太大，
badCertID 表明CertDetails 中的信息無法確定一個未過期、未撤銷的證書；
對于能夠確定有問題的證書，revDetails 將包含這個被拒絕撤銷證書的 CertId 。PKIProtection 字段包含CA的簽名，即對頭和正文的DER編碼進行簽名。若CA生成CRLs,并且撤銷請求被接受，CRL將有以下值:
·　userCertificate 字段中的被撤銷證書的序列號；
·　revocationDate 收到撤銷請求的日期和時間；
·　crlEntryExtensions 要出現并包括：
RevDetails 字段中的reasonCode ，除非CA的策略有專門規定，
(可選的) RevDetails字段中的 badSinceDate 擴展可以是invalidaityDate。
d) 從RA到證書持有者的撤銷響應
RA在收到CA的回應消息后，返回一個含有PKIBody元素rp 的PKIMessage給證書持有者。 PKIHeader包含以下信息：
·　pvno是1；
·　transactionID 和從RA到CA的撤銷請求rr 消息中的transactionID字段一樣；
·　messageTime為當前精確到秒的時間；
·　sender為CA的可辨別名；
·　recipient為RA的可辨別名；
·　protectionAlg為保護消息而使用的簽名算法標識符。
如果相應的從證書持有者到RA的撤銷請求消息中有senderNonce , 則響應的PKIHeader中應把它作為recipNonce 。

6.6.8　集中產生密鑰對和密鑰管理證書申請

擁有當前有效證書的PKI實體可以向該證書的簽發CA提出申請，申請產生加密密鑰對并簽發相應的證書。下面以RSA為例說明申請過程，在國內應用時，應使用國家密碼管理主管部門審核批準的相關算法。發出申請的實體：
·　產生臨時的密鑰管理密鑰；
·　生成PKI cr（證書申請certificate request）消息，申請RSA密鑰管理證書，cr消息中包括了上一步的臨時密鑰；
·　利用當前有效證書的對應私鑰，對消息進行簽名；
·　發送給CA。
如果CA的CPS支持集中產生加密密鑰對，則CA執行如下操作：
·　CA按申請消息的要求產生密鑰對，簽發密鑰管理證書；
·　申請消息使用臨時RSA密鑰；
·　CA產生對稱密鑰；
·　利用對稱密鑰加密新產生的私鑰；
·　使用臨時RSA公鑰加密對稱密鑰；
·　產生和返回cp（certificate response證書響應）消息給證書持有者。cp消息中包括了新生成的證書和加密后的私鑰，或者是事務失敗的代碼。
a) 集中產生密鑰對申請
證書持有者產生證書申請消息：PKIMessage消息中的PKIBody部分是cr元素。PKIHeader包括了如下信息：
·　pvno是1；
·　messageTime是當前時間，精確到秒；
·　sender是證書持有者的可辨別名；
·　recipient是CA的可辨別名；
·　protectionAlg是用于保護消息簽名算法ID。
消息體是CertReqMessages，是一個或者多個CertReqMessage組成的序列。對于集中產生密鑰對申請和密鑰管理證書事務，CertReqMessages只能是包括了一個CertReqMessage的序列。在消息CertReqMessage中包括了如下信息：
·　certReq包含了申請者要求包括在證書中的各種信息。
certReq是CertRequest，CertRequest是由一個certReqID、一個certTemplate和controls所組成的序列。對于集中產生密鑰對申請和密鑰管理證書事務：
·　certReqID是任意整數；
·　certTemplate是一個CertTemplate；
·　controls包含了protocolEncrKey控制。protocolEncrKey registration control的值是臨時公鑰的值和參數（如果需要），以及算法OID。
CertTemplate包含了如下信息：
·　version必須是v3(2)；
·　publicKey指明了算法和可選的參數，說明了所申請的密鑰。
CertTemplate中可能包括了如下信息：
·　signingAlg指明了首選的簽名算法。
如果沒有signingAlg，則CA應該使用protectionAlg中說明的簽名算法。
申請消息里面不應該包括如下信息：
·　issuerUID；
·　subjectUID。
PKIProtection域是使用當前有效證書的對應私鑰對消息頭和消息體的DER編碼信息的簽名結果。
b) 集中產生密鑰對回應
CA返回密鑰更新（PKIMessage，PKIBody是cp元素）消息給證書持有者。
PKIHeader包括了如下信息：
·　pvno是1；
·　messageTime是當前時間，精度到秒；
·　sender是CA的可辨別名；
·　recipient是證書持有者的可辨別名，也就是cr消息的sender；
·　protectionAlg是用于保護消息簽名算法ID。
如果在cr消息中具有transtionID，則CA回應消息的消息頭中包括同樣的transtionID。如果在senderNonce消息中具有senderNonce，則CA回應消息的消息頭中應該包括同樣的recipNonce。
PKIBody是cp元素。也就是CertRepMessage格式。如果CA簽發了新證書，在消息體中應包括如下信息：
·　status是granted或者是grantedWithMods；
·　certificate包括了新簽發的GB/T 16264.8-200X證書；
·　certifiedKeyPair必須存在。
certifiedKeyPair將在certOrEncCert域中包括證書，在privateKey域中包括加密過的私鑰。申請者使用臨時RSA公鑰，privateKey域應該包括symmAlg、encSymmKey和encValue。
·　symmAlg應該包括tDEA-ecb的OID，keyingOption應該是option-2（表示K1和K2是獨立產生的，K3 = K1）；
·　encSymmKey是對CA產生的對稱密鑰的加密計算結果，使用臨時RSA公鑰進行加密；
·　對稱密鑰K1和K2，應串接為TwoKeys，見（6.2.2.5）；
·　TwoKeys應該按照RFC 2313說明的RSA加密方法進行加密；
·　加密結果編碼為encSymmKey。加密結果編碼為BIT STRING，BIT STRING的最高位就是加密結果的最高位。
新的用戶證書應該包括如下擴展：
·　subjectKeyIdentifier域；
·　在certificatePolicies字段中至少包含一個證書策略OID；
·　在KeyIdentifier域中有一個機構密鑰標識符。
CA應該對證書公鑰信息計算低96bit的SHA-1摘要值，并將其作為subjectKeyIdentifier的值。摘要值是對證書中的主體公鑰進行計算得到的，不包括標簽和長度。
如果cr消息中包含了擴展，CA有可能修改或者忽略其擴展。
如果issuer的證書和CRL不能夠從已知的X.500目錄中得到，則新證書中應該在issuerAltName中包括URLs信息，在CRLDistributionPoints控制中包括distributionPoint域。
如果status是granted或者grantedWithMods，則failInfo域不存在。
如果CA拒絕用戶的申請，消息體包括如下信息：
·　status是rejected；
·　failInfo包括了合適的代碼，可以是：
badAlg表示CA不支持或者不認識kr指定的簽名算法，
badPop表示popoSigningKey域中的簽名有誤，
badMessageCheck表示PKIProtection域中的簽名有誤，
badRequest表示回應者不支持或者不允許該事務，
badTime表示消息頭中的messageTime的時間和回應者的系統時間相差太大，
badCertId表示證書序號不能是serial域中所填的非零值；
如果status是rejected，certifcate域不存在。
PKIProtection域包含了CA對于消息頭和消息體的DER編碼的簽名。
c) 確認消息
收到cp的時候，證書持有者應該產生PKIConfirm消息。PKIHeader中的信息和利用RA向CA申請證書的情況下的PKIHeader一致，除了messageTime是當前時間。

6.6.9　組合證書申請

簽名密鑰證書和密鑰管理密鑰證書的申請可以由一次事務完成。RA發起的注冊請求和自我注冊請求（見6.6.2、6.6.3、6.6.4）可以和加密證書申請組合在一起（見6.6.9）。在這樣的情況下，CertReqMessages包括了兩個CertReqMessage的序列。一個CertReqMessage等同于RA發起的注冊請求和自我注冊請求的情況，另一個CertReqMessage等同于加密證書申請的情況。消息使用了簽名證書申請的方式來加以保護。
如果組合申請中包括的是自我注冊請求，則要么簽名密鑰證書申請成功，要么兩個證書的申請都不成功。如果還需要額外的信息來提供pop，申請者則使用自我注冊請求中的私鑰來對消息做簽名。
簽名密鑰的pop將使用pop域來實現（見6.6.2、6.6.3和6.6.6）。集中產生密鑰對申請，私鑰應該使用6.6.8中描述的方式進行加密。CA的響應按照響應部分的說明。CA響應可以是組成一個CertRepMessage，或者是分開。申請者使用CertReqID來區分CA的響應。
響應消息的PKIFreeText域可以用來提供額外的信息。
收到kp的時候，證書持有者應該產生PKIConfirm消息。PKIHeader中的信息和利用RA向CA申請證書的情況下的PKIHeader一致，除了messageTime是當前時間。

6.6.10　從資料庫請求證書

實體可以使用LDAP V2（見RFC 2559）向資料庫請求證書。當使用LDAP時，實體可以通過LDAP搜索請求（定義見RFC 2559）從資料庫中請求證書，或是利用給定的LDAP URL （見RFC1959）來請求證書（即authorityInformationAccess擴展）。

6.6.11　從資料庫請求CRL

實體可以使用LDAP V2（見RFC 2559）向資料庫請求CRLs。實體可以使用LDAP（見RFC1777）從資料庫中請求CRLs。當使用LDAP時，實體可以通過LDAP搜索請求（定義見RFC 2559和 RFC1777）從資料庫中請求CRLs，或是利用給定的LDAP URL（見RFC1959）來請求CRLs（即，cRLDistributionPoints 擴展中的 distributionPoint 字段）。