專利名稱：可配置的在線公鑰基礎(chǔ)設(shè)施(pki)管理框架的制作方法
可配置的在線公鑰基礎(chǔ)設(shè)施(PKI)管理框架相關(guān)申請的聲明本申請要求2009年8月12日提交的美國臨時專利申請序列號No. 61/233，380的權(quán)益，通過參考將該申請的全部內(nèi)容合并于此。
背景技術(shù)：
公鑰密碼術(shù)是使用密鑰對來實現(xiàn)安全通信的方法。每個密鑰對包括公鑰和私鑰。 公鑰和私鑰相關(guān)，使得例如通過一個密鑰加密的消息僅通過另一個密鑰解密，但是在給定公鑰的情況下用計算的方式推導(dǎo)出私鑰是不可行的。除了消息加密之外，密鑰對還可用于執(zhí)行其他功能。私鑰通常由實體創(chuàng)建并安全持有；而通常使得對應(yīng)的公鑰廣泛可用。于是， 通過使用各方的公鑰和密鑰可實現(xiàn)各方之間的安全通信。公鑰密碼術(shù)的使用解決了諸如互聯(lián)網(wǎng)的開放網(wǎng)絡(luò)中很多內(nèi)在的安全問題。但是， 仍然有兩個明顯的問題。首先，參與者必須能夠以有效的方式訪問其他實體的公鑰。其次， 由于在很多協(xié)議中實體相互關(guān)聯(lián)，并且在某種意義上是通過它們的公鑰來識別的，所以必須有安全的方法讓各方核實某一公鑰被綁定到某一實體。公鑰基礎(chǔ)設(shè)施(PKI)系統(tǒng)解決了這兩個問題。在一個常見的方法中，公鑰基礎(chǔ)設(shè)施是基于數(shù)字證書，數(shù)字證書用于將某一公鑰對關(guān)聯(lián)到具有一定程度信譽的某一實體。公鑰管理基礎(chǔ)設(shè)施通常將包括數(shù)字證書的數(shù)據(jù)庫、發(fā)布證書的證書權(quán)力機構(gòu)以及用于認證各方的其他基礎(chǔ)設(shè)施。通常提供很多數(shù)字證書服務(wù)，以便建立、散布、維持和維護PKI中使用的公鑰以及關(guān)聯(lián)的數(shù)字證書。通常由CA或第三方運營商將這些服務(wù)提供給終端用戶。所提供的數(shù)字證書服務(wù)通常包括登記、狀態(tài)報告、檢索和搜索服務(wù)以及驗證、撤回、更新和替換服務(wù)。PKI系統(tǒng)中的CA執(zhí)行很多不同的功能。例如，登記服務(wù)向用戶提供關(guān)于他們身份的信息。CA核實該信息并基于該信息來創(chuàng)建有效的數(shù)字證書。狀態(tài)報告服務(wù)允許用戶確定數(shù)字證書是有效、撤回還是具有任何其他狀態(tài)。檢索服務(wù)允許用戶檢索數(shù)字證書的備份。 搜索服務(wù)允許用戶搜索符合某一搜索準則的數(shù)字證書。驗證服務(wù)允許用戶建立數(shù)字證書的有效性，或者是當前，或者是曾經(jīng)。撤回服務(wù)允許用戶和CA動作一致地撤回數(shù)字證書。更新服務(wù)允許用戶和CA聯(lián)合創(chuàng)建新的有效的數(shù)字證書，替換要期滿的數(shù)字證書。替換服務(wù)允許CA創(chuàng)建新的有效的數(shù)字證書，替換已經(jīng)撤回的數(shù)字證書。在信息技術(shù)時代，PKI技術(shù)被組織廣泛采用，以在它們提供的產(chǎn)品和服務(wù)中實現(xiàn)安全特征。良好實現(xiàn)的PKI系統(tǒng)及其關(guān)聯(lián)的實踐和程序通常深度涉及組織的產(chǎn)品開發(fā)過程， 從設(shè)計階段到制造階段始終如此。但是，每個組織通常有它自己的安全策略、不同的制造過程和獨特的工程協(xié)作風(fēng)格。所有這些不同導(dǎo)致開發(fā)需要由每個組織維持的復(fù)雜和定制的 PKI系統(tǒng)。當通過諸如聯(lián)盟的外部方來定義和實行安全策略時，情況變得更加復(fù)雜。因為很多公司互相協(xié)作地開發(fā)了越來越多的標準或技術(shù)，所以聯(lián)盟正在變成用于保護涉及的所有方的最大利益的普遍實體。因此，聯(lián)盟的PKI系統(tǒng)與參與者組織的自產(chǎn)PKI系統(tǒng)之間的整合變成每個參與者組織都必須應(yīng)對的重要而有挑戰(zhàn)性的任務(wù)。由于很多產(chǎn)品開發(fā)項目的多元化性質(zhì)而造成在一些情況下組織涉及多個聯(lián)盟。對于聯(lián)盟來說，維持支持參與公司施加的各種安全要求的復(fù)雜PKI系統(tǒng)可能非常困難。因此，良好整合的PKI平臺可以由多個聯(lián)盟以及它們的參與公司使用，使得它們能夠從聯(lián)盟和參與者組織卸下大量開銷，從而允許它們專注于產(chǎn)品開發(fā)。

發(fā)明內(nèi)容
根據(jù)本發(fā)明的一個方面，提供了一種用于建立用于提供由PKI系統(tǒng)遞送的數(shù)字證書服務(wù)的過程的方法。該方法包括接收對數(shù)字證書服務(wù)的請求以及接收指定包括要被提供數(shù)字證書的至少一個產(chǎn)品的項目的數(shù)據(jù)。還接收指定所述項目的所有者組織以及參與所述項目的至少一個參與者組織的標識的數(shù)據(jù)。從所述所有者組織接收要在所述數(shù)字證書中包括的PKI數(shù)據(jù)應(yīng)當符合的屬性?；谒邮盏降臄?shù)據(jù)和屬性，為與所述項目相關(guān)聯(lián)的組織中的每個組織建立賬戶，與所述組織中的每個組織相關(guān)聯(lián)的用戶通過所述項目能根據(jù)從所述所有者組織接收到的所述屬性分別請求用于所述至少一個產(chǎn)品的數(shù)字證書。根據(jù)本發(fā)明的另一個方面，提供一種使得參與至少一個項目的多個組織能夠提供用于所述項目的定制數(shù)字證書服務(wù)的系統(tǒng)。該系統(tǒng)包括賬戶管理組件，所述賬戶管理組件用于為與所述項目相關(guān)聯(lián)的所述組織中的每個組織建立賬戶，與所述組織中的每個組織相關(guān)聯(lián)的用戶通過所述賬戶能分別請求用于在所述項目中包括的至少一個產(chǎn)品的數(shù)字證書。 該系統(tǒng)還包括用戶管理組件，所述用戶管理組件被配置成認證和授權(quán)與所述項目的所有者組織以及參與所述項目的至少一個參與者組織相關(guān)聯(lián)的用戶，所述至少一個參與者組織被所述所有者組織指定為參與者組織。該系統(tǒng)還包括證書權(quán)力機構(gòu)(CA)管理組件，所述CA 管理組件被配置成生成至少一個用戶可定義的證書簡檔模板(CPT)，所述CPT建立用于由與所述項目相關(guān)聯(lián)的所有證書權(quán)力機構(gòu)發(fā)布的數(shù)字證書的數(shù)字證書格式。該系統(tǒng)進一步包括產(chǎn)品管理組件，所述產(chǎn)品管理組件被配置成(1)建立由所述所有者組織定義的屬性，要在所述數(shù)字證書中包括的PKI數(shù)據(jù)應(yīng)當符合所述屬性，以及( 建立要執(zhí)行的活動的工作流程，以便用已經(jīng)建立的所述屬性來生成所述數(shù)字證書。該系統(tǒng)另外包括PKI管理組件，所述PKI管理組件被配置成依照所述用戶管理組件、證書權(quán)力機構(gòu)管理組件以及所述產(chǎn)品管理組件來處理對來自與所述所有者組織或者所述參與者組織中的至少一個參與者組織相關(guān)聯(lián)的用戶的數(shù)字證書的用戶請求。


圖1示出PKI管理系統(tǒng)的一個實施方式的邏輯架構(gòu)。圖2示出在高等級上說明PKI數(shù)據(jù)請求處理所需要的圖1中的PKI系統(tǒng)的相關(guān)組件。圖3示出圖1所示的PKI服務(wù)組件130的邏輯架構(gòu)的更詳細視圖。圖4是項目、組織、賬戶和PKI系統(tǒng)的用戶之間的關(guān)系的說明性邏輯圖。圖5示出在PKI管理系統(tǒng)中建立新項目的過程。圖6示出具有三個等級的證書權(quán)力機構(gòu)層級。圖7是圖示證書權(quán)力機構(gòu)密鑰和它們的關(guān)聯(lián)證書怎樣鏈接到項目、組織項目賬戶以及產(chǎn)品的邏輯圖。圖8示出用于圖7所示的組織X和Y的根CA與子CA之間的關(guān)系。圖9示出CA鏈和與那些CA相關(guān)聯(lián)的CPT之間的關(guān)系的一個示例。圖10示出可呈現(xiàn)給用戶的報告摘要的示例。圖11示出圖示在PKI管理系統(tǒng)中怎樣分配ID范圍的一些示例。圖12是示出方法的示例的流程圖，現(xiàn)有項目的授權(quán)用戶通過該方法可以創(chuàng)建用于產(chǎn)品的產(chǎn)品證書。圖13示出處理流程的高級示例，系統(tǒng)可使用該處理流程來處理PKI數(shù)據(jù)。圖14是圖示訂單履行過程的狀態(tài)圖。圖15是可與PKI系統(tǒng)相關(guān)聯(lián)的組織層級的邏輯圖，其圖示可分配給系統(tǒng)用戶的各種角色。
具體實施例方式如下詳述，替代組織向不同組織提供不同服務(wù)的PKI系統(tǒng)，PKI管理系統(tǒng)可以向不同的聯(lián)盟以及它們的參與組織提供不同的服務(wù)。單獨的項目例如可以是提供要加載身份數(shù)據(jù)(諸如數(shù)字證書)以及可能的其他安全數(shù)據(jù)的一個或多個產(chǎn)品。每個項目可能涉及多個組織。通過這種方式可以改善在普通項目中涉及多個組織時出現(xiàn)的關(guān)于上述PKI系統(tǒng)的問題。如同這里使用的，組織指的是組成任何數(shù)量的個體的任何實體，不管法律結(jié)構(gòu)或狀態(tài)。 這樣的組織的非窮盡示例包括公司和企業(yè)，不管公有還是私有的，以及非盈利和盈利的，政府機構(gòu)或代理以及任何其他個體的群組甚至組織的群組。現(xiàn)在轉(zhuǎn)向附圖，圖1示出PKI管理系統(tǒng)的一個實施方式的邏輯架構(gòu)。該系統(tǒng)包括屬于三個組織A、B和C中的一個的多個用戶101A-101C(統(tǒng)稱101)。組織可以是公司，并且用戶可以是相應(yīng)公司的雇員。組織A、B和C都采用PKI管理系統(tǒng)的服務(wù)。用戶101通過互聯(lián)網(wǎng)110或者任何其他基于數(shù)據(jù)分組的廣域網(wǎng)與系統(tǒng)通信。在本示例中，用戶通過一個或多個web門戶服務(wù)器120來訪問系統(tǒng)、與系統(tǒng)交互，web門戶服務(wù)器120提供由基于客戶端的應(yīng)用(諸如常規(guī)的web瀏覽器)訪問的單一前端接口。屬于服務(wù)提供商托管組織的內(nèi)部系統(tǒng)管理用戶也可以通過互聯(lián)網(wǎng)或局域網(wǎng)(LAN)訪問系統(tǒng)?？蓪⒛承└呒壒芾砉δ軆H限于LAN訪問，不向公共網(wǎng)絡(luò)公開。PKI管理系統(tǒng)通常包括帶有一個或多個物理存儲裝置、數(shù)據(jù)庫以及各種處理引擎的一個或多個物理服務(wù)器計算機。特別地，在圖1所示的示例中，PKI管理系統(tǒng)包括一個或多個服務(wù)組件130，服務(wù)組件130通常駐留在執(zhí)行向客戶端101提供各種PKI服務(wù)的一個或多個應(yīng)用的應(yīng)用服務(wù)器上。在圖1中，示出5個邏輯服務(wù)組件或模塊基礎(chǔ)設(shè)施管理組件131、用戶管理組件132、產(chǎn)品管理組件133、CA配置管理組件134以及PKI數(shù)據(jù)管理組件 135。在高等級中，基礎(chǔ)設(shè)施管理組件實現(xiàn)在一個統(tǒng)一的系統(tǒng)中維持多個公鑰基礎(chǔ)設(shè)施和相關(guān)組織的能力。用戶管理組件定義了角色并在系統(tǒng)中準予對用戶的訪問。產(chǎn)品管理組件允許參與者組織根據(jù)各種產(chǎn)品的PKI需要來實現(xiàn)和管理他們自己的安全策略。CA配置管理組件用于管理各種CA和他們的策略以及他們與相應(yīng)組織以及產(chǎn)品的關(guān)聯(lián)。PKI數(shù)據(jù)管理組件135不僅提供常規(guī)的PKI數(shù)據(jù)生命周期管理，而且提供端到端請求和遞送服務(wù)。
再參照圖1，PKI管理系統(tǒng)還包括訂單履行處理器140，訂單履行處理器140生成用戶為產(chǎn)品請求的數(shù)字證書或其它身份數(shù)據(jù)。訂單履行處理器可包括或者可訪問硬件安全模塊(HSM) 145，其中可存儲CA的證書簽字密鑰和安全數(shù)據(jù)，用于由系統(tǒng)使用。PKI管理系統(tǒng)還包含記錄的數(shù)據(jù)庫150。這些記錄可屬于發(fā)布的數(shù)字證書、對新數(shù)字證書或安全數(shù)據(jù)的原始請求、審計數(shù)據(jù)、控制策略信息、組織信息、項目配置、賬戶關(guān)系、 產(chǎn)品配置、用戶信息以及其它必要的記錄類型。圖2示出在高等級上說明PKI數(shù)據(jù)請求過程所需要的圖1的相關(guān)組件。首先，如圖所示，認證用戶以保證他或她的身份。接著，用戶 (可以是參與組織的產(chǎn)品管理員或授權(quán)代表)通過互聯(lián)網(wǎng)110向web門戶服務(wù)器120提交請求，web門戶服務(wù)器120進而將其轉(zhuǎn)發(fā)給訂單履行處理器140。訂單履行處理器140生成請求數(shù)據(jù)，隨后請求數(shù)據(jù)經(jīng)由web門戶服務(wù)器120和互聯(lián)網(wǎng)110被用戶101下載。圖3示出圖1所示的PKI服務(wù)組件130的邏輯架構(gòu)的更詳細視圖，其解決上述管理問題。如圖所示，PKI管理系統(tǒng)300的這些組件包括5個管理組件?；A(chǔ)設(shè)施管理組件 315包括項目管理子組件350、組織管理子組件351和賬戶管理子組件352。用戶管理組件 310包括用戶認證子組件312以及用戶授權(quán)和角色管理子組件314。CA配置管理組件320 包括即插即用子組件322和證書模板管理子組件324。產(chǎn)品管理組件330包括工作流程管理子組件332、產(chǎn)品簡檔定義管理子組件334和ID管理子組件336。PKI數(shù)據(jù)管理組件340 包含訂單處理管理子組件342、訂單履行管理子組件344和數(shù)據(jù)生命周期管理子組件346。 全體地，這些組件允許完全動態(tài)再配置的PKI管理系統(tǒng)，該PKI管理系統(tǒng)可以全部定制，不管怎樣，沒有任何系統(tǒng)停工期或者需要進行任何代碼改變。例如，可以添加新項目、可以添加或減少項目中的組織/賬戶、可以添加產(chǎn)品、可以修改項目中的證書鏈，所有都在事先已經(jīng)編碼的在線環(huán)境中。下面詳細討論每個前述組件和子組件?；A(chǔ)設(shè)施管理組件當出現(xiàn)對PKI相關(guān)系統(tǒng)基礎(chǔ)設(shè)施的新需要時，諸如新的網(wǎng)絡(luò)要求安全通信或者新的裝置類型要求專用安全數(shù)據(jù)時，在PKI管理系統(tǒng)中將創(chuàng)建新的項目。下面也將包括HiI 組件、組織、組織賬戶、用戶、產(chǎn)品以及制造裝置的項目稱為“基礎(chǔ)設(shè)施”。圖4示出項目、組織、賬戶和用戶之間的關(guān)系的說明性邏輯圖。本示例中包括兩個項目，即項目1和項目2 (或者PKI基礎(chǔ)設(shè)施1和PKI基礎(chǔ)設(shè)施2、。組織W和組織X只參與項目1。組織U和組織Z只參與項目2。組織Y既參與項目1也參與項目2。如圖所示，每個組織有一個賬戶用于它所關(guān)聯(lián)的每個項目。因此，當組織U、W、X和Z各自有單一賬戶時， 組織Y有兩個賬戶。每個項目被一個組織擁有；例如，項目1被組織W擁有，項目2被組織 U擁有。此外，一個組織可參與多個項目。同時，多個組織也可以參與一個項目。在每個組織中，用戶基于它們的角色和實體關(guān)系被授權(quán)對不同的實體(例如，組織、產(chǎn)品、項目等等) 執(zhí)行不同的動作。角色可包括但不限于策略權(quán)力機構(gòu)、授權(quán)代表、產(chǎn)品管理員、安全官員以及賬戶管理員。例如，如圖所示，用戶1_1和用戶Ul分別是項目1和項目2的項目管理員。 用戶X_1、用戶X_2、用戶Y_l、用戶Υ_2以及用戶Z_1是他們相應(yīng)組織的組織管理員?；诮M織在項目中的賬戶類型來推斷用戶的角色。例如，可以將項目1的策略權(quán)力機構(gòu)角色分配給用戶評_1，因為組織W有項目1的所有者賬戶。圖4還示出組織以及它們的用戶可跨域訪問不同的項目，這允許在一個PKI管理系統(tǒng)下共同托管多個公鑰基礎(chǔ)設(shè)施。下面將用具體示例幫助理解這里描述的PKI管理系統(tǒng)。應(yīng)當強調(diào)，僅通過說明的方式提出該說明性示例，并且不是作為對這里所述的方法、技術(shù)和系統(tǒng)的限制。在本示例中，項目1包括要加載數(shù)字證書的一系列不同WiMAXTM產(chǎn)品(例如，模型)的生產(chǎn)。單獨的 WiMAX裝置是WiMAX產(chǎn)品的一個實例。項目所有者(即組織W)例如可以是負責(zé)建立和管理 WiMAX標準的WiMAX聯(lián)盟。組織W具有項目1下的所有者賬戶，如圖4中的1_W所示。組織 X和組織Y可以是諸如生產(chǎn)WiMAX產(chǎn)品的獨立公司的實體，WiMAX產(chǎn)品是項目1的一部分， 并且這些組織希望獲取可以加載到它們相應(yīng)裝置中的數(shù)字證書或其它身份數(shù)據(jù)。組織X和組織Y都具有項目1下的參與者賬戶(1_X和1_Y)。類似地，項目2包括要加載數(shù)字證書或其它身份數(shù)據(jù)的一系列不同的長期演進 (LTE)產(chǎn)品的生產(chǎn)。LTE是已經(jīng)作為4G無線系統(tǒng)的候選者正式提交的移動通信標準。再一次，單獨的LTE裝置是LTE產(chǎn)品的一個實例。項目所有者(即組織U)可以是負責(zé)建立和管理LTE標準的LTE聯(lián)盟。組織U具有項目2下的所有者賬戶，如圖4中的2_U所示。組織 Y和組織Z可以是諸如生產(chǎn)LTE產(chǎn)品的獨立公司的實體，LTE產(chǎn)品是項目2的一部分，并且組織希望獲取可以加載到相應(yīng)裝置中的數(shù)字證書或其它身份數(shù)據(jù)。組織Y參與WiMAX項目 (項目1)，并且也參與LTE項目(項目2)。它具有兩個單獨的賬戶1_Y和2_Υ，其分別參與項目1和項目2?，F(xiàn)在將提出與本示例中每個項目的管理有關(guān)的一些一般特征和規(guī)則。首先，關(guān)于項目管理，假定在系統(tǒng)中每個項目只被一個組織擁有，但是多個組織可參與每個項目。此夕卜，項目策略只能被所有者組織修改。其次，關(guān)于組織的管理，每個組織可擁有多個項目并且多個組織可參與多個項目。因此接著，在PKI管理系統(tǒng)中每個組織可以有多個賬戶。圖5示出定義用于向PKI管理系統(tǒng)引進新項目的過程。在PKI管理服務(wù)供應(yīng)商在步驟510中從要求不同公鑰基礎(chǔ)設(shè)施的組織(例如聯(lián)盟)接收請求之后，在步驟512創(chuàng)建項目實體。例如使用基于web的管理門戶來創(chuàng)建項目，基于web的管理門戶只能由授權(quán)的托管組織的用戶(諸如服務(wù)托管管理員)來訪問。管理員通過該接口進入要在數(shù)據(jù)庫中存儲的任何相關(guān)項目信息，用于進一步的項目配置。如圖3所示，項目創(chuàng)建和規(guī)則由項目管理子組件350處理。一旦創(chuàng)建了項目，則如步驟520所示在需要的時候識別和創(chuàng)建所有者組織(組織可能已經(jīng)在系統(tǒng)中存在)。創(chuàng)建項目所有者賬戶以將組織鏈接到它的項目。注意，只能將一個組織指定為該項目的所有者，但是該邏輯組織可通過類似于典型聯(lián)盟的若干其他組織來管理并由其組成。在步驟530和532中，可以創(chuàng)建所有者組織的用戶賬戶并將其分別與項目相關(guān)聯(lián)。這些步驟可以在已經(jīng)建立所有者組織之后的任何時間發(fā)生。組織與其項目之間的所有者賬戶鏈接準予對各種配置值的適當控制以及對屬于其用戶的其他信息的訪問。在適當設(shè)置所有的組織、項目和用戶賬戶之后，諸如具有項目的策略權(quán)力機構(gòu)角色的某人的授權(quán)用戶在步驟540中配置項目。項目配置包括指定遍及基礎(chǔ)設(shè)施中要使用的項目屬性，包括但不限于PKI數(shù)據(jù)屬性、CA結(jié)構(gòu)以及各種其他安全和操作參數(shù)。在創(chuàng)建項目之后的任何時間，其他組織可以請求參與者賬戶。如果在系統(tǒng)中不存在組織，則可以通過授權(quán)的服務(wù)供應(yīng)商用戶在系統(tǒng)中創(chuàng)建組織，如同步驟550。一旦創(chuàng)建， 則在步驟552中項目參與者賬戶將參與組織鏈接到項目。然后如同步驟560和562所示， 可以創(chuàng)建適當?shù)挠脩糍~戶并將其與項目賬戶相關(guān)聯(lián)。這使得參與者組織能夠創(chuàng)建和配置產(chǎn)品，如同“產(chǎn)品配置管理”部分所述。
如圖3所示，分別通過組織和賬戶管理子組件351、352來管理組織和它們的賬戶的規(guī)則以及關(guān)系。下面將詳細討論用戶賬戶和管理。對于每個請求項目可以重復(fù)上述處理。系統(tǒng)的靈活性允許在運行時間添加和修改項目，而不中斷運轉(zhuǎn)的系統(tǒng)或者更改其實施方式。證書權(quán)力機構(gòu)(CA)配置管理組件在圖3中，證書權(quán)力機構(gòu)(CA)配置管理組件320包括兩個子組件即插即用管理 (子組件32 和證書模板管理(子組件324)。當生成CA證書時，在已知為密鑰儀式的程序中，在安全的離線環(huán)境下生成密鑰和證書。在圖6中，示出三等級CA鏈作為示例。根CA證書是自我簽名的。然后，通過根CA 驗證中間等級CA，并且通過中間CA驗證最低等級CA。在密鑰儀式之后，只將最低等級CA密鑰對直接導(dǎo)入硬件安全模塊630。將整個CA 證書鏈導(dǎo)入PKI管理系統(tǒng)的數(shù)據(jù)庫620中。插即用管理子組件322用于將CA密鑰和關(guān)聯(lián)的證書鏈接到項目、組織項目賬戶以及產(chǎn)品。如圖7所示，根CA與所有者組織賬戶1_A相關(guān)聯(lián)。為了不同的目的，所有者組織可具有一個或多個根CA。例如，項目可能需要一個服務(wù)器根CA用于服務(wù)器證書，并且需要另一個根CA用于裝置證書。同樣地，參與者組織可具有與所需要的一樣多的子CA，每個CA 按照不同產(chǎn)品的PKI需要定制。但是，項目的所有者組織可以限制可在根CA下面存在的子 CA的層級等級的數(shù)量。也可以限制層級等級中為參與組織存在的子CA的數(shù)量。子CA與諸如賬戶1_X和賬戶1_Y的對應(yīng)參與者組織賬戶相關(guān)聯(lián)。圖8示出用于圖7所示的組織X 和Y的根CA與子CA之間的關(guān)系。直接對運轉(zhuǎn)的系統(tǒng)執(zhí)行即插即用操作，而沒有任何服務(wù)中斷。圖3中的證書模板管理組件3 提供一種可配置機制，以保證數(shù)字證書在整個證書鏈中保持一致，并保持符合項目所有者的要求。例如，當子CA生成子等級證書時，該組件實行通過母CA建立的策略或約束。證書簡檔模板(CPT)被包括以定義要在派生證書中提供的所有要求的和可選字段。通過設(shè)計，每個CPT與一個CA相關(guān)聯(lián)。在生成數(shù)字證書之前， 圖3中的證書模板管理組件3 通過在證書鏈中向上搜索來定位任何相關(guān)CPT。任何這樣定位的CPT被用于實行由對應(yīng)CA施加的策略。圖9示出CA鏈和與那些CA相關(guān)聯(lián)的CPT之間的關(guān)系的一個示例。在該示例中， 根CA具有所有子CA都必須符合的用于整個項目的CPT (“項目CPT”)。用于公司A的子CA 在其CPT ( “公司A的CP”)中有更多具體或細微的要求，它們與根CA的CPT—致。另一方面，用于公司Bl的子子CA簡單地使用根CA的CPT。產(chǎn)品管理組件通過PKI管理系統(tǒng)保護的每個制造商的產(chǎn)品具有與其相關(guān)聯(lián)的要在數(shù)字證書中包括的產(chǎn)品特定屬性。這些屬性可包括例如數(shù)據(jù)格式、保護機制、標識(ID)類型以及生成數(shù)據(jù)而需要執(zhí)行的動作。為了特定產(chǎn)品而生成的所有PKI數(shù)據(jù)可具有共同的格式。但是， 當請求用于裝置的PKI數(shù)據(jù)時用戶對PKI管理系統(tǒng)的訪問被限制于具有對應(yīng)項目賬戶的組
幺口
/Ν O如圖3所示，產(chǎn)品管理組件330包括3個子組件工作流程管理組件332、簡檔定
1義管理組件334以及ID管理組件336。簡檔定義管理子組件334用于定義和管理產(chǎn)品的簡檔和屬性。產(chǎn)品屬性的示例包括產(chǎn)品名稱、產(chǎn)品制造商名稱、模型名稱以及產(chǎn)品中使用的芯片集的身份。簡檔信息包括進一步描述每個產(chǎn)品的細節(jié)，諸如用于唯一識別裝置實體(例如MAC地址)的簡檔類型、ID類型，和它所關(guān)聯(lián)的證書權(quán)力機構(gòu)，以及它所關(guān)聯(lián)的證書簡檔模板(CPT)。簡檔類型指示簡檔產(chǎn)生什么安全數(shù)據(jù)輸出。輸出可以是證書與對應(yīng)密鑰對的組合，或者只是基于證書簽名請求生成的證書。在后一情況下(僅證書簡檔)，通過參與組織單獨生成密鑰對，并將公鑰提交給PKI管理系統(tǒng)用于證書生成。這種情況要求參與組織具有密鑰對生成能力。ID管理子組件336控制ID的類型連同產(chǎn)品使用的分配范圍。ID類型的說明性示例包括MAC地址、序列號、完全合格域名(FQDN)、IP地址以及國際移動設(shè)備身份(IMEI)號。 所有者組織也可以定義用于其項目的其自己的ID類型。除了別的以外，ID管理組件336指定是否能夠?qū)P再用于產(chǎn)品。例如，當證書要更新時，ID可以被另一個產(chǎn)品或者被相同的產(chǎn)品再使用。如果沒有允許ID再使用，則該組件將防止請求用戶用復(fù)制ID生成數(shù)據(jù)。根據(jù)所有者組織和/或參與者組織建立的規(guī)則，ID管理子組件336還保證只將有效ID用于每個產(chǎn)品。對于符合標準格式的ID類型，該組件保證只使用適當和預(yù)分配范圍中的ID。例如，如果ID類型是MAC地址，則ID管理子組件336核實組織唯一標識符(OUI) 用于期望的組織。ID管理子組件336允許可能是參與組織的產(chǎn)品管理員的用戶指派用于產(chǎn)品的不同地址范圍。它還允許產(chǎn)品管理員指定獨立ID或者ID的范圍怎樣用于證書生成， 以用于他們的產(chǎn)品。例如，當請求用于裝置的PKI數(shù)據(jù)時，可由用戶輸入ID的特定值，或者可以選擇“下一個可用”地址選項(其自動計算ID的第一連續(xù)未使用分配)用于裝置的證書生成。在一些情況下，當選擇產(chǎn)品的ID范圍時，產(chǎn)品可能需要被指派一些特殊模式。例如，在地址的特定范圍內(nèi)，產(chǎn)品可以只使用偶數(shù)MAC地址，而保留每個奇數(shù)MAC地址用于不同接口。這稱為地址跳躍?；诋a(chǎn)品的定義，組織可以使用或可以不使用在另一個產(chǎn)品中已經(jīng)跳過的地址。ID管理子組件336也可以跟蹤ID資源的使用，并向用戶(其可以是賬戶管理員、 產(chǎn)品管理員或者具有參與者賬戶的組織的授權(quán)代表)提供信息化ID使用報告。可以跨產(chǎn)品和項目賬戶跟蹤和報告ID使用。這使得用戶能夠監(jiān)視預(yù)分配給授權(quán)賬戶的ID范圍的整體使用以及對每個獨立產(chǎn)品的使用細節(jié)。如圖10所示可以實時通過用戶界面生成ID使用報告，或可以根據(jù)特定商業(yè)要求將ID使用報告離線遞送給這些用戶。附圖示出用于特定產(chǎn)品的ID使用報告的示例。在該示例中，授權(quán)用戶能夠監(jiān)視由所選擇的產(chǎn)品使用并且在預(yù)分配給特定產(chǎn)品的選擇的地址范圍中的MAC地址范圍。在相同地址范圍中由其他產(chǎn)品使用的 MAC地址也可以用不同的顏色在相同的視圖中示出。該服務(wù)允許參與組織跟蹤和管理它們的身份使用。圖11示出了圖示在PKI管理系統(tǒng)中怎樣分配ID范圍的幾個示例。例如，產(chǎn)品1_ X ABC和產(chǎn)品1_X DEF都在用于項目1的組織X的賬戶1_X下。它們共享相同的ID類型。 但是，產(chǎn)品1_X ABC使用范圍0001-1000，而產(chǎn)品1_X DEF使用范圍5000-6000。另外，組織 Y參與兩個項目項目1和項目2。在用于項目1的其賬戶1_Y下的產(chǎn)品1_Y AAA使用在范圍2001-2500中的ID類型1，而在用于項目2的賬戶2_Y下的產(chǎn)品1_Y BBB使用在范圍 0x000-0x800 中的 ID 類型 2。
再參照圖3，產(chǎn)品管理組件330還包括工作流程管理組件332。工作流程定義基礎(chǔ)設(shè)施執(zhí)行的動作的順序，以生成并驗證用于特定產(chǎn)品的必要PKI數(shù)據(jù)。這些動作被稱為行為。例如，“生成RSA密鑰對”可以是一個行為，“核實證書”可以是另一個行為。行為是最小的可重新使用的單位。它們可以被多個工作流程共享。工作流程也可以在若干產(chǎn)品之間共享，或甚至跨多個項目共享。但是，每個產(chǎn)品只能有一個工作流程。工作流程管理組件332 定義和管理產(chǎn)品與工作流程之間的關(guān)系。當訂購某個產(chǎn)品時，執(zhí)行該產(chǎn)品的工作流程。一旦為現(xiàn)有項目登記了組織，則授權(quán)用戶(其可包括托管組織用戶或者來自參與組織的產(chǎn)品管理員)可以使用以下程序(其在圖12的流程圖中被圖示)來創(chuàng)建用于產(chǎn)品的產(chǎn)品證書。首先，在步驟1210中，用戶選擇與產(chǎn)品所屬的項目相關(guān)聯(lián)的賬戶。接著，在步驟 1220中，用戶將要與該產(chǎn)品相關(guān)聯(lián)的CA添加到賬戶(允許多個子CA用于相同的產(chǎn)品，只要它們在相同的證書鏈下)。在步驟1230中，從之前已經(jīng)為該組織建立的可用CPT的列表當中選擇CPT，并且用戶指定各種證書簡檔屬性，證書簡檔屬性導(dǎo)致產(chǎn)品證書簡檔(PCP)。在步驟1240中，由用戶分配ID類型。在步驟1250中，指定ID地址的可用范圍，連同當在可用范圍內(nèi)分配ID時要服從的特定規(guī)則(諸如地址跳躍)。最后，在步驟1260中，用戶選擇以適當?shù)母袷缴蒔KI數(shù)據(jù)的工作流程，使用所期望的保護方法等等。通過允許參與組織根據(jù)在線系統(tǒng)環(huán)境來配置它們的產(chǎn)品，組織能夠按照需要創(chuàng)建新產(chǎn)品，而不必等待或依靠托管組織的職員。PKI數(shù)據(jù)管理組件PKI數(shù)據(jù)管理組件340處理用于生成PKI數(shù)據(jù)并在數(shù)據(jù)的整個生命周期中維持該數(shù)據(jù)的用戶請求(“訂單”)。在邏輯上可將該組件劃分為三個子組件。訂單處理管理子組件342將訂單進行優(yōu)先級排序并分類。當授權(quán)用戶(諸如產(chǎn)品管理員或授權(quán)代表)提交訂單時，檢查訂單的若干屬性，以便確定履行訂單的順序。訂單履行管理子組件344根據(jù)由訂單處理管理子組件342指定的順序來執(zhí)行訂單。最后，數(shù)據(jù)生命周期管理組件346在數(shù)據(jù)的整個生命周期里維持已經(jīng)生成的PKI數(shù)據(jù)。在公共平臺中提供通過這些子組件遞送的服務(wù)產(chǎn)生很多好處。首先，通過將處理集中在一個系統(tǒng)中，可以將它們的處理優(yōu)化，因為可以使用負載平衡連同并行處理，并行處理相比于嘗試簡化每一個串行地訂購的若干系統(tǒng)一般更有效。另外，通過允許用戶在一個位置管理和監(jiān)視PKI數(shù)據(jù)而不是使用若干全異、專用系統(tǒng)，為用戶簡化了數(shù)據(jù)生命周期。因為PKI數(shù)據(jù)受單一系統(tǒng)(其具有遍及整個工作流程的控制)控制，所以可以更好地使HiI 數(shù)據(jù)安全，并且因此不需要依靠外部方來使數(shù)據(jù)安全。現(xiàn)在將更詳細地描述獨立子組件中的每一個。訂單處理管理組件342可以接收和處理很多訂單，并確定它們需要什么時候處理。在該過程中包括兩個主要考慮訂單優(yōu)先權(quán)和負載平衡。圖13示出系統(tǒng)可用來處理 PKI數(shù)據(jù)的處理流程的高級示例。圖3中的訂單處理管理組件342當選擇要處理的下一個訂單時可以考慮表征訂單的很多因素。通過說明的方式，這些因素包括優(yōu)先級、數(shù)量、請求類型、數(shù)據(jù)類型以及年齡等寸。可以通過請求用戶或者通過系統(tǒng)本身來指派優(yōu)先級值。如果其由用戶指定，則可以在適當?shù)牡胤皆O(shè)定一些限制，以防止用戶濫用并保證系統(tǒng)能繼續(xù)處理其他訂單。對于優(yōu)先級排序的服務(wù)，可通過要求更高的費用來施加這些限制。在一些情況下，諸如服務(wù)托管管理員的授權(quán)用戶可以對例外情況手動調(diào)節(jié)優(yōu)先級，或者可將系統(tǒng)配置成在預(yù)定義環(huán)境下自動調(diào)節(jié)某些訂單的優(yōu)先級。根據(jù)系統(tǒng)的當前負載，有時可以加快執(zhí)行要求少量數(shù)字證書的一些訂單，使得它們不被較大訂單阻塞。而且可將由系統(tǒng)處理的較大訂單的總量保持為低于某閾值，使得訂單履行處理器可以總是可用于更高優(yōu)先級訂單。該閾值不限制留在隊列中的訂單的數(shù)量。 訂單處理也可以考慮在訂單中包括的請求的類型。不同的請求類型(即，訂單的格式)一般要求不同量的處理，處理進而確定將需要多少時間來完成它。每個訂單還將具有通過πα 輸出數(shù)據(jù)的大小確定的數(shù)據(jù)類型、使用的生成算法、以及將確定相對于其他訂單中的數(shù)據(jù)實際上要多久來生成訂單中的數(shù)據(jù)的其他因素。例如，包含2048比特RSA密鑰的數(shù)據(jù)將比包含IOM比特RSA密鑰的數(shù)據(jù)要更久的時間來生成，并且該信息可幫助預(yù)測其履行訂單將花費的時間。還可以監(jiān)視訂單等待被處理的時間量。較舊訂單可給予相對于較近訂單某個等級的優(yōu)先級，使得沒有訂單被延遲不合理的時間量?？傊赏ㄟ^下面的等式來表示訂單的所計算的優(yōu)先級C。C = wp*P+wq*Q+wr*R+wd*D+wa*A在該等式中，使用每個參數(shù)的可配置權(quán)重(其中Wx是用于參數(shù)X的權(quán)重)與指派給參數(shù)自身的數(shù)值的乘積來計算每個被加數(shù)。每個參數(shù)(P、Q、R、D、A)分別表示上述優(yōu)先級、數(shù)量、請求類型、數(shù)據(jù)類型和年齡因素。該等式允許基于所有給定參數(shù)以定量方式來確定實時自適應(yīng)訂單優(yōu)先級排序。訂單處理管理組件342還可以考慮負載平衡。也就是說，除了選擇處理訂單的順序之外，還可以應(yīng)用負載平衡?？蓪⒂唵斡成涞娇捎玫奶幚韱卧?例如，訂單履行服務(wù)器)。 每個履行服務(wù)器可以處理訂單履行處理的多個線程。隨著系統(tǒng)增長，可添加越來越多的訂單履行服務(wù)器，每個服務(wù)器具有多個可用的處理核心?？梢允褂枚喾N負載平衡技術(shù)來處理輸入的訂單。例如，在一些情況下可以有兩種操作模式。在模式I中，將每個訂單指派給訂單履行服務(wù)器上的單一線程。當并行處理大量訂單時這種操作模式優(yōu)化了系統(tǒng)。在模式II 中，將一個訂單并行分布在若干訂單履行線程當中。當處理尺寸大的訂單時這種操作模式優(yōu)化了系統(tǒng)?？傊?，訂單處理管理組件342可基于各種因素將訂單排序，并使用負載平衡以并行方式來履行那些訂單。訂單處理的這樣的方法增強了系統(tǒng)的靈活性，同時可升級，使得容易服務(wù)于具有各種類型和數(shù)量的訂單的不同項目。這種負載平衡方案被稱為“訂單屬性和系統(tǒng)狀態(tài)驅(qū)動的負載平衡”，因為訂單類型連同系統(tǒng)狀態(tài)用于確定負載平衡方法。一旦已經(jīng)選擇訂單進行處理，則它就在其創(chuàng)建、生成和管理期間經(jīng)歷若干階段。該處理通過訂單履行管理子組件344來控制。結(jié)合附圖14描述該處理，附圖14是圖示訂單履行過程的狀態(tài)視圖。請求用戶可經(jīng)由用戶界面進行訂購，用戶界面可以是例如基于web 的門戶，所述基于web的門戶基于它從用戶接收到的數(shù)據(jù)動態(tài)地生成其關(guān)聯(lián)的圖形用戶界面。該過程當用戶創(chuàng)建訂單請求時開始。當組件處于創(chuàng)建狀態(tài)時，用戶可以選擇請求的類型(例如，證書撤回、更新或生成)以及如果適用的話，哪個產(chǎn)品要與該訂單相關(guān)聯(lián)。用戶界面首先提示用戶指定特定產(chǎn)品和請求類型(可能從下拉式菜單)。然后用戶界面向用戶呈現(xiàn)附加提示，以指定適合于這種類型訂單的其他類型的輸入數(shù)據(jù)。要求的其他輸入數(shù)據(jù)可包括例如一系列產(chǎn)品屬性、地址范圍或者請求某一數(shù)據(jù)文件的提示。在由用戶輸入數(shù)據(jù)以后，輸入被驗證為適合于做出的訂單的類型。在用于項目的組織賬戶的存在始終，向與托管組織相關(guān)聯(lián)的金融實體進行支付，然后用預(yù)先約定的比率將支付轉(zhuǎn)換為表示組織可生成的可用數(shù)量的證書的余額。例如，可將該余額分配給對應(yīng)的項目賬戶或者分配給具體產(chǎn)品?？梢杂墒跈?quán)用戶(諸如服務(wù)托管管理員)來更新賬戶的余額。然后可以在訂單提交期間推導(dǎo)出賬戶的余額，以保證請求的數(shù)量不大于用于給定賬戶和產(chǎn)品選擇的可用余額。此外，還可以在生成每個證書之前核實余額。該過程中的下一階段是未決批準狀態(tài)，假定要求這樣的批準，則在該階段期間，批準或者拒絕訂單。不要求批準的訂單被系統(tǒng)自動批準，實質(zhì)上使得該階段為可選的。一旦訂單已經(jīng)被批準，則它進入新的狀態(tài)，在此期間，訂單排隊用于處理。一旦已經(jīng)選擇訂單進行處理，則它進入進行中狀態(tài)，在此期間，由訂單履行服務(wù)器履行訂單。根據(jù)訂單的類型(例如，證書簽名請求或證書撤回請求)，可采用不同的處理模塊。在處理之后，已經(jīng)完成訂單，并且訂單進入已處理狀態(tài)。在一些情況下由于無效的用戶輸入或某種其他問題，一些輸出記錄可能沒有成功處理。如果發(fā)生錯誤，則系統(tǒng)執(zhí)行 “盡力”嘗試以生成它有可能做的所有輸出記錄，并且訂單輸出伴隨著日志，所述日志指示成功處理的那些記錄和未成功處理的那些記錄。接著，在下載狀態(tài)中，訂單中的輸出記錄被配置為適當?shù)母袷?，使得它們可以被請求用戶下載，通常以加密文件的方式(下面更詳細描述這種保護機制)。在下載了記錄之后，訂單進入已下載狀態(tài)，在此期間，用戶核實輸出記錄中的數(shù)據(jù)是正確的。這可以例如使用已經(jīng)提供給用戶的輔助應(yīng)用或程序來完成。最后，訂單進入關(guān)閉狀態(tài)。通過系統(tǒng)自動關(guān)閉訂單或者請求用戶確認訂單已經(jīng)履行來達到這種狀態(tài)。系統(tǒng)可以因為很多原因中的任何原因而自動關(guān)閉訂單。例如，由于訂單已經(jīng)被處理，所以可以在可配置的時間段已經(jīng)過去之后自動關(guān)閉該訂單。替代地，如果用戶確認該訂單，則訂單進入已確認狀態(tài)并立即關(guān)閉。通過這種方式，所有者組織可以控制系統(tǒng)生成數(shù)據(jù)的系統(tǒng)中的生命周期。另外，通過自動關(guān)閉訂單，鼓勵用戶積極監(jiān)視他們的數(shù)據(jù)并在關(guān)閉訂單之前確認其有效性。在一些情況下，所有者組織可以指定在已經(jīng)下載輸出記錄之后、在確認訂單之后關(guān)閉訂單、或者在某個其他時間段之后要立即關(guān)閉訂單。一旦訂單關(guān)閉，則可以將其存檔，并且為了安全目的，可以永久刪除與該訂單相關(guān)聯(lián)的任何私有數(shù)據(jù)。做出的每個訂單經(jīng)歷上述每個狀態(tài)，從而允許使用單一處理平臺。但是，雖然可以采用共同的過程，但是根據(jù)訂單類型，仍然可以以定制的方式來處理每個訂單，從而允許靈活性和可展開性。另外，共同處理狀態(tài)集合的使用允許系統(tǒng)更容易確定在任何給定時間任何訂單的狀態(tài)，而不管訂單類型。如果請求生成諸如私鑰的敏感數(shù)據(jù)，則根據(jù)由項目、參與組織或產(chǎn)品定義的保護策略來保護(例如，加密)該數(shù)據(jù)以用于其遞送。這種保護可以制定為使得數(shù)據(jù)只能被請求它的用戶訪問。使用與這樣一種方法相關(guān)的過程可以實現(xiàn)這一點，通過該方法將用戶認證到PKI管理系統(tǒng)。例如，如果用戶使用保護私鑰/公鑰對的USB令牌和由授權(quán)CA簽名的證書來與PKI管理系統(tǒng)進行認證(如同下面在用戶管理組件部分中所述)，則可以利用用戶令牌的公鑰來加密所生成的敏感數(shù)據(jù)。一旦遞送給用戶，則可以利用用戶的令牌上保護的私鑰將敏感數(shù)據(jù)解密來檢索數(shù)據(jù)。這樣的話，通過請求生成的敏感數(shù)據(jù)被鏈接到請求用戶并且只能被請求用戶訪問。圖3中的PKI數(shù)據(jù)管理組件340還包括數(shù)據(jù)生命周期管理子組件346，用于維持、 管理和監(jiān)視生成的PKI數(shù)據(jù)。這包括將PKI數(shù)據(jù)遞送給用戶的方式、將其歸檔的方式，包括歸檔持續(xù)時間以及撤回合并PKI數(shù)據(jù)的證書的時間和條件。為了簡化數(shù)據(jù)生成和維護并使其安全，PKI數(shù)據(jù)生命周期的所有方面都可以在 PKI管理系統(tǒng)中管理。PKI數(shù)據(jù)生命周期與用戶可提交的請求的類型有關(guān)。這些請求包括密鑰和證書生成、證書簽名請求、更新、證書撤回和數(shù)據(jù)存檔及刪除。密鑰和證書生成請求將使得利用指定范圍內(nèi)期望的輸入值和ID集合來生成用于給定產(chǎn)品的密鑰和證書。證書簽名請求使得基于包含多個請求的輸入文件來生成證書集合。更新請求將使得生成新的PKI數(shù)據(jù)以替換已經(jīng)期滿的數(shù)據(jù)。根據(jù)請求，這可以包括或可以不包括數(shù)據(jù)的“再鍵入”。如果其對應(yīng)的私鑰被泄漏，則做出證書撤回訂單(即，一批請求)。撤回請求使得更新對應(yīng)的證書撤回列表(CRL)。數(shù)據(jù)存檔和刪除策略確定當PKI老化時應(yīng)當(或者不應(yīng)當)怎樣維持H(I。這種策略可以指令將其一些數(shù)據(jù)存檔用于以后參考，而一旦已經(jīng)將一些敏感數(shù)據(jù)遞送給用戶，則將其從在線系統(tǒng)強制刪除，作為額外的安全措施。在一些情況下，通過允許只有請求密鑰的用戶才能發(fā)布它們，可以保護在系統(tǒng)中維持的密鑰。訂單生命周期的狀態(tài)由商業(yè)要求和安全策略驅(qū)動，安全策略可以包括訂單批準、密鑰刪除和數(shù)據(jù)存檔。在項目生命周期的始終，可以由項目所有者和參與者組織來定義這些限制。這使得能夠?qū)⒚總€PKI基礎(chǔ)設(shè)施配置成滿足其基礎(chǔ)設(shè)施中包括的每個組織的要求。這些PKI數(shù)據(jù)管理組件可提供以下特征實時自適應(yīng)訂單優(yōu)先級排序如同以上等式所示，可以實時確定訂單的優(yōu)先權(quán)，以基于若干因素在變動的系統(tǒng)中動態(tài)地對訂單進行優(yōu)先級排序。訂單屬性和系統(tǒng)狀態(tài)驅(qū)動負載平衡通過訂單的類型和若干其他訂單屬性以及系統(tǒng)的當前狀態(tài)來驅(qū)動該系統(tǒng)的負載平衡，諸如訂單的數(shù)量和訂單處理器的當前占有率。商業(yè)和安全策略驅(qū)動的訂單處理程序通過項目所有者和參與者組織在整個系統(tǒng)中定義的若干商業(yè)規(guī)則和安全策略來驅(qū)動所有訂單經(jīng)歷的狀態(tài)。相比于將處理狀態(tài)與系統(tǒng)中定義的其他策略隔離的其他系統(tǒng)，這是有利的。用戶管理組件來自每個組織的PKI管理系統(tǒng)的用戶與一個或多個賬戶相關(guān)聯(lián)，并經(jīng)歷認證和授權(quán)兩者。用戶可僅屬于一個組織，但是可以與他或她的組織的項目賬戶中的任何一個相關(guān)聯(lián)。通過賬戶關(guān)聯(lián)，用戶可以訪問選擇的一個或多個產(chǎn)品，用于用戶的組織所關(guān)聯(lián)的項目。 對于用戶關(guān)聯(lián)的每個項目賬戶，可以定義一個或多個角色集合。某些角色可以限制成特定賬戶類型。例如，策略權(quán)力機構(gòu)角色可以僅指派配給與所有者賬戶相關(guān)聯(lián)的用戶。每個角色在賬戶的范圍中準予用戶特定能力。通過這種方式，基礎(chǔ)設(shè)施可以創(chuàng)建和管理具有不同能力的各種用戶。在圖15中，在用戶圖標的右上方用不同的字母(即Α、Β和C)表示不同的用戶角色。用戶可以具有指派給每個賬戶關(guān)聯(lián)的多個角色，每個角色給予他們對系統(tǒng)的不同等級的訪問。例如，指派給賬戶的管理員角色可給予用戶管理與賬戶產(chǎn)品相關(guān)聯(lián)的其他用戶的能力。但是，該用戶不能管理與產(chǎn)品相關(guān)聯(lián)的ID地址分配。相反，指派給產(chǎn)品的相同的管理員角色可給予用戶管理與產(chǎn)品相關(guān)聯(lián)的ID地址而不是與項目所在賬戶相關(guān)聯(lián)的用戶的能力。圖15示出若干不同的示例。例如，用戶項目1管理員是用作所有者組織的組織A 的成員。用戶項目1管理員具有角色A。用戶產(chǎn)品ABC負責(zé)人是組織X的成員，并且可以通過角色B所述的能力訪問產(chǎn)品1_XABC。用戶組織X管理員是組織X的成員，并且具有角色 C的能力，以便利用項目1管理組織的賬戶。用戶組織Y項目負責(zé)人是組織Y的成員，并且以角色C利用項目1管理組織的賬戶，以及以角色B管理產(chǎn)品1_YAAA和2_Y BBB0對于更具體的示例，如前面圖4所示，用戶Y_1是項目1中的產(chǎn)品管理員，但是不能訪問項目2。類似地，用戶Y_2是項目1中的賬戶管理員，并且是項目2的授權(quán)代表。當在項目2的域中工作時，用戶Υ_2不具有訪問賬戶管理員的能力。一旦被認證，則用戶能夠訪問系統(tǒng)中他或她的賬戶所關(guān)聯(lián)的每個項目。用戶可以容易地在項目域之間切換，而不需要與系統(tǒng)進行重新認證。當切換項目域時，用戶被限制到所選擇的項目中準予的角色集合。如上所述，屬于服務(wù)供應(yīng)商之外組織的用戶可以被準予高級配置能力。項目所有者用戶可以配置用于他們項目的根證書授權(quán)，并且可以設(shè)置管理參與組織的PKI數(shù)據(jù)的生命周期和結(jié)構(gòu)的項目廣泛策略。項目參與者用戶可以創(chuàng)建新的產(chǎn)品并實時從各種CA鏈中選擇?？墒褂眯湃蔚淖C書鏈執(zhí)行用戶認證。特別地，可以向用戶提供安全令牌裝置(例如，USB令牌)，所述安全令牌裝置存儲私鑰/公鑰對以及通過授權(quán)的證書權(quán)力機構(gòu)簽名的證書。當用戶訪問PKI管理系統(tǒng)(例如通過web門戶來訪問其網(wǎng)站)時，令牌向系統(tǒng)提供公共證書對象。當用戶登錄系統(tǒng)時，將令牌的私鑰和證書用于認證以及提供對系統(tǒng)的安全訪問。例如，通過保證由授權(quán)的證書權(quán)力機構(gòu)簽名以及證書的二進制值與系統(tǒng)中存儲的期望值匹配，核實證書的有效性。如果證書變?yōu)椴豢稍L問(例如，如果令牌丟失或鎖定，則可能發(fā)生這種情況)，則證書失效，并且將不再認證用戶。生成新的證書和私鑰，以為用戶提供連續(xù)的訪問。當然，可以不使用基于令牌的認證而使用其他認證技術(shù)，或者除了使用基于令牌的認證之外也使用其他認證技術(shù)。認證和授權(quán)的過程可以相互不同和分離，或者它們也可以被組合。如果它們保持分離，則用戶的認證證書僅用于識別用戶?？梢詫⒂脩舻臋?quán)力機構(gòu)作為用戶的記錄的一部分存儲在系統(tǒng)內(nèi)。用戶的證書不提供關(guān)于用戶的權(quán)力機構(gòu)的任何信息，并且在用戶的賬戶關(guān)聯(lián)或授權(quán)角色改變的情況下不需要替換或更新。另一方面，如果將認證和授權(quán)過程組合， 則生成認證證書，指定用戶的項目賬戶關(guān)聯(lián)，在證書中包含的數(shù)據(jù)中指定用戶角色。這后一種方法可以提供授權(quán)的更嚴格模型，并且如果用戶的賬戶關(guān)聯(lián)或授權(quán)角色改變，則要求生成新的證書。如同本申請中使用的，術(shù)語“組件”、“模塊”、“系統(tǒng)”、“設(shè)備”、“接口”等等一般是要表示計算機相關(guān)實體，硬件、硬件與軟件的組合、軟件、或者執(zhí)行中的軟件。例如，組件可以是但是不限于在處理器上運行的處理、處理器、對象、可執(zhí)行、執(zhí)行的線程、程序和/或計算機。通過說明的方式，在控制器上運行的應(yīng)用和控制器都可以是組件。一個或多個組件可駐留在過程和/或執(zhí)行的線程中，并且組件可以位于一個計算機上和/或分布在兩個或多個計算機之間。 此外，可以使用標準編程和/或工程技術(shù)產(chǎn)生軟件、固件、硬件或者其任何組合以控制實施所公開的主題的計算機來將所要求保護的主題實現(xiàn)為方法、設(shè)備或者制品。這里使用的術(shù)語“制品，，目的是包括從任何計算機可讀裝置、載體或介質(zhì)都可以訪問的計算機程序。例如，計算機可讀存儲介質(zhì)可包括但不限于磁性存儲裝置(例如，硬盤、軟盤、磁帶...)、光盤(例如，壓縮盤(CD)、數(shù)字通用盤(DVD)...)、智能卡以及閃存裝置(例如，卡、 棒、鍵驅(qū)動)。當然，本領(lǐng)域技術(shù)人員將認識到，在不脫離所要求保護的主題的范圍或精神的情況下可以對該配置作出很多修改。
權(quán)利要求
1.一種建立用于提供由PKI系統(tǒng)遞送的數(shù)字證書服務(wù)的過程的方法，包括接收對數(shù)字證書服務(wù)的請求；接收指定包括要被提供數(shù)字證書的至少一個產(chǎn)品的項目的數(shù)據(jù)；接收指定所述項目的所有者組織以及參與所述項目的至少一個參與者組織的標識的數(shù)據(jù)；從所述所有者組織接收要在所述數(shù)字證書中包括的PKI數(shù)據(jù)應(yīng)當符合的屬性；以及基于所接收到的數(shù)據(jù)和屬性，為與所述項目相關(guān)聯(lián)的所述組織中的每個組織建立賬戶，與所述組織中的每個組織相關(guān)聯(lián)的用戶通過所述賬戶能夠根據(jù)從所述所有者組織接收到的所述屬性分別請求用于所述至少一個產(chǎn)品的數(shù)字證書。
2.根據(jù)權(quán)利要求1所述的方法，進一步包括基于從所述所有者接收到的所述屬性，生成根證書簡檔模板，所述根證書簡檔模板建立用于由與所述項目相關(guān)聯(lián)的所有證書權(quán)力機構(gòu)發(fā)布的數(shù)字證書的數(shù)字證書格式；從所述參與者組織中的第一參與者組織接收當包括在為所述第一參與者組織所關(guān)聯(lián)的所述項目中的第一產(chǎn)品發(fā)布的數(shù)字證書中時所述PKI數(shù)據(jù)應(yīng)當符合的第二屬性集合；基于從所述第一參與者組織接收到的所述第二屬性集合，生成第一子證書簡檔模板， 所述第一子證書簡檔模板建立用于由與所述第一參與者組織相關(guān)聯(lián)的子證書權(quán)力機構(gòu)發(fā)布的數(shù)字證書的數(shù)字證書格式。
3.根據(jù)權(quán)利要求1所述的方法，其中，從所述所有者組織接收到的所述屬性包括最小密鑰大小和證書有效期。
4.根據(jù)權(quán)利要求2所述的方法，其中，所述第二屬性集合包括PKI數(shù)據(jù)格式、用于識別產(chǎn)品的ID類型、以及生成所述PKI數(shù)據(jù)所需的一系列動作。
5.根據(jù)權(quán)利要求1所述的方法，其中，所述項目至少包括第二參與者組織參與的第二產(chǎn)品，并且進一步包括從所述第二參與者組織接收當包括在為所述第二參與者組織所關(guān)聯(lián)的所述項目中的第二產(chǎn)品發(fā)布的數(shù)字證書中時所述PKI數(shù)據(jù)應(yīng)當符合的第三屬性集合；基于從所述第二參與者組織接收到的所述第三屬性集合，生成第二子證書模板，所述第二子證書模板建立用于由與所述第二參與者組織相關(guān)聯(lián)的子證書權(quán)力機構(gòu)發(fā)布的數(shù)字證書的數(shù)字證書格式。
6.根據(jù)權(quán)利要求5所述的方法，進一步包括建立第一工作流程和與所述第一工作流程不同的第二工作流程，所述第一工作流程定義生成用于所述第一產(chǎn)品的數(shù)字證書所需的動作，所述第二工作流程定義生成用于所述第二產(chǎn)品的數(shù)字證書所需的動作。
7.根據(jù)權(quán)利要求1所述的方法，其中，建立第一賬戶用于第一參與者組織，并且進一步包括從所述第一參與者組織中的管理用戶接收所述第一參與者組織中要成為所述系統(tǒng)的授權(quán)用戶的至少第二用戶和第三用戶的指定，其中所述第二用戶被指派具有對所述第一參與者組織的賬戶的第一等級訪問的第一角色，并且所述第三用戶被指派具有對所述第一參與者組織的賬戶的第二等級訪問的第二角色，所述第二等級訪問不同于所述第一等級訪問。
8.一種使得參與至少一個項目的多個組織能夠提供用于所述項目的定制數(shù)字證書服務(wù)的系統(tǒng)，包括賬戶管理組件，所述賬戶管理組件用于為與所述項目相關(guān)聯(lián)的所述組織中的每個組織建立賬戶，與所述組織中的每個組織相關(guān)聯(lián)的用戶通過所述賬戶能夠分別請求用于在所述項目中包括的至少一個產(chǎn)品的數(shù)字證書；用戶管理組件，所述用戶管理組件被配置成認證和授權(quán)與所述項目的所有者組織以及參與所述項目的至少一個參與者組織相關(guān)聯(lián)的用戶，所述至少一個參與者組織被所述所有者組織指定為參與者組織；證書權(quán)力機構(gòu)(CA)管理組件，所述CA管理組件被配置成生成至少一個用戶能定義的證書簡檔模板(CPT)，所述CPT建立用于由與所述項目相關(guān)聯(lián)的所有證書權(quán)力機構(gòu)發(fā)布的數(shù)字證書的數(shù)字證書格式；產(chǎn)品管理組件，所述產(chǎn)品管理組件被配置成(1)建立由所述所有者組織定義的屬性， 要在所述數(shù)字證書中包括的PKI數(shù)據(jù)應(yīng)當符合所述屬性，以及(2)建立要執(zhí)行的動作的工作流程，以便利用已經(jīng)建立的所述屬性來生成所述數(shù)字證書；以及PKI管理組件，所述PKI管理組件被配置成依照所述用戶管理組件、證書權(quán)力機構(gòu)管理組件以及所述產(chǎn)品管理組件來處理對來自與所述所有者組織或者所述參與者組織中的至少一個參與者組織相關(guān)聯(lián)的用戶的數(shù)字證書的用戶請求。
9.根據(jù)權(quán)利要求8所述的系統(tǒng)，其中，所述證書管理組件進一步被配置成生成多個用戶能定義的證書簡檔模板，每個證書簡檔模板與關(guān)聯(lián)于所述參與者組織的證書權(quán)力機構(gòu)鏈中的證書權(quán)力機構(gòu)相關(guān)聯(lián)，使得子證書權(quán)力機構(gòu)具有符合母證書簡檔模板的子證書簡檔模板。
10.根據(jù)權(quán)利要求8所述的系統(tǒng)，其中，所述產(chǎn)品管理組件包括ID管理組件，所述ID 管理組件被配置成依照由所述項目所有者建立的規(guī)則將ID分配給與所述項目相關(guān)聯(lián)的產(chǎn)PΡΠ O
11.根據(jù)權(quán)利要求8所述的系統(tǒng)，其中，所述PKI管理組件進一步被配置成依照參與者組織的優(yōu)選來在所述PKI數(shù)據(jù)的整個生命周期管理和維持所述PKI數(shù)據(jù)。
12.根據(jù)權(quán)利要求8所述的系統(tǒng)，其中，所述PKI管理組件包括用于對用戶請求進行優(yōu)先級排序的訂單處理管理組件，并基于每個獨立請求的特性，使得每個請求以與其他請求串行的方式或者以并行的方式履行，在所述并行的方式中，請求的不同線程彼此同時處理。
13.根據(jù)權(quán)利要求8所述的系統(tǒng)，其中，所述賬戶管理組件經(jīng)由基于web的用戶接口、通過通信網(wǎng)絡(luò)對于用戶是能訪問的。
14.一種用于利用數(shù)字證書提供產(chǎn)品的方法，包括在與第一 PKI項目相關(guān)聯(lián)的第一產(chǎn)品中接收對要在產(chǎn)品中提供的第一序列的數(shù)字證書的第一請求，認證和授權(quán)提交所述請求的第一用戶；識別與所述第一用戶相關(guān)聯(lián)的第一組織以及所述第一 PKI項目的所有者組織；檢索與所述所有者組織的根證書權(quán)力機構(gòu)相關(guān)聯(lián)的根證書簡檔模板(CPT)以及由所述第一用戶所關(guān)聯(lián)的所述第一組織建立的至少一個附加CPT，其中所述根CPT指定所述第一序列的數(shù)字證書應(yīng)當符合的格式，并且所述至少一個附加CPT進一步指定當保持與所述根CPT格式一致時所述第一序列的數(shù)字證書應(yīng)當符合的格式；從所述第一用戶接收第一 PKI數(shù)據(jù)集合，所述第一 PKI數(shù)據(jù)集合指定用于要在所述第一序列的數(shù)字證書中包括的預(yù)定義屬性的值；以及使用所述第一 PKI數(shù)據(jù)集合來生成所請求的第一序列的數(shù)字證書，其中所述第一序列的數(shù)字證書依照所述根CPT和所述至少一個附加CPT。
15.根據(jù)權(quán)利要求14所述的方法，進一步包括在與所述第一 PKI項目相關(guān)聯(lián)的第二產(chǎn)品中接收對要在產(chǎn)品中提供的第二序列的數(shù)字證書的第二請求，認證和授權(quán)提交所述請求的第二用戶； 識別與所述第二用戶相關(guān)聯(lián)的第二組織；檢索由所述第二用戶所關(guān)聯(lián)的所述第二組織建立的至少一個其他CPT，其中所述至少一個附加CPT進一步指定當保持與所述根CPT格式一致時所述第二序列的數(shù)字證書應(yīng)當符合的格式；從所述第二用戶接收第二 PKI數(shù)據(jù)集合，所述第二 PKI數(shù)據(jù)集合指定用于要在所述第二序列的數(shù)字證書中包括的預(yù)定義屬性的值；以及使用所述第二 PKI數(shù)據(jù)集合來生成所請求的第二序列的數(shù)字證書，其中所述第二序列的數(shù)字證書依照所述根CPT和所述至少一個其他CPT。
16.根據(jù)權(quán)利要求15所述的方法，其中，生成所請求的第一和第二序列的數(shù)字證書包括基于在從所述第一和第二用戶接收到的所述PKI數(shù)據(jù)中包括的信息，分別向所述第一和第二序列的數(shù)字證書中的每一個提供產(chǎn)品ID。
17.根據(jù)權(quán)利要求14所述的方法，其中，所述第一請求由PKI系統(tǒng)接收到，并且所述數(shù)字證書由所述PKI系統(tǒng)生成，并且進一步其中認證和授權(quán)所述第一用戶包括授權(quán)所述第一用戶到由第一組織中的管理用戶指定的對PKI系統(tǒng)的第一等級訪問，所述管理用戶具有比所述第一用戶更高等級的特權(quán)。
18.根據(jù)權(quán)利要求15所述的方法，進一步包括；在與所述第一組織參與的第二 PKI項目相關(guān)聯(lián)的第三產(chǎn)品中接收對要在產(chǎn)品中提供的第三序列的數(shù)字證書的第三請求，認證和授權(quán)與所述第一組織相關(guān)聯(lián)的提交所述請求的第三用戶； 識別所述第二 PKI項目的第二所有者組織；檢索與關(guān)聯(lián)于所述第二所有者組織的第二根證書權(quán)力機構(gòu)相關(guān)聯(lián)的第二根證書簡檔模板(CPT)以及與由所述第一組織建立的證書鏈相關(guān)聯(lián)的CPT鏈，其中所述第二根CPT指定所述第三序列的數(shù)字證書應(yīng)當符合的格式，并且所述CPT鏈中的每個CPT進一步指定當保持與所述第二根CPT格式一致時所述第三序列的數(shù)字證書應(yīng)當符合的格式；從所述第三用戶接收第三PKI數(shù)據(jù)集合，所述第三PKI數(shù)據(jù)集合指定用于要在所述第三序列的數(shù)字證書中包括的預(yù)定義屬性的值；以及依照所述第二根CPT和所述CPT鏈來生成所請求的第三序列的數(shù)字證書。
19.根據(jù)權(quán)利要求14所述的方法，其中，所述第一組織是企業(yè)實體，并且所述第二組織是企業(yè)實體的聯(lián)盟。
20.根據(jù)權(quán)利要求18所述的方法，其中，所述CPT鏈中的每個CPT由與所述第一組織相關(guān)聯(lián)的不同子證書權(quán)力機構(gòu)來使用。
全文摘要
提供一種方法和設(shè)備，以建立用于提供由PKI系統(tǒng)遞送的數(shù)字證書服務(wù)的過程。所述方法包括接收對數(shù)字證書服務(wù)的請求以及接收指定包括要被提供數(shù)字證書的至少一個產(chǎn)品的項目的數(shù)據(jù)。還接收指定項目的所有者組織以及參與項目的至少一個參與者組織的標識的數(shù)據(jù)。從所有者組織接收要在數(shù)字證書中包括的PKI數(shù)據(jù)應(yīng)當符合的屬性?；谒邮盏降臄?shù)據(jù)和屬性，為與項目相關(guān)聯(lián)的每個組織建立賬戶，與每個組織相關(guān)聯(lián)的用戶通過該賬戶能夠根據(jù)從所有者組織接收到的屬性分別請求用于至少一個產(chǎn)品的數(shù)字證書。
文檔編號H04L9/28GK102474415SQ201080035525
公開日2012年5月23日 申請日期2010年8月12日 優(yōu)先權(quán)日2009年8月12日
發(fā)明者T·J·巴伯, 克里斯·加德納, 凱爾·斯圖爾特, 劉嘉勁, 周威霖, 奧斯卡·歐, 姚挺, 安妮·蔡, 王凡, 邱新, 陳李強, 陳纓 申請人:通用儀表公司