嘉哲的翻譯／寫作作品集

        很明顯地，因為它的重要性，這個觀念增加了某些助益。認証通路的建立是從你的認証至通訊連結另一端的個人(或系統)建立一連串信任的過程。沒有了通路的建立，我們不可能見到我們的認証環境從難以維護的網路瀏覽器的Trusted List進步至功能化的PKI。當某些數位認証的原始開發者被要求建立文件說明時，他們的反應不是”這是個簡單的圖形化理論─為什麼需要文件說明呢？” 就是”我們的工具程式可以解決這個問題”。簡單的圖形化理論？我上次什麼時候做過這些事？並且我所知道文件建立是幾十個工具程式中的兩個才可能讓廠商完成它，它並不會為任何人釐清程序。

何謂認証通路？又為何我們需要它？

        你的(和你的企業伙伴的)數位認証是由你和其他人所信賴的機構的私人金鑰所簽署完成的。符合公共金鑰的認証稱為簽章或根認証。更重要的是，它稱為你的Trust Anchor。如果雙方的Trust Anchor都相同，雙方的認証有效程度即正常。但如果Trust Anchor不同的話，雙方必須從他們的Trust Anchor建立信任鏈至對方的Trust Anchor，才能使雙方認証有效。

        PKI的建立者可以從兩種方法中選擇一種作為通路建立的基礎，兩種方法均基於個別Trust Anchor的關係所產生。一個方法是使用階層組織：一個最終的Trust Anchor和其他依附的Trust Anchor。另一個方法是以一群Trust Anchor相互認証產生。多重Trust Anchor減少安全性風險(和相關責任)，提供供應來源競爭(可減少成本)並且可以較適切地說明公司政策。雖然管理工作、安全性風險和政策在階層性方法和相互認証方法上各有不同，但兩者均需要圖形理論來建立通路。

通路建立的替代方案

       因為通路建構是複雜的，它可在複雜的PKI中產生許多有趣的問題─所以你可能要考慮替代方案。你的兩個主要選擇方案是瀏覽器中的Trusted List模式，和線上認証確認服務。前者依賴所有系統─所有Trust Anchor的分配。不幸的是，這個模式產生了長期維護的問題，因為瀏覽器程式通常每六個月會推出具有新的Trusted List的新軟體。可了解地，這個解決方案的實際上對許多使用者是存疑的。你其他的主要替代方案，即線上認証確認服務，會藉由服務中的CA(Certificate Autorities)註冊來轉移通路建構問題，如此也減少了產生Trust Anchor的需求。然而，離線使用者和即時系統無法有效地使用這些服務。在其他替代方案的情況下，這解決方案並不適合每一個人，了解和實行路徑建構是明的作法。

如何著手

        連連看是小朋友和道路工程師所熟悉的遊戲。當小朋友連接各點形成一個圖案時，而道路工程師連接各點，代表各個城市，來管理交通。就像道路工程師一樣，PKI管理者使用單向的階層結構連結和雙向的交叉認証連結來建立PKI的結構圖中信任的有效率的路徑。

在使用者可以”閱讀”結構圖來找出所想要的路徑時，程式設計師必須從起始點建立所有的路徑，直到想要的路徑建構完成為止。由Trust Anchor開始，認証完成的應用程式需要發現所有相鄰Trust Anchor，然後這些相鄰設定至延伸清單直到所有伙伴的Trust Anchor找到為止。

在階層結構中，通路建構 就像在單行道上至較有權力的Trust Anchor，然後找尋所有從它放射出去的單向道。這個新發現的程序是由Certificate Reoisitory(Internet Draft draft-ieft-pkix-LDAPv2-schema-02.txt)擷取caCertificate物件。

一個應用程式藉由利用Suject 欄位符合Trust Anchor的Issuer欄位來擷取物件以產生由小至大的階層組織。為了產生由大至小的階層組織，應用程式利用Issuer欄位來核對Subject欄位來擷取物件。到最後，階層組織j以Trust Anchor成為開端而伙伴的Trust Anchor在最底部而造成整個組織翻轉。

在相互認証群體的通路建立則類似階層組織程序。在此物件是由cross CertificatePair所擷取。CaCertificate包含了單獨根或簽章認証，CrossCertificatePair 則包含了定義相互認証的兩個認証。CrossCertificatePair物件具有”前向”和”後向”認証元素。對一個已知的CA，前向元素是它己經相互認証的指標；後向元素是從相互認証CA至起始CA的指標。在Certificate Repository中，可能有兩個CrossCertificatePair，彼此相互監測。在此建立通路將接著擷取crossCertificatePair物件，它的前向元素必須符合Trust Anchor中的Subject 欄位。通路建立在前向元素中的Subjectvo 伙伴認証中的Issuer相符合時才完成。

這些例子中，通路建立程序均相同，但所擷取的物件卻不同。同時，在階層組織中，通路在當最末點的Trust Anchor擷取才完成，而在相互認証群體中，Trust Anchor從未被擷取並且不需放於暫存區中。最後的前向元素包含和對應Trust Anchor相同的公共金鑰。

通路建構之最佳化

        通路建構的最佳化有兩個方法─兩者都影響階層的PKI─較為人所知的方法是將指派最上層的根認証作為所有末端的Trust Anchor。雖然這會增加一次作業成本(在使用者建立認証時增加)，但它簡化了每一個認証通路的建構工作。因為系統並沒有直接的Trust Anchor，使用者必須從他或她所擁有的Trust Anchor在階層的最上層來建構通路。一旦這件工作完成之後，建立通路的工作就剩下簡單的向下擷取程序而已。

        這個最佳化的提倡者說明實行的好處。每一個設備可以用相同的Trust Anchor來啟動。因為Intermediate Certificate Authorities 設成額外的Trust Anchor，它們不需被分配，這對想要對系統負載標準化的公司而言產生很大的吸引力。它的缺點是對單一Trust Anchor的妥協會影響PKI的每一個使用者，而不只是對CA的立即幫助。

        第二種且更重要的最佳化方法是在Internet Draft中說明，即draft0ietf-pkix-LDAPv2-Schema-02.txt。CA簽署認証可儲存於crossCertificatePair的前向元素中而不是在cACertificate中。如果PKI的暫存區以此方式產生，則LDAP的向下需求會和通過相互認証群體的一樣。如果這個方法是由CA供應商所實行，應用程式廠商的開發和測試會簡化且較不容易產生錯誤。

PKI管理者的角色

        許多PKI倡導者並不認同建立PKI時階層式和相互認証群體何者較佳的建立模式的爭議。有趣的是，我們發現以適當的設定，它在作業上和通路建構的重點完全相同。身為現今新興的PKI管理者必須了解，他們可以開始要求認証啟始和相關產品必須謹遵通路建構方法，並讓使用者選擇適賞的模式，並且甚至可以將它混合在複雜的PKI模式中。

        回顧我在大學無憂無慮的日，當我真正了解圖形理論背後的數學計算時，我們了解可在圖形中的任一點開始進行，向外移動，並且最後將圖形反轉。這在當時是有趣的學術討論問題。而現在我們畫著圖並且它反轉成為企業的準則，忘掉了圖形理論幫助程序標準化和最佳化。這讓我們覺得欣慰，覺得大學的課並不是白上的。