中國人民銀行信息系統(tǒng)電子認證應用指引(V1.0).doc

《中國人民銀行信息系統(tǒng)電子認證應用指引(V1.0).doc》由會員分享，可在線閱讀，更多相關《中國人民銀行信息系統(tǒng)電子認證應用指引(V1.0).doc（45頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、內(nèi)部資料 注意保管 中國人民銀行信息系統(tǒng) 電子認證應用指引 （征求意見稿） 中國人民銀行 2010年1月  目 錄 1 概況 1 1.1. 編寫目的 1 1.2. 適用范圍 1 1.3. 指引內(nèi)容簡介 1 1.4. 術語定義 1 2 CA系統(tǒng)及應用簡介 4 2.1. 生產(chǎn)系統(tǒng) 5 2.2. 測試系統(tǒng) 6 2.3. CA應用現(xiàn)狀 6 2.3.1. CA系統(tǒng)與CA應用的關系 6 2.3.2. CA應用類型與模式 8 2.3.2.1. CA應用類型 8 2.3.2.2

2、. 應用模式 10 3 應用流程和工作分工 14 3.1. CA應用總體流程 14 3.2. 需求階段 17 3.2.1. 工作內(nèi)容 17 3.2.2. 參與部門與工作流程 17 3.3. 設計階段 17 3.3.1. 工作內(nèi)容 17 3.3.2. 參與部門與工作流程 17 3.4. 開發(fā)階段 18 3.4.1. 工作內(nèi)容 18 3.4.2. 參與部門及工作流程 18 3.5. 測試階段 18 3.5.1. 工作內(nèi)容 18 3.5.2. 參與部門及工作流程 19 3.6. 上線實施階段 20 3.6.1. 工作內(nèi)容 20 3.6.2. 參與部門及工作流程 20

3、 3.7. 運維階段 20 3.7.1. 工作內(nèi)容 20 3.7.2. 參與部門及工作內(nèi)容 20 4 CA應用設計和實現(xiàn)的內(nèi)容 20 4.1. 確定CA應用需求類型 21 4.2. 確定實現(xiàn)方式 21 4.2.1. 軟件方式 21 4.2.2. 硬件方式 22 4.3. 其他內(nèi)容 22 4.3.1. 撤銷列表下載方式 22 4.3.2. 交叉認證 23 4.3.3. 多應用加載的環(huán)境 23 4.4. 應用策略 23 4.4.1. 實現(xiàn)方式 23 4.4.2. 撤銷列表下載方式 24 4.4.3. CA應用模式實現(xiàn)方式 24 4.4.3.1. B/S模式實現(xiàn)方式

4、 24 4.4.3.2. C/S模式實現(xiàn)方式 25 4.4.3.3. S/S模式實現(xiàn)方式 25 4.4.3.4. 混合模式實現(xiàn)方式 26 4.4.4. 其他情況 26 4.5. CA應用模板 26 5 附錄 28 5.1. CA應用開發(fā)包獲取方式 28 5.2. 人民銀行CA系統(tǒng)DN規(guī)則 33 III 1 概況 1.1. 編寫目的 本指引是人民銀行信息系統(tǒng)電子認證應用（以下簡稱“CA應用”）的指導性文件。CA應用貫穿信息系統(tǒng)建設的設計、開發(fā)、測試、上線實施及運行維護的各個階段，通過該指引規(guī)范CA應用的工作流程，以便各相關部門（業(yè)務部門、管理部門、建設部門、運維部門

5、）明確職責、保證CA應用的順利進行。 本指引解釋權歸屬人民銀行總行科技司。 1.2. 適用范圍 本指引適用于人民銀行內(nèi)部及與人民銀行有信息系統(tǒng)互聯(lián)的外部機構。其中人民銀行內(nèi)部各部門包括系統(tǒng)管理部門、業(yè)務部門、系統(tǒng)建設部門、系統(tǒng)運維部門等；外部機構的使用范圍根據(jù)互聯(lián)機構的具體情況由人民銀行業(yè)務主管部門和科技司共同決定。 使用CA安全認證服務的機構、部門和個人，都需要嚴格遵守本指引。 1.3. 指引內(nèi)容簡介 本指引在簡單介紹人民銀行CA系統(tǒng)基本情況的基礎上，重點介紹了CA應用涉及的工作內(nèi)容、應用策略、應用流程和工作分工，并在附錄中給出與CA應用有關的管理制度和技術文檔。 1.4. 術

6、語定義 PKI：Public Key Infrastructure即公開密鑰基礎設施，是以公鑰（非對稱）密碼學為基礎，為信息系統(tǒng)提供安全認證服務，構建網(wǎng)絡信任體系的安全基礎平臺。 CA：Certification Authority即認證中心。CA是PKI的核心，受信任的第三方，生成用戶的數(shù)字證書，解決公鑰體系中公鑰的合法性問題。本指引中CA專指人民銀行內(nèi)部CA系統(tǒng)。 RA：Registration Authority即注冊機構，數(shù)字證書注冊審批機構。負責完成證書的發(fā)放、撤銷、更新、恢復、凍結和解凍等管理功能。本指引中RA專指人民銀行RA系統(tǒng)。 LRA：Local Registrati

7、on Authority即證書注冊審核受理點，RA的組成部分，作為證書發(fā)放受理點，直接面向用戶。 KMC：Key Management Centre密鑰管理中心，提供加密密鑰的產(chǎn)生、存儲、更新、分發(fā)、查詢、撤消、歸檔、備份及恢復等管理功能。 LDAP：Lightweight Directory Access Protocol 目錄服務器，用以存儲和發(fā)布用戶的證書信息、證書撤銷列表，用戶在使用證書時通過訪問目錄服務器，驗證證書的有效性。 CRL：Certificate Revocation List證書撤消列表，通過查詢CRL用以驗證證書的使用狀態(tài)是否為撤消或凍結，判斷證書的有效性。 O

8、CSP：Online Certificate Status Protocoal即在線證書狀態(tài)協(xié)議，與CRL以及證書狀態(tài)相結合，能為用戶提供高效、實時的證書狀態(tài)查詢服務。 TSA：Time Stamp Authority即時間戳服務，負責對所有請求時間戳服務的請求進行簽發(fā)處理，并對時間戳進行相應的管理。 數(shù)字證書：由CA認證中心發(fā)放的，能進行身份驗證的一種權威性文件，用戶通過數(shù)字證書來證明自己的身份和識別對方的身份。數(shù)字證書是一段包含用戶或服務器身份信息、公鑰信息以及身份驗證機構數(shù)字簽名的文件，人民銀行CA證書格式及證書內(nèi)容遵循X.509標準。 數(shù)字簽名：數(shù)字簽名是指用戶用自己的私鑰對業(yè)務

9、操作數(shù)據(jù)、數(shù)據(jù)傳輸?shù)认嚓P信息的哈希摘要用非對稱密碼算法進行加密所得的數(shù)據(jù)，實現(xiàn)對業(yè)務操作數(shù)據(jù)及數(shù)據(jù)發(fā)送者的身份認證，防止抵賴，保證數(shù)據(jù)的完整性。 數(shù)字信封：結合對稱密碼和非對成密碼技術，用以保證數(shù)據(jù)傳輸安全的加密方法。 個人證書：向個人使用者發(fā)放的數(shù)字證書，用以實現(xiàn)應用系統(tǒng)中個人操作所需的安全服務。個人證書的保管使用由使用者本人負責。人民銀行CA個人證書分為：RA管理員證書、LRA管理員證書、LRA操作員證書、個人單密鑰證書。其中RA管理員證書、LRA管理員證書、LRA操作員證書均可用于管理或使用LRA系統(tǒng)；個人單密鑰證書為個人普通證書。 服務器證書：發(fā)放給應用系統(tǒng)中服務器的數(shù)字證書，用

10、以建立服務器和客戶端之間的安全信任關系。 設備證書：發(fā)放給網(wǎng)絡設備的數(shù)字證書，用以實現(xiàn)該設備所需的安全服務。 機構證書：向與應用系統(tǒng)互聯(lián)的外部機構發(fā)放的證書，該證書的使用對象為機構。它解決的是人民銀行信息系統(tǒng)與外部機構系統(tǒng)互聯(lián)時，對所連接的機構實體進行認證的問題，而不針對這個機構中的具體操作人員，這也是業(yè)務數(shù)據(jù)交換的延伸超出了管轄范圍情況下的一種解決辦法。機構證書在應用系統(tǒng)中的具體表現(xiàn)形式為服務器證書。 證書責任人：個人證書的證書責任人是證書持有（使用）人；服務器、設備證書責任人是證書申請部門為該證書指定的證書管理責任人。 SSL：Security Socket Layer即安全套接層

11、協(xié)議，通信雙方通過數(shù)字證書，建立數(shù)據(jù)傳輸安全通道的協(xié)議。 身份認證：驗證一個主體身份的過程，即驗證者根據(jù)被驗證者提供的或擁有的身份鑒別信息用以確認其身份是否真實的過程。 數(shù)據(jù)機密性：信息具有的一種內(nèi)在性質(zhì)，這一性質(zhì)要求信息不泄露給非授權的個人、實體或進程，不為其所用。 數(shù)據(jù)完整性：信息具有的一種內(nèi)在性質(zhì)，這一性質(zhì)表明信息沒有遭受以非授權方式所作的篡改或破壞。 數(shù)據(jù)不可否認性：信息具有的一種內(nèi)在性質(zhì)，確保個人或設備不能否認其發(fā)送過的信息及交易，也稱抗抵賴性。 2 CA系統(tǒng)及應用簡介 人民銀行內(nèi)部CA系統(tǒng)（以下簡稱“CA系統(tǒng)”）作為人民銀行的安全基礎設施，為人民銀行信息系統(tǒng)提供身份認證

12、、防抵賴、完整性和保密性的安全服務。 根據(jù)CA系統(tǒng)運行和CA應用的實際需要，CA系統(tǒng)分為生產(chǎn)系統(tǒng)和測試系統(tǒng)兩部分，下面對兩個系統(tǒng)分別進行介紹。 2.1. 生產(chǎn)系統(tǒng) CA生產(chǎn)系統(tǒng)的體系結構如下圖所示： 從目錄服務器 圖－1 人民銀行CA生產(chǎn)系統(tǒng) 其中： l CA生產(chǎn)系統(tǒng)分為CA中心和RA證書注冊系統(tǒng)。 l 其中CA中心作為后臺系統(tǒng)生產(chǎn)證書，并提供證書及撤銷列表的查詢服務。目前CA中心部署在金電公司，由金電公司負責CA中心運維和CA應用的技術支持工作。 l RA系統(tǒng)作為證書發(fā)放系統(tǒng)面向用戶，負責證書申請的審核和發(fā)放。RA系統(tǒng)部署在總行信管中心，由總行信管中心負責運維，

13、總行信管中心和上海總部/營管部/分行/省會中支的管理員、操作員通過Web界面登陸RA系統(tǒng)進行證書相關操作。 2.2. 測試系統(tǒng) 測試系統(tǒng)的體系結構圖如下： 圖－2 人民銀行CA測試系統(tǒng) 其中： l 測試系統(tǒng)整體部署在金電公司，由金電公司服務運維。 l 金電公司的工作包括測試證書的生產(chǎn)、發(fā)放。 l 提供CA應用測試技術支持。 2.3. CA應用現(xiàn)狀 2.3.1. CA系統(tǒng)與CA應用的關系 CA系統(tǒng)作為人民銀行的安全基礎設施，提供數(shù)字證書簽發(fā)、密鑰管理、證書查詢等功能，應用系統(tǒng)根據(jù)CA應用工具（開發(fā)包或硬件設備），通過接口開發(fā)實現(xiàn)自身的簽名、驗簽名等功能模塊，從而滿足

14、應用系統(tǒng)身份認證、防抵賴、完整性、保密性的安全需求。 CA系統(tǒng)及CA應用的現(xiàn)狀如下圖所示： 圖－3 CA系統(tǒng)及CA應用現(xiàn)狀示意圖 其中： l 圖中左半部分為CA系統(tǒng)示意圖，右半部分為應用系統(tǒng)的CA實現(xiàn)示意圖。 l 圖中虛線為RA系統(tǒng)面向用戶離線方式的證書申請、發(fā)放。 個人證書 申請證書時，USBKey產(chǎn)生密鑰對，私鑰駐留USBKey中，不可導出，實現(xiàn)對私鑰的硬件級保護，同時在應用中數(shù)字簽名的密碼運算在USBKey內(nèi)完成。 服務器證書 服務器證書的申請、發(fā)放，根據(jù)確定的CA應用方式有所不同。如果是軟件方式，則服務器的管理員需要使用專用工具產(chǎn)生密鑰對及證書申請文件，提交

15、給發(fā)證終端LRA，由CA中心生產(chǎn)簽名證書后，返給系統(tǒng)管理員，管理員用該工具將本地保存的私鑰和簽名證書一起轉換為系統(tǒng)所需的證書文件。如果是硬件方式，需要硬件支持申請證書。 l 圖中黑色加粗線條表示在CA應用中，應用系統(tǒng)在線（或離線）查詢證書撤銷列表（CRL），驗證證書的有效性。 l 根據(jù)具體應用系統(tǒng)的需求，在客戶端和服務器端分別部署所需的CA應用安全套件。安全套件的內(nèi)容包括開發(fā)包、硬件設備、根證書、用戶證書、撤銷列表。 2.3.2. CA應用類型與模式 2.3.2.1. CA應用類型 隨著CA應用的推廣，我行應用系統(tǒng)數(shù)據(jù)集中以及資源整合的不斷深入，根據(jù)不同的安全需求，可將CA應用分為如

16、下幾種不同類型。 一、安全需求說明 基于CA應用，應用系統(tǒng)能夠實現(xiàn)系統(tǒng)用戶身份認證和系統(tǒng)數(shù)據(jù)傳輸安全等安全需求，其中數(shù)據(jù)傳輸安全包括數(shù)據(jù)防抵賴、完整性和保密性需求。 二、基于CA應用實現(xiàn)信息系統(tǒng)用戶身份認證 （一） 基于SSL協(xié)議雙向認證實現(xiàn)系統(tǒng)用戶身份認證 基于SSL協(xié)議雙向認證，能夠實現(xiàn)系統(tǒng)服務器和用戶認證，加密數(shù)據(jù)并防止數(shù)據(jù)中途被竊取，維護數(shù)據(jù)的完整性，確保數(shù)據(jù)在傳輸過程中不被改變。 （二） 基于簽名、驗簽實現(xiàn)系統(tǒng)用戶身份認證 首先在客戶端調(diào)用數(shù)字簽名的接口完成數(shù)字簽名，并生成簽名包，然后將該簽名包傳遞給服務器端，服務器端調(diào)用驗簽的接口對簽名包進行驗證，并將驗證結果返回給客

17、戶端。由于驗證簽名包時包含了完整的證書驗證功能，從而可以完成身份認證功能。 圖－4基于簽名、驗簽實現(xiàn)系統(tǒng)用戶身份認證流程 三、基于簽名/驗簽實現(xiàn)數(shù)據(jù)傳輸?shù)耐暾院头赖仲? 基于簽名/驗簽能夠實現(xiàn)系統(tǒng)間數(shù)據(jù)傳輸?shù)耐暾缘姆赖仲?。系統(tǒng)A在發(fā)送數(shù)據(jù)時，將擬發(fā)送的數(shù)據(jù)進行數(shù)據(jù)簽名，并將簽名數(shù)據(jù)和擬發(fā)送的數(shù)據(jù)等一同發(fā)送給系統(tǒng)B。系統(tǒng)B基于系統(tǒng)A發(fā)送過來的數(shù)據(jù)進行驗簽，驗證書數(shù)據(jù)在傳輸過程中的完整性，實現(xiàn)數(shù)據(jù)傳輸過程中的防抵賴和完整性安全需求。 四、基于數(shù)字信封實現(xiàn)數(shù)據(jù)傳輸?shù)谋Ｃ苄? 數(shù)字信封是對稱加密和非對稱加密相結合的CA應用，實現(xiàn)系統(tǒng)間數(shù)據(jù)傳輸?shù)谋Ｃ苄浴Ｔ谶M行數(shù)據(jù)傳輸時，通過生成隨機數(shù)，作

18、為對稱加密密鑰，實現(xiàn)擬發(fā)送數(shù)據(jù)的對稱加密；通過非對稱加密實現(xiàn)對稱加密密鑰的傳輸。 2.3.2.2. 應用模式 CA應用模式包括以下三種：B/S模式，即瀏覽器/服務器架構下的證書應用；C/S模式，即客戶端/服務器架構下的證書應用；S/S模式，即服務器/服務器架構下的證書應用，多為系統(tǒng)互聯(lián)。下面對這三種結構進行詳細說明。 一、B/S結構 B/S結構是目前普遍的應用系統(tǒng)結構，即客戶端以瀏覽器登錄服務器，實現(xiàn)業(yè)務操作的應用模式。 目前主流的Web服務器和主流瀏覽器都支持SSL協(xié)議，因此身份認證可以基于SSL實現(xiàn)。但由于SSL不能有效實現(xiàn)交易/行為的抗抵賴性和關鍵數(shù)據(jù)的保密性，所以還

19、需要在瀏覽器端和服務器端增加加解密/簽名驗證模塊，來真正實現(xiàn)交易/行為的抗抵賴性和關鍵數(shù)據(jù)的保密性。 具體實現(xiàn)中，需要在瀏覽器端需要配置個人證書，服務器端需要配置服務器證書。 針對IE瀏覽器，需要在客戶端安裝CSP模塊，加解密/簽名驗證模塊可以采用ActiveX技術實現(xiàn)；針對非IE瀏覽器如Netscape等，需要在瀏覽器端安裝Pkcs#11模塊，加解密/簽名驗證模塊可以采用Plugin或XPCOM技術實現(xiàn)。圖示如下： 瀏覽器 內(nèi)置SSL模塊 Web服務器 內(nèi)置SSL模塊 CSP模塊 加解密/簽名驗證模塊 證書/私鑰介質(zhì) CSP模塊 加解密/簽名驗證模塊 證書/私鑰介質(zhì)

20、 證書身份認證 交易/行為抗抵賴性 關鍵數(shù)據(jù)保密性 圖－5 CA應用B/S結構圖 二、C/S結構 C/S是以前比較流行的應用系統(tǒng)結構，即需要在客戶端部署客戶端軟件，用戶通過客戶端軟件登錄服務器，進行業(yè)務操作。 C/S結構一般都不支持PKI證書機制，為了實現(xiàn)證書應用，提高系統(tǒng)安全性，必須在客戶端和服務器端增加PKI安全模塊。 （一）安全代理方式 對于安全性要求不高或無法進行開發(fā)改造的C/S系統(tǒng)，可以采用安全代理技術，實現(xiàn)證書應用，提高身份鑒別的強度和數(shù)據(jù)傳輸?shù)陌踩裕缦聢D所示： 客戶端 C 服務器端 S 證書身份認證 數(shù)據(jù)傳輸保密性 證書/私鑰介質(zhì) 證書/私

21、鑰介質(zhì) 安全代理 客戶端 安全代理 服務器 圖－6 CA應用C/S結構圖（1） 采用安全代理技術，需要在客戶端部署安全代理客戶端，在服務器端部署安全代理服務器，由安全代理客戶端/服務器負責實現(xiàn)PKI證書機制，對原有的客戶端和服務器端沒有影響；客戶端/服務器與安全代理客戶端/服務器之間通過TCP/IP協(xié)議進行通信。 （二）2、API接口開發(fā)方式 對于安全性要求較高且能夠進行開發(fā)改造的C/S系統(tǒng)，可以采用API接口技術進行開發(fā)，實現(xiàn)證書應用，提高身份認證的強度，同時保證數(shù)據(jù)保密性、完整性以及交易/行為的抗抵賴性，如下圖所示： API接口包 客戶端 C 服務器端 S

22、數(shù)據(jù)完整性 交易/行為抗抵賴性 證書/私鑰介質(zhì) API接口包 證書/私鑰介質(zhì) 證書身份認證 數(shù)據(jù)保密性 圖－7 CA應用C/S結構圖（2） 采用API接口開發(fā)方式，需要分別在客戶端和服務器端利用API接口開發(fā)包進行接口開發(fā)改造，在客戶端/服務器端的業(yè)務處理邏輯中通過函數(shù)調(diào)用方式，調(diào)用證書API接口來實現(xiàn)PKI證書機制。 在客戶端需要配置個人證書，在服務器端需要配置服務器證書。 三、S/S結構 S/S結構即兩個服務器之間的數(shù)據(jù)交換，一般為不同應用系統(tǒng)之間的交換。S/S結構一般都不支持PKI證書機制，為了實現(xiàn)證書應用，提高系統(tǒng)安全性，必須在服務器兩端增加PKI安全模塊。

23、 1、（一）安全代理方式 對于安全性要求不是很高或無法進行開發(fā)改造的S/S系統(tǒng)，可以采用安全代理技術，實現(xiàn)證書應用，提高身份認證的強度和數(shù)據(jù)傳輸?shù)陌踩?，如下圖所示： 服務器端 S 服務器端 S 證書身份認證 數(shù)據(jù)傳輸保密性 證書/私鑰介質(zhì) 證書/私鑰介質(zhì) 安全代理 服務器 安全代理 服務器 圖－8 CA應用S/S結構圖（1） 采用安全代理技術，需要在服務器兩端都部署安全代理服務器，由安全代理服務器負責實現(xiàn)PKI證書機制，對原有的服務器端沒有影響，服務器與安全代理服務器之間通過TCP/IP協(xié)議進行通信。 在服務器兩端均需要配置服務器證書。 （二）2、API

24、接口開發(fā)方式 對于安全性要求很高且能夠進行開發(fā)改造的S/S系統(tǒng)，可以采用API接口技術進行開發(fā)，實現(xiàn)證書應用，提高身份認證的強度，同時保證數(shù)據(jù)保密性、完整性以及交易/行為的抗抵賴性，如下圖所示： API接口包 服務器端 C 服務器端 S 數(shù)據(jù)完整性 交易/行為抗抵賴性 證書/私鑰介質(zhì) API接口包 證書/私鑰介質(zhì) 證書身份認證 數(shù)據(jù)保密性 圖－9 CA應用S/S結構圖（2） 采用API接口開發(fā)方式，需要分別在服務器兩端利用API接口開發(fā)包進行接口開發(fā)改造，在服務器兩端的業(yè)務處理邏輯中通過函數(shù)調(diào)用方式，調(diào)用證書API接口來實現(xiàn)PKI證書機制。 在服務器兩端均需

25、要配置服務器證書。 3 應用流程和工作分工 首先通過流程圖從整體上介紹CA應用流程，其次根據(jù)整體流程分階段介紹工作內(nèi)容和參與部門的職責。 3.1. CA應用總體流程 CA應用總體流程根據(jù)CA應用實現(xiàn)過程涉及的不同階段來確定，包括CA應用需求提出、確認，制定CA應用方案，方案審核確認，CA應用開發(fā)實現(xiàn)，測試，證書發(fā)放、實施及運行維護幾個階段。詳細內(nèi)容如下： 第一步：業(yè)務部門提出CA應用需求。 第二步：在項目管理部門協(xié)助下，由建設部門細化CA應用需求，提交業(yè)務部門確認，建設部門根據(jù)業(yè)務部門的要求完善需求，若業(yè)務部門認可CA應用需求，則進入第三步。 第三步：建設部門制定CA應用方案。

26、 第四步：建設部門提交CA應用方案到項目管理部門。 第五步：項目管理部門組織審核確認CA應用方案。 第六步：建設部門根據(jù)項目管理部門審核意見進一步完善方案，若方案審核通過，則進入第七步。 第七步：建設部門獲取CA應用開發(fā)包，完成CA應用開發(fā)工作。 第八步：建設部門進行CA應用測試。 第九步：證書發(fā)放管理部門實現(xiàn)CA數(shù)字證書發(fā)放工作。 第十步：建設部門進行CA應用實施。 第十一步：運行部門進行系統(tǒng)運行。實施 建設部門 數(shù)字證書發(fā)放 證書發(fā)放管理部門 提出應用需求 業(yè)務部門 細化需求 建設部門 確認需求 業(yè)務部門 制定方案 建設部門 Y N

27、 金電公司 技術支持 方案審核確認 管理部門 編碼實現(xiàn) 建設部門 測試 建設部門 運維部門 運維 圖－10 CA應用總體流程圖 以下根據(jù)總體流程分階段的詳細描述各階段的工作內(nèi)容及參與的部門。 3.2. 需求階段 3.2.1. 工作內(nèi)容 提出CA應用的明確需求。 3.2.2. 參與部門與工作流程 第一步：由業(yè)務部門提出身份認證、防抵賴、完整性和保密性的安全需求。 第二步：業(yè)務部門將初步的安全需求提交項目建設部門進行細化，明確在業(yè)務系統(tǒng)中，具體那些業(yè)務需要進行數(shù)字簽名。 第三步：項目建設部門將細化的需求提交業(yè)務部門進行確認。 3.3. 設計階段 3

28、.3.1. 工作內(nèi)容 基于該指引，制定CA應用方案。 3.3.2. 參與部門與工作流程 第一步：項目建設部門根據(jù)業(yè)務部門確認的CA應用需求及本指引，制定CA應用方案。 第二步：項目建設部門將制定的CA應用方案提交項目管理部門。 第三步：項目管理部門組織審核確認項目建設部門提交的CA應用方案。 第四步：項目建設部門根據(jù)項目管理部門審核意見進一步修改完善CA應用方案。 第五步：項目管理部門將CA應用相關的測試、發(fā)證、技術支持等工作任務下達給金電公司和證書發(fā)放等部門。 3.4. 開發(fā)階段 3.4.1. 工作內(nèi)容 獲取CA應用開發(fā)包，完成在應用系統(tǒng)中的CA應用編碼實現(xiàn)。 3.4.

29、2. 參與部門及工作流程 第一步：一、項目建設部門領取CA應用開發(fā)包。 (一) 人民銀行內(nèi)部 項目建設部門首先從金電公司獲取符合系統(tǒng)開發(fā)需要的CA開發(fā)包。 (二) 外聯(lián)機構 （1） 京外外聯(lián)機構從當?shù)厝嗣胥y行科技處獲取CA應用開發(fā)包。 （2） 在京外聯(lián)機構從金電公司獲取開發(fā)包。 （3） 外聯(lián)機構簽署開發(fā)包使用承諾書。 第二步：二、項目建設部門完成編碼工作。 第三步：三、在開發(fā)中如果需要，項目建設部門可從金電公司獲取CA應用技術支持。 3.5. 測試階段 3.5.1. 工作內(nèi)容 對開發(fā)完成CA應用的系統(tǒng)進行聯(lián)調(diào)測試。 3.5.2. 參與部門及工作流程 第一步：一、項目

30、建設單位向金電公司申請測試證書，并獲取測試用CA配置文件。 （一）個人測試證書申請流程 1.證書申請者向金電公司申請個人測試證書。 2.金電公司批準申請。 3.金電公司發(fā)放USBKey為介質(zhì)的測試個人證書。 4.證書申請者從金電公司領取測試用個人證書、測試CRL和測試根證書，并辦理領取登記手續(xù)。 （二）服務器測試證書（機構測試證書）申請流程 1.證書申請部門使用專用工具生成證書申請文件，以郵件方式發(fā)送給金電公司。 2.金電公司將做好的測試證書、測試CRL和測試根證書發(fā)給申請者。 3.申請者將接收到的證書轉換為所需的PFX證書。 二、第二步：在聯(lián)調(diào)測試環(huán)境中，項目建設部門

31、完成測試證書和其他CA配置文件的系統(tǒng)配置。 第三步：三、項目建設部門進行聯(lián)調(diào)測試。 四、第四步：金電公司對聯(lián)調(diào)測試中出現(xiàn)的問題進行技術支持。 第五步：五、測試結束后，項目建設部門給出測試報告。 3.6. 上線實施階段 3.6.1. 工作內(nèi)容 配合應用系統(tǒng)完成系統(tǒng)上線的工程實施工作。 3.6.2. 參與部門及工作流程 第一步：一、業(yè)務部門上線前一個月向證書發(fā)放管理部門申請生產(chǎn)證書。具體內(nèi)容和工作流程參照《中國人民銀行內(nèi)網(wǎng)電子認證證書管理辦法（試行）》（銀辦發(fā)[2006]153號）執(zhí)行。 第二步：二、項目建設單位從金電公司獲取生產(chǎn)系統(tǒng)CA應用配置文件。 第三步：三、項目建設單位

32、完成系統(tǒng)關于生產(chǎn)證書和其他配置文件的系統(tǒng)配置。 3.7. 運維階段 3.7.1. 工作內(nèi)容 系統(tǒng)運維工作中，對與CA應用相關的問題進行技術支持。 3.7.2. 參與部門及工作內(nèi)容 第一步：一、系統(tǒng)運維部門從建設單位獲取與CA應用有關的配置文件及配置文檔。 第二步：二、明確生產(chǎn)證書的有效期，在證書到期前一個月向證書發(fā)放管理部門申請證書更新。 第三步：三、在系統(tǒng)運維中出現(xiàn)與CA有關的問題，可以從建設單位和金電公司獲取技術支持。 4 CA應用設計和實現(xiàn)的內(nèi)容 這部分內(nèi)容主要是針對CA應用設計和實現(xiàn)的內(nèi)容進行詳細介紹。 4.1. 確定CA應用需求類型 CA應用需求類型根據(jù)應用系統(tǒng)

33、的安全需求確定是以下一種或幾種的組合。 一、證書有效性的身份認證 二、數(shù)字簽名及驗簽的身份認證、防抵賴、數(shù)據(jù)完整性 三、傳輸?shù)谋Ｃ苄? 4.2. 確定實現(xiàn)方式 4.2.1. 軟件方式 一、 軟件實現(xiàn)方式內(nèi)容 軟件實現(xiàn)方式即應用系統(tǒng)根CA應用開發(fā)包及開發(fā)文檔，通過API接口調(diào)用開發(fā)實現(xiàn)CA應用。 二、 軟件版本 目前CA應用開發(fā)包包括如下版本： （一）Java版 跨平臺應用的開發(fā)包，不受硬件平臺、操作類型的限制。 （二）C版 1、.COM版 Windows平臺下的C語言版。 2、.C語言版 （1）AIX 32位平臺下的C語言版； （2）AIX 64位平臺下的C語

34、言版； （3）C語言源碼：對于其他操作系統(tǒng)和平臺類型環(huán)境，提供C語言源碼程序，開發(fā)單位在其環(huán)境進行編譯后使用。 三、 開發(fā)包獲取方式 參照附錄1獲取CA應用開發(fā)包。 4.2.2. 硬件方式 一、 硬件實現(xiàn)方式內(nèi)容 通過專用的硬件設備實現(xiàn)簽名、驗簽，提高簽名私鑰的安全性，解決服務器端高并發(fā)簽名、驗簽名的性能瓶頸問題。 二、 硬件接口版本 （一）JAVA接口 （二）C接口 4.3. 其他內(nèi)容 4.3.1. 撤銷列表下載方式 目前存在兩種撤銷列表（CRL）的下載方式，自動方式和手工方式。 一、自動方式 一般服務器端認證的對象數(shù)量多，為保證證書有效性，需要實時或定期更新CR

35、L，通過查詢以確定當前所驗證證書的有效性。 由金電公司提供撤銷列表下載工具，在應用系統(tǒng)安裝該工具：JIT Cinas CRL 1.0.8.4 for Aix Release或JIT Cinas CRL 1.0.8.4 for Windows Release，從CA中心自動下載更新應用系統(tǒng)本地的CRL。 二、手工方式 如果驗證的對象數(shù)量比較少，這樣不需要對CRL進行實時或定期更新，根據(jù)驗證對象證書的變化情況，通過手工更新撤銷列表，以便提供證書及撤銷列表的查詢服務。 4.3.2. 交叉認證 人民銀行與外部機構互聯(lián)時，如果雙方分別使用各自的CA體系，那么就需要進行不同CA域的交叉認證實現(xiàn)兩

36、家CA的互通，為雙方聯(lián)網(wǎng)系統(tǒng)建立安全信任關系，保障數(shù)據(jù)傳輸安全。 在實現(xiàn)交叉認證時，雙方基于標準的簽名結果格式進行數(shù)據(jù)交換，以便實現(xiàn)數(shù)據(jù)傳輸?shù)耐暾院头赖仲嚒? 4.3.3. 多應用加載的環(huán)境 這種情況的CA應用和以上情況是一致的，只是在服務器證書申請時需使用服務器域名的方式，不能再使用服務器IP地址。 4.4. 應用策略 應用策略的內(nèi)容明確了CA應用中需要明確的應用類型、實現(xiàn)方式、撤銷列表下載方式、是否需要進行交叉認證，然后確定CA應用模式。 4.4.1. 實現(xiàn)方式 一、如果服務器端既需要驗簽名、還要簽名，或服務器端并發(fā)業(yè)務量大，軟件方式無法滿足性能需求，從簽名私鑰的安全保護和性

37、能需求上考慮，需要使用硬件方式實現(xiàn)CA應用。 二、如果服務器端只是驗簽，并發(fā)量不大，軟件方式能滿足系統(tǒng)的性能需求，則使用軟件方式實現(xiàn)，需要選擇適合的開發(fā)包類型。 4.4.2. 撤銷列表下載方式 一、一般服務器端面向大量客戶端做驗簽認證客戶端身份，需要查詢撤銷列表，驗證客戶端證書是否被撤銷。這種情況需要安裝下載工具，自動下載并更新本地的撤銷列表。 二、如果需要驗證簽名的對象數(shù)量很少，為減少系統(tǒng)壓力和不必要的網(wǎng)絡資源消耗，在被驗證的證書發(fā)生變化時，通知驗證方，采用手工方式下載并更新本地的CRL。 4.4.3. CA應用模式實現(xiàn)方式 應用系統(tǒng)的結構類型決定了其CA應用的實現(xiàn)模式，應用系統(tǒng)

38、本身的結構類型如果為B/S、C/S或S/S，則CA應用對應相應的模式。 以下的實現(xiàn)模式主要是基于目前我行應用系統(tǒng)本身的結構體系及CA應用的實際模式總結的常見幾種情況。 4.4.3.1. B/S模式實現(xiàn)方式 B/S是目前比較流行的應用結構。這種模式下為服務器和瀏覽器之間通過配置SSL協(xié)議，建立安全通道，實現(xiàn)數(shù)據(jù)傳輸?shù)谋Ｃ苄裕⑼ㄟ^服務器端的CA應用接口開發(fā)、在瀏覽器安裝簽名/驗簽控件，實現(xiàn)身份認證、抗抵賴及數(shù)據(jù)完整性。 具體內(nèi)容如下： 一、建立SSL安全通道。 二、開發(fā)單位利用CA應用開發(fā)包，在服務器端實現(xiàn)CA應用中驗簽名的接口開發(fā)功能，客戶端（瀏覽器）需要安裝CA應用的OCX控件，

39、實現(xiàn)簽名功能。 三、向客戶端發(fā)放載體為USBKey的個人證書。 四、服務器端配置根證書和證書撤銷列表（CRL）。 五、服務器端需要安裝CRL下載工具，下載并更新本地的CRL。 這種模式為常用模式，典型應用為“貨幣金銀信息管理系統(tǒng)”。 4.4.3.2. C/S模式實現(xiàn)方式 C/S是以前比較流行的應用系統(tǒng)結構，目前很少應用。這種應用模式下服務器是可信的，服務器只對客戶端進行認證。利用數(shù)字簽名技術，服務器對客戶端進行身份認證，并防止關鍵業(yè)務的防抵賴操作，保證數(shù)據(jù)的完整性。具體內(nèi)容如下： 一、開發(fā)單位利用CA應用開發(fā)包，在服務器端和客戶端進行接口開發(fā)，在服務器端實現(xiàn)驗簽的功能，在客戶端實

40、現(xiàn)簽名功能。 二、向客戶端發(fā)放載體為USBKey的個人證書。 三、服務器端配置根證書和證書撤銷列表（CRL）。 四、服務器端需要安裝CRL下載工具，下載并更新本地的CRL。 這種模式目前人民銀行還沒有應用案例。 4.4.3.3. S/S模式實現(xiàn)方式 這種模式為服務器對服務器的模式,即交互雙方互為客戶端和服務器。兩端服務器互不信任，利用數(shù)字簽名技術實現(xiàn)雙向的身份認證、防抵賴和數(shù)據(jù)的完整性。具體內(nèi)容如下： 一、兩端服務器所部署的應用系統(tǒng)開發(fā)單位要在分別完成各自的CA應用開發(fā)（兩端的開發(fā)單位可能不同），根據(jù)各自的CA應用開發(fā)包，在兩端分別實現(xiàn)CA應用中簽名和驗簽名的接口開發(fā)功能。

41、二、向兩端服務器端發(fā)放服務器證書或簽名硬件設備證書。 三、兩端都要配置根證書和證書撤銷列表（CRL）。 四、是否需要安裝CRL下載工具，根據(jù)本服務器驗證的證書數(shù)量及實施的方便性決定。 這種應用模式的典型案例為國庫信息處理系統(tǒng)（TIPS）中人民銀行與外部機構之間數(shù)據(jù)交換中實現(xiàn)的CA應用。 4.4.3.4. 混合模式實現(xiàn)方式 混合模式指在一個應用系統(tǒng)中，CA實現(xiàn)的集中模式會同時出現(xiàn)兩種或兩種以上。 TIPS的CA應用為B/S和S/S的混合模式。 4.4.4. 其他情況 隨著技術更新和新的系統(tǒng)體系架構的出現(xiàn)，可能還會出現(xiàn)新的CA應用模式，需要在應用中進行總結。 4.5. CA應用模

42、板 CA應用模板以圖表的形式總括說明CA應用實現(xiàn)的三種情況。 模板 類型 條件及 策略 B/S模板 C/S模板 S/S模板 備注 應用系統(tǒng) 結構類型 瀏覽器/服務器結構 客戶端/服務器結構 應用系統(tǒng)之間的服務器/服務器結構 信任關系 服務器可信，客戶端不可信的單向認證 服務器可信，客戶端不可信的單向認證 兩端互不信任，雙向認證 實現(xiàn) 方式 服 務 器 根據(jù)性能需要選擇： 1、軟件方式（接口或代理均可） 2、硬件方式（需要服務器與專用硬件之間開發(fā)CA應用的通信接口） 根據(jù)性能需要選擇： 1、軟件方式（接口或代理均可） 2、硬件

43、方式（需要服務器與專用硬件之間開發(fā)CA應用的通信接口） 硬件方式（需要服務器與專用硬件之間開發(fā)CA應用的通信接口） 客 戶 端 安裝CA應用控件 軟件方式（接口或代理均可） CRL下載 安裝工具，自動下載 安裝工具，自動下載 自動或手動，根據(jù)驗證方需驗證的證書數(shù)量確定 證書使用 服 務 器 1、配置根證書； 2、（如果還需要進行交叉認證，還需配置對方CA的根證書）。 1、配置根證書； 2、如果還需要進行交叉認證，還需配置對方CA的根證書。 1、配置根證書 2、如果還需要進行交叉認證，還需配置對方CA的根證書； 3、申請服務器證書 客

44、 戶 端 申請個人證書 申請個人證書 應用情況 常用,貨金系統(tǒng)、TCBS、財務系統(tǒng)、紀檢系統(tǒng)、TIPS個人用戶的CA應用。 不常用，人民銀行沒有案例。 常用,TIPS與外聯(lián)機構互聯(lián)的CA應用。 28 5 附錄 5.1. CA應用開發(fā)包獲取方式 一、CA應用開發(fā)包獲取流程 CA應用開發(fā)包相關材料已下發(fā)省級數(shù)據(jù)中心，項目建設單位應根據(jù)應用系統(tǒng)自身實際情況選用不同的CA應用接口實現(xiàn)方式，CA應用流程如下： 閱讀“CA接口實現(xiàn)方式說明” 選擇CA實現(xiàn)方式 購買專用簽名服務器 硬件方式 簽署開發(fā)包使用承諾書，并領取開發(fā)包 軟件方式 通信接口開發(fā) 簽名驗

45、簽功能模塊開發(fā) 聯(lián)調(diào)測試：簽名服務器測試證書申請、測試環(huán)境配置、進行測試 聯(lián)調(diào)測試：生產(chǎn)系統(tǒng)服務器測試證書申請、測試環(huán)境配置、進行測試 系統(tǒng)上線：簽名服務器生產(chǎn)證書申請、生產(chǎn)環(huán)境配置、上線運行 系統(tǒng)上線：生產(chǎn)系統(tǒng)服務器生產(chǎn)證書申請、生產(chǎn)環(huán)境配置、上線運行 運行維護 針對以上流程的詳細解釋如下： 第一步：第一步：通過閱讀CA接口實現(xiàn)方式說明，項目建設單位根據(jù)自身情況選定使用軟件還是硬件方式實現(xiàn)CA應用。 第二步：第二步：接口開發(fā) （一）獲取開發(fā)工具 1.軟件方式免費獲取開發(fā)包 人民銀行提供免費CA應用開發(fā)包，項目建設單位需要和人民銀行簽署開發(fā)包使用承諾書，以避免開發(fā)

46、包因免費提供，在使用中出現(xiàn)商務糾紛，特別是用戶購買第三方開發(fā)服務導致的非授權使用。 在京的項目建設單位從人民銀行總行科技司或金電公司領取所需的開發(fā)包及證書申請工具KeyTool，京外項目建設單位從當?shù)厝嗣胥y行省級機構科技處領取所需的開發(fā)包和證書申請工具KeyTool。各項目建設單位應根據(jù)自己的應用環(huán)境領取適合自己的開發(fā)包。 開發(fā)包類型有JAVA、COM、C版三大類。其中C版開發(fā)包提供AIX（64）環(huán)境的開發(fā)包，其他平臺環(huán)境的C版開發(fā)包需要外聯(lián)機構根據(jù)C版源碼編譯獲取所需開發(fā)包。 2.使用硬件方式。 根據(jù)數(shù)字簽名驗證服務器產(chǎn)品及供應商基本要求，選擇CA簽名服務器供應商。 （二）CA應用

47、接口開發(fā) 1.軟件方式接口開發(fā) 項目建設單位領取開發(fā)包后，其開發(fā)團隊或第三方開發(fā)服務通過閱讀開發(fā)包中提供的開發(fā)文檔及開發(fā)示例，逐步完成CA應用接口開發(fā)，實現(xiàn)簽名、驗簽等功能模塊。 2.硬件方式接口開發(fā) 購買簽名服務器硬件設備后，項目建設單位只需要基于CA簽名服務器的接口，實現(xiàn)簽名、驗簽等功能。 第三步第三步：：聯(lián)調(diào)測試 （一）軟件方式 1.需要使用專用工具（KeyTool）申請測試用服務器證書； 2.將開發(fā)環(huán)境的CA配置文件替換為測試對應的配置文件進行聯(lián)調(diào)測試。 （二）硬件方式 1.用CA簽名服務器自帶的證書申請功能完成測試證書申請； 2.完成CA簽名服務器測試環(huán)

48、境CA配置，進行聯(lián)調(diào)測試； 第四步：第四步：系統(tǒng)上線 （一）軟件方式 1.需要使用專用工具申請上線用服務器證書； 2.將測試環(huán)境的CA配置文件替換為生產(chǎn)環(huán)境對應的配置文件上線。 （二）硬件方式 1.用CA簽名服務器自帶的證書申請功能完成生產(chǎn)證書申請； 2.完成對簽名服務器生產(chǎn)環(huán)境CA配置，上線運行。 第五步： 第五步：運行維護 二、軟硬件CA應用接口實現(xiàn)方式的比較 為方便選擇CA應用接口實現(xiàn)，現(xiàn)對軟硬件CA應用接口實現(xiàn)方式從安全性與性能、開發(fā)測試及價格幾個方面進行比較。 （一）安全性、性能比較 1、安全性 在軟件方式中，簽名私鑰以證書文件形式存儲在硬盤上，用口令保護；

49、而且簽名驗簽運算在前置主機上實現(xiàn)，需要讀出證書文件中的私鑰進行簽名驗簽，這樣私鑰在內(nèi)存中駐留，安全性相對要低。 在硬件方式中，私鑰保存在CA簽名服務器的專用硬件中，簽名驗簽運算在簽名服務器硬件中實現(xiàn)，只將簽名、驗簽結果返給前置系統(tǒng)，私鑰不出硬件，安全性更高。 2、性能 軟件方式由于簽名驗簽模塊與前置系統(tǒng)共享主機資源，且簽名驗簽是CPU密集型運算，過多消耗主機資源，系統(tǒng)整體性能低。 硬件方式由于簽名服務器硬件獨立實現(xiàn)簽名驗簽，不占用主機資源，性能可實現(xiàn)數(shù)量級提高。 （二）開發(fā)、測試比較 軟件方式要在前置主機系統(tǒng)上基于開發(fā)包實現(xiàn)簽名驗簽功能，屬于緊耦合模式。 硬件方式由CA簽名服務器

50、獨立完成簽名驗簽功能，前置服務器只需要完成與簽名服務器的通信接口開發(fā)，避免了由于軟件方式緊耦合模式及應用環(huán)境導致的各種問題。 （三）價格比較 軟件方式的開發(fā)包免費獲得，進行接口開發(fā)的投入相對較少；硬件方式的簽名服務器價格相對較高。 注：根據(jù)以上提供的CA接口實現(xiàn)方式說明，項目建設單位結合自身的實際情況自主選擇使用軟件或者硬件方式實現(xiàn)CA應用。 四、技術支持 趙義斌：010-63568866-6305，13671398408，ybzhao@ 尚蕾：010-63568866-6303，shanglei@ 33 5.2. 人民銀行CA系統(tǒng)DN規(guī)則 DN組成 DN的具體內(nèi)容依

51、次由C、O、OU、CN幾部分組成。其中C用來表示國家；O用來表示組織機構，在一般的PKI DN標準中，它可表示為發(fā)放該證書的CA名稱;OU用來表示次級組織機構，為體現(xiàn)證書持有者的多種不同次級屬性，OU可分為兩級，即OU[1]和OU[2]來表示；CN用來表示用戶名。 人民銀行內(nèi)網(wǎng)CA DN的組成包括：C、O、OU[1]、OU[2]、CN五部分。 C定義 在DN中，C一般表示國家代碼。在人民銀行內(nèi)網(wǎng)CA中DN規(guī)則仍沿用國際慣例，定義為：C=CN;CN為中國的英文代碼。 O定義 在證書DN標準中，O一般表示組織機構。由于人民銀行內(nèi)網(wǎng)CA為CFCA根CA的子CA，遵循CFCA的O定義規(guī)則，

52、在人民銀行內(nèi)網(wǎng)CA DN規(guī)則中，定義為：O=PBC CA，表示該證書用戶為人民銀行CA的用戶。 OU[1]定義 OU在DN標準中一般表示為證書持有者所屬的次級組織機構。在人民銀行內(nèi)網(wǎng)CA DN規(guī)則中，OU[1]體現(xiàn)發(fā)放證書的RA系統(tǒng)和LRA機構。 RA系統(tǒng)使用RA系統(tǒng)編碼表示。RA系統(tǒng)編號為1位字符，從“1”開始編碼，每新增RA系統(tǒng)時依次遞增，具體如下： RA系統(tǒng) RA系統(tǒng)編碼 信管中心RA系統(tǒng) 1 LRA機構使用LRA所在組織的組織機構編碼表示。 OU[1]具體定義為：LRA組織機構編碼@RA系統(tǒng)編碼。LRA組織機構編碼與RA系統(tǒng)編碼之間以分隔符“@”分隔。 OU[1]示

53、例： OU[1]=113101000@1 表示為人行內(nèi)網(wǎng)CA信管中心RA系統(tǒng)河北石家莊中心支行LRA受理點所發(fā)證書 OU[2]定義 OU在DN標準中一般表示為證書持有者從屬的次級組織機構。人民銀行內(nèi)網(wǎng)CA DN規(guī)則中，將OU[2]定義為發(fā)放的不同證書類型，包括人員類和設備類兩個大類，具體而言包括以下五種子類： ● 個人單密鑰證書，名稱為：Operator 個人單密鑰證書，是頒發(fā)給人行工作人員的單密鑰證書，屬于人員類證書。所謂單密鑰證書，即證書持有者只有一張數(shù)字證書，使用該證書來完成相應的證書安全應用操作。 示例：OU[2]=Operator ● 個人雙密鑰證書，名稱為：Advan

54、ced Operator 個人雙密鑰證書，是頒發(fā)給人行工作人員的雙密鑰證書，屬于人員類證書。所謂雙密鑰證書，即證書持有者擁有加密、簽名兩張數(shù)字證書，加密證書用于加密目的、簽名證書用于簽名目的。 示例：OU[2]=Advanced Operator ● 服務器證書，名稱為：Server 服務器證書，是特指頒發(fā)給通用WEB服務器（如IIS、Apache等）和應用服務器（如Weblogic、Websphere）的證書，屬于設備類證書。 示例：OU[2]= Server ●設備證書，名稱為：Equipment 設備證書，是指頒發(fā)給硬件設備和軟件系統(tǒng)的證書，其適用范圍除前述適用服務器證書以

55、外的所有設備和軟件系統(tǒng)。在本DN規(guī)則中，設備證書目前僅適用網(wǎng)絡設備。 示例：OU[2]= Equipment ● RA操作員證書，名稱為：Ra Operator RA操作員證書，特指頒發(fā)給RA系統(tǒng)所有操作員和管理員的數(shù)字證書，它屬于人員類證書。 示例：OU[2]=Ra Operator 描述證書類型的每個英文單詞，第一個字母大寫，其余小寫。 根據(jù)業(yè)務系統(tǒng)的實際需要，可以擴充更多的證書類型，如：代碼簽名證書等等。 CN定義 CN的組成 CN是證書持有者的通用名（common name），它用以表征證書持有者的個體特性。它包括以下幾個字段： ● ☆主版本號：DN規(guī)則的主版本號，

56、目前為“01” ● ☆次版本號：DN規(guī)則的次版本號，目前為“0” ● ☆證件類型：表征證書持有者的證件類型，具體見0 ● ☆證件號碼: 表征證書持有者的證件的號碼。 ● ☆組織機構類別：證書持有者所屬的組織機構類別代碼。 ● ☆組織機構編碼：證書持有者所屬的組織機構編碼。 ● ☆擴展內(nèi)容：可自定義的擴展內(nèi)容。 ● ☆證書持有者順序號：表示該證書為證書持有者的第幾張證書，長度為1位字符，目前為“1”。 證件類型 DN中所包含的證件類型通過一位字符的編碼形式來體現(xiàn)，目前人民銀行CA系統(tǒng)只允許使用身份證作為證件，具體編碼規(guī)則如下： 證件類型 證件類型編碼 身份證 0 設備

57、類證書，目前已知包括服務器和網(wǎng)絡設備。其證件類型編碼規(guī)則為： 證件類型編碼 服務器證書 6 設備證書 M 證件號碼 證件號碼域填寫符合對應的證件類型的證件號碼內(nèi)容，具體規(guī)則如下： 證書類型 證件類型 證件號碼 證件號碼的解釋說明 個人單密鑰證書、個人雙密鑰證書、RA操作員證書 0、1、B、C、E、F、G 證件號碼 如申請證書時使用身份證，則“證件號碼”填身份證號碼 服務器證書 6 IP地址或域名 設備證書 M 網(wǎng)絡設備名稱，長度為3位字符 網(wǎng)絡設備名稱的編碼規(guī)則，見附件二《人民銀行內(nèi)網(wǎng)統(tǒng)一CA認證基礎設施建設數(shù)字證書DN網(wǎng)絡設備編碼規(guī)則》。

58、 證件類型及證件號碼示例： ● 0110101197201203264：表示證書持有者，是持身份證申請人員類數(shù)字證書，該證書持有者身份證號為“110101197201203264”。 ● 611.28.1.1：表示該張服務器證書持有者為一臺服務器，其IP地址為11.28.1.1。 ● M03：表示該設備證書持有者，為編號“03”的一臺路由器。 組織機構類別 組織機構類別由3位字符編碼表示，具體表示如下： 組織機構類別 編碼 中國人民銀行 489 根據(jù)中組部代碼手冊，人民銀行代碼為“489”。根據(jù)業(yè)務系統(tǒng)需要，有人民銀行以外單位需要使用數(shù)字證書時，組織機構類別編碼表可以進

59、行擴充。 組織機構編碼 組織機構編碼為6位或9位字符編碼表示。 擴展內(nèi)容 擴展內(nèi)容包括為由業(yè)務系統(tǒng)或用戶自行定義內(nèi)容，該內(nèi)容為非標準內(nèi)容。 對于人員證書，該部分內(nèi)容包括：人員拼音名和自定義內(nèi)容。具體定義為： 字段名 長度 解釋說明 拼音名長度 1字符位 標識拼音名的長度 拼音名 由”拼音名長度”定義其長度 人員的姓名全拼，使用小寫字母 自定義內(nèi)容 只受DN總長約束 用戶或業(yè)務系統(tǒng)自行定義，可為空 對于設備證書，該內(nèi)容為自定義內(nèi)容，也可為空。 CN規(guī)則示例 字段名 （長度） RA操作員證書 個人單密鑰、雙密鑰證書 設備證書 服務器證書 主版本號

60、 （2位） 01 01 01 01 次版本號 （1位） 0 0 0 0 @ 分隔符號 證件類型 （1位） 0：居民身份證 0：居民身份證 M：設備 6：服務器 證件號碼 相應的證件號碼 相應的證件號碼 網(wǎng)絡設備名稱 IP地址或域名 @ 分隔符號 組織機構類別（3位） 489：中國人民銀行 組織機構編碼（6或9位） 組織機構編碼 @ 分隔符號 擴展內(nèi)容 姓名長度＋姓名全拼音+可由LRA自定義內(nèi)容 姓名長度＋姓名全拼音+可由LRA自定義內(nèi)容 可由LRA自定義內(nèi)容（可以是英文/拼音名） 可由LRA自定義內(nèi)容

61、（可以是英文/拼音名） @ 分隔符號 證書持有者順序號 （1位） 證書持有者的證書順序號，目前為“1” cn實例 010@0110101197201203264@489111000@bliuxiaogang@1 010@0110101197201203264@489111000@bliuxiaogang@1 010@M03@489111000@ @1 010@6210.73.40.41@489111000 @@1 注： 分隔符（@）為保留字符，CN內(nèi)各字段內(nèi)容均不得使用。 補充說明 ● 1）在DN中，可以使用除專用字符和特殊字符外的所有ASCII字符。專用字符為反斜杠

62、（“\”）和雙引號(“"”)，由于在DN中有特殊含義，不能用在DN中。另外，不允許在cn中包含特殊字符（“，” 、“=” 、“+” 、“#” 、“<” 、“>” 、“;” ） 由于存在不可見的ASCII字符，不便于用戶使用，下面給出本規(guī)則中所有可用的ASCII字符列表（ASCII值為十進制數(shù)值）： ASCII值 字符 032 空格 033 ! 036 $ 037 % 038 & 039 ‘ 040 ( 041 ) 042 * 045 - 046 . 047 / 048~057 0~9 058 : 065 ? 065~090 A~Z 091 [ 093 ] 094 ^ 095 — 096 ` 097~122 a~z 123 { 125 } 126 ~ ● 2）考慮到人民銀行業(yè)務系統(tǒng)使用漢字字符集的多樣性，在人民銀行內(nèi)網(wǎng)CA/DN規(guī)則中不使用漢字。 ● 3)證書DN總長不超過255位字符。 42