互操作性
理想情况下，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 将使“密钥管理”服务器成为一个更通用的系统功能，使其他应用程序也能使用该功能。
