公共密鑰基礎結構的製作方法

2023-10-09 23:30:04 2

專利名稱：公共密鑰基礎結構的製作方法
公共密鑰基礎結構發明領域本發明涉及公共密鑰基礎結構(PKI)。尤其是涉及數字籤名證書 的頒發及證實、系統以及便利該證實的相關方面。其與PKI系統之間 的交叉認證尤為相關。
背景技術：
公共密鑰基礎結構(PKI)是一種支持在可信任的團體間建立電子 信任的技術基礎結構。基於公共密鑰密碼學(PKC)的概念，該技術迄 今已被證明是為在網際網路和任何地方(包括銀行網絡)上包括安全電 子商務的安全通信的堅固平臺。公共密鑰密碼學(PKC)是一種允許團體通過使用公鑰和私鑰對進 行安全通信的技術。基於公共密鑰密碼學的通信可以既可信賴又安 全，即使使公鑰廣為人知以及可用。該技術在20世紀70年代期間作 為對稱密鑰密碼學(SKC)的替代技術首次被發明，後者要求共享密鑰 在希望通信的團體之間保密。為PKC大規模地成功運用通常要求建立一種公共密鑰基礎結構 (PKI )。在PKI的核心是一個可信代理，通常稱作為認證機構(CA ), 其證明用戶的公鑰的有效性。通過籤署這些密鑰形成一種數據結構即 (公鑰)證書完成上述功能。然後，使用必須通過可靠方法首先獲得 的、認證CA的公鑰，可以對公鑰進行電子方式地交換和驗證完整性。指定的認證機構可以支持為整個企業的單個應用或多個應用，假定 該企業規模不太大。由如此的企業CA頒發的證書被典型地存儲於諸如 機構目錄的數據儲存庫，在那兒應用對證書進行訪問。許多企業—— 包括汽車工業、金融和銀行業、石油和國防等部分——現在正在建立 機構CA。一個著名的大案例是美國國防部，該部已經建立一個約有1000 萬個證書的才幾構PKI。在正式術語中，PKI的兩組用戶可以被定義如下 訂戶(subscriber)是一個擁有私鑰和由CA頒發的相應數字證書的用戶、伺服器或加密設備，其使用證書發送已鑑定的(已 籤名的)消息。消息可包括數字籤名的電子郵件、或在挑戰-應答 鑑定協議中使用的消息交換。 信賴方(RP)是一個代理，其使用CA頒發的證書驗證由訂戶 籤名的消息的真實性。稱其為信賴方是因為信賴方依賴CA代表它 驗證那些發送數字籤名的電子郵件或通過在挑戰-應答鑑定協議中 所使用的消息交換進行反應的訂戶的身份。使用來啟動信任路徑建 立的CA證書被稱作為信任錨。信任錨經常是但並不總是層次結構 的根。可以建立具有根和一些下屬的CA的層次結構，而不是建立為一個 企業中所有應用的所有用戶提供服務的單個CA。層次結構允許證書管 理功能被分發到整個機構內，與用戶更接近。在適應性與安全性方面 這帶來益處。因為CA能夠以與其所服務的用戶極其接近的方式為證書 與撤銷列表出版運行，所以適應性增加。因為極其接近性促進PKI組 件和用戶群之間的帶外通信，所以安全性增加。現在參考圖1，信任總是從嚴格的CA層次結構中的根產生。這由 在層次結構的根(根A)處的環形箭頭圖示性地加以說明，該環形箭頭 表示自籤名(或自頒發)的證書。要指出的重要一點是，該層次結構的根是為機構A內所有信賴方 (RP)的共享信任錨。這是CA的嚴格層次結構的定義特徵.其結果是 所有RP以完全相同的方式確定信任。這起先似乎違反直覺，因為其最 初(雖然錯誤地)可能被假定大多數本地的CA是為發送和接收安全通 信的開始點。可是，在嚴格的層次結構中信任管理是不對稱的 為發送已籤名的通信，信任鏈從根經由本地CA擴展到訂戶的 證書。
為接收已籤名的通信，信任再次從根開始，如有必要將擴展到 從屬CA (或其它地方)的每一個CA。本地CA對該過程沒有影響。 可是，嚴格的層次結構具有某些缺點 根CA是企業失敗的單點。如果由於任何原因企業的根CA停止 服務一段時間，則證書撤銷信息不能被發布，導致潛在地拒絕經由 企業(包括本地域)的服務。更為嚴重的是，如果根被永久性的損 壞或受損，則必須對整個企業重新建立密鑰基礎結構，這會是一個 潛在地非常費時、代價高昂的過程。
嚴格的層次結構經常不能反映真正的企業需求。例如，在聯營
企業或擁有一些小公司的大公司中， 一種更聯合的方法可能更為適 宜。
證書和密鑰的滾動非常複雜，因為由從屬CA頒發的證書的有 效期通常不會超過上級證書的有效期。
如果下級試圖與外部團體進行交叉驗證，則會發生無法預料的 信任。這在下面進行深入討論。經常有通過機構邊界進行安全通信的需求，其通常也涉及穿過安全 管理邊界(包括PKI邊界)。有幾項技術用於擴展公鑰的信任，但目 前所使用的技術中最流行的是交叉認證。對等交叉認證(以下簡稱為交叉認證)是由許多PKI技術的銷售商 支持的方法。交叉認證允許兩個單獨的PKI系統彼此間建立信任關係。 這種信任關係可以在所施加的某些約束或條件下被建立，因此每一個 PKI不需要無條件地信任該合作PKI系統，但可以在控制的條件下信任 它。兩個機構可以在根層次上交叉驗證其各自的PKI。如果每個機構意 欲信任其它機構的整個PKI，則這種方法是理想的。可是，其可能是， 一個機構可更願意只在從屬層次上將信任擴展到其它機構，例如僅在 所選擇的部門之間建立信任。以這種方式限定信任的需要可以由於多 種原因而產生例如，某些部門可以在商業敏感領域中工作，其希望 對外部團體拒絕信任；而採購部門可以有更開放的政策，其需要與相 當多的外部供應商建立信任關係。從標題為 "Plannibg and implementing Cross—certification and Qualified Subordination Using Windows Server 2003 (使用 Windows Server 2003規劃和實現交叉認證和合格下屬)"的微軟公 司的文檔中知悉，利用已知的交叉認證方法以限制外部(被交叉驗證 的)合作機構內的信任範圍。然而，由頒發交叉證書給外部(被交叉 驗證的)機構所建立的任何信任關係， 一律被交叉認證機構內的所有 信賴方繼承。該方法的一個問題是，即使在允許從屬CA進行交叉驗證的應用環 境中應用該方法時，由此引起的信任關係是不對稱的外部實體可以 在機構範圍內鑑定自身，但只有在交叉驗證CA之中或之下的交叉驗證 機構內的實體能夠對外部機構鑑定自身。這種不對稱性可以導致某些通信協議不能正確運行。因此，通常不推薦在從屬CA之間創建信任關 系，而總是優選在根層次上創建信任關係以保證這種協議正確運行。因此希望提供改善的PKI系統、裝置、方法等，其減輕與已知系統 關聯的一個或多個問題。發明內容本發明提供約束PKI或相似系統對證書的頒發與/或使用的方法、 裝置、系統與電腦程式(任選地存儲在機器可讀介質上)，包括基 於ITU推薦標準X. 509及相關標準的那些。特別是，根據本發明的第一方面，提供一種包括一個認證機構層次 結構的公共密鑰基礎結構，其中安排第一認證機構頒發交叉證書，其 中安排層次高於第 一認證機構的第二認證機構，使得僅頒發那些無論 單獨或聯合均不可以被成功使用以證實交叉證書的證書。當第二認證機構確實可以頒發信任錨(trust anchor)和其它證 書時，其必須保證，無論單獨地或聯合地，它們中沒有一個允許成功 驗證由第 一認證機構頒發的交叉證書。在某些實施例中，這些證書包括一個信任錨。在某些實施例中，安排層次上高於第一認證機構的每一個認證機 構，使得僅頒發那些無論單獨或聯合均不可以被成功使用以證實交叉 證書的證書。在某些實施例中，笫二認證機構向其下級認證機構頒發包括一個阻 止4吏用證書以成功地證實交叉證書的約束的證書。在某些實施例中，該約束包括路徑長度約束、命名空間約束、策略 映射約束和應用約束中的一種。在某些實施例中，該約束包括一個策略映射約束。在某些實施例中，該約束禁止策略映射。在某些實施例中，該信任錨包括一個inhibitPolicyMapping (禁 止策略映射)欄位，其中該約束包括把inhibitPolicyMapping欄位 設置為一個預先確定的值。在某些優選的實施例中，inhibitPolicyMapping欄位的預先確定 的值等於零。基本上可以按照ITU推薦標準X. 509對公共密鑰基礎結構進行操作。
在本上下文中已經有若干基本X. 509推薦標準的派生標準，其不 可避免地會隨時間演化。因此，本領域的技術人員容易地理解，本發 明同樣應用對於X. 509推薦標準自身的文字措辭的，那些派生標準， 因而該應用基礎結構不是字面上地而是實質上依照X. 509。根據本發明的另外一個方面，提供一種為包括認證機構層次結構的 公共密鑰基礎結構的認證機構，在該基礎結構中安排笫 一認證機構使 頒發一份交叉證書，配置認證機構使層次高於第一認證機構，並且安 排重些認證機構使得僅頒發那些無論單獨或聯合均不可以被成功使用 以證實交叉證書的證書。本發明也提供該基礎結構運行的方法以及包括與設備的每一個相 關組件對應的方法步驟。特別是，根據本發明的另外一個方面，提供一種運行公共密鑰基礎 結構的方法，包括步驟提供包括認證機構層次結構的公共密鑰基礎 結構，該認證機構層次結構包括笫一認證機構和層次高於笫一認證機 構的第二認證機構；配置笫一認證機構使頒發交叉證書；配置第二認 證機構使頒發那些無論單獨或聯合均不允許成功地證實由第 一認證機 構頒發的交叉證書。本發明也提供為計算機執行本發明的方法的程序(無論作為軟體、 固件、晶片布置軟體，或原始碼或目標代碼，任選地存儲在機器可讀 的載體或介質上)；本發明也提供依靠上述程序的已編程的計算機， 根據本發明的其它方面這些程序也形成裝置。特別是，根據本發明的另外一個方面，提供具有組件代碼部分的計 算機程序，配置該程序使在包括認證機構層次結構的公共密鑰基礎結 構中擔任一個認證機構，在該基礎結構中安排第一認證機構使頒發交 叉證書，配置認證機構使層次高於第一認證機構，並且安排使得僅頒 發那些無論單獨或聯合均不可以被成功使用以證實交叉證書的證書。根據本發明的另 一個方面，提供包括一個認證機構的公共密鑰基礎 結構，配置該認證機構使頒發包括一個約束的從屬證書或信任錨，在 正常操作中該約束分別防止該從屬證書或信任錨被使用於證實由從屬 i人證機構頒發的交叉證書。根據本發明的另一個方面，提供包括證書證實功能的公共密鑰基礎 結構，安排該證書證實功能使響應包含一種約束的從屬證書或信任錨 中的約束證實交叉證書，該約束在正常運行中分別防止該從屬證書或 信任錨被使用於證實由從屬認證機構頒發的交叉證書。優選的特徵可以被適當地組合，這一點對本領域的技術人員是顯而 易見的，並且可以與本發明的任意方面組合。除上述說明的事例外， 本發明的其它優點對本領域的技術人員也會是顯而易見的。


為顯示本發明如何被實現，下面僅舉例和參考附圖對本發明的實施例進行描述，附圖中圖l表示依照本發明的第一系統； 圖2表示依照本發明的第一PKI系統； 圖3表示依照本發明的第二PKI系統。
具體實施方式
現參考圖1，控制交叉認證範圍的一種可能的方法是在從屬的、部 門的層次上運行交叉認證。它例證性說明在兩個從屬層次的CA之間的 信任關係財務A和財務B。顯然，此處的目的是把信任關係限定於兩 個機構的財務部門。在尋找滿足該要求中，當在根CA層次上進行交叉 驗證時所使用的以前已知的方法是要使用眾所周知的證書約束的技 術。可是，當在從屬CA層次上進行交叉驗證時，該方法令人遺憾地不 能滿足需要，下面會進行闡述。X. 509標準允"MH吏用證書約束(例如，如"APC ^/J^-//7fei77efM屍C W"-J^闢丄5"^並齊鉤差4潛^證並々^2;無要義#>> " (Http: 〃www. faqs. org/rfcs/rfc259. html)中所定義).這樣的約 束可以包括命名空間、策略映射、路徑長度、或應用策略約束。這樣 的約束被放置在交叉證書內，並且具有限制信任擴展到合作機構內的 程度的作用。以例證性說明的方式以及再次參考圖1，約束可以被CA 財務A以如下方式^f吏用 可以使用路徑長度約束以防止信任擴展到財務B與之已經交 叉驗證的任何其它CA。例如，在由財務A頒發的交叉證書中將路徑 長度設置為零，將保證信任不會擴展到財務B之外的任何其它CA。
在由財務A向財務B頒發的交叉證書中，可以使用命名空間 約束以防止信任擴展到所允許的命名空間之外的證書在本例中，
交叉證書可能僅允許格式為"xxx.Organisation-B.com"的命名 空間，該格式會把證書的使用限制在機構B內的任何實體"xxx" 之中(在本例中"xxx"可能是與機構B關聯的命名空間)。 可以使用由財務A頒發的交叉證書中的策略映射約束以防止 信任擴展到沒有使用所允許的策略類型之一的CA 。 可以使用由財務A頒發的交叉證書中的應用策略約束以將安 全通信限制於所定義的應用集。RFC 2459包括證書約束的不同類型、證書的語法以及可以如何使 用證書的詳細描述。理解約束的重要一點是，雖然約束確實應用於被交叉驗證的機構 (本例中為機構B)中的訂戶10，但它們不選擇性地應用於交叉驗證 機構(機構A)中的信賴方11-13。而是，包含在證書中的任何約束全 局性地應用於所有開始與特別的信任錨建立信任關係的信賴方。因此 在本例中，在機構A內的所有團體，無論其在財務部門內部還是外部， 都將以相同方式處理交叉證書。每一個訂戶或信賴方保留或訪問一組證書20-23。雖然顯示每一個用戶似乎在本地保留證書，但證書實際上可以被保留在每一個機構內 的一個可公共訪問的存儲庫中。然而本發明的發明者已經確定這種方案的一個不合乎要求的結果 是在被交叉驗證的機構內信任路徑意外出現，並且已經經驗性地確認 這些出乎意料的信任路徑的存在。仍參考圖1，機構B的財務部的訂戶IO發送一封籤名的電子郵件 給機構A的銷售部的用戶12。即使在兩個財務CA之間已經實現交叉認 證，然而從根A到發送用戶的證書的信任鏈仍然存在。接收用戶的信 任錨24由根A頒發，並且因為由財務CA創建的交叉證書25在機構A 的目錄內被自由地分發，所以接收者的電子郵件應用程式將以完全相 同的方式處理籤名的電子郵件，遵守由財務A建立的由交叉認證施加 的相同約束。這種無意的且因此出乎意料的信任路徑的存在將被稱作"意外信 任"。意外信任具有對機構產生重要的並且在某些情況下嚴重的影響 的可能。這意味著在機構B內的用戶例如能夠發送籤名的電子郵件 26-28到機構A內的任何地點並且使之被接收。它們還可以與web服
務器或文件伺服器安全地連接，或遠程登錄系統，等等。採取減輕這一問題的影響的措施是有可能的。這些措施可能包括在 機構的邊界設置防火牆使僅允許特定應用程式，或者限制應用程式以 檢查證書路徑的其它方面，例如命名約束或距信任錨的最大路徑長 度。可是，這些措施只能部分解決該問題，並且導致另外的複雜性。 如果機構的註冊程序有缺陷，則有很大的可能性是，懷有不良企圖的 人能夠偽裝成合作機構內的另 一名用戶，繞開由應用程式所使用的任 何命名約束。在上面所描述的簡單模式中，已經確定從屬CA層次上交叉驗證的 系統內的意外信任的存在，本發明的發明者繼續開發使用以特別方式 配置的CA層次結構的加強的PKI方案。總之根CA支持機構內部的信 任並且從屬CA也在可以被稱作多根層次結構的結構內擔當為本地用戶 的信任點。從屬CA也可以與合作者交叉驗證以支持本地事務要求。可 是，來自根CA的約束防止該信任被傳播到該機構的其它不希望的部 分，從而避免意外信任的問題。現參考圖2，為機構A的已修正的認證機構結構包括自驗證CA(如 前面的根A)和從屬CA (工程A、銷售A和財務A，從機構而言分別對 應於工程部、銷售部和財務部)。可是在本事例中，財務A的CA也同 樣自驗證29，形成為從屬CA的用戶的信任錨。機構B的組織結構與前 面所述相同，因為該確切的結構不重要。在本例中，除根A向依賴於其自身或其從屬CA的信任的用戶ll-13頒發信任錨以外，財務A也向它自己的信任的用戶13頒發信任錨， 雖然其並未向依賴於其它對等的CA (例如銷售A)的從屬用戶11-12 頒發信任錨。可是，除財務A有能力頒發其自身的信任錨之外，上級根A CA施 加約束31給當在這一點上開始時能夠被證實的證書。特別是，這些證 書被限制來防止使用於證實由從屬CA財務A頒發的交叉證書。這可以 通過一些方式得以實現，但是最容易和最有效的方式是可以通過把頒 發給從屬CA的證書的inhibitPolicyMapping欄位設置為零來實現。 這意味著，雖然由根A頒發的證書30可以被使用於證實機構A內頒發 的證書，但是它們不能被使用於證實由從屬CA頒發給其他機構的交叉 證書25。
在財務A頒發交叉證書25給財務B而財務B依次驗證財務B的財 務B的訂戶IO的事例中，該證書鏈可以被反過來呈現給財務A信任的 用戶13用於證實。在該例中，通過一種簡單的機制，例如提供和檢查 該證書內的策略映射欄位，該證書可被確認為交叉證書。雖然財務A 信任的用戶可以保留來自根A的信任錨，但在由根A頒發的證書中策 略映射被抑制為長度為零的路徑意味著根A的證書不能被成功地使用 於證實交叉證書。可是，財務A信任的用戶也保留來自財務A的、可 以被成功地使用於證實交叉證書的信任錨29，從而允許所要求的交互 繼續進行。相反，如果財務B的訂戶IO將包括交叉證書25的相同證書鏈呈現 給機構A的部分內的信任的、不保留來自財務A的信任錨的用戶ll-lZ, 則證實將失敗。例如，如果財務B的訂戶要將它的證書呈現給銷 售A信任的用戶12，則任何使用來自根A的信任錨24以證實證書的嘗 試都會失敗，因為不可以使用該信任錨來證實距頒發的根A CA零步以上頒發的交叉證書。這通過使用前述的約束得以實現。此外，因為銷 售A信任的用戶12不依賴於財務A，所以其不保留來自財務A的信任 錨，該信任錨將會是證實由財務A頒發的交叉證書的唯一其它方法。 因此，銷售A信任的用戶不能證實由財務B的訂戶呈現的交叉證書， 因此所要求的交互將被拒絕。如果該交叉證書被呈現給工程A信任的 用戶則相似情形產生，因此如上所述的意外信任從而被防止。本發明的發明者於是已經意識到，多根的層次結構與對證書頒發的 約束一起提供控制企業外部的信任的改進方法。約束被施加於由根頒發給從屬CA的證書。這些防止信任在信任可 以從根開始的機構外擴展。約束可以包括前述所列約束中的任意一個 ——命名空間、策略映射、路徑長度和應用策略。 一個事例是對於根 將具有一個"inhibitPolicyMapping"約束的證書頒發給從屬CA。這 防止信賴方使用其內具有策略映射欄位的證書來從根建立信任路徑。在從屬CA可以希望頒發交叉證書，以及該證書包含一個策略映射 的地方，該映射將超越(override)來自根的約束，而只應用於除從 根之外開始路徑建立的信賴方。在多根層次結構的當前事例中，這是 從屬CA的本地訂戶13。在本方案中的用戶保留信任兩個信任錨 部門/本地CA (即自籤名的從屬CA)，其可以實施它自己的 策略，以及其僅應用於那些保留本地CA證書作為信任錨的用戶。 根CA，通過根CA本地用戶將能夠信任它們自己機構的其它 部分。根CA將實施一種全局策略，該策略的作用是要禁止建立到 被交叉驗證的CA的信任。其結果是，通過從根CA頒發給從屬CA的證書用戶信任它們自己機 構的其它部分。根據證書被約束的事實，來自本地CA的信任不傳播到 該機構的其餘部分。採取這項技術，仍參考圖2，在表1中概括了作為結果的信任關係。 表l:信任關係來自該部門的用 戶…—財務A的用戶機構B的用戶銷售A的用戶和工 程A的用戶...信任/不信任 來自該部門的用 戶1財務A的用戶《一經由根 A和財務A的 信任錨《一經由交 叉證書《--經由根A的 信任錨機構B的用戶V --經由交 叉證書《一經由根 A信任錨x --沒有信任路 徑存在(來自根A 的約束超越交叉證 書)銷售A的用戶和 工程A的用戶V —經由根 A的信任錨x —沒有信 任路徑存在V—經由根A和銷 售A或工程A的信 任錨通過檢查本表可見，期望獲得的信任的需求已經完全被滿足 財務A的用戶，在左手側那列中，信任每一個人。
外部(機構B)用戶，在中間那列中，只信任財務用戶以及他們自己機構的用戶。他們不信任銷售A或工程A的用戶，因為在團體間不存在有效的證書路徑。 銷售A或工程A的用戶，在右手側那列中，信任財務A以及
他們自己本地的用戶。他們不信任外部CA的用戶，因為從信任的 應用程式的觀點而言來自根的策略約束使得該路徑成為一個非法 路徑。可用於該目的的一個簡單、有效的約束是設置 "inhibitPolicyMapping，，(如RFC 2459中所述)屬性為零，如此 則不允許策略映射從而禁止交叉認證。這允許機構的PKI具有如所要 求的深度。雖然命名約束可以作為另一種可選方案被使用，但它們的 使用依賴於外部合作機構內的註冊的正確實施和運行，而策略映射約 束的使用把對信任傳播的全部控制保留在頒發交叉證書的機構手中。 策略映射約束的使用也好於路徑長度約束，否則路徑長度約束會限制 本地機構CA的深度。通過該方法，可能看起來似乎在以下兩個方面存在明顯的矛盾，一 方面根(或其它上級)CA禁止對其從屬的策略映射，另一方面從屬CA 實際上頒發包含策略映射的證書。在這些策略基礎上而言所提出的方 案可能因此被反對。可是進一步觀察看出不是該層次結構的根CA定義 該機構的策略，而是根據機構的策略其僅負責實施策略中的某些部 分。因此，機構的PKI策略可以選擇指定一個根(或其它層次上級) CA作為僅負責實施其安全通信的某些方面，例如僅負責內部通信。從 屬CA於是由該策略允許，負責機構的安全通信的需求的其它方面，例 如交叉認證，假定該從屬CA實施與交叉證書的頒發關聯所要求的、必 需的約束。根CA和從屬CA二者因此依照機構的PKI策略運行。雖然在基於X. 509推薦標準的已知PKI中約束可以在從上級CA頒 發到下級CA的證書中被執行，但也已經被確認的是約束也可以被嵌入 到由自驗證的CA頒發的信任錨之中。在該實施例中僅需要由該CA把 約束包括在其信任錨中，而在其它實施例中約束必須被包括在由上級 CA頒發到其每一個下級的每一份證書之中。通過對信任錨的數據結構 作簡單修改以及對讀取和解釋這些數據結構的系統作相應修改(通常 經由電腦程式實施)，將約束包括在信任錨中的單點實施可以被實 現。雖然按照兩個層次的CA層次結構在上面對該方案進行描述，但該 方案可以輕易地推廣為多於兩個層次的層次結構，這一點對本領域的 技術人員是顯而易見的。特別是，現參考圖3，多個層次的層次結構可
包括三個或更多層次的CA。在該例中，總體方案與圖2中的方案相似， 除在根A的CA和工程A、銷售A以及財務A的CA之間插入另外一個層 次。具體而言，工程CA被作為R&A的CA的下級，使銷售A和財務A 的CA二者作為總部A的CA的下級。在任何或所有層次內的CA可以被 安排35-36使頒發信任錨，雖然不是認證機構R&A A，但在所示的事 例中認證機構總部A和工程A被顯示能夠執行該職能。如前所述，自驗證CA可以頒發交叉證書。然而，在由比那些頒發 給定交叉證書的CA層次更高的CA頒發的信任錨之內所施加的約束的 性質，比前述事例中更為複雜。總的來說，那時必需保證由比給定交 叉證書的頒發機構層次更高的CA所頒發的信任錨不能成功地使用於證 實所頒發的交叉證書。為實現上述目的， 一種簡單的方法是通過使用 該證書的路徑長度約束或禁止策略映射約束的"跳躍證書"子欄位， 來限制距離所頒發信任錨的證實路徑的長度。因此在所示的事例中， 如果希望防止關於由最低層次的CA (例如工程A、銷售A以及財務A) 頒發的交叉證書25的意外信任的產生，則根A的CA把 inhibitPolicyMapping設置為一個不大於1的值，同時總部A的CA 把inhibitPolicyMapping i殳置為一個不大於零的值。以這種方式， 來自根A的信任錨24和來自總部A的25 二者都不能被成功使用於證 實由工程A、銷售A或財務A頒發的交叉證書25。(注意在現有基於 X. 509的系統中，交叉證書必須在其內總是具有一個策略映射欄位為該 具體實施例正常運行)然而注意如果在根A已經把inhibitPolicyMapping設置為1 (而 不是零)的情況下，總部A要頒發交叉證書36，則意外信任仍可能作 為通過使用根A的信任錨證實由總部A頒發的交叉證書36的結果發 生。因此，如果也要防止上述問題，則根A的信任錨也必須限定其路 徑長度為零(或總的來說限定為某一長度，該長度防止信任錨被使用 於證實由任何從屬CA頒發的任何交叉證書)。如前所述，這可以通過 把inhibitPolicyMapping再次設置為零得以實現。相反，如果由才艮A施加的約束是要把inhibitPolicyMapping設置 為零，但是沒有對應的約束被施加於由總部A頒發的信任錨，則由從 屬於總部A的任何CA頒發的交叉證書將有效地把信任錨擴展到所有總 部A的信任的用戶12-13。因此以該方式選擇性地限制信任錨的能力允
許創建複雜的信任結構。雖然僅就兩個交互的機構中的一個進行了展示，但是顯然，所提議 的配置可以被應用於許多交互的機構中的每一個，以便使它們中的每 一個在它們各自的機構內將意外信任限制到所選擇的程度。仍參考圖3，本地CA (例如財務A)為該CA的訂戶13形成另外一 個信任錨。因此每一個用戶具有幾個信任錨，該用戶從它們可以驗證 證書鏈在上述事例中，用戶具有來自根的一個信任錨、來自本地CA 的另一個信任錨以及一些用戶12-13具有來自總部A的另外一個信任 錨。來自從屬CA的另外的信任錨允許本地通信得以繼續進行，即使該 企業的根因為任何原因停止服務。多根層次結構(其為一個從屬CA在其內可以頒發信任錨的層次機 構)克服上面所列的嚴格層次結構的許多問題。它去除根C A成為企業 失敗的單點的問題。它也使證書和密鑰的有效期管理得以簡化，因為 本地CA的密鑰和證書可以從根的密鑰和證書中被分離。因此，總的來說，對許多情況而言多根方法要優於嚴格的層次結構。總而言之，仍參考圖3，提供一種限制信任在證書頒發機構內傳播 的方法。通過在層次上第一高的CA (根CA)和第二交叉證書頒發CA(財務A )之間，設置一個笫三CA (總部A )——該CA具有它自己的、 能夠證實由第二交叉證書頒發CA所頒發的交叉證書25的信任錨35， 信任的範圍被限制。通過把合適的約束包括在由第一層次上高級CA(根 CA)所頒發的證書之中，由第二CA (財務A)所頒發的交叉證書25隻 可以在第三CA (總部A)或層次低於第三CA的CA中被證實。這把證 書頒發機構(機構A)內的信任關係的範圍作為整體限定在那些第三 CA (總部A)或層次低於第三CA的機構單元中。從前面的描述中顯而 易見的是，在某些情況下第三CA和第二CA可以是同一個CA (例如財 務A),由此在該頒發機構中的信任被限定僅在交叉證書頒發機構單元(財務A)之內進行傳播。因此，儘管在已知的系統中通過施加於頒發給外部機構的交叉證 書的約束，外部機構(機構B)內的信任的範圍可以被限定於該機構結 構的一個子集，然而本發明允許頒發機構(機構A)內的信任範圍被相 應地加以限制。這允許在進行交叉驗證的機構和被交叉驗證的機構的 子集之間建立信任並將信任限定於其中。
在不失去目標效果的情況下，可以對此處給定的任何範圍或設備 值進行擴展或更改，這對於本領域的技術人員理解此處的技術內容而 言是顯而易見的。
權利要求
1.一種包括認證機構層次結構的公共密鑰基礎結構，其中安排第一認證機構頒發交叉證書，其中安排層次高於第一認證機構的第二認證機構，使得僅頒發那些無論單獨或聯合均不可以被成功使用以證實交叉證書的證書。
2. 根據前面任意一條權利要求的公共密鑰基礎結構，其中該證書 包括一個信任錨。
3. 根據前面任意一條權利要求的公共密鑰基礎結構，其中安排層 次高於第一認證機構的每一個認證機構，使得僅頒發那些無論單獨或 聯合均不可以被成功使用以證實交叉證書的證書。
4. 根據前面任意一條權利要求的公共密鑰基礎結構，其中第二認 證機構向其下級認證機構頒發證書，所述證書包括一個排除該證書被 使用於成功地證實交叉證書的約束。
5. 根據前面任意一條權利要求的公共密鑰基礎結構，其中該約束 包括路徑長度約束、命名空間約束、策略映射約束和應用約束中的一 種。
6. 根據前面任意一條權利要求的公共密鑰基礎結構，其中該約束 包括一個策略映射約束。
7. 根據前面任意一條權利要求的公共密鑰基礎結構，其中該約束 禁止策略映射。
8. 根據前面任意一條權利要求的公共密鑰基礎結構，其中信任錨 包括一個禁止策略映射欄位，其中約束包括設置禁止策略映射欄位為 一個預先確定的值。
9. 根據權利要求8的公共密鑰基礎結構，其中該預先確定的值等 於零。
10. 根據前面任意一條權利要求的公共密鑰基礎結構，其基本上 按照ITU推薦標準X. 509運行。
11. 一種用於包括認證機構層次結構的公共密鑰基礎結構的認證 機構，其中安排第一認證機構頒發一份交叉證書，配置認證機構使層 次高於第一認證機構，並且安排使僅頒發那些無論單獨或聯合均不可 以尋皮成功4吏用以證實交叉證書的證書。
12. —種運行公共密鑰基礎結構的方法，包括以下步驟 提供一個包括認證機構層次結構的公共密鑰基礎結構，該層次結構包括第 一認證機構和層次高於笫 一認證機構的第二認證機構； 配置笫一認證機構使頒發交叉證書；配置第二認證機構使頒發那些無論單獨或聯合均不允許成功地證 實由第 一認證機構頒發的交叉證書的證書。
13. —種具有組件代碼部分的電腦程式，配置該程序使在包括認 證機構層次結構的公共密鑰基礎結構中擔任一個認證機構，其中安排 第一認證機構頒發一份交叉證書，配置認證機構使層次高於第一認證 機構，並且安排使僅頒發那些無論單獨或聯合均不可以被成功使用於 證實交叉證書的證書。
14. 一種包括一個認證機構的公共密鑰基礎結構，配置該認證機構 使頒發包括一個約束的信任錨，在正常操作中該約束防止該信任錨被 使用於證實由從屬認證機構頒發的交叉證書。
15. —種包括證書證實功能的公共密鑰基礎結構，安排該證書證實 功能使響應包含一種約束的信任錨中的約束證實交叉證書，該約束在 正常操作中防止該信任錨被使用於證實由從屬認證機構頒發的交叉證書。
16. —種公共密鑰基礎結構，包括根認證機構和從屬於根認證機構 的第二認證機構，其中第二認證機構可以頒發信任錨。
17. 根據權利要求16的公共密鑰基礎結構，其中第二認證機構也 可以頒發交叉證書。
18. 公共密鑰基礎結構方法、裝置、系統以及可選地在機器可讀介 質上的電腦程式，基本上在前面的描述中以及參考附圖被公開。
全文摘要
本發明為公共密鑰基礎結構(PKI)中的交叉認證提供方法、裝置、系統和軟體。提供一種具有認證機構層次結構的公共密鑰基礎結構。安排第一CA頒發一份交叉證書。安排層次高於第一認證機構的第二認證機構，使得不頒發任何可被成功使用於證實交叉證書的信任錨。在驗證機構內的信任不擴展到整個驗證機構，而僅被限定於該驗證機構的預先確定的部分。
文檔編號H04L9/32GK101129016SQ200580048655
公開日2008年2月20日 申請日期2005年12月23日 優先權日2004年12月24日
發明者T·B·迪恩 申請人:秦內蒂克有限公司