Internet电子邮件保密增强:Part1-消息编码和鉴别过程(13)


的产生减少了发送者为了发送邮件进行实时服务器查询(潜在的独一的)的频率,加强交互
可用性 。
当对称密码被使用时,一个基于KDC集中产生的优势是DEKs能在被消息的接收者的
Iks加密后被返回给端点而不是提供IKs给发送者 。这减少了IK的暴露并简化了端点密钥管
理的要求 。假如使用非对称密钥治理这个方法没什么价值,因此每个接收者公共IK组件被
认为一般是可用的而且每个发送者的私有IK组件不需要和KDC共享 。
5.2交互密钥(Iks)
交互密钥(IK)组件被用于加密DEKs和MICs 。一般,IK间隔尺寸是除了发送给包含
多个用户的地址列表的邮件的每个对等用户级别 。对于使用标准的密码进行保密增强电子邮
件交互有两个主要的原则,首先必须处理公共的IK组件(当使用对称密钥治理)或补充的
IK组件(当使用非对称密钥治理) 。当使用对称密码,IK由一个单一的组件构成,被用于
加密DEKs和MICs 。当使用非对称密码,一个接收者的公共组件用做一个IK加密DEKs(一
个相反的转换只由接收者处理对应私有组件),发送者的私有组件被用于加密MICs(一个相
反的转换由所有的接收者操作,因此发送者的证书提供了发送者的必要的公共组件) 。
而本文档没有规定交互密钥被提供给合适的使用者的手段,注重这些可能被集中(例
如,通过密钥治理服务器)或分散(例如,通过对等协商和直接在用户中分发)的手段是有
用的 。在任何情况下,任何给定的IK组件和一个对应的发行机构(IA)相关 。当基于认证
的在RFC-1114中讨论非对称密钥治理被采用,IA功能通过一个证书机构实现(CA) 。
当一个IA产生和分发一个IK组件,相关的控制信息被提供指导如何使用IK 。为了选
择用于消息加密的合适的Iks,一个发送者必须保留一个在IK组件和与之相关的接收者的通
信 。终止时间信息必须被保留,以便可以使存储的入口无效并被合适的替代 。
因此一个消息可以被多个IK组件标识发送给相应的多个接收者,每个接收者的用户代
理必须能够决定接收者需要的IK组件 。此外,假如当一个消息到达时接收者的数据库里没
有相应的IK组件,接收者必须能鉴别需要的IK组件并鉴别与IA相关的IK组件 。注重不
同的IK可以在一对通信者之间被用于不同的消息 。考虑,例如,一个从A发送到B的消息
和另一个从A发送到B所在的邮件列表的消息(使用IK-per-list方法) 。第一个消息将使用
分别与A和B相关联的IK组件,但是第二个将使用在列表成员之间共享一个IK组件 。
当一个保密增强消息被发送,一个用于加密DEK和MIC的IK指示必须被包括 。到此
为止,“X-Sender-ID:”和“X-Recipient-ID:”被封装的头域提供下面的数据:
1. 相关发行机构的鉴别(IA子域)
2. 与一个非凡IK组件相关的一个实体的鉴别(实体标识符或实体标识子域)
3. 版本/满期子域
冒号被用于在一个“X-Sender-ID:”或“X-Recipient-ID:”中进行分界 。IA,EI,和版
本/满期子域从一个严格的字符集中产生,通过下面的BNF表述(使用定义在RFC-822,第
2节和3.3节中的符号):
IKsubfld:=1*ia-char
ia-char:=DIGIT/ALPHA/"""/" "/"("/")"/
","/"."/"/"/"="/"?"/"-"/"@"/
"%"/"!"/"""/"_"/"<"/">"
一个“X-Recipient-ID:”域的示例如下:
X-Recipient-ID:linn@ccy.bbn.com:ptf-kmc:2
这个例子表明IA“ptf-kmc”已经发行了一个IK组件用于发送给linn@ccy.bbn.com的消
息,并且IA提供了数字2作为一个对于那个IK组件的版本标识符 。

推荐阅读