Can you summarize the following document?
        
  X.509最早與X.500一起釋出於1988年7月3日。它假設有一套嚴格的層次化的證書頒發機構(CA)。X.500系統僅由主權國家實施,以實現國家身份資訊共享條約的實施目的;而IETF的公鑰基礎設施(X.509)簡稱PKIX工作組將該標準制定成適用於更靈活的網際網路組織。而且事實上X.509認證指的是RFC5280裡定義的X.509 v3,包括對IETF的PKIX證書和證書吊銷列表,通常也稱為公鑰基礎設施(PKI)。

  在X.509裡,組織機構通過發起證書籤名請求(CSR)來得到一份簽名的證書。首先需要生成一對金鑰對,然後用其中的私鑰對CSR進行數碼簽署(簽名),並安全地儲存私鑰。CSR進而包含有請求發起者的身份資訊、用來對此請求進行驗真的的公鑰以及所請求證書專有名稱。CSR裡還可能帶有CA要求的其它有關身份證明的資訊。然後CA對這個CSR進行簽名。 組織機構可以把受信的根證書分發給所有的成員,這樣就可以使用公司的PKI系統了。瀏覽器(如Firefox)或作業系統預裝有可信任的根證書列表,所以主流CA釋出的TLS證書都直接可以正常使用。瀏覽器的開發者直接影響著它的使用者對CA的信任。X.509也定義了CRL實現標準。另一種檢查合法性的方式是OCSP。

  證書組成結構標準用ASN.1(一種標準的語言)來進行描述. X.509 v3 數字證書結構如下:  所有擴充套件都有一個ID,由object identifier來表達.它是一個集合,並且有一個標記用與指示這個擴充套件是不是決定性的。證書使用時,如果發現一份證書帶有決定性標記的擴充套件,而這個系統並不清楚該擴充套件的用途,那麼要拒絕使用它。但對於非決定性的擴充套件,不認識可以予以忽略。 RFC 1422給出了v1的證書結構 ITU-T在v2裡增加了頒發者和主題唯一識別符號,從而可以在一段時間後可以重用。重用的一個例子是當一個CA破產了,它的名稱也在公共列表裡清除掉了,一段時間之後另一個CA可以用相同的名稱來註冊,即使它與之前的並沒有任何瓜葛。不過IETF並不建議重用同名註冊。另外v2在Internet也沒有多大範圍的使用。 v3引入了擴充套件。CA使用擴充套件來發布一份特定使用目的的證書(比如說僅用於程式碼簽名) 所有的版本中,同一個CA頒發的證書序列號都必須是唯一的。

  (及後續版本)定義了一些擴充套件用來指定證書的用途。 它們的多數都來源於joint-iso-ccitt(2) ds(5) id-ce(29) OID。在4.2.1裡定義的幾個常用擴充套件定義如下:  通常情況下,一份證書有多個限制用途的擴充套件時,所有限制條件都應該滿足才可以使用。<nowiki>RFC 5280</nowiki>裡有對一個同時含有keyUsage和extendedKeyUsage的證書的例子,這樣的證書只能用在兩個擴充套件中都指定了的用途。比如網路安全服務決定證書用途時會同時對這兩個擴充套件進行判斷

  X.509有多種常用的副檔名。不過其中的一些還用於其它用途,就是說具有這個副檔名的檔案可能並不是證書,比如說可能只是儲存了私鑰。  PKCS#7 是簽名或加密資料的格式標準,官方稱之為容器。由於證書是可驗真的簽名資料,所以可以用SignedData結構表述。.P7C檔案是退化的SignedData結構,沒有包括簽名的資料。  PKCS#12 由PFX進化而來的用於交換公共的和私有的物件的標準格式。

  證書鏈(也就是RFC 5280裡的證書路徑)是從終端使用者證書後跟著一系列的CA證書,而通常最後一個是自簽名證書,並且有如下關係:  證書鏈用於檢查目標證書(證書鏈裡的第一個證書)裡的公鑰及其它資料是否屬於其主題。檢查是這麼做的,用證書鏈中的下一個證書的公鑰來驗證它的簽名,一直檢查到證書鏈的尾端,如果所有驗證都成功通過,那個這個證書就是可信的。  下面是對RFC 5280裡定義的證書路徑合法性演算法的一個簡要介紹,包括對證書的有效期、CRL等其它額外的檢查。  對於具體的證書來說,有一點需要注意的是它可能存在於很不一樣的兩條或多條證書鏈中,並且都是合法的。這是因為CA證書可以來自多個頒發者,或者來自相同頒發者但用不同的私鑰簽發,這樣在CA證書上會出現分叉,從而可以出現多條證書鏈。這也是PKI之間交叉認證和其它應用的關鍵所在。  看下面的例子:  在這兩個圖裡:

  為了讓PKI2的使用者證書也得到PKI1的信任,CA1生成一包含CA2公鑰的證書cert2.1 這時候cert2和cert2.1具體相同的主題及公鑰,cert2.2 (User 2)就有了兩條合法的證書鏈:"cert2.2 → cert2" and "cert2.2 → cert2.1 → cert1"。  CA2也可以生成類似的包含有CA1公鑰的證書cert1.1,以便PKI1的使用者(比如User 1)的證書能在PKI2得到認證。

  假設cert1和cert3具有相同的公鑰,對於cert5來說有兩條合法的證書鏈,cert5 → cert1 和 cert5 → cert3 → cert2, cert6的情況也類似。這樣就允許老的使用者證書可以在新舊兩個根證書之間平滑轉移。

  下面是GlobalSign頒發的用於wikipedia.org以及一些其它Wikipedia網站X.509證書。證書頒發者填在頒發者(Issuer)欄位,主題內容裡是組織機構Wikipedia的描述,主題備用名稱是那些採用該證書的伺服器的主機名。主題公鑰裡的資訊表明採用的是橢圓曲線公共金鑰,位於最後的簽名演算法表示它是由GlobalSign用其私鑰並採用帶RSA加密的SHA-256演算法進行簽名的。

  憑證:  要驗證這個證書,我們需要一個跟該證書頒發者及授權金鑰識別符號 都匹配的中間證書 配置正確的伺服器可以在TLS連線建立的握手階段同時提供其中間證書。但是也有可能需要根據證書裡頒發者的URL去取得中間證書。

  下面是證書頒發機構的證書示例。該證書是由下例根證書籤名的用於頒發上例最終實體證書的證書。當然它的主題識別符號跟上例證書的授權金鑰識別符號是相匹配的。

  下面是證書頒發機構的自簽名根證書。它的頒發者和主題是相同的,可以用自身的公鑰進行合法認證。證書認證過程也將在此終止。如果應用已經在它的可信公鑰存貯裡已經含有該公鑰證書,那麼TLS連線時的那個最終實體證書是可信的,否則就是不可信的。

  布魯斯·施奈爾、彼得·古特曼及其他安全專家已經發布了很多PKI的安全問題。
X.509是密碼學裡公鑰證書的格式標準。X.509證書已應用在包括TLS/SSL在內的眾多網路協議裡,同時它也用在很多非線上應用場景裡,比如電子簽名服務。X.509證書裡含有公鑰、身份資訊(比如網路主機名,組織的名稱或個體名稱等)和簽名資訊(可以是證書籤發機構CA的簽名,也可以是自簽名)。對於一份經由可信的證書籤發機構簽名或者可以通過其它方式驗證的證書,證書的擁有者就可以用證書及相應的私鑰來建立安全的通訊,對文件進行數字簽名。