| 密码学里公钥证书的格式标准 | |
 | |
| 状态 | 已生效 |
|---|---|
| 开始年 | 1988 |
| 最新版本 | 10/19 2019-10 |
| 组织 | ITU-T |
| 有关标准 | X.509 |
| 网站 | https://www.itu.int/rec/T-REC-X.509/ |
X.509是密码学里公钥证书的格式标准。X.509证书已应用在包括TLS/SSL在内的众多网络协议里，同时它也用在很多非在线应用场景里，比如电子签名服务。X.509证书里含有公钥、身份信息（比如网络主机名，组织的名称或个体名称等）和签名信息（可以是证书签发机构CA的签名，也可以是自签名）。[1]
X.509还附带了证书吊销列表和用于从最终对证书进行签名的证书签发机构直到最终可信点为止的证书合法性验证算法。X.509是ITU-T标准化部门基于他们之前的ASN.1定义的一套证书标准。
| 互联网安全协议 |
|---|
| 密钥管理 |
| 应用层 |
| 域名系统 |
| 网络层 |
历史及使用情况
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来表达.它是一个集合，并且有一个标记用与指示这个扩展是不是决定性的。证书使用时，如果发现一份证书带有决定性标记的扩展，而这个系统并不清楚该扩展的用途，那么要拒绝使用它。但对于非决定性的扩展，不认识可以予以忽略。[2] RFC 1422[3]给出了v1的证书结构 ITU-T在v2里增加了颁发者和主题唯一标识符，从而可以在一段时间后可以重用。重用的一个例子是当一个CA破产了，它的名称也在公共列表里清除掉了，一段时间之后另一个CA可以用相同的名称来注册，即使它与之前的并没有任何瓜葛。不过IETF并不建议重用同名注册。另外v2在Internet也没有多大范围的使用。 v3引入了扩展。CA使用扩展来发布一份特定使用目的的证书（比如说仅用于代码签名） 所有的版本中，同一个CA颁发的证书序列号都必须是唯一的。
扩展指定了证书的用途
RFC 5280（及后续版本）定义了一些扩展用来指定证书的用途。 它们的多数都来源于joint-iso-ccitt(2) ds(5) id-ce(29) OID。在4.2.1里定义的几个常用扩展定义如下：
- Basic Constraints， { id-ce 19 }[4]用于指定一份证书是不是一个CA证书。
- Key Usage, { id-ce 15 },[5]指定了这份证书包含的公钥可以执行的密码操作。作为一个例子，它可以指定只能用于签名，而不能用来进行加密操作。
- Extended Key Usage, { id-ce 37 },[6]典型用法是用于叶子证书中的公钥的使用目的。它包括一系列的OID，每一个都指定一种用途。比如{ id-pkix 3 1 } 表示用于服务器端的TLS/SSL连接，而{ id-pkix 3 4 }用于email的安全操作。
通常情况下，一份证书有多个限制用途的扩展时，所有限制条件都应该满足才可以使用。RFC 5280里有对一个同时含有keyUsage和extendedKeyUsage的证书的例子，这样的证书只能用在两个扩展中都指定了的用途。比如网络安全服务决定证书用途时会同时对这两个扩展进行判断[7]
证书文件扩展名
X.509有多种常用的扩展名。不过其中的一些还用于其它用途，就是说具有这个扩展名的文件可能并不是证书，比如说可能只是保存了私钥。
- .pem – 隐私增强型电子邮件格式，通常是Base64格式的。
- .cer, .crt, .der – 通常是DER二进制格式的。
- .p7b, .p7c – PKCS#7格式
- .p12 – PKCS#12格式，包含证书的同时可能还包含私钥
- .pfx – PFX，PKCS#12之前的格式（通常用PKCS#12格式，比如由互联网信息服务产生的PFX文件）
证书链和交叉认证
证书链（也就是RFC 5280里的证书路径)[8]是从终端用户证书后跟着一系列的CA证书，而通常最后一个是自签名证书，并且有如下关系：
- 在证书链上除最后一个证书外，证书颁发者等于其后一个证书的主题。
- 除了最后一个证书，每个证书都是由其后的一个证书签名的。
- 最后的证书是信任主题，由于是通过可信过程得到的，你可以信任它。
证书链用于检查目标证书（证书链里的第一个证书）里的公钥及其它数据是否属于其主题。检查是这么做的，用证书链中的下一个证书的公钥来验证它的签名，一直检查到证书链的尾端，如果所有验证都成功通过，那个这个证书就是可信的。
下面是对RFC 5280里定义的证书路径合法性算法的一个简要介绍[8]，包括对证书的有效期、CRL等其它额外的检查。
对于具体的证书来说，有一点需要注意的是它可能存在于很不一样的两条或多条证书链中，并且都是合法的。这是因为CA证书可以来自多个颁发者，或者来自相同颁发者但用不同的私钥签发，这样在CA证书上会出现分叉，从而可以出现多条证书链。这也是PKI之间交叉认证和其它应用的关键所在。 [9] 看下面的例子：
在这两个图里：
- 方块代表证书，加黑的是证书的主题名字。
- A → B 表示 "A是由B签发的" （更确切地说，A是由B中所载公钥对应的私钥签署的）
- 相同颜色（透明色和白色除外）的证书具有相同的公钥
例1: 两个PKI之间的根证书交叉认证
为了让PKI2的用户证书也得到PKI1的信任，CA1生成一包含CA2公钥的证书cert2.1[10] 这时候cert2和cert2.1具体相同的主题及公钥，cert2.2 (User 2)就有了两条合法的证书链："cert2.2 → cert2" and "cert2.2 → cert2.1 → cert1"。
CA2也可以生成类似的包含有CA1公钥的证书cert1.1，以便PKI1的用户(比如User 1)的证书能在PKI2得到认证。
例2: CA证书更新
假设cert1和cert3具有相同的公钥，对于cert5来说有两条合法的证书链，cert5 → cert1 和 cert5 → cert3 → cert2, cert6的情况也类似。这样就允许老的用户证书可以在新旧两个根证书之间平滑转移。[11][12]
安全性
布鲁斯·施奈尔、彼得·古特曼及其他安全专家已经发布了很多PKI的安全问题。 [13][14][15]
架构的弱点
- 采用黑名单方式的证书吊销列表(CRL)和在线证书状态协议(OCSP)
- 如果客户端仅信任在CRL可用的时候信任证书，那就失去离线信任的需求。因此通常客户端会在CRL不可用的情况下信任证书，因而给了那些可以控制信道的攻击者可乘之机。如谷歌的Adam Langley所说，对CRL的检查就像在关键时刻断开的安全带[16]
- 在大范围及复杂的分布模式下选用CRL并不明智
- OCSP由于没有吊销状态的历史记录也会出现歧义
- 聚合问题
- 代表问题: 证书颁发机构没办法限制其下属颁发的证书作出名字及属性方面的限制。而且在Internet上存在着相当多的证书颁发机构，想对他们进行分类和策略上的限制是一项不可能完成的任务。
- 分布问题: 证书链引的下属颁发机构，桥接颁发机构以及交叉认证使得证书验证变得非常复杂，需要付出很大的代价。层次式的第三方信任模型作为一种唯一的模型的话，路径验证也可能出现含糊不明的情况岐义，这对于已经创建双边信任也很不方便。
- 发布一个对主机名的扩展验证并不能防止再发布一个验证要求低一些的适用于同一个主机名的证书。这就造成了不能对中间人攻击的有效保护[17]
证书颁发机构问题
- 即使主题实体购买了扩展验证的证书，他的付出也并不能得到相应的回报，因为这并不能阻止通过更便宜的证书颁发机构购买相同主题内容的证书的行为
- 证书颁发机构不能给用户提供主题甚至组织团体上的担保，无法阻止同名证书
- 证书有效期应该限制在密钥强度可保护的范围内。但这个字段却被证书颁发机构误用为收费依据从而让用户处于密钥可能被破解的情况下
- "如果用户通过一种未定义的证书请求协议去获得子一个地址不明的，不存在于任何目录下的证书，那么你也没办法吊销这个证书。"[15]
参考文献
- ↑ X.509 : Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks. www.itu.int. [2021-04-29].
- ↑ RFC 5280 section 4.2, retrieved 12 February 2013. [2018-04-28].
- ↑ RFC 1422
- ↑ RFC 5280, Section 'Basic Constraints'. [2018-04-28].
- ↑ 'RFC 5280, Section 'Key Usage'. [2018-04-28].
- ↑ RFC 5280, Section 'Extended Key Usage'. [2018-04-28].
- ↑ All About Certificate Extensions
- ↑ 8.0 8.1 Certification Path Validation. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Network Working Group. 2008 [2018-04-28].
- ↑ Lloyd, Steve. Understanding Certification Path Construction (PDF). PKI Forum. 2002-09.
- ↑ Cross-Certification Between Root CAs. Qualified Subordination Deployment Scenarios. Microsoft. 2009-08.
- ↑ Nash; Duane; Joseph; Brink. Key and Certificate Life Cycles. CA Certificate Renewal. PKI: Implementing and Managing E-Security. RSA Press - Osborne/McGraw-Hill. 2001. ISBN 0-07-213123-3.
- ↑ Understanding Certification Path Construction (PDF). PKI Forum. 2002-09.
为了证书颁发者从旧的私钥顺利地转移到新的私钥，他可以颁发两个证书，其中一个是新的私钥对旧的公钥进行签名，另一个是旧的私钥对新的公钥的签名，这两个都是机构自己给自己颁发的证书，但都不是自签名证书。注：另外还存在新旧两个自签名证书。
- ↑ Carl Ellison and Bruce Schneier. Top 10 PKI risks (PDF). Computer Security Journal (Volume XVI, Number 1, 2000). [2018-04-28].
- ↑ Peter Gutmann. PKI: it's not dead, just resting (PDF). IEEE Computer (Volume:35, Issue: 8). [2018-04-28].
- ↑ 15.0 15.1 Gutmann, Peter. Everything you Never Wanted to Know about PKI but were Forced to Find Out (PDF). [2011-11-14].
- ↑ Langley, Adam. Revocation checking and Chrome's CRL (05 Feb 2012). Imperial Violet. [2017-02-02].
- ↑ Zusman and Sotirov Blackhat 2009