各位朋友们，你们好： 《 PKI 漫谈》是我早就想写的一系列文稿。有一段时间，经常给一些同事介绍 PKI ，几次后手头就有了一个简要的大纲。在和几个朋友有了一些简单的交流后，我将经过第一次修改后的大纲拿给了一些专业人员看了看，有一些朋友提出了很好的意见，如金辉 (Arthur Jin) 提出了应加入 RC 系列密码算法的介绍，李延昭 (Chorus Li) 提出了应对国内的 PKI 厂商与产品进行一些介绍，……。最后，更为重要的是， Yongtian Zhang 提出一些很好的意见。基于这些意见，我对大纲做了第二次的修改 ( 我会附在下面 ) 。这些事情都发生在 2000 年 11 月份以前，在接下来的这一年时间里，一直没抽出比较整块的时间来写这份东西，此次，借 AKA 安全沙龙召开活动的契机，我用 Powerpoint 的形式整编了一些资料，希望能对大家学习、了解 PKI 有一些帮助。 王曙 (Kevin Wang) 2001.11.11 附： From: Kevin Wang Date: Fri Nov 15, 2000 11:51am Subject: the second revision for the outline of <<PKI Guide>> Hi, all: The following is the second revision for the outline of <<PKI Guide>>. Thanks Arthur for reminding me to add RC2/RC4, thanks Chorous for reminding me to add something about domestic PKI vendors, and some of important ideas come from a friend - Zhang.Yongtian, he spent time to review the outline and give me his important comments. I hope you can review the new coming one and give me your ideas about it. kevin 11/15/2000 =========================================================== PKI 漫 谈 Chapter 0 绪论 0.1 什么是 PKI 0.2 PKI 的理论基础 0.3 PKI 的由来 / 来源 ( 为什么需要 PKI ， PKI 能解决什么问题 ) 0.4 PKI 的进展 0.5 本漫谈的内容介绍 Chapter 1 密码学 1.1 概述 1.2 公钥密码学 1.2.1 概述 1.2.2 RSA 1.2.3 DH/DSA 1.2.4 Elgemal 1.2.5 Others 1.3 传统密码学 1.3.1 概述 1.3.2 DES 1.3.3 IDEA 1.3.4 RC2 与 RC4 1.3.5 AES 与 Rijndeal 1.3.6 Others 1.4 散列算法 1.4.1 概述 1.4.2 MD5,MD4 1.4.3 SHA 1.4.4 RIPEMD 1.4.5 HMAC 1.4.6 Others 1.5 不同算法的特点 Chapter 2 X.500 目录体系与数字证书 2.1 概述 2.2 X.500 目录体系 2.3 X.509 数字证书 2.4 LDAP 协议 Chapter 3 PKI 及其构件 3.1 综述 3.2 CA 、 RA 与 EE 3.3 PKI 运作与 CPS 3.4 PMI 与 TSA 在本章中，先介绍 PKI 的构件组成，再谈一谈 PKI 中各构件的关系，最后谈一谈 PKI 运作与 CPS 。 Chapter 4 PKI 实施中的问题 ( 一 ) – 技术问题 4.1 数字证书 RSA 证书， DH/DSA 证书的实现； 4.2 证书验证与证书生命周期 4.3 交叉认证 4.4 标准化 本章主要介绍 PKI 实施中涉及到的一些实际问题。 如各 CA 间的互操作性，验证证书时的协议实现 (CRL or OCSP) - 客户端应用与 CA 之间的配合，这涉及到各个 PKI 厂商的专用实现。 Chapter 5 PKI 实施中的问题 ( 二 ) – 非技术问题 5.1 证书政策与证书政策声明 (CP and CPS) 5.2 运作安全 5.3 PKI 涉及到的法律问题 Chapter 6 PKI 应用 6.1 SSL/TLS 6.2 S/MIME 6.3 IPSec 6.4 SET 6.5 Time Stamping 6.6 Data Certification Chapter 7 著名的 PKI 厂商与实现 7.1 著名的 PKI 厂商及其产品 7.1.1 VeriSign 7.1.2 Entrust 7.1.3 Baltimore 7.1.4 RSA Security 7.1.5 Others 7.2 著名的 PKI 实现 7.2.1 OpenCA 工程 7.2.2 OSCAR PKI 工程 7.2.3 JonahPKI 工程 7.2.4 pyCA 工程 7.2.5 Mozilla NSS/PSM 7.2.6 MISPC 参考实现 Chapter 8 标准化进展 8.1 概述 8.2 X 系列标准 (X.208,X.209,X.500 & X.509) 8.3 IETF PKIX 工作组 8.4 SET 8.5 PKCS 8.6 OpenPGP 8.4 其它 Appendix A 信任模型 Web of Trust, Trust Hierarchy, Others Appendix B 现有 PKI 的不足 指明现有 PKI 的不足之处，如 Trust Model ， Privacy 以及应用标准化等方面存在的问题，并说明下一步可能的 进展。主要内容基于 http://www.anu.edu.au/people/Roger.Clarke/II/PKIMisFit.html 和其它方面的一些文章和报道。 Appendix C Terminology( 术语表 ) Appendix D References( 参考文献 ) Appendix E 国内的 PKI 工程与厂商 1. CTCA ( 即中国电信 CA ，由创原世纪完成 ) 2. 外经贸部 CA - 国富安 ( http://www.cacenter.com.cn/ ) 3. CFCA （即中国金融认证中心， http://www.cfca.com.cn/ ） 4. CPCA （即国家邮政总局 CA ，在建项目） 5. 信安世纪 ( http://www.infosec.com.cn/ ) 6. 诺方信业 ( http://www.netfront.com.cn/ ) 7. 德达创新 ( http://www.datatrust.com.cn/ ) 8. 吉大正元 ( http://www.jit.com.cn/ )
1. PKI 是一个用公钥概念和技术来实施和提供安全服务的具有普适性的安全基础设施。 2. PKI 是安全管理基础设施中使用基于公钥安全服务、专注于密钥和证书管理的部分。这包括共同为用户和应用提供安全服务的策略、规程、设备和个人。 PKI 产生等同于手工过程的“信任链”。 A PKI is that portion of the security management infrastructure dedicated to the management of keys and certificates used by public key-based security services. This includes the policy, procedures, equipment, and personnel that collectively provide security services to users and applications. A PKI produces a &quot;chain of trust&quot; equivalent to manual processes. URL ： http://www.computermagic.com/PKI/pki-components.htm 3. Public Key Infrastructure (PKI): 提供公钥证书的生成、制造、分发、控制、计帐和破坏的框架和服务。 The framework and services that provide for the generation, production, distribution, control, accounting and destruction of public key certificates URL ： http://www.wcecrc.org/Definitions.html Definitions for Department of Defense (DoD) Public Key Infrastructure (PKI) 4. PKI 公钥基础设施的缩写，是用于验证和鉴别在互联网交易中涉及到各方的有效性的关于数字证书、证书授权机构和其它登记机构的系统。 PKI 正在演进，当前没有单独的 PKI 和为建立 PKI 公认的标准。然而，几乎所有人都同意可靠的 PKI 是电子商务获得广泛应用必需的。 PKI 也被称为信任层次结构。 Short for public key infrastructure, a system of digital certificates, Certificate Authorities, and other registration authorities that verify and authenticate the validity of each party involved in an Internet transaction. PKIs are currently evolving and there is no single PKI nor even a single agreed-upon standard for setting up a PKI. However, nearly everyone agrees that reliable PKIs are necessary before electronic commerce can become widespread. A PKI is also called a trust hierarchy URL ： http://webopedia.internet.com/TERM/P/PKI.html 5. What is a PKI? PKI 由支持公钥密码学应用的协议、服务和标准组成。术语 PKI ，出现时间并不长，定义也变化多端。有时 PKI 只简单的指基于公钥证书的信任层次，而在其它场合却意味着提供给最终用户应用的加密和数字签名服务。较中立的观点是 PKI 包括管理公钥的服务和协议，通常是通过 CA 和 RA 构件，但执行密码运算不是必需的。 A public-key infrastructure (PKI) consists of protocols, services, and standards supporting applications of public-key cryptography. The term PKI, which is relatively recent, is defined variously in current literature. PKI sometimes refers simply to a trust hierarchy based on public-key certificates , and in other contexts embraces encryption and digital signature services provided to end-user applications as well [OG99]. A middle view is that a PKI includes services and protocols for managing public keys, often through the use of Certification Authority (CA) and Registration Authority (RA) components, but not necessarily for performing cryptographic operations with the keys. 在 PKI 中可见到的服务有： 密钥注册：发布公钥的证书； 证书吊销：取消先前发布的证书； 密钥选择：得到一方的公钥； 信任评估：确定一证书是否有效以及它授权了什么操作； 也建议密钥恢复是 PKI 的一部分； Among the services likely to be found in a PKI are the following: Key registration: issuing a new certificate for a public key. Certificate revocation: canceling a previously issued certificate. Key selection: obtaining a party's public key. Trust evaluation: determining whether a certificate is valid and what operations it authorizes. Key recovery has also been suggested as a possible aspect of a PKI. 今天还没有一个单一普适的公钥基础设施，尽管定义 PKI 的努力通常假定最会只有一个，或者多个独立的 PKI 会日益演进成不同程度共存和互操作性的基础设施。从这个意义上讲，今天的 PKI 可被视作 20 世纪 80 年代，未广泛连接形成互联网前的局域网和广域网。从往全球性的 PKI 发展这个观点来看，证书格式和信任机制以开放和可伸缩的方式定义，但可根据特定客户和应用环境的信任和政策需求制定相应的使用框架 (Usage Profile) 。例如，通常可以接受在全球性的 PKI 中有多个“根”或“顶级”证书授权中心，而非只是一个“根”，尽管在本地 ( 局部 )PKI 中只能有一个根。相应的，协议可被定义为按规定为给定应用或用户提定根。 There is no single pervasive public-key infrastructure today, though efforts to define a PKI generally presume there will eventually be one, or, increasingly, that multiple independent PKIs will evolve with varying degrees of coexistence and interoperability. In this sense, the PKI today can be viewed akin to local and wide-area networks in the 1980's, before there was widespread connectivity via the Internet. As a result of this view toward a global PKI, certificate formats and trust mechanisms are defined in an open and scaleable manner, but with usage profiles corresponding to trust and policy requirements of particular customer and application environments. For instance, it is usually accepted that there will be multiple ``root'' or ``top-level'' certificate authorities in a global PKI, not just one ``root,'' although in a local PKI there may be only one root. Accordingly, protocols are defined with provision for specifying which roots are trusted by a given application or user. 今天定义 PKI 的努力在几个政府和标准化组织中进行。美国财政部和 NIST 都有 PKI 项目，在加拿大和英国也一样。 NIST 发布了 PKI 构件互操作性的描述；它指定了证书授权机构需支持的算法和证书格式。另外一些有 PKI 工作项目的标准化团体包括 IETF 中的 PKIX 和 SPKI 工作组和 TOG(The Open Group) 。 Efforts to define a PKI today are underway in several governments as well as standards organizations. The U.S. Department of the Treasury and NIST both have PKI programs [2,3], as do Canada  and the United Kingdom . NIST has published an interoperability profile for PKI components [BDN97]; it specifies algorithms and certificate formats that certification authorities should support. Some standards bodies which have worked on PKI aspects have included the IETF's PKIX and SPKI working groups [6,7] and The Open Group . Most PKI definitions are based on X.509 certificates, with the notable exception of the IETF's SPKI. URL ： http://www.rsasecurity.com/rsalabs/faq/4-1-3-1.html
为什么需要数字证书与第三方认证 2. 对 PGP 来说公匙本来就要公开，就没有防监听的问题。但公匙的发布中仍然存在安全性问题，例如公匙的被篡改 (Public Key Tampering) ，这可能是公匙密码体系中最大的漏洞，因为大多数新手不能很快发现这一点。你必须确信你拿到的公匙属于它看上去属于的那个人。为了把这个问题说清楚，我举个例子，然后再说如何正确地用 PGP 堵住这个漏洞。 以你和 Alice 的通信为例，假设你想给 Alice 发封信，那你必须有 Alice 的公匙，你从 BBS 上下载了 Alice 的公匙，并用它加密了信件用 BBS 的 Email 功能发给了 Alice 。不幸地，你和 Alice 都不知道，另一个用户叫 Charlie 的用户潜入 BBS ，把他自己用 Alice 的名字生成的密匙对中的公匙替换了 Alice 的公匙。那你用来发信的公匙就不是 Alice 的而是 Charlie 的，一切看来都很正常，因为你拿到的公匙的用户名是“ Alice” 。于是 Charlie 就可以用他手中的私匙来解密你给 Alice 的信，甚至他还可以用 Alice 真正的公匙来转发你给 Alice 的信，这样谁都不会起疑心，他如果想改动你给 Alice 的信也没问题。更有甚者，他还可以伪造 Alice 的签名给你或其他人发信，因为你们手中的公匙是伪造的，你们会以为真是 Alice 的来信。 防止这种情况出现的最好办法是避免让任何其他人有机会篡改公匙，比如直接从 Alice 手中得到她的公匙，然而当她在千里之外或无法见到时，这是很困难的。 PGP 发展了一种公匙介绍机制来解决这个问题。举例来说：如果你和 Alice 有一个共同的朋友 David ，而 David 知道他手中的 Alice 的公匙是正确的（关于如何认证公匙， PGP 还有一种方法，后面会谈到，这里假设 David 已经和 Alice 认证过她的公匙）。这样 David 可以用他自己的私匙在 Alice 的公匙上签名（就是用上面讲的签名方法），表示他担保这个公匙属于 Alice 。当然你需要用 David 的公匙来校验他给你的 Alice 的公匙，同样 David 也可以向 Alice 认证你的公匙，这样 David 就成为你和 Alice 之间的“介绍人”。这样 Alice 或 David 就可以放心地把 David 签过字的 Alice 的公匙上载到 BBS 上让你去拿，没人可能去篡改它而不被你发现，即使是 BBS 的管理员。这就是从公共渠道传递公匙的安全手段。 有人会问：那你怎么安全地得到 David 的公匙呢，这不是个先有鸡还是先有蛋的问题吗？确实有可能你拿到的 David 的公匙也是假的，但这就要求这个捣蛋者参与这整个过程，他必须对你们三人都很熟悉，还要策划很久，这一般不可能。当然， PGP 对这种可能也有预防的建议，那就是由一个大家普遍信任的人或机构担当这个角色。他被称为“密匙侍者”或“认证权威”，每个由他签字的公匙都被认为是真的，这样大家只要有一份他的公匙就行了，认证这个人的公匙是方便的，因为他广泛提供这个服务，假冒他的公匙是很极困难的，因为他的公匙流传广泛。这样的“权威”适合由非个人控制组织或政府机构充当，现在已经有等级认证制度的机构存在。 对于那些非常分散的人们， PGP 更赞成使用私人方式的密匙转介方式，因为这样有机的非官方更能反映出人们自然的社会交往，而且人们也能自由地选择信任的人来介绍。总之和不认识的人们见面一样。每个公匙有至少一个“用户名” (User ID) ，请尽量用自己的全名，最好再加上本人的 Email 地址，以免混淆。 注意！你所必须遵循的一条规则是：在你使用任何一个公匙之前，一定要首先认证它！！！无论你受到什么诱惑，当然会有这种诱惑，你都不要，绝对不要，直接信任一个从公共渠道（由其是那些看起来保密的）得来的公匙，记得要用熟人介绍的公匙，或者自己与对方亲自认证。同样你也不要随便为别人签字认证他们的公匙，就和你在现实生活中一样，家里的房门钥匙你是只会交给信任的人的。
参阅海南出版社《密码故事》，朱小篷、林金钟译 2. 密码学与隐写术 － 信息保密的两种途径 密码学 (Cryptography) － 不是隐藏信息本身，而是要隐藏它的意思 隐写术 (Staganography) － 通过把信息隐藏起来的秘密通信。 3. 分组密码 (block cipher) 与流密码 (stream cipher). 4. 文献记载最早使用的加密术是在公元前 1900 年的埃及：一个书记员在一幅题字中使用了非标准的象形文字； 公元前 1500 年的美索不达米亚文字匾中含有一个制造陶瓷釉的秘方； 公元前 500 － 600 年的希伯来人的 ATBASH 密码； 公元前 486 年希腊人的 skytale ，以及 Julius Caesar 的简单的置换密码等； 摘自 吴世忠、马芳译的《网络信息安全的真相》 ( 原书为《 Secrets and Lies: Digital Security in a Networked World 》，作者为 Bruce Schneier)
1. 直到 20 世纪 70 年代中期，人们使用的仍然全是传统密码学 － 对称密码学 .
1.1973 年 5 月 15 日， NBS( 国家标准局，后来的 NIST) 在 Federal Register 上，发布了公开征集标准密码算法的请求，他们确定了一系列的设计准则： * 算法必须提供较高的安全性； * 算法必须完全确定且易于理解； * 算法的安全性必须依赖于密钥，而不应依赖于算法； * 算法必须对所有用户都用效； * 算法必须适用于各种应用； * 用以实现算法的电子器件必须很经济； * 算法必须能有效使用； * 算法必须能验证； * 算法必须能出口； 2. 1976 年 11 月 23 日 DES 被采纳为联邦标准，并授权在非密级的政府通信中使用。 FIPS PUB 46 - DES 的正式文本，于 1977 年 1 月 15 日公布，并在 6 个月后生效； FIPS PUB 81 - DES 工作方式 ( 模式 ) ，于 1980 年公布； FIPS PUB 74 – 实现和使用 DES 的指南，于 1981 年公布； 此外， FIPS PUB 112 指定 DES 用作口令加密， FIPS PUB 113 指定 DES 用作计算机数据鉴别 3. DES Challenge http://www.eff.org/descracker.html
1. Xuejia Lai 和 James Massey 于 1990 年公布了 IDEA 密码算法第一版，它被称做 PES (Proposed Encryption Standard, 推荐加密标准 ) 。在 Biham 和 Shamir 演示了差分密码分析之后，第二年设计者为对抗此攻击，增加了密码算法的强度，他们把新算法称之为 IPES (Improved Proposed Encryption Standard ，改进型推荐加密标准 ) 。 IPES 在 1992 年又改名为 IDEA (International Data Encryption Algorithm ，国际数据加密标准 ) 。
1. RC2 是 Ron Rivest 为 RSA 公司设计的变长密钥加密算法，其分组长度为 64bit ，虽然“ RC” 正式的说法是“ Rivest Cipher” ，但实际上，它示” Ron’s Code“ 。 2. RC3 在开发过程中在 RSADSI 被攻破了； RC1 除了在 Rivest 的记事本上外，从未公开过； 3. RC4 是 Ron Rivest 在 1987 年为 RSA 数据安全公司开发的变长密钥的序列密码，在开始的 7 年中它有专利，算法的细节仅在签署一个保密协议后才能得到； 1994 年 9 月，有人把它的源代码匿名贴到 Cyberpunk 邮件列表中，该代码迅速被传到 Usenet 新闻组 sci.crypt 中，并且通过互联网传到了全球的许多的 ftp 站 . 美国政府已允许 RC2 、 RC4 产品出口，但密钥限制为 <=40bit 。 5. RC5 是由 RSA 公司的 Rivest 于 1994 年设计的一种新型的分组密码算法。它是一种分组长、密钥长和迭代轮数都可变的分组迭代密码算法，一个特定的 RC5 表示为 RC5-w/r/b ，其中 w 是以比特表示的字 (word) 的尺寸 (w=16, 32, 64) ， r 是轮数 (0<=r<=255) ， b 是密钥的字节 (byte) 长度 (0<=b<=255) 。 RC5 有两个字长 (2w) 的输入和输出。 6. RSA Laboratories Secret-Key Challenge – Status and Prizes The current status each of the contests in the RSA Security Secret-Key Challenge is as follows: contest prize start end DES $10,000 28 January 1997, 9 am 17 June 1997, 10:40 pm PST RC5-32/12/5 $1,000 28 January 1997, 9 am 28 January 1997, 12:30 pm PST RC5-32/12/6 $5,000 28 January 1997, 9 am 10 February 1997, 10:00 am PST RC5-32/12/7 $10,000 28 January 1997, 9 am 20 October 1997,11:18 am PST RC5-32/12/8 $10,000 28 January 1997, 9 am RC5-32/12/9 $10,000 28 January 1997, 9 am RC5-32/12/10 $10,000 28 January 1997, 9 am RC5-32/12/11 $10,000 28 January 1997, 9 am RC5-32/12/12 $10,000 28 January 1997, 9 am RC5-32/12/13 $10,000 28 January 1997, 9 am RC5-32/12/14 $10,000 28 January 1997, 9 am RC5-32/12/15 $10,000 28 January 1997, 9 am RC5-32/12/16
1. 1997 年 1 月 2 日， NIST 发起 AES 开发活动，并于 9 月 12 日形成了正式的征集活动 - AES (Advanced Encryption Standard) ，并专门成立了 AES 工作组，目的是为了确定一非保密的、公开披露的、全球免费使用的分组密码算法，用于保护下一代政府的敏感信息，也希望能够成为秘密的和公开部门的数据加密标准 (DES) 。 1997 年 9 月 12 日在 Federal Register 公布了征集 AES 候选算法的通告。 AES 的基本要求比三重 DES 快而且至少和三重 DES 一样安全，分组长度为 128 bit ，密钥长度为 128/192/256 bit 。 1998 年 8 月 20 日 NIST 召开了第一次 AES 候选会议，并公布了 15 个 AES 候选算法。 1999 年 3 月 22 日举行第二次 AES 候选会议，公开 15 个候选算法的讨论结果。关于算法的讨论于 1999 年 4 月 15 日结束，从 15 个中选出 5 个。 NIST 从这 5 个算法选取一个做为 AES 。 2000 年 4 月 13 、 14 日在 New York 举行了 AES 第三次候选大会， NIST 听取来自全球的 200 多个密码研究团体的建议。 2000 年 10 月 2 日， NIST 宣布选定 Rijndael 做为 AES 的建议标准。 2. 5 个最后的候选算法分别是： MARS, submitted by International Business Machines Corporation (U.S.) ； RC6, submitted by RSA Laboratories (U.S.) ； Rijndael, submitted by Joan Daemen and Vincent Rijmen (Belgium) ； Serpent, submitted by Ross Anderson (U.K.), Eli Biham (Israel), and Lars Knudsen (Norway) ； Twofish, submitted by Bruce Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall and Niels Ferguson (U.S.) ； 3. The Home Page is: http://csrc.nist.gov/encryption/aes/ 4. Rijndael 算法的原型是 Square 算法，其设计策略是宽轨迹策略 (Wide Trail Strategy) 。这种策略是针对差分分析和线性分析提出的。 Rijndael 是一个迭代分组密码，其分组长度和密钥长度都是可变的，但是为了满足 AES 的要求，分组长度为 128bit ，密码长度为 128/192/256bit ，相应的轮数 r 为 10/12/14 。
在英国政府的政府通信总部工作的 Ellis(1970), Cocks(1973) 和 Williamson(1974,1975) 也独立地完成的 PKC 的发明。 公钥密码学使用了一对密钥 – 加密密钥和解密密钥，且从解密密钥推出加密密钥是不可行的； 2. 公钥密码学解决了密钥分发问题； 3. Bob 给 Alice 发信 Alice 对外发放许多带锁的空盒子 ( 只有 Alice 一个人拥有此锁的钥匙 ) ， Bob 找到这样一个盒子，将信息放进去，然后将锁锁上，并将上锁后的盒子寄给 Alice ，由于只能 Alice 有相应的钥匙，所以只有 Alice 才可以打开盒子读取里面的信息。 4. 一个误解是公开密钥加密在防范密码分析上比常规加密更安全。事实上，任何加密方案的安全程度都依赖于密钥的长度和破译密码所包含的计算工作量。从抗击密码分析的角度讲，无论常规还是公开密钥原则上都没有比对方优越的地方。 5. 另一个误解是公开密钥是一个使得常规加密已经过时的通用技术。相反，由于当前公开密钥加密在计算上的巨大开销，在可以预见的将来常规加密并不会被抛弃。 Diffie 曾说过：大家几乎普遍接受的观点是公开密钥编码学的使用只限于密钥管理和数字签名等应用。 6. 最后，有一个感觉是与使用常规加密涉及密钥分配中心的相当繁琐的握手过程相比，使用公开密钥加密后密钥分配就变得非常简单。事实上，仍然需要某种形式的协议，一般这会涉及到一个中心代理，而且整个过程比常规加密中的过程既不更简单也不更有效。
在本章中，先介绍一下 PKI 的构件组成，再谈一谈 PKI 中各构件的关系， PKI 运作与 CPS 的关系，最后谈一谈 PMI 与 TSA. 1. Functions of a PKI This section describes the major functions of a PKI. In some cases, PKIs may provide extra functions. 1.1 Registration This is the process whereby a subject first makes itself known to a CA (directly, or through an RA), prior to that CA issuing a PKC or PKCs for that subject. Registration involves the subject providing its name (e.g., common name, fully-qualified domain name, IP address), and other attributes to be put in the PKC, followed by the CA (possibly with help from the RA) verifying in accordance with its Certification Practice Statement (CPS) that the name and other attributes are correct. 1.2 Initialization Initialization is when the subject (e.g., the user or client system) gets the values needed to begin communicating with the PKI. For example, initialization can involve providing the client system with the public key or PKC of a CA, or generating the client system's own public-private key pair. 1.3 Certification This is the process in which a CA issues a PKC for a subject's public key, and returns that PKC to the subject or posts that PKC in a repository. 1.4 Key Pair Recovery In some implementations, key exchange or encryption keys will be required by local policy to be &quot;backed up,&quot; or recoverable in case the key is lost and access to previously-encrypted information is needed. Such implementations can include those where the private key exchange key is stored on a hardware token which can be lost or broken, or when a private key file is protected by a password which can be forgotten. Often, a company is concerned about being able to read mail encrypted by or for a particular employee when that employee is no longer available because she is ill or no longer works for the company. In these cases, the user's private key can be backed up by a CA or by a separate key backup system. If a user or her employer needs to recover these backed up key materials, the PKI must provide a system that permits the recovery without providing an unacceptable risk of compromise of the private key. 1.5 Key Generation Depending on the CA's policy, the private-public key pair can either be generated by the user in his local environment, or generated by the CA. In the latter case, the key material may be distributed to the user in an encrypted file or on a physical token (e.g., a smart card or PCMCIA card). 1.6 Key Update All key pairs need to be updated regularly (i.e., replaced with a new key pair) and new PKCs issued. This will happen in two cases: normally, when a key has passed its maximum usable lifetime; and exceptionally, when a key has been compromised and must be replaced. 1.6.1 Key Expiry In the normal case, a PKI needs to provide a facility to gracefully transition from a PKC with an existing key to a new PKC with a new key. This is particularly true when the key to be updated is that of a CA. Users will know in advance that the key will expire on a certain date; the PKI, working together with PKC-using applications, should allow for appropriate keys to work before and after the transition. There are a number of ways to do this; see [CMP] for an example of one. 1.6.2 Key Compromise In the case of a key compromise, the transition will not be &quot;graceful&quot; in that there will be an unplanned switch of PKCs and keys; users will not have known in advance what was about to happen. Still, the PKI must support the ability to declare that the previous PKC is now invalid and shall not be used, and to announce the validity and availability of the new PKC. Note: compromise of a private key associated with a Root CA is catastrophic for users relying on that Root CA. If a Root CA's private key is compromised, that CA's PKC must be revoked and all PKCs subordinate to it must also be revoked. Until such time as the Root CA has been issued a new PKC and the Root CA issues PKCs to users relying upon it, users relying on that Root CA are cut off from the rest of the system, as there is no way to develop a valid certification path back to a trusted node. Further, users will likely have to be notified by out-of-band mechanisms about the change in CA keys. If the old key is compromised, any &quot;update&quot; message telling subordinates to switch to a new key could have come from an attacker in possession of the old key, and could point to a new public key for which the attacker already has the private key. It is possible to have anticipated this event, and &quot;pre-placed&quot; replacement Root CA keys with all relying parties, but some secure, out-of-band mechanism will have to be used to tell users to make the switch, and this will only help if the replacement key has not been compromised. Additionally, once the Root CA is brought back up with a new key, it will likely be necessary to re-issue PKCs, signed with the new key, to all subordinate users, since their current PKC would be signed with a now-revoked key. 1.7 Cross-certification A cross-certificate is a PKC issued by one CA to another CA which contains a public CA key associated with the private CA signature key used for issuing PKCs. Typically, a cross-certificate is used to allow client systems orend entities in one administrative domain to communicate securely with client systems or end users in another administrative domain. Use of a cross-certificate issued from CA_1 to CA_2 allows user Alice, who trusts CA_1, to accept a PKC used by Bob, which was issued by CA_2. Cross-certificates can also be issued from one CA to another CA in the same administrative domain, if required. Cross-certificates can be issued in only one direction, or in both directions, between two CA's. That is, just because CA_1 issues a cross-certificate for CA_2, CA_2 does not have to issue a cross-certificate for CA_1. 1.8 Revocation When a PKC is issued, it is expected to be in use for its entire validity period. However, various circumstances may cause a PKC to become invalid prior to the expiration of the validity period. Such circumstances include change of name, change of association between subject and CA (e.g., an employee terminates employment with an organization), and compromise or suspected compromise of the corresponding private key. Under such circumstances, the CA needs to revoke the PKC. X.509 defines one method of PKC revocation. This method involves each CA periodically issuing a signed data structure called a certificate revocation list (CRL). A CRL is a time stamped list identifying revoked PKCs which is signed by a CA and made freely available in a public repository. Each revoked PKC is identified in a CRL by its PKC serial number. When a certificate-using system uses a PKC, that system not only checks the PKC signature and validity but also acquires a suitably-recent CRL and checks that the PKC serial number is not on that CRL. The meaning of &quot;suitably-recent&quot; may vary with local policy, but it usually means the most recently-issued CRL. A CA issues a new CRL on a regular periodic basis (e.g., hourly, daily, or weekly). CA's may also issue CRLs aperiodically. For example, if an important key is deemed compromised, the CA may issue a new CRL to expedite notification of that fact, even if the next CRL does not have to be issued for some time. (A problem of aperiodic CRL issuance is that end-entities may not know that a new CRL has been issued, and thus may not retrieve it from a repository.) An entry is added to the CRL as part of the next update following notification of revocation. An entry may be removed from the CRL after appearing on one regularly scheduled CRL issued beyond the revoked PKC's validity period. Leaving the revoked PKC on the CRL for this extra period allows for PKCs that are revoked prior to issuing a new CRL and whose invalidity date falls before the CRL issuing time to be accounted for. If the revoked PKC is not retained on the CRL for this extra period then the possibility arises that a revoked PKC may never appear on a CRL. An advantage of the CRL revocation method is that CRLs may be distributed by exactly the same means as PKCs themselves, namely, via untrusted communications and server systems. One limitation of the CRL revocation method, using untrusted communications and servers, is that the time granularity of revocation is limited to the CRL issue period. For example, if a revocation is reported now, that revocation will not be reliably notified to certificate-using systems until the next CRL is issued - this may be up to one hour, one day, or one week depending on the frequency that the CA issues CRLs. As with the X.509 v3 PKC format, in order to facilitate interoperable implementations from multiple vendors, the X.509 v2 CRL format needed to be profiled for Internet use. This was done as part of [FORMAT]. However, PKIX does not require CAs to issue CRLs. On-line methods of revocation notification may be applicable in some environments as an alternative to the X.509 CRL. PKIX defines a protocol known as OCSP to facilitate on-line checking of the status of PKCs [OCSP]. On-line revocation checking may significantly reduce the latency between a revocation report and the distribution of the information to relying parties. Once the CA accepts the report as authentic and valid, any query to the on-line service will correctly reflect the PKC validation impacts of the revocation. However, these methods impose new security requirements; the PKC validator must trust the on-line validation service while the repository does not need to be trusted. 1.9 Certificate and Revocation Notice Distribution and Publication As alluded to in sections 3.1 and 3.5.8 above, the PKI is responsible for the distribution of PKCs and PKC revocation notices (whether in CRL form or in some other form) in the system. &quot;Distribution&quot; of PKCs includes transmission of the PKC to its owner, and may also include publication of the PKC in a repository. &quot;Distribution&quot; of revocation notices may involve posting CRLs in a repository, transmitting them to end-entities, or forwarding them to on-line responders.
1. Public Key Infrastructure (PKI) - The set of hardware, software, people, policies and procedures needed to create, manage, store, distribute, and revoke PKCs based on public-key cryptography. Certificate - Can refer to either an AC or a public key certificate. Where there is no distinction made the context should be assumed to apply to both an AC and a public key certificate. 2. PKI 的安全策略
1. 介绍一个三者的定义，以及它们的逻辑关系 2. CA is a trusted authority that is responsible for creating, distributing and revoking digital certificate. RAs are used to enroll new users into a PKI. 3. 术语 Certification Authority (CA) - An authority trusted by one or more users to create and assign public key certificates. Optionally the CA may create the user's keys. It is important to note that the CA is responsible for the public key certificates during their whole lifetime, not just for issuing them. Certificate Policy (CP) - A named set of rules that indicates the applicability of a public key certificate to a particular community or class of application with common security requirements. For example, a particular certificate policy might indicate applicability of a type of public key certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range. End-entity - A subject of a certificate who is not a CA in the PKIC or an AA in the PMI. (An EE from the PKI can be an AA in the PMI.) 终端实体 -- 证书的主题 ( 此证书既非 PKIC 中的 CA ，也非 PMI 中的 AA 的证书 ) Public Key Certificate (PKC) - A data structure containing the public key of an end-entity and some other information, which is digitally signed with the private key of the CA which issued it. Public Key Infrastructure (PKI) - The set of hardware, software, people, policies and procedures needed to create, manage, store, distribute, and revoke PKCs based on public-key cryptography. Registration Authority (RA) - An optional entity given responsibility for performing some of the administrative tasks necessary in the registration of subjects, such as: confirming the subject's identity; validating that the subject is entitled to have the values requested in a PKC; and verifying that the subject has possession of the private key associated with the public key requested for a PKC. Relying party - A user or agent (e.g., a client or server) who relies on the data in a certificate in making decisions. 依赖方 / 依托方 -- 依赖证书中的数据做决策的用户或代理。 Root CA - A CA that is directly trusted by an EE; that is, securely acquiring the value of a Root CA public key requires some out-of-band step(s). This term is not meant to imply that a Root CA is necessarily at the top of any hierarchy, simply that the CA in question is trusted directly. Subordinate CA - A &quot;subordinate CA&quot; is one that is not a Root CA for the EE in question. Often, a subordinate CA will not be a Root CA for any entity but this is not mandatory. Subject - A subject is the entity (AA, CA, or EE) named in a certificate. Subjects can be human users, computers (as represented by Domain Name Service (DNS) names or Internet Protocol (IP) addresses), or even software agents. 主题 -- 主题是指在证书命名的实体 (AA, CA 或 EE) 。主题可以是人，计算机 ( 由 DNS 或 IP 地址表示 ) ，甚至是软件代理。 Top CA - A CA that is at the top of a PKI hierarchy. Note: This is often also called a &quot;Root CA,&quot; since in data structures terms and in graph theory, the node at the top of a tree is the &quot;root.&quot; However, to minimize confusion in this document, we elect to call this node a &quot;Top CA,&quot; and reserve &quot;Root CA&quot; for the CA directly trusted by the EE. Readers new to PKIX should be aware that these terms are not used consistently throughout the PKIX documents, as [FORMAT] uses &quot;Root CA&quot; to refer to what this and other documents call a &quot;Top CA,&quot; and &quot;most-trusted CA&quot; to refer to what this and other documents call a &quot;Root CA.“ 4. PKI Entities: +---+ | C | +------------+ | e | <-------------------->| End entity | | r | Operational +------------+ | t | transactions ^ | | and management | Management | / | transactions | transactions | | | PKI users | C | v | R | -----------------+------+------------+---------------- | L | ^ ^ | | | | PKI management | | v | entities | R | +------+ | | e | <---------------------| RA | --+ | | p | Publish +------+ | | | o | certificate | | | s | | | | I | v v | t | +------------+ | o | <---------------------------------| CA | | r | Publish certificate +------------+ | y | Publish CRL ^ | | | +---+ Management | transactions | v +------+ | CA | +------+
A PKI consists of five types of components [MISPC]: - Certification Authorities (CAs) that issue and revoke PKCs; - Organizational Registration Authorities (ORAs) that vouch for the binding between public keys and certificate holder identities and other attributes; - Certificate holders that are issued certificates and can sign digital documents and encrypt documents; - Clients that validate digital signatures and their certification paths from a known public key of a trusted CA; - Repositories that store and make available certificates and Certificate Revocation Lists (CRLs).
1. Certification Practice Statement (CPS) - A statement of the practices which a CA employs in issuing public key certificates. CPS ，是 CA 在发行公钥证书时使用的实践 ( 惯例 ) 的声明。 2. VeriSign CPS V1.2 中文版目录 1 ： 前言 2 ： VeriSign 認證基礎建設 3 ： 憑證制度運作之基礎 4 ： 憑證申請程序 5 ： 憑證申請書之確認 6 ： 憑證之簽發 7 ： 用戶同意接受憑證 8 ： 憑證之使用 9 ： 憑證之中止與廢止 10 ： 憑證期效 11 ： 簽發管理中心與 VERISIGN 之義務，以及該義務之限制 12 ： 雜項條款 13 ： 附錄
1. Privilege Management Infrastructure (PMI) - A collection of ACs, with their issuing AA's, subjects, relying parties, and repositories, is referred to as a Privilege Management Infrastructure. The TSA is a TTP that creates time stamp tokens in order to indicate that a datum existed at a particular point in time 2.Many systems use the PKC to perform identity based access control decisions (i.e., the identity may be used to support identity-based access control decisions after the client proves that it has access to the private key that corresponds to the public key contained in the PKC). For many systems this is sufficient, but increasingly systems are beginning to find that rule-based, role-based, and rank-based access control is required. These forms of access control decisions require additional information that is normally not included in a PKC, because the lifetime of the information is much shorter than the lifetime of the public-private key pair. To support binding this information to a PKC the Attribute Certificate (AC) was defined in ANSI and later incorporated into ITU-T Recommendation X.509. The AC format allows any additional information to be bound to a PKC by including, in a digitally signed data structure, a reference back to one specific PKC or to multiple PKCs, useful when the subject has the same identity in multiple PKCs. Additionally, the AC can be constructed in such a way that it is only useful at one or more particular targets (e.g., web server, mail host). Users of a PMI must be confident that the identity purporting to posess an attribute has the right to possess that attribute. This confidence may be obtained through the use of PKCs or it may be configured in the AC-using system. If PKCs are used the party making the access control decision can determine &quot;if the AC issuer is trusted to issue ACs containing this attribute.&quot;
本章主要介绍 PKI 实施中涉及到的一些实际问题。如各 CA 间的互操作性，验证证书时的协议实现 (CRL or OCSP) - 客户端应用与 CA 之间的配合，这涉及到各个 PKI 厂商的专用实现。
这里是指广义的数字证书， X.509 只是其一个特例 1 RSA 证书， DH/DSA 证书的实现； 2. Public Key Certificate (PKC) - A data structure containing the public key of an end-entity and some other information, which is digitally signed with the private key of the CA which issued it. A certificate is a document, issued by a trusted agent, stating that the public key of the person named in the document has a certain value. 3. Different Digital Certificate Formats: X.509 , the identity certificate from the X.500 effort, with an attribute certificate added recently (perhaps borrowed from X9) PGP , an identity certificate format, the first to gain widespread usage and the form supporting the well known Web of Trust X9.59 (also known as AADS) is a mechanism that uses ACLs only, instead of certificates. Specifically, the ACL is a bank's account database that has had a public-key field added, so that the bank can look up the account-holder's public key. This makes the X9.59 ACL an authorization instrument, in SPKI terms, similar to the ACL implemented by SSH's file: .ssh/authorized_keys. For more information on X9.59, see: http://www.garlic.com/~lynn Others , such as: Blaze, Feigenbaum and Lacy trust management forms (computing authorization with certified code) PolicyMaker KeyNote 4. In general, the certificate provides a statement by a trusted third party (eg. Issuer Authority or Certificate Authority or a person) that the signed key is authentic and truly belongs to the entity who claims it. The term certificate was proposed for the first time in 1978 by Loren M. Kohnfelder in his bachelor thesis at MIT. Since then, the concept of certificate has evolved to act as a token of trust to participate the process of authentication, authorisation, and authority delegation. A certificate contains a range of information, which varies between the different trust models: information about an entity (or non-entity): email address, public key and/or permission/credential. information about a certificate issuer: issuer-signature (created using the issuer's private key), issuer-public-key. information about the certificate itself: date and time of certificate issue, certificate-serial-number, validity-period, certificate-fingerprint. extra information: version certificate, Certificate Revocation List (CRL) version, class and type of the certificate and comments.
1. 在考虑证书的有效性或者可用性时除了简单的完整性检查还需要其它的机制。 证书验证包括确定以下内容： * 一个可信的 CA 已经在证书上签名 ( 即 CA 的数字签名被验证是正确的 ) 。注意这可能包括证书路径处理； * 证书有良好的完整性；即证书上的数字签名与签名者的公钥和单独计算出来的证书杂凑值一致； * 证书处在有效期内 ( 由证书中的 Not Valid Before 和 Not Valid After 两个参数来限定有效期 ) ； * 证书没有被吊销； * 证书的使用方式与任何声明的策略和 / 或使用限制相一致 ( 这由特殊的扩展来限定 ) 2. 关于综合密钥 / 证书生命周期管理的基本假设如下： * 密钥和证书生命周期的终端实体管理是不实际的； * 密钥 / 证书生命周期管理必须尽可能自动完成； * 密钥 / 证书生命周期管理必须尽可能对终端实体是不显眼的。 * 综合密钥 / 证书生命周期管理要求安全的运作和可信实体如： RA 、 CA 以及必要时这些部件相互作用的客户端软件等的合作。
VeriSign CPS 敘述之認證過程，有如一個生命週期。首先成立簽發管理中心並開始運作，並涵蓋簽發管理中心一般的作業與 註冊 ；及憑證之使用、中止、廢止與期滿。此種方式之優點，在於以時間先後之次序排列，且與目前公私立機構所採行之實作準則相容。 CA certification authority ，憑證管理中心 CK common key ，一般金鑰 CPS VeriSign Certification Practice Statement 憑證實作準則 CRL certificate revocation list 憑證廢止清冊 CSR certificate signing request 憑證簽章要求 DAM draft amendment (to an ISO standard) 擬稿修正條文 ( 符合國際標準組織 ISO 的標準 ) FIPS Federal Information Processing Standard 聯邦資料處理標準 FTP File Transfer Protocol 檔案傳輸協定 GMT Greenwich Mean Time 格林威治標準時間 HTTP Hypertext Transfer Protocol 超文字傳輸協定 HTTPS Hypertext Transfer Protocol with SSL 採用 SSL 的超文字傳輸協定 IA issuing authority 簽發管理中心 LRA local registration authority 地方註冊管理中心 LRAA local registration authority administrator 地方註冊管理中心主管 NSI nonverified subscriber information 未經證實之用戶資料 PCA VeriSign public primary certification authority 主要憑證管理中心 PCS VeriSign‘s public certification services VeriSign 公共憑證服務 PIN personal identification number 個人識別密碼 PKCS Public Key Cryptography 公開金鑰密碼法 標準 PKI public key infrastructure 公開金鑰基礎建設 RDN Relative Distinguished Name 易於辨識之名稱 RSA 一種 cryptographic system 密碼系統 ( 請見 定義 ) SET Secure Electronic Transaction 安全電子交易 S/MIME Secure Multipurpose Internet Mail Extensions 安全多用途網際信件延伸格式 SSL Secure Sockets Layer URL uniform resource locator 單一資源位址 VDPE VeriSign Distinguished Panel of Experts VeriSign 傑出的專家小組 VR VeriSign root VeriSign 根節點 VSP VeriSign Security Procedures VeriSign 保全程序 WWW or Web World Wide Web 全球資訊網 X.509 the ITU-T standard for certificates and their corresponding authentication framework 一種由 ITU-T （ International Telecommunication Union-T ；國際電訊聯盟）所發佈之憑證標準 以及對應的鑑別架構
1. 关于交叉认证的所用到的信任模型，可以参阅 RSA Labs 的 John Linn 于 2000 年 11 月写的论文《 Trust Models and Management in Public-Key Infrastructures 》， .pdf 文档在 ftp://ftp.rsasecurity.com/pub/pdfs/PKIPaper.pdf 。
1. Profiles A profile of the X.509 v3 PKC specification is a description of the contents of the PKC and which extensions must be supported, which extensions may be supported, and which extensions may not be supported. Internet X.509 Public Key Infrastructure Certificate and CRL Profile (RFC 2459) 2. Operational Protocols Operational protocols are required to deliver certificates and CRLs (or other certificate status information) to certificate using systems. Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP (RFC 2585) Internet X.509 Public Key Infrastructure Online Certificate Status Protocol - OCSP (RFC 2560) Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 (RFC 2559) Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv3, <draft-ietf-pkix-ldap-v3-0x.txt> Limited AttributeCertificate Acquisition Protocol, <draft-ietf-pkix-laap-0x.txt> Diffie-Hellman Proof-of-Possession Algorithms, <draft-ietf-pkix-dhpop-0x.txt> 3. Management Protocols Management protocols are required to support on-line interactions between PKI user and management entities. There are two parts to a &quot;management protocol.&quot; The first is the format of the messages that will be sent, and the second is the actual protocol that governs the transmission of those messages. Internet X.509 Certificate Request Message Format (RFC 2511) Internet X.509 Public Key Infrastructure Certificate Management Protocols (RFC 2510) Certificate Management Messages over CMS (RFC 2797) Using HTTP as a Transport Protocol for CMP, <draft-ietf-pkix-cmp-http-0x.txt> Using TCP as a Transport Protocol for CMP, <draft-ietf-pkix-cmp-tcp-0x.txt 4. Policy Outline As mentioned before, profiling certificates and specifying operational and management protocols only addresses a part of the problem of actually developing and implementing a secure PKI. What is also needed is the development of a certificate policy (CP) and certification practice statement (CPS), and then following those documents. The CP and CPS should address physical and personnel security, subject identification requirements, revocation policy, and a number of other topics. [POLPROC] provides a framework for certification practice statements. Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework (RFC 2527) 5. Time-Stamp, Data Verification, and Data Certification Services Time stamping is a service in which a trusted third party - a Time Stamp Authority, or TSA - signs a message, in order to provide evidence that it existed prior to a given time. TSP also defines the role of a Temporal Data Authority, or TDA. A TDA is a Trusted Third Party (TTP) that creates a temporal data token. This temporal data token associates a message with a particular event and provides supplementary evidence for the time included in the time stamp token. A DVCS is a Trusted Third Party that verifies the correctness of specific data submitted to it. It also allows the delegation of trustworthy servers and allows for chaining of verifications. Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP) (RFC 3161) Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols (RFC 3029)
1. MISPC, Minimum Interoperability Specifications for PKI Components NIST developed the Minimum Interoperability Specifications for PKI Components (MISPC), Version 1 with the assistance of ten CRADA partners: AT&T, BBN, Certicom, Cylink, DynCorp, IRE, Motorola, Nortel (Entrust), Spyrus, and Verisign. The specification includes a certificate and CRL profile, message formats and basic transactions for a PKI issuing signature certificates. The specification includes support for multiple signature algorithms and transactions to support a broad range of security policies. This document has been formally published as a NIST Special Publication 800-15; it is available electronically in Microsoft Word (284K) or PostScript (954K) . NIST has developed an updated specification with the help of CRADA partners to enhance the specification to support development of conforming PKI components. MISPC Version 2 is available for review and comment. The associated reference implementation is currently undergoing an upgrade and will be available second quarter of fiscal year 2001. 2. The PKI Forum is an international, not-for-profit, multi-vendor and end-user alliance whose purpose is to accelerate the adoption and use of Public-Key Infrastructure (PKI) products and services. The PKI Forum advocates industry cooperation and market awareness to enable organizations to understand and exploit the value of PKI in their e-business applications. Key objectives of the PKI Forum are to: * Accelerate the adoption and use of PKI as a critical enabler of e-business * Advocate industry cooperation in a vendor-neutral atmosphere * Enhance the value of PKI for customers and business partners * Increase confidence in deployment of PKI by customers and independent software vendors (ISVs)
1.CP ， Certificate Policy ； CPS ， Certification Practice Statement ； 2.CPS A certification practice statement (CPS) is a legal document, created and published by a CA, that explains the CA’s certificate issuance and revocation policies. People and organizations use the CA’s CPS to determine the level of trust they can place in a CA 3.Certificate Policy A certificate policy (CP) explains the conditions and limitations of use for a digital certificate. In other words, a CP defines the level of trust a user can place in someone else’s digital certificate. A CP can be embedded in or referenced in a digital certificate.
美国联邦政府的“证书策略建模” (MCS) 证书策略要比 CPS 处在更高的级别上，证书策略要考虑的是支持什么，而不是如何支持。 CPS 却是一个相当详细全面的技术和程序化的文档，它考虑的是支持基础设施的具体操作。 证书策略和 CPS 的角色 CPS – 认证惯例综述 1. CPS A certification practice statement (CPS) is a legal document, created and published by a CA, that explains the CA’s certificate issuance revcation policies. People and organizations use the CA’s CPS to determine the level of trust they can place in a CA. 2. Certificate Policy A certificate policy (CP) explains the conditions and limitions of use for a digital certificate. In other words, a CP defines the level of trust a use can place in someone else’s digital certificate. A CP can be embeded in or referenced in a digital certificate. 4. Liability and Other Legal Considerations Organizations should determine who assumes responsibility for losses if a PKI entity engages in or fails victim to fraud. For example, does the CA bear full responsibility for all losses? Or do members of the PKI share responsibility? After determining an organization’s legal rights and obligations, policies can be put in place to ensure that these responsibilities will be met.
1. SET 是开放的、设计用来保护 Internet 上信用卡交易的加密和安全规范。 IBM, Microsoft, Netscape, RSA, Terisa 和 VeriSign 都参加了规范的开发。 2. SET 本身不是一个支付系统。事实上，它是一个安全协议和格式的集合，使得用户可以以一种安全的方式，将已经存在的信用卡支付基础设施配置在开放网络，如 Internet 上。 3. 从本质上， SET 提供了三种服务： * 在交易涉及的各方之间提供安全的通信信道。 * 通过使用 X.509 v3 数字证书来提供信任。 * 保证机密性，因为信息只是在必要的时候、必要的地方才对交易各方可用。
1. Time stamping is a service in which a trusted third party - a Time Stamp Authority, or TSA - signs a message, in order to provide evidence that it existed prior to a given time. 2. TSP also defines the role of a Temporal Data Authority, or TDA. A TDA is a Trusted Third Party (TTP) that creates a temporal data token. This temporal data token associates a message with a particular event and provides supplementary evidence for the time included in the time stamp token. Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP) (RFC 3161)
DVCS – Data Validation and Certification Service A DVCS is a Trusted Third Party that verifies the correctness of specific data submitted to it. It also allows the delegation of trustworthy servers and allows for chaining of verifications. Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols (RFC 3029)
From: Kevin Wang Date: Tue Aug 8, 2000 10:29am Subject: Differences between Enterprise CA And Trade CA Hi, all: The following is someone told to me the differences between Enterprise CA and Trade CA , I think it is helpful. Enterprise CA is a model that your company hold everything of PKI including CA, RA, Directory Server etc. The best vendor on this is Entrust and Baltimore. RSA Security Inc. can provide this product too. In China, InfoSec, JIT, Koal and NetFront can provide Enterprise CA products. The Trade CA is another model that a trusted third party (offten are PKI vendors) will manage every thing for you, but maybe you can control the user enrollment process. The dominant vendor is Verisign. In China, CFCA (China Financial CA), CTCA (China Telecom CA) belong to Trade CA. The selection between them will base on a lot things, such as trust relationship, the control you have on the end users etc. You can surf these vendors' website and get more informaiton. http://www.infosec.com.cn/ http://www.jit.com.cn/ http://www.koal.com/ http://www.netfront.com.cn/ http://www.netfront.com/ http://www.rsasecurity.com/ http://www.verisign.com/ http://www.entrust.com/ http://www.baltimore.com/ http://www.openca.org/
1. OpenCA Project (http://www.openca.org/) The OpenCA Project is a collaborative effort to develop a robust, full-featured and Open Source out-of-the-box Certification Authority implementing the most used protocols with full-strength cryptography world-wide. OpenCA is based on many Open-Source Projects. Among the supported software is OpenLDAP, OpenSSL, Apache Project, Apache mod_ssl. The project development is divided in two main tasks: studying and refining the security scheme that guarantees the best model to be used in a CA and developing software to easily setup and manage a Certification Authority. FAQs: What is the OpenCA PKI development ? TheOpenCA PKI development is a project aimed to the deveoping of a full PKI Toolkit anyone can use to setup their own CAs. All software used together with the one we directly code is under OS licenses so you have not the need to pay to manage your PKI. Obviously if you want to contribute to our project or to any of the project related with ours you can! What is the difference between the former OpenCA Project and the OpenCA PKI development ? None. The renaming of the project is due to the OpenCA LABS acting as a framework where PKI related projects (R&D) are grouped together. The OpenCA PKI development Project will countinue its work releasing ever more complete version of the OpenCA packages 2. OSCAR PKI Project (http://oscar.dstc.qut.edu.au/) What is Oscar? Oscar is a project aimed at designing and constructing a public key certification system from the ground up. The system will include all necessary components including, a Certificate Authority, Certificate repository and client interface. This will provide the infrastructure required to manage and administer a public key environment. The Oscar project aims to conform to existing and emerging standards such as the IETF PKIX, OSI X.509, and RSA PKCS standards. Oscar stands for O pen S ecure C ertificate AR chitechture. Note:Oscar is no longer undergoing active development. Instead you might want to take a look at µPKI [C] or JCSI [Java] 3. Jonah PKIX (http://www.mit.edu/pfl/) a freeware PKIX (see below) reference implementation (IBM). 4. pyCA (http://www.pyca.de/) The usage of cryptographic techniques promises secure usage of Internet services concerning authentication of clients and servers and authorized access to sensitive data. During the last two years it turned out that X.509 certificates, SSL and S/MIME are the relevant, widely adopted cryptographic standards for securing various Internet services like WWW, Mail, etc. However these standards require setting up a working X.509-based PKI (pulic key infrastructure). Although there is a quite lot of documentation and some example software for setting up a primitive PKI with an own certificate authority with the free package OpenSSL it seems that this task is not easy for most people. There is a lot of discussion on various mailing-lists, e.g. how to generate self-signed CA certificates, generate certificate requests with the famous WWW browsers and how to provide client certificates / certificate revocation lists for download, etc. Additionally if the certification business of an organization gets only a little bit more serious one has to take care about critical security issues. pyCA tries to make it easier for people to set up and run a organizational certificate authority which fulfills the need for a fairly secure certification processing. The package also tries to reduce administrative tasks and user's frustration by providing a comfortable web interface to users contacting the certificate authority. 5. Mozilla Open Source PKI Project (http://www.mozilla.org/projects/security/pki/) Open source PKI projects include: Network Security Services (NSS) . Libraries designed to support cross-platform development of security-enabled server applications. Applications built with NSS can support SSL v2 and v3 , TLS , PKCS #5 , PKCS #7 , PKCS #11 , PKCS #12 , S/MIME , X.509 v3 certificates, and other security standards. The Sun-Netscape Alliance uses NSS to support these standards in a wide range of products, including iPlanet Certificate Management System, iPlanet Web Server, iPlanet Directory Server, and iPlanet Messaging Server. NSS also provides the security foundation for Netscape Communicator. Network Security Services for Java (JSS) . A Java interface to NSS that supports most of the security standards and encryption technologies supported by NSS. JSS also provides a pure Java interface for ASN.1 types and BER/DER encoding. Personal Security Manager (PSM) . Libraries and a daemon designed to support cross-platform development of security-enabled client applications. Built on top of NSS, these libraries are currently being used by the Sun-Netscape Alliance for ongoing development of a security module for use with Netscape Communicator 4.7 and Seamonkey. PKCS #11 Conformance Testing . Test suites designed to test PKCS #11 implementations. Open Source PKI Goals Improve the quality, scalability, and feature set of security code used to create PKI products. Encourage the development and deployment of PKI-enabled applications and services throughout the industry, including support for PKI features in more open source applications. Improve confidence in security software by encouraging open review of source code. Accelerate the growth of a standards-based security foundation for ecommerce and the Internet. 6. MISPC Reference Implementation ( http://csrc.nist.gov/pki/mispc/welcome.html ) MISPC, Minimum Interoperability Specifications for PKI Components NIST developed the Minimum Interoperability Specifications for PKI Components (MISPC), Version 1 with the assistance of ten CRADA partners: AT&T, BBN, Certicom, Cylink, DynCorp, IRE, Motorola, Nortel (Entrust), Spyrus, and Verisign. The specification includes a certificate and CRL profile, message formats and basic transactions for a PKI issuing signature certificates. The specification includes support for multiple signature algorithms and transactions to support a broad range of security policies. This document has been formally published as a NIST Special Publication 800-15; it is available electronically in Microsoft Word (284K) or PostScript (954K) . NIST has developed an updated specification with the help of CRADA partners to enhance the specification to support development of conforming PKI components. MISPC Version 2 is available for review and comment. The associated reference implementation is currently undergoing an upgrade and will be available second quarter of fiscal year 2001. NIST developed the Minimum Interoperability Specifications for PKI Components (MISPC), Version 1 with the assistance of ten partners: AT&T, BBN, Certicom, Cylink, DynCorp, IRE, Motorola, Nortel (Entrust), Spyrus, and Verisign. The specification includes a certificate and CRL profile, message formats and basic transactions for a PKI issuing signature certificates. Also, it includes support for multiple signature algorithms and transactions to support a broad range of security policies. This document is available at the MISPC WWW page. Along with the specification, there is a reference implementation that is available only by ordering a CDROM from NIST. The CDROM does not contain cryptographic support.
OpenSSL Project 源于 SSLeay, 由 Eric Young 发起。 Open Source 的实现， Apache-style license. 2. CDSA – Common Data Security Architecture Intel 开发，由 TOG 标准化，其参考实现支持 Windows 及 Linux ，类 BSD License. 3. RSA BSAFE 商用软件包，需要付费
指明现有 PKI 的不足之处，如 Trust Model ， Privacy 以及应用标准化等方面存在的问题，并说明下一步可能的进展。主要内容基于 1. Conventional Public Key Infrastructure: An Artefact Ill-Fitted to the Needs of the Information Society ( http://www.anu.edu.au/people/Roger.Clarke/II/PKIMisFit.html ) 2. Ten Risks in PKI, (http://www.counterpane.com/pki-risks.html), By Carl Ellison, Bruce Schneier 3. PKI POLICY PITFALLS (http://www.infosecuritymag.com/articles/july01/features_pki.shtml), By MIKE BOBBITT 和其它方面的一些文章和报道。
1. PEM (Hierarchy), PGP (Web of Trust), ICE-TEL (Web of Hierarchy), The Solar Trust Model, SDSI/SPKI 2. 王曙，曾晓涛，伍思仪，“ PKI 中的常见信任模型 ”， 2001 年 7 月 (http://www.whizlabs.net/topic/topics.html)
这一部分，尚未认真整理，下面只是 copy&paste 过来的一些内容。 asymmetric cryptography : defined originally by Diffie and Hellman, a cryptographic system using different keys for encipherment and decipherment such that one of the keys (private key) can not be derived efficiently from the other (public key). certificate : a digitally signed data record communicating some information from the signer (issuer) of the certificate to the verifier of the certificate. A certificate differs from a general signed message usually in that: the data structure is well defined so that a computer can interpret the structure, and the certificate's ``message'' is of the form ``to whom it may concern'', rather than addressed to a specific party Certificate Authority : in the X.509 world, a special certificate issuing entity, usually part of a hierarchy, responsible for issuing all certificates to end entity keyholders. digital signature : a computation with a private key and typically the hash of a document or data record such that any entity in possession of the matching public key can verify computationally that the computation was performed by the associated private key and that the signed document has not changed since the signature was computed. hash : a cryptographic computation over a message yielding a fixed length quantity (the hash value) such that it is computationally difficult to find any two different input messages yielding the same hash value. The ``strength of a hash'' is a reference to the difficulty of finding such message pairs. keyholder : the holder of the private key. non-repudiation : the notion that the keyholder is legally liable for any statement digitally signed by that keyholder's signature key. PGP : Pretty Good Privacy -- an early public key application, defining the first public key infrastructure to be widely deployed. PKI : Public Key Infrastructure -- a mechanism to permit the distributed use of public keys, involving certificates that bind information of interest to public keys private key : a key in an asymmetric cryptosystem that is kept secret and held by one entity, called the keyholder. public key : a key in an asymmetric cryptosystem that need not be kept secret and is often SDSI : Simple Distributed Security Infrastructure secret key : a key in a symmetric cryptosystem. speaks for : the notion that a private digital signature key speaks digitally signed statements in cyberspace on behalf of the keyholder SPKI : Simple Public Key Infrastructure symmetric cryptography : the original kind of cryptography, in which the same key is used for both encipherment and decipherment. Web of Trust: a mechanism for fault tolerance of certificate signature , associated with PGP. X.509 : a data structure defined as part of the X.500 global directory effort, designed to bind an X.500 distinguished name to a public key. The presumption in X.509 is that the named entity is the keyholder of the associated public key. In some cases, it is assumed that the public key speaks for the named entity. Attribute Authority (AA) - An authority trusted by one or more users to create and sign attribute certificates. It is important to note that the AA is responsible for the attribute certificates during their whole lifetime, not just for issuing them. 属性认证中心 -- 一或多个用户信任的生成并签发属性证书的认证中心。重要的需要指出的是， AA 在属性证书的整个生命周期中都要负责任，而非仅仅签发它们。 Attribute Certificate (AC) - A data structure containing a set of attributes for an end-entity and some other information, which is digitally signed with the private key of the AA which issued it. 属性证书 -- 包含终端实体的一系列属性或其它信息的数据结构，使用签发它的 AA 的私钥进行数字签名得到。 Certificate - Can refer to either an AC or a public key certificate. Where there is no distinction made the context should be assumed to apply to both an AC and a public key certificate. Certification Authority (CA) - An authority trusted by one or more users to create and assign public key certificates. Optionally the CA may create the user's keys. It is important to note that the CA is responsible for the public key certificates during their whole lifetime, not just for issuing them. Certificate Policy (CP) - A named set of rules that indicates the applicability of a public key certificate to a particular community or class of application with common security requirements. For example, a particular certificate policy might indicate applicability of a type of public key certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range. Certification Practice Statement (CPS) - A statement of the practices which a CA employs in issuing public key certificates. End-entity - A subject of a certificate who is not a CA in the PKIC or an AA in the PMI. (An EE from the PKI can be an AA in the PMI.) 终端实体 -- 证书的主题 ( 此证书既非 PKIC 中的 CA ，也非 PMI 中的 AA 的证书 ) Public Key Certificate (PKC) - A data structure containing the public key of an end-entity and some other information, which is digitally signed with the private key of the CA which issued it. Public Key Infrastructure (PKI) - The set of hardware, software, people, policies and procedures needed to create, manage, store, distribute, and revoke PKCs based on public-key cryptography. Privilege Management Infrastructure (PMI) - A collection of ACs, with their issuing AA's, subjects, relying parties, and repositories, is referred to as a Privilege Management Infrastructure. Registration Authority (RA) - An optional entity given responsibility for performing some of the administrative tasks necessary in the registration of subjects, such as: confirming the subject's identity; validating that the subject is entitled to have the values requested in a PKC; and verifying that the subject has possession of the private key associated with the public key requested for a PKC. Relying party - A user or agent (e.g., a client or server) who relies on the data in a certificate in making decisions. 依赖方 / 依托方 -- 依赖证书中的数据做决策的用户或代理。 Root CA - A CA that is directly trusted by an EE; that is, securely acquiring the value of a Root CA public key requires some out-of-band step(s). This term is not meant to imply that a Root CA is necessarily at the top of any hierarchy, simply that the CA in question is trusted directly. Subordinate CA - A &quot;subordinate CA&quot; is one that is not a Root CA for the EE in question. Often, a subordinate CA will not be a Root CA for any entity but this is not mandatory. Subject - A subject is the entity (AA, CA, or EE) named in a certificate. Subjects can be human users, computers (as represented by Domain Name Service (DNS) names or Internet Protocol (IP) addresses), or even software agents. 主题 -- 主题是指在证书命名的实体 (AA, CA 或 EE) 。主题可以是人，计算机 ( 由 DNS 或 IP 地址表示 ) ，甚至是软件代理。 Top CA - A CA that is at the top of a PKI hierarchy. Note: This is often also called a &quot;Root CA,&quot; since in data structures terms and in graph theory, the node at the top of a tree is the &quot;root.&quot; However, to minimize confusion in this document, we elect to call this node a &quot;Top CA,&quot; and reserve &quot;Root CA&quot; for the CA directly trusted by the EE. Readers new to PKIX should be aware that these terms are not used consistently throughout the PKIX documents, as [FORMAT] uses &quot;Root CA&quot; to refer to what this and other documents call a &quot;Top CA,&quot; and &quot;most-trusted CA&quot; to refer to what this and other documents call a &quot;Root CA.&quot;
§0.4 PKI 进展 标准化进展 IETF PKIX 、 SPKI Workgroup ； NIST ， DOT (Department of the Treasury) ； TOG (The Open Group) ； and others (include WAPForum, etc) 产品与工程 From Pilot Projects to Practices, Various Vendors and Products PKI 应用 MS Outlook/Netscape Messanger (S/MIME), IE/Navigator (SSL/TLS), PGP
§1.2 传统密码学 历史悠久，最古老与最现代的密码学 基本特点：加密和解密采用同一个密钥 let C = Cipher text, P = Plain text, k is key, E()/D() is the encryption/decryption function, then C=E(P, k), P=D(C, k) 基本技术 替换 / 置换和移位
DES DES 是第一个得到广泛应用的密码算法； DES 是一种分组加密算法，输入的明文为 64 位，密钥为 56 位，生成的密文为 64 位； DES 是一种对称密码算法，源于 Lucifer 算法 ，其中采用了 Feistel 网络 (Feistel Network) ， 即 Li = Ri −1 Ri = Li −1 ⊕ f ( Ri −1 , K i ) DES 已经过时，基本上认为不再安全； http://dir.yahoo.com/Computers_and_Internet/Security_and_E
IDEA Xuejia Lai 和 James Massey 提出； IDEA 是对称、分组密码算法，输入明文为 64 位，密钥为 128 位，生成的密文为 64 位； IDEA 是一种相对较新的算法，虽有坚实的理 论基础，但仍应谨慎使用 ( 尽管该算法已被证 明可对抗差分分析和线性分析 ) ； IDEA 是一种专利算法 ( 在欧洲和美国 ) ，专利 由 Ascom-Tech AG 拥有 ; PGP 中已实现了 IDEA ；
Summary DES 是应用最广泛的对称密码算法 ( 由于计算 能力的快速进展， DES 已不在被认为是安全的 )； IDEA 在欧洲应用较多； RC 系列密码算法的使用也较广 ( 已随着 SSL 传遍全球 ); AES 将是未来最主要，最常用的对称密码算法 ；
§1.3 公钥密码学 Whitefield Diffie ， Martin Hellman ，《 New Directions in Cryptography 》 ,1976 公钥密码学的出现使大规模的安全通信得以实 现 – 解决了密钥分发问题； 公钥密码学还可用于另外一些应用：数字签名 、防抵赖等； 公钥密码体制的基本原理 – 陷门单向函数 (troopdoor one-way function)
RSA Ron Rivest, Adi Shamir 和 Len Adleman 于 1977 年研制并于 1978 年首次发表； RSA 是一种分组密码，其理论基础是一种特殊 的可逆模幂运算，其安全性基于分解大整数的 困难性； RSA 既可用于加密，又可用于数字签名，已得 到广泛采用； RSA 已被许多标准化组织 ( 如 ISO 、 ITU 、 IETF 和 SWIFT 等 ) 接纳； RSA-155(512 bit), RSA-140 于 1999 年分别被分
RSA (cont.) 设 n 是两个不同奇素数之积，即 n = pq ， 计算其欧拉函数值 Φ(n)=(p-1)(q-1). 随机选一整数 e,1≤e<Φ(n), (Φ(n),e)=1. 因而在模 Φ(n) 下 ,e 有逆元 d = e −1 mod(n) 取公钥为 n,e, 秘密钥为 d.(p,q 不再需要，应该被舍弃，但绝不可泄露 ) Ek ( x) = x e mod n, x ∈ Z n 定义加密变换为 解密变换为 y ) = y d mod n, y ∈ Z n Dk (
Differences between Enterprise CA And Trade CA Enterprise CA is a model that your company hold everything of PKI including CA, RA, Directory Server etc. Entrust ， Baltimore ， RSA Security, InfoSec, JIT, Koal and NetFront etc. Trade CA is another model that a trusted third party (often are PKI vendors) will manage every thing for you, but maybe you can control the user enrollment process. Verisign, CFCA, CTCA The selection between them will base on a lot things, such as trust relationship, the control you have on the end users etc
§7.2 著名的 PKI 实现 (opensource) OpenCA Project (http://www.openca.org/) OSCAR PKI Project (http://oscar.dstc.qut.edu.au/) Jonah PKIX (http://web.mit.edu/pfl/) pyCA (http://www.pyca.de/) Mozilla Open Source PKI Project http://www.mozilla.org/projects/security/pki/
致谢 ! Arthur Jin (who remind me to add RC2/RC4) Chorus Li (who remind me to add something about domestic PKI vendors) Yongtian Zhang (who spent time to review the outline and give me his important comments) Frank Lau, Richard Wei, WHIZ Labs, & AKA etc.