1GB/T19771—XXXX網(wǎng)絡(luò)安全技術(shù)公鑰基礎(chǔ)設(shè)施PKI組件最小互操作規(guī)范本文件規(guī)定了公鑰基礎(chǔ)設(shè)組件最小互操作的基本功能要求和數(shù)據(jù)格式要求，給出了測試評價(jià)方法。本文件適用于電子簽名、電子簽章、身份管理等中的PKI的設(shè)計(jì)、開發(fā)、測試及其應(yīng)用。2規(guī)范性引用文件下列文件中的內(nèi)容通過文中的規(guī)范性引用而構(gòu)成本文件必不可少的條款。其中，注日期的引用文件，僅該日期對應(yīng)的版本適用于本文件；不注日期的引用文件，其最新版本（包括所有的修改單）適用于本文件。GB/T15852.2信息技術(shù)安全技術(shù)消息鑒別碼第2部分：采用專門設(shè)計(jì)的雜湊函數(shù)的機(jī)制GB/T16262.1信息技術(shù)抽象語法記法GB.T19714-XXXX網(wǎng)絡(luò)安全技術(shù)公鑰基礎(chǔ)設(shè)施證書管理協(xié)議GB/T20518-2018信息安全技術(shù)公鑰基礎(chǔ)設(shè)施數(shù)字證書格式GB/T32905-2016信息安全技術(shù)SM3密碼雜湊算法GB/T32907-2016信息安全技術(shù)SM4分組密碼算法GB/T32918.2-2016信息安全技術(shù)SM2橢圓曲線公鑰密碼算法第2部分：數(shù)字簽名算法GB/T37092-2018信息安全技術(shù)密碼模塊安全要求3術(shù)語和定義下列術(shù)語和定義適用于本文件。3.1公鑰基礎(chǔ)設(shè)施publickeyinfrastructure基于公鑰密碼技術(shù)，具有普適性，可用于提供保密性、完整性、真實(shí)性及抗抵賴性等安全服務(wù)的基礎(chǔ)設(shè)施。[來源：GM/Z4001-2013，2.29，有修改]3.2數(shù)字證書digitalcertificate也稱公鑰證書，由證書認(rèn)證機(jī)構(gòu)對用戶的公鑰和身份信息進(jìn)行確認(rèn)，并用私鑰進(jìn)行簽名的數(shù)據(jù)。3.3加密證書enciphermentcertificate用于證明加密公鑰的數(shù)字證書。[來源：GM/Z4001-2013，2.43，有修改]3.4證書認(rèn)證機(jī)構(gòu)CertificateAuthority負(fù)責(zé)創(chuàng)建和頒發(fā)證書，受用戶信任的權(quán)威機(jī)構(gòu)。2GB/T19771—XXXX3.5注冊機(jī)構(gòu)RegistrationAuthority為用戶辦理證書申請、身份審核、證書下載、證書更新、證書注銷以及密鑰恢復(fù)等實(shí)際業(yè)務(wù)的辦事機(jī)構(gòu)或業(yè)務(wù)受理點(diǎn)。3.6證書持有者certificateholder與有效證書的主體相對應(yīng)的實(shí)體。3.7證書使用者certificateuser需要獲取另一實(shí)體的公鑰，并利用PKI獲取證書并執(zhí)行驗(yàn)證證書和簽名功能的實(shí)體。3.8資料庫repository存儲(chǔ)數(shù)字證書和CRL等信息，并提供無需驗(yàn)證的信息檢索服務(wù)的數(shù)據(jù)庫。3.9證書策略certificatepolicy預(yù)先定義的界定證書的通用安全要求和適用范圍的一組規(guī)則集。3.10認(rèn)證業(yè)務(wù)聲明CertificationPracticeStatement證書認(rèn)證機(jī)構(gòu)頒發(fā)某證書策略的證書時(shí)遵循的相關(guān)業(yè)務(wù)操作的聲明。3.11證書認(rèn)證路徑certificationpath基于起始可信證書的有序證書序列。注：通過處理該有序序列及其起始對象的公鑰能得知該3.12證書撤銷列表CertificateRevocationList列出一組證書發(fā)布者認(rèn)為無效的已簽名列表。4縮略語下列縮略語適用于本文件。BYOD：自帶設(shè)備（BringYourOwnDevice）CA：證書認(rèn)證機(jī)構(gòu)（CertificateAuthority）CRL：證書撤銷列表（CertificateRevocationList）LDAP：輕量級目錄訪問協(xié)議（LightweightDirectoryAccessProtocol）PKCS：公鑰密碼學(xué)標(biāo)準(zhǔn)（PublicKeyCryptographyStandard）PKI：公鑰基礎(chǔ)設(shè)施（PublicKeyInfrastructure）RA：注冊機(jī)構(gòu)（RegistrationAuthority）5基本功能要求5.1概述本文件描述的PKI系統(tǒng)由四個(gè)需要互相通信的組件構(gòu)成，分別是：--負(fù)責(zé)頒發(fā)和撤銷證書的CA；3GB/T19771—XXXX--確保公鑰和證書持有者的身份以及別的屬性之間綁定的RA；--獲得證書和簽署文檔的證書持有者；--驗(yàn)證簽名并且執(zhí)行密鑰管理協(xié)議以及驗(yàn)證證書認(rèn)證路徑的證書使用者。這四個(gè)組件分別提供不同的功能，但一個(gè)實(shí)體可以承擔(dān)多個(gè)組件的角色。CA可以也是RA。在功能上是證書持有者的實(shí)體也是證書使用者，證書使用者可以不是證書持有者。本文件描述的互操作指的是PKI組件之間通過互相通信和協(xié)作，共同完成PKI功能的操作。最小互操作指的是PKI組件為了實(shí)現(xiàn)證書注冊、證書更新、證書撤銷、資料庫訪問等PKI基本功能所需要的最低限度的互操作。文本描述的最小互操作的基本功能要求指的是這些組件為了實(shí)現(xiàn)基本的PKI功能，所必須具備的基本功能集合。5.2CACA應(yīng)支持以下功能：--頒發(fā)并傳送證書給終端實(shí)體和其他的CA；--接收來自RA的證書撤銷請求；--將證書和CRL存入資料庫；--為下級CA頒發(fā)證書。CA生成自己的公私鑰對并公布自己的證書，CA生成、估定相應(yīng)的參數(shù)以便生成/驗(yàn)證所頒發(fā)證書的簽名。CA授權(quán)RA去確認(rèn)申請證書的使用者的身份或其他的特征屬性。授權(quán)通過離線接受來自某個(gè)RA的證書請求完成。CA具備5.4中證書持有者的功能：請求、撤銷、更新由其他CA頒發(fā)的證書；也具備5.5中證書使用者的功能：檢索證書和CRL、驗(yàn)證證書認(rèn)證路徑。CA與其他組件進(jìn)行互操作時(shí)，基本功能要求為：a)頒發(fā)數(shù)字簽名證書CA應(yīng)支持兩種數(shù)字簽名證書的證書請求：RA發(fā)起的注冊請求和自我注冊請求。根據(jù)不同類型，CA采用不同方式鑒別申請證書主體的身份。1）RA發(fā)起的證書請求。RA應(yīng)確保用戶身份與公鑰的綁定。CA處理來自經(jīng)授權(quán)的RA的證書請求。如請求被接受，CA生成新證書并存儲(chǔ)在資料庫中，然后將該證書發(fā)給相應(yīng)的RA或證書持有者。如請求由非經(jīng)授權(quán)的RA發(fā)送，即簽名無效或信息不匹配，CA拒絕請求并向RA報(bào)告失敗并說明原因。CA應(yīng)至少能支持GB/T20518-2018中定義的頒發(fā)機(jī)構(gòu)密鑰標(biāo)識(shí)符（authorityKeyIdentifiers）、主體密鑰標(biāo)識(shí)符（subjectKeyIdentifier）、基本限制（basicConstraints）、密鑰用法（keyUsage）、證書策略（certificatePolicies）等擴(kuò)展。2）自我注冊請求。RA為提交請求的實(shí)體提供一份秘密信息。請求實(shí)體生成公私鑰對，創(chuàng)建證書請求消息并使用相應(yīng)私鑰簽名，被簽名的部分包括基于RA提供的秘密信息導(dǎo)出的認(rèn)證信息。CA接收請求，通過認(rèn)證信息驗(yàn)證請求者身份，并確認(rèn)其實(shí)體擁有私鑰。若驗(yàn)證成功，CA生成新證書并存入資料庫，隨后發(fā)送至證書持有者。若驗(yàn)證失敗、簽名無效或信息不匹配，CA拒絕請求并向申請者報(bào)告失敗原因。b)頒發(fā)加密證書CA應(yīng)支持實(shí)體進(jìn)行加密證書的申請。CA處理來自授權(quán)的RA的加密證書的請求。如請求被接受，CA驗(yàn)證響應(yīng)證書申請，用戶的加解密公私鑰對可由第三方產(chǎn)生，CA通過安全的方式獲得加密公鑰和用戶加密私鑰數(shù)據(jù)信封。CA頒發(fā)加密證書并存儲(chǔ)在資料庫中，并將該證書和加密私鑰數(shù)據(jù)信封返回給相應(yīng)的RA或證書持有者。c)交叉認(rèn)證4GB/T19771—XXXXCA應(yīng)具備向其他CA頒發(fā)證書的能力。交叉認(rèn)證決策通過物理形式進(jìn)行，并應(yīng)按照與證書策略相關(guān)的認(rèn)證業(yè)務(wù)聲明進(jìn)行安全可信檢查。CA應(yīng)對頒發(fā)的交叉證書的路徑驗(yàn)證做出適當(dāng)約束，應(yīng)將basicConstraints、nameConstraints和policyConstraints設(shè)置為關(guān)鍵擴(kuò)展并配置相應(yīng)約束條件，包括路徑長度的約束。如未設(shè)置這些擴(kuò)展或不進(jìn)行路徑驗(yàn)證約束，即允許對方CA無限制地進(jìn)行簽名傳遞，即，頒發(fā)交叉證書的CA應(yīng)承擔(dān)其證書策略對應(yīng)的認(rèn)證業(yè)務(wù)聲明中承諾的全部責(zé)任，包括給其他無關(guān)CA頒發(fā)的所有證書的責(zé)任。d）證書更新請求申請者通過其原有私鑰對更新請求消息進(jìn)行簽名以完成身份驗(yàn)證。CA處理證書更新請求，若簽名有效，則頒發(fā)新證書給證書持有者并存入資料庫。若簽名無效、請求實(shí)體處于非法狀態(tài)或更新請求不符合CA認(rèn)證業(yè)務(wù)聲明或證書策略，CA拒絕該請求。e)證書撤銷CA應(yīng)按照相關(guān)書策略對應(yīng)的認(rèn)證業(yè)務(wù)聲明，按時(shí)生成和發(fā)布包含所有被撤銷但尚未到期的證書的完整證書撤銷列表(CRL)。頒發(fā)CRL的形式和周期由相關(guān)證書策略對應(yīng)的認(rèn)證業(yè)務(wù)聲明決定。f)為下級CA頒發(fā)證書CA應(yīng)能向?qū)哟胃叩腃A申請證書。在生成證書請求時(shí)，應(yīng)使用basicConstraints擴(kuò)展來明確該請求來自一個(gè)CA實(shí)體。在頒發(fā)下級CA證書時(shí)，應(yīng)在證書中明確授權(quán)的證書策略、層級限制以及名稱限制。如缺少這些擴(kuò)展，或者這些擴(kuò)展存在但被設(shè)置為非關(guān)鍵項(xiàng)，則上級CA應(yīng)對下級CA頒發(fā)的所有證書承擔(dān)與證書策略對應(yīng)的認(rèn)證業(yè)務(wù)聲明中所承諾的所有的法律責(zé)任。5.3RA5.3.1與互操作性有關(guān)的功能要求RA應(yīng)支持以下功能：——接受和驗(yàn)證證書請求；——向CA發(fā)送證書請求；——生成證書撤銷請求。RA與其他組件進(jìn)行互操作時(shí)，基本功能要求為：a）當(dāng)物理證書介質(zhì)與RA進(jìn)行物理連接時(shí)，RA通過驗(yàn)證簽名消息來驗(yàn)證該介質(zhì)中擁有與公鑰相應(yīng)的私鑰材料(見6.5.2)。在密鑰對和實(shí)體身份均經(jīng)過驗(yàn)證之后，RA簽署并向相應(yīng)的CA發(fā)送電子證書請求。b）未與RA進(jìn)行過物理接觸的證書請求者，在發(fā)起證書請求時(shí)，應(yīng)持有RA提供的認(rèn)證信息。此信息將作為實(shí)體在自我注冊請求中向CA證明其身份的證據(jù)。c）RA應(yīng)支持對CA授權(quán)其所管理的實(shí)體證書請求進(jìn)行證書撤銷操作。該功能可與CA集成，也可在不同的設(shè)施中執(zhí)行。d）RA應(yīng)將新頒發(fā)的證書與CA的證書一同發(fā)送給證書持有者。e）RA應(yīng)代表不再擁有私鑰并且懷疑該私鑰已泄露的證書持有者產(chǎn)生并簽署證書撤銷請求。如果CA的認(rèn)證業(yè)務(wù)聲明允許，RA應(yīng)代表證書持有者的組織產(chǎn)生并簽署證書撤銷請求。5.3.2使用BYOD請求證書的RA功能要求RA應(yīng)驗(yàn)證BYOD設(shè)備的密碼模塊是否符合GB/T37092-2018的要求。RA應(yīng)鑒別密碼模塊的安全等級是否與認(rèn)證業(yè)務(wù)聲明一致。5.4證書持有者5.4.1與互操作性相關(guān)的功能要求5GB/T19771—XXXX證書持有者包括CA、RA和其他的終端實(shí)體。終端實(shí)體是個(gè)人、企業(yè)、用戶、計(jì)算機(jī)系統(tǒng)、或應(yīng)用程序(CA和RA除外)。證書持有者應(yīng)包括以下功能：——生成簽名；——生成證書注冊請求；——生成證書撤銷請求；——生成證書更新請求。證書持有者同時(shí)也是證書使用者，具備5.5中定義證書使用者的功能。5.4.2證書持有者的BYOD功能要求證書持有者BYOD作為證書介質(zhì)申請或使用證書服務(wù)時(shí)，該設(shè)備應(yīng)安裝有符合GB/T37092-2018的密碼模塊并具備未被破壞的可信啟動(dòng)。該設(shè)備也應(yīng)具備數(shù)字證書展示和通信能力，如，使用二維碼交換證書和簽名。BYOD設(shè)備不應(yīng)要求物理接入他人的設(shè)備進(jìn)行證書展示和驗(yàn)證。5.5證書使用者5.5.1與互操作性有關(guān)的功能要求證書使用者是使用證書的實(shí)體，包括CA、RA、個(gè)人、企業(yè)、用戶和計(jì)算機(jī)系統(tǒng)。證書使用者應(yīng)包括以下功能：——驗(yàn)證證書；——從查詢服務(wù)器中檢索證書和CRL;——驗(yàn)證證書認(rèn)證路徑。具有證書持有者身份的證書使用者也能產(chǎn)生簽名、支持撤銷或更新證書。5.5.2驗(yàn)證證書的最小步驟要求證書使用者應(yīng)能獲得從信任起點(diǎn)開始的完整的證書路徑。信任起點(diǎn)可以是預(yù)埋的根證書，也可以是預(yù)埋的CA證書，也可以是經(jīng)過驗(yàn)證后緩存的可信CA的證書。證書使用者應(yīng)從信任起點(diǎn)的證書開始，針對每個(gè)證書，逐一完成以下驗(yàn)證：a)驗(yàn)證證書基本信息。1)使用頒發(fā)該證書的CA的公鑰驗(yàn)證簽名；2)驗(yàn)證有效期；3)驗(yàn)證證書是否被撤銷；4)驗(yàn)證證書頒發(fā)者的名稱。b)驗(yàn)證關(guān)鍵證書擴(kuò)展。c)如果證書是自簽名證書，且不是路徑中的最終證書，跳過本步驟。否則，驗(yàn)證主體名稱是否在頒發(fā)該證書的CA證書中的nameContraints擴(kuò)展（如適用）中一個(gè)允許的子樹中，并驗(yàn)證subjectAltName擴(kuò)展中的每個(gè)替代名稱（關(guān)鍵或非關(guān)鍵）是否在該名稱類型的一個(gè)允許的子樹中。d)如果證書是自簽名證書，且不是驗(yàn)證路徑中的最終證書，跳過本步驟。否則，驗(yàn)證主體名稱不在頒發(fā)該證書的CA證書中的nameContraints擴(kuò)展（如適用）中的任何排除子樹中，并驗(yàn)證subjectAltName擴(kuò)展中的每個(gè)替代名稱（關(guān)鍵或非關(guān)鍵）不在該名稱類型的任何排除子樹中。e)如果有證書策略（certificatePolicies）擴(kuò)展，驗(yàn)證該擴(kuò)展是否使用符合預(yù)期的策略。任何未通過都表示該證書不能被信任。5.6密碼算法6GB/T19771—XXXX本文件的PKI組件使用四類算法：密碼雜湊函數(shù)、數(shù)字簽名算法、消息鑒別碼算法和對稱加密算法。PKI組件使用密碼算法的總體安全要求如下：a）一個(gè)PKI組件應(yīng)實(shí)現(xiàn)一個(gè)數(shù)字簽名算法，其他組件應(yīng)能夠產(chǎn)生和驗(yàn)證由其中一個(gè)算法生成的簽名；b）組件應(yīng)支持一個(gè)加密算法。對四類算法的要求如下：c）應(yīng)支持GB/T32905-2016規(guī)定的SM3密碼雜湊算法；d）應(yīng)支持GB/T32918.2-2016規(guī)定的SM2數(shù)字簽名算法；e）應(yīng)支持GB/T15852.2規(guī)定的MAC算法2（HMAC）；f）應(yīng)支持GB/T32907-2016規(guī)定的SM4分組密碼算法。6數(shù)據(jù)格式要求6.1數(shù)字證書證書的數(shù)據(jù)結(jié)構(gòu)、證書擴(kuò)展、證書撤銷列表應(yīng)符合GB/T20518-2018的要求。6.2PKI事務(wù)消息內(nèi)容6.2.1總體要求PKI事務(wù)包括：注冊請求、更新證書、撤銷證書、訪問目錄服務(wù)。CA、RA和證書持有者應(yīng)能實(shí)現(xiàn)這些事務(wù)。PKI事務(wù)的消息格式應(yīng)符合GB/T19714-XXXX第6章的要求。對于CA和RA物理上在一起且不支持遠(yuǎn)端RA的PKI產(chǎn)品，可忽略CA和RA之間的消息交互。6.2.2注冊請求6.2.2.1RA發(fā)起的注冊請求RA請求CA為一個(gè)終端實(shí)體頒發(fā)簽名證書，終端實(shí)體通過物理方式(如，提交實(shí)體U盤)，在簽名消息中向RA提供其公鑰。RA產(chǎn)生認(rèn)證請求，利用簽名消息保護(hù)請求，向CA為終端實(shí)體申請證書。CA產(chǎn)生響應(yīng)并發(fā)送給RA，響應(yīng)消息中包含證書或錯(cuò)誤代碼的簽名。RA通過物理形式向終端實(shí)體提供CA的公鑰和所頒發(fā)的證書，終端實(shí)體也可以直接從CA獲得證書。在這個(gè)過程中包括三條消息：a)從RA到CA的證書請求RA建立證書請求的PKIMessage，并發(fā)送給CA，其PKIBody的請求代碼為cr。其中，PKIHeader的sender是RA的可辨別名，recipient是CA的可辨別名。PKIBody是CertReqMessages,是一個(gè)CertReqMessage字段的序列，應(yīng)包括如下信息：certReq含有請求者希望包含在證書中的信息；pop證明了對新證書私鑰的擁有。本文件只支持終端實(shí)體產(chǎn)生簽名密鑰對，不支持終端實(shí)體產(chǎn)生加密密鑰對。在進(jìn)行簽名私鑰的擁有性證明時(shí)，如果由RA來實(shí)現(xiàn)，RA修改了主體名，popoSKInput域出現(xiàn)，并且包含了原來的主體名。否則，RA不修改主體名，pop域與請求者提交的主體名一致。與證書內(nèi)容相關(guān)的信息放入為CertRequest的certReq中。PKIProtection字段含有根據(jù)消息頭和消息體的DER編碼序列計(jì)算的RA的簽名。b)從CA到RA的證書響應(yīng)CA返回證書響應(yīng)請求的PKIMessage給RA，其PKIBody的響應(yīng)代碼為cp。其中PKIHeader的sender是CA的可辨別名，recipient是RA的可辨別名。如果在證書請求中提供了senderNonce，響應(yīng)的PKIHeader應(yīng)7GB/T19771—XXXX將其作為recipNonce。PKIBody是CertRepMessage，CertRepMessage含有唯一的response字段，是包含certReqld、status和certifiedKeyPair的序列。如果CA頒發(fā)了一張證書，PKIBody應(yīng)含有如下信息：certReqld與請求中的certReqId匹配；status是granted或者是grantedWithMods;certifiedKeyPair序列至少含有一個(gè)字段certificate。證書應(yīng)滿足如下性質(zhì)：version號應(yīng)是v3(2);publicKey字段應(yīng)與證書請求中相同或者是由CA所產(chǎn)生的公鑰；主體可辨別名應(yīng)與證書請求中相同；頒發(fā)者名字應(yīng)是CA的可辨別名；如果notBefore出現(xiàn)在證書請求中，證書應(yīng)從頒發(fā)日和notBefore所指之日的較晚者之后生如果notAfter出現(xiàn)在證書請求中，證書應(yīng)在該日或之前期滿。證書應(yīng)包括如下擴(kuò)展(extensions):subjectKeyIdentifier域；在certificatePolicies字段中至少包括一個(gè)證書策略的OID;authorityKeyIdentifier域。如果status是granted和grantedWithMods,faillnfo字段可不存在。如果CA拒絕了請求，PKIBody應(yīng)含有如下信息：status是rejected;failInfo包含適當(dāng)?shù)腻e(cuò)誤代碼。如果status是rejected,certifiedKeyPair字段可以不出現(xiàn)。PKIProtection字段含有根據(jù)消息頭和消息體的DER編碼序列計(jì)算的CA的簽名。6.2.2.2新實(shí)體的自我注冊請求如果新實(shí)體尚未從某一特定CA獲取證書，可直接向該CA申請一張新的證書。在申請過程中，請求實(shí)體生成一個(gè)請求代碼為ir的PKIMessage以請求新證書，該消息中包含對所請求證書中公鑰相對應(yīng)的私鑰的擁有證明。實(shí)體利用RA提供的一個(gè)秘密密鑰和消息鑒別碼算法對PKIMessage進(jìn)行保護(hù)。如果CA接受自我注冊請求，向證書持有者返回一個(gè)響應(yīng)代碼為ip的PKIMessage。該消息包含證書或者事務(wù)出錯(cuò)的原因代碼。a)RA與實(shí)體之間的事務(wù)RA給實(shí)體發(fā)送一個(gè)共享的秘密密鑰。通過從該共享秘密中生成消息鑒別碼，CA對實(shí)體進(jìn)行認(rèn)證。本文件不指定該事務(wù)明確的內(nèi)容和格式。但是，秘密密鑰和CA的公鑰信息應(yīng)以可信方式傳遞給實(shí)體。b)從證書持有者到CA的自我注冊請求請求者建立一個(gè)PKIMessage，其PKIBody的請求代碼為ir。PKIHeader的sender是請求者的可辨別名，recipient是CA的可辨別名。PKIBody是CertReqMessages,是一個(gè)CertReqMessage字段的序列。CertReqMessage包括如下信息：certReq含有請求者希望包含在證書中的信息；popoSKInput包含公鑰的MAC值；pop證明了對證書私鑰的擁有。其中pop域通過與CertTemplate中的公鑰相對應(yīng)的私鑰來產(chǎn)生，產(chǎn)生pop的輸入數(shù)據(jù)包括popoSKInput中的公鑰MAC值和CertTemplate中的公鑰。與證書內(nèi)容相關(guān)的信息放入為CertRequest的certReq中。8GB/T19771—XXXXPKIProtection域包含一個(gè)請求者利用從RA獲得的秘密產(chǎn)生的值。c)從CA到證書請求者的自我注冊請求的響應(yīng)CA返回證書響應(yīng)請求的PKIMessage給證書持有者，其PKIBody的響應(yīng)代碼為ip。其中，PKIBody的sender是CA的可辨別名，recipient是證書請求消息頭中sender域的值。如果在證書請求中提供了transactionID,響應(yīng)的PKIHeader中包括同樣的transactionID。如果在證書請求中提供了senderNonce，響應(yīng)的PKIHeader應(yīng)將其作為recipNonce。PKIBody是CertRepMessage。如果CA頒發(fā)了一張證書，PKIBody應(yīng)含有如下信息：status是granted或者是grantedWithMods;certificate包含新的證書。如果status是granted和grantedWithMods,faillnfo字段可以不存在。如果CA拒絕了請求，PKIBody應(yīng)含有如下信息：status是rejected;failInfo包含適當(dāng)?shù)腻e(cuò)誤代碼。如果status是rejected,certificate域可能不存在。證書應(yīng)包括如下擴(kuò)展(extensions):subjectKeyIdentifier域；在certificatePolicies字段中至少包括一個(gè)證書策略的OID;authorityKeyIdentifier域。PKIProtection字段含有根據(jù)消息頭和消息體的DER編碼序列計(jì)算的CA的簽名。6.2.2.3已知實(shí)體的自我注冊請求如果某一實(shí)體并非當(dāng)前證書持有者，但是先前曾從特定CA獲得過證書，該實(shí)體可直接向該CA提出新證書的申請。在申請過程中，請求實(shí)體生成請求代碼為cr的PKIMessage以請求新證書，該消息中包含與證書請求中公鑰所對應(yīng)的私鑰的擁有證明。實(shí)體利用RA提供的一個(gè)秘密密鑰和消息鑒別碼算法PKIMessage進(jìn)行保護(hù)。。如果CA接受自我注冊請求，向證書持有者返回一個(gè)響應(yīng)代碼為cp的PKIMessage。該消息包含證書或者事務(wù)出錯(cuò)的原因代碼。a)RA與實(shí)體的事務(wù)RA給實(shí)體發(fā)送一個(gè)共享的秘密密鑰。CA通過從共享的秘密中產(chǎn)生的消息鑒別碼，對實(shí)體進(jìn)行認(rèn)證。本文件不指定該事務(wù)明確的內(nèi)容和格式。但是，秘密密鑰和CA的公鑰信息應(yīng)以可信方式傳遞給實(shí)體。b)從證書持有者到CA的自我注冊請求請求者建立一個(gè)PKIMessage，其PKIBody的請求代碼為cr。PKIHeader的sender是請求者的可辨別名，recipient是CA的可辨別名。PKIBody是CertReqMessages,是一個(gè)CertReqMessage字段的序列。CertReqMessage包括如下信息：certReq含有請求者希望包含在證書中的信息；popoSKInput包含公鑰的MAC值；pop證明了對證書私鑰的擁有。其中pop域通過與CertTemplate中的公鑰相對應(yīng)的私鑰來產(chǎn)生，產(chǎn)生pop的輸入數(shù)據(jù)包括popoSKInput中的公鑰MAC值和CertTemplate中的公鑰。與證書內(nèi)容相關(guān)的信息放入為CertRequest的certReq中。PKIProtection域包含一個(gè)請求者利用從RA獲得的秘密產(chǎn)生的值。c)從CA到證書請求者的自我注冊請求的響應(yīng)9GB/T19771—XXXXCA返回證書響應(yīng)請求的PKIMessage給證書持有者，其PKIBody的響應(yīng)代碼為cp。其中，PKIBody的sender是CA的可辨別名，recipient是證書請求消息頭中sender域的值。如果在證書請求中提供了transactionID,響應(yīng)的PKIHeader中包括同樣的transactionID。如果在證書請求中提供了senderNonce，響應(yīng)的PKIHeader應(yīng)將其作為recipNonce。PKIBody是CertRepMessage。如果CA頒發(fā)了一張證書，PKIBody應(yīng)含有如下信息：status是granted或者是grantedWithMods;certificate包含新的證書。如果status是granted和grantedWithMods,faillnfo字段可以不存在。如果CA拒絕了請求，PKIBody應(yīng)含有如下信息：status是rejected;failInfo包含適當(dāng)?shù)腻e(cuò)誤代碼。如果status是rejected,certificate域可能不存在。證書應(yīng)包括如下擴(kuò)展(extensions):subjectKeyIdentifier域；在certificatePolicies字段中至少包括一個(gè)證書策略的OID;authorityKeyIdentifier域。PKIProtection字段含有根據(jù)消息頭和消息體的DER編碼序列計(jì)算的CA的簽名。6.2.2.4加密證書申請擁有當(dāng)前有效證書的PKI實(shí)體可向該證書的頒發(fā)CA提出申請，申請產(chǎn)生加密密鑰對并頒發(fā)相應(yīng)的證書。發(fā)出申請的實(shí)體產(chǎn)生臨時(shí)的密鑰管理密鑰，并生成請求代碼為cr的PKIMessage，以申請密鑰管理證書，PKIMessage中包括了臨時(shí)的密鑰管理密鑰。利用當(dāng)前有效證書的對應(yīng)私鑰，對PKIMessage進(jìn)行簽名并發(fā)送給CA。如果CA的CPS支持集中產(chǎn)生加密密鑰對，則CA執(zhí)行如下操作：--CA按請求消息的要求產(chǎn)生密鑰對，頒發(fā)加密證書；--CA產(chǎn)生對稱密鑰，利用對稱密鑰加密新產(chǎn)生的私鑰，使用臨時(shí)公鑰加密對稱密鑰，產(chǎn)生和返回響應(yīng)消息給證書持有者。響應(yīng)消息中包括了新生成的證書和加密后的私鑰，或者是事務(wù)失敗的代碼。用戶的加解密公私鑰對也可由可信第三方（如，密鑰管理系統(tǒng)）產(chǎn)生，應(yīng)采用符合GB/T19714-XXXX中7.5節(jié)規(guī)定的協(xié)議和消息格式獲得產(chǎn)生的公鑰和加密私鑰數(shù)字信封。CA頒發(fā)加密證書并存儲(chǔ)在資料庫中，并將該證書和以用戶公鑰保護(hù)的加密私鑰返回給相應(yīng)的RA或證書持有者。6.2.2.5組合證書申請簽名密鑰證書和密鑰管理密鑰證書的申請可以由一次事務(wù)完成。RA發(fā)起的注冊請求和自我注冊請求(見6.2.2.1、6.2.2.2、6.2.2.3)可以和加密證書申請（見6.2.2.4）組合在一起。在此情況下，CertReqMessages包括了兩個(gè)CertReqMessage的序列。一個(gè)CertReqMessage等同于RA發(fā)起的注冊請求和自我注冊請求的情況，另一個(gè)CertReqMessage等同于加密證書申請的情況。消息使用了簽名證書申請的方式來加以保護(hù)。如果組合申請中包括的是自我注冊請求，則要么簽名密鑰證書申請成功，要么兩個(gè)證書的申請都不成功。如果還需要額外的信息來提供pop,申請者則使用自我注冊請求中的私鑰來對消息做簽名。6.2.3證書更新GB/T19771—XXXX擁有當(dāng)前有效(指在有效期內(nèi)、未被撤銷)證書的PKI實(shí)體可直接向該證書的頒發(fā)CA要求頒發(fā)一份新的證書。PKI實(shí)體生成請求代碼為kr的PKIMessage，包括證書申請和相應(yīng)的pop。證書持有者使用有效證書的對應(yīng)私鑰對該P(yáng)KIMessage進(jìn)行簽名。如果CA的CPS支持證書更新，則CA返回請求代碼為kp的PKIMessage，包含新生成的證書或者是事務(wù)失敗的代碼。如果新證書成功生成，則還有兩個(gè)可選的消息。分別是：PKI實(shí)體在收到新的證書后給CA發(fā)出確認(rèn)，CA響應(yīng)確認(rèn)消息。a)從證書持有者到CA的證書更新申請證書持有者建立一個(gè)PKIMessage，其PKIBody的請求代碼為kr。PKIHeader的sender是證書持有者的可辨別名，recipient是CA的可辨別名。PKIBody是CertReqMessages,是一個(gè)CertReqMessage字段的序列。CertReqMessage包括如下信息：certReq包含了申請者要求包括在證書中的各種信息；pop是新證書公鑰的對應(yīng)的pop證明。pop應(yīng)由publicKey域的公鑰對應(yīng)的私鑰產(chǎn)生。CertReq的publicKey域是新證書的公鑰。如果消息中沒有signingAlg,CA應(yīng)使用終端實(shí)體的公鑰對應(yīng)的算法簽名。PKIProtection域是使用當(dāng)前有效證書的對應(yīng)私鑰對消息頭和消息體的DER編碼信息的簽名結(jié)果。b)從CA到證書持有者的證書更新響應(yīng)CA返回證書更新響應(yīng)請求的PKIMessage給證書持有者，其PKIBody的響應(yīng)代碼為kp。其中，PKIBody的sender是CA的可辨別名，recipient是證書請求消息頭中sender域的值。如果在證書請求中提供了transactionID,響應(yīng)的PKIHeader中包括同樣的transactionID。如果在證書請求中提供了senderNonce，響應(yīng)的PKIHeader應(yīng)將其作為recipNonce。PKIBody是CertRepMessage。如果CA頒發(fā)了新證書，PKIBody應(yīng)含有如下信息：status是granted或者是grantedWithMods;certificate包含新的證書。如果status是granted和grantedWithMods,faillnfo字段可以不存在。如果CA拒絕了請求，PKIBody應(yīng)含有如下信息：status是rejected；failInfo包含適當(dāng)?shù)腻e(cuò)誤代碼。如果status是rejected,certificate域可能不存在。證書應(yīng)包括如下擴(kuò)展(extensions)：subjectKeyIdentifier域；在certificatePolicies字段中至少包括一個(gè)證書策略的OID;authorityKeyIdentifier域。PKIProtection字段含有根據(jù)消息頭和消息體的DER編碼序列計(jì)算的CA的簽名。6.2.4撤銷請求證書持有者可以請求撤銷自己的證書。證書持有者產(chǎn)生RevReq消息，對該消息進(jìn)行簽名并發(fā)送給相應(yīng)RA,并在RA審查通過用戶的身份后向CA發(fā)出相應(yīng)撤銷信息。該簽名必須用未過期、未被撤銷的簽名證書的相應(yīng)私鑰產(chǎn)生(可為要撤銷的證書)。RevReq消息要標(biāo)識(shí)出想撤銷的證書以及要撤銷的原因。CA回應(yīng)RA一個(gè)RevRep消息，RA再回應(yīng)證書持有者相應(yīng)的RevRep消息。如果消息rr(RevReq)中包含transactionID,則CA和RA所響應(yīng)的rp(RevRep)消息中也應(yīng)包含相同的transactinID,注意其中從證書持有者所發(fā)出的rr和RA所發(fā)出的rr消息中的transactinID可以不同。rp消息至少要包含status字段以反映請求的狀態(tài)和revCerts字段以表示將撤銷的證書。GB/T19771—XXXXa)從證書持有者到RA的撤銷請求證書持有者建立一個(gè)PKIMessage，其PKIBody的請求代碼為rr。PKIHeader的sender是證書持有者的可辨別名，recipient是RA的可辨別名。PKIBody是RevReqContent,是RevDetails的序列，由CertDetails和三個(gè)可選字段組成的序列：原因標(biāo)志、懷疑或丟失的日期和時(shí)間、crlEntryDetails(CRLEntry擴(kuò)展的序列)。CertDetails最少包括以下信息：serial證書序列號；issuer證書發(fā)放者的標(biāo)識(shí)名。或是subject證書持有者的標(biāo)識(shí)名；issuer證書發(fā)放者的標(biāo)識(shí)名。CertDetails還可在extensions字段中包含subjectKeyldentifier。(如果請求者希望撤銷頒發(fā)給某個(gè)主體的所有證書，CertDetails應(yīng)僅含有subject和issuer。即，僅希望撤銷單個(gè)證書的請求只含有相應(yīng)的序列號或是subjectKeyldentifier)。RevDetails應(yīng)包括帶有reasonCode擴(kuò)展的crlEntryDetails,也可包括invalidityDate擴(kuò)展來說明何時(shí)該證書作廢。原因代碼也可不是removeFromCRL。PKIProtection字段含有請求者的簽名，即消息頭和消息體的DER編碼進(jìn)行簽名。終端實(shí)體用相應(yīng)CA所頒發(fā)的當(dāng)前有效簽名證書的相應(yīng)私鑰進(jìn)行簽名。b)從RA到CA的撤銷請求RA或證書持有者生成包含PKIBody元素rr的PKIMessage。PKIHeader包含以下信息：pvno是103；transactionlD標(biāo)識(shí)RA名一起唯一標(biāo)識(shí)一個(gè)RA與CA之間事務(wù)的整數(shù)；messageTime為當(dāng)前精確到秒的時(shí)間；sender為RA的可辨別名；recipient為CA的可辨別名；protectionAlg為保護(hù)消息而使用的簽名算法標(biāo)識(shí)符。消息體與從證書持有者到RA的撤銷請求相同。PKIProtection字段含有RA的簽名，即對頭和正文的DER編碼進(jìn)行簽名。RA要用相應(yīng)CA所頒發(fā)的當(dāng)前有效簽名證書的相應(yīng)私鑰進(jìn)行簽名。c)從CA到RA的撤銷響應(yīng)CA返回證書更新響應(yīng)請求的PKIMessage給證書持有者，其PKIBody的響應(yīng)代碼為rp。其中，PKIBody的sender是CA的可辨別名，recipient是RA的可辨別名。如果在證書請求中提供了senderNonce，響應(yīng)的PKIHeader應(yīng)將其作為recipNonce。PKIBody是RevRepContent。如果CA撤銷了證書，正文將包含以下信息：status是granted或是grantedWithMods；revDetails將包含已撤銷證書的CertId。如果status是granted或grantedWithMods,faillnfo字段也可以不出現(xiàn)。如果CA拒絕了請求，PKIBody應(yīng)含有如下信息：status是rejected；failInfo包含適當(dāng)?shù)腻e(cuò)誤代碼。對于能夠確定有問題的證書，revCerts包含被拒絕撤銷證書的Certld。PKIProtection字段包含CA的簽名，即對頭和正文的DER編碼進(jìn)行簽名。若CA生成CRLs,并且撤銷請求被接受，CRL將有以下值：userCertificate字段中的被撤銷證書的序列號；GB/T19771—XXXXrevocationDate收到撤銷請求的日期和時(shí)間；crlEntryExtensions。crlEntryExtensions包括：revCerts字段中的reasonCode,除非CA的策略有專門規(guī)定；(可選的)revCerts字段中的badSinceDate擴(kuò)展可以是invalidaityDate。d)從RA到證書持有者的撤銷響應(yīng)RA在收到CA的回應(yīng)消息后，返回含有響應(yīng)代碼為rp的PKIMessage給證書持有者。其中，PKIBody的sender是CA的可辨別名，recipient是RA的可辨別名。如果響應(yīng)的從證書持有者到RA的撤銷請求消息中有senderNonce,則響應(yīng)的PKIHeader中應(yīng)把它作為recipNonce。PKIBody是RevReqContent,內(nèi)容與從CA到RA的撤銷響應(yīng)相同，PKIProtection字段包含RA的簽名，即對消息頭和消息體的DER編碼進(jìn)行簽名。6.2.5訪問資料庫6.2.5.1從資料庫請求證書證書使用者可使用LDAPV3向資料庫請求證書。當(dāng)使用LDAP時(shí)，證書使用者可以通過LDAP搜索請求從資料庫中請求證書，或是利用給定的LDAPURL來請求證書(即authorityInformationAccess擴(kuò)展)。6.2.5.2從資料庫請求CRL證書使用者可使用LDAPV3向資料庫請求CRLs。證書使用者可使用LDAP從資料庫中請求CRLs。當(dāng)使用LDAP時(shí)，實(shí)體可以通過LDAP搜索請求從資料庫中請求CRLs,或是利用給定的LDAPURL來請求CRLs(即，cRLDistributionPoints擴(kuò)展中的distributionPoint字段)。7測試評價(jià)方法7.1通用測試評價(jià)方法可采用人工訪談、文檔查閱、人工核查等方法，確認(rèn)CA的功能是否符合5.2的要求，確認(rèn)RA的功能是否符合5.3的要求，確認(rèn)證書持有者的功能是否符合5.4的要求，確認(rèn)證書使用者的功能是否符合5.4的要求?？刹捎萌斯ぴL問、文檔查閱、人才核查等方