用于ocsp和分布式ocsp的通信有效實時憑證的制作方法

專利名稱：用于ocsp和分布式ocsp的通信有效實時憑證的制作方法
相關申請交叉索引本申請要求2004年1月9日申請的美國臨時申請60/535,666和2004年1月15日申請的美國臨時申請60/536,817的優先權，兩個申請均通過引用組合于此。
背景技術：
1.技術領域本申請涉及數字證書領域，特別是涉及驗證和確認數字證書及其它信息的領域。
2.背景技術數字簽名提供有效形式的因特網鑒別。不像傳統的密碼和PIN，數字簽名以到處可證實的方式鑒別事務。因此，否定已被數字簽署的事務是很難的，但并非不可能。數字簽名經簽署密鑰SK產生，并經相配的驗證密鑰PK進行驗證。用戶U保密其自己的SK，從而只有U可代表U簽署。幸運地，密鑰PK不會“背叛”相配的密鑰SK；即PK的知識在計算SK時并不提供任何實際的優點。因此，用戶U可使其自己的PK盡可能的公開，從而每個人均可驗證U的簽名。為此，PK被稱為公鑰。
數字證書是字母數字串，其通過保證給定密鑰PK真地是用戶U的公鑰而使能數字簽名。認證機構(CA)產生并發出證書給用戶，但通常僅在確定用戶的身份之后進行。因此，證書證明CA已驗證持有人的身份以及其它屬性。證書在指定時間后過期，在公共CA的情況下通常為一年。
大體上，數字證書C由將幾個數安全綁定在一起的CA數字簽名組成，所述幾個數為對證書唯一的序號SN、用戶的公鑰PK、用戶名U、發出日期D1、期滿日期D2、及其它數據。表示成符號
C＝SIGCA(SN，PK，U，D1，D2，...)能夠確定數字證書的狀態是有用的，包括確定特定證書是否被有效發出和/或確定在證書過期之前其是否已被廢除。有很多技術可用于確定單個數字證書的狀態。例如，美國專利5,666,416和5,717,758描述了提供單個證書狀態的技術。其它用于散布和確定證書狀態的技術也是眾所周知的，包括證書廢除列表(CRL)，其是數字簽署的廢除證書的列表，及包括在線證書狀態協議(OCSP)，其規定查詢特定證書的狀態的機制。
CRL通過使每一CA定期發出載明適當日期且數字簽署的列表(CRL)而進行工作，所述列表包含作廢證書的序號。在某些實踐中，CRL包含給定證書組的所有作廢證書。因此，數字證書可和與最近CRL比較的電子事務一起呈現。如果給定證書未過期但在已被廢除證書的列表中，則從CRL可知道證書無效且證書持有人不再有權執行由數字證書使能的事務。另一方面，如果證書沒有出現在CRL中，則證書被視為有效。或者，CRL可與每一事務的其它記錄一起存檔，以在將來能夠證明事務的有效性，或在作廢證書的情況下，證明拒絕服務是正確的。
假定作廢率為10％，則平均10個數字證書就有1個在其期滿前被廢除。根據這樣的作廢率，具有1000萬證書的系統將產生包含100萬序號的CRL，這可能使得CRL很難處理。盡管可通過最近出現的CRL分區技術減輕該問題，但將許多證書的作廢信息打包在一起的基本策略依然可能產生不方便和成本。如果序號是24位長(以處理幾百萬證書)，1000個證書的子CRL將是24000位(3000字節)長。在某些部署中，由于開銷，每一證書的CRL條目為22位長，因而1000證書的子CRL為22000位長。但在某些情形下這是不可接受的，例如，在無線事務情形下，必須傳送這么多位(保護未來的爭議及可能的合法要求)是不切實際的。
CRL逐漸變大，因為它們提供關于集中在一起的許多證書的作廢證明(因而間接地提供有效性證明)。通過比較，OCSP可提供各個證書的有效性證明。傳統的OCSP服務使用可從客戶(即依賴方)接收問題的OCSP應答器，所述問題關于給定CA發出的給定證書的有效性，響應于此，OCSP可提供數字簽署的答案，其指明證書的狀態及關于該答案的時間信息。
為能夠提供OCSP服務，傳統的OCSP應答器被提供以關于CA的所有證書的狀態的信息。由于通常CA可確定其自己的證書的狀態，如果OCSP應答器是CA自身，則OCSP應答器/CA已經具有關于證書作廢狀態的信息。另一方面，如果OCSP應答器不是CA，則OCSP應答器可被保持更新CA的證書狀態。例如，可參見美國專利5,717,758基于證據的證書廢除系統。
CA可通過發送最近的CRL而更新OCSP應答器。OCSP應答器可查閱該CRL以推斷感興趣的特定證書在當前有效還是已被廢除，從而OCSP應答器可向依賴方提供簽署的響應，其指明當前CRL的時間、下一次更新的時間及實際處理的時間。
當然，惡意/被損害的OCSP應答器可提供任意簽署的關于給定CA的證書的答案，查閱或不查閱任何CRL。因此，為使依賴方安全依賴OCSP應答器數字簽署的關于給定CA的證書的答案，OCSP包括機制CA向OCSP應答器提供應答器證書，由CA簽署的特殊數字證書，其實質上向其它方擔保CA信任該OCSP應答器以提供關于CA的證書的準確證明。應注意，為使該過程適當地工作，每一OCSP應答器(及每一CA)必須具有秘密簽署的密鑰，且該密鑰必須被保護(如通過將實現該應答器的服務器放在保險庫中進行保護)。
參考圖1，示意圖40示出了傳統OCSP環境中的信息流。示意圖40包括CA42、傳統OCSP應答器44、及依賴方46。用于CA42和OCSP應答器44的粗線表明存在必須被保護的密鑰以使系統可靠運行。CA42向OCSP應答器44提供有效性信息48(如CRL)。依賴方46向OCSP應答器44其它OCSP請求52。OCSP應答器44檢查CA42提供的有效性信息(如CRL形式)并確定所涉及證書的有效性狀態。之后，OCSP應答器44準備相應的響應，數字簽署該響應并將其作為OCSP應答器54的結果提供給依賴方46。在某些情況下，OCSP應答器44還可向依賴方46提供應答器證書56，其指明OCSP應答器44被CA42授權和委托。
但OCSP有很大的缺陷。首先，數字簽名是計算集中的運算。由傳統OCSP應答器在每一OCSP響應上建立的數字簽名在請求時產生，并可能是確認運算的最計算集中的部分。例如，產生數字簽名可增加50毫秒到1秒的事務處理時間。即使傳統的OCSP應答器在數字證書C第一次被詢問之后緩存關于C的數字簽名，并在以后詢問C時發送所緩存的簽名，由于產生初始數字簽名，對詢問C的第一用戶的回答仍然會被大大延遲。
此外，如果只有一個OCSP應答器，則所有證書有效性查詢實際上均被發送給該單一OCSP應答器，之后，其變為主要網絡瓶頸并導致相當的擁塞和延遲。如果大量的誠實用戶突然查詢該OCSP應答器，則中斷拒絕服務的情形將跟著發生。
另一方面，為防止集中實施OCSP的問題，機構可考慮跨幾個適當證明的、傳統OCSP應答器分布請求負載(關于其證書的有效性)。總地來說，跨幾個(如100個)戰略分布在全球(以避免傳輸瓶頸)的服務器分布單一服務器的負載可減輕網絡擁塞。然而，對于OCSP，負載分布可導致另外的問題，因為，為提供針對證書有效性查詢的簽署的響應，100個分布式傳統OCSP應答器中的每一個均具有其自己的秘密簽署的密鑰。因此，泄密100個服務器中的任一個均可有效地使整個幾個泄密。實際上，如果傳統OCSP應答器被泄密，則攻擊者可使用已發現的秘密簽署的密鑰不實地簽署響應，其指明(1)有效證書已被廢除，或(2)作廢證書依然有效。該后一類型的假陽性響應可允許已被解雇的雇員重新獲得進入系統的權利。
防止應答器被泄密的一種辦法是從安全的保險庫運行應答器，其具有全天候監視。不幸的是，這是成本非常高昂的選擇。真正安全的保險庫，比如滿足金融CA的所有要求的保險庫，僅建立就須100萬美元以上，且每年的運行費用也在100萬美元左右。此外，即使機構愿意支付這樣的支出，保險庫也不可能在一夜之間建成。因此，如果CA需要幾個保險庫來減輕其當前傳統OCSP應答器的負荷，在新的適當保護的OCSP應答器建好之前將有幾個月的延遲。
此外，招致幾個保險庫的花費并不能解決OCSP安全問題。這是因為，OCSP機制要求傳統OCSP應答器接收來自非置信來源(依賴方)的請求，并使用應答器的秘密簽署的密鑰服務于該請求。因此，懷惡意的依賴方(或佯裝依賴方的懷惡意的代理)更喜歡通過在基本操作系統中發現可能的弱點而曝光OCSP應答器簽署的密鑰。
而且，在服務于源自不同安全域的證書有效性請求時，有幾個困難與OCSP有關。例如，由機構A運行的傳統的OCSP應答器可容易地提供關于機構A的CA的證書狀態的響應，但由另一機構運行的OCSP應答器并沒有足夠的信息來提供關于“外來”證書的響應。
源于缺乏特定知識的該問題可能以下述兩種方式之一進行處理。第一，來自機構B的依賴方可從機構A的應答器獲得機構A的CA的證書狀態。然而，這限制了性能，因為來自機構A的OCSP應答器可能在地理上遠離機構B的依賴方，從而網絡時間可大大減慢整個確認處理。第二種方式是允許來自機構B的應答器可做出關于機構A的證書的響應，其通過使來自機構A的CA將機構A的CRL轉發給外來應答器而實現。實際上，CRL被數字簽署因而不必保密，且機構A的CA按理應希望將機構A的證書的有效性狀態通知給盡可能多的受眾。該第二方式向機構B的OCSP應答器提供足夠的信息以回答來自依賴方的、關于機構A的證書的請求。要不是依賴方重視機構B的OCSP應答器的數字簽署的答案，機構A的CA還應證明外來應答器在回答關于機構A的證書的有效性查詢方面是可信賴的。
參考圖2，示意圖60示出了圖1的示意圖40中所示的CA42、傳統OCSP應答器44、及依賴方46。然而，在示意圖60所示的情形下，依賴方46提供關于證書的OCSP請求62，其不由CA42管理，而是由不同的CA64發出和管理。在這種情況下，OCSP應答器44不可單獨基于CA42提供的CRL48內的信息向OCSP應答器44提供OCSP響應。而是，CA64提供不同的CRL66和不同的應答器證書給OCSP應答器44。之后，OCSP應答器44使用不同的CRL66制訂關于外來證書的OCSP響應72。在某些情況下，OCSP應答器44還可向依賴方46提供應答器證書68。
該第二種方式可提供更好的可擴縮性和性能，但其使兩個機構之間的安全和信任流混亂。在示意圖60中，OCSP應答器44正給予依賴方權威響應，即CA64的證書依然有效。如果OCSP應答器44因為任何原因(誤配置、敵對攻擊、或直接不誠實)而給出不正確的響應，則OCSP應答器44可消極影響CA64的機構。通過允許OCSP應答器44做出關于CA64的機構的證書的權威聲明，CA64的機構放棄其先前擁有的某些信任。
作為例子，假設機構為信用卡發行人。來自機構A的銀行廢除用戶的證書，且銀行確保機構A的傳統OCSP應答器是安全且可靠的。假定機構B的OCSP應答器被誤配置，當機構B的商戶依賴方詢問用戶的有效性時，機構B的應答器不正確地回答用戶有效。商戶接受該回答并允許進行作廢用戶的交易。機構之間的這種類型的信任授權在某些情況下是可接受的，但對于任何大規模的傳統OCSP的不同種類部署，其幾乎沒有用。
因此希望提供可解決上述困難的系統。

發明內容
根據本發明，提供關于數字證書有效性的信息包括為一組數字證書中的多個數字證書的每一個確定數字證書有效性狀態，產生關于多個數字證書的數字證書集的至少一子集的有效性狀態的多個人工預計算的消息，其中至少一消息指明一個以上數字證書的有效性狀態，及數字簽署人工預計算的消息以提供OCSP格式響應，其響應于關于數字證書集中的特定數字證書的OCSP查詢，其中至少一數字簽名連同OCSP格式響應用于一個以上數字證書。產生并數字簽署可在任何OCSP查詢被任一OCSP格式響應回答之前進行。確定數字證書有效性狀態包括獲得關于數字證書的經鑒定的信息。關于數字證書的經鑒定的信息可由廢除證書的實體產生。關于數字證書的經鑒定的信息可以是CRL。產生多個人工預計算的響應可包括為數字證書集中至少所有未作廢的數字證書產生響應。提供關于數字證書有效性的信息還可包括，在數字簽署人工預計算的消息之后，將其結果轉發給服務于依賴方的請求的多個應答器，所述依賴方詢問數字證書集中的數字證書的有效性狀態。提供關于數字證書有效性的信息還可包括，使包含公開驗證密鑰的特殊數字證書可為應答器所用，所述密鑰用于驗證在數字簽署人工預計算的響應時提供的數字簽名。發出特殊數字證書的實體還可發出數字證書集的證書。產生多個人工預計算的響應及數字簽署人工預計算的響應可周期性地執行。人工預計算的響應可包括對應于人工預計算的響應在何時產生的時間信息。
根據本發明，保存在計算機可讀介質上的、提供關于數字證書有效性信息的計算機軟件包括為一組數字證書中的多個數字證書的每一個確定數字證書有效性狀態的可執行代碼，產生關于多個數字證書的數字證書集的至少一子集的有效性狀態的多個人工預計算的消息的可執行代碼，其中至少一消息指明一個以上數字證書的有效性狀態，及數字簽署人工預計算的消息以提供OCSP格式響應的可執行代碼，其響應于關于數字證書集中的特定數字證書的OCSP查詢，其中至少一數字簽名連同OCSP格式響應用于一個以上數字證書。確定數字證書有效性狀態的可執行代碼包括獲得關于數字證書的經鑒定的信息。關于數字證書的經鑒定的信息可由廢除證書的實體產生。關于數字證書的經鑒定的信息可以是CRL。產生多個人工預計算的響應的可執行代碼可包括為數字證書集中至少所有未作廢的數字證書產生響應。計算機軟件還可包括將數字簽署的人工預計算消息轉發給服務于依賴方的請求的多個應答器的可執行代碼，所述依賴方詢問數字證書集中的數字證書的有效性狀態。計算機軟件還可包括使包含公開驗證密鑰的特殊數字證書可為應答器所用的可執行代碼，所述密鑰用于驗證在數字簽署人工預計算的響應時提供的數字簽名。發出特殊數字證書的實體還可發出數字證書集的證書。產生多個人工預計算的響應及數字簽署人工預計算的響應的可執行代碼可周期性地產生和簽署響應。
根據本發明，提供關于數字證書有效性的信息包括獲得多個簽署密鑰/驗證密鑰對，其中每一簽署密鑰提供數字簽名及相應的驗證密鑰驗證該數字簽名，其中使用簽署密鑰一起數字簽署多個數據元相較個別地數字簽署每一數據元在計算上效率更高，為一組數字證書中的每一證書確定數字證書有效性狀態，產生關于數字證書集的至少一子集的有效性狀態的多個人工預計算的消息，并使用來自密鑰對的簽署密鑰一起數字簽署人工預計算的消息。確定數字證書有效性狀態可包括獲得關于數字證書的經鑒定的信息。關于數字證書的經鑒定的信息可由廢除證書的實體產生。關于數字證書的經鑒定的信息可以是CRL。人工預計算的響應可以是OCSP格式響應。產生多個人工預計算的響應包括為數字證書集中至少所有未作廢的數字證書產生響應。提供關于數字證書有效性的信息還可包括，在數字簽署人工預計算的消息之后，將其結果轉發給服務于依賴方的請求的多個應答器，所述依賴方詢問數字證書集中的數字證書的有效性狀態。產生多個人工預計算的響應及數字簽署人工預計算的響應可周期性地執行。人工預計算的響應可包括對應于人工預計算的響應在何時產生的時間信息。提供關于數字證書有效性的信息可包括鑒定驗證密鑰。鑒定驗證密鑰包括在單一數字證書中提供驗證密鑰。鑒定驗證密鑰可包括在分開數字證書中提供每一驗證密鑰。
根據本發明，保存在計算機可讀介質上的、提供關于數字證書有效性信息的計算機軟件包括獲得多個簽署密鑰/驗證密鑰對的可執行代碼，其中每一簽署密鑰提供數字簽名及相應的驗證密鑰驗證該數字簽名，其中使用簽署密鑰一起數字簽署多個數據元相較個別地數字簽署每一數據元在計算上效率更高，為一組數字證書中的每一證書確定數字證書有效性狀態的可執行代碼，產生關于數字證書集的至少一子集的有效性狀態的多個人工預計算的消息的可執行代碼，及使用來自密鑰對的簽署密鑰一起數字簽署人工預計算的消息的可執行代碼。確定數字證書有效性狀態的可執行代碼可包括獲得關于數字證書的經鑒定的信息的可執行代碼。關于數字證書的經鑒定的信息可由廢除證書的實體產生。關于數字證書的經鑒定的信息可以是CRL。人工預計算的響應可以是OCSP格式響應。產生多個人工預計算的響應的可執行代碼包括為數字證書集中至少所有未作廢的數字證書產生響應的可執行代碼。計算機可包括鑒定驗證密鑰的可執行代碼。鑒定驗證密鑰的可執行代碼可在單一數字證書中提供驗證密鑰或在分開數字證書中提供每一驗證密鑰。
根據本發明，幫助第一方和第二方之間的交易包括，在開始交易之前，交易方之一獲得關于特定數字證書的人工預計算的OCSP響應，其中人工預計算的OCSP響應由不同于第一方和第二方的實體產生，交易方之一開始交易，在交易時，第一方提供特定數字證書給第二方，第二方使用人工預計算的OCSP響應驗證該特定數字證書。第二方可在交易開始之前獲得人工預計算的OCSP響應。第二方可緩存人工預計算的OCSP響應以用于將來交易。第一方可在交易開始之前獲得人工預計算的OCSP響應。第一方可緩存人工預計算的OCSP響應以用于將來交易。幫助第一方和第二方之間的交易還可包括在交易開始之后第一方提供人工預計算的OCSP響應給第二方。
根據本發明，確定數字證書的有效性包括檢查數字簽署的關于數字證書有效性的消息，其中消息由不同于發出數字證書的實體的特殊實體數字簽署，且還包括使用來自至少下述之一的信息驗證數字簽署的消息數字證書和鑒定發出數字證書的實體的證書。信息可以是對應于用于數字簽署消息的秘密密鑰的公鑰。信息可對應于鑒定數字簽署消息的特定實體的特定數字證書。
根據本發明，為數字證書集中的每一證書確定數字證書有效性狀態包括定期產生多個數字簽署的關于數字證書集的至少一子集的有效性狀態的人工預計算消息，并定期將數字簽署的人工預計算消息轉發給多個服務于依賴方的請求的應答器，所述依賴方詢問數字證書集中的數字證書的有效性狀態，其中關于一些證書的消息以不同于關于其它證書的消息的頻率進行轉發。相較關于有效證書的消息，關于作廢證書的消息可相對不頻繁地進行轉發。
根據本發明，保存在計算機可讀介質中的、確定數字證書有效性的計算機軟件包括檢查數字簽署的關于數字證書有效性的消息的可執行代碼，其中消息由不同于發出數字證書的實體的特殊實體數字簽署，且還包括使用來自至少下述之一的信息驗證數字簽署的消息的可執行代碼數字證書和鑒定發出數字證書的實體的證書。信息可以是對應于用于數字簽署消息的秘密密鑰的公鑰。信息可對應于鑒定數字簽署消息的特殊實體的特殊數字證書。
根據本發明，保存在計算機可讀介質中的、提供關于數字證書有效性的信息的計算機軟件包括為數字證書集的每一證書確定數字證書有效性狀態的可執行代碼，定期產生多個數字簽署的關于數字證書集的至少一子集的有效性狀態的人工預計算消息的可執行代碼，及定期將數字簽署的人工預計算消息轉發給多個服務于依賴方的請求的應答器的可執行代碼，所述依賴方詢問數字證書集中的數字證書的有效性狀態，其中關于一些證書的消息以不同于關于其它證書的消息的頻率進行轉發。相較關于有效證書的消息，關于作廢證書的消息可相對不頻繁地進行轉發。
在此描述的系統是節省成本的、安全的、可升級的、且整體有效的確認系統，其大大提高了傳統的方法。在此描述的系統，即使在保持與OCSP標準的兼容性時，仍較傳統OCSP有很明顯的優點，從而在質量上提供超級安全性和可擴縮性。
在此描述的系統是獨立于傳統OCSP工作的一般、獨立系統。然而，在一些實施例中，該系統可以是OCSP兼容的，其中根據在此描述的系統的有效性的每一證明均被構造成句法正確的數字簽署的OCSP響應，使得依賴方請求并繼而根據OCSP格式驗證證書有效性信息等。數字簽名是計算集中的運算，但在此描述的系統將該困難集中在單一專用服務器上，或者，在其它實施例中，集中在少量的專用服務器上。因此，裝備單一專用服務器(或少量服務器)非常容易且相對便宜，其具有足夠計算能力以在每一更新時處理所有必需的數字簽名。在于此描述的系統中使用的應答器僅需執行普通的讀取-轉發操作，因而可較傳統OCSP應答器更快地服務于輸入的依賴方查詢，因為傳統OCSP應答器必需執行復雜的數字簽名。
由于用于在此描述的系統的應答器可采用普通硬件且不需保護，因而可相對便宜地購買和運行應答器。因此，相對大量的應答器可以相對低的開銷進行部署。因此，即使在短時間內產生了大量的證書有效性狀態請求，該負荷可被分散到許多應答器，從而在不產生太多花費的情況下消除擁塞及良性拒絕服務的風險。應注意，用于在此描述的系統的數字簽名的數量取決于證書的數量并相對獨立于有效性狀態請求的數量。因此，即使預計有相當大量的有效性請求，也可使用單一服務器提供數字簽署的響應。
在于此描述的系統中，只有一個專用服務器(或少量專用服務器)及CA(如果不同于單一專用服務器)需要被保護/放入保險庫。實際上，在此描述的系統的應答器不保存任何秘密密鑰它們僅保存提供給應答器的預計算響應的數字簽名，其一旦被計算，則不可能被惡意修改，因而不需要保密。作為對比，所有傳統OCSP應答器均需要保護，因為傳統OCSP應答器中的每一個均具有秘密簽署的密鑰，其中之一泄密將使整個系統泄密。因此，在此描述的系統比OCSP更安全，因為保護一個站點(或少量站點)比保護許多且同等重要的站點更可取且更容易。
此外，與OCSP情形不同，依賴方不能容易地在于此描述的系統上安裝軟件攻擊程序。即使依賴方成功地在其查詢中嵌入某種類型的特洛伊木馬，其也不能使任何秘密公開，因為在此描述的系統的應答器不擁有任何秘密應答器僅保存和返回提供給應答器的預計算的數字簽名。因此，所有懷惡意的依賴方希望公開是全部的、準確的、及數字簽署的賬戶，包括在給定時間間隔內哪些證書有效和哪些已作廢。然而，這不僅不是秘密信息，且實際上，其是CA希望廣為人知的信息，以防止依賴方不正確地依賴于CA發出的已作廢的證書。
此外，應注意，軟件攻擊程序不能容易地針對數字簽署預計算響應的單一專用服務器(或少量專用服務器)進行安裝。在一些實施例中，單一專用服務器(或少量專用服務器)不處理非置信來源的請求，而是僅接收來自CA的信息并提供數字簽署的信息給應答器。因此，不可能在于此描述的系統中插進特洛伊木馬。
除了這些優點外，在此描述的系統還使在包括多個機構的異機種部署內能具有很大的靈活性。來自一機構的應答器可將人工預計算的響應轉發給另一機構，而無須向另一機構分布任何信任。第一機構可使另一機構的應答器為第一機構提供可相信的有效性證明，而不用放棄對第一機構的證書的有效性狀態的任何數量的控制。即，在于此描述的系統中，信任可從一機構流到另一機構，而不會損失任何安全性或控制。在一些實施例中，應答器可被處理為透明的網絡基礎設施，而不是硬化的信任點。這類似于因特網的DNS基礎設施提供的服務云，因為其允許名稱服務器的異類集合，這些名稱服務器相互透明地合作運行以發現和緩存對查詢的有效響應。
安全的異機種性是在此描述的系統相對于傳統OCSP的主要優點。安全的異機種性允許多種機構合作運行，從而來自不同機構的依賴方可以安全、可靠、有效的方式交叉確認來自其它機構的證書。
在此描述的系統將所有確認信任提供在單一權力機構(或少量權力機構)中，同時跨任意數量的無保護的應答器分布查詢負荷。在此描述的系統不會降低安全性，即使所分布的實施依賴于相當大量的即使未受保護的應答器也是如此。在此描述的系統改善了對查詢的響應時間。在此描述的系統不會授權信任給異機種環境中的外來應答器。


圖1所示為提供OCSP響應給依賴方的現有技術系統。
圖2所示為在異機種環境中提供OCSP響應的現有技術系統。
圖3所示為根據在此描述的系統的實施例的RTC系統。
圖4為根據在此描述的系統的實施例初始化RTCA的流程圖。
圖5為根據在此描述的系統的實施例在CA和RTCA之間進行通信的流程圖。
圖6為根據在此描述的系統的實施例將數據從RTCA進棧到RTC應答器的流程圖。
圖7為根據在此描述的系統的實施例RTC應答器從RTCA獲取數據的流程圖。
圖8為根據在此描述的系統的實施例RTC應答器提供信息給依賴方的流程圖。
圖9為根據在此描述的系統的實施例RTC應答器獲取有效性信息的流程圖。
圖10為根據在此描述的系統的另一實施例RTC應答器獲取有效性信息的流程圖。
圖11為根據在此描述的系統的實施例幫助雙方交易時所執行步驟的流程圖。
圖12為根據在此描述的系統的實施例數字證書的示意圖。
圖13為根據在此描述的系統的實施例CA、RTCA、RTC應答器和依賴方之間的數據流的示意圖。
圖14為根據在此描述的系統的實施例，第一系統的CA、RTCA、RTC應答器及依賴方和第二系統的CA、RTCA、RTC應答器及依賴方之間的數據流的示意圖。
圖15為根據在此描述的系統的實施例RTC應答器的異類云的示意圖。
圖16為根據在此描述的系統的實施例進行優化的流程圖。
圖17為根據在此描述的系統的實施例的特許機構的示意圖。
圖18為根據在此描述的系統的實施例在CA、SERTCA、RTC應答器和依賴方之間的數據流的示意圖。
圖19為根據在此描述的系統的實施例，為成批OCSP處理提供信息給RTCA/SERTCA/OCSP應答器的流程圖。
圖20為根據在此描述的系統的實施例，為成批OCSP處理提供信息給RTC應答器的流程圖。
具體實施例方式
在此描述的系統使用實時憑證(RTC)，也被稱為分布式OCSP(DOCSP)，并使用稱為RTC權力機構(RTCA)的實體。RTCA可以也可不與給定企業的CA相一致。在一些實施例中，每一CA向其自己的RTCA提供以特殊證書，RTCA證書。CA可數字簽署RTCA證書，以表明CA信任并授權RTCA提供關于CA發出的證書的有效性信息。RTCA證書可將RTCA狀態傳給給定實體(如由給定標識符、OID號等確定的實體)并可將特定驗證密鑰PK(特定實體擁有相應的秘密簽署的密鑰)賦值給特定實體。
在CA和RTCA一致的情況下，RTCA具有不同于CA的簽署密鑰是有利的。因此，如果CA和RTCA為同一實體，實體的CA部分實際上僅發出證書而實體的RTCA部分僅通過證明特定證書是有效還是已作廢而管理證書。因此，即使CA和RTCA重合，依然可使用RTCA證書。
在一些實施例中，每一CA與唯一一個RTCA相關聯。在其它實施例中，也可能每一CA與一個以上RTCA相關聯，其中每一RTCA具有不同的簽署密鑰，或者，部分或所有RTCA共享簽署密鑰。使多個RTCA與CA相關聯對冗余目的而言是有利的。在其它實施例中，也可能使一個或多個RTCA與多個CA相關聯。
正象CA保護其簽署密鑰那樣，RTCA保護其簽署密鑰，例如借助于保險庫、安全設施或安全的硬件。在一些實施例中，RTCA可被放入受保護的設施中，其包括一個以上具有秘密簽署密鑰的服務器。設施可安全地保存秘密簽署密鑰的拷貝。RTCA可包括一個以上服務器，每一服務器均具有由CA適當證明的秘密簽署密鑰。
CA可保持RTCA知道CA的證書的有效性狀態，例如通過使用CRL或使用任何其它機制。CA可(1)只要發生變化，即以在線方式將證書有效性的任何變化通知給RTCA；和/或(2)以固定時間間隔和/或在CA產生新CRL時將CRL發送給RTCA。CA可使用大量技術中的任一或多個(單獨或組合)來提供各個證書狀態信息。例如，參見美國專利5,420,927、5,604,804、5,610,982、6,097,811、6,301,659、5,793,868、5,717,758、5,717,757、6,487,658及5,717,759中提供的內容，所有這些專利均通過引用組合于此。在此描述的系統可使用這些專利中的一個或多個公開的技術，也可與一個或多個其它適當的技術相結合。可被單獨或結合使用的技術包括全部CRL、分割的CRL、CRL增量、OCSP響應(單獨或成組)、迷你CRL(逐位壓縮的CRL)、VTokens(單向散列鏈)、及各種Merkle樹或其它樹形。
在一連串日期D1、D2、…的任一日期Di，RTCA，基于其當前的有效性狀態的知識(如基于CA的最新CRL)并獨立于任何依賴方請求，可通過處理CA的每一未完成的證書并數字簽署說明每一證書的狀態的聲明而執行更新。例如，每一證書的狀態可被視為有效、已作廢、或延緩決定(及可能“不知道”)。簽署的聲明可指定時間間隔T。在一些實施例中，在每一更新時，每一簽署的聲明均指定相同的時間間隔T，而在一些實施例中，全體時間間隔是連續的。例如，在每一更新日期Di，時間間隔可以是T＝Di+1-Di，其中可能Di和Di+1中只有一個是T的一部分，而其它日期是相鄰時間間隔的一部分。在一些實施例中，如果RTCA當前關于證書狀態的知識是基于CRL，則每一Di可與一CRL的日期一致，且Di+1與下一CRL的日期一致，依此類推。應意識到的是，這樣嚴格的時間依存并不是必需的。例如，RTCA處理或開始處理其聲明的日期可以是D1、D2等，而在聲明內指定的時間間隔可以是D1’、D2’等，其中Di和Di’可以不同和/或相互獨立。例如，Di可早于Di’，在這種情況下，RTCA可在聲明的時間間隔開始之前開始處理聲明一例如，因為RTCA希望在間隔T開始之前完成其處理。
在一些實施例中，如果CRL被用于來自CA的RTCA更新，聲明時間和CRL時間也可不同。在處理時間、CRL時間和聲明時間之間可能缺乏同步對在此描述的相同并不至關重要。在實踐中，“實時”是抽象，因為需要一些額外的時間來通知并對事件做出適當地反應。首先，應注意，雖然推進RTCA進程，但CRL可能不被實時產生。此外，廢除證書的過程也可能不是實時的。例如，用戶可能已認識到其秘密密鑰已被泄密一因而請求廢除其自己的證書一僅在泄密實際發生后一天內。因此，用戶證書的廢除有1天的延遲，相比較而言，由于RTCA計算引起的與實時的偏差可以忽略不計。
RTCA預計算數字簽名，其指明每一證書在特定時間間隔T期間的狀態。這樣的預計算可獨立于任何一方關于證書有效性的請求進行。在一些實施例中，在做出關于C的任何狀態查詢之前，甚至可能在時間間隔開始之前，RTCA預計算在特定時間間隔中證書C的狀態的簽署的聲明。
在一些實施例中，RTCA簽署的證書狀態聲明可以是標準OCSP格式。這在OCSP軟件已經到位的情況下是有用的，從而可方便地利用RTC系統，而不需修改任何現有的依賴方OCSP軟件。在一些實施例中，OCSP一致可通過特別選擇有關的數量、數字簽名算法、OID等而實現。
在許多情況下，RTCA需要為每一發出的證書產生響應，而不是僅對作廢證書產生響應。為確定每一發出的證書序號的存在，RTCA可由CA或另一實體給予每一證書的拷貝以用于內部跟蹤，或者RTCA可通過另一機制給予發出的序號，所述機制不包括傳送各個證書。在一些實施例中，在證書序號是按連續順序發出的特殊情況下，發出的證書信息可不必明確地提供給RTCA。當使用連續序號時，RTCA可選擇僅使用當前CRL推斷每一證書序號的存在。這可通過確定CRL中的最低和最高序號完成。在高和低序號之間的范圍中的任何中間號均由CA發出。如果范圍中的號出現在CRL中，則可知道其狀態為已作廢。如果范圍中的中間號沒有出現，則可確定相應的證書尚未被廢除，在OCSP標準中其被定義為“有效”。
上述技術可處理所發出證書的大部分，盡管仍然有少量被發出的證書具有或低于最低CRL條目或高于最高CRL條目的序號。RTCA可通過可配置參數包括這些另外的序號，所述參數假定在CRL中第一條目之前和最后條目之后有固定數量的有效序號。例如，RTCA可指定在最低CRL條目之前有100個序號及在最高CRL條目之后有500個序號代表有效證書。這種優化允許RTCA取回一個數據元(CRL)而不是大量數據元(各個證書)。在證書是按從低到高的連續序號發出的情況下，在高端使用的較高號碼可用于容納新發出的證書。在其它實施例中，所發出證書的最低和最高序號可被明確地提供給RTCA，且在一些實施例中，該信息可被數字簽署。
應注意，預計算的句法正確的OCSP響應在技術上可被視為不是OCSP響應，因為這些響應并不是響應于任何原始/初始請求而進行計算的。實際上，RTCA對尚未產生且可能永遠也不會產生的OCSP請求預計算依從OCSP的響應。因此，RTCA響應可被視為人工預計算的響應。還可能使用術語人工預計算的響應表示任何數字簽署的RTCA聲明，即使在不依從OCSP的情形也可能使用。
在產生人工預計算的響應之后，RTCA可給出可用于其它方的響應。具體地，RTCA可響應于有效性狀態查詢返回響應給依賴方。然而，在其它實施例中，RTCA可給出可用于RTC應答器的人工預計算響應。RTC應答器不必保護，因為在實踐中RTCA簽署的消息(人工預計算響應)不可能以不可檢測的方式進行欺騙性地修改或纂改。因此，RTCA可發送人工預計算響應給外來應答器(屬于其它機構的應答器)，而不會危害安全性。
在一些實施例中，RTCA可通過以適當組織的方式將人工預計算響應呈現給RTC應答器而幫助RTC應答器進行的處理。例如，RTCA可呈現根據證書序號或根據長度等排序的人工預計算響應。為確保所有有關的人工預計算響應均已被接收，在每一次更新時，RTCA可通過簽署全體人工預計算響應并注明日期而向RTC應答器提供另外的簽名。在一些實施例中，可使用人工預計算響應的數量的計數或類似機制，具有也可沒有數字簽名。
此外，RTCA可將CA產生的RTCA證書發送給RTC應答器以證明CA信任和授權RTCA提供關于CA發出的證書的有效性信息。在一些實施例中，不必在每次更新時均進行該發送。在一些情況下，RTCA僅在開始或以某一固定周期或基于請求發送RTCA證書給RTC應答器。
RTC應答器可將所接收的RTCA的人工預計算響應保存足夠長的時間。在一些實施例中，如果RTCA的簽名涉及特定時間間隔T，RTC應答器可將人工預計算響應至少保存到T結束為止。在一些實施例中，至少部分RTC應答器，如那些與RTCA屬于同一機構的應答器，可定期采取措施以確保信息是正確且最新的。例如，RTC應答器可驗證關于時間間隔T的人工預計算響應是在T或其它與T有關的適當時間開始之前接收的，驗證所有接收的RTCA簽名(還可能驗證適當的RTCA證書)，驗證RTC應答器是否已接收所有簽名(如不少于預期數量的簽名，不少于已經發出的證書的最后傳輸的簽名)，驗證RTC應答器是否已接收指示先前已被聲明作廢的證書的有效性的信息，驗證RTCA證書本身是否已被廢除(如因為安全泄密)等。如果檢測到任何問題，則RTC應答器可通知RTCA或其它適當實體。
依賴方可向RTC應答器詢問證書的有效性狀態。在一些實施例中，請求是OCSP格式。當詢問特定證書的有效性時，RTC應答器可從存儲器取回RTCA產生的特定證書的人工預計算響應并將其返回給依賴方。在一些實施例中，RTC應答器還可轉發簽署人工預計算響應的RTCA證書。在一些實施例中，依賴方可發出信號表明其對接收RTCA證書不感興趣(例如因為依賴方已經有拷貝)，或RTC應答器可知道或假定依賴方已經有證書的拷貝。依賴方可處理所接收的響應以確定感興趣的證書的有效性狀態。在一些實施例中，如果人工預計算的響應是OCSP格式，則依賴方可使用OCSP軟件用于這樣的處理。在一些實施例中，依賴方可驗證適當的RTCA證書。在依從OCSP的情形下，依賴方可將RTCA證書作為OCSP應答器證書進行驗證。在一些實施例中，RTCA證書可在句法上構造成OCSP應答器證書。
有各種可被執行的優化。例如，假設U是具有證書Cu的一方。作為與V方交易的一部分，U可發送Cu給V(除非V已有Cu)，并可能執行另外的任務(如展示與在Cu中證明屬于U的公開驗證密鑰有關的數字簽名，或通過解密由V使用在Cu中證明屬于U的公開加密密鑰加密的隨機難題而被識別)。為使交易安全，V可確定Cu的當前有效性并向RTC應答器進行有效性查詢。應答器可通過取回并返回關于Cu的最新RTCA簽署的聲明(人工預計算響應)而回答所述查詢。然而，查詢RTC應答器將第三方加入本來是兩方的交易中，這增加了交易的時間和復雜性。
一種解決辦法是使U方在每一時間間隔T開始時或至少在每一時間間隔T期間接收RTCA簽署的聲明Du(人工預計算的響應)，其表明Cu在整個T期間均是有效的。U可響應于對RTC應答器的請求接收Du(例如通過進行一般的依賴方請求)。或者，Du可被進棧給U及可能其它方，例如通過RTC應答器或RTCA在每次更新時和/或在自動基礎上進行。在任何情況下，在間隔T期間與V交易時，除了交易必需的所有其它步驟或任務以外，U可轉發Du給V。因此，U-V之間的交易可得以很大程度地加快，因為V不需要訪問任何第三方(如RTC應答器)來確定U的證書的當前有效性。
應注意，即使包括U獲取Du的總體時間不被加快，U-V之間的交易也被加快。然而，還應注意，僅加快U-V之間的交易而沒有節約總體時間依然是有用且有效率的。例如，如果假定RTCA聲明(人工預計算的響應)在午夜進行計算并指定一整天為時間間隔，則U可在大清早(此時交易相當少)獲得Du并繼而在時間敏感的U-V交易執行期間將Du轉發給V，而此時交易相當多，因而節約時間是有用的。還應注意，在獲得并緩存Du之后，通過使U在全天與其它方交易時轉發Du也可獲得另外的效率。這樣，例如，單一依賴方查詢(U自身的查詢，可能在相對不忙的時間做出)可成功地代替大量依賴方請求(可能在更忙的時間)。
上述優化還可由V方完成。在從RTC應答器獲得針對關于U方的證書Cu的有效性查詢返回的Du之后，V方可將Du給予U，或使Du可為其它方使用。
應注意，在此討論的優化應用于在此描述的系統的依從OCSP的實施例。應注意，還可能將類似的優化應用于傳統的OCSP實施。對于這樣的實施，用戶請求并獲得關于其自己的證書的OCSP響應，之后，將該OCSP響應作為其交易的一部分以適當時間間隔轉發給交易的其它方。或者，當依賴方第一次詢問U方的證書Cu的有效性時，OCSP應答器可計算響應Ru，將Ru返回給發出查詢的依賴方，且還將Ru轉發給U，使得U可緩存Ru，至少暫時緩存(直到下一次更新為止)，并可將Ru作為基于Cu的交易的一部分進行轉發。
在一些實施例中，在此描述的系統可使用在各個證書中發現的數據進行實施，從而節約另外的證書和/或響應長度。如上所述，CA可發出RTCA證書，其授權特定RTCA提供關于CA發出的證書有效性的權威答案。這樣的RTCA證書可指定公鑰用于驗證RTCA簽署的響應(人工預計算的響應)。然而，在一些實施例中，CA可將RTCA公鑰嵌入在CA發出的證書內或該信息可被嵌入在CA證書自身內。即，CA(具有適當的格式，OID等)可在證書Cu中包括公鑰PK，其可用于驗證數字簽署的關于Cu的有效性的響應。對于這些實施例，依賴方不必接收單獨的RTCA證書。當向RTC應答器詢問Cu的有效性的最新證明時，依賴方僅可獲得(如因為其那樣詢問)RTCA簽署的響應(人工預計算的響應)。實際上，Cu可指定依賴方可用以驗證Cu的有效性證明的公開驗證密鑰。在其它實施例中，整個RTCA證書(或指向其的指針)可被嵌入在用戶證書和/或CA證書中。這些實施例可產生相當的傳輸節約(因為RTC應答器不必發送單獨的RTCA證書，其可能比RTCA響應長很多)及存儲器節約(因為依賴方不必將RTCA證書與RTCA響應保存在一起)。
類似地，證書Cu可指定時間間隔。對于這些實施例，RTCA響應不必指定時間間隔T的開始和結束。在一些實施例中，單獨T的開始(或其它更簡單的規約)可適當地指定T。例如，如果Cu指定每日更新，則特定天內的任何時間均足以指定響應所涉及的全天。或者，如果已了解(如從CA的總體政策)證書具有由全天組成的有效性間隔，則沒必要將這樣的信息在證書內指出，因而節約了RTCA響應。
應注意，在特定證書C的有效性或延緩決定的RTCA證明可指定證明涉及的時間間隔的同時，作廢證明不必指定任何時間間隔。而是，對于這樣的證明，指定單一時間點(如廢除時間)通常就足夠了，因為不像有效性和延緩決定，廢除通常是不可撤回的過程。因此，僅廢除時間rt即可足以證明證書已作廢。應注意，rt不必須是任何時間間隔T的開始，而是可指任何時間。因此，在證書C永久作廢的情況下，RTCA不必在所有更新日期(如D1、D2等)發送C的作廢證明。而是，作廢證明可被僅發送一次(或為了冗余發送幾次)并由RTC應答器緩存以在依賴方進行關于C的查詢時返回給依賴方。
還應注意，RTCA可被立即通知證書C已被廢除。例如，C已被廢除的信息可在時間間隔T的中間轉發，其時RTCA已經產生并轉發C的有效性證明給RTC應答器。在這種情況下，到下一更新之前，將不為C計算有效性證明。然而，到那時(即直到T結束)，不正確的、但表面上有效的、C的有效性證明由RTC應答器保存。可能的對策包括使作廢證明優先于有效性證明。在這種情況下，既看見C在某一時間間隔T的有效性證明又看見C的作廢證明(在任何時間t)的誠實依賴方應將C視作已廢除(在時間t之后)。
在某些情形下，某些依賴方永遠不會看見作廢證明，因而即使C已被廢除，C可被這些依賴方視為仍然有效，直到T結束為止。只要RTCA獲知C已被廢除(如直接從CA那知道，不用等待下一次CRL更新)，這樣的問題可通過使RTCA計算C的廢除證明并發送給所有RTC應答器而得以減輕(獨立于預定的日期D1、D2等或D1’、D2’等)。之后，所有適當運行的RTC應答器可從存儲器刪除C的任何有效性證明并用新接收的廢除證明替代。在這種情況下，RTC應答器更可能向依賴方提供關于C的有效性的準確證明。
參考圖3，示意圖80示出了實施在此描述的系統的體系結構。CA82連到RTCA84并向其提供確認信息(如CRL)。RTCA84連到多個RTC應答器86-88，RTC應答器從RTCA接收人工預計算的響應。如本說明書別處所述，CA82和RTCA84中的每一個均使用秘密簽署的密鑰。在一些實施例中，CA82和RTCA84可以是同一實體，如框85所示。
RTCA84提供人工預計算的響應給RTC應答器86-88。如本說明書別處所述，RTC應答器不需要它們自己的秘密簽署的密鑰且不需要被保護，因為由RTC應答器86-88之一提供給依賴方的任何信息均已由RTCA84數字簽署并是公開信息。
在其它實施例中，可使用一個以上RTCA，其由RTCA92和RTCA94示出，它們代表多個另外的RTCA。每一另外的RTCA92、94可連到由RTCA84服務的應答器86-88。或者，另外的RTCA92、94中的一個或多個可連到另外的、不同的多個應答器96-98。
參考圖4，流程圖100示出了在初始化RTCA時CA所執行的步驟。流程圖100的步驟可在新的RTCA被添加到系統時或在先前的RTCA被發給新證書時執行，或因為舊RTCA證書已期滿或因為RTCA的密鑰已被泄密。
處理開始于第一步驟102，CA驗證RTCA。在步驟102驗證RTCA取決于系統的拓撲學和安全性要求，并可能要求管理員在物理上檢查RTCA并驗證RTCA在適當的位置且是安全的。當然，在步驟102也可執行其它適當的處理以驗證RTCA是安全的。在步驟102之后是步驟104，CA為RTCA產生密鑰。在步驟104，CA既為RTCA產生秘密密鑰，也為RTCA產生公鑰。
在步驟104之后是步驟106，CA基于在步驟104產生的密鑰為RTCA產生證書。在步驟106產生的證書是RTCA證書。在步驟106之后是步驟108，秘密密鑰被提供給RTCA。在一些實施例中，為安全目的，使秘密密鑰以離線方式(如用戶將秘密密鑰寫在一張紙上，之后在RTCA處輸入該秘密密鑰)提供給RTCA是有用的。
在步驟108之后是步驟112，在步驟106產生的證書被提供給RTCA。在步驟112，可能以在線(甚至不安全的)方式將證書提供給RTCA，因為RTCA證書將被公開，實際上，沒有CA的秘密密鑰(通常不同于在步驟104產生的秘密密鑰)的知識，其將不能被纂改。在步驟112之后是步驟114，關于由CA管理的證書的初始證書數據從CA提供給RTCA。在步驟114提供的初始數據可包括初始CRL。此外，如本說明書別處所述，在步驟114提供的初始數據還可包括關于有效、未過期證書的信息，從而RTCA可為有效未過期的證書提供適當的響應。在步驟114之后，處理結束。
在一些實施例中，步驟104由RTCA執行，使得RTCA是具有秘密密鑰的知識的唯一實體。在這種情況下，RTCA將相應的公鑰呈現給CA(或在線或離線方式)，使得CA可在步驟106產生證書。當然，在這樣的情況下，不必執行如上所述的步驟108。這可由流程圖100中示出的從步驟106到步驟112的另一流程116說明。
應注意，流程圖100的步驟甚至可在CA和RTCA為同一實體的情況下執行。當然，在這樣的情況下，在步驟102驗證RTCA是沒有價值的。此外，對于RTCA/CA將使用同一公鑰和秘密密鑰對用于CA運行和RTCA運行的實施例，步驟104、106、108和112不需要被執行，因為RTCA證書將簡單地是CA的證書。然而，在使RTCA證書格式不同于CA證書格式(如OCSP應答器證書格式)有用的情況下，步驟106可在為RTCA證書產生不同格式的證書時執行。
參考圖5，流程圖120示出了在定期將證書有效性數據從CA傳送給RTCA時執行的步驟。流程圖120的步驟或可定期執行，或可基于RTCA的專用請求執行。處理開始于第一測試步驟122，確定最近是否有任何證書已被廢除(即自上一次迭代以來)。如果是，則控制從測試步驟122轉到步驟124，作廢信息被發送給應答器。如本說明書別處所述，在一些實施例中，作廢信息被立即(盡可能接近立即)從CA發送給RTCA。在一些實施例中，在步驟124從CA發送給RTCA的作廢信息被數字簽署或被鑒定。
在步驟124之后或測試步驟122之后(如果最近沒有證書被廢除)是測試步驟126，確定當前時間是否對應于用于更新證書信息的新的時間間隔。如本說明書別處所述，在一些實施例中，CA以周期性的間隔將新的確認信息進棧到RTCA。因此，如果在測試步驟126確定當前時間不對應于新間隔，則控制從測試步驟126轉回到前述的步驟122。否則，如果當前時間對應于新間隔，則控制從測試步驟126轉到步驟128，新的確認信息由CA產生，在一些實施例中，其包括數字簽署或鑒定該信息。如本說明書別處所述，新的確認信息可以是多種形式中的任何一種，包括CRL。
在步驟128之后是步驟132，在步驟128產生的新確認信息被提供給RTCA。在步驟132之后是測試步驟134，其確定RTCA是否已確認接收在步驟132發送的信息。如果否，則控制從步驟134轉到步驟136，執行錯誤處理。在步驟136執行的錯誤處理可包括通知系統管理員。應注意，在步驟134確定RTCA是否已接收新信息是有用的，因為懷惡意的攻擊者可能使RTCA停用，以作為防止關于最近廢除的證書的信息被傳播的手段。在步驟136之后，處理結束。
如果在測試步驟134確定RTCA已確認接收在步驟132發送的信息，則控制從步驟134轉回到步驟122以處理下一迭代。在一些實施例中，數據被定期從CA提供給RTCA，而不管RTCA是否確認數據的接收。這由另一路徑137圖示。
在一些實施例中，流程圖120的步驟不定期執行，而是僅響應于RTCA請求數據的特定請求執行。這由另外的路徑138圖示，其使得控制從步驟122或步驟124直接轉到步驟128。還應注意，另外的路徑142對應于在步驟134的確認的接收。因此，在流程圖120的步驟不定期執行的實施例中，當在測試步驟134確定RTCA已確認接收在步驟132發送的信息，則路徑142指示處理結束。當然，還可能有RTCA不確認接收來自CA的信息的實施例。這由另一路徑144圖示。
參考圖6，流程圖150示出了在數據被定期從RTCA進棧到RTC應答器的實施例中，由RTCA所執行的處理。處理開始于第一步驟152，RTCA確定自先前進棧以來是否已接收新數據。如果否，則控制轉回到步驟152以繼續循環和輪詢，直到新的數據被接收為止。一旦在測試步驟152確定新的數據已被接收，則控制從步驟152轉到步驟154，數據被從RTCA傳到RTC應答器。在步驟154之后，控制轉回到步驟152以繼續輪詢等待新數據。
參考圖7，流程圖160示出了在響應于RTC應答器的請求而將數據從RTCA提供給RTC應答器的實施例中RTCA執行的步驟。如本說明書別處所述，RTC應答器自身可定期從RTCA請求數據，而不是依賴于使數據被定期從RTCA自動進棧到RTC應答器。
處理開始于第一步驟162，RTCA從RTC應答器接收查詢(請求數據)。在步驟162之后是測試步驟164，其確定RTC應答器是否請求RTCA證書。如本說明書別處所述，RTCA證書用于說明CA信任并授權RTCA提供確認信息。在一些實施例中，每一RTC應答器可緩存RTCA證書(將被提供，如果被請求和/或依賴方需要的話)，在這種情況下，只需請求RTCA證書一次。在其它實施例中，RTC應答器可定期請求RTCA證書，或者在某些情況下，一直請求RTCA證書。
如果在測試步驟164確定RTC應答器已請求RTCA證書，則控制從測試步驟164轉到步驟166，RTCA提供RTCA證書給RTC應答器。在步驟166之后或在測試步驟164之后(如果RTC應答器尚未請求RTCA證書)是測試步驟168，其確定其它信息(即人工預計算的響應)是否已被請求。如果否，則處理結束。否則，控制從測試步驟168轉到測試步驟172，其確定另一信息是否可在RTCA獲得。在某些情況下，由RTC應答器請求的另一信息不可在RTCA獲得。例如，如果RTC應答器請求關于外來證書的信息，人工預計算的響應不可在RTCA獲得。
如果在測試步驟172確定所請求的信息不可獲得，則控制從測試步驟172轉到步驟174，RTCA提供數據給RTC應答器，其指明所請求的信息不能得到。在步驟174之后，處理結束。如果在測試步驟172確定所請求的另一信息可得到，則控制從測試步驟172轉到步驟176，所請求的信息由RTCA提供給RTC應答器。在步驟176之后，處理結束。
參考圖8，流程圖190示出了在從依賴方接收請求人工預計算響應(OCSP響應)的請求時RTC應答器所執行的步驟。處理開始于第一步驟192，接收請求。在步驟192之后是步驟194，RTC應答器獲得適于該請求的RTCA數據。在步驟194獲得RTCA數據將在本說明書別處詳細描述。在步驟194之后是測試步驟196，確定是否可得到所請求的數據。如果否，則控制從測試步驟196轉到步驟198，RTC應答器提供響應給依賴方，其指明不知道特定證書的狀態。在步驟198之后，處理結束。
如果在測試步驟196確定最新的有效性數據可用于感興趣的證書，則控制從測試步驟196轉到步驟202，對數據執行檢查。如本說明書別處所述，在步驟202執行的檢查可包括下述任一或多個確定數據的當前性，確定RTCA證書尚未被纂改并依然有效，及任一或多個可對步驟194獲得的數據執行的其它檢查。
在步驟202之后是測試步驟204，其確定在步驟202執行檢查的結果是否指示一切正常。如果否，則控制從步驟204轉到步驟206，向依賴方提供表明有效性數據不能認可的指示。可在步驟206執行其它適當的處理，例如包括將錯誤通知給系統管理員。在步驟206之后，處理結束。
如果在測試步驟204確定有效性數據可以認可，則控制從測試步驟204轉到測試步驟208，確定依賴方是否請求RTCA證書。如果否，則控制從測試步驟208轉到步驟212，向依賴方提供有效性數據(人工預計算響應)。在步驟212之后，處理結束。否則，如果在測試步驟208確定RTCA證書連同有效性數據一起被請求，則控制從測試步驟208轉到步驟214，有效性數據(人工預計算的響應)和RTCA證書被提供給依賴方。在步驟214之后，處理結束。
對于某些實施例，依賴方可執行其自己的有效性數據檢查，在這種情況下，不必執行步驟202的檢查或步驟204的相應測試。這可由從步驟196到步驟208的另一流程路徑216圖示說明。
參考圖9，流程圖230更詳細地示出了在圖8的流程圖190的步驟194獲取RTCA數據時由RTC應答器執行的步驟。流程圖230對應于RTCA數據由RTCA自動進棧到RTC應答器的實施例，RTC應答器不必明確請求數據。對于這些實施例，應答器總是自動擁有最新(或接近于最新)的RTCA數據。
處理開始于第一測試步驟232，RTC應答器確定所請求的數據是否可在RTC應答器得到。如果是，則控制從測試步驟232轉到測試步驟234，其確定在RTC應答器的所請求的數據是否是最新數據。如本說明書別處所述，人工預計算的響應可包括人工預計算響應在其期間均有效的時間間隔，在該時間間隔之后，需要獲取新的人工預計算響應。不管用于確定人工預計算響應的時間間隔的特殊機制，在測試步驟234確定由依賴方請求的特殊的人工預計算響應是否是最新的，其通過比較當前時間和與人工預計算響應相關聯的時間間隔而進行確定。
如果數據是最新的，則控制從測試步驟234轉到步驟236，其確定RTCA證書是否有效。在某些情況下，RTCA證書將被廢除(或將要期滿)也是可能的，從而RTCA提供的數據可能不可靠。例如，如果RTCA的秘密密鑰已泄密，則RTCA證書可變為已作廢。在步驟236確定RTCA證書的有效性可使用多種已知技術中的任一一種執行，包括在此描述的技術。如果在測試步驟236確定RTCA證書有效，則控制從測試步驟轉到步驟238，提供所請求的人工預計算響應以用于進一步處理，如結合圖8的流程圖190所述的。在步驟238之后，處理結束。
如果在測試步驟232確定不能得到數據，或如果在測試步驟234確定所請求的數據不是最新的，或如果在測試步驟236確定RTCA證書不是有效的，則控制轉到步驟242，其表明在圖8的流程圖190的步驟處理之后不能得到數據。在一些實施例中，在步驟242提供的信息可包括不能得到所請求信息的原因。在步驟242之后，處理結束。
在一些實施例中，可能不希望在每一迭代時均檢查RTCA證書的有效性。對于這些實施例，步驟236可被省略，這由另一路徑244圖示說明。
還應注意，還可能使用流程圖230所示的處理，其用于RTC應答器定期從RTCA請求新數據的實施例。在這樣的情況下，數據可能不可得到或不是最新的，因為其尚未由RTC應答器從RTCA請求。
參考圖10，流程圖260更詳細地示出了在圖8的流程圖190的步驟194獲取RTCA數據時所執行的步驟，其用于RTC應答器從RTCA請求數據的實施例。處理開始于第一步驟262，確定依賴方是否已請求RTCA證書。如果是，則控制從步驟262轉到步驟264，確定RTCA證書是否被RTC應答器緩存。如果否，則控制從測試步驟264轉到步驟266，RTC應答器從RTCA請求RTCA證書。
在步驟266之后、或在步驟262之后(如果RTCA證書未被請求)、或在步驟264之后(如果所請求的證書不能得到)是測試步驟268，確定人工預計算響應是否已被請求。如果是，則控制從測試步驟268轉到測試步驟272，確定所請求的人工預計算響應是否被緩存(當然是最新的)在RTC應答器。如果否，則控制從測試步驟272轉到測試步驟274，RTC應答器從RTCA請求人工預計算響應。在步驟274之后、或在步驟268之后(如果沒有人工預計算響應被請求)、或在步驟272之后(如果所請求的人工預計算響應被緩存)是步驟276，獲取所請求信息的結果被提供以繼續圖8的流程圖190的步驟的處理。在步驟276之后，處理結束。
參考圖11，流程圖300示出了在建立雙方交易以避免第三方交易的額外步驟和處理的實施例中，由用戶或用戶與其交易的依賴方執行的步驟。處理開始于第一測試步驟302，確定用戶和/或依賴方已緩存的信息(人工預計算響應)是否是最新的(或根本存在于本地)。如果是，則控制轉回到測試步驟302以繼續輪詢直到信息不是最新時為止。一旦在測試步驟302確定緩存的信息不是最新的，則控制從測試步驟302轉到步驟304，實體(用戶和/或依賴方)獲取最新信息，如本說明書別處所述。在步驟304之后是步驟306，在步驟304獲得的信息被本地保存(緩存)。在步驟306之后，控制轉回到步驟302以繼續輪詢直到所緩存的信息不再是最新的時候為止。
參考圖12，證書320被示作包括傳統的證書信息322和RTCA證書信息324。證書320可以是用戶證書或CA證書。如上所述，在一些實施例中，可能將RTCA證書324證明的公鑰嵌入在證書中。當依賴方查看證書320(或用戶證書或CA證書)時，不必單獨獲取RTCA證書。在其它實施例中，RTCA證書信息324包括整個RTCA證書或指向其的指針。
參考圖13，示意圖400示出了CA402、RTCA404、RTC應答器406、和依賴方408之間的信息流。如本說明書別處所述，CA402提供確認信息(如CRL)412給RTCA404。RTCA404產生多個人工預計算響應416，其被提供給RTC應答器406。在某些情況下，RTCA404還可提供RTCA證書414給RTC應答器406。然而，如本說明書別處所述，RTCA證書414可僅被提供一次或獨立于RTCA404定期提供，RTCA404提供人工預計算響應416給RTC應答器406。
依賴方408產生依賴方408提供給RTC應答器406的OCSP請求418(或某些其它類型的請求有效性信息的請求)。RTC應答器406通過提供人工預計算的OCSP響應422而服務于OCSP請求418，所述響應是先前從RTCA404提供給RTC應答器406的人工預計算OCSP響應422之一。之后，依賴方可使用人工預計算響應422基于所涉及證書的有效性狀態而采取適當的進一步行動。如本說明書別處所述，在一些情況下，RTC應答器406可提供RTCA證書414給依賴方408。
參考圖14，示意圖430示出了在兩個另外的獨立數字證書系統之間傳送確認信息。示意圖430示出了圖13的示意圖400的CA402、RTCA404、RTC應答器406、及依賴方408。示意圖430還示出了由CA402提供給RTCA404的確認信息412，并示出了從RTCA404傳給RTC應答器406的RTCA證書414和人工預計算響應416。
示意圖430還示出了第二CA432、第二RTCA434、第二RTC應答器436、及第二依賴方438。第二CA432提供確認信息442給第二RTCA434。第二RTCA434提供人工預計算響應446給第二RTC應答器436。然而，假定CA402和第二CA432管理獨立的數字證書集，則CRL412包含關于不同于CRL442的證書的信息，且人工預計算響應416包含不同于人工預計算響應446的證書的信息。因此，當第二依賴方438提供OCSP請求448給關于CA402管理的證書的第二應答器436時，由第二RTCA434提供的人工預計算響應446中沒有響應可適于滿足OCSP請求448。
如果RTCA404已提供人工預計算響應416給第二RTC應答器436且如果RTCA404先前已提供RTCA證書414給第二RTC應答器436，則上述困難可得以解決，第二RTC應答器436可通過將RTCA證書414及RTCA404產生的人工預計算響應422提供給第二依賴方438而滿足OCSP請求。應注意，如本說明書別處所述，從RTCA404到第二RTC應答器436的傳輸不必須是安全的，因為在傳輸給第二應答器436之前，RTCA證書414和人工預計算響應436已被數字簽署。
參考圖15，示意圖460示出了產生圖14的示意圖430所示的系統。在示意圖460中，RTCA404提供人工預計算響應416給RTC應答器的異類云462。類似地，第二RTCA434提供人工預計算響應446給RTC應答器的異類云462。RTCA404、434還可將其各自的RTCA證書(未示出)提供給RTC應答器的異類云462。應注意，任何數量的RTCA均可將人工預計算響應和/或RTCA證書提供給RTC應答器的異類云462。因此，依賴方408、第二依賴方438、或某些其它依賴方可接收人工預計算響應中的適當響應，可選地，還可響應于OCSP請求(或某些其它類型的請求)接收RTCA證書，所述請求是對于其人工預計算響應被提供給異類云462的任何證書的請求。
在于此描述的技術解決了傳統OCSP的許多缺陷的同時，如成本高昂的計算、高通信量及花費高昂的安全服務器復制，另外的優化甚至可減少更多的計算和通信成本。具體地，在RTCA和RTC應答器之間的通信量可通過適當的壓縮而減少，如下所述。因下述技術的組合所得的節約非常明顯，特別是使用標準OCSP語法時更是如此。
如上所述，RTCA發送人工預計算響應給每一RTC應答器，每一人工預計算響應可由多個數據元組成，如響應類型、計算響應的時間、數字簽名算法標識符、RTCA的id、證書號、證書是有效還是無效、及數字簽名本身。這些項目中的許多項目是相同的、或類似的、跨多個響應。例如，對于所有響應，計算響應的時間及RTCA的id均是相同的。當所有響應被共同從RTCA發送給RTC應答器時，共同的數據元可僅被傳輸一次。當回答依賴方請求時，RTC應答器還可重新構造適當的響應。此外，當數據項目類似但不相同時，可使用適當的壓縮算法以利用類似處并僅傳送相差的地方。
此外，為進一步降低計算響應并傳送給應答器的成本，基于部分而不是所有證書的有效性狀態更新應答器是有利的。例如，所有證書的有效性狀態可能按小時更新，而部分高優先性(如高安全性)證書可能使其狀態每分鐘更新。或者(或此外)，新近作廢的證書可使其有效性狀態被立即向應答器更新以降低不適當使用的風險。或者，RTCA可向應答器提供其狀態已改變的證書的每一分鐘的更新，同時還提供每日(或每小時)簽署的所有證書的有效性狀態信息。
可使用標準普通壓縮技術(如Lempel-Ziv)進一步降低通信成本。壓縮技術可在上述優化已經降低通信量之后應用。
上述優化降低了RTCA上的計算負載及RTCA和應答器之間的通信成本，因為，在許多情況下，只需計算更少量的簽名。實際上，通過減少計算和通信引起的等待時間，該方法增大了安全性如果RTCA不得不一直處理和發送所有數字證書的有效性狀態，應答器具有較其應有的更多的當前信息。
參考圖16，流程圖470示出了壓縮RTCA和RTC應答器之間通信的數據的步驟。處理開始于第一步驟472，移除計劃外的項目，不進行傳輸。如上所述，可能的優化之一是以不同的頻率更新關于證書的信息，越重要的證書，更新越頻繁。因此，在每一更新周期，關于較不重要的、計劃外的證書的信息被從將從RTCA發送給RTC應答器的信息中刪除。
在步驟472之后是步驟474，從剩余的數據中刪除多余的項目。如上所述，多余的項目包括對正被傳輸的信息均一樣的項目。例如，對從RTCA傳給RTC應答器的所有信息，RTCA的身份和更新時間均是一樣的。在步驟474之后是步驟476，對剩下的信息應用壓縮算法。各種可能的壓縮算法如上所述。在步驟476之后，處理結束。
證明證書的有效性在證明一個聲稱的身份時是有價值的。然而，在某些情況下，證明一個聲稱的身份通常與訪問特定的物理位置、邏輯實體或服務的特權相關聯。身份和特權的關聯可以是不言明的，并可不適應控制同一用戶的多個獨立特權的需要。不同的方法將采用每一獨立特權的分開的特權狀態。RTCA可被擴展以除提供證書狀態以外還提供多個特權的特權狀態。
特權可由一個或多個授權機構授予。這可以是暗含的過程，其中授權機構和CA為同一實體。在這樣的情形下，證明其身份的用戶可建立訪問特定位置、邏輯實體或服務的用戶權限。然而，該方法的缺陷在于特權狀態可能與證書或身份有效性狀態是一樣的，因而對所有暗指的特權均導致單純的是/否回答。如下所述，這可通過擴展RTCA以為各個用戶提供個別的、獨立的特權狀態而得以解決。
在開始，CA證明RTCA為特權管理機構。例如，這可作為在本說明書別處描述的一般CA證明過程的一部分執行。CA可數字簽署證書，其指明CA信任并授權RTCA除證書有效性狀態以外還提供多個獨立的特權狀態。授權或可以是暗含的，或在RTCA證書中明確指出。
在證明之后，授權機構可將各個特權狀態的當前狀態通知給RTCA。授權機構可保持將特權的有效性狀態通知給RTCA，所述特權被授予授權機構可對其控制的每一用戶。例如，授權機構可(1)只要發生變化，以在線方式將任何特權狀態變化通知給RTCA，或(2)將指示變化的數字簽署的消息發送給RTCA。
確定實體為有授權的授權機構可通過使用由適當信任和授權的CA發出的數字簽署的證書進行。由每一授權機構控制的特權可在證書自身內(即由CA)或在位于RTCA的數據庫中或通過一些其它適當的手段與機構綁定。
當RTCA產生單獨簽署的證書有效性狀態消息時，RTCA可包括與特定證書相關聯的每一特權的狀態。作為提供證書的有效性狀態的過程的一部分，RTCA可包括與所涉及證書相關聯的每一特權的標識符和當前狀態。與特權狀態相關聯的時間間隔可與應用到證書有效性狀態的一樣。在這方面，預計算各個特權狀態可與如上所述的用于證書狀態確認的技術一樣并同時發生。特權狀態可被包括在與證書狀態確認一樣的數字簽署的消息中。
RTCA可將預計算的特權有效性狀態發送給未保護的RTC應答器。分布各個特權狀態的過程可與用于如上所述的證書狀態確認的一樣并同時發生。之后，應答器可保存RTCA預計算的特權狀態。在特權狀態確認信息被包括為證書狀態確認信息的一部分時，特權狀態信息可由如上所述的應答器保存為單一響應和/或可與證書確認信息一起保存。
如上所述，當依賴方向應答器詢問證書的有效性狀態信息時，RTC應答器可提供RTCA預計算的響應，其包括證書有效性狀態及所有相關的特權狀態。之后，依賴方可驗證預計算的響應(及，如果合適，還驗證RTCA證書)。依賴方對所接收響應的處理與上述類似，除了現在任何相關的特權狀態也可得到以外。特權狀態可被讀取和使用以確定是否授權所請求的訪問。擴展到提供多個清楚的特權狀態的RTC系統可類似于在本說明書別處描述的用于提供證書狀態的系統，除了預計算的OCSP響應現在可被知道包含特權有效性狀態及證書有效性狀態信息以外。
參考圖17，示意圖480示出了授權機構的實施。示意圖480示出了連到RTCA484的CA482。如本說明書別處所述，CA482提供信息給RTCA484。RTCA484連到多個RTC應答器486-488以向其提供信息，如本說明書別處所述。
示意圖480還示出了提供授權信息給RTCA484的授權機構492。可選地，CA482可以直接連到授權機構492以提供初始授權信息、授權機構證書、及任何其它適當的信息。如本說明書別處所述，CA482和授權機構492可以是同一實體，其由在CA482和授權機構492周圍的框496圖示。盡管未在示意圖480中示出，在此與授權機構492一起描述的系統可包括另外的RTCA、應答器等，如本說明書別處所述(例如，參見圖3及相應的描述)。
應注意，在一些實施例中，CA482可將授權機構證書直接提供給RTCA484，而不用從CA482提供證書給授權機構492。還應注意，授權機構證書(或其它授權證據)可在由CA482發出的證書中提供(類似于上面圖12中所示的那樣)或由CA482提供給RTCA484的其它信息提供。
在RTC系統解決了許多OCSP缺陷的同時，進一步的優化也是可能的。具體地，RTCA的計算成本可通過一次處理多個數字簽名而得以降低。對于上述系統，RTCA簽署每一數字證書的狀態。即使這被提前完成，甚至可能在做出狀態查詢之前，也可能希望降低該過程的計算成本，特別是因為數字簽名的產生是計算集中的運算。
如下面將詳述的，通過使簽名有效RTCA(SERTCA)將多個證書的狀態結合在單一聲明中并繼而簽署并注明該聲明的日期而提供改進，從而使用單一簽名即可鑒定多個證書在特定時間點的狀態。其狀態被那樣鑒定的證書的數量可以是固定的(每一聲明總是包含同樣數量證書的狀態信息)，也可以是變化的。在單一聲明中確定的證書也可在其它聲明中確定。例如，一聲明可代表屬于特定個體的所有證書的有效性狀態，另一聲明可代表具有某一整數間隔內的序號的所有證書的有效性。同一證書可能屬于兩個集合，因而屬于兩個單獨的鑒定聲明。
在鑒定特定時間間隔的所有聲明之后，SERTCA可發送聲明給一個或多個RTC應答器，其保存聲明以服務于依賴方的查詢。當接收關于證書X的查詢時，RTC應答器可取回包含X的有效性狀態的SERTCA簽署的聲明并將該聲明返回給依賴方。依賴方可驗證SERTCA簽名并在聲明中搜索關于X的信息，因而以經鑒定的方式獲知X的狀態。
當然，SERTCA還可發出關于單一證書的狀態的聲明，因此，如果SERTCA發出僅關于單一證書的聲明，則SERTCA可提供與RTCA一樣的信息。特定的SERTCA可某些時候可用作RTCA并在其它時候不用作RTCA(例如，根據特定時間的計算限制和需要)。系統可結合RTCA和SERTCA。
在開始，CA以類似于上面證明RTCA的方式證明SERTCA，如上所述。正象RTCA那樣，SERTCA是可以也可不與特定機構的CA一致的實體。每一CA提供其自己的一個或多個SERTCA，其中每一SERTCA具有特殊證書，即SERTCA證書。CA可數字簽署SERTCA證書，以表明CA信任并授權SERTCA提供關于CA的證書的有效性信息。這樣的證書將SERTCA狀態傳給特定實體(如由特定標識符、OID號等確定的實體)，并可將特定驗證密鑰PK(特定實體擁有其相應的秘密簽署的密鑰)與特定實體綁定。
正象RTCA那樣，即使CA和SERTCA一致，CA和SERTCA具有不同的簽署密鑰也是有利的。因此，無論CA和SERTCA是否代表同一實體，CA發出證書及SERTCA管理證書(如證明證書有效/已作廢/延緩決定)。這樣，即使CA和SERTCA一致，也可能依然使用單獨的SERTCA證書。在一些實施例中，每一CA僅具有一個SERTCA，盡管因為冗余或其它目的，具有一個以上是有利的，無論是否使用同一簽署密鑰。如果有多個SERTCA，則其中部分可簡單地用作RTCA。
應注意，正象RTCA那樣，SERTCA保護其簽署密鑰。例如借助于保險庫、安全設施、或安全硬件。CA保持將其證書的有效性狀態通知給SERTCA。例如，CA可(1)只要發生變化，以在線方式將證書有效性的任何變化通知給SERTCA，或者(2)當產生時將其CRL發送給SERTCA。在一連串日期D1、D2、…的任一日期Di，SERTCA基于其當前的確認狀態知識(如基于CA的最新CRL)并獨立于任何依賴方請求而執行更新，其通過處理CA的每一未完成(最好未過期)證書、將關于證書的有效性狀態的信息結合成集、并為每一集合數字簽署指明集合中每一證書的狀態的聲明(人工預計算響應)而實現。例如，這樣的狀態可以是有效、已作廢、或延緩決定(或可能是“不知道”、或“未發出”或另外的狀態指示)。簽署的聲明可指定時間間隔T。在一些實施例中，在每一更新時，每一簽署的聲明可指定相同的時間間隔T，且這些時間間隔的總數可覆蓋整個“時間線”。例如，在每一更新日期Di，時間間隔T＝Di+1-Di-其中可能只有Di和Di+1之一是T的一部分，而另一日期是相鄰時間間隔的一部分。
作為例子，聲明例子可具有形式SIG-SERTCA(“X有效；Y已作廢；Z延緩決定；日期Di；下一日期Di+1”)，其中X、Y和Z代表確定特定證書的信息(如序號)，及“有效”、“無效”、“已作廢”是相應證書狀態的指示符。如果SERTCA當前關于證書狀態的知識是基于CA的CRL，則每一Di可與一CRL的日期一致，Di+1與下一CRL的日期一致。應意識到，這樣嚴格的時間依存不是必需的。例如，在SERTCA處理或開始處理其聲明的日期可以是D1、D2等，而在聲明內指定的時間間隔可以是D1’、D2’等，其中Di和Di’可以不同。例如，Di可以早于Di’，在這種情況下，RTCA可在開始聲明的時間間隔之前開始處理聲明—例如，因為SERTCA希望在間隔T開始之前完成其處理。類似地，如果CRL在SERTCA更新時使用，聲明時間和CRL時間也可不同。
因此，實際上，SERTCA預計算的數字簽名指明所有證書在特定時間間隔T的狀態。這樣的預計算可獨立于任何關于證書有效性的依賴方請求進行執行。SERTCA可在時間間隔中做出任何狀態查詢之前甚至在該時間間隔開始之前為該特定時間間隔預計算簽署的聲明。證書狀態的SERTCA簽署的聲明(人工預計算響應)可以是標準OCSP格式，也可以是與現有依賴方軟件兼容的格式。在OCSP軟件已經在其位時，這對最小化或消除對現有依賴方軟件的修改是有用的。例如，為確保依從OCSP的所有有關數量，可適當地選擇數字簽名算法、OID等。
然而，應注意，SERTCA的句法正確的OCSP響應不必須是傳統的OCSP響應，因為SERTCA響應不響應于任何請求進行計算。實際上，SERTCA對尚未產生且可能永遠不會產生的OCSP請求預計算OCSP依從的響應。SERTCA響應，無論是否是OCSP格式，均是人工預計算的響應。
在預計算響應之后，SERTCA可使響應可用于其它方。盡管SERTCA可響應于有效性狀態查詢將響應返回給依賴方，在其它實施例中，SERTCA可提供預計算的響應給RTC應答器，其與上述連同RTCA使用的RTC應答器相似。
SERTCA可通過以適當組織的方式將簽名呈現給RTC應答器而幫助RTC應答器處理簽名。為確保所有有關的預計算響應均已接收，在每一次更新時，SERTCA可向RTC應答器提供另外的簽名，其通過簽署并注明RTC應答器接收的人工預計算響應的總體的日期而進行。此外，SERTCA可發送SERTCA證書給RTC應答器。該傳送不必在每次更新時都發生，其可僅在開始時或定期執行。
RTC應答器可將所接收的SERTCA的人工預計算響應保存足夠長的時間。在一些實施例中，如果簽名涉及特定時間間隔T，則RTC應答器可將人工預計算響應至少保存到T結束為止。在一些實施例中，RTC應答器(特別是那些與SERTCA屬于同一組織的應答器)可檢查以具有正確信息。例如，RTC應答器可驗證在T開始之前(或其它與T有關的適當時間)接收的關于時間間隔T的人工預計算響應，驗證所有所接收的SERTCA簽名(可能及適當的SERTCA證書)，驗證RTC應答器是否已接收關于所有證書的信息(如不少于預期數量的證書，不少于上一傳輸已經發出的證書)，驗證RTC應答器是否已接收先前被聲明作廢的證書的有效性的DERTCA簽署的聲明等。如果檢測到任何問題，RTC應答器通知SERTCA或另一適當的實體。
依賴方可向RTC應答器詢問證書的有效性狀態。在一些實施例中，依賴方使用OCSP格式用于請求。如果同一證書狀態上的信息出現在一個以上聲明中，依賴方可向RTC應答器指明哪一聲明是依賴方的首選。例如，如果SERTCA提供代表屬于特定個體的所有證書的有效性狀態的聲明，并提供代表具有某一整數間隔內的序號的所有證書的有效性狀態的聲明，且依賴方主要對屬于個體I的具有序號X的證書的有效性狀態感興趣，則依賴方可提供指示優先選擇的指示符以接收(a)SERTCA簽署的聲明，其包括關于序號接近于X的證書的信息，或(b)SERTCA簽署的聲明，其包括關于I的其它證書的信息，或(c)非常短的SERTCA簽署的聲明，或(d)包括關于X的狀態的信息的SERTCA簽署的聲明(即沒有優先選擇)。根據情況選擇其中之一是有優點的。
當詢問特定證書的有效性時，RTC應答器可從存儲器取回SERTCA人工預計算響應，其包括該證書的信息。RTC應答器可返回人工預計算響應。RTC應答器還可為SERTCA轉發已簽署人工預計算響應的適當證書。應注意，依賴方可提供指示以接收SERTCA證書，或RTC應答器可能知道或假定依賴方已經有SERTCA證書的拷貝。如果有多個預計算的答案包含關于同一證書的信息，RTC應答器可根據依賴方的偏愛或某些指定算法或根據一些其它規則選擇返回哪一答案。
依賴方處理所接收的響應以確定感興趣證書的有效性。在一些實施例中，如果響應是OCSP格式，RTC應答器使用OCSP軟件用于這樣的處理。RTC應答器可驗證適當的SERTCA證書。在OCSP依從的實施例中，RTC應答器可將SERTCA證書驗證為OCSP應答器證書。在一些實施例中，SERTCA證書可在句法上構造成OCSP應答器證書。
參考圖18，示意圖500示出了在CA502、SERTCA504、RTC應答器506和依賴方508之間的數據流。CA502提供確認信息(如CRL)給SERTCA504。SERTCA504使用確認信息產生多個多證書人工預計算響應516。SERTCA504還有其自己的證書514，其可由CA502提供給SERTCA504。
依賴方508產生依賴方508提供給RTC應答器506的OCSP請求518。響應于此，RTC應答器506提供多證書人工預計算響應522，其是最初由SERTCA504提供給應答器506的多證書人工預計算響應516之一。此外，如本說明書別處所述，在某些情況下，應答器506提供SERTCA證書514給依賴方508。
應注意，上述RTCA系統的處理同樣可適于與SERTCA系統和/或混合系統一起使用，包括使用授權機構，如上所述，以及提供上面連同圖16所述的壓縮優化。類似地，上述SERTCA系統的處理同樣適于與RTCA系統和/或混合系統一起使用。
另一技術，批處理OCSP可用于降低RTCA或SERTCA計算成本。批處理OCSP可單獨使用，也可與在此描述的一個或多個其它機制結合使用。
當在響應中使用的特殊數字簽名是RSA數字簽名時可采用批處理OCSP。在SERTCA通過鑒定單一簽名中的多個證書的狀態而提高簽名效率時，批處理OCSP可借助于單一計算產生多個單證書OCSP響應而提高效率，使每響應成本大大低于單一OCSP響應的成本。例如，如果10個單證書OCSP響應單獨產生，成本大概是RTCA(或傳統OCSP應答器)的10個RSA簽名的成本。如上所述，SERTCA機制可將成本降低到一個RSA簽名的成本，其通過將10個證書上的信息組合在單一聲明中實現。然而，使用SERTCA的缺陷在于相應的聲明變得更長。批處理OCSP可以低于10個RSA簽名的成本的總成本(在一些情況下，大約為2個RSA簽名的成本)產生10個不同的單證書，單獨簽署的OCSP響應。
如下所述，批處理OCSP基于Fiat的批處理RSA計算。RSA的公鑰PK由兩個整數組成，即(N，e)，其分別為公知的模數及驗證指數。模數是兩個大的秘密質數p和q的積，RSA的安全性依賴于從模數N發現其組成質數的難度。相應的秘密密鑰SK由(N，d)組成，其中d具有下述特性對于所有小于N的正整數b，如果s等于b與以N為模的冥d自乘，則b等于s與以N為模的冥e自乘。換言之，將整數與以N為模的冥e自乘的運算和將整數與以N為模的冥d自乘的運算正好相反。
RSA數字簽名的計算包括(可能隨機地)格式化消息m的散列以獲得b，繼而通過使b與冥d自乘而獲得簽名的計算，之后得到以N為模的結果。相應的驗證過程從s計算b，通過使s與以N為模的冥e自乘進行，并檢查b實際上是否正確地從m產生。Fiat批處理RSA簽名的評論如下所述。假如具有多個值b1、…、bi，多個驗證指數e1、…、ei，及相應的簽署指數d1、…、di。之后，通過使用號碼理論算法(未在此描述，但在本領域是公知的)，s1對以N為模的冥d1、s2對以N為模的冥d2、…、si對以N為模的冥di的計算可比i個單獨的個別計算更有效率地執行(假定e1、…、ei不同且滿足某些其它條件)。
如上所述，SERTCA(及RTCA)具有由CA發出的數字證書，其證明SERTCA在預計算OCSP響應上簽名使用的公鑰，所述預計算OCSP響應指明數字證書的有效性信息。同樣如上所述，SERTCA數字證書由將幾個數如SN、對證書獨一無二的序號、PK、SERTCA的公鑰、標識符、發出日期、期滿日期、及另外的數據安全綁定在一起的CA的數字簽名組成。表示成符號C＝SIGCA(SERTCA，SN，PK，ID，D1，D2，...)。在RSA數字簽名由SERTCA使用的情況下，SERTCA的公鑰PK采用(n，e)的形式，其中n是模數，e是驗證指數，且證書采取形式C＝SIGCA(SERTCA，SN，(n，e)，ID，D1，D2，…)RTC應答器和依賴方可以經鑒定的方式從SERTCA證書獲知SERTCA公鑰。然而，由于傳統的證書僅包含單一指數e，傳統的證書不適于與使用多個不同指數的批處理RSA一起使用。除非驗證人(RTC應答器和/或依賴方)知道在鑒定數字證書的有效性信息的特定簽名中使用的驗證指數，驗證人將不能驗證簽名。下面使用批處理OCSP內的批處理RSA克服了該問題。
在一方法中，SERTCA首先產生傳統RSA簽名中那樣的模數n，并將n呈現給CA用于驗證為SERTCA的公鑰。SERTCA保護其秘密密鑰，其由質數p和q組成。之后，CA向SERTCA發出用于僅由n組成的公鑰的數字證書。例如，SERTCA證書可采取C＝SIGCA(SN，n，ID，D1，D2，...)的形式。之后，CA將SERTCA的用戶證書的狀態通知給SERTCA。接著，SERTCA產生i個簽署指數d1、…、di及相應的驗證指數e1、…、ei。獨立于任何依賴方請求，SERTCA產生關于一個或多個證書在特定時間間隔的有效性狀態的聲明，并將這些聲明結合為大小為i的一批，并在每一批內用指數d1、…di使用批處理RSA，為每一聲明產生數字簽名。接著，SERTCA將有效性狀態的預計算簽名發送給未保護的應答器，另外包括允許應答器和/或依賴方確定用于驗證每一聲明的指數ej的信息。之后，應答器保存SERTCA人工預計算的響應。
當依賴方向應答器詢問有效性狀態信息時，RTC應答器用人工預計算響應回答查詢。每一響應包括驗證響應需要的驗證指數ej及SERTCA證書(如果需要)。之后，依賴方可使用具有從SERTCA證書獲得的模數n和從RTC應答器獲得的驗證指數ej的RSA驗證來驗證人工預計算的響應。
對該方法變化也是可能的。例如，如果指數是任意的(且在發出RSA簽名前沒有使用特殊的消息格式)，已從SERTCA證書獲知SERTCA模數n的敵人可尋找使敵人能夠產生相對于n和e的假聲明的RSA簽名的指數e。為提高安全性，SERTCA指數e1、…、ei可被提前固定(并不必每次均可由應答器得到)。具體地，指數可被指定為由CA簽署的SERTCA證書的一部分。接著，SERTCA證書可采取形式C＝SIGCA(SERTCA，SN，(n，e1，...，ei)，ID，D1，D2，...)依賴方還可從SERTCA證書或另一來源獲得驗證指數，而不是從應答器獲得。
使應答器和/或依賴方能夠推斷哪一指數ej被用于特定聲明而不是清楚地指明該信息是有利的。例如，如果在每一批中確認的第j證書總是具有適合以i為模的j的序號，則可進行這樣的推斷。接下來，應答器和/或依賴方能夠簡單地從其有效性正被驗證的證書的序號推導指數的冥j。
應注意，在該方法中，依賴方驗證實施可能不遵循標準RSA簽名驗證范例，因為SERTCA的公鑰可不按對(n，e)呈現給依賴方。修改現有依賴方RSA實施的成本在某些應用中是不允許的。這可由下述另外的方法解決。
對于第二方法，SERTCA在開始產生與傳統RSA簽名中一樣的模數n、及i個驗證指數e1、…、ei，SERTCA將其呈現給CA用于證明。對于SERTCA，保護n的素數因素分解是有利的。之后，CA可發出i個用于公鑰的數字證書，公鑰由PK1＝(n，e1)、PK2＝(n，e2)、...PKi＝(n，ei)組成。例如，i個SERTCA證書可采取形式C1＝SIGCA(SERTCA，SN，(n，e1)，ID，D1，D2，…)、…、Ci＝SIGCA(SERTCA，SN，(n，ei)，ID，D1，D2，…)。之后，CA可將其用戶證書的狀態通知給SERTCA。在其之后，且獨立于任何依賴方請求，SERTCA產生關于一個或多個證書在特定時間間隔的有效性狀態的聲明，并將這些聲明結合為大小為i的一批，并在每一批內用指數d1、…di使用批處理RSA，為每一聲明產生數字簽名。接著，SERTCA將有效性狀態的預計算簽名發送給未保護的應答器，另外包括允許應答器和/或依賴方確定用于驗證簽署每一聲明的指數ej的信息。應答器保存SERTCA預計算的響應。
當依賴方向應答器詢問有效性狀態信息時，RTC應答器用預計算響應回答查詢。用指數ej簽署的每一響應包括第j個SERTCA證書Cj(如果需要或被請求)。依賴方使用具有從SERTCA證書獲得的公鑰(n，ej)的RSA驗證來驗證預計算的答案。應注意，依賴方驗證與標準RSA驗證在句法上一樣，因為標準形式的RSA公鑰是從SERTCA證書獲得。因此，對依賴方而言，不需修改標準RSA實施。實際上，依賴方可能完全不知道SERTCA正使用批處理OCSP。
對上述方法進行變化也是可能的。例如，不是選擇指數e1、…、ej并呈現給CA—這樣的指數可被CA提前推斷或知道—例如，因為這些指數是系統的固定參數。或者，應答器和/或依賴方能夠推斷哪一指數ej被用于特定聲明而不是清楚地指明該信息是有利的。例如，如果在每一批中確認的第j證書總是具有適合以i為模的j的序號，則可進行這樣的推斷。接下來，應答器和/或依賴方能夠簡單地從其有效性正被驗證的證書的序號推導指數的冥j。
參考圖19，流程圖600示出了在初始化SERTCA(或適當的RTCA或OCSP應答器)以執行批處理OCSP時執行的步驟。處理開始于低于步驟602，CA證明模數n。在步驟602之后是步驟604，產生i個指數對(驗證指數和簽署指數)。在于此的實施例中，指數對由SERTCA使用一對秘密質數產生，秘密質數的積等于n。然而，對于其它實施例，使其它實體產生步驟604的指數對及使用其它算法產生這些對也是可能的。
對于某些實施例，處理可在步驟604之后結束。然而，其它實施例可包括由CA進行另外的證明，如上所述，包括使CA證明驗證指數e1、e2、…、ei。在一實施例中，如步驟606所示，CA證明單一證明中的i個驗證指數，如上所述。在另一實施例中，如步驟608所示，CA證明表示n、ek的RSA風格公鑰的i個單獨證書，其中ek是i個驗證指數之一。
參考圖20，流程圖620示出了在產生人工預計算響應時SERTCA(或適當的RTCA或OCSP應答器)執行的步驟。處理開始于第一步驟622，CA提供確認信息給SERTCA，如本說明書別處所述。在步驟622之后是步驟624，SERTCA使用簽署指數d1、d2、…、di產生人工預計算響應。在步驟624之后是步驟626，SERTCA以類似于本說明書別處所述的方式將人工預計算響應提供給RTC應答器。
在一些實施例中，SERTCA可提供另外的指數信息給RTC應答器。這由圖20的流程圖620中所示的可選步驟圖示說明。另外的指數信息可由正使用的特定指數的一個或多個證明和/或指示哪些特定指數用于哪些人工預計算響應的信息組成。當然，如本說明書別處所述，也可有其它機制確定哪些指數用于哪些人工預計算響應，從而對于SERTCA，不必單獨提供那樣的信息。類似地，可以有用于將指數信息通信給RTC應答器(最終通信給依賴方)的機制，從而不必為指數單獨提供任何另外的證明。
應注意，上述批處理OCSP技術可代替SERTCA與RTCA一起使用，也可與傳統的OCSP框架一起使用，其中OCSP應答器基于從依賴方接收查詢而計算數字簽署的證書狀態信息。具體地，如果OCSP應答器接收孤立的查詢，則OCSP應答器可產生單個RSA簽署的響應，但如果OCSP應答器在很短時間內接收許多查詢，OCSP可以上述批處理的方式回答所有或部分查詢。下面將對此進行闡述。
最初，CA將其用戶證書的狀態以與OCSP相容的方式通知給OCSP應答器。在接收多個證書狀態查詢的基礎上，應答器可使用批處理RSA計算獨立的單證書，對第i查詢的傳統OCSP響應，每一均與指數ej有關。OCSP應答器還可指定一致的指數和/或包括CA簽署的應答器證書，其鑒定ej(及適當的RSA模數n)可用于驗證應答器簽名。CA可向OCSP應答器提供單一OCSP應答器證書，其指出只有RSA模數n由應答器用于其批處理RSA簽名。例如，表示成符號C＝SIGCA(responder，SN，n，ID，D1，D2，...)應注意，如果OCSP應答器使用的指數是固定的，則這特別準確和安全。或者，CA可向OCSP應答器提供應答器證書，其指定應答器可用于批處理RSA簽署的多個指數。例如，表示成符號C＝SIGCA(responder，SN，(n，e1，...ek)，ID，D1，D2，...)或者，對于特定OCSP應答器，CA可發出k個不同的應答器證書，每一證書對于應答器可用于批處理RSA簽署的每一指數。例如，表示成符號C1＝SIGCA(responder，SN，(n，e1)，ID，D1，D2，...)、...、Ck＝SIGCA(responder，SN，(n，ek)，ID，D1，D2，...)在此的整個描述中，CA、RTCA、應答器、交易方、用戶可以是任何實體(如個人、機構、服務器、設備、計算機程序、計算機文件)或實體的集合。證書應被理解為包括所有種類的證書，具體地，包括分級證書和平面證書。例如，參見美國專利5,420,927，其通過引用組合于此。有效性狀態和有效性狀態的證明可包括分級證書的有效性狀態和有效性狀態的證明(如一系列證書中所有證書的有效性狀態和有效性狀態的證明)。驗證證書C的有效性可包括驗證已發出C的CA的CA證書的有效性及提供關于C的有效性狀態的簽署響應的RTCA/SERTCA的RTCA/SERTCA證書的有效性。
在適當的情況下，數字簽署和數字簽名在此可被理解為包括任何適當的信息鑒定。
盡管證書描述將特定密鑰與特定用戶綁定的數字簽署的文檔，在美國專利5,666,416(通過引用組合于此)之后，證書還應被理解為包括所有類型的數字簽署的文檔。例如，充作CA的賣主可通過數字簽署價格表(可能連同日期信息一起)而證明價格表在其控制之下。知道這樣的證書的有效性狀態是有用的。例如，賣主可能想證明價格表的當前有效性(并拒絕價格表中的特定價格，除非展示其當前有效性的證明)。因此，客戶可能希望確定價格表文檔的當前有效性。在此描述的系統可用于此。在此描述的系統可用于證明網頁的當前有效性。在一些實施例中，RTCA/SERTCA產生的當前有效性的證明可與網頁本身一起保存(或與其關聯)。在這樣的情況下，交易方可被視作計算機文件。
發送一塊數據D(給交易方X)應被理解為包括使D可用(或使X接收D)。
應注意，在此描述的系統可使用硬件、軟件或其某種結合進行實施，包括但不限于通用計算機編程，以與專用硬件如數字信號處理硬件結合而提供在此描述的功能。
當本發明已結合多個實施例進行公開的同時，對本領域技術人員而言其修改是非常顯然的。因此，本發明的精神和范圍由下述權利要求提出。
權利要求
1.幫助第一方和第二方之間的交易的方法，包括在開始交易之前，交易方之一獲得關于特定數字證書的人工預計算的OCSP響應，其中人工預計算的OCSP響應由不同于第一方和第二方的實體產生；交易方之一開始交易；在交易時，第一方提供特定數字證書給第二方；及第二方使用人工預計算的OCSP響應驗證該特定數字證書。
2.根據權利要求1的方法，其中第二方在交易開始之前獲得人工預計算的OCSP響應。
3.根據權利要求2的方法，其中第二方緩存人工預計算的OCSP響應以用于將來交易。
4.根據權利要求1的方法，其中第一方在交易開始之前獲得人工預計算的OCSP響應。
5.根據權利要求4的方法，其中第一方緩存人工預計算的OCSP響應以用于將來交易。
6.根據權利要求4的方法，還包括在交易開始之后第一方提供人工預計算的OCSP響應給第二方。
7.確定數字證書的有效性的方法，包括檢查數字簽署的關于數字證書有效性的消息，其中消息由不同于發出數字證書的實體的特定實體數字簽署；及使用來自至少下述之一的信息驗證數字簽署的消息數字證書和鑒定發出數字證書的實體的證書。
8.根據權利要求7的方法，其中信息是對應于用于數字簽署消息的秘密密鑰的公鑰。
9.根據權利要求7的方法，其中信息對應于鑒定數字簽署消息的特定實體的特定數字證書。
10.提供關于數字證書有效性的信息的方法，包括為數字證書集中的每一證書確定數字證書有效性狀態；定期產生多個數字簽署的關于數字證書集的至少一子集的有效性狀態的人工預計算消息；及定期將數字簽署的人工預計算消息轉發給多個服務于依賴方的請求的應答器，所述依賴方詢問數字證書集中的數字證書的有效性狀態，其中關于一些證書的消息以不同于關于其它證書的消息的頻率進行轉發。
11.根據權利要求10的方法，其中關于作廢證書的消息相較關于有效證書的消息被相對不頻繁地進行轉發。
12.確定數字證書有效性的計算機軟件，包括檢查數字簽署的關于數字證書有效性的消息的可執行代碼，其中消息由不同于發出數字證書的實體的特定實體數字簽署；及使用來自至少下述之一的信息驗證數字簽署的消息的可執行代碼數字證書和鑒定發出數字證書的實體的證書。
13.根據權利要求12的計算機軟件，其中信息是對應于用于數字簽署消息的秘密密鑰的公鑰。
14.根據權利要求12的計算機軟件，其中信息對應于鑒定數字簽署消息的特定實體的特定數字證書。
15.保存在計算機可讀介質中的計算機軟件，其提供關于數字證書有效性的信息，包括為數字證書集的每一證書確定數字證書有效性狀態的可執行代碼；定期產生多個數字簽署的關于數字證書集的至少一子集的有效性狀態的人工預計算消息的可執行代碼；及定期將數字簽署的人工預計算消息轉發給多個服務于依賴方的請求的應答器的可執行代碼，所述依賴方詢問數字證書集中的數字證書的有效性狀態，其中關于一些證書的消息以不同于關于其它證書的消息的頻率進行轉發。
16.根據權利要求15的計算機軟件，其中關于作廢證書的消息相較關于有效證書的消息被相對不頻繁地進行轉發。
全文摘要
幫助第一方和第二方之間的交易包括在開始交易之前，交易方之一獲得關于特定數字證書的人工預計算的OCSP響應，其中人工預計算的OCSP響應由不同于第一方和第二方的實體產生；交易方之一開始交易；在交易時，第一方提供特定數字證書給第二方；及第二方使用人工預計算的OCSP響應驗證該特定數字證書。第二方可在交易開始之前獲得人工預計算的OCSP響應。第二方可緩存人工預計算的OCSP響應以用于將來交易。第一方可在交易開始之前獲得人工預計算的OCSP響應。第一方可緩存人工預計算的OCSP響應以用于將來交易。
文檔編號H04L9/00GK1985460SQ200580002180
公開日2007年6月20日 申請日期2005年1月10日 優先權日2004年1月9日
發明者戴維·恩貝里, 菲爾·利賓, 西爾維奧·米卡利 申請人:科爾街有限公司