Identifier）：簽發者唯一標識符在第2版加入證書定義中。此域用在當同一個X.500名字用于多個認證機構時，用一比特字符串來唯一標識簽發者的X.500名字。可選。 
                        <BR>證書持有者唯一標識符（Subject Unique 
                        Identifier）：持有證書者唯一標識符在第2版的標準中加入X.509證書定義。此域用在當同一個X.500名字用于多個證書持有者時，用一比特字符串來唯一標識證書持有者的X.500名字。可選。 
                        <BR>簽名值（Issuer's 
                        Signature）：證書簽發機構對證書上述內容的簽名值。<BR><BR>X.509 
                        V3證書是在v2的基礎上一標準形式或普通形式增加了擴展項，以使證書能夠附帶額外信息。標準擴展是指由X.509 
                        V3版本定義的對V2版本增加的具有廣泛應用前景的擴展項，任何人都可以向一些權威機構，如ISO，來注冊一些其他擴展，如果這些擴展項應用廣泛，也許以后會成為標準擴展項。<BR><BR>3.1.2 
                        CRL格式 <BR>證書廢除列表CRL（Certificate revocation 
                        lists，又稱證書黑名單）為應用程序和其它系統提供了一種檢驗證書有效性的方式。任何一個證書廢除以后，證書機構CA會通過發布CRL的方式來通知各個相關方。目前，同X.509 
                        V3證書對對應的CRL為X.509 v2 CRL，其所包含的內容格式如下： 
                        <BR><BR>CRL的版本號：0表示X.509 V1 標準；1表示X.509 V2 
                        標準；目前常用的是同X.509 V3證書對應的CRL V2版本。 
                        <BR>簽名算法：包含算法標識和算法參數，用于指定證書簽發機構用來對CRL內容進行簽名的算法。 
                        <BR>證書簽發機構名：簽發機構的DN名，由國家、省市、地區、組織機構、單位部門和通用名等組成。 
                        <BR>此次簽發時間：此次CRL簽發時間，遵循ITU-T X.509 
                        V2標準的CA在2049年之前把這個域編碼為UTCTime類型，在2050或2050年之后年之前把這個域編碼為GeneralizedTime類型。 
                        <BR>下次簽發時間：下次CRL簽發時間，遵循ITU-T X.509 
                        V2標準的CA在2049年之前把這個域編碼為UTCTime類型，在2050或2050年之后年之前把這個域編碼為GeneralizedTime類型。 
                        <BR>用戶公鑰信息，其中包括廢除的證書序列號和證書廢除時間。廢除的證書序列號是指要廢除的由同一個CA簽發的證書的一個唯一標識號，同一機構簽發的證書不會有相同的序列號。 
                        <BR>簽名算法：對CRL內容進行簽名的簽名算法。 
                        <BR>簽名值：證書簽發機構對CRL內容的簽名值。<BR><BR>另外，CRL中還包含擴展域和條目擴展域。CRL擴展域用于提供與CRL有關的額外信息部份，允許團體和組織定義私有的CRL擴展域來傳送他們獨有的信息；CRL條目擴展域則提供與CRL條目有關的額外信息部份，允許團體和組織定義私有的CRL條目擴展域來傳送他們獨有的信息。<BR><BR>3.1.3 
                        證書的存放 <BR>數字證書作為一種電子數據格式，可以直接從網上下載，也可以通過其他方式。 
                        <BR><BR>使用IC卡存放用戶證書。即把用戶的數字證書寫到IC卡中，供用戶隨身攜帶。這樣用戶在所有能夠讀IC卡證書的電子商務終端上都可以享受安全電子商務服務。 
                        <BR>用戶證書直接存放在磁盤或自己的終端上。戶將從CA申請來的證書下載或復制到磁盤或自己的PC機或智能終端上，當用戶使用自己的終端享受電子商務服務時，直接從終端讀入即可。<BR><BR>另外，CRL一般通過網上下載的方式存儲在用戶端。<BR><BR><BR>3.2 
                        CA框架模型 <BR><BR><BR>證書機構CA用于創建和發布證書，它通常為一個稱為安全域（security 
                        domain）的有限群體發放證書。創建證書的時候，CA系統首先獲取用戶的請求信息，其中包括用戶公鑰（公鑰一般由用戶端產生，如電子郵件程序或瀏覽器等），CA將根據用戶的請求信息產生證書，并用自己的私鑰對證書進行簽名。其他用戶、應用程序或實體將使用CA的公鑰對證書進行驗證。如果一個CA系統是可信的，則驗證證書的用戶可以確信，他所驗證的證書中的公鑰屬于證書所代表的那個實體。<BR><BR>CA還負責維護和發布證書廢除列表CRL（certificate 
                        revocation 
                        lists，又稱為證書黑名單）。當一個證書，特別是其中的公鑰因為其他原因無效時（不是因為到期），CRL提供了一種通知用戶和其他應用的中心管理方式。CA系統生成CRL以后，要么是放到LDAP服務器中供用戶查詢或下載，要么是放置在Web服務器的合適位置，以頁面超級連接的方式供用戶直接查詢或下載。<BR><BR>一個典型的CA系統包括安全服務器、注冊機構RA、CA服務器、LDAP目錄服務器和數據庫服務器等。如圖2所示。<BR><BR><IMG 
                        src="PKI技術及應用開發指南.files/fig2.gif"><BR><BR><BR>圖2 
                        典型CA框架模型<BR><BR>安全服務器：安全服務器面向普通用戶，用于提供證書申請、瀏覽、證書撤消列表以及證書下載等安全服務。安全服務器與用戶的的通信采取安全信道方式（如SSL的方式，不需要對用戶進行身份認證）。用戶首先得到安全服務器的證書（該證書由CA頒發），然后用戶與服務器之間的所有通信，包括用戶填寫的申請信息以及瀏覽器生成的公鑰均以安全服務器的密鑰進行加密傳輸，只有安全服務器利用自己的私鑰解密才能得到明文，這樣可以防止其他人通過竊聽得到明文。從而保證了證書申請和傳輸過程中的信息安全性。 
                        <BR>CA服務器：CA服務器使整個證書機構的核心，負責證書的簽發。CA首先產生自身的私鑰和公鑰（密鑰長度至少為1024位），然后生成數字證書，并且將數字證書傳輸給安全服務器。CA還負責為操作員、安全服務器以及注冊機構服務器生成數字證書。安全服務器的數字證書和私鑰也需要傳輸給安全服務器。CA服務器是整個結構中最為重要的部分，存有CA的私鑰以及發行證書的腳本文件，出于安全的考慮，應將CA服務器與其他服務器隔離，任何通信采用人工干預的方式，確保認證中心的安全。 
                        <BR>注冊機構RA：登記中心服務器面向登記中心操作員，在CA體系結構中起承上啟下的作用，一方面向CA轉發安全服務器傳輸過來的證書申請請求，另一方面向LDAP服務器和安全服務器轉發CA頒發的數字證書和證書撤消列表。 
                        <BR>LDAP服務器：LDAP服務器提供目錄瀏覽服務，負責將注冊機構服務器傳輸過來的用戶信息以及數字證書加入到服務器上。這樣其他用戶通過訪問LDAP服務器就能夠得到其他用戶的數字證書。 
                        <BR>數據庫服務器：數據庫服務器是認證機構中的核心部分，用于認證機構中數據（如密鑰和用戶信息等）、日志合統計信息的存儲和管理。實際的的數據庫系統應采用多種措施，如磁盤陣列、雙機備份和多處理器等方式，以維護數據庫系統的安全性、穩定性、可伸縮性和高性能。<BR><BR>3.3 
                        證書的申請和撤銷 
                        <BR>證書的申請有兩種方式，一是在線申請，另外一個就是離線申請。在線申請就是通過瀏覽器或其他應用系統通過在線的方式來申請證書，這種方式一般用于申請普通用戶證書或測試證書。離線方式一般通過人工的方式直接到證書機構證書受理點去辦理證書申請手續，通過審核后獲取證書，這種方式一般用于比較重要的場合，如服務器證書和商家證書等。下面討論的主要是在線申請方式。<BR><BR>當證書申請時，用戶使用瀏覽器通過Internet訪問安全服務器，下載CA的數字證書（又叫做根證書），然后注冊機構服務器對用戶進行身份審核，認可后便批準用戶的證書申請，然后操作員對證書申請表進行數字簽名，并將申請及其簽名一起提交給CA服務器。<BR><BR>CA操作員獲得注冊機構服務器操作員簽發的證書申請，發行證書或者拒絕發行證書，然后將證書通過硬拷貝的方式傳輸給注冊機構服務器。注冊機構服務器得到用戶的證書以后將用戶的一些公開信息和證書放到LDAP服務器上提供目錄瀏覽服務，并且通過電子郵件的方式通知用戶從安全服務器上下載證書。用戶根據郵件的提示到指定的網址下載自己的數字證書，而其他用戶可以通過LDAP服務器獲得他的公鑰數字證書。<BR><BR>證書申請的步驟如下： 
                        <BR><BR>用戶申請。<BR>用戶首先下載CA的證書，又叫根證書，然后在證書的申請過程中使用SSL安全方式與服務器建立連接，用戶填寫個人信息，瀏覽器生成私鑰和公鑰對，將私鑰保存客戶端特定文件中，并且要求用口令保護私鑰，同時將公鑰和個人信息提交給安全服務器。安全服務器將用戶的申請信息傳送給注冊機構服務器。 
                        <BR><BR>注冊機構審核<BR>用戶與注冊機構人員聯系，證明自己的真實身份，或者請求代理人與注冊機構聯系。 
                        注冊機構操作員利用自己的瀏覽器與注冊機構服務器建立SSL安全通信，該服務器需要對操作員進行嚴格的身份認證，包括操作員的數字證書、IP地址，為了進一步保證安全性，可以設置固定的訪問時間。<BR>操作員首先查看目前系統中的申請人員，從列表中找出相應的用戶，點擊用戶名，核對用戶信息，并且可以進行適當的修改，如果操作員同意用戶申請證書請求，必須對證書申請信息進行數字簽名。操作員也有權利拒絕用戶的申請。<BR>操作員與服務器之間的所有通信都采用加密和簽名，具有安全性、抗否認性，保證了系統的安全性和有效性。 
                        <BR>CA發行證書<BR>注冊機構RA通過硬拷貝的方式向CA傳輸用戶的證書申請與操作員的數字簽名，CA操作員查看用戶的詳細信息，并且驗證操作員的數字簽名，如果簽名驗證通過，則同意用戶的證書請求，頒發證書。然后CA將證書輸出。如果CA操作員發現簽名不正確，則拒絕證書申請，<BR>CA頒發的數字證書中包含關于用戶及CA自身的各種信息，如：能唯一標識用戶的姓名及其他標識信息，如個人的email地址；證書持有者的公鑰。公鑰用于為證書持有者加密敏感信息、簽發個人證書的認證機構的名稱、個人證書的序列號和個人證書的有效期（證書有效起止日期）等 
                        <BR>注冊機構證書轉發<BR>注冊機構RA操作員從CA處得到新的證書，首先將證書輸出到LDAP目錄服務器以提供目錄瀏覽服務，最后操作員向用戶發送一封電子郵件，通知用戶證書已經發行成功，并且把用戶的證書序列號告訴用戶到指定的網址去下載自己的數字證書。并且告訴用戶如何使用安全服務器上的LDAP配置，讓用戶修改瀏覽器的客戶端配置文件以便訪問LDAP服務器，獲得他人的數字證書。 
                        <BR>用戶證書獲取<BR>用戶使用證書申請時的瀏覽器到指定的網址，鍵入自己的證書序列號，服務器要求用戶必須使用申請證書時的瀏覽器，因為瀏覽器需要用該證書相應的私鑰去驗證數字證書。只有保存了相應私鑰的瀏覽器才能成功下載用戶的數字證書。<BR><BR>這時用戶打開瀏覽器的安全屬性，就可以發現自己已經擁有了CA頒發的數字證書，可以利用該數字證書與其他人以及web服務器（擁有相同CA頒發的證書）使用加密、數字簽名進行安全通信。<BR><BR>認證中心還涉及到CRL的管理。用戶向特定的操作員（僅負責CRL的管理）發一份加密簽名的郵件，申明自己希望撤消證書。操作員打開郵件，填寫CRL注冊表，并且進行數字簽名，提交給CA，CA操作員驗證注冊機構操作員的數字簽名，批準用戶撤消證書，并且更新CRL，然后CA將不同格式的CRL輸出給注冊機構，公布到安全服務器上，這樣其他人可以通過訪問服務器得到CRL。<BR><BR>證書撤銷流程步驟如下： 
                        <BR><BR>用戶向注冊機構操作員CRLManager發送一封簽名加密的郵件，聲明自己自愿撤消證書。 
                        <BR>這冊機構同意證書撤消，操作員鍵入用戶的序列號，對請求進行數字簽名。 
                        <BR>CA查詢證書撤消請求列表，選出其中的一個，驗證操作員的數字簽名，如果正確的話，則同意用戶的證書撤消申請，同時更新CRL列表，然后將CRL以多種格式輸出。 
                        <BR>注冊機構轉發證書撤消列表。操作員導入CRL，以多種不同的格式將CRL公布于眾。 
                        <BR>用戶瀏覽安全服務器，下載或瀏覽CRL。<BR><BR>在一個PKI，特別是CA中，信息的存儲是一個非常核心的問題，它包括兩個方面：一是CA服務器利用數據庫來備份當前密鑰和歸檔過期密鑰，該數據庫需高度安全和機密，其安全等級同CA本身相同；另外一個就是目錄服務器，用于分發證書和CRL，一般采用LDAP目錄服務器。<BR><BR>3.4 
                        密鑰管理 
                        <BR>密鑰管理也是PKI（主要指CA）中的一個核心問題，主要是指密鑰對的安全管理，包括密鑰產生、密鑰備份、密鑰恢復和密鑰更新等。<BR><BR>1. 
                        密鑰產生<BR>密鑰對的產生是證書申請過程中重要的一步，其中產生的私鑰由用戶保留，公鑰和其他信息則交于CA中心進行簽名，從而產生證書。根據證書類型和應用的不同，密鑰對的產生也有不同的形式和方法。對普通證書和測試證書，一般由瀏覽器或固定的終端應用來產生，這樣產生的密鑰強度較小，不適合應用于比較重要的安全網絡交易。而對于比較重要的證書，如商家證書和服務器證書等，密鑰對一般由專用應用程序或CA中心直接產生，這樣產生的密鑰強度大，適合于重要的應用場合。<BR>另外，根據密鑰的應用不同，也可能會有不同的產生方式。比如簽名密鑰可能在客戶端或RA中心產生，而加密密鑰則需要在CA中心直接產生。<BR><BR>2. 
                        密鑰備份和恢復<BR>在一個PKI系統中，維護密鑰對的備份至關重要，如果沒有這種措施，當密鑰丟失后，將意味著加密數據的完全丟失，對于一些重要數據，這將是災難性的。所以，密鑰的備份和恢復也是PKI密鑰管理中的重要一環。<BR>使用PKI的企業和組織必須恩能夠得到確認：即使密鑰丟失，受密要加密保護的重要信息也必須能夠恢復，并且不能讓一個獨立的個人完全控制最重要的主密鑰，否則將引起嚴重后果。<BR>企業級的PKI產品至少應該支持用于加密的安全密鑰的存儲、備份和恢復。密鑰一般用口令進行保護，而口令丟失則是管理員最常見的安全疏漏之一。所以，PKI產品應該能夠備份密鑰，即使口令丟失，它也能夠讓用戶在一定條件下恢復該密鑰，并設置新的口令。<BR>例如，在某些情況下用戶可能有多對密鑰，至少應該有兩個密鑰：一個用于加密，一個用于簽名。簽名密要不需要備份，因為用于驗證簽名的公鑰（或公鑰證書）廣泛發布，即使簽名私鑰丟失，任何用于相應公要的人都可以對已簽名的文檔進行驗證。但PKI系統必須備份用于加密的密鑰對，并允許用戶進行恢復，否則，用于解密的私鑰丟失將意味著加密數據的完全不可恢復。<BR>另外，使用PKI的企業也應該考慮所使用密鑰的生命周期，它包括密鑰和證書的有效時間，以及已撤銷密鑰和證書的維護時間等。<BR><BR>3. 
                        密鑰更新<BR>對每一個由CA頒發的證書都會有有效期，密鑰對生命周期的長短由簽發證書的CA中心來確定，各CA系統的證書有效期限有所不同，一般大約為2-3年。<BR>當用戶的私鑰被泄漏或證書的有效期快到時，用戶應該更新私鑰。這時用戶可以廢除證書，產生新的密鑰對，申請新的證書。<BR><BR>3.5 
                        證書的使用 
                        <BR>在實際應用中，為了驗證信息的數字簽名，用戶首先必須獲取信息發送者的公鑰證書，以及一些額外需要的證書（如CA證書等，用于驗證發送者證書的有效性）。<BR><BR>證書的獲取可以有多種方式，如發送者發送簽名信息時附加發送自己的證書，或以另外的單獨信息發送證書，或者可以通過訪問證書發布的目錄服務器來獲得，或者直接從證書相關的實體處獲得。在一個PKI體系中，可以采取某種或某幾種上述方式獲得證書。<BR><BR>在電子商務系統中，證書的持有者可以是個人用戶、企事業單位、商家、銀行等。無論是電子商務中的哪一方，在使用證書驗證數據時，都遵循同樣的驗證流程。一個完整的驗證過程有以下幾步： 
                        <BR><BR>將客戶端發來的數據解密 (如解開數字信封)。 
                        <BR>將解密后的數據分解成原始數據，簽名數據和客戶證書三部分。 <BR>用CA根證書驗證客戶證書的簽名完整性。 
                        <BR>檢查客戶證書是否有效 (當前時間在證書結構中的所定義的有效期內)。 <BR>檢查客戶證書是否作廢 
                        (OCSP方式或CRL方式)。 <BR>驗證客戶證書結構中的證書用途。 
                        <BR>客戶證書驗證原始數據的簽名完整性。<BR><BR>如果以上各項均驗證通過，則接受該數據。<BR><BR>4 
                        PKI應用 
                        <BR>---PKI技術的廣泛應用能滿足人們對網絡交易安全保障的需求。當然，作為一種基礎設施，PKI的應用范圍非常廣泛，并且在不斷發展之中，下面給出幾個應用實例。<BR><BR>1. 
                        虛擬專用網絡（VPN）<BR>VPN是一種架構在公用通信基礎設施上的專用數據通信網絡，利用網絡層安全協議（尤其是IPSec）和建立在PKI上的加密與簽名技術來獲得機密性保護。基于PKI技術的IPSec協議現在已經成為架構VPN的基礎，它可以為路由器之間、防火墻之間或者路由器和防火墻之間提供經過加密和認證的通信。雖然它的實現會復雜一些，但其安全性比其他協議都完善得多。<BR><BR>2. 
                        安全電子郵件<BR>----作為Internet上最有效的應用，電子郵件憑借其易用、低成本和高效已經成為現代商業中的一種標準信息交換工具。隨著Internet的持續增長，商業機構或政府機構都開始用電子郵件交換一些秘密的或是有商業價值的信息，這就引出了一些安全方面的問題，包括：消息和附件可以在不為通信雙方所知的情況下被讀取、篡改或截掉；發信人的身份無法確認。電子郵件的安全需求也是機密、完整、認證和不可否認，而這些都可以利用PKI技術來獲得。目前發展很快的安全電子郵件協議是S/MIME 
                        (The Secure Multipurpose Internet Mail 
                        Extension)，這是一個允許發送加密和有簽名郵件的協議。該協議的實現需要依賴于PKI技術。<BR><BR>3. 
                        Web安全 <BR>----瀏覽Web頁面是人們最常用的訪問Internet的方式。如果要通過Web 
                        進行一些商業交易，該如何保證交易的安全呢？為了透明地解決Web的安全問題，在兩個實體進行通信之前，先要建立SSL連接，以此實現對應用層透明的安全通信。利用PKI技術，SSL協議允許在瀏覽器和服務器之間進行加密通信。此外服務器端和瀏覽器端通信時雙方可以通過數字證書確認對方的身份。-結合SSL協議和數字證書，PKI技術可以保證Web 
                        交易多方面的安全需求，使Web上的交易和面對面的交易一樣安全。<BR><BR>5 應用編程接口API 
                        <BR>協議標準是系統具有可交互性的前提和基礎，它規范了PKI系統各部分之間相互通信的格式和步驟。而應用編程界面API（Application 
                        programming 
                        interfaces）則定義了如何使用這些協議，并為上層應用提供PKI服務。當應用需要使用PKI服務，如獲取某一用戶的公鑰、請求證書廢除信息或請求證書時將會都會用到API。目前API沒有統一的國際標準，大部分都是操作系統或某一公司產品的擴展，并在其產品應用的框架內提供PKI服務。<BR><BR>目前，有很多可以讓開發者選擇的API類型。IETF建議標準為通用安全服務API：GSS-API（Generic 
                        Security Service Application Program 
                        Interface），它提供了一種接口與網絡機制和網絡協議相互獨立的實現。<BR><BR>歐洲建立的SESAME（Secure 
                        European System for Applications in a Multi-Vendor 
                        Environment）定義了一些安全界面，并作為該組織發展的安全技術的一部分，該接口得到了歐洲許多著名廠商的支持，如Bull 
                        SA、ICL和Seimens等，但沒有在美國得到支持，特別是一些大的廠商，如Microsoft和Netscape等。<BR><BR>Entrust也為其產品提供了一套API，如Entrust證書管理服務API（CMS 
                        API，Entrust's Certificate Management Services 
                        API），該API允許應用使用Entrust的證書管理和分發服務。在1996年指定，并與1997年更新的PKIX 
                        Internet草案"Architecture for Public Key