数字签名(三)
上一节，我们找到Bob信任的Trent，让Trent对"Carol的公钥是Y"这一消息进行签名，Bob收到消息及签名后，用Trent的公钥验证签名的正确性(或合法性)，从而相信Carol的公钥真的是Y，Bob就可以放心地用公钥Y给Carol发送加密信息了。但是Trent的公钥从何而来？
只有两种途径，一、直接方式，即Bob通过某种可信渠道(比如两人亲自见面)直接得到Trent的公钥。二、间接方式，即Bob并不认识Trent，而是通过信任传递来相信Trent的公钥。举个例子，Bob信任Alice，同时Alice又信任Trent，则Bob由于信任Alice而信任Trent，这就是信任的传递。用前面描述的流程，可以这样表述：Bob信任Alice(因而相信Alice的公钥)，而Alice信任Trent(自然，Alice也信任Trent的公钥PT)，则Alice用自己的私钥，对消息"Trent的公钥是PT"签名。Bob收到这个消息和签名后，用Alice的公钥进行验证，发现签名正确，因而该消息确实为Alice所发，最终Bob相信Trent的公钥是PT。接下来Bob就可以用Trent的公钥来验证"Carol的公钥是Y"这一消息。
在间接方式中，我们进入了一个循环：为了相信甲的公钥，我们要相信乙的公钥，为了相信乙的公钥，我们要相信丙的公钥，为了相信丙的公钥，我们要相信丁的公钥......
我们好象陷入了死循环，什么时候才是个头？
答案是：你最终得信任某个可信方(及其公钥)。换句话说，You MUST trust in something.
这种终结方式，如同函数递归调用中的基准条件一样，用来终结递归调用。
或者可以这样打比方，你相信乡长是因为你相信县长，你相信县长是因为你相信省长，你相信省长是因为你相信国家主席。而到了国家主席这一层，你就无可依靠了，只能说，因为你相信国家主席，所以相信国家主席。
既然最终还是要去信任某个可信方及其公钥，那只能通过可信渠道来获取了。在这方面，Internet就无用武之地了----它天然就不是一个可信渠道，还记得Dolev-Yao攻击者模型吗？唯一的选择，就是通过传统较权威可信的渠道获取公钥，比如广播、电视、报纸甚至政府公告等方式。这恰好是前面说到的直接方式的途径，用于递归终结。
说明：为了方便布署，现在的操作系统和浏览器都内置了很多数字证书(证书中的重点内容就是公钥，详细见下节)，说得明白点，它们替你相信了这些证书中的公钥。
从这个角度，我们得到两个结论：二、解决好公钥的信任关系是通信的先决条件。二、Internet上的信任关系最终要依赖于传统的信任关系和可信渠道。毕竟，只要涉及到利益相关，虚拟的网络世界必然是现实世界的映照。
以上公钥信任链的构成，是PKI(Public Key Infrastructure，中文名称"公钥基础设施")的核心概念。和PKI紧密联系在一起的，还有两个核心概念：CA和数字证书(简称证书)。下一节，我们将配以实例，进行详细阐述。