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


息不需要加密 。参考资料[17]的4.3.1节提到这一要求,甚至在个别DEKs被产生用于个
别消息的情况下,IV也将随着消息被传送 。
一定的操作要求一个被传送的密钥被一个交互的密钥加密 。头部内容指出了IK被用
于加密的模式 。RFC1115规定了加密算法/模式的标识,包括DES-ECB,DES-EDE,和
RSA 。所有使用对称密钥治理的实现应该支持DES-ECBIK的使用,所有使用非对称密钥
治理的实现应该支持RSAIK的使用 。
RFC-1114,当前和这个文档一起发放,规定了非对称的基于证书的密钥治理过程支
持定义在这个文档中的消息处理过程 。消息处理过程也能和对称密钥治理一起使用,合适
的对称IKs通过带外通道预先发放 。强烈推荐支持在RFC1114中定义的非对称方法 。
4.3保密增强消息转换
4.3.1约束
一个电子邮件加密机制必须与底层电子邮件功能的透明约束相兼容 。这些约束一般被
建立在预期的用户要求和预期的端点和传输设备的特色,加密机制必须也与所交互的计算
机系统的本地规范相兼容 。在我们的建议中,一个规范的步骤是抽象我们的本地规范和操
作一个后续的编码步骤以与底层邮件传输媒体(SMTP)特色相一致 。编码与SMTP的约
束相一致,用于支持人与人之间的通讯 。SMTP的规则也以规范的处理过程独立使用 。
RFC-821"s的4.5节具体说明了SMTP"s的透明约束 。
预备一个进行SMTP传送的消息必须满足以下的要求:
1. 所有的字符必须是7位ASCII码中的一员 。
2. 文本行,通过字符对划界,不能超过1000个字符长 。
3. 因此字符串指出了消息的结束,它必须在文本中先于
消息的结束出现 。
尽管SMTP规定了一个标准的行分界符的表述,大量的系统使用一个不同的本地的
行分界的表述 。例如,在邮件中使用的行分界符进入UNIX操作系统被转换为
单一的s作为邮件的分界符被写到本地的邮件箱文件中 。邮件中的行引入到面向记录
的系统(例如VAXVMS)可以被目的SMTP服务器转换成合适的记录 。因此假如加密处
理产生s或s,这些字符可能被一个使用不同行分界规则的接收用户代理进程
获取 。也可能Tabs和空格的转换可以在SMTP内部和本地格式映射的过程中被处理;这
是一个本地选择的问题 。假如这样的转换改变了被传送的密文的形式,解密将不能产生被
传送的明文,被传送的MIC将不能和在目的计算机上计算出来的MIC相比较 。
在采用EBCDIC作为本地字符集的系统中被SMTP服务器操作的转换甚至有更严重
的影响,因此从EBCDIC到ACSII的转换是一个信息损失的转换 。在原则上,在SMTP
内部规范ASCII消息表示和本地格式之间的映射转换功能可以从SMTP服务器上移到用
户代理上,给定的治理SMTP服务器的手段不应该再进行那种转换 。这个方法有很大的
缺陷:内部的文件(例如,邮件箱)格式和它所驻留的本地文件形式不兼容 。此外,它将
要求修改SMTP服务器,邮件将以一种与现在被传递的不同的表述被传递给SMTP服务
器 。
4.3.2建议
我们建议支持保密增强邮件通过一个中间转换可以发生的环境,编码邮件以一种统一
的表述风格通过保密增强用户代理不论他们的系统采用何种本地字符集 。这种编码的形式
被用于表示从发送者到接受者的邮件文本,但是编码未被用于封装邮件传输头或去封装插
入到载有保密增强用户代理之间的控制信息的头中 。编码的特色使在预期的发送者和接收

推荐阅读