DIV CSS 佈局教程網

 DIV+CSS佈局教程網 >> 網頁腳本 >> XML學習教程 >> XML詳解 >> 對 Donald Eastlake 關於 XML 數字簽名的采訪
對 Donald Eastlake 關於 XML 數字簽名的采訪
編輯:XML詳解     

在本次獨家 developerWorks 采訪中,XML 數字簽名(XML Digital Signature)先行者 Donald Eastlake 通過闡明許多有關如何使用該技術的問題來回答有關這一主題的 Larry Loeb 近期文章。

  作者的注釋:在關於 XML 數字簽名的近期文章中,我對它們的實用性和有效性產生了疑問。因為這個提案剛被推薦通過常規使用,所以我確定這是再次核對這個主題的時候了。這次,我與 Donald Eastlake 進行了交談,他是 XML 數字簽名(XMLDSIG)RFC 的編輯,也是應該知道有關該主題的人,因為自 90 年代以來他就一直參與了 XML 規范的工作。他還為 IETF 做了多得無法列出的工作。除了在文法上稍做改動之外,基本上未對他的回答做過編輯。向他提出的問題用粗體顯示。

  依照 RFC,在 XML 中使用數字簽名的目的是為‘或許在或許不在 XML 中’的數據提供認證服務。您對此陳述有何預想?

  在 XML 數字簽名工作組中有許多代表著不同觀點的對象群體。一些是“表單(Forms)”人,他們的目的是獲得把簽名插入到文檔的能力,即無需更改根元素就由該簽名簽署了所有或部分文檔(除了簽名本身)。其他一些是面向協議的人,例如他們想要使用 XML 簽名以相對簡短而不是極其冗長的用 XML 編碼的協議消息的形式來簽署特定元素。還有一些人想要構造分離的 XML 簽名,這些簽名認證了並可能還斷言了某些或許根本不是 XML 格式,但很可能是例如二進制可執行文件的遠程數據的一些特性。

  為了使這些對象群體都滿意,XMLDSIG 構成得非常靈活。因為這些對象群體中的一些人把他們的觀點視為唯一觀點而忽略了其他人的觀點,諸如您在以上引用的 RFC 上的短語那樣的贅述也會包含在需求和規范中,以明確說明將涉及到所有基本方面。

RFC 還指出此規范對於解決所有應用程序的“安全-信任”問題還不夠充分,因此需要額外要求。對於真正安全的 XML 的額外需要,您有何預想?

  什麼是“真正安全的 XML”?在未定義您試圖獲得什麼樣的安全特性以及威脅模型類型的情況下,這個短語毫無意義。XMLDISG 提供了一個構件。它是用於將數據密碼綁定到密鑰的一種靈活機制。

  滿足一些特殊應用程序的安全性要求可能意味著指定要使用的特別算法、允許的密鑰信息的類型、綁定到簽名的語義標記、密鑰生成和分發的安全性、包括 TEMPEST 考慮的執行環境的安全性、涉及到的人員的背景檢查級別、包括如何響應對安全性的損害的管理程序、解決爭論的合法地點的選擇,等等、等等、等等。

  為了認證一本匿名政治小冊子(例如,什麼也沒),您需要做的不同於為了認證本地網絡內會議室預訂而做的(它不是為了全球因特網上多方國際基金劃撥系統上操作幾百萬美元交易的認證)。您出版發行所需的機密性(例如,無)不是普通用戶點擊蹤跡所需的機密性,不是獲取有關至今還未宣布的大公司合並信息所需的機密性,並且也不是當您正在為緊急戰爭訂單而分發認證材料時想要的安全性(擁有了該安全性,在理論上您就能發射核導彈)。在不知道您想要的安全性策略以及您想要防御的威脅等情況下,您也就沒有可以使用的魔術公式或仙塵(pixIE dust)使某些信息“安全”。前面主要評論了數字簽名或認證代碼的常規特性,並且事實上這與它們是否是 XML、S/MIME 還是其它什麼形式無關。

  對於為 XML 消息傳送而添加(或除去)數字簽名,您是如何看的?

  XMLDSIG 用密碼使數據與密鑰關聯,而且可以提供認證和/或完整性。由於您明確請求消息傳送,因此通過 X 方添加的 XML 數字簽名後從 X 方發送到 Y 方的 XML 消息就能被 Y 方認證為來自 X 方並且是完好無損的。這裡假設 X 方使用的密鑰只為 X 方和其它信任方(如果有的話)所擁有;這只應用於該簽名所涉及的消息的數據元素;並且這裡假設 Y 方信任表示 X 方簽署所用的密鑰,並且信任和已經實現了所用的密碼算法。

 為了采用較少面向消息的觀點而更多面向文檔的觀點,X 可以是 XML 對象/文檔的發送方。然後,由 X 添加的簽名可以認證並確保那個被發送到無數接收方的文檔完整性而不管被簽署對象可能已被嵌入到其它 XML 和/或轉發的多個跳躍點之類的對象。

  數據傳送的目標是要確保消息完整性(也就是,“完好無損”)。現在,XMLDSIG 能確保以某些供應商告知用戶的方式做到“不可抵賴性”(暫時忽略那術語的合法定義)嗎?

  是的。為了做到這一點,您必須選擇象 RSA 那樣的非對稱簽名算法,使發送方用其私鑰簽署,使那些想要驗證簽名的人能夠知道並信任相應的公鑰(可能將它放入以接收方信任的認證中心簽署的簽名的 KeyInfo 部分發送的證書中)。如果那些都是事實,那麼您就擁有了由它們簽名的簽發者通常所指的不可抵賴性。

  對於大多數目的,您還必須添加一個指出簽名“含義”的語義標記(例如,契約協議、證明、對其它簽名的反簽名、原作者等)。

  部分問題可能在於:為了避免煩瑣的措詞,XMLDSIG 使用術語“簽名”不僅為了包含上面描述的人們通常理解的“簽名”的含義,而且還為了包含對稱密鑰認證代碼或基於生物識別技術的認證或其它任何事物。盡管如此,使用對稱密鑰認證代碼,任何能驗證認證代碼的人都能偽造一個代碼,所以它可能被拒絕,但您可能想要使用這個代碼,因為它更加有效。

  如果您只嘗試根據機器 A 到機器 B 在因特網上通信完整性來獲取信任,並且您控制著這兩台機器,那麼在向另一方發送消息然後在接收方檢查並獲取一個認證代碼之前,使每台機器添加一個這樣的代碼的做法也是合理的。[也就是說,在數據流中使用 Mac 有時會是認證的一個更常用的方法 ― ed.]。這就以相當低的計算的開銷代價給您帶來防止篡改的管道安全(但不適用於竊聽,除非您還添加了加密)。

確實如此。XMLDSIG 允許 ― 真的,鼓勵 ― 多種認證方法。我假設當您前面提到“為了使這些 [ 不同 ― ed. ] 對象群體都滿意,XMLDSIG 構成得非常靈活”時,這個特性是那個靈活性的一部分。並且可以由 URI 元素指向特定方法,是嗎?

  是的。一些靈活性來自指定加密算法的能力並且工作組選擇了使用 URI 作為算法的名稱。但是通過使一些元素和屬性變為可選,通過接受各種密鑰信息等,在您能使用 URI 的其它地方也可以提供靈活性。XMLDSIG 是具有各種用途的工具箱。

  但是重要的是請注意:在大多數真實世界的系統中,特別驗證程序可能對於它們將接受這麼多選項中的什麼選項有非常嚴格的策略。如果某人正在您本地公司的那個密鑰的認證中心上尋找帶有至少 1024 位長的公鑰模數的 RSA 公鑰簽名和一個當前有效的證書,那麼您可能不會考慮指定另一種算法或密鑰信息類型的 XMLDSIG 來認證為您的目的所簽署的東西,即使它對於某些其它驗證程序是可能接受的。

  您認為真實世界中的 XML 數字簽名有什麼用途?您認為它們最大的用途在那裡?

  我相信將會有非常廣泛的用途,但特別突出的兩個領域可能是:文檔和消息。雖然有時候這兩個領域會相互混合,但是文檔趨向於保存得更長,並且其上的簽名趨向於表示對所有或部分文檔的人類批准,雖然它們可能還有自動附加的簽名時間戳記。消息趨向於是瞬時的,並且通常會自動添加和除去認證。當然,就我在這裡使用的單詞而言,在其內容中,消息可以包含一個或更多文檔。

  文檔很可能使用公鑰技術,而根據應用程序的不同,消息可以使用公鑰或對稱秘鑰技術。文檔很可能是象抵押契據或法院文件那樣“重要”的東西。但是如果 XML 數字簽名廣泛用於消息,那麼消息就可達幾個數量級那樣之多。

  對於將在真實世界應用程序中非常有用的 XML 數字簽名所需要的最小安全性上部構造,您是如何看的?

  它事實上取決於應用程序。簽發者和驗證程序總是需要密鑰資料,所以最小的所謂“上部構造”是簽發者和驗證員用密鑰資料進行手工配置。雖然我確信這在某些例子中將會這樣做,但對於大多數的應用程序而言,您可以使用證書系統或密鑰分發中心作為密鑰中的信任源。


 

XML學習教程| jQuery入門知識| AJAX入門| Dreamweaver教程| Fireworks入門知識| SEO技巧| SEO優化集錦|
Copyright © DIV+CSS佈局教程網 All Rights Reserved