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的签名,也可以是自签名)。对于一份经由可信的证书签发机构签名或者可以通过其它方式验证的证书,证书的拥有者就可以用证书及相应的私钥来创建安全的通信,对文档进行数字签名。