專利名稱：用于驗證用戶的公鑰框架和方法
技術(shù)領(lǐng)域：
本發(fā)明總體上涉及數(shù)字安全，更具體地說，涉及一種其中信賴方控制信任錨(trust anchor)的公鑰技術(shù)框架(framework)。
背景技術(shù)：
PKI(公鑰基礎(chǔ)設(shè)施)允許諸如因特網(wǎng)之類的基本上不安全的公共網(wǎng)絡(luò)的用戶通過使用公共和私有密鑰對來安全地并且私下地交換數(shù)據(jù)和執(zhí)行事務(wù)處理，其中所述公鑰是經(jīng)由信任的證書授權(quán)方(Certificate Authority)來獲得并且共享的。通過使用公鑰基礎(chǔ)設(shè)施，用戶可以被唯一地驗證。證書授權(quán)方使用證書數(shù)據(jù)存儲庫(repository)，其通常是LDAP(輕型目錄訪問協(xié)議，LightweightDirectory Access Protocol)目錄，用于存儲用戶證書和有關(guān)已撤消的證書的信息。
在傳統(tǒng)的PKI模型中，通常使用兩個因素的驗證方案，其中，用戶使用(1)由信任的證書授權(quán)方(CA)發(fā)布的私鑰/證書，以及(2)由信賴方發(fā)布的用戶ID(UID)/密碼。這種處理的典型實施例包括如下步驟1.信賴方向用戶詢問用戶的UID和密碼；2.用戶利用所述UID和密碼來作出響應(yīng)；3.信賴方相對于安全地存儲在憑證(credentials)數(shù)據(jù)庫中的信息來檢驗給出的UID和密碼。
4.使用私鑰和相應(yīng)的證書在SSL上向信賴方驗證用戶；5.信賴方萬維網(wǎng)(web)服務(wù)器檢驗如下信息a.證書沒有到期，b.證書由信任的發(fā)布CA簽名，
c.根據(jù)證書撤銷列表(Certificate Revocation List，CRL)分析(其中所述CRL是由發(fā)布CA創(chuàng)建并且控制的)，證書沒有被撤消。
傳統(tǒng)的PKI模型把發(fā)布方CA視為信任錨(trust anchor)。這意味著信賴方期望CA創(chuàng)建合法的證書，所述合法的證書用于把與預(yù)訂者(subscriber)(最終用戶)有關(guān)的信息與一公鑰唯一地綁定。所述模型還期望CA檢驗預(yù)訂者的身份并且檢驗在CA發(fā)布證書之前、預(yù)訂者的私鑰被安全地生成并存儲。在傳統(tǒng)的PKI中，信賴方無論在何種情況下都明確地信任CA。
在分布式多域PKI模型中，存在多個CA，他們之間建立有信任關(guān)系(分級結(jié)構(gòu)、交叉證明、網(wǎng)格等)。在證書確認(validation)期間，允許PKI的(PKI-enabled)應(yīng)用首先必須嘗試發(fā)現(xiàn)信任路徑，所述信任路徑可到達作為信任錨的CA級別，然后必須通過檢查由信任的CA發(fā)布的CRL/ARL(Authority Revocation List，授權(quán)方撤銷列表)來檢驗證書撤銷狀態(tài)。在一般情況下，信賴方必須知道每個CA的CRL/ARL的位置、格式和訪問。如果存在許多CA，并且如果證書是自己簽名的，那么這樣做會帶來相當(dāng)大的難題。
這些難題中的一些包括如下事實(1)預(yù)訂者需要使用公鑰技術(shù)由信賴方進行安全驗證；(2)預(yù)訂者可以使用由任何CA發(fā)布的證書，所述CA可以是信任的或者是不信任的；并且(3)預(yù)訂者證書可以是自己簽名的(例如使用PGP、OpenSSL或者其它專有應(yīng)用來進行)。
傳統(tǒng)的PKI模型無法有效地滿足這些要求，是因為(1)信賴方認為發(fā)布CA不值得信任(在信任錨的意義上講)，并且發(fā)布CA之間也許沒有定義任何信任關(guān)系；(2)在相同的環(huán)境下，自己簽名的和CA簽名的證書無法被輕易接納；并且(3)由于CA不被信賴方所信任，所以信賴方無法使用它們來進行證書撤銷狀態(tài)確認。
由此，在不同種類的復(fù)雜的大規(guī)模PKI的情況下，其中該大規(guī)模PKI包括自己簽名的證書和其數(shù)目可能不可預(yù)測并且隨著時間變化的獨立CA，傳統(tǒng)的PKI模型無法提供一致的信任級別，并且無法把那些CA以及自己簽名的證書用作信任錨。因此，存在對這樣一種PKI模型的需要，所述PKI模型可以有效地處理多個CA以及自己簽名的證書。

發(fā)明內(nèi)容
本發(fā)明通過提供一種公鑰技術(shù)框架來致力于解決上述問題以及其它問題，其中所述公鑰技術(shù)框架是基于對由信賴方控制的信任錨的定義的。在此模型中，信賴方安全地把已注冊用戶與相應(yīng)的用戶證書相綁定。用戶證書被存儲在用戶憑證存儲庫中，所述用戶憑證存儲庫由信賴方控制。此框架中的預(yù)訂者負責(zé)其私鑰的安全性并且獲得證書(類似于傳統(tǒng)的PKI)。然而，信賴方負責(zé)檢驗預(yù)訂者的身份，并且依照信賴方的用戶帳戶規(guī)定策略、標準、規(guī)則和過程來進行預(yù)訂者帳戶生命周期管理(對用戶給出的證書進行注冊、懸置(suspend)、刪除、更新等)。
依照第一方面，本發(fā)明提供了一種具有信賴方用戶驗證系統(tǒng)的公鑰(PK)框架，所述信賴方用戶驗證系統(tǒng)用于允許信賴方驗證用戶，其中所述PK框架把用戶證書置于信賴方的控制之下，并且其中所述信賴方用戶驗證系統(tǒng)包括用于在用戶憑證數(shù)據(jù)存儲庫中存儲從用戶那里接收的證書的存儲系統(tǒng)，其中所述證書是由多個不同的證書授權(quán)方發(fā)布的；用于管理與用戶相關(guān)聯(lián)的用戶憑證數(shù)據(jù)存儲庫中的記錄的管理系統(tǒng)；以及用于允許信賴方從用戶憑證數(shù)據(jù)存儲庫中檢取(retrieve)證書以便驗證用戶的確認系統(tǒng)。
依照第二方面，本發(fā)明提供了一種用于使用公鑰基礎(chǔ)設(shè)施(PKI)憑證來驗證用戶的信賴方驗證服務(wù)器，其中所述信賴方驗證服務(wù)器包括多個用于驗證用戶的信任錨，并且其中所述信任錨包括包含信任的證書授權(quán)方證書的密鑰庫(key store)；已注冊證書目錄；以及定制的萬維網(wǎng)服務(wù)用戶憑證檢驗應(yīng)用(custom web services usercredentials verification application)。
依照第三方面，本發(fā)明提供了一種允許信賴方在公鑰(PK)框架內(nèi)驗證用戶的方法，其中用戶憑證受到信賴方的控制，所述方法包括提供受控于信賴方的用戶憑證數(shù)據(jù)存儲庫；在用戶憑證數(shù)據(jù)存儲庫中存儲從用戶那里接收的證書，其中所述證書是由多個不同的證書授權(quán)方發(fā)布的；在信賴方處接收驗證用戶的請求；并且從用戶憑證數(shù)據(jù)存儲庫中檢取證書以便驗證用戶。
依照第四方面，本發(fā)明提供了一種用于使用公鑰基礎(chǔ)設(shè)施(PKI)憑證來驗證用戶的方法，包括如下步驟在信賴方驗證服務(wù)器處接收驗證用戶的請求；并且從多個信任錨中選擇至少一個信任錨來驗證所述用戶，其中用于驗證預(yù)訂者的多個信任錨包括包含信任的證書授權(quán)方證書的密鑰庫(key store)；已注冊證書目錄；以及定制的萬維網(wǎng)服務(wù)用戶憑證檢驗應(yīng)用。
依照第五方面，本發(fā)明提供了一種用于利用信賴方用戶驗證應(yīng)用的方法，其中用戶憑證受到信賴方的控制，所述方法包括提供計算機基礎(chǔ)設(shè)施，其可操作用于在受控于信賴方的用戶憑證數(shù)據(jù)存儲庫中存儲從用戶那里接收的證書，其中所述證書是由多個不同的證書授權(quán)方發(fā)布的；管理與信賴方相關(guān)聯(lián)的用戶憑證數(shù)據(jù)存儲庫中的記錄；并且允許信賴方從所述用戶憑證數(shù)據(jù)存儲庫中檢取證書以便驗證用戶。


根據(jù)如下結(jié)合附圖對本發(fā)明各個方面的詳細描述，將使本發(fā)明的這些以及其它特征更加易于理解，其中圖1描述了一種依照本發(fā)明的PK技術(shù)框架。
圖2描述了一種依照本發(fā)明的目錄系統(tǒng)。
圖3描述了依照本發(fā)明的具有多個信任錨選項的混合系統(tǒng)。
具體實施例方式
公鑰框架概述在本發(fā)明的第一實施例中，提供了這樣一種框架，其中信賴方使用與用戶憑證數(shù)據(jù)存儲庫相關(guān)聯(lián)的信任的實體目錄(Trusted EntitiesDirectory，TED)，其包含作為信任錨的已注冊的實體。所述用戶憑證數(shù)據(jù)存儲庫存儲與信賴方相關(guān)聯(lián)的每個用戶的證書。在此說明性的實施例中，被稱為預(yù)訂者的用戶預(yù)訂由信賴方提供的服務(wù)。除在用戶憑證數(shù)據(jù)存儲庫中存儲證書以外，還可以保存預(yù)訂者記錄，其包括諸如預(yù)訂者狀態(tài)之類的管理信息，所述預(yù)訂者狀態(tài)例如為已添加、已注冊、已刪除等。
為了確保安全，使用用戶注冊處理把證書安全地遞送到用戶憑證數(shù)據(jù)存儲庫，其中用戶注冊處理提供了綁定步驟?？梢允褂美绮捎孟嗷ヲ炞C的安全套接字層(secure sockets layer，SSL)，由信賴的應(yīng)用來驗證預(yù)訂者，并且可以通過使用相應(yīng)的TED記錄信息，由信賴的應(yīng)用來確認預(yù)訂者的狀態(tài)。
此方法與使用密碼進行用戶驗證相似，但是在該情況下，使用了非對稱的密鑰密碼技術(shù)，而不需要存儲基于密碼的安全信息。存儲在TED中的證書是可公開得到的。由此，雖然需要在TED中保護它們以免被未被授權(quán)的替代或者刪除，但是它們不需要被加密。這樣做較大地限制了信賴方對受損用戶憑證的責(zé)任。
每一預(yù)訂者的私鑰都是在預(yù)訂者的完全控制下進行維護的，并且由此應(yīng)當(dāng)永遠不會放棄預(yù)訂者的所有權(quán)。預(yù)訂者可以使用任何媒介(例如，令牌、智能卡、瀏覽器等)來存儲其PKI憑證。由于發(fā)布CA沒有被視為信任錨，所以此框架不要求檢查證書撤銷或者期滿狀態(tài)，除非信賴方?jīng)Q定使用組合方法。
現(xiàn)在參考圖1，示出了依照本發(fā)明的公鑰技術(shù)框架10的說明性實施例。在此例子中，預(yù)訂者15和17接收分別來自證書授權(quán)方12CA1和CA2的證書14、16。預(yù)訂者19具有自己簽名的證書18。因此，每一證書14、16、18的來源是唯一的。在此框架中，每一個預(yù)訂者15、17、19都把其證書14、16、18傳送至信任的實體目錄(TED)系統(tǒng)24，該系統(tǒng)由信賴方22控制。為了此實施例的目的，術(shù)語“控制”指的是信賴方22對TED系統(tǒng)24中的信息具有排他性的存儲、管理和訪問權(quán)利。TED系統(tǒng)24包括用戶憑證數(shù)據(jù)存儲庫25，用于存儲并且管理證書和預(yù)訂者記錄。在此實施例中，證書到用戶憑證數(shù)據(jù)存儲庫25中的傳送最好在是安全信道20上(例如，使用采用單向服務(wù)器驗證的SSL等)執(zhí)行的。傳送可以在例如當(dāng)預(yù)訂者預(yù)訂由信賴方提供的服務(wù)時執(zhí)行。例如，信賴方22可以提供在線零售，并且預(yù)訂者可以是客戶。當(dāng)預(yù)訂者例如在信賴方的網(wǎng)站上向信賴方22注冊時，可以從預(yù)訂者那里傳送證書并且將其存儲在用戶憑證數(shù)據(jù)存儲庫25中。
當(dāng)信賴方22需要檢驗預(yù)訂者15時，信賴方22(1)獲得預(yù)訂者15的數(shù)字簽名28(例如，采用預(yù)訂者的私鑰加密的消息摘要(digest))，(2)訪問用戶憑證數(shù)據(jù)存儲庫25，以便獲得預(yù)訂者15的公鑰，并且(3)解密數(shù)字簽名28，以便檢驗預(yù)訂者15。
現(xiàn)在參考圖2，示出了用于實現(xiàn)信任的實體目錄系統(tǒng)24的計算機系統(tǒng)30，其充當(dāng)所述框架的信任錨。信任的實體目錄系統(tǒng)24通常包括用于在數(shù)據(jù)庫41中存儲證書的存儲系統(tǒng)40，用于管理證書和預(yù)訂者帳戶信息的管理系統(tǒng)42，以及用于從數(shù)據(jù)庫41中搜索并且檢取證書的確認系統(tǒng)44。存儲系統(tǒng)40允許預(yù)訂者將其證書安全地遞送至數(shù)據(jù)庫41的預(yù)訂者記錄中。如上所述，每一預(yù)訂者記錄可以包括管理信息，其諸如為預(yù)訂者狀態(tài)(已添加、已注冊、已刪除等)。管理系統(tǒng)42允許信賴方22和/或預(yù)訂者管理其預(yù)訂者記錄。
計算機系統(tǒng)30可以作為服務(wù)器的一部分來實現(xiàn)。計算機系統(tǒng)30通常包括處理器32、輸入/輸出(I/O)34、存儲器36以及總線37。所述處理器32可以包括單個處理單元，或者可以跨越一個或多個處理單元而分布在一個或多個位置、例如客戶端和服務(wù)器上。存儲器36可以包括任何已知類型的數(shù)據(jù)存儲和/或傳輸介質(zhì)，包括磁性介質(zhì)、光學(xué)介質(zhì)、隨機存取存儲器(RAM)、只讀存儲器(ROM)、數(shù)據(jù)高速緩沖存儲器、數(shù)據(jù)對象等。此外，存儲器36可以駐留在單個物理位置上，包括一種或多種類型的數(shù)據(jù)存儲設(shè)備，或者依照各種形式跨越多個物理系統(tǒng)分布。
I/O 34可以包括用于往返于外部資源交換信息的任何系統(tǒng)。外部設(shè)備/資源可以包括任何已知類型的外部設(shè)備，其中包括監(jiān)視器/顯示器、揚聲器、存儲設(shè)備、其它計算機系統(tǒng)，手持設(shè)備、鍵盤、鼠標、語音識別系統(tǒng)、語音輸出系統(tǒng)、打印機、傳真機、尋呼機等?？偩€37在計算機系統(tǒng)30中的每一組件之間提供了通信鏈路，并且同樣可以包括任何已知類型的傳輸鏈路，其中包括電的、光學(xué)的、無線的等。雖然未示出，但是還可以把諸如高速緩沖存儲器、通信系統(tǒng)、系統(tǒng)軟件等之類的附加組件包括在計算機系統(tǒng)30中。
對計算機系統(tǒng)30的訪問可以在諸如因特網(wǎng)、局域網(wǎng)(LAN)、廣域網(wǎng)(WAN)、虛擬專用網(wǎng)絡(luò)(VPN)等的網(wǎng)絡(luò)上提供。通信可以經(jīng)由直接硬布線的連接(例如，串行端口)來進行，或者經(jīng)由可以利用有線線路和/或無線傳輸方法的任何組合的可尋址連接來進行。此外，還可以使用諸如令牌環(huán)網(wǎng)(Token Ring)、以太網(wǎng)、WiFi或者其它常規(guī)通信標準的常規(guī)網(wǎng)絡(luò)連接性。另外，可以通過常規(guī)的基于TCP/IP套接字的協(xié)議來提供連接性。在這種情況下，因特網(wǎng)服務(wù)供應(yīng)商可用于建立互連性。此外，如上所述，可以在客戶端-服務(wù)器或者服務(wù)器-服務(wù)器環(huán)境下進行通信。
混合信任錨在某些應(yīng)用中，希望實現(xiàn)一種使用多叉(mutli-pronged)方法來驗證預(yù)訂者的信任錨。依照此方式，驗證服務(wù)器可以被配置為使用多種可能方法中的一種來進行驗證?，F(xiàn)有的SSL/TLS協(xié)議(參見RFC2246)要求服務(wù)器檢驗為了進行驗證而給出的客戶端證書是由信任的CA簽名的。為了實現(xiàn)它，服務(wù)器通常在服務(wù)器的密鑰庫中存儲信任的CA證書的列表。除了檢驗CA簽名是可靠的以外，服務(wù)器還可以被配置為檢查與CA有關(guān)的證書撤銷列表(CRL)以便確認客戶端證書撤銷狀態(tài)。
在RFC 2246中規(guī)定的TLS實現(xiàn)方式假定簽名CA證書(或者相應(yīng)的CA鏈)是可用于客戶端驗證的唯一信任錨。本實施例允許服務(wù)器使用信賴方專用信任錨，在通常情況下，其不同于簽名CA以及相應(yīng)的CRL。它允許企業(yè)用自己簽名的證書或者由具有不一致的信任、法律地位、經(jīng)營范圍以及技術(shù)實現(xiàn)方式級別的不同CA發(fā)布的證書來驗證用戶。
依照本發(fā)明的此說明性的實施例，所述TLS協(xié)議被修改為包括信賴方專用信任錨信息。它可以是在RFC 2246中略述的簽名CA或者CA鏈，或者是專用于特殊信任錨實現(xiàn)方式的協(xié)議數(shù)據(jù)。例如，信賴方客戶端的驗證設(shè)計可以基于對自己簽名的證書或者由不同CA發(fā)布的證書的使用。在此特殊實例中，可以把已注冊用戶的證書存儲在數(shù)據(jù)存儲庫中，并且可被信賴方視為是值得信任的(例如，如以上在圖1和2中所述那樣)。通過使用受托方(depository)專用協(xié)議(例如，LDAP、SQL、HTTPS、SOAP等)，可以相對于此數(shù)據(jù)存儲庫來確認客戶端證書的信任和撤銷狀態(tài)。
所提供的方法包括如下用戶驗證選項1.信賴方驗證服務(wù)器接收來自用戶的驗證證書(經(jīng)由數(shù)字簽名)。
2.基于信賴方信任錨實現(xiàn)方式，所述驗證服務(wù)器執(zhí)行下述操作之一a.檢驗所述用戶證書是由在服務(wù)器的信任的CA證書庫(store)中公布的信任的CA簽名的(基于RFC 2246的方法)；或者b.相對于已注冊用戶證書的LDAP目錄56(備選的信任錨)或者某個其它數(shù)據(jù)存儲庫58來檢查證書；和/或c.使用萬維網(wǎng)服務(wù)機制把接收的證書發(fā)送至指定的遠程萬維網(wǎng)應(yīng)用(備選的信任錨)以便進行檢驗。
圖3描述了用于實現(xiàn)混合信任錨的說明性的實施例。在該情況下，當(dāng)預(yù)訂者50向信賴方驗證服務(wù)器52提交SSL證書62時，信賴方驗證服務(wù)器52可以使用一個或多個用于驗證預(yù)訂者50的機制。選項包括使用信任的CA證書庫54(諸如EQUIFAXTM、GTETM、MICROSOFTTM、VERISIGNTM等)，使用已注冊證書的LDAP(輕型目錄訪問協(xié)議)目錄56，或者使用其它用于提供已注冊證書的憑證數(shù)據(jù)庫58的數(shù)據(jù)庫技術(shù)(例如，使用諸如JDBC(Java DataBaseConnectivity，Java數(shù)據(jù)庫連接性)、ODBC(Open DataBaseConnectivity，開放式數(shù)據(jù)庫連接性)、SQL(Structured QueryLanguage，結(jié)構(gòu)化查詢語言)、所存儲的過程等之類的訪問協(xié)議)，或者例如使用HTTP/SOAP萬維網(wǎng)服務(wù)實現(xiàn)的定制的萬維網(wǎng)服務(wù)信任錨應(yīng)用60。
此方法識別各種可由信賴方使用的信任錨，以便當(dāng)用戶驗證證書是自己簽名的或者是由任意CA簽名的時、更加有效地滿足各種驗證要求。此方法允許信賴方實現(xiàn)集中化的信任錨模型，其可以跨越分布式大規(guī)模企業(yè)環(huán)境而被有效地管理。
應(yīng)該理解的是，本發(fā)明的教義是作為在預(yù)訂或者付費基礎(chǔ)上的商業(yè)方法而提供的。例如，信任的實體目錄系統(tǒng)或者混合系統(tǒng)可以由服務(wù)供應(yīng)商來創(chuàng)建、維護、和/或利用，所述服務(wù)供應(yīng)商為客戶提供此處所述的功能。也就是說，服務(wù)供應(yīng)商可以如上所述提供信任錨服務(wù)。
應(yīng)該理解的是，此處所述的系統(tǒng)、功能、機制、方法、引擎和模塊可以以硬件、軟件或者硬件和軟件的組合實現(xiàn)。它們可以通過任何類型的計算機系統(tǒng)或者其它適合于執(zhí)行此處所述的方法的設(shè)備來實現(xiàn)。硬件和軟件的典型組合可以是具有計算機程序的通用計算機系統(tǒng)，當(dāng)載入并且執(zhí)行所述計算機程序時，該程序控制所述計算機系統(tǒng)，以使其執(zhí)行此處所述的方法。作為選擇，還可以利用包含用于執(zhí)行本發(fā)明的一個或多個功能任務(wù)的專用硬件的專用計算機。在進一步的實施例中，本發(fā)明的一部分例如可以在諸如因特網(wǎng)之類的網(wǎng)絡(luò)上依照分布式方式來實現(xiàn)。
本發(fā)明還可以被嵌入在計算機程序產(chǎn)品中，其包括能夠?qū)崿F(xiàn)此處所述的方法和功能的所有特征，并且當(dāng)將其載入計算機系統(tǒng)時，其能夠執(zhí)行這些方法和功能。在這個上下文中，諸如計算機程序、軟件程序、程序、程序產(chǎn)品、軟件等之類的術(shù)語，指的是以任何語言、代碼或符號的、這樣一組指令的任何表示，所述指令意在使具有信息處理能力的系統(tǒng)直接地或者在進行如下步驟中任何一個步驟或兩個步驟之后執(zhí)行特殊的功能，所述步驟包括(a)轉(zhuǎn)換為另一種語言、代碼或符號；和/或(b)以不同材料形式再現(xiàn)。
為了舉例說明和描述的目的，已經(jīng)給出了本發(fā)明的先前描述。這并不意味著是窮舉的或者把本發(fā)明限制為所公開的具體形式，并且顯然，許多修改和變化都是可能的。意圖使對于本領(lǐng)域技術(shù)人員來說顯而易見的這種修改和變化被包括在本發(fā)明的范圍之內(nèi)，其中本發(fā)明的范圍由所附權(quán)利要求書來限定。
權(quán)利要求
1.一種具有用于允許信賴方驗證用戶的信賴方用戶驗證系統(tǒng)的公鑰(PK)框架，其中所述PK框架把用戶憑證置于所述信賴方的控制之下，并且其中所述信賴方用戶驗證系統(tǒng)包括存儲系統(tǒng)，用于在用戶憑證數(shù)據(jù)存儲庫中存儲從用戶那里接收的證書，其中所述證書是由多個不同的證書授權(quán)方發(fā)布的；管理系統(tǒng)，用于管理與用戶相關(guān)聯(lián)的用戶憑證數(shù)據(jù)存儲庫中的記錄；以及確認系統(tǒng)，用于允許信賴方從用戶憑證數(shù)據(jù)存儲庫中檢取證書以便驗證用戶。
2.如權(quán)利要求1所述的PK框架，其中存儲在所述用戶憑證數(shù)據(jù)存儲庫中的證書包括自己簽名的證書。
3.如權(quán)利要求1所述的PK框架，其中從用戶那里接收的證書是經(jīng)由安全信道接收的。
4.如權(quán)利要求1所述的PK框架，其中所述用戶預(yù)訂由信賴方提供的服務(wù)。
5.一種用于使用公鑰基礎(chǔ)設(shè)施(PKI)憑證來驗證用戶的信賴方驗證服務(wù)器，其中所述信賴方驗證服務(wù)器包括多個用于驗證用戶的信任錨，并且其中所述信任錨包括包含信任的證書授權(quán)方證書的密鑰庫；已注冊證書目錄；以及定制的萬維網(wǎng)服務(wù)用戶憑證檢驗應(yīng)用。
6.如權(quán)利要求5所述的信賴方驗證服務(wù)器，其中所述信賴方驗證服務(wù)器還包括選擇機制，用于從多個信任錨中選擇至少一個信任錨來驗證用戶。
7.如權(quán)利要求5所述的信賴方驗證服務(wù)器，其中把已注冊證書目錄與用戶憑證數(shù)據(jù)存儲庫相鏈接，其中所述用戶憑證數(shù)據(jù)存儲庫是使用從這樣的一個組中選出的訪問協(xié)議來實現(xiàn)的，其中所述組包括JDBC(Java數(shù)據(jù)庫連接性)、ODBC(開放式數(shù)據(jù)庫連接性)、SQL(結(jié)構(gòu)化查詢語言)和LDAP(輕型目錄訪問協(xié)議)目錄。
8.如權(quán)利要求5所述的信賴方驗證服務(wù)器，還包括用戶憑證數(shù)據(jù)存儲庫，用于存儲從用戶那里接收的證書，其中所述證書是由多個不同的證書授權(quán)方發(fā)布的；管理系統(tǒng)，用于管理與用戶相關(guān)聯(lián)的用戶憑證數(shù)據(jù)存儲庫中的記錄；以及確認系統(tǒng)，用于允許信賴方從用戶憑證數(shù)據(jù)存儲庫中檢取證書以便驗證用戶。
9.如權(quán)利要求5所述的信賴方驗證服務(wù)器，其中所述用戶預(yù)訂由信賴方提供的服務(wù)。
10.一種用于允許信賴方在公鑰(PK)框架內(nèi)驗證用戶的方法，其中所述用戶憑證受到信賴方的控制，所述方法包括提供受控于信賴方的用戶憑證數(shù)據(jù)存儲庫；在用戶憑證數(shù)據(jù)存儲庫中存儲從用戶那里接收的證書，其中所述證書是由多個不同的證書授權(quán)方發(fā)布的；在信賴方處接收驗證用戶的請求；并且從用戶憑證數(shù)據(jù)存儲庫中檢取證書以便驗證用戶。
11.如權(quán)利要求10所述的方法，還包括如下步驟允許信賴方管理與用戶相關(guān)聯(lián)的用戶憑證數(shù)據(jù)存儲庫中的記錄。
12.如權(quán)利要求10所述的方法，其中存儲在所述用戶憑證數(shù)據(jù)存儲庫中的證書包括自己簽名的證書。
13.如權(quán)利要求10所述的方法，其中從用戶那里接收的證書是經(jīng)由安全信道接收的。
14.如權(quán)利要求10所述的方法，其中所述用戶預(yù)訂由信賴方提供的服務(wù)。
15.一種用于使用公鑰基礎(chǔ)設(shè)施(PKI)憑證來驗證用戶的方法，包括如下步驟在信賴方驗證服務(wù)器處接收驗證用戶的請求；并且從多個信任錨中選擇至少一個信任錨來驗證所述用戶，其中用于驗證預(yù)訂者的多個信任錨包括包含信任的證書授權(quán)方證書的密鑰庫；已注冊證書目錄；以及定制的萬維網(wǎng)服務(wù)用戶憑證檢驗應(yīng)用。
16.如權(quán)利要求15所述的方法，其中已注冊證書目錄包括LDAP目錄。
17.如權(quán)利要求15所述的方法，其中已注冊證書目錄包括使用從這樣的一個組中選出的訪問協(xié)議的數(shù)據(jù)庫，其中所述組包括JDBC(Java數(shù)據(jù)庫連接性)、ODBC(開放式數(shù)據(jù)庫連接性)和SQL(結(jié)構(gòu)化查詢語言)。
18.如權(quán)利要求17所述的方法，其中所述用戶預(yù)訂由信賴方提供的服務(wù)。
19.一種用于利用信賴方用戶驗證應(yīng)用的方法，其中用戶憑證受到信賴方的控制，所述方法包括提供計算機基礎(chǔ)設(shè)施，其可操作用于在受控于信賴方的用戶憑證數(shù)據(jù)存儲庫中存儲從用戶那里接收的證書，其中所述證書是由多個不同的證書授權(quán)方發(fā)布的；管理與信賴方相關(guān)聯(lián)的用戶憑證數(shù)據(jù)存儲庫中的記錄；并且允許信賴方從所述用戶憑證數(shù)據(jù)存儲庫中檢取證書以便驗證用戶。
20.如權(quán)利要求15所述的方法，其中所述信賴方用戶驗證應(yīng)用還可操作用于接收驗證用戶的請求；并且從多個信任錨中選擇至少一個信任錨來驗證用戶，其中用于驗證用戶的多個信任錨包括包含信任的證書授權(quán)方證書的密鑰庫；已注冊證書目錄；以及定制的萬維網(wǎng)服務(wù)用戶憑證檢驗應(yīng)用。
全文摘要
一種用于允許信賴方充當(dāng)信任錨以便驗證預(yù)訂者的公鑰(PK)框架。所述框架提供了一種受控于信賴方的目錄系統(tǒng)，其中所述目錄系統(tǒng)包括用于在數(shù)據(jù)庫中存儲從預(yù)訂者那里接收的證書的存儲系統(tǒng)，其中所述證書是由多個不同的證書授權(quán)方發(fā)布的；用于管理與預(yù)訂者相關(guān)聯(lián)的數(shù)據(jù)庫中的記錄的管理系統(tǒng)；以及用于允許信賴方從數(shù)據(jù)庫中檢取證書以便驗證預(yù)訂者的確認系統(tǒng)。
文檔編號H04L29/06GK1881879SQ20061009127
公開日2006年12月20日 申請日期2006年6月8日 優(yōu)先權(quán)日2005年6月8日
發(fā)明者戴維·卡喬夫 申請人:國際商業(yè)機器公司