網(wǎng)絡(luò)安全技術(shù) 公鑰基礎(chǔ)設(shè)施 PKI組件最小互操作規(guī)范 征求意見稿

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