摘要我们提出一个架构来扩展LDAPServer的功能,原.docVIP

文章编号：1009－8119（2005）10－0041－02 利用LDAP目录解决证书注册中的POP问题 姜华阳 （北京理工大学计算机科学工程系，北京 100081） 摘 要 提出利用LDAP目录解决公钥基础设施中拥有证明问题的解决方案，并与其他的解决方案做了比较，分析了该方案的可用性。 关键词 公钥基础设施，拥有证明，目录服务，LDAP Using LDAP Directory to Solve POP Problem in Certificate Registration Jiang Huayang (Dept. of Computer Science and Engineering, Beijing Institute of Technology, Beijing 100081) Abstract This aritcle propose a scheme of using LDAP Directory to solve POP problem in PKI, compares with other schemes, and analyses the usability of the scheme. Keywords PKI, POP, Directory services, LDAP 1 前言 公钥基础设施（PKI）基于Diffiee和Hellmann提出的公钥加密算法，实体注册PKI服务以获取PKI提供的公钥加密和数字签名服务。PKI最典型的产品是数字证书。把公钥和拥有相应私钥的实体绑定，通常生成符合X.509和RFC3280标准的证书。PKI一般由两部分组成，即RA和CA。 在PKI系统中RA的作用是通过检查终端实体的凭证来注册实体，实体可以自己生成密钥对或者由CA生成密钥对。第一种情况(可以是签名或加密密钥对)，实体在注册时把公钥提交给RA，再由RA传给颁发证书的CA；第二种情况(只能是加密密钥对)，CA生成密钥对和证书，并交给实体。两种情况CA都要保证证书被颁发给拥有相应私钥的实体。 在提交证书申请时，实体必须提供POP(拥有相应私钥的证据)。如果密钥对用于签名，可以在提交证书请求的同时提交使用私钥对某个值(证书申请者的名字、所提交的公钥等)所做的签名；如果密钥对用于加密，则不能用加密密钥来签名。考虑到完成POP所需的往返消息个数，可以用CA颁发的证书所包含的公钥加密证书，这样，证书就只能被拥有相应私钥的接收者读取，但如果证书用户很多，CA的负担会很重(由于要比较CA收到的解密的证书和原先所颁发证书是否一致)。我们提出的基于LDAP目录的解决方案简单有效，并且在完成POP的同时也激活了证书(是否激活及何时激活证书则由实体决定)。 本文在第二节讨论了证书请求消息的标准和实现POP的几种提案，第三节讨论了提出的解决方案及其可用性。最后得出结论并讨论了未来要做的工作。 2 证书请求消息和POP 一般PKI环境下终端实体提交证书请求有专门的证书请求语法格式。有如下几个标准： 最常用的是语法是PKCS10，定义了一套终端实体向CA提供注册信息以生成证书的语法。PKCS10消息中可以包含证书处理过程中及随后可能要用到的其他数据。该语法要求用数字签名来保证所提交信息的安全性。可以使用私钥签名某个值发给CA或RA，这样CA/RA可以通过验证签名来完成POP。然而，该语法并没有考虑加密密钥对的情况，这样，加密密钥对就需要另外处理。 另一个标准语法是CRMF。它对签名密钥对的处理和PKCS10不一样，但它提供了三种加密密钥对的POP方法。第一种是让CA拥有实体的私钥；第二种，也就是直接方法，CA和终端实体交换质询/响应信息(CA发送公钥加密的某个值给终端实体，终端实体解密后发回解密的值给CA)，这样做需要额外的消息传递。第三种，间接方法，用证书包含的公钥加密证书，让终端实体用一条确认消息发送回解密的证书，以证明实体拥有相应的私钥。 CMP也有相似的解决方案，CMS也在证书管理消息中包含了加密密钥对情况的处理。CMC规定了用于POP的一套机制，但它要求两次以上的消息传递，因而复杂了POP的处理过程。而XKMS对于POP问题则没有考虑签名密钥对的情况。 以上几种关于POP问题的解决方案都有缺点：要么终端实体的私钥被暴露给CA，要么把证书的处理过程变得很复杂。 加密密钥对的POP非常重要，CA颁发了一个包含公钥的证书，如果终端实体没有相应的私钥，或相应的终端实体根本不存在，这样的证书通常是不可用的。使用这样的证书包含的公钥加密的消息不能被实体解密。因此一旦原来的消息(明文)被毁坏就无法从密文中恢复。因此，只有确认证书拥有者拥有相应的私钥才能激活相应的包含加密密钥对的证书。 为解决POP问题，我们提出了类似上述间接方法的解决方