auto_pki

自动pki：PKI资源的发现系统

摘要：PKI的中心目标是在分布的用户间能够进行信任判断。虽然证书在做出的决定中起中心地位，但是一个PKI用户需要的不仅仅是证书的知识。最低限度，可信第三方必须能够定位一些关键的参数，如证书的存储库以及证书验证服务器相关的可信路径都在考虑范围内。其他方案的用户可能需要其他资源和服务。奇怪的是，在现实世界中部署的X.509 PKI中定位这些资源和服务仍然是一很大的没有解决的难题。本文为证书服务提供者（Certificate Service Provider (CSP)）中可用的服务和数据存储的自动发现，提供了一个新的灵活的解决方案并展示了一个设计原型。本文的贡献将是现实中的PKI更接近其要达到的目标。

关键字：PKI，服务发现，认证中心，数字证书。

引言：

PkI的主要目的就是能够在分布式用户之间建立可信赖的判断。PKI的核心依赖于证书：公钥持有者的属性与公钥之间的签名绑定。高效应用PKI需要更多地应用这些证书。然而高效地应用这些这些证书还需要一些其他的服务，比如:OCSP服务，CRL仓库，时间戳服务等。因此，客户端方的PKI工具需要能够发现这些服务，服务器端方PKI工具需要提供这些服务并促使客户端工具可以发现它们。

不幸的是，由于糟糕的用户接口和过度细节化的配置，使得为完成这些任务而对这些工具的配置，不管对服务器管理员还是最终用户来说都是比较困难的，。认证中心很少在他们的官方网站上公开他们的访问细节，甚至它们提供的服务和库的URL这样基本的数据也被省略了。这样的话，如果认证中心提供了一个新的服务（例如OCSP），或者是一个新的数据存储（例如LDAP），用户和管理者很难了解到这些改变，此外，证书一旦发布就不能再标记新的服务。这与用户和应用软件没有直接接触仍可以很容易意识到新的服务不一样。这个问题对来自企业的用户比发行组织的影响更大，因为他们在关于CA的实施以及服务定位方面知识有限。

本文展示了一个新的途径，提供一种灵活的方式，从一个CA中自动发现它提供的可用的服务及数据存储。这种灵活性也将促进不同基础设施的互操

作性。第二部分展现了我们解决方案的核心方面：一个新的且更简单的PKI资源查询协议(PRQP)的设计和实现，它将使得管理员和最终用户的PKI的管理变得简单。第四部分评价了原型的性能及我们方案的效率，第五部分回顾了其他的解决方案，第六部分总结了我们将来工作的方向。

2 PKI资源查询协议(PRQP)

为了解决这个问题我们定义了一个PKI资源查询协议(PRQP)，这样就可以从一个特定的CA中找到任意有效的资源。在 PQRP中, 客户端和资源查询权威(RQA)相互交换一组信息。

1.客户端给服务器发送一个申请资源令牌的请求，

2.服务器给请求实体发送一个应答响应请求。

客户端精确指定其感兴趣的数据时，客户端在它发出的请求的资源标记中嵌入0或更多的资源标示符（OIDs）----指定它需要的CA资源的子集。如如果客户端没有指定任何服务，通过在请求中提供一个空的OIDs列表，那么特定CA 中所有可用的资源都应该在应答中被服务器返回。这里的资源可能是今天偶然嵌入证书中的项----例如CRLs、OCSP、或SCVP等的URLs，也可能是如CA网站地址，订阅服务（the subscription service），或撤销请求等等。

图1显示本协议的一个例子：一个SSL Web服务器获取一个用户证书的撤销状态（这里Web服务器是PQRP请求客户端）。

第一步，Web服务器从浏览器获取用户证书。

第二步，Web服务器查看证书中颁发者的标示符，并构建一个PRQP请求，询问RQA，颁发的CA其OCSP服务器的地址。

第三步，RQA给Web服务器提供在RQA中配置的请求服务地址。

最后，按照正常的有效过程网络服务器将通过给定的URL直接访问 OCSP服务器。

在这个特殊的例子中，仅需要被请求的OCSP的URL，因此仅此服务的地址放入响应中。因此

第四步，Web服务器通过提供的URL直接访问OCSP服务器，继续正常的验证过程。

2.1资源查询权威 (RQA)

在我们的协议中RQA 扮演着两种角色。

第一CA可直接委托一个RQA应答有关它的证书的问题，CA通过给RQA 颁发证书----用一个唯一值嵌入extendedKeyUsage (i.e.prqpSigning)里。那么RQA 将给予给RQA颁发证书的CA的请求，提供权威的应答。另外，RQA可作为受信任的权威Trusted Authority (TA)。（这里“trusted”受信任，意味着客户端简单地选择信任RQA的决定）。在这种情况下，RQA可提供有关多CAs的应答，而不需要得到这些CAs的认证（certified）。在这种情况下，应答被作为非权威的，意思是RQA和CA间没有直接信任关系。如果RQA作为TA，特定的扩展（prqpTrustedAuthority）应呈现在RQA的证书里并且它的值应设为真。在这样的配置情况下，RQA可以被配置为不同的CA应答，这些CA可能是也可能不是和RQA具有相同的PKI。

2.信息格式

一个PRQP请求需要包含了几个不同的元素，协议的版本用来区分客户端或RQA能过处理请求的格式。(目前， v1 是唯一的可用的版本)。 NONCE （可选）

是一个随机的足够长的数，客户端确保只产生一次。资源要求令牌（ResourceRequestToken）用于识别资源（例如CA或服务本身）。最大响应数（MaxResponse）标志符告诉RQA可能在响应中处理的资源要求令牌的最大数目。

资源请求令牌包含了CA的目标证书标识符和可选的一个或更多个资源标识符字段。如果在请求提供一个或更多个资源标识符，RQA应该报告每一个请求服务的地址。如果在请求中没有资源标识位出现，响应返回特定CA所有有效的服务地址（这受最大响应数目约束）。扩展将可能用于将来的协议的增强。

PRQP 响应也包括几个部分。同样的，协议的版本也标志了响应的版本

。NONCE，如果存在的话，它绑定了对特定请求的响应。NONCE的应用仅仅在有认证的响应，并且它的值必须从相应的请求中直接复制过来的。状态数据结构(PKIStatusInfo) 携带了响应的状态以及出错原因的描述（如果出错的情况下）。资源响应令牌用于为请求资源提供指针（每一个请求的服务都有一个指针）。如果需要的情况下，可选择的扩展也要求被加入。

讨论：当设计协议时，我们特别重视以下几个方面：简易，安全，信息复杂度，以及RQA地址分发。

协议的一个重要设计目标就是简单。为了实现这一目标，它的应用不会给PKI管理增加额外的负担，也不会给应用软件和开发者造成负担。

安全是另一个我们主要关心的问题，PRQP提供 URLs给PKI资源，它仅仅提供的是信息和服务的地址而不是实际的信息。。通过URLs来收集需要的信息和验证信息（例如签名和SSL）这些工作仍然保留给客户端。出于这种考虑，为了提供请求和响应的灵活性，NONCE和签名是可选择的，同样，在NONCE不被客户提供的情况下，提供预计算也响应是可能的。如果在客户与RQA 之间的传输层有一个权威的安全信道（例如 HTTPS 或 SFTP），那么在请求与响应之间的签名也可以被安全的省略掉。

我们也分析信息的复杂性层次。有一些形式的服务，例如 delta CRLs,可以通过数据下载被直接发现。然而如果有一个客户端在寻找一个特定版本协议或数据类型，当正在请求的客户支持这个版本时，一个fine-grained的查询系统，可以通过允许数据下载来减少服务器负担。

我们为PRQP 信息格式考虑两个不同的候选：扩展标记语言(eXtensible Markup Language (XML) )和唯一性编码规则（Distinguished Encoding Rules (DER)）。采用抽象语法符号Abstract Syntax Notation (ASN.1)来描述信息结构可以让软件开发者提供选择DER 或XML-based任意一个去实现协议。然而当我们考虑与已存在的软件及API的兼容性，认为基于DER的PRQP实现是最好的

选择。此外DER 编码信息比XML 的编码信息在规模上小并且几乎所有的已知的PKI应用都已经支持它。

最后一点（但这并不意味着我们对它的考虑比其他方面少）：RQA的地址的分发。我们正视两个不同的方法。第一个选择用AIA和SIA的扩展来提供指向RQA的指针。虽然这个方式看起来与 5.1中的考虑有差异，我们相信仅使用一个扩展就可以提供一个简便的方法去分发RQA的地址。虽然这是一个十分有效的解决方案，但它需要发行的证书的大小却更小。第二个选择是：尽可能多的应用LANs和通过DHCP的方式来提供RQA的地址。当可信赖的RQA在本地存在时，这种方式将会被最大的应用。这两种技术可以被结合在一起。

3 原型

为了使我们的解决方案付诸于实践，我们构建了自动PKI，一个库和可以在在真实的PKi应用中支持实行PQRP的软件的原型实现。自动PKI的基本思想就是给客户提供PKI资源的地址，并可以使PKI配置发行的管理者和用户更加舒适的使用。

我们的系统不同于其他先前的系统，是因为我们的目标是提供一个简单的定位服务的不需要第三方验证和和代理服务（例如不需要提供像SCVP的服务）。

自动PKI原型由三个原理性部件构成：(图2): 一个扩展的DHCP 客户和服务器，一个资源查询权威服务器，和一个PRQP库。

1.1.扩展的DHCP 客户和服务器

为了使PRQP适应于实践，我们需要分发可用的RQA的地址，一个很自然选择就是在数字证书中直接包括AIA和SIA的扩展来提供直接指向RQA的指针。如果这个目标证书的CA提供一个RQA的话，那么这个方式就是有效的。扩展的内容指向了一个有用的RQA，这样客户端就可以通过查询CA来直接发现由CA提供的的服务。

然而今天我们还不能依赖在证书中有RQA指针存在。因此我需要一个方法给客户端提供一个本地RQA的指针来查询没有RQA的CA的资源。事实上

，如果证书中没有RQA地址的话，客户端可以使用默认配置的那个。

DHCP协议在实现这个目的上提供了足够的灵活性。特别地，他允许客户端在需要时请求服务器提供特定信息。通过修改配置（在客户端和服务器增加特殊参数），它可以通过在一个系统范围内的配置文件存储提供的地址，应用程序可以从中得到RQA的地址。图3即是PRQP的一个事例配置文件的例子。如果没有可用的DHCP的服务器，配置可以通过一个简单的用户接口来实现，这和许多系统中，DNS的基本配置一样普通。

3.PRQP库

PRQP库可以被应用软件调用来发现一个存储库或者服务的地址。库的实现为应用程序提供了易于使用的的函数，他们可以产生和解析请求、响应以及与目标RQA的通信。本库用 OpenSSL来实现加密操作，比如签名的产生和确认。

库使用DHCP客户端产生的配置文件来检索RQA的地址。除了几个底层的函数需要用来管理PRQP数据结构，我们也实现了几个高层的函数来帮助开发者们在他们的应用程序中集成PRQP；

我们为这个库建立了一个命令行工具，它接受X.509证书和作为输入的配置选项（比如请求资源的名字），以及以PEM/DER或者人们可读的格式输出响应。输出数据应该可以被任何调用程序解析来使用响应的数据。

当命令行工具执行时，它执行以下几步：

（1）验证用户的输入和连接被请求的服务器或数据的证书，

（2）建立PRQP请求，

（3）解析全局PKI配置文件，

（4）通过TCP套接字，来连接配置了的RQA服务器。

（5）通过HTTP协议来给服务器发送请求，具体地，我们使用POST 方法来上传给服务器的请求，

（6）回滚和解析RQA响应，

（7）将请求和响应保存在不同的文件中。

（8）以文本格式打印响应细节。

通过应用客户端库，以上六步中的两步可以被自动执行。为了这个目的，我们

这个库的getpkiresources函数可以处理所有的PRQP细节并可以将URL结构栈返

回给调用函数。扩展的DHCP产生的一个全局PKI配置文件/etc/pki.conf来直接

存取RQA的地址，应用程序不会再需要关于PRQP的其他内容。

3.RQA服务器

由于在基本设计方面 PRQP和 OCSP有许多类似之处，我们决定用OpenCA [5] OCSPD [6]包来实现我们的PRQP响应器。这个软件在HTTP的基础上，使用OpenSSL和实现OCSP响应。为了实现PRQP，我们根据PRQP库提供的功能修改这个软件：ASN.1具有利用OpenSSL的输入输出抽象层来解析和保存PRQP数据的功

能；处理请求和响应的功能；网络通信具有管理客户端与RQA之间使用简易HTTP POST 方法的功能。

由于 OpenCA的OCSP响应器遵从简易设计的原则，我们可以重新使用

部分原始代码来建立PRQP响应来代替 OCSP 的。当前，我们只支持HTTP 之上的PRQP。我们也为PRQP的请求和响应指令分别定义了

“a pplication/prqp?request”和“application/prqp?response” 两种HTTP 内容类型。

通过选择适当的设置，我们的服务器也可用作为一个TA来支持多级CA。每

一个配置了的CA和它提供的服务，都在分开的配置文件之中被组合在一起。因

此很容易给服务器增加新的CA。

4 评价

4.1 性能

为了测试这个系统，我们建立了一个测试台，它由两台通过 Fast

Ethernet LAN连接的计算机组成。在第一台机器上 (Intel Core Duo @ 2.13GHz, 4GB Ram) 我们安装 PRQP 库和PRQP 服务器，在第二台机器上(Intel Pentium M 600MHz, 512MB Ram) 我们安装PRQP库和命令行工具6两个机器都运行在具有Linux 2.6.18.3 Kernels内核的 Fedora Core 6发布版系统上。在RQA服务器上，我们配置了指向CA提供的服务的指针。每一个响应都是用 RSA算法和

1024位密钥来数字标记的，这其中没有使用加密硬件。

在客户机服务器上，我们运行几个测试，这几个测试使用命令行应用软件来对RQA服务器进行查询。特别是我们查询服务器时使用了一个增长着数目的请求指针，并重复每个实验50次。虽然PRQP在他们的有效期内可以提供响应缓冲，但在我们的测试中却没有用到响应缓冲。响应的次数在表4/a中有描述。

结果显示，我们系统引入的开销(voerhead)是小的，几乎可以在今天的应用软件中被忽略。并且响应时间没有随请求的增多而增加。

我们也分析了PRQP的请求和响应的大小。收集的数据在表4/b中有描述。产生请求在规模上比响应小。这主要是应为我们决定不对请求进行签名和在请求中包含任意证书（因为我们将它视为最通常的情形），但是服务器为它的响应签名还有要包含他自己的证书。

我们也注意到响应的规模比请求增长的速度快。它很容易解释，由于请求使用一个单独的OID来标志服务，同时响应需要一个更复杂的数据结构来构成实际的定位器和验证信息的日期。

4.解决这个问题

为了证明PRQP解决资源的发现问题，我们分析了流行的被广泛部署的的CA 证书的轮廓。

我们的分析集中在两类不同的证书集上，分别是被嵌入到流行浏览器(例如Firefox, IE and Konqueror)和邮件用户代理(i.e., Thunderbird, Outlook and KMail)中的证书，以及美国和欧洲一些大学的主要web页中使用的证书。表1 展示了来自第一个集合的证书的研究的结果。大多数的证书不提供任何指针，这给应用软件正确的到达与PkI相联系的资源很困难。例如在Firefox/ Thunderbird证书中有66%的证书没有指针指向任何的服务器或数据存储单元（甚至是CRL），在IE7/ Outlook中，这个比例上升到了82%。这个问题在涉及到证书的生命周期时更加的严重。表5 展示了分析的主要证书有效期在20和多于20年。事实上，大多数证书的生命周期都比典型的URL长，于是通过简单地列出证书中的URL列表来解决证书的资源发现问题是危险的。两个分析的结合说明了更新嵌入的CA中的内容是比较困难的。PQRP将解决这一问题。

为了验证这些结果是否由于应用软件政策的需求而产生了偏移，我们把注

意力转向第二种证书集，通过访问所有支持应用HTTP协议大学的站点，我们可以单从服务器中导出证书列表。在获取所有的证书以后，我们分析了结果，在2013所美国大学中，有1016所支持HTTPS协议。获取的证书基本上是外面的组织颁发给大学（91.4%）。这个证书集中，许多证书指向了相同的提供

者，仅35个CA给929所大学提供证书。大多数的证书提供指向CRL和 OCSP服务器的指针，并且大多数时候在穿过不同的组织时，它们没有变化。我们认为即使存在一内部CA,还使用从不同商用提供者提供

的证书, 是由于缺乏PKIs间协同操作的真实的解决方案。

来自于欧洲大学的结果是非常不同的。在2541所大学中，只有745所支持HTTP协议。然而与美国不同的是内部发行的证书超过了外部供应商发行的证书。我们计算过，414个不同的提供者中，就有332个是内部的。在这种环境中，有许多不同的供应商，我们发现超过54%的证书没有提供任何指向PKI资源的指针。从这个结果来看，即使对于EE证书来说（例如来自大学的站点），仅仅通过简单地列出证书中的URL列表来解决资源发现问题是不可行的。

OASIS开展了一个关于PKI部署的调查。这个调查显示应用软件和操作系统经常缺少对PKI的支持，而且当这些支持存在时，总是不一致，某种意义上说在支持什么上有很大不同。这个调查也显示了：当前的PKI标准是不充分的，如它们太复杂，并且不同的提供商很少能互操作。我有意思的是我们注意到报告中列出的10个问题中有7个和PKI可用及互操作有关。

P PRQP能帮助部署PKIs和使用PKI的应用，通过提供灵活的方式来自动发现CA可用的服务和数据存储。通过提供这样一种机制，支持PKI的基本操作（例如证书的验证）可以很容易的在操作系统层被执行。

5 相关工作

我们的工作主要集中在PKI资源查找问题上。此问题不单是包含证书获取，也包含当资源提供者提供的资源可用时发现新资源。在从前的工作中，我们知道客户得到PKI数据指针的三个基本方式：采用特殊的证书扩展，查找易于访问的库（例如DNS，当地数据库等），和修改现存协议（例如Web服务）。

5.1证书扩展

为了提供指向发表数据的指针，CA可以使用权威信息访问Authority Information Access (AIA) 和主题信息访问Subject Information Access (SIA) 扩展作为RFC 3280 [10]中的细节。前者可以提供证书颁布者的信息，而后者在CA证书的内部携带所提供服务的信息。主题信息访问扩展能携带一URI指向证

书库及时间戳服务。因此，此扩展允许不同的协议（如HTTP, LDAP or SMTP）访问服务。

虽然鼓励利用AIA 、SIA扩展，但是它们仍然没有广泛部署。主要原因有两个：第一，可用的客户端缺乏对此扩展的支持。第二，扩展是静态的，即不能修改。真要去修改或添加新的扩展，为了使用户及应用意识到新的服务或服务的取消，证书必须重新颁发。

除非周期性的发行，否则这对于终端实体证书（EE）来说是不可行的，但是它对于CA证书本身来说却是可行的。CA可以保留同样的公钥和名字，仅仅需要在新证书的扩展中增加新值给AIA扩展。如果用户有规律获取CA，而不是缓存它，这样就可以促使它们发现新的服务。虽然这样可行，但如果客户端的数据库中存在证书,他们并不会去查询CA证书。

在任何情况下，既然URLs趋向于经常变化，而证书又是长时间的，经验告诉我们这些不变的扩展指向并不存在的URLs。而且，考虑到颁发证书的实体和运行服务的实体并不相同，那么在一个服务的URLs改变时颁发CA重新颁发所有证书并不可行。因此依赖使用AIA和SIA扩展来查找有效的服务和库是不明智的。

在表2中，我们报告了大多数普及的应用中AIA扩展的比例。正如预期的仅仅OCSP指针存在于很少数量的证书中（如Firefox/Thunderbird 11%，

IE7/Outlook 和Konqueror/KMail 0%），同时没有提供其它指针指向其他服务。

5.2DNS 服务记录

在DNS [11]中SRV记录或服务记录技术是通过直接给服务器提供指针. 正如在RFC2782[12]中定义的，引入此种类型的记录允许管理员执行的操作和我

们本文中提出解决的问题相当相似，如容易配置PKI发现服务。

基本思想是使客户端从DNS查询一个特定的SRV记录。例如，如果一个SRV敏感的LDAP客户端要发现一个特定域的LDAP服务器，它执行一个DNS 查找查找“_ldap._https://www.wendangku.net/doc/3a14043517.html,”（“tcp”意思是客户端请求一个TCP可用的LDAP服务器）。返回记录包含优先权、权值、端口及那个域里服务目标。

采用这个机制的不足就是在PKIs中,和 DNS不一样，它没有固定的请求来命名已用的空间。在大多数情况下，DNS结构和的证书中数据之间并不相符

。唯一的例外是证书的主题应用了区域组件(DC)属性。

区域组件属性用来指定特定领域组件中DNS的名字。例如“https://www.wendangku.net/doc/3a14043517.html,”这个域名可以表达成使用dc=com, dc=example格式。如果CA的主题字段应用这种格式，发行者字段将允许客户端应用软件查询DNS来获得存储了库和服务信息的域。

然而，在当前情况下，这种应用是非常不同的。客户端通过 DNS记录去映像一个数字证书是很困难的，因为DC格式并没有被CA广泛采用。据我们分析所知：仅仅IE7/Outlook 中存储的证书用到了域组件来提供证书和网络域（Internet Domain）之间的映射。

最近IETF PKIX 工作组 [13]提出一个新的提议，目的是使得应用DNS记录来定位PKI库的用法标准化。经过讨论得出，虽然客户端可以实现从一个特定的e-mail地址定位LDAP服务，但是作者不能通过规范找到在DNS中发布服务的人。

另一个说明这个解决方案不可行的例子在图6中被描绘。图6描述了一个很普通的方案：组织A为它的Web服务器从一个运行CA的组织B那买了一个证书。不管是证书中有区别的名字还是证书中其他字段的内容(比如说主题名字选择subjectAltName)都不能提供一个合适的指向可以产生RR记录请求域的指针。

发行证书的组织在需要升级时，甚至控制不了DNS记录。在我们这个例子中，如果RR记录被放在DNS之中，而Web服务器的证书通过通用名字（CN）属性如”my.server”来识别这个域，那么这个证书的纪录不被发行组织B控制的。

5.Web 服务

Web 服务[14]是一项允许应用软件交换数据的新技术，它应用三种不同的

组件实现：简单对象访问协议SOAP (Simple Object Access Protocol) [15],网络服务描述语言WSDL (Web Services Description Language) [16, 17] 以及通用描述发现集成UDDI (Universal Description Discovery and Integration) [18].

通过使用 UDDI, 应用软件可以发现有效的网络服务(使用WSDL语言来描述)并通过应用SOAP交换数据来相互影响。虽然Web 服务器在适应性与复杂性之间

有一个好的权衡(e.g. 比如CORBA [19] 提供更大的适应性但是

CORBA-oriented 应用软件执行起来更困难。)，但是交换信息的格式仍然很复杂。事实上使用 XML [20]处理通信相比起其他其他二进制格式（比如DER [21, 22]）时显得很复杂。这些方面应该特别加以考虑，尤其是应用到移动工具的时候。XML格式的信息需要大量的计算能力来正确处理同时也需要很大的带宽（信息通常在规模上会比较大）。以我们的经验来看一段采用 DER格式编码的信息比采用相应的XML格式编码要在规模上少30%。

另一个应该考虑的方面是使得与现有的软件整合简单化。每一个处理数字

证书的应用软件都已经用 DER实现，如果不是这样的话， XML 也会被广泛的支持。

5.Local Network导向的解决方案。

另一种提供可靠信息的方法是使用现有的服务定址协议例如 Jini [23,24], 即插即用协议 Universal Plug and Play protocol (UPnP) [25,26] or服务定位协议 Service Location Protocol (SLP) [27–29]。

Jini 用来定位和与基于JAVA的服务交互。Jini的不足之处是它与特定的程序化语言绑定并且需要大量的JAVA特定机制 ( 比如对象串行化, RMI [30] 以及代码下载) 来实现功能，。而且，它提供了许多非常复杂但在我们的环境中却不需要的通信服务。

和 Jini一样， UpnP 提供了一个在网络上定位服务和与服务交互的一个机制。UpnP 使用了像基于 HTTP 上的XML (SOAP) 的各种不同技术，这使得它也非常的复杂。UpnP协议存在一个服务发现子集叫做简单的服务发现协议(SSDP)[31],它在 UDP 上对 HTTP进行操作。和 UpnP一样， SSDP 被认为是在小环境中操作，而且管理员会从局域网中阻塞UpnP,或者由于安全原因禁用它，同样地，他们也阻塞/禁用 NetBIOS来离开当地的网络。

ETF定义了 SLP来提供一个提供独立于语言和技术的服务定位机制。然而

，一些协议的一些问题使它并不是解决我们问题的一个比较好的选择。最重

要的一点,免费可得的参考实现 [32] 存在，协议的实现还是非常复杂，此外SLP 的部署很少而且他的有关他的扩展的知识很少。

真正地，我们相信给 PKI 资源位置定位定义一个特定并且简单协议的定义是不可或缺的，这样它才容易整合进入现有和将来的应用中, 尤其是那些计算

能力和通信带宽有限的移动装置。

6 结论

封闭的 PK孤岛之间缺乏互操作是一个非常紧急的问题而且急需解决方案。

可测量我们的系统的进步的环境的一个例子是网格社区,它已经大量的利用了X.509。最敏感且待解决的技术上议题之一是在大网格中有效收回数据和确认服务。网格安全基础(GSI) 在因特网上使用代理证书，允许一个实体暂时把它的权力委派给远程进程或资源。这样的一份证书由终端实体（EE）证书起源并签署。因此为了验证EE证书的有效性需要一个简单的方法去查找有效的服务和EE 证书的 CRLs。管理员决定一组CAs, 来使使用者可以自由的存取被分享的资源.

借助PRQP可以自动配置确认服务，它主要通过提供更新了的OCSP、 CRLs 库、或其他的服务(例如SCVP)的URL. 这会增加数据的有效性和安全地使用存在的 PKIs来进行网格计算的可能。甚至可信的第三方法如在 2005 年十月建立的国际的网格信赖同盟 (IGTF)[33],可以运行一个中心的RQA为所有的使用者和资源管理者提供同盟CAs的URLs。

无线电是 PRQP 的部署的另外一个非常有趣的方案。开放环境 (比如说大学和企业的无线局域网) 的数字证书的用法在操作性方面受到很大的限制。访问点(或者半径服务器) 可以支持使用PRQP发现服务并重新取得需要的PKI数据来验证客户证书。举例来说，为支持学生或者教授访问大学的网络可以简化管理，减免验证基础设施的复杂性(比如 EduRoam[34])和免去向第三方委派证书有效性检查.

PRQP协议提供一个特定的PKI资源发现协议并且为PKI资源发现框架提供一个起点，这里不同的RQAs协作访问本地不具备的数据。我们下一步的研究将评价使用经过验证了的P2P网络在RQAs间分发可用服务的URLs。这些P2P网络中的权威将和其它对等结点分享配置数据。这里，每个客户端用配置中的一个RQAs作为进入点，它们所有的请求都发送给它。因此P2P网络将映射网络地址到服务特像DNS映射逻辑名称到IP地址。当前的研究这样一个网络的研究及实现上。