GBT 27913-2022 用于金融服務的公鑰基礎設施 實施和策略框架

代替GB/T27913—2011用于金融服務的公鑰基礎設施國家市場監(jiān)督管理總局國家標準化管理委員會I Ⅲ 1 1 2 8 95.1概述 9 95.3商業(yè)要求對PKI環(huán)境的影響 5.4認證機構 5.5商業(yè)視角 5.9時間戳 215.10信任模型 216證書策略和認證業(yè)務說明要求 257認證機構控制規(guī)程 25 257.2CA環(huán)境控制 267.3CA密鑰生命周期管理控制 7.4主體密鑰生命周期管理控制 457.5證書生命周期管理控制 7.6CA證書生命周期管理控制 7.7從屬CA證書生命周期管理 附錄A(資料性)根據(jù)證書策略進行管理 附錄B(資料性)認證業(yè)務說明的要素 附錄C(資料性)對象標識符(OID) 附錄F(規(guī)范性)認證機構審計日志內(nèi)容及使用 附錄G(資料性)可選的信任模型 參考文獻 Ⅲ易及處理系統(tǒng)方面的需求不斷增長，從而導致業(yè)務優(yōu)化的技術、管理和策略基礎設施(本文件中定義為公鑰基礎設施或PKI)來在我國，數(shù)字簽名和PKI技術可用于開發(fā)金融服務業(yè)的應用。這些賴于確保基礎設施整體完整性的實踐。對于將個人身份與其他實體和密鑰要素(如本文件制定了通過證書策略、認證業(yè)務說明、控制目標和控準的實現(xiàn)者來說，我國金融交易中的實體可以依賴本文件實1章～第6章。GB/T14916—2006識別卡物理特性(ISO/16649.1識別卡帶觸點的集成電路卡第1部分：物理特性16649.2識別卡帶觸點的集成電路卡第2部分：觸點的尺寸和位置16649.3識別卡帶觸點的集成電路卡第3部分：電信號和傳輸協(xié)議16649.4識別卡集成電路卡第4部分：用于交換的結(jié)構、安全和命令16649.5識別卡帶觸點的集成電路卡第5部分：應用標識符的國家編號體系和注冊16649.6識別卡帶觸點的集成電路卡第6部分：行業(yè)間數(shù)據(jù)元16649.8識別卡帶觸點的集成電路卡第8部分：與安全相關的行業(yè)間命令16649.9識別卡集成電路卡第9部分：用于卡管理的命令2GB/T16649.10識別卡帶觸點的集成電路卡第10部分：同步卡的電信號和復位應答GB/T16649.11識別卡集成電路卡第11部分：通過生物特征識別方法的身份驗證GB/T16649.12識別卡集成電路卡第12部分：帶觸點的卡USB電氣接口和操作規(guī)程GB/T16649.15識別卡集成電路卡第15部分：密碼信息應用GB/T17552—2008信息技術識別卡金融交易卡(ISO/IEC7813:2006,IDT)GB/T18336.1—2015信息技術安全技術信息技術安全評估準則第1部分：簡介和一般模GB/T18336.2—2015信息技術安全技術信息技術安全評估準則第2部分：安全功能組件GB/T18336.3—2015信息技術安全技術信息技術安全評估準則第3部分：安全保障組件ISO13491-1銀行業(yè)務安全加密設備(零售)第1部分：概念、要求和評估方法(FinancialServices—-Securecryptographicdevices(rISO/IEC9594-8信息技術開放系統(tǒng)互連目錄第8部分：公鑰和屬性證書框架(Informationtechnology—OpenSystemsInterconnectiotributecertificatefratechniques—Primenumbergeneration)ISO/IEC18033-1信息技術安全技術加密算法第1部分：概括(Informationtechnology—ISO/IEC18033-2信息技術安全技術加密算法第2部分：非對稱密碼(Informationtech-nology—Securitytechniques—EncryptionalgoritISO/IEC18033-3信息技術安全技術加密算法第3部分：分組密碼(Informationtechnolo-gy—Securitytechniques—Encryptionalgorithms—Part3:BlockciISO/IEC18033-4信息技術安全技術加密算法第4部分：序列密碼(Informationtechnolo-gy—Securitytechniques—EncryptionalgoritISO/IEC19790信息技術安全技術密碼模塊的安全要求(Informationtechnology-Securitytechniques—Securityrequirement接入點accesspoint34證書框架certificateprofile認證certification實體證書的有序序列，通過處理該有序序列及其初始實體的公鑰從而獲得該路徑上最終實體的CA(3.21)在頒發(fā)證書時采用的業(yè)務說明，它定義了CA為滿足由它支持的證書策略的要求而采用5證書有效性certificatevalidity兩個CA(3.21)互相證明彼此的公鑰的過程。硬件密碼模塊hardwarecryptographicmodule數(shù)字簽名digitalsignature實體entity67注冊請求registrationrequestCA(3.21)在CA層次結(jié)構的頂端CA。簽名有效性signaturevalidation由簽發(fā)CA(3.36)認證并符合簽發(fā)CA的證書策略(3.13)的CA(3.21)。8ASN.1抽象語法標記1(AbstractSyntaxNotationOne)9從屬CA(SubordinateCA)公開。主體的公鑰和鑒別數(shù)據(jù)用CA的私鑰簽名后形成證書。證書是根據(jù)證書策略生成的。公鑰的公金融機構可使用PKI在以下環(huán)境中根據(jù)與信任方之間的關系來服務于他們的商業(yè)需求。表1～表3提供了每一種環(huán)境的示例。書策略，見圖1和表1。依附于信任服務的實體可以作為自己或其他證書主體認證的信任方或簽署方。在這種情況下，簽署方和證書主體可能是受超出本文件范圍的業(yè)務關系約束的不同b)契約環(huán)境：證書主體和信任方可具有不2)使用不同證書策略的雙邊交叉認證形式；3)通過中心機構或?qū)嶓w可識別不同證書策略的鑒定橋形式。這可以通過中心組織發(fā)布證書見圖2和表2。c)開放環(huán)境：金融機構可作為TSP向公眾簽發(fā)證書并允許在一個開放的認。TSP可在自愿的TSP的鑒定方案下或在本國規(guī)章制度內(nèi)運行。典型的情況下，用戶的TSP和信任方之間不存在正式的合同。見圖3、表3和圖4。求應在最初進行確定。這些要求在部署PKI時實現(xiàn)?！裕弧职l(fā)3;——使用4;——終結(jié)5;1電子郵件(如利率變化的通完整性?！邮辗津炞C發(fā)送方證書。接收方驗證數(shù)字簽名。2在FI的網(wǎng)絡范圍內(nèi)雇員間——為接收方鑒別發(fā)送方?！邮辗津炞C發(fā)送方的證書。2在FI的網(wǎng)絡范圍內(nèi)雇員間完整性。保護報文內(nèi)容的機密性。3向面對用戶的設備進行FI軟件的內(nèi)部網(wǎng)絡分發(fā)(如軟件有一個可信的來源?！邮辗酱_認FI的證書。用戶用戶1Internet向使用另一個TSP保證報文完整性?！脩魴z查數(shù)字簽名。一保護報文內(nèi)容的機密性。-—發(fā)送方用接收方的公鑰加密報文?！邮辗接米约旱乃借€解密報文。2——顧客批準訂單。——商戶對用戶顧客進行鑒別。——交易報文完整性。一顧客使用私鑰對訂單數(shù)字簽名?！邮辗津炞C發(fā)送方證書?！虘趄炞C數(shù)字簽名。3報文鑒別。——驗證數(shù)字簽名并對證書進行確認。4已有的用戶使用電子銀行服務向FI發(fā)送高額支付——強雙向鑒別?！獔笪耐暾??！獧C密性?！狥I驗證用戶的證書?！狥I驗證數(shù)字簽名——用戶從目錄中取得FI的證書。一強雙向鑒別?！獔笪耐暾浴！獧C密性。5IC卡生成數(shù)字簽名?？ǚ焦€檢查IC卡的真實性。用戶依賴方1——金融機構(FI)的鑒別?！狥I可執(zhí)行代碼的完整性?！脩趄炞CFI的數(shù)字簽名。2—用戶驗證FI服務器的證書。3協(xié)議的情況下通過Internet交換電子郵件證明?！Ｗo報文內(nèi)容的機密性。4務結(jié)果)——用戶驗證FI的證書。5——報文完整性?！Ｗo報文內(nèi)容的機密性。通過讓CA生成證書來實現(xiàn)主體的公鑰與其身份的綁定，從而證明其中的信息的關系并提供其完通過使用一個或多個CA的公鑰來驗證主體的公鑰和身份的綁定。CA可以向任何主體(包括——主體(包括CA)可以使用這些證書對信任方進行身份驗證。因此，鑒別可能涉及一證書鏈的驗證從受信任的CA公鑰開始，以驗證證書結(jié)束。受信任的CA公鑰應通過使用證書以外的其他方法獲得和鑒別。這是為了確保流程安全啟動。詳見ISO/IEC9594-8。CA或終端實體頒發(fā)證書。在層次體系結(jié)構中，根CA的公鑰體都周知。任何實體的證書都可以通過驗證簽名證書的認證路徑來驗徑從被驗證的證書返回到根CA的可信CA公鑰。在這種體系結(jié)構中，根CA是所有實體的交叉認證的遠程CA構建從遠程實體到根CA的證書鏈。——在非層次結(jié)構中，獨立CA可以通過相互頒發(fā)公鑰證書來交叉認證。這將在CA之間形成一擁有自己的CA。實體使用選定CA的公鑰作為其受信任CA的公鑰。證書路徑包含從驗證的證書鏈返回的信任方的可信CA證書。CA交叉認證。獨立的根CA彼此是對等的且橋接CA不需要相互交叉認證。橋接CA允許偽裝成一個或多個終端實體。未能提供補償性控制以應對金融網(wǎng)絡中發(fā)的證書可以由屬于該方案的另一個CA客戶的信任方驗證。通過電子媒介進行商業(yè)活動的可信任安全環(huán)境決定了金融機構將來參與全球在線經(jīng)濟的能力。金融機構的理想目標是為在線市場建立一個支持內(nèi)部安全需求的安全基礎設施，該基礎設施是金融機構b)向公眾或機構間提供認證服務的金融機構應在其CPS中明確他們自己的業(yè)務實踐規(guī)則。 (根策略)(根策略)根CA(策略A)終端實體CVSP(金融機構)間與數(shù)字簽名的生成的準確或接近時間相關聯(lián)。這一技術通常稱為時間戳。時間戳協(xié)議的示例在用于CA和EV審計的Webtrust是第三方信任模型的例子。第二方審核員可以是注冊的 標識策略機構：2)一般規(guī)定；3)認證與鑒別；4)操作要求；6)技術的安全控制；7)證書和CRL;8)實施管理。具體控制見表4和表5。1PA應負責確保CA控制過程，按照認證業(yè)務說明(CPS)或等價文件中的規(guī)定，并完全符合CP的要求。2PA應有最終授權和責任規(guī)定并核準證書策略。3PA應有最終授權和責任核準CA的認證業(yè)務說明(CPS)。4PA應確保認證業(yè)務說明(CPS)或等價文件的產(chǎn)生并確保這些文件至少描述以下內(nèi)容：a)CA環(huán)境控制；b)密鑰生命周期管理控制；c)證書生命周期管理控制。5PA或委托的代表應確保其業(yè)務服務應用使用適當?shù)淖C書策略。6當證書策略終止時，PA應維護相關規(guī)程并通知受影響的各方。PA應首先立即通知支持其證書策略的CA以7PA應維護其終止情況下的程序，在這種情況下，應通知受影響的各方傳輸歸檔記錄到相關管理8策略機構按照定義好的評審過程核準證書策略，包括對證書策略的維護。9應存在確定的評審過程以確保CPS中規(guī)定的控制支持證書策略。PA應使CA支持的證書策略對所有適合的用戶和信任方都是可用PA應定期進行評估，以確定CP處理業(yè)務風險的充分應由PA根據(jù)確定的程序核準CA的CPS并修改，包括維護CPS的責任。CA應使其認證業(yè)務說明對所有適合的各方都可用。CPS應包括對控制的解釋以確保與以下保持一致：a)法律要求；b)合同要求；c)教育和通告要求；e)業(yè)務連續(xù)性要求；f)因違反安全策略或安全事故結(jié)果導致的增CA的控制應在CPS或等價文件中描述。具體控制見表6和表7?！踩跈C構內(nèi)得到規(guī)劃、管理和支持；——有效管理已識別的風險；——CA設施、系統(tǒng)和第三方訪問的信息資產(chǎn)的安全得到維護；12CA的負責管理人員應能夠證明信息安全策略得到實施和遵守。3信息安全策略應包括：a)信息安全的定義，全部目標和范圍，以及安全作為能夠進行信息共享b)管理目的的描述、支持的目標和信息安全原則；c)解釋對機構特別重要的安全策略、原則、標準和一致性要求；d)定義信息安全管理的一般和特別責任，包括報告安全事件；4應有確定的規(guī)程用于維護信息安全策略，包括職責和評審日5高級管理和/或高層管理信息安全委員會應確保有明確的指導和管理，以此來支持有效的風險處6傳達給負責信息安全和風險管理的管理組或委7應明確定義保護個人資產(chǎn)和執(zhí)行特定安全過程的職責。8應存在并遵循新信息處理設備的管理授權過程。9如果CA有業(yè)務需求允許第三方訪問CA的設施及系統(tǒng)，則應進行風險評估以確定涉及的安全和特定的控制要求。涉及第三方對CA設施及系統(tǒng)進行訪問的安排應基于包含所有必要的安全要求的正式合如果CA將全部或部分信息系統(tǒng)、網(wǎng)絡和/或桌面環(huán)境的管理和控制外包，則應在相關各方簽署的合同中明確如果CA選擇將CA的部分角色和相應功能委托給另一方，則CA應最終負責外包功能的完成以及CPS規(guī)則具體控制見表8和表9。1應識別所有CA資產(chǎn)的所有者，并且為維護合適的控制分配責2應維護CA資產(chǎn)的清單。3CA應對基于業(yè)務需求和與之相關的業(yè)務影響信息進行信息分級，并采取相關的保護控制。4應定義規(guī)程以確保信息的標識和處理是按照CA的信息分級方案執(zhí)行的。具體控制見表10和表11。表11人員安全控制規(guī)程1CA應聘用擁有與工作內(nèi)容相適應的相關技能、知識和經(jīng)驗的人員。2機構安全策略中所規(guī)定的安全角色和職責應在工作描述中記錄。應明確標識CA運行3a)CA安全業(yè)務實施的全面管理職責；b)證書生成、撤銷和掛起的核準；c)CA系統(tǒng)的安裝、配置和維護；d)CA系統(tǒng)的日常操作及系統(tǒng)備份和恢復；e)CA系統(tǒng)歸檔文件和審計日志的審查和維護；f)密碼密鑰生命周期管理功能(如，密鑰組件管理者);4CA策略和規(guī)程應規(guī)定對可信角色和非可信角色要求的背景檢查和清除。至少對永久職員的作申請時執(zhí)行，并且對承擔可信角色的個人進行周期性檢5個人的可信狀態(tài)應在獲得對系統(tǒng)/設施的訪問或執(zhí)行需要可信狀態(tài)的行為前核6CA的雇員和可信角色應簽署一份保密協(xié)議作為雇用的條件。7執(zhí)行可信角色的簽約員工應至少受到和雇員一樣的背景檢查及人員管理規(guī)程。8簽約員工和CA之間的合同協(xié)議應包括這樣的條款，使臨時簽約員工明確同意CA對違a)同簽約員工簽署明確要求；b)要求簽約員工對故意的有害行為導致的損害進行賠償；9應有正式的紀律處理規(guī)程，對違反組織安全策略和程序的雇員加以處當終止雇用時應及時采取適當?shù)男袆?，使得控?如，訪問控制)不會被削機構的所有雇員和相關第三方簽約員工應接受機構策略和規(guī)程的適當培訓。具體控制見表12和表13。表12物理和環(huán)境安全控制目標——僅有已授權的個人才能對CA設施進行訪問；——保護CA設施防止來自環(huán)境的危險；——防止資產(chǎn)的丟失、損壞或泄露以及業(yè)務活動的中斷；防止信息和信息處理設施的泄露；1應通過創(chuàng)建嚴格的安全邊界(即物理和邏輯屏障)來提供物理保護。CA的證書生產(chǎn)設備2包括CA證書生產(chǎn)設施的建筑或地點的邊界應有最少數(shù)量的受控訪問點。3應設置有人接待區(qū)域或其他控制物理訪問的方法，使得對CA運行所在的建筑或地點的訪問僅限于授權人4應設置物理屏障(如從地板到天花板的堅固墻體)以防止對CA證書生產(chǎn)設施的非授權進入或環(huán)境污染。5應設置物理屏障(如電磁屏蔽)以防止對所有根CA操作(如密鑰生成和CA證書認證)以及證書策略所規(guī)定內(nèi)容的電磁輻射。6圍繞CA運行設施的安全邊界上的防火門應具有警報裝置并遵循地方防火規(guī)7應安裝并定期檢查入侵檢測系統(tǒng)，范圍覆蓋放置CA運行設施的建筑的所有外面的門。8無人時，應將CA運行設施物理鎖住并設置報警裝9所有人員應佩戴可見的身份標識。應鼓勵雇員查問任何沒有佩戴可見標識的人應通過使用鑒別控制，限制僅有授權人員能夠?qū)A運行設施進行訪問。應將所有進入和離開CA運行設施的人員記入日志(即應維護所有訪問的審計追蹤)。應監(jiān)督CA設施的訪問人員，記錄他們進入和離開的日期和時應限制第三方支持服務人員對安全CA設施的訪問，當必要訪問時，也應對該訪問進行授權并且有人陪同。應定期審查并更新CA設施的所有訪問權。CA應維護一個設備清單。應確定設備放置地點并對設備進行保護，以減少環(huán)境威脅和災害，以及減少非授權訪問的機表13物理和環(huán)境安全控制規(guī)程(續(xù))設備應受到保護以有效應對停電或其他電力異常情應保護CA服務的電力電纜和通信電纜不受到偵聽或破應根據(jù)制造商說明書和/或其他文檔化的規(guī)程維護設備，確保其連續(xù)可用性和完整性。應檢查包含存儲介質(zhì)(固定和可移動的磁盤)設備的所有項目，確保在銷毀前不再包含敏據(jù)的存儲介質(zhì)應被物理銷毀或在重新使用前進行安全重寫。通用控制敏感或關鍵業(yè)務信息應在不需要或CA設施不再使用時被鎖起。規(guī)程應要求屬于機構的設備、信息和軟件不能未經(jīng)授權就被帶離所在位置。對密碼模塊的物理訪問應限于雙重控制下的授權實具體控制見表14和表15。——CA信息處理設施的正確和安全運行；——CA系統(tǒng)失效的風險最小化；——CA系統(tǒng)和信息的完整性受到保護，防止病毒和惡意軟件；——通過使用事件報告和響應規(guī)程將安全事件和故障的損失最小化；1對于每個功能區(qū)，應將CA運行程序通過文件記錄并維護。2應有正式的管理責任和規(guī)程來控制CA設備、軟件和運行規(guī)程的所有變更。3責任和責任范圍應被分開，以減少非授權修改、信息或服務誤表15運行管理控制規(guī)程(續(xù))4開發(fā)和測試設施應與運行設施分開。5應監(jiān)視容量需求并預測未來的容量要求，以確保有充足的處理能力和存儲6應建立新信息系統(tǒng)、升級系統(tǒng)或新版本系統(tǒng)的接受標準，并在接受前執(zhí)行適當?shù)南到y(tǒng)測防止病毒和惡意軟件7應實施防止病毒和惡意軟件的檢測和防護控制。應有適當?shù)某绦蚴构蛦T知曉控制措施。8應有正式的安全事件報告規(guī)程，在接收到事件報告時啟動應采取的行動。這包括分配程。任何事件都應作為緊急問題報告給責任管理者。9被授予可信角色的CA系統(tǒng)用戶應記錄并報告觀察到的或懷疑的在系統(tǒng)或服務中的安全對安全事件的適當響應。應建立并遵循硬件和軟件故障報告規(guī)程。應建立并遵循相應規(guī)程，報告錯誤，并采取正確的行動。應建立并遵循規(guī)范的問題管理程序，以記錄、量化并監(jiān)視事件和故障的類型、數(shù)量和影可移動的計算機介質(zhì)的管理規(guī)程應要求：a)如果不再需要，應有效擦除任何準備移走的可重用介質(zhì)中原有數(shù)據(jù)內(nèi)容，或者將該介質(zhì)銷毀；b)從機構內(nèi)移走的所有介質(zhì)需要得到授權，并且保存所有移動的記錄以維持審計追蹤；c)所有介質(zhì)應根據(jù)制造商的規(guī)定在安全的環(huán)境中存儲和放包含存儲介質(zhì)的設備(即固定硬盤)應受到檢查，以確定在銷毀或重用前是否包含敏感數(shù)據(jù)。包含敏感信息的存儲設備應在銷毀或重用前被物理銷毀或安全地重應建立并遵循信息處理和存儲規(guī)程以防止該信息非授權暴露或誤應保護系統(tǒng)文件，防止非授權訪問。具體控制見表16和表17?！獌H限于已授權的擁有預定任務權限的人員對運行系統(tǒng)進行訪問；——僅限于已授權的個人、應用和服務對CA系統(tǒng)所處網(wǎng)段進行訪問；1應在訪問控制策略中定義并以文件形式明確訪問控制的業(yè)務要求a)角色和相應的訪問許可；b)每一用戶的認證與鑒別過程；c)責任分離；d)執(zhí)行特定CA操作所要求的人員的數(shù)量(即n分之m規(guī)則。其中，m表示2應有正式的可信角色用戶注冊和注銷程序，以允許訪問CA信345網(wǎng)絡訪問控制6CA雇員應只對明確授權其使用的服務進行直接訪問。用戶終端到計算機服務的路徑應受到控制7如果允許CA雇員或外部系統(tǒng)對CA系統(tǒng)的遠程訪問，則應要求進8CA雇員或CA系統(tǒng)和遠程計算機系統(tǒng)的連接應9應具有有效控制(如防火墻)以保護CA的內(nèi)部網(wǎng)絡區(qū)域，防止來自其他區(qū)域的任何根據(jù)CA的訪問控制策略，應具備有效控制來限制授權用戶可用的網(wǎng)絡服務(如HTTP、FT用的所有網(wǎng)絡服務的安全屬性應由CA以文應具有路由控制以確保計算機連接和信息流不違反CA的CA應確保本地網(wǎng)絡組件(如防火墻和路由器)處于物理安全的環(huán)境中，并周期性地審計它們置要求的一致性。操作系統(tǒng)訪問控制操作系統(tǒng)應根據(jù)CA的操作系統(tǒng)配置標準進行配置并操作系統(tǒng)補丁和升級程序應基于風險評估在的確需要系統(tǒng)升級應使用自動終端認證來鑒別到特定地點和便攜組賬戶的地方應實施其他監(jiān)控措施來維持個人行為與表17系統(tǒng)訪問管理控制規(guī)程(續(xù))操作系統(tǒng)訪問控制服務于CA系統(tǒng)的非活動終端應在使用前重新鑒對高風險的應用宜使用連接時間限制，以提供額外的安全應防止敏感的操作系統(tǒng)數(shù)據(jù)泄露給非授權用戶。應用訪問控制信息和應用系統(tǒng)功能的訪問應根據(jù)CA的訪同控制策略進行限CA人員使用與證書管理相關的關鍵應用前應被成功識別和鑒別。敏感系統(tǒng)(如根CA)應要求專門的(隔離的)計算環(huán)境。具體控制見表18和表19。1新系統(tǒng)和系統(tǒng)升級的業(yè)務要求中應明確規(guī)定控制要求。2對于操作系統(tǒng)上的軟件實施，包括預定的軟件發(fā)布、修改和緊急軟件修復，應建立和遵規(guī)程。3應建立和遵循硬件、網(wǎng)絡組件和系統(tǒng)配置變更規(guī)45操作系統(tǒng)發(fā)生變更時應對系統(tǒng)進行審查和測6宜限制對軟件包的修改，應嚴格控制所有變更。7應控制和檢查軟件的購買、使用和修改，防止可能的隱蔽通道或惡意代碼。這些應包括些控制同樣應用于外包軟件開發(fā)。應遵照GB/T18336.1、GB/T18336.2、GB/T18336具體控制見表20和表21。—CA災難恢復計劃的開發(fā)和測試；——在備用地點存儲系統(tǒng)、數(shù)據(jù)和配置信息的備份；——保證用于恢復的備用地點、設備和連接的可用性；1CA應有開發(fā)和維護其業(yè)務持續(xù)性計劃的管理過程。CA應有基于適當風險評估的業(yè)務持續(xù)性計劃策2CA應有在關鍵CA過程中斷或失效后及時維護或恢復CA運行的業(yè)務持續(xù)性計劃。CA的業(yè)明確：b)應急規(guī)程；c)撤退規(guī)程；d)恢復規(guī)程；e)計劃的維護方案；f)意識和教育要求；g)個人職責；h)恢復時間目標(RTO);i)業(yè)務持續(xù)性計劃的定期測試。3CA業(yè)務持續(xù)性計劃應包括一個或多個組件失效時CA所有關鍵組件的災難恢復過程，包括a)用于存儲CA私鑰備份的密碼設備應安全保存在異地，以在主CA設施災難事件時得到恢復；b)使用并管理災難恢復密碼設備所需的必要子密鑰和密鑰組件也應在異地保4應定期進行基本業(yè)務信息的備份。這些備份的安全要求應與信息備份控制要求保持一致。5CA應確定并安排備用地點，在CA主地點發(fā)生災難事件時，核心的PKI操作可恢復。撤退設放置在安全距離外，避免來自主地點災難的破壞。6不管是在本地還是遠程，當災難發(fā)生并且安全環(huán)境沒有恢復期間，CA業(yè)務持續(xù)性計劃應包括這段時間內(nèi)保護設施安全的規(guī)程。7CA業(yè)務持續(xù)性計劃應明確如果計算資源、軟件和/或數(shù)據(jù)被破壞或被懷疑受到破壞時使用的恢復規(guī)8業(yè)務持續(xù)性計劃應定期進行測試以確保是最新的和有效的。9業(yè)務持續(xù)性計劃應通過定期審查和更新進行維護以確保持續(xù)有效性。具體控制見表22和表23?！狢A的運行及服務符合相關法律、制度和合同要求；——CA的運行及服務與CA安全策略和規(guī)程的一致性；1CA應有實施規(guī)程以確保遵守使用知識產(chǎn)權和專有軟件產(chǎn)品的法律規(guī)2應有控制來確保對密碼硬件與軟件的訪問或使用符合國家法律、法規(guī)或其他規(guī)34a)應由CA或RA保密的信息；b)不認為是機密的信息；c)向法律強制機構發(fā)布信息的策略；d)可以作為當事人證據(jù)收集被披露的信息；e)信息在主體同意情況下可被披露的條件；f)機密信息可被披露的其他情況。5保護CA的重要記錄，防止丟失、破壞和偽造篡改。6管理者宜負責確保他們職責范圍內(nèi)的安全規(guī)程正確執(zhí)行。表23監(jiān)視和遵守控制規(guī)程(續(xù))7CA的運行應受到定期審查以確保與CPS一致。8應周期性檢查CA系統(tǒng)與安全實施標準的一致性。監(jiān)視系統(tǒng)訪問和使用9應建立監(jiān)視CA系統(tǒng)使用的規(guī)程，監(jiān)視活動的結(jié)果應定期審查。應實施報警機制檢測非授權訪具體控制見表24和表25?！獪蚀_適當?shù)赜涗汣A環(huán)境、密鑰管理和證書管理事件；——當前和歸檔的審計日志的機密性和完整性得到維護；-——根據(jù)業(yè)務揭示說明將審計日志完整地機密地歸檔；審計日志1CA應按照法律和證書策略的要求生成自動的(電子的)和手工的審計日志。2所有日志條目應包括：a)條目的日期和時間；b)條目的序列號或順序號(對于自動日志條目);c)條目種類；d)條目來源(如終端、端口、地點、客戶等);表25審計日志控制規(guī)程(續(xù))3CA應記錄以下CA和主體密鑰生命周期管理a)CA密鑰生成；b)手工密鑰的安裝及結(jié)果(連同操作者的身份);c)CA密鑰備份；d)CA密鑰存儲；e)CA密鑰恢復；f)CA密鑰托管活動(如果有);g)CA密鑰使用；h)CA密鑰歸檔；i)密鑰要素從服務中撤銷；j)CA密鑰銷毀；k)授權一個密鑰管理操作的實體的身份；1)處理密鑰要素(如存儲在便攜設備或介質(zhì)內(nèi)的密鑰組件或密鑰)的實體的身份m)密鑰，設備或保存密鑰的介質(zhì)的保管；4a)設備接收和安裝；b)放置或移除儲存器中的設備；c)設備激活和使用；d)設備解除安裝；e)指定對設備的服務和修理；5如果CA提供主體密鑰管理服務，CA應記錄以下主體密鑰生命周期管a)密鑰生成；b)密鑰分發(fā)(如果可用);c)密鑰備份(如果可用);d)密鑰托管(如果可用);e)密鑰存儲；f)密鑰恢復(如果可用);g)密鑰歸檔(如果可用);h)密鑰銷毀；i)授權一項密鑰管理操作的實體的身份；表25審計日志控制規(guī)程(續(xù))6CA應記錄(或要求RA記錄)以下證書應用信息：a)采用的身份認證方法和用于符合“了解你的用戶”的要求的信息；b)惟一身份鑒別數(shù)據(jù)記錄、號碼或組合的記錄，如申請者駕照號碼(如果可用);c)申請和認證文件副本的存儲地點；d)接受申請的實體的身份；e)用于驗證認證文件的方法；f)接收申請的CA或提交申請的RA的名稱(如果可用);g)主體用戶協(xié)議的接受；h)按照個人隱私的相關法律要求，用戶同意CA保存包含用戶個人數(shù)據(jù)的記錄，同意將該信息三方并發(fā)布證書。7CA應記錄以下證書生命周期管理相關的事件：a)收到證書請求——包括初始證書請求、更新證書請求和更新密鑰請求；b)提交用于認證的公鑰；c)實體從屬關系的變更；d)證書生成；e)CA公鑰的分發(fā)；f)證書撤銷請求；g)證書撤銷；h)證書掛起請求(如果可用);i)證書掛起和取消掛起；8CA應記錄以下安全敏感事件：a)包括審計日志本身的安全敏感文件或記錄的讀寫；b)對安全敏感數(shù)據(jù)采取的行動；c)安全配置文件的更改；d)認證與鑒別機制的使用，不論成功還是不成功(包括多次失敗的鑒別嘗試);e)安全敏感的非金融交易(如賬戶或名稱/地址變更等);f)系統(tǒng)崩潰、硬件失效或其他異常；g)可信角色、計算機操作員、系統(tǒng)管理員和系統(tǒng)安全員個人所采取的行動；h)實體從屬關系的變更；i)不進行加密/鑒別過程或規(guī)程的決定；j)訪問CA系統(tǒng)或其中的任何組件。9審計日志不應以任何形式(如明文或加密的形式)記錄私CA計算機系統(tǒng)時鐘應按照CP或CPS中規(guī)定的可接受時間源進行同步，以準確進行記錄。表25審計日志控制規(guī)程(續(xù))審計日志保護當前和歸檔的審計日志應以防止修改或非授權銷毀的形式進行維護。在可能或要求滿足法律要求的情況下應使用數(shù)字簽名保護審計日志的完整用于對審計日志簽名的私鑰不應用于其他目的。用于對稱MAC機制中使用的對稱密鑰同樣不應用于其他目的。審計日志歸檔CA應定期歸檔審計日志數(shù)據(jù)。除了可能的相關規(guī)則的規(guī)定，應執(zhí)行風險評估確定保持歸檔審計日志的適當時間長審計日志的審查當前和歸檔的審計日志應只能被授權人員以合理的業(yè)務原因或安全原因獲審計日志應根據(jù)CPS中建立的業(yè)務規(guī)則進行審當前或歸檔的審計日志的審查應包括驗證審計日志的完整性，以及異常、非授權或可疑活動的鑒別及其后續(xù)事件的追蹤。要求分析的情況和可能行為的示例包括系統(tǒng)資源的異常飽和、數(shù)量的突然變化和意外的增加以及在異常時間或來自異常地點的訪問。具體控制見表26和表27。表26CA密鑰生成控制目標表27CA密鑰生成控制目標1CA密鑰生成應根據(jù)規(guī)定了執(zhí)行步驟和參與者責任的詳細的CA密鑰生成過程腳本來執(zhí)行。序腳本應包括：a)角色和責任的定義；b)執(zhí)行密鑰生成過程的核準；c)密鑰生成過程需要的密碼硬件和激活材料；d)規(guī)定密鑰生成過程期間執(zhí)行的步驟；e)密鑰生成后密碼硬件和激活材料安全存儲的規(guī)程；f)參與者和見證人簽署指明密鑰是否根據(jù)詳細密鑰生成過程腳本生成；g)任何密鑰生成過程腳本執(zhí)行及執(zhí)行結(jié)果異?，F(xiàn)象的注2CA密鑰的生成應在按照ISO/IEC19790、ISO13491-1和CPS業(yè)務要求的密碼模塊執(zhí)行。這使用ISO/IEC18032規(guī)定的隨機數(shù)生成器(PNG)或偽隨機數(shù)生成器(PRNG)進行密鑰生成。3CA密鑰的生成應在物理安全環(huán)境中(見7.2.5)由被授予可信角色的人員在多重控制和知識分附錄D)進行。4CA應在使用密鑰對的同一密碼設備內(nèi)生成密鑰對，或者直接從生成它的設備注入到使用它的設備當5CA所生成的密鑰應：a)適合預定的應用或目的，并且與識別的風險相適應；b)使用ISO/IEC18033-1、ISO/IEC18033-2、ISO/IEC18033-3、ISO/IEC18033c)具有與密碼算法和CA證書有效期相適應的密鑰長度；d)同時考慮上級CA和它的從屬CA密鑰長度的要求；6CA密鑰的生成應產(chǎn)生符合CP的密鑰長度。經(jīng)CA認證的公鑰長度應小于或等于CA簽名私鑰的長7用于密鑰生成的軟硬件的完整性和與這些軟硬件的接口應在生產(chǎn)使用前進行測具體控制見表28和表29?！狢A私鑰保持機密性和完整性；1CA的(簽名和機密性)私鑰應在安全密碼設備內(nèi)存儲和使用，這些設備應基于風險評估和C合GB/T18336.1、GB/T18336.2、GB/T18336..3保護框架或ISO19790保護配置文件的CPS和適用的證書策略一致。2如果CA的私鑰沒有從安全密碼模塊中導出，則CA私鑰應在同一個密碼模塊內(nèi)生成、存儲和使用。3如果CA的私鑰從安全密碼模塊導出到安全存儲，用于離線處理或備份和恢復的目的，則它們應在一個安全密鑰管理方案內(nèi)被導出，該方案可包括：a)密文使用的密鑰被適當保護；b)加密的密鑰片斷使用多重控制和分割知識/所有權；c)使用另一個安全密碼模塊，如使用多重控制的密鑰傳輸設備。4如果備份CA的私鑰，則它們應由被授予可信角色的授權人員，在物理安全環(huán)境中使儲和恢復。授權執(zhí)行該功能的人員的數(shù)量應保持最5如果備份CA的私鑰，則CA私鑰的備份應受到與當前使用的密鑰相同或更高級別的復應以與備份過程相同安全的方式執(zhí)行。6維修.就應執(zhí)行驗收測試和固件設置驗證。7為防止篡改，CA密碼硬件應在安全地點存儲和使用，并將訪問限制于授權人員。CA密碼硬件具有以下特征：a)詳細清單控制過程和程序管理每一設備的來源、到達、狀況、出發(fā)和目的地；b)訪問控制過程和程序限制授權人員的物理訪問；c)在審計日志內(nèi)記錄所有對CA設施和設備存儲機制(如保險箱)成功或失敗的訪問：d)具有事件處理過程和程序來處理異常事件、違反安全事件、調(diào)查和報告；e)具備審計過程和程序以驗證控制的有效性。8未連接到CA系統(tǒng)時，CA密碼硬件應保存在防纂改的容器內(nèi)，容器在多重控制下安全地保存(如保險箱9CA密碼硬件的處理，包括以下任務，應在不少于兩個可信雇員在場的情況下執(zhí)a)安裝CA密碼硬件；b)從生產(chǎn)系統(tǒng)中移走CA密碼硬件；c)CA密碼硬件的服務或修理(包括新硬件、固件或軟件的安裝);用于私鑰存儲和恢復的設備以及與這些設備的接口應在使用前對完整性(如遵循制造商的說明)進行測試。具體控制見表30和表31。1CA應提供驗證CA公鑰可鑒別性和完整性的機制。對于根CA公鑰分發(fā)過程(如使用自簽名的證書),應使用帶外通知機制。在自簽名證書被用于任何CA的地方，CA應提供驗證自簽名證書可鑒別性的機制(如證書指紋的發(fā)布)。對隨后的和/或下級的CA公鑰，這些應通過使用證書鏈方法或類似過程鏈接到可信根證書的根證書，可要求帶外過程。表31CA公鑰分發(fā)控制規(guī)程(續(xù))2CA公鑰的初始分發(fā)機制應按照CA的CPS中明確的方式進行控制。CA公鑰應在證書內(nèi)使按照CA的CPS進行初始分發(fā)：a)來自己進行源鑒別的機器易讀的介質(zhì)(如智能卡、CDROM);b)嵌入在實體的密碼模塊內(nèi)；3CA公鑰應根據(jù)CPS的要求周期性變更(密鑰更新)。應提前通知以避免CA服務的中斷。4CA公鑰隨后的分發(fā)機制應按照CA的CPS中明確的方法進行控制。5如果實體已經(jīng)有CA公鑰的已鑒別副本，新的CA公鑰應使用以下方法之一按照CA的CPS進行分a)從CA直接進行電子傳輸；b)放入遠程緩存或目錄；具體控制見表32和表33。1CA簽名私鑰的激活應使用多方控制執(zhí)行(如n分之m),m使用的最小值推薦為3。2基于風險評估，如果必要，CA私鑰的激活宜使用多因素鑒別進行(如智能卡和口令、生物鑒別和口令等3用于生成證書和/或簽發(fā)撤銷狀態(tài)信息的CA簽名私鑰不應用于其他目4CA的私鑰應只在物理安全前提內(nèi)使用(見7.2.5)。5CA應在定義的密鑰對的運行生命期結(jié)束時或者已知或懷疑私鑰泄露時停止使用該密鑰對。6CA密碼硬件的正確處理宜周期性地得到驗7PA宜要求對密鑰長度每年進行評審，以確定適當?shù)拿荑€使用期并作出建議。表34CA密鑰歸檔和銷毀控制目標—歸檔的CA密鑰在重新導入生產(chǎn)系統(tǒng)后仍然保持機密性和安全性；表35CA密鑰歸檔和銷毀控制規(guī)程1歸檔的CA密鑰應受到與當前使用的密鑰相同或更高級別的安全控制。2CA的私鑰應直到其業(yè)務目的或應用已經(jīng)終止或者法律責任已經(jīng)期滿時才能被銷毀。3歸檔的密鑰只有在安全事件導致生產(chǎn)密鑰丟失或歷史證據(jù)要求驗證時才能重新放回到生產(chǎn)當中。應要求控制過程確保CA系統(tǒng)和密鑰集的完整性。4歸檔的密鑰應在最短的可能時間期內(nèi)恢復以符合業(yè)務要5授權銷毀CA私鑰以及如何銷毀CA私鑰(如交出令牌、銷毀令牌或密鑰重寫)應根據(jù)CA的CPS進行限制。6CA私鑰的所有副本和分段應以私鑰無法被重新得到的方式被銷毀。7如果CA密碼設備正從服務中永久移除，則設備內(nèi)包含的用于任何密碼目的的密鑰應從設備內(nèi)擦除。具體控制見表36和表37。表37CA密鑰泄漏控制規(guī)程1CA的業(yè)務連續(xù)性計劃中應將CA私鑰的泄露或懷疑泄露作2表37CA密鑰泄漏控制規(guī)程(續(xù))3如果CA私鑰泄露，則使用的恢復程序應包a)如何保護生產(chǎn)環(huán)境中的密鑰使用被重新建立；b)CA的舊公鑰如何撤銷；c)對受影響方(如受影響的CA、資料庫、用戶和CVSP)的通知程序；d)CA的新公鑰如何連同鑒別機制一起提供給終端實體及信任方；4CA不得不更換其根CA私鑰時，應具備程序?qū)⒁韵聝?nèi)容安全地并經(jīng)過a)舊的CA根公鑰；b)基于泄露私鑰的根CA或任何CA簽發(fā)的所有證書集(包括自簽名的證書);567.4.1CA提供的主體密鑰生成服務(如果支持)具體控制見表38和表39。表38CA提供的主體密鑰生成服務控制目標——CA(或RA或其他授權第三方)根據(jù)CP生成的主體密鑰；表39CA提供的主體密鑰生成服務控制規(guī)程1由CA(或RA或其他授權第三方)執(zhí)行的主體密鑰生成應在安全密碼設備內(nèi)發(fā)生，符合基于風險評估的適當?shù)腎SO/IEC19790一級安全要求以及CA的業(yè)務要求，并符合適用的CP。這樣的密碼設備應使用ISO/IEC18032規(guī)定的隨機數(shù)生成器或偽隨機數(shù)牛成器(PRNG)執(zhí)行主體密鑰的生2由CA(或RA或其他授權第三方)執(zhí)行的主體密鑰生成應使用CP中規(guī)定的3由CA(或RA或其他授權第三方)執(zhí)行的主體密鑰生成應按照CP產(chǎn)生具有適當密鑰CA(或RA或其他授權第三方)提供的主體密鑰生成4由CA(或RA或其他授權第三方)執(zhí)行的主體密鑰生成應由授權人員啟動的過程根據(jù)該CA的CPS來執(zhí)行5當CA(或RA或其他授權第三方)執(zhí)行主體密鑰生成時，CA(或R或其他授權第三方)生成的主體密鑰對根據(jù)CP傳送給主體。6具體控制見表40和表41。——由CA存儲的主體私鑰保持機密性和完整性；——由CA歸檔的主體私鑰保持機密性；——由CA存儲的主體私鑰在密鑰對生命周期結(jié)束時被完全銷毀；1由CA(或密鑰存儲的信任服務提供者)存儲的主體私鑰應使用基于風險評估和CP要求的密碼算法和密鑰長2如果CA為用戶生成密鑰對，則CA(或密鑰存儲的信任服務提供者)應確保主體的私外的任何實體。3如果CA(或密鑰存儲的信任服務提供者)生成簽名公/私密鑰對，則一旦主體確認收到密應保留任何簽名私鑰的副本。4如果CA(或密鑰存儲的信任服務提供者)提供主體(機密性)密鑰存儲備份和恢復，或主體(機密性)私有密鑰備份和恢復，則這些服務只應由授權的人員執(zhí)5如果CA(或密鑰存儲的信任服務提供者)提供主體密鑰存儲、備份和恢復，則應有控制來確保主體(機密性)私有密鑰的完整性在生命周期內(nèi)得到保證。表41CA提供的主體密鑰存儲和恢復服務控制規(guī)程(續(xù))6由CA歸檔的主體(機密性)私有密鑰應使用基于風險評估和CP要求的密碼算法和密鑰長度以加密形式7如果CA提供主體(機密性)密鑰歸檔，則所有歸檔的用戶密鑰應在歸檔期8如果CA提供主體(機密性)密鑰存儲，則授權銷毀主體私鑰9如果CA提供主體(機密性)密鑰存儲，則主體私鑰的所有副本和分段應在密鑰對生命周期結(jié)由CA保管的用于法律強制訪問目的的主體(機密性)私有密鑰使用基于風險評估和CP要求的密碼算法和密7.4.3集成電路卡(IC卡)生命周期管理(如果支持)具體控制見表42和表43?！狪C卡的獲得、準備和個性化由CA(或RA或發(fā)卡方)安全地控制；——IC卡的使用在IC卡簽發(fā)前由CA(或RA或發(fā)卡方)激活；——IC卡由CA(或RA或發(fā)卡方)安全地存儲和分發(fā)；——IC.卡由CA(或RA或發(fā)卡方)安全地更換；IC卡的獲得1如果CA或RA約定了發(fā)卡方的服務，則相關各方間應存在正式協(xié)議。當發(fā)卡功能委2IC卡在卡制造商和發(fā)卡方之間傳輸時應通過使用傳輸密鑰或通行字進行邏輯保護。IC卡的獲得3頒發(fā)給主體的IC卡應基于風險評估和CP的要求，符合適當?shù)腉B/T18336保護配置文件、ISO卡標準(如4發(fā)卡方應根據(jù)來自卡制造商的收據(jù)驗證IC卡的5當IC卡在發(fā)卡方控制之下時，IC號應被安全地存儲并在資產(chǎn)清6IC卡準備過程和程序，包括以下內(nèi)容，這些內(nèi)容應存b)創(chuàng)建邏輯數(shù)據(jù)結(jié)構(卡文件系統(tǒng)和卡安全域);c)加載應用程序；d)邏輯保護IC卡，防止對卡操作系統(tǒng)、卡文件系統(tǒng)、卡安全域和應用程序7IC卡個性化過程和程序，包括以下內(nèi)容.這些內(nèi)容應存在并被遵守：a)將身份認證信息加載到卡上；b)根據(jù)7.4.1和CP的要求生成主體密鑰對；c)將主體私鑰以加密的形式加載到IC卡上(如果在卡外生成);d)加載主體證書到IC卡上；e)加載CA或其他用于契約環(huán)境的證書到IC卡上；8發(fā)卡方或CA(或RA)應在審計日志內(nèi)記錄IC卡的準9除非卡已經(jīng)由發(fā)卡方、CA或RA準備和個性化，否則不應IC卡的分發(fā)應創(chuàng)建并遵循過程和程序來分發(fā)、追蹤和說明主體安全接收到IC卡的分發(fā)應由發(fā)卡方、CA(或RA)在審計主體IC卡的使用IC卡上的主體私鑰不應導出到應用程序執(zhí)行加密(即對于密碼應用和卡功能，應要求主體使用雙向鑒別機制，以確表43集成電路卡(IC卡)生命周期管理控制規(guī)程(續(xù))主體IC卡的使用應要求主體使用應用程序在簽名報文(或交易)數(shù)據(jù)前，向主體顯示報文或報文摘要。主體有使用IC卡的審計日志。這包括私鑰所有者驗證過程中的所有嘗試。如果信任方對交易IC卡的更換應創(chuàng)建并遵循過程和程序來更換主體丟失的或損壞的IC卡?？▉G失或損壞時，應根據(jù)CP(見7.5.2和7.5.3)更新主體證書或更新密鑰。IC卡的更換應由發(fā)卡方或CA(或RA)在審計日志內(nèi)記錄。IC卡的終止所有返回給發(fā)卡方或CA(或RA)的所有IC卡應解除激活或安全地銷毀，防止非授權訪問IC卡的終止應由發(fā)卡方或CA(或RA)在審計日志內(nèi)記錄。具體控制見表44和表45。表44主體密鑰管理要求的控制目標表45主體密鑰管理要求的控制規(guī)程1CP應規(guī)定用于主體密鑰生成的密碼模塊和適當?shù)腎SO19790級別要求。2CP應規(guī)定可用于主體密鑰生成的密鑰生成算3CP應規(guī)定用于主體密鑰生成的可接受密鑰長4CA或RA應向用戶提供機制允許用戶訪問(如私鑰所有人驗證方法)、管理和控制私鑰的使用并使這些機制對用戶是可用的。5表45主體密鑰管理要求的控制規(guī)程(續(xù))6CP應規(guī)定恢復主體私鑰時的環(huán)境和授權以7CP應規(guī)定由主體存儲的主體私鑰的備份副本主體密鑰使用范圍8金融服務條款和條件(或單獨的用戶協(xié)議)應描述用戶(及主體)使用密碼機制(如HSM序)需要遵循的程序和過程。9CP應規(guī)定主體密鑰對可接受或允許的使用主體密鑰歸檔CP應規(guī)定歸檔的主體密鑰在歸檔期結(jié)束時CP或CPS應規(guī)定在密鑰對生命周期結(jié)束時，主體私鑰的所有副本和如果要求，CP應規(guī)定密碼硬件在其他物理位置時(即HSMCP應規(guī)定主體密鑰泄露時對CA或RA的具體控制見表46和表47。表46主體注冊控制目標——主體(或用戶)按照適用的“了解你的用戶”的要求被準確地識別；認證與鑒別1CA應驗證或要求RA驗證主體提供的證明其身份或授權的憑證，以證明根據(jù)證書策略和法a)對于個人終端實體證書，CA或RA應(按照CP所確定的方式)驗證姓名包含在證別名字段內(nèi)的人的身份。未經(jīng)鑒別的個人姓名不應包括在證書基本域的主體惟一識別名當中；b)對于機構證書(包括基于角色的、服務器、網(wǎng)絡資源、代碼簽名的證書),CA或R式)驗證包含在證書基本域的主體惟一識別名字段機構屬性內(nèi)的機構名未經(jīng)鑒別的機構名不應包括在證書當中；c)對于包含機構域名的機構證書，CA或RA應(按照CP所確定的方式)驗證包含在證書基本域的主體惟一識別名字段通用名屬性內(nèi)的域名的所有權、控制權和使用權。未經(jīng)鑒別的域名不應包括在證書當中2CA或RA應根據(jù)CP驗證包含在請求實體的證書請求中的3CA或RA應根據(jù)CP檢查證書請求中的差錯4對于終端實體證書，CA應使用包含在實體證書請求中的RA的公鑰來驗證證書請求5CA應在CP定義的邊界或在CA服務的群體范圍內(nèi)驗證主體惟一識別名的惟一性。6應使用加密和訪問控制來保護傳輸和存儲中的注冊數(shù)據(jù)的機密7在注冊時(證書簽發(fā)之前)RA或CA應通知主體或用戶關于證書使用8CA應要求請求證書的實體必需按照CP的要求準備并向RA(或CA)提交恰當?shù)淖C書請求數(shù)據(jù)(9CA應要求請求實體以自簽名的報文的形式向CA提交其公鑰進行證書申請。CA應要求請冊請求中包含的公鑰相關的私鑰對注冊請求進行數(shù)字簽a)允許在證書應用處理中檢測差錯；b)證明擁有該注冊公鑰對應的私鑰；c)驗證證書簽名請求(CSR)中實體的惟一識別名、公鑰和其他信息的完整性。證書請求應被認為請求實體已經(jīng)按照用戶協(xié)議接受了使用證書CA應在特定CP下驗證經(jīng)授權發(fā)出注冊請求的CA應要求RA在由RA簽名的報文(證書請求)中向CA提交請求實體的證書請求數(shù)據(jù)。CACA應要求RA根據(jù)CA的CPS來保護其(RA)負責的那部分的證書申請過程的安全。即便在審計日志中，CA(或RA)也應記錄注冊的CA應根據(jù)CA的CPS驗證RA提交的請求的可鑒別性。具體控制見表48和表49。12CA應要求請求實體使用與請求實體已有證書中包含的公鑰對應的私鑰對證書更新請求3泄露的跡象，CA才能使用主體以前已認證過的公4CA或RA應處理證書更新數(shù)據(jù)以驗證請求實體的身份并鑒別要567CA或RA應驗證證書更新請求，包括其延長的有效期，符合CP8如果使用RA,則CA應要求RA在RA簽署的報文(證書更新請求)中向CA提交證書更新數(shù)9RA應根據(jù)CP保護它(RA)負責的那部分證書更新CA應檢查證書更新請求的差錯或忽略的內(nèi)容。該功能可明確CA或RA應在證書期滿前通知主體或用戶，證書需要具體控制見表50和表51。1CA應要求請求實體使用已有私鑰對包含新公鑰的證書密鑰更新請求進2CA或RA應驗證證書密鑰更新請求符合相關CP中3如果使用RA,CA應要求RA在由RA簽名的報文中向CA提交實4如果使用RA,CA應要求RA保護它(RA)負責的那部分證書密鑰更新過程的安5如果使用RA,CA應要求外部RA在審計日志中記錄它們的行為。6如果使用RA,CA應驗證證書密鑰更新請求上的RA的簽7CA或RA應檢查證書密鑰更新請求的差錯或89a)對證書密鑰更新數(shù)據(jù)提交所做的簽名；b)該密鑰更新請求的存在性和有效性；在證書撤銷后，當用戶要求新證書時，實體應被要求根據(jù)CP實體證書過期后，當用戶要求新證書時，證書可被自動生成，或者應要求實體根據(jù)CP具體控制見表52和表53。1CA應使用證書請求數(shù)據(jù)生成證書，并遵照符合ISO/IEC9594-8格式化規(guī)則的證書框架制造證書。2應在CP內(nèi)設置有效期并遵照ISO/IEC9594-8進行格式化。3證書擴展域應遵照ISO/IEC9594-8格式化。表53證書簽發(fā)控制規(guī)程(續(xù))4CA應用CA的簽名私鑰簽署實體的公鑰和其他相關信息：a)CA應驗證自己的數(shù)字簽名；b)CA不應簽發(fā)失效的簽名；c)CA應將事件記錄在審計日志中。私鑰資料的交付須經(jīng)過認證：a)接受方應對電子交付進行認證；5證書應基于根據(jù)7.5.1～7.5.3的要求核準的主體注冊、證書更新或證書密鑰更新請求程序進行簽6當RA為主體提交了證書請求，證書被簽發(fā)給主體時CA應向RA發(fā)出一個簽名了的通知。7證書被簽發(fā)時，CA應向主體發(fā)出一個帶外通知。當該通知包括初始激活數(shù)據(jù)時，控制過全交付。8如果證書過期、被撤銷或被掛起，應在CP中規(guī)定的適當時間長度內(nèi)保留證書的副本。具體控制見表54和表55。1CA應使用一種已建立的符合CP的機制(例如，像目錄服務器這樣的資料庫)使CA簽發(fā)的證a)收集，資料庫或在線目錄服務；b)交付，使用受保護的介質(zhì)(如，CD-ROM或IC2只有授權的CA人員才能管理CA的資料庫或其他可替代3CA資料庫或可替代的其他分發(fā)機制的性能應受到4資料庫或可替代的其他分發(fā)機制的完整性應得到5當需要時，只有在獲得主體同意的情況下證書才可被其他相6當使用密碼保護CA公鑰時，用于生成數(shù)字簽名的私鑰或用于具體控制見表56和表57。1CA應提供一種快速通信的方法，以便將以下證書安全地、經(jīng)a)一個或多個主體的一個或多個證書；b)CA基于生成證書的單個公/私鑰對簽發(fā)的所有證書的集合：c)CA簽發(fā)的所有證書，無論使用的公鑰/私鑰對是什2CA應驗證或要求RA根據(jù)CP驗證請求撤銷證書的實體的3如果RA接受了撤銷請求，則CA應要求RA根據(jù)CP以一種可鑒別的方式向CA提交簽名的證4如果RA接受并向CA轉(zhuǎn)發(fā)了撤銷請求，則CA應向RA提供一個簽名的確認以確認收到了該證書撤銷請求和5CA應在CP規(guī)定的時間框架內(nèi)遵照ISO/IEC9594-8定義的格式更新證書撤銷列表(CRL),6CA應在審計日志中記錄所有的證書撤銷請求及其結(jié)果，具體按照附錄7CA或RA可向發(fā)出撤銷請求的實體提供一個可鑒別的證書撤銷確認(簽名或8若支持證書更新，當證書被撤銷時，所有有效的該證書的實例也應被撤銷9應向已撤銷或掛起的證書的實體(和用戶)通知其證書——向其他實體(如信任方、監(jiān)管機構)發(fā)送通知；具體控制見表58和表59。1根據(jù)CA的CPS,CA提供一種快速通信的方法.以便將以下證書安全地、經(jīng)鑒別地掛起：a)一個或多個主體的一個或多個證書；b)CA基于生成證書的單個公/私鑰對簽發(fā)的所有證書的集合；c)CA簽發(fā)的所有證書。2CA應驗證或要求RA根據(jù)CP驗證請求證書掛起和請求證書取消掛起的實體的身份和授權。3如果RA接受了掛起請求，則RA應根據(jù)CP以一種可鑒別的方式向CA提交簽名的證書掛起請求。4證書掛起時，CA或RA應通知該主體和用戶。56CA應在證書掛起時更新證書撤銷列表(CRL)和其他證書狀態(tài)機制。證書狀態(tài)的更改應在C架內(nèi)完成。7證書應根據(jù)CP只被在允許的時間長度內(nèi)掛起。8一旦證書掛起已經(jīng)發(fā)布，掛起應以下面三種方式之一處理：a)掛起的證書的條目保留在CRL上，沒有進一步動作；b)掛起的證書的CRL,條目被同一證書的撤銷條目代替；c)掛起的證書被明確解除，條目從CRL中移除。9證書掛起條目應保留在CRL上，直到證書期滿或掛起期滿時間中的一個先到達。CP可起的最大次數(shù)和處于該狀態(tài)的最大時間周期。如果達到限度，則可通知PA進行進一步的調(diào)查。CA應在證書取消掛起對根據(jù)其CP來更新其證書撤銷列表(CRL)和其他證書狀態(tài)機制。CA應驗證或要求RA驗證請求取消證書掛起的實體的身份和授權。證書掛起和取消掛起應遵照附錄F的要求在審計日志中記錄。具體控制見表60和表61。表61證書確認服務控制規(guī)程1CA應根據(jù)CP使用已建立的機制使證書狀態(tài)信息對相關各方(信任方或其代理)是可用的。式達到：a)請求響應方式，信任方向證書狀態(tài)提供方的響應器發(fā)出一個簽名的請求；反過來，證器用適時簽名的證書狀態(tài)信息進行響應(OCSP是一種使用該方法的協(xié)議實例);b)傳遞方式，由CA簽署——CRL,并在策略規(guī)定的時間框架內(nèi)發(fā)布該CRL。2CA應對發(fā)布的每一個CRL進行數(shù)字簽名，這樣實體可以驗證CRL的完整性和發(fā)布的日期時間。3CA應根據(jù)CP的規(guī)定以固定時間間隔發(fā)布CRL,即使從上次發(fā)布以來沒有發(fā)生改變。4標識一個撤銷了的證書的CRL條目至少應在CRL上保留到該證書有效期結(jié)束?？梢笞C書的狀態(tài)。因此，CRL條目可被保持到超過證書有效期的時間，以證明它在使用時的有效5如果支持證書掛起，證書掛起條目連同其原始動作日期和期滿日期應保留在CRL上取消掛起。6CRL應根據(jù)相應CP的要求，包括歸檔的CRL的獲取方法，進行歸檔。7CRL應包括CA簽發(fā)的所有已撤銷的未過期證書的條目。可要求在給定的時間回顧證書的狀態(tài)條目可被保持到超過證書有效期的時間，以證明它在使用時的有效性。8舊的CRL應根據(jù)相應CA保留適當時間長度。9在收到來自信任方或其代理的證書狀態(tài)請求(如OCSP請求)時，CA應向信任方或其代理返回確定的響如果：a)該請求報文格式正確；b)證書狀態(tài)提供方響應器已有配置來提供所請求的服務；c)該請求按照相應CP的要求包含證書狀態(tài)提供方響應器所需的信息(即證書標識，序列號，OID等);d)證書狀態(tài)提供方響應器能夠定位證書并解釋其狀當這些條件滿足時，CA或證書狀態(tài)提供方應產(chǎn)生簽名的響應報文，根據(jù)CP的要求指出證書的狀態(tài)：如果以上條件中的任何一條不能滿足，則返回“未知”狀態(tài)。所有響應報文應進行數(shù)字簽名并包括CP要求的所有數(shù)具體控制見表62和表63。1在證書頒發(fā)機構成立時設立咨詢委員會，負責監(jiān)督CA的終止或與任何其他CA的234提供在CA終止后重新驗證任何用戶的數(shù)字5制定終止計劃，以盡量減少中斷，包括通知用戶、保存記錄、將業(yè)務移交給6根CA數(shù)據(jù)庫至少保留一年。具體控制見表64和表65?！獜膶貱A證書請求是準確的、已鑒別并核準的；——從屬CA證書更換(更新和密鑰更新)請求是準確的、已授權并完整的；——新的、更新的和密鑰更新的從屬CA證書根據(jù)特定CP的要求生成簽發(fā)的；——從屬CA證書基于授權的和驗證的證書撤銷請求進行撤銷；123上級CA應在核準從屬CA的證書請求前審計從屬CA的CP與其自身的CP要求的一致法是，從屬CA應提交它的CPS供審計。4當允許從屬CA證書更新時，上級CA的CP應規(guī)定提交從屬CA更5當允許從屬CA證書更新時，上級CA應根據(jù)其CA的CP鑒別其從屬CA的表65從屬CA證書生命周期管理的控制規(guī)程(續(xù))6上級CA的CP應規(guī)定提交從屬CA密鑰更新7上級CA應根據(jù)其CP鑒別從屬CA的證書密從屬CA證書簽署8a)使用適當?shù)淖C書框架，符合CP和ISO/IEC9594-8的格式化規(guī)則；b)具有遵照ISO/IEC9594-8和CP的要求格式化了c)當使用擴展域時，擴展域根據(jù)ISO/IEC9594-8和CP進行9上級CA應按照其CP的要求使用已建立的機制(如像目錄這樣的資料庫)使其從屬CA任方)可用。從屬CA證書撤銷上級CA應根據(jù)CP的要求驗證請求撤銷從屬CA證書的實體的在證書撤銷時，上級CA應根據(jù)CP的要求更新證書撤銷列表(CRL)和其他從屬上級CA應根據(jù)其CP的要求使用已建立的機制(如CRL,OCSP等)使從屬CA證書狀態(tài)信息對信任方可用CP宜被證書的各種用戶使用，以決定是否接受(證書的)主體和公鑰之間的綁定關系。CP在約束。對象標識符可不在證書中出現(xiàn)或在上述擴展域的某些或所有這些字段當中出現(xiàn)。證書策略策略機構或其代理可向潛在的用戶提供已簽名的紙質(zhì)的證書策略副本，作為一種合同捆綁關自動化方法處理。這些策略和策略限定符由簽發(fā)CA在證書的證書策略擴展項中列出，其定義}CertifcatePoliciesSynPolicyInformation::=SSIZE(1..MAX)OFPolicyInformationCertPolicyId::=OBJECTIDENTIFPolicyQualifers::=SEQUENCESIZE(1..MAX)OFPolicycertificatePolicies證書擴展項中列出的證書策略是那些簽發(fā)CA認為適合于該證書的策略。信擴展項被設置為關鍵的，則該擴展項表示該證書宜由信任方用于該證書策略所指的目的。特定的CP可要求使用證書的系統(tǒng)以特定的方式處理任何限定符的值，進一步限制或擴展證書使用的有PolicyQualifierInfo::=S}SupportedPolicyQualifiersCERT-POLICYPolicyQualifierInfo類型由兩個組件組成，policyQualifierld和qualifier,它們根據(jù)信息對象類&.QualifierOPTI}WITHSYNTAX{POLICY-QUAIIFIER-ID&id[QUAIIFIERb)戶通知限定符包含了在使用證書前將顯示給證書用戶(包括用戶和信任方)的文本串。該文本串可以是IA5字符串或BMP字符串——GB/T13000多一旦各方能夠識別和定位與一張證書相關的CP,用戶應能夠明確證書的用途和限制。策略機——證書策略是面向用戶的，因為證書提供了一種控制機制來管理提供給用戶服務的相關一些PKI域限制證書策略擴展的使用。例如，CA瀏覽器論壇禁止在根CA證書中使用certifi-交叉認證是兩個或更多不同策略機構發(fā)布的證書策略的相互認證過程。交叉認證使不同策略一個可接受的策略標識符是一個認證路徑上的用戶要求的CP標識符，或者通過策略映射(見policyMappingsEXTENPolicyMappingsSyntax::=SEQUENCESIZ書指出明確的CP。證書用戶認為認證路徑起始的證書是一個信任域的一部分(即認證機構對所有策略約束擴展項的其他可特性是對于認證機構能夠禁止認證路徑上隨后的認證機構設置的策帶來的風險(如域A信任域B,域B信任域C,但是域A不希望被迫信任域C)。policyConstraintsEXTENSION::={IDENTIFIEDBYd-ce-pPolicyConstraintsSyntax::= 這一方法考慮了隨后的補充要求，這些要求可由市場為證書策略和相關信 用戶負責根據(jù)用戶協(xié)議的條款保護對私鑰的訪問。這表示任何對使用私鑰的訪問從不泄露給使用一個已知并可信的證書確認服務提供者的服務。以下三個簡單的例用前被信任方主動地接受。只有在這種方式成為一種使用證書的標準方法并被廣泛用于宜陳述證書更替如何管理(如身份的自動或重新驗證)或者是否需要生成新的密鑰對。還宜陳在規(guī)定的時間周期內(nèi)(如兩年)根據(jù)CPS審計CA的正式方法宜在策略機構和CA間達成一致。(資料性)認證業(yè)務說明的要素B.1概述認證業(yè)務說明宜包含本附錄中包括的所有組件和子組件的引用。CPS不需要包括每個主題的確定性陳述。特定的CPS對組件、子組件或元素沒有要求時可聲明為“不實施”。這將指示讀者清楚地做出決定是包括或是排除哪一主題。這樣在決定業(yè)務應用的使用性時便于比較不同的認證業(yè)務說明以確認哪一個更合適。本附錄依據(jù)RFC2527的結(jié)構，它已經(jīng)被RFC3647取代。從RFC2527到RFC3647的變化可見附錄E中的映射表。B.2簡介CPS的引言有以下子組件：——參與群體和適用性；——詳細聯(lián)系方式。提供了一般性的介紹(如業(yè)務規(guī)則的通用目的)。提供可用名稱或其他標識符，包括ASN.1對象標識符。B.2.4參與群體和適用性本子組件描述了簽發(fā)證書或主體CA的實體類型，執(zhí)行RA功能的實體類型和、主體終端實體或用戶的實體類型?！灠l(fā)的證書適用的應用列表；——適用簽發(fā)的證書受到限制的應用列表，或者使用簽發(fā)的證書受到禁止的應用列表。B.2.5詳細聯(lián)系方式本節(jié)包括負責注冊、維護和解釋CPS的機構的名稱和郵件地址，也包括所有適當聯(lián)系人的名稱、B.3一般條款 B.3.7機密性常規(guī)密鑰更新的認證業(yè)務宜與初始注冊時相同。除非已到期的證書在過期前被用于鑒別。密本子組件描述了每個主體類型(CA、RA和終端實體)或其他(根據(jù)CP規(guī)定的)授權方或監(jiān)管方發(fā)出的證書撤銷請求的認證與鑒別規(guī)程。B.4.6掛起的請求本子組件描述了每個主體類型(CA、RA和終端實體)或其他(根據(jù)CP規(guī)定的)授權方或監(jiān)管方發(fā)出的掛起請求的認證與鑒別規(guī)程。B.5操作要求B.5.1概述本組件用于規(guī)定施加于簽發(fā)CA、主體CA、RA、CVSP或終端實體的各種操作活動的要求。本組件包括以下子部分：——證書申請；—證書簽發(fā)；——證書接受；——安全審計規(guī)程；——CA終止。B.5.2證書申請本子部分用于說明主體登記注冊和請求簽發(fā)證書的有關要求。B.5.3證書簽發(fā)本子部分用于說明證書簽發(fā)和通知申請者該證書的簽發(fā)情況的有關要求。B.5.4證書接受本子部分用于說明對已簽發(fā)的證書的接受和隨之發(fā)布該證書的有關要求。 掛起可持續(xù)多長時間 對信任方檢查CRL的要求 當掛起或撤銷是由于私鑰泄露所導致時(與其他掛起或撤銷的原因相對),以上約定的 審計日志備份規(guī)程 對實體的審計日志積累制度是內(nèi)部的還是外部的 是否在審計過程中通知導致審計事件發(fā)生的主體； 本子部分描述了在泄露或災難事件發(fā)生時與通知和恢復規(guī)程有關的要求。以下每種情況需要 介質(zhì)保護： 廢物處理： 對承擔可信角色的人員所要求的背景檢查和安全檢查規(guī)程。背景檢查可包括安全檢查級 對每個角色的培訓要求和培訓規(guī)程； 因為非授權行為、非授權使用權力以及人員對實體系統(tǒng)的非授權使用從而導致的對相關人 提供給相關人員的文件(如操作或培訓手冊)本子部分用于定義簽發(fā)CA為保護其密鑰和激活數(shù)據(jù)(如PIN,口令或手工持有的密鑰分享組護他們的密鑰和關鍵安全參數(shù)。安全的密鑰管理對于確保所有密鑰和激活數(shù)據(jù)受到保護并只被授 誰生成終端實體的公私密鑰對： 實體的公鑰如何安全地提供給證書生成者： 如果實體是CA或證書狀態(tài)提供者(簽發(fā)者或主體),則該實體的公鑰證書如何安全地提供 ——私鑰是在m分之n多人控制下的嗎?如果是，提供n和m的具體值(兩人控制是m分之n被分給m個不同的個人。這m份中的任何n份可被用來完全重建密鑰。但擁有任何n-1的。這樣，根據(jù)需要密鑰可由這些功能的任何子集進行處理。托管的目的是允許第三方(如機構或政府)在法律上無需主體的協(xié)作而獲得密鑰。備份的目的是允許主體在密鑰受 ——誰將私鑰輸入到密碼模塊?以何種形式(即明文的、加密的或分割密鑰的)?私鑰如何存儲——公鑰歸檔嗎?如果這樣，誰是歸檔代理，對歸檔系統(tǒng)的安全控制是什么?歸檔系統(tǒng)宜提供對私鑰的訪問在初始和整個有效使用期內(nèi)需要受到控制和保護。激活數(shù)據(jù)在鑒別機制中用于驗證私鑰的所有者。激活數(shù)據(jù)指除密鑰外需要操作密碼模塊并需要受到保護的數(shù)值。需要為簽發(fā)密碼機制是硬件、軟件和使用特定設備時相關固件的組合。遵從性B.8證書和CRL框架本子部分用于規(guī)定證書格式，如果使用CRL,還需要規(guī)定CRL的格式。如果假設使用 ——變更規(guī)程——無需通知就可以變更的部分、子部分和/或其他項目的列表，CP對象標識符或CPS指針——在通知期后變更的部分、子部分和/或其他組成部分的列表，而不變更CP對象標識符或B.9.3發(fā)布和通知規(guī)程本子部分包括以下內(nèi)容：——存在但沒有公開的部分、子部分和/或其他項目的列表；因為其敏感性，機構可選擇不公開 B.9.4CP一致性本子部分描述檢查CPS符合CP要求的過程。(資料性)對象標識符(OID)C.1為什么有OID使用OID可以使得信任方自動地識別CP(如建立了一個或多個策略域的根CA適用的CP文件)。每個從屬CA將需要一