您的位置：首页 > 其它

Windows 2000 公钥基础结构详解 (ZT)

2005-08-31 14:44 477 查看
Windows 2000 公钥基础结构详解 1楼
引言

　　Microsoft Windows 2000 将一个综合的公钥基础结构 (PKI) 引入到 Windows 平台。这利用和扩展了Windows 公钥 (PK) 加密服务（该服务是过去几年中引入的），提供了一整套服务和管理工具，以创建、部署和管理基于 PK 的应用程序。它允许应用程序开发人员利用 Windows NT 的共享机密安全机制或基于 PK 的安全机制，作为其相应的安全机制。同时，企业还因此能够基于统一工具和策略机制，来管理该环境和应用程序。

　　本文最后对 Windows 2000 中 PKI 作了概述。

　　概念

　　加密技术是一门保护数据的科学。加密算法从数学上将输入“明文”数据与“加密密钥”结合起来，生成加密数据（暗记文）。虽然有了一个好的加密算法，但要逆转加密过程，并将仅以暗记文开始的数据反推成明文数据，从计算角度上是不可行的；此转换过程还需要其他数据，即“解密密钥”。

　　传统上，“密钥（或对称密钥）加密”、加密与解密密钥是相同的，因而可以共享敏感数据。对于想要使用密钥加密进行通信的双方，只有安全地交换加密/解密密钥后，才能相互交换加密数据。

　　而“PK 加密”基本属性则是，加密和解密使用不同的密钥。用公钥加密密钥进行的加密是“单向”功能；明文虽然可以很容易地转变为暗记文，但加密密钥却与解密过程无关。要将暗记文转回到明文，则需要解密密钥（与加密密钥有关，但不相同）。因此，对于 PK 加密来说，每个用户都有一对密钥，由一个“公钥”和一个“私钥”组成。在公钥可用的前提下，可以让其他人将加密数据发给您，而该数据只能用您的私钥来解密。相似地，可用您的私钥来转换数据，这样，其他人就会验证出该数据是由您发送的。第二种功能是数字签名的基础，下面将对它进行论述。

　　PK 加密中，公钥与私钥是分开的，由此产生了很多新技术。最重要的新技术有：数字签名、分布式身份验证、使用公钥的密钥协议，以及未预设共享机密情况下进行的批量数据加密。

　　有许多人们熟知的 PK 加密算法。其中一些算法是通用的，如 RSA (Rivest-Shamir-Adleman) 和 ECC (Elliptic Curve Cryptography)，因为它们能支持以上所有操作。其他算法则仅支持这些功能的一个子集。一些示例中包括数字签名算法 — 即 DSA，是美国政府的数字签名标准（FIPS 186）的一部分，该算法仅用于数字签名；还包括 Diffie-Hellman (D-H)，它用于私钥协议。

　　以下几段简要论述了 PK 加密的主要用途。这些内容是以 Bob 和 Alice 两个用户为例，来讲述这些操作的。它假定 Bob 和 Alice 可以交换信息，但没有任何预设的共享的机密。

　　数字签名
　　
　　也许，公钥加密最引人注目的特征就是创建和验证“数字签名”。它以数学转换为基础；该转换将私钥与待“签名”的数据结合在一起，这样：

　　　只有拥有私钥的人才有可能创建数字签名。

　　　任何能访问此相应公钥的人均能验证该数字签名。

　　　对已签名的数据进行的任何修改（即使只修改了大型文件的一位）都会使数字签名无效。

　　数字签名本身就是数据，因此可将其与所保护的签名数据一起传输。例如，Bob 可以创建一个给 Alice 的电子邮件消息，并把签名与消息文本一起发送，用它给 Alice 提供验证消息来源所需的信息。此外，数字签名还提供了一种方法，以验证数据在从源到目标的传送过程中，没有被篡改过（无论是意外的还是蓄意的）。因此，数字签名可用来提供一个能高度保障数据完整性的机制。

　　身份验证

　　可用 PK 加密来提供可靠的分布式“身份验证”服务。“实体身份验证”可以保证：数据发件人就是收件人所认为的那个实体。验证的一种方法是：数据接收人 Alice 向数据发送人 Bob 发送一个质询，该质询是用 Bob 的公钥进行加密的。Bob 对此质询进行解密，并把它发回给 Alice，证明他有与 Alice 发布质询所用公钥相关联的私钥。另一种方法是：Alice 向 Bob 发送一个明文质询。Bob 将该质询与其他信息（已有数字签名）结合起来。然后，Alice 就用 Bob 的公钥来验证该签名，并证实 Bob 有与此关联的私钥。该质询能够使该消息是唯一的，并可防止有敌意的第三方利用答复进行攻击。这两种情况都称为“证明所有权”协议，因为发送人在此过程中证明自己有特定的私钥。

　　使用公钥的密钥协议

　　PK 加密的另一个功能是，它允许双方就使用公共的非安全通信网络的共享机密达成一致。实际就是 Bob 和 Alice 每人都生成一个随机数，分别形成了共享机密密钥的一半。然后，Bob 用 Alice 的公钥，对自己的那一半机密进行加密，再把机密发送给 Alice；而 Alice 则用 Bob 的公钥对自己的那一半机密进行加密，再把机密发送给 Bob。双方都可以将对方发来的消息进行解密，将共享机密中不是自己生成的那一半提取出来，然后将两个一半密码结合起来，生成共享机密。协议完成后，共享的机密就可以用于保障其他通信的安全了。
未预设共享机密的批量数据加密

　　PK 加密带来的第四个主要技术是：无须建立预设共享机密，就可以进行批量数据加密。从计算角度上看，现有的 PK 算法与密钥算法是密切相关的。这就不适于加密大量数据。要既能利用 PK 加密技术，又能进行有效的批量加密，通常要将 PK 和密钥技术结合起来使用。

　　它是这样实现的：先选择一个密钥加密算法，并生成一个“随机会话密钥”，进行数据加密。如果 Bob 要发送消息，他先用 Alice 的公钥对该会话密钥进行加密。随后，生成的暗记文密钥与加密数据一同发给 Alice。Alice 可用她的私钥来恢复该会话密钥，然后用该会话密钥解密数据。

　　在私钥加密中，Alice 和 Bob 信任他们的共享机密，因为他们已就此达成一致或是以安全的方式交换的，他们还一致同意将其安全地进行存储，防止被有恶意的第三方窃取。相反，使用 PK 加密技术，Alice 和 Bob 都只需要保护其各自的私钥即可。他们需要共享的唯一信息就是对方的公钥。他们需要能够用高保障来标识彼此的公钥，但不需保密公钥。对使用 PK 加密而言，能够信任公钥与已知实体的关系是至关重要的。

　　Alice 信任 Bob 的公钥，有可能是因为 Bob 以安全的方式将它直接传递给了 Alice。但这是以 Alice 和 Bob 此前已有安全通信为前提的。更可能是，Alice 通过非安全机制（如从公共目录）获得了 Bob 的公钥，所以必须有其他的机制使 Alice 确信，她所谓的来自“Bob”的公钥，的确是 Bob 的公钥。这样的机制之一就是基于“证书颁发机构”(CA) 颁发的证书。

　　证书

　　证书提供了一种机制，用于确立对公钥和拥有相应私钥的实体之间关系的信任。证书就是一种特殊类型的数字签名式的声明；证书的主题则是一个特殊的“主题公钥”，该证书是由颁发者（保存另一对私钥和公钥）签名的。通常，证书也含有与主题公钥有关的其他信息，如有相应私钥的实体标识信息。因此，当颁发一个证书时，颁发者就证明了主题公钥和主题标识信息之间绑定关系的有效性。

　　现用证书的最常见格式是以 ITU-T X.509 标准为基础的。这是 Windows 2000 PKI 中使用的一个基本技术。但是，它并不是唯一的证书格式。例如，Pretty Good Privacy (PGP) 安全电子邮件采用的是一种 PGP 独有的证书。

　　证书颁发机构

　　证书颁发机构 (CA) 仅是一个颁发证书的实体或服务。CA 可作为绑定担保人，这是在颁发证书中包含的主题公钥与主题标识信息之间的绑定。不同的 CA 可选用不同的方法来验证这种绑定，所以在选用担保公钥的颁发机构之前，了解该机构的策略和步骤是很重要的。

　　信任和验证

　　当 Alice 收到一个签名的消息时，面临的根本问题就是，她是否应该“信任”该签名是有效的，并的确是由自称的“签名人”签名的。Alice 可以确认该签名数学上是有效的；即，她可以使用已知的公钥来验证该签名的完整性。但是，Alice 仍需确定：验证该签名所用的公钥是否的确属于自称第一个签名的那个实体。如果 Alice 并不完全相信该公钥是属于 Bob 的，她需要获得有力的证据，证明该密钥属于 Bob。

　　如果 Alice 可以找到一个 Bob 公钥的证书（由 Alice 绝对信任的 CA 颁发的），那么，Alice 就会相信“Bob 的公钥”的确是 Bob 的。即，如果 Alice 找到的证书具有以下特征，她就会相信，她收到的确实是 Bob 的公钥：

　　　证书具有其颁发者加密的有效签名。

　　　证书可证实名称“Bob”与 Bob 的公钥之间存在绑定关系。

　　　证书是由 Alice 信任的颁发者颁发的。

　　假定 Alice 找到了 Bob 公钥的这样一个证书，然后她可以使用颁发证书的 CA (Ira) 的公钥来验证其真伪（假设下一个需要验证的是 Ira）。但是，Alice 再次面临这样的困境。即她怎么知道该公钥是不是真的属于 Ira 的呢？所以，Alice 需要找到一个证书，能证实 Ira 的身份标识以及 Ira 与“Ira 的公钥”之间的绑定关系。

　　最终，Alice 会建立一条“证书链”，从 Bob 和“Bob 的公钥”开始，经过一系列 CA，在颁发给 Alice 绝对信任的人的证书处结束。这个证书称为“可信根证书”，因为它成为公钥/标识绑定层次结构的根（顶层节点），Alice 相信它是真实的（请参见 4.1 节，“证书层次结构”）。如果 Alice 明确信任某一特定可信根证书，那么也就是绝对信任了该可信根颁发的所有证书，以及该可信根证实的任何从属 CA 颁发的证书。

　　这组 Alice 明确信任的可信根证书，是 Alice 必须以安全方式获取的唯一信息。这组证书是 Alice 的信任系统以及她对公钥基础结构的信任基石。
Windows 2000 PKI 组件

　　图 1 给出了 Windows 2000 PKI 组件的顶层视图。这是一个逻辑视图，并不是指独立服务器的物理需求；事实上，很多功能都可能合并到一个单服务器系统中。Microsoft 证书服务是 PKI 的一个重要组成部分。用它可以部署一个或多个企业 CA。这些 CA 支持证书的颁发和吊销。它们与 Active Directory 集成在一起，提供 CA 位置信息和 CA 策略，并允许发布证书和吊销信息。

　　PKI 并未取代原有基于域控制器 (DC) 和 Kerberos 密钥分发中心 (KDC) 的 Windows NT 域信任和身份验证机制。而是与这些服务配合使用，增强了性能，使应用程序得以方便地扩展，以满足外部网和 Internet 的需求。尤其值得一提的是，PKI 满足了对于可扩展的分布式标识和身份验证、完整性和保密性的需求。

图 1 Windows 2000 公钥基础结构组件

　　在运行 Windows NT 的工作站和应用程序服务器，以及运行 Windows 95 和 Windows 98 的工作站上，均支持创建、部署和管理基于 PK 的应用程序。Microsoft CryptoAPI 是这些服务的基石。它为可安装的加密服务提供程序 (CSP) 的加密功能提供了一个标准接口。这些 CSP 可能是基于软件的，或利用加密硬件设备的程序，它们能够支持各种算法和密钥强度。如图中所示，一种可能基于硬件的 CSP 可支持智能卡。CSP 与 Windows 2000 一起发行并利用与 Microsoft PC/SC 兼容的智能卡基础结构的例子很多（请参见 http://www.Microsoft.com/smartcard/ 以及 http://www.smartcardsys.com / ）。

　　在加密服务的上层是一组证书管理服务。这些服务支持 X.509 v3 标准证书，提供永久存储、枚举服务以及解码支持。最上层是用于处理标准的工业消息格式的服务。这些服务主要是用来支持 PKCS 标准（请参见 http://www.rsa.com/ ）以及发展中的 IETF（Internet 工程任务任务组— http://www.ietf.org /）PKIX（公钥基础结构 X.509）草案标准。

　　其他服务使用 CryptoAPI，为应用程序开发人员提供其他功能。安全信道 (schannel) 使用工业标准 TLS 和 SSL 协议，来支持网络身份验证和加密。可用 Microsoft WinInet 接口（与 HTTP 协议 (HTTPS) 一起使用）访问这些服务，也可通过 SSPI 接口与其他协议配合使用这些服务。Authenticode 支持对象签名和验证。这虽然也可用于其他环境，但主要用于确定 Internet 下载组件的来源和完整性。还支持通用智能卡接口。以上这些特点已用于将加密智能卡以一种与应用程序无关的方式进行集成，这是集成在 Windows 2000 中的智能卡登录支持的基础。

图 2 公钥应用程序服务

　　证书颁发机构

　　Microsoft 证书服务包含在 Windows NT Server 5.0 中，它提供一种方法，使企业能够方便地建立 CA，以满足其商业需求。证书服务包含一个默认策略模块，它适于将证书颁发给企业实体（用户、机器或服务）。其中包括请求实体的标识，以及验证该域 PK 安全策略是否接受所请求的证书。要考虑到解决其他策略，或要将 CA 扩展成支持各种外部网或 Internet 方案时，对其进行相应的修改或改进也是很容易的。因为证书服务是基于标准的，所以它为异构环境中启用 PK 的应用程序提供了广泛的支持。

　　在 PKI 中，可以方便地支持企业 CA 以及外部 CA，例如，与其他单位或商业服务提供程序相关的 CA。这样，企业就可以根据商业需要来调整环境了。

　　Windows 2000 PKI 采用层次结构的 CA 模型。其优点是：具有可扩展性，管理方便，并且与很多商业和第三方 CA 产品有一致性。最简单的形式是，CA 层次结构仅由一个 CA 组成；但通常一个层次结构会包含多个 CA，并明确定义了父子关系（图 3）；正如图中所示，可能还存在多个不连续的利益层次结构。并不要求所有 CA 共享一个公用顶层父 CA（或根 CA）。

　　这一模型中，子 CA 由父 CA 颁发的证书来“验证”，该证书将一个 CA 的公钥与其标识和其他基于策略的属性绑定到一起。层次结构顶端的 CA 通常称为“根 CA”。下属 CA 通常称为“中级 CA”或“颁发 CA”。在本文中，“颁发 CA”指的是颁发最终实体证书的 CA。“中级 CA”不是指根 CA，而是指仅验证其他 CA 的 CA。

图 3 证书颁发机构层次结构

　　这一模型的主要优点就是：验证证书只需要对少数根 CA 建立信任即可。同时，它对颁发 CA 的数量要求更为灵活。支持多个颁发 CA 有许多实际的原因。包括：

　　 用法 – 可基于多种用途颁发证书，例如，安全电子邮件、网络身份验证等等。颁发的用途不同，其策略也会有所不同，对其进行分别处理是策略管理的基础。

　 　组织划分 – 根据组织中实体角色不同，颁发证书策略也不相同。仍然可以创建颁发 CA，区分和管理这些策略。

　 　地理划分 – 组织可能在多个物理站点拥有实体。这些站点间的网络连接决定了需要多个颁发 CA，以满足可用性要求。

　　这种 CA 层次结构还为管理提供了好处，包括：

　　 可以灵活配置 CA 安全环境（密钥长度、物理保护、防止网络攻击的保护等），以保持安全性和可用性之间的平衡。例如，对于根 CA，可使用特殊用途的加密硬件，把它放到物理上安全的区域，或在脱机模式下运行。出于成本或可用性的考虑，它可能并不适于颁发 CA。

　　 可频繁更新颁发 CA 密钥和/或证书（泄密风险最高），而无须更改已建立的信任关系。

　　 可以去掉 CA 层次结构的某一部分，而不会影响已建立的信任关系。例如，可以很容易地拒绝或吊销一个与特定地理站点关联的颁发 CA 证书，而不会影响组织中的其他部分。

　　CA 层次结构一般是静态的，但并不要求必须如此。在给定根 CA 下，可以方便地添加或删除颁发 CA。另外，可由一个根 CA 颁发证书，证明另一个根 CA 是它的中级 CA，这样，就可以合并原有的 CA 层次结构。但是，在合并之前，需要慎重考虑可能会引起的策略不一致性，还要考虑可能会编入原有证书的“深度”限制的影响。

　　部署 Microsoft 证书服务是一个非常简单、直观的操作。创建 CA 前，最好先建立域。然后，建立一个或多个企业根 CA。在证书服务安装过程中，管理员就是按这样的步骤进行安装的。安装过程的要点包括：

　　　选择主服务器 – 根 CA 可以在任何 Windows NT Server 平台上运行，包括 DC。在此过程中，必须考虑物理安全性要求、预期负载、连接性要求等因素。

　　　命名 – CA 名称与其证书绑定在一起，因此，不能修改。应该考虑组织命令规则以及将来需要，以区分不同的颁发 CA。

　　　密钥生成 – CA 的公钥对将在安装过程中生成，它是该 CA 所独有的。

　　　CA 证书 – 对于根 CA 而言，安装过程会用 CA 的公钥-私钥对，自动生成一个自签名的 CA 证书。对于子 CA，可以选择生成一个证书请求，并提交到中级 CA 或根 CA。

　　　Active Directory 集成 – 在安装过程中，关于 CA 的信息会写入 Active Directory 中的 CA 对象。它给域客户提供了可用的 CA 以及颁发证书类型的信息。

　　　颁发策略 – 企业 CA 安装程序会自动为该 CA 安装和配置 Microsoft 提供的企业策略模块。已授权的管理员可对该策略进行修改，虽然大多数情况下无需这样做。

　　建立根 CA 后，就可以安装此根 CA 所属的中级或颁发 CA 了。安装策略的唯一重大差别是：生成的证书请求是提交给根 CA 还是中级 CA。此请求可以自动路由到联机 CA（可通过 Active Directory 定位这些 CA），或在脱机情况下手动路由。在这两种情况下，都必须先把生成的证书安装到 CA，CA 才能开始工作。
在这些企业 CA 和 Windows NT 域信任模型之间有明显的联系。但这并不意味着，CA 信任关系和域信任关系之间存在直接的映射关系。一个 CA 可以处理多个域中的实体，甚至域外的实体。相似地，一个给定域可以有多个企业 CA。

　　正如上面讨论的，CA 是很有价值的资源，通常希望给它们提供更高等级的保护。应该考虑的特定操作有：
　
　　　物理保护 – 因为 CA 代表了企业中的高度可信任实体，通常希望保护它们，防止篡改。这一需求取决于该 CA 颁发证书的内在价值。将 CA 服务器从物理上隔离（在职能部门中，只有安全管理员能够访问），可大大减少此类攻击的可能性。

　　　密钥管理 – CA 的密钥最有价值，因为私钥是信任证书过程的基础。加密硬件模块（通过 CryptoAPI CSP 访问证书服务）可提供防止篡改的密钥存储，并将加密操作与运行在该服务器上的其他软件隔离开。这大大减少了 CA 密钥泄露的可能性。

　　　恢复 – 丢失 CA（例如，由于硬件故障）可能会引起很多管理和操作上的麻烦，并会阻止吊销原有证书。证书服务支持 CA 实例的备份，这样，以后就可以恢复它了。这是整个 CA 管理过程的一个重要组成部分。

　　基于以前的讨论，很明显，Windows 2000 PKI 必须处理跨多个 CA 层次结构的信任关系。它可能只包括一个企业内的 CA 层次结构，但也可能包括多个企业内的层次结构，以及商业 CA（如 Verisign、Thawte 等）。

　　在 PKI 中，可以基于 Windows NT 域机器策略对象，从管理上建立和实施基于 CA 的信任关系。对于每个可信根 CA，此系统提供了一个方法，对该 CA 颁发的证书限制使用。例如，即使某个 CA 颁发的证书可以有多种用途，也可以仅将其用于服务器身份验证。

　　另外，个别用户可以添加其他 CA 信任关系，这种信任关系只适用于他们自己。可通过使用客户功能，但不涉及管理操作来实现这一目标。

　　要将所有可信根 CA 包含在一个策略对象中，可采用的另一要个方法是使用“交叉证书”。至少有一个供应商的 PKI 产品中使用了这种证书，它提供了一种方法，来创建从可信根 CA 到多个其他 CA 的一条信任链。Windows NT PKI 能够处理这种交叉证书，并能够在进行信任决策时使用它们；但在我们的模型中，它并不是必需的。我们这样做，是因为交叉证书会带来很多问题，特别是：

　　当 CA 实施不同的策略时，对于跨越不同组织界限的交叉证书其解释不明确。

　　如果没有现成的商业协议阐释其用法，则会产生交叉证书的解释问题。

　　生成和维护交叉证书会导致额外的管理负担。

　　启用域客户

　　Windows 2000 提供了一整套核心服务，来支持开发和部署可互操作的、基于 PK 的应用程序。这些核心服务也可在 Windows NT 4.0、Windows 98 及 Windows 95 中使用。Windows 2000 实现最显著的新功能是，它与域管理和策略模型集成，从而大大简化了企业内部的应用程序管理。

　　在本节的后面，我们阐述了 PKI 提供的核心应用程序服务。

　　PK 技术的使用取决于是否能够生成和管理一个或多个 PK 算法的密钥。Microsoft 的 CryptoAPI 支持可安装的 CSP，该 CSP 支持各种加密算法的密钥生成和管理。CryptoAPI 定义了标准接口，用于生成和管理密钥（对所有 CSP 均相同）。

　　存储密钥材料的机制取决于所选定的 CSP。Microsoft 提供的软件 CSP（或“基础”CSP）会基于每个用户或每个机器，将密钥材料以不同的加密形式存储。另外，它们支持对公钥对的导出性（CRYPT_EXPORTABLE 标记）控制，以及对使用的控制（CRYPT_USER_PROTECT 标记）。前者控制从 CSP 的私钥导出；后者决定了当应用程序试图使用该私钥时，用户的通知性能。其他 CSP 可以实施不同的机制。例如，智能卡 CSP 将公钥对存储在智能卡的防篡改硬件中，通常需要输入一个 PIN 代码，才能访问与私钥有关的操作。对应用程序来说，这些“保护”机制是透明的；该程序可用 CSP 环境中独有的密钥设置名称，来引用所有密钥对。
密钥恢复

　　CryptoAPI 体系结构与密钥恢复是兼容的，但并不能管理它。在这种情况下，密钥恢复是指，对一个实体的私钥以某种方式进行永久存储，这种方式允许已授权的个人在不知道谁是拥有该私钥的实体，或没有得到该实体的同意下，就可以访问该私钥。通常，这是为了访问重要商业信函，或为了满足执法的需要。

　　密钥恢复只有在用于永久性数据加密所用的密钥时，才是有用的。对于基于 PK 的应用程序，它通常指实体密钥的交换密钥。在归档标识或数字签名私钥时，其作用十分有限，并且冒很大风险。这是因为，其唯一的实际用途就是模拟私钥所有者。

　　Microsoft Exchange 现提供对密钥交换密钥的支持，这样，就可以阅读加密的电子邮件。另外，第三方 CSP 也提供了对密钥恢复的广泛支持。根据客户的需要，Microsoft 将来还会增加其他的密钥恢复功能。

　　正如前面讲到的，基于 PK 技术的实际应用一般取决于把公钥与已知实体绑定在一起的证书。Windows 2000 PKI 支持 Microsoft 企业 CA 或第三方 CA 的证书登记。登记支持是以与传输无关的方式实现的，并以使用工业标准的 PKCS-10 证书请求消息及包含产生的证书或证书链的 PKCS-7 响应为基础。同时，还支持 RSA 密钥和签名的证书、数字签名算法 (DSA) 密钥和签名，以及 Diffie-Hellman 密钥。

　　Microsoft 提供的登记控制 (Xenroll.dll) 提供了对 PKCS-10 和 PKCS-7 消息的支持，这种控制可为基于 Web 的登记编写控制脚本，或由程序调用该控制，以实现对其他传输机制，如 RPC、DCOM 及电子邮件的支持。该控制允许调用应用程序，来指定 PKCS-10 消息中包含的属性；允许使用原有密钥对或生成一个新的密钥对。登记过程被假设为非同步的，登记控制提供了状态管理，使颁发的证书与等待的请求相匹配。这就提供了这样一种方法，该方法可在证书、生成密钥对的 CSP 以及密钥对容器名称之间建立内部绑定。

　　PKI 支持多个登记方法，包括基于 Web 的登记、登记向导以及基于策略的“自动登记”（是用户登录过程的一部分）。将来，Microsoft 计划采用 IETF PKIX 工作组中现有证书请求语法 (CRS) 草案相同的方式，来开发证书登记过程。

　　从概念上讲，证书更新与登记相似，但它利用了原有证书内在的信任关系。证书更新假定请求实体需要一个新证书，新证书的属性与原有有效证书相同，但有效日期更长。更新可使用原有的公钥或新公钥。

　　更新对 CA 特别有利。可以推测，处理更新请求的效率会很高，因为此过程不需要重新验证原有证书的属性。Windows 2000 PKI 支持对自动登记证书的更新。对于其他机制，更新是作为一个全新的登记请求来处理的。

　　有关证书更新的工业标准消息协议尚未确定，但是已包含在 IETF PKIX CRS 草案中。只要这些标准被批准，Microsoft 就会计划实施有关的消息格式。

　　在 Microsoft PKI 中，密钥和相关证书由 CryptoAPI 子系统存储和管理。正如上文所述，密钥由 CSP 管理，而证书则由 CryptoAPI 证书存储区管理。

　　证书存储区是证书及其相关属性的库。按照常规，PKI 定义了五个标准证书存储区：

　　　MY – 此存储区用于保存用户或机器的证书（相关私钥可用于该证书）。

　　　CA – 此存储区用于保存颁发和中级 CA 证书（用于建立证书验证链）。

　　　TRUST – 此存储区用于保存证书信任列表 (CTL)。这些列表给管理员提供了其他机制，以指定一组可信 CA。这样做的优点是：这组可信 CA 可以通过非安全链接进行传输，因为它们已经过数字签名。

　　　BOOT – 此存储区仅保存可信根 CA 的自签名 CA 证书。

　　　UserDS – 此存储区提供了保存在 Active Directory（例如，在用户对象的用户证书属性中）中的证书库的逻辑视图。其目的是简化对这些外部库的访问。

　　这些是逻辑存储区，可展示驻留在多个物理存储区（硬盘、智能卡等）中的可用证书的全系统统一视图。使用这些服务，应用程序可以共享证书，并保证管理策略的一致操作。此证书管理功能支持对 X.509 v3 证书的解码，并提供枚举功能来帮助查找特定证书。

　　为简化应用程序的开发，MY 存储区会维护证书属性（表明 CSP 和相关私钥的密钥集名称）。应用程序选定了要使用的证书后，该程序就会用此信息来获取正确私钥的 CSP 环境。

　　公钥对和证书一般价值较高。如果由于系统故障而丢失，替换公钥对和证书要花费很长时间，并会造成经济损失。为解决这一问题，Windows 2000 PKI 提供了可实施证书管理的管理工具，支持证书及相关密钥对的备份和恢复功能。

　　当用证书管理器导出证书时，用户必须指定是否同时导出相关密钥对。如果选定该选项，该信息就会作为加密（基于用户提供的密码）PKCS-12 消息导出。它随后会导入到该系统或其他系统中，用于恢复证书和密钥。

　　此操作假定密钥对可由 CSP 导出。对于 Microsoft 基础 CSP 而言，如果在密钥生成时设置了导出标志，就可实现上述操作。第三方 CSP 可支持，也可以不支持私钥导出。例如，智能卡 CSP 一般不支持此操作。对于带有不可导出密钥的软件 CSP，变通的方法是保持一个完整的系统映像备份，包括所有注册信息。

　　在本文中，“漫游”是指，在企业的 Windows NT 环境中，不同物理机器上使用同一个基于 PK 的应用程序的能力。基本要求是，无论用户在何处登录，其密钥和证书都是可用的。Windows 2000 PKI 以两种方式支持此功能。

　　第一，如果用的是 Microsoft 基础 CSP，密钥和证书漫游则由漫游配置文件机制支持。只要启用了漫游配置文件，此操作对用户就是透明的。第三方 CSP 不支持此功能，这是因为每三方 CSP 通常使用不同的方法保存密钥数据，通常保存在硬件设备上。

　　硬件令牌设备（如智能卡）只要包含物理证书存储区，就可以支持漫游功能。与 Windows 2000 平台一起发行的智能卡 CSP，支持此功能。通过将硬件令牌随用户移动，可实现对漫游的支持。

　　证书往往是长期凭据，但为什么很多凭据在到期之前就变得不可信呢？其原因很多。例如：

　　　实体的私钥泄密或可能泄密。

　　　获取证书时采用了欺诈手段。

　　　状态改变。

　　基于 PK 的功能采用分布式验证，不需要直接与颁发凭据的中心可信实体进行通信。这就需要将吊销信息分发到要验证证书的个人。

　　吊销信息及其即时性的需求取决于应用程序。为支持各种操作情况，Windows 2000 PKI 增加了对工业标准的证书吊销列表 (CRL) 的支持。在管理控制下，企业 CA 支持证书吊销以及 Active Directory 的 CRL 发布。域客户可以提取此信息，将它在本地进行缓存，并在验证证书时使用。该机制还支持商业 CA 颁发的 CRL 或第三方证书服务器产品，只要客户可通过网络访问发布的 CRL 即可。

　　当使用基于 PK 的功能时，最令人关注的是与证书验证有关的客户信任问题。通常，它基于与颁发证书的 CA 有关的信任。如前所述，PKI 使用一个根 CA 层次结构，在此层次结构中，信任控制以根 CA 的决策为基础。如果给定的最终实体证书有条“链”通往一个已知的可信根 CA，并且预计的证书用法与应用程序环境一致，那么就认为它是有效的。如果以上条件有一条不成立，就认为它是无效的。

　　在 PKI 中，用户可以做只影响自已的信任决定。使用证书管理工具，用户通过安装和删除可信根 CA，并配置有关的使用限制，来实现上述过程。希望这只是例外情况，而非常规律性的。相反，我们希望这些信任关系能成为企业策略的一部分（请参见下一节“Windows 2000 的 PK 安全策略”）。使用策略建立的信任关系可以自动传播到 Windows 2000 客户机。
Windows 2000 的 PK 安全策略

　　安全策略可以应用到站点、域或部门 (OU)，并会影响有关用户和计算机的安全组。PK 安全策略仅是整个 Windows NT 安全策略的一个方面，它被集成到该结构中。它提供了一个机制，在全局实施策略时，可对策略进行统一定义和管理。PK 安全策略的最突出特点将在下面进行论述。

　　可用策略设置根 CA 的信任，以建立域客户在验证 PK 证书时所用的信任关系。可信 CA 集可使用组策略编辑器来配置。它可根据每台机器的情况进行配置，并将用于该机器上的所有用户。

　　除将一个根 CA 用作可信 CA 外，管理员可以设置与该 CA 关联的使用属性。如果指定了，这些属性就会限制 CA 颁发证书用途的有效性。此限制是基于对象标识符 (OID) 设定的，如 IETF PKIX 第一部分草案中的 ExtendedKeyUsage 扩展所述。 现在，它提供了一种方法，限制对以下组合的使用：

　　　服务器身份验证

　　　客户身份验证

　　　代码签名

　　　电子邮件

　　　IPSec 终端系统

　　　IPSec 隧道

　　　IPSec 用户

　　　时间戳

　　Microsoft 加密文件系统

　　作为 PKI（与 Windows 2000 集成）的一个组成部分，策略机制已定义成支持自动证书登录过程。由两个关键因素控制：证书类型以及自动登记对象。这些均与组策略对象集成到一起，可以基于每个站点、域、机器或用户来定义。

　　证书类型给证书提供了一个模板，并将它与一个常用名称关联起来，以便于管理。此模板定义了许多元素，如命名需求、有效期、密钥生成所允许的 CSP、算法以及应添加到证书中的扩展。逻辑上，证书类型分成机器类型和用户类型，并应用到相应的策略对象中。定义后这些证书类型就可用于自动登记对象及证书登记向导了。
　
　　此机制并不是替代颁发策略的企业 CA，而是与之集成在一起。CA 服务会接收一组证书类型，作为其策略对象的一部分。企业策略模块使用这些证书类型，定义该 CA 可颁发的证书类型。对不符合这些标准的证书请求，该 CA 予以拒绝。

　　自动登记对象定义了域中实体应包含的证书策略。它可基于每台机器和每个用户来使用。可参考证书类型对象，来添加证书类型，它可以是任何定义的类型。此自动登记对象提供了大量信息，用于决定一个实体是否有所需证书，并用于企业 CA 登记这些证书（如已丢失）。此自动登记对象也定义了证书更新的策略。它可由管理员在证书到期前设置，以支持长期操作，而无须用户直接干预。当策略刷新（登录、GPO 刷新等）时，就会处理自动登记对象，并进行必要的操作。

　　智能卡登录（请参见第 22 页）是由与该用户对象关联的策略控制的，其受控方式与密码策略相似。可以将策略设置为启用智能卡登录（仍可使用基于密码的登录），或者设置为实施智能卡登录。在防止对帐户未授权访问方面，后者提供的保护要强大得多。但是，这也意味着，如果用户忘记了他们的智能卡，或试图使用没有智能卡读取器的机器时，将无法登录。

　　应用程序概述

　　本节概述了目前使用基于 PK 功能的许多应用程序。其用意在于，给您提供一个简要说明，以便您在解决现实商业问题时，权衡 PKI 的投资。

　　在创建和部署全球范围内信息交换的解决方案方面，Web 已迅速成为一个关键因素。特别是，商业方面的使用飞快增长。在很多方面，安全是一个重要的考虑因素。特别是：

　　　服务器身份验证 – 使客户能够验证与之通信的服务器

　　　客户身份验证 – 使服务器能够验证客户的身份标识，并用作访问控制决策的基础

　　　保密性 – 在客户与服务器之间的数据加密，可防止其暴露于公共 Internet 链接

　　在解决这些需求方面，安全套接字层 (SSL) 以及刚出现的 IETF 标准传输层安全 (TLS) 协议起到至关重要的作用。SSL 和 TLS 是灵活的安全协议，可在其他传输协议的上层执行。这两个协议依靠基于 PK 的身份验证技术，并使用基于 PK 的密钥协商，生成每个客户/服务器会话独有的加密密钥。它们通常与基于 Web 的应用程序以及 HTTP 协议关联（称为 HTTPS）。

　　在 Windows 平台上，SSL 和 TLS 由安全信道 (schannel) SSPI 提供程序所支持。Microsoft Internet Explorer 和 Internet Information Server 都使用 schannel 来支持此功能。因为 schannel 与 Microsoft SSPI 体系结构集成在一起，所以它可与多个协议一起使用，来支持身份验证和/或加密通信。

　　要充分利用 SSL 和 TLS 协议，还需要客户和服务器都要拥有相互信任的 CA 颁发的标识证书，允许双方相互验证。在这种模式下，证书与证实相应私钥归属的数据一起交换。然后，每一方均可验证该证书，并可用证书的公钥来验证私钥的所有人是谁。随后，证书中的标识信息可用来进行补充的访问控制决策。例如，客户可以决定该服务器是不是他要与之进行商务交易的人，服务器可以决定该客户可以访问哪些数据。

　　Windows NT5.0 PKI 集成了对后一种决策的支持，使之成为 Windows NT Server 的一个标准功能。用户证书可以一对一或多对一的方式映射到 Active Directory 中的安全主管（用户对象）。Schannel 可利用这些信息，给该客户自动合成一个安全令牌，这样，就可使用 Windows NT ACL 机制，来实施对资源的访问控制。这对于服务是有利的，因为它们可以使用相同的访问控制机制，而与所用的客户身份验证机制（PK 或 Kerberos）无关。

　　一旦客户和服务器相互验证了身份后，它们就可以协商决定一个会话密钥，并安全地进行通信。SSL 和 TLS 也常用于不需要客户身份验证的模式。在企业环境中，建议使用相互身份验证，因为它允许使用 Windows 访问控制机制。此外，PKI 大大简化了证书登记和管理，减少了客户的负担。

　　基于 PK 的安全电子邮件产品（包括 Microsoft Exchange）已出现了多年，并获得了广泛应用。这些系统依靠 PK 技术来：

　　　数字签名 - 用于证实电子邮件消息的来源及真实性。

　　　未预设共享机密的批量数据加密 - 用于保护通信双方之间的保密性

　　电子邮件的分布式性质，以及依靠存储 - 转发传输传到多个接收人，都是使用 PK 技术的关键因素。基于共享机密的加密技术的替代方法，对管理和物理安全提出了一些要求，使之变得难以使用。

　　早期实现的一个限制就是，缺少供应商之间的互操作性。在没有适用标准的情况下，供应商实现的系统依靠专用协议、消息编码以及信任假定（有效定义了非互操作性的 PKI）。（备注：尽管 PGP 已获得了广泛的应用，但仍属于此类范畴。因为总的说来，其消息格式不能大规模作为行业内的可互操作安全电子邮件应用程序的基础）。只有最近，才具备了为各主要供应商提供互操作安全电子邮件系统的基础，即使用建议的 IETF S/MIME v3 标准，该标准建立在 RSA Data Security 的 S/MIME v2 提议的基础上。 尽管 S/MIME 还只是草案，但目前已在很多产品中实施，包括 Microsoft Outlook Express 以及 Microsoft Outlook 98，在提供 PK 加密和数字签名（使用 RSA 算法）的供应商之间提供了详实的可互操作性。

　　使用时，这些系统使用用户的私钥，对发出电子邮件进行数字签名。该用户的证书随后与该电子邮件一起发出，这样收件人就可以验证该签名了。S/MIME 给这些证书定义了一个配置文件来保证互操作性，并使用层次结构的 CA 模型，提供可扩展的信任管理。要加密发给另一个用户的电子邮件，需要从以前的电子邮件或目录服务中获取他们的证书。证书验证完成后，就可用其中的公钥，给用于加密电子邮件的密钥加密。

　　随着 Internet 使用的增长，人们更加关注下载活动内容的可靠性，如基于 Windows 的应用程序、ActiveXTM 控制以及 Java 小程序。结果，人们对于这些下载程序的安全性更加关注，因为常常是在没有任何特定用户通知的情况下，就出现了 Web 脚本带来的负作用。正是出于对这类安全问题的关注，Microsoft 在 1996 年开发了 AuthenticodeTM 数字签名技术，并在 1997 年显著改进了该技术，包括带有集成许可模型的 Java 小程序签名。

　　Authenticode 允许软件发行商对任何形式的活动内容进行数字签名，其中包括多文件归档。在下载时，这些签名可用于验证这些内容的发行商以及内容的完整性。此验证基础结构依赖层次结构的 CA 结构，可扩展为全球范围的 Windows 用户；在此结构中，少量商业 CA 可颁发软件发行证书。对于企业方面的需要，Windows 2000 PKI 允许用户将 Authenticode 证书颁发给内部开发人员/承包商，并允许任何员工验证下载的应用程序的来源及完整性。

　　Windows 2000 加密文件系统 (EFS) 支持在 Windows NT 文件系统 (NTFS) 中对存储在磁盘上的文件进行透明的加密和解密。用户可以加密单个文件，或文件夹（其内容必须以加密形式进行维护）。应用程序访问加密文件的方式与访问未加密文件相同。但应用程序不能解密其他用户的任何加密文件。

　　EFS 广泛使用基于 PK 的技术，给多个用户提供文件加密的机制，并支持文件恢复。为此，它使用了 PK 支持“未预设共享机密的批量数据加密”的功能。使用时，每个 EFS 用户生成一个公钥对，并获取一个 EFS 证书。此证书由 Windows 2000 域的企业 CA 颁发，即使 EFS 为单独的操作（数据共享已不成问题时）生成一个自签名的证书也是如此。另外，Windows 2000 支持 EFS 恢复策略，该策略可用来指定可信任的恢复代理。这些代理将生成一个 EFS 恢复公钥对，并由企业 CA 颁发 EFS 恢复证书。此 EFS 恢复代理证书会发布到带有组策略对象的域客户。

　　在使用时，EFS 给每个要加密的文件创建了一个随机的密钥，用于加密该文件。用户的 EFS 公钥随后用于加密此“密钥”，并使之与该文件关联。此外，该密钥的一个副本（用每个恢复代理的 EFS 公钥来加密）也与该文件关联。该系统没有存储该密钥的明文副本。

　　接收文件时，EFS 使用用户的私钥，透明地解开使用用户公钥进行加密的密钥副本。然后，在文件读写操作过程中，还会用 EFS 对文件进行实时解密。相似地，恢复代理可用私钥访问该密钥，以对该文件解密。

　　Windows 2000 引入了基于 PK 的智能卡登录，替代域身份验证所用的密码。它取决于与 PC/SC Workgroup 兼容的智能卡基础结构（该结构于 1997 年 12 月首次引入 Windows NT 和 Windows 95）以及与 RSA 兼容的智能卡（带有支持的 CryptoAPI CSP）。按照 IETF Kerberos 工作组的建议，身份验证过程使用了 PKINIT 协议，将基于 PK 的身份验证与 Windows 2000 Kerberos 访问控制系统集成到一起。

　　使用时，系统将把智能卡插入事件视为另一种启动登录的方法，代替标准的 CTRL + ALT + DEL 安全注意序列。用户随后被提示应输入智能卡的 PIN 代码，该代码用存储在智能卡上的私钥来控制对操作的访问。在此系统中，智能卡还包含用户证书的副本（由企业 CA 颁发）。这样用户就可以在该域内漫游了。

　　IPSec 在 IP 协议层定义了用于网络加密的协议。IPSec 并不需要基于 PK 的技术，它可用共享密钥（通过带外机制安全地进行通信）在网络端点进行加密。但是，IETF IPSec 工作组认为，基于 PK 的技术提供了一个可行的解决方案，可用于创建可扩展的分布式信任体系结构；特别是，可在 IPSec 设备上进行相互身份验证，并可协商确定密钥，而无须预设共享密钥。

　　IPSec 群体（包括 Microsoft）正积极制订可互操作的证书和证书登记/管理协议的标准。尽管已实现了一定的互操作性，但要保证各种 IPSec 设备之间及 PKI 实现之间的广泛的互操作性，还需要做很多工作。Microsoft 致力于使其 Windows 2000 PKI 与这些发展中的标准保持同步。
互操作性

　　理想情况下，PKI 就是“基础结构”。CA 可能会基于标准证书请求协议，颁发一套可完全互操作的证书。随后，支持的应用程序以一致的方式对它们进行评估（包括是否已吊销），并且，整个过程不会有任何语法或语义方面的二义性。

　　工业上，还没有实现这一级别的互操作性。所以，问题在于，什么时候所有这些均能实现呢？当有更多的应用程序使用基于 PK 的技术时，就有可能实现相对无缝的互操作性。现在，SSL/TLS 和 S/MIME 在多个供应商产品中的应用效果很好。但那些较新的和较少使用的应用程序则不能很好地执行跨产品的操作，如代码签名及数字签名形式。另一个令人关注，也更麻烦的问题是：至今还没有技术机制，可用来比较两个不同语言编码的名称。例如，Unicode 允许重要文字以多种等同的形式进行加密。

　　确切地说，这些问题归因于基于 PK 的技术的相对成熟程度。今后几年，至少有两个主要的力量会推动互操作性的发展。

　　经过最初的尝试，今后对基于 PK 的系统的依赖性会不断增强

　　更加强调标准

　　Microsoft 积极投入与 PK 相关的标准开发上，并致力于建立基于“事实”和“理论”标准的产品，以将其 PKI 的操作性提高到最大限度。

　　Internet 标准虽然有助于实现互操作性，但并不保证互操作性。标准的问题由来已久，问题的起因是商业产品部署比合作过程速度快得多。PK 技术领域更是如此；IETF 目前在该领域有多个工作组，他们正在积极开发基于 PK 技术的建议标准。但是，虽然许多应用程序将是这些标准的潜在受益者，但它们早就开始发行产品了。而且，任何标准都不可能预测到每个应用程序的所有要求和依赖条件。因此，即使最综合的标准在实施时也会大打折扣。有鉴于此，互操作性正是市场对标准进行调整的结果。

　　负责定义可互操作 PKI 的基础的 IETF 工作组是 PKIX (X.509)。经过大约整整三年的工作，基本的体系结构已就绪，“Internet 公钥基础结构 X.509 证书和 CRL 配置文件，第一部分” ( http://www.ietf.org/ids.by.wg/pkix.html ) 规范即将成为标准。Microsoft 在 IETF 的该标准中投入了大量工作，并承诺，其 PKI 产品必定与之兼容。获准后，该标准就会成为定义可靠 PKI 的一个重要文件，从而保证了可以以某种标准方式请求、解释和吊销证书。

　　IETF 还在进行其他工作，这些工作将对 PKI 互操作性具有深远的影响。这些工作都是源于对基于 PK 的应用程序的需要，特别重要的有 TLS、S/MIME 及 IPSec。在每种情况中，这些应用程序都发现有必要定义一个满足其需要的 PKIX 子集，或常常需要取代 PKIX 定义的功能。尽管这看起来与设计过程有些脱节，但却为 PKI 设计者创造了一个封闭的反馈环。

　　应用程序相关的标准中，最引人注目的一组是 IETF S/MIME 工作组 ( http://www.ietf.org/ids.by.wg/smime.html ) 的产品，这一点并不令人吃惊。其中，(S/MIME)“加密消息语法”、“S/MIME 版本 3 消息规范”、“S/MIME 版本 3 证书处理”以及“证书请求语法”最为重要。S/MIME 群体，与之前的 TLS 一样，具有从事实标准着手的优点。可以证实 PKIX 也是从标准 (X.509) 入手的；但已有证据表明，它不足以作为可互操作的基于 PK 系统的基础。这意味着，PKIX 第一部分（基础 IETF 标准）正从试用该标准的应用程序中汲取“经验”。反馈过程的一个新示例就是证书链验证。

　　PKIX 第一部分建议（但并非规定）使用证书链验证算法。对当前 Internet 草案的一个诠释就是：即使存在诸如 AuthorityKeyIdentifier（颁发人公钥）等信息，也必须始终实施名称链（即，将证书颁发人名称与父证书的主题域中的 CA 名称进行匹配）。但是，此方法的一个内在问题就是，它并不适用于两种重要的公钥环境：一个环境是：没有可用目录来按名称查找 CA 证书；更复杂的则是，处于交叉验证 CA 的复杂网中。只是当应用程序试着概括自己的链验证算法，却发现不能这样做时，PKIX 工作组才会遇到此类问题。它的正面效应是反馈环在起作用，并且新机制立刻就会在标准中有所体现。

　　在对 PKI 互操作性认识方面，还有一个重要的“强制性功能”。国家标准协会 (NIST) 已成立一个互操作性工作组，由 AT&T、CertCo、Certicom、Cylink、Digital Signature Trust、Dynacorp、Entrust、Frontier Technologies、GTE、ID Certify、MasterCard、Microsoft、Motorola、Spyrus、VeriSign 以及 Visa 组成。该工程的目标是：保证成员的“PKIX 第一部分”的不同实施形式间存在最小的互操作性。NIST 对于该论坛能否解决新 PKIX 标准的二义性和/或错误问题，持乐观态度。

　　定义 PKI 标准的另一个因素与 IETF 无关。这是一组事实上的加密消息标准 (PKCS)，由 RSA 实验室开发和维护 ( http://www.rsa.com/rsalabs/html/standards.html )，它已广泛部署到产品中。PKCS 标准在 1990 年首次发布，它包含加密消息的语法。与 PKI 最密切相关的标准是 PKCS-7（加密消息语法标准）和 PKCS-10（证书请求语法标准）。RSA 标准的重要性在于，它给互操作性提供了一个易于理解的基本框架。事实上，当 PKIX 工作组提出另一个用于证书管理的标准时，S/MIME 工作组就已创建了自己的基于 PKCS 的提案。这种反应是 IETF 的典型作法，反映了市场的需求。事实上的标准常常是最好的标准，Microsoft 在其现在的 PKI 实现形式中使用了这些标准，将互操作性提高到了最大。

　　希望标准过程为所有互操作性打好基础的想法无可厚非，但最终许多供应商都只是将标准的某个子集添加到产品中，创建可互操作的解决方案。在决定 PK 互操作性时，市场需求起作用的较好例子就是决定了信任模型的运做方式。

　　“基础结构”一词指 PKI 可彼此链接起来。例如，如果公司内某个部门为其应用程序选择了供应商 A 的 PKI 模型，但后来公司选择了供应商 B，用于自己的邮件系统，那么，必须有某种自然的重叠才行。当公司 A 和 B 要有选择地将其 PKI 模型合到商业专用的外部网时，情况会更复杂一些。技术复杂性在于：必须映射实体之间的信任关系（谁信任谁，为什么信任），还要始终跟踪这种关系。目前，有三种用于信任关系如何工作的模型，相互竞争：

　　　根层次结构（如，VeriSign、Microsoft 以及 Netscape）

　　　网络（如 Entrust）

　　　Web（如 PGP）

　　将这几种模型在文中一起讨论时，在如何建立和维护信任关系方面，每种信任模型均与其他模型有所不同。这涉及到这些模型是直接创建的，还是通过中介创建的；在这些技术和商业模型后面，则是关于 PKI“应该”如何工作的牢固信念。在标准中，要使某些基本内容都达成一致是不可能的，因此，不同信任模型可能不会执行完全无缝的互操作。至多会在给定的 PKI 中，提供充分的灵活性及辅助管理工具，使用户能够以某种方式把那些独立的信任模型集成在一起，以满足特定的商业需要。
Windows 2000 PKI 的准备工作

　　基于公钥基础结构的安全是相对新鲜的事物，实际 PKI 部署的现实示例和个案研究几乎没有。要更广泛部署 PKI，公司必须培训用户，了解密钥/证书管理问题以及与 PKI 有关的风险和责任。很多的公司可以对这些问题提供帮助。在此有一个列表：

http://www.Microsoft.com/security/partners/ 。

　　用 PKI 安全获益的最常用应用程序领域之一就是电子邮件。使用 S/MIME（它基于 PKI），客户就可以发送经数字签名和加密的电子邮件。使用基于 S/MIME 的电子邮件，公司就可以着手部署 PKI，并积累经验和专业知识。

　　Microsoft 建议，要部署 PKI 的客户最好从 Microsoft Exchange Server 5.5 (SP1) 和提供基于 S/MIME 电子邮件的 Microsoft Outlook '98 入手。Exchange/Outlook 中 PKI 的重要功能有：

　　　具有内置密钥恢复功能的“密钥管理”服务器

　　　X.509v3 证书服务器

　　　基于 LDAP 的交换目录服务

　　　使用 CryptoAPI 的 S/MIME 客户 (Outlook)。

　　　带有 Outlook 的 Microsoft Exchange Server 5.5 提供了安全电子邮件以及密钥恢复功能，能设置多个“密钥管理”服务器以及一个证书信任层次结构。

　　Microsoft 将为 Exchange 用户提供一个迁移路径，使之移到更通用的 PKI 基础结构（Windows NT 5 提供的），它包括一个通用企业目录服务 (Active Directory) 以及通用企业证书颁发机构。在以后版本中，Microsoft 将使“密钥管理”服务器成为一个更通用的系统功能，使其他应用程序也能使用该功能。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 点击这里给我发消息
标签： 
相关文章推荐
新的分享
章节导航