rfc1113.txt

很多RFC的中文文档

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：金凤（phoenix_jin  [e-mail]）
译文发布时间：2001-10-28
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。




Network Working Group                                            J. Linn
Request for Comments:  1113                                         DEC
Obsoletes RFCs: 989, 1040                         IAB Privacy Task Force
                                                                August 1989
Internet电子邮件保密增强：Part1-消息编码和鉴别过程 
（RFC1113 ——Privacy Enhancement for Internet Electronic Mail:
      Part I -- Message Encipherment and Authentication Procedures） 


本备忘录的状态
本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建
议以得到改进。请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化
程度和状态。本备忘录的发布不受任何限制。
版权声明
Copyright (C) The Internet Society (2001).
感谢
本文档是internet构架委员会（IAB）保密特别委员会的一系列会议及在那些会议上分
发的internet工作报告的产物。我想感谢以下列出的保密特别委员会的成员集中了他们在会
议上的观点和贡献形成了这个rfc文档：David Balenson, Curt Barker, Jim Bidzos, Matt 
Bishop, Danny Cohen, Tom Daniel, Charles Fox, Morrie Gasser, Russ Housley, Steve 
Kent (chairman), John Laws, Steve Lipner, Dan Nessett, Mike Padlipsky, Rob Shirey, 
Miles Smid, Steve Walker, and Steve Wilbur.
目录
1.  介绍	3
2. 术语	3
3.  服务、约束和暗示	3
４. 消息处理	5
４.1 消息处理总览	5
４.1.1 密钥类型	5
４.1.２ 处理过程	6
4.2  加密算法和模式	6
4. 3 保密增强消息转换	7
4.3.1 约束	7
4.3.2 建议	8
4.3.2.1 步骤一：本地形式	8
4.3.2.2 步骤二：规范形式	8
4.3.2.3 步骤三：鉴别和加密	8
4.3.2.4 步骤四：可打印的编码	9
4.3.2.5 转换概述	9
4.4 封装机制	10
4.5 邮件列表的邮件	12
4.6 被封装的头域小结	12
4.6.1 每个消息被封装的头域	14
4.6.1.1 X-Proc-Type域	14
4.6.1.2 X-DEK-Info域	14
4.6.2 一般每个消息被封装的头域	15
4.6.2.1 X-Sender-ID域	15
4.6.2.2 X-Certificate域	15
4.6.2.3 X-MIC-Info域	15
4.6.3 不定出现的头域	16
4.6.3.1 X-Issuer-Certificate域	16
4.6.4 每个接收者被封装的头域	16
4.6.4.1 X-Recipient-ID域	16
4.6.4.2 X-Key-Info域	17
4.6.4.2.1 对称密钥管理	17
4.6.4.2.2 非对称密钥管理	17
5. 密钥管理	17
5.1 数据加密密钥（DEKs）	18
5.2 交互密钥（Iks）	18
5.2.1 子域的定义	19
5.2.1.1 实体标识符子域	19
5.2.1.2 发行机构子域	19
5.2.1.3 版本/满期子域	19
5.2.2 IK加密期发行	20
6. 用户命名	20
6.1 当前的方法	20
6.2 发行考虑	20
7. 用户接口和实现的例子	21
8. 进一步研究的领域	21
9. 参考	21
注意：	22
作者地址：	24

1.  介绍
本文档定义了为在internet上传输的电子邮件提供保密增强服务的消息编码和鉴
别的过程。是四个相关文档中的一篇。在当前的RFC中定义的步骤试图与各种密钥管
理方法保持兼容，包括加密密钥的数据加密的对称（秘钥）和非对称（公钥）方法。并
预见了消息文本加密的对称密码系统的使用和／或完整性检查计算。RFC-1114规定了
支持基于公钥证书使用的密钥管理机制。RFC-1115规定了算法和与当前文档和
RFC-1114相关的信息。后续的RFC将提供被建立的密钥基础设施的详细的报告和电
子格式和过程以支持这些服务。
保密增强服务（机密性、可鉴别性、消息完整性保证）是通过发送者和接受者用户
进程之间的端对端的加密系统提供的，没有特殊的处理要求强加于端点的消息传输系统
或中继站。这种方法容许保密增强功能被结合到一个站对站或用户对用户的基础之上，
不会影响其他的网络实体。支持不同种类的的组件和邮件传输工具之间的互操作性。
2. 术语
为了描述的目的，本RFC文档使用了定义在OSI X.400消息处理系统（1984年
经CCITT推荐）模型里的术语。这部分复制了X.400 2.2.1小节的部分内容，“MHS
模型的描述：总览”为了使不熟悉OSI MHS模型的的读者清楚的理解这个术语。
在MHS模型中，一个用户是一个人或一个计算机应用。一个用户要么作为发送者
要么作为接收者（当正在接收）。MH服务元素定义了一组消息类型和一个发送者传送
这些类型消息给一个或多个接收者的能力。
一个发送者在他或她的用户代理的帮助下准备消息。一个用户代理（UA）是一个
和传送消息的消息传输系统（MTS）相互影响的应用进程。这个MTS向一个或多个接
受者的用户代理传送消息。只是被用户代理操作而没有标准化为一个MH服务元素的
一部分的功能被称为本地用户代理功能。
MTS有大量的消息传送代理（MTAs）组成。在一起操作，MTAs转送消息将它们
传送给目的接收用户代理，通过这些代理使消息对于目的接受者可用。
UAs和MTAs总称为消息处理系统（MHS）。MHS和它的所有用户作为消息处理
环境。
3.  服务、约束和暗示
本文档定义了增强电子邮件在网络上保密传送的机制。在本文档中讨论的功能提供
了基于发送者和接收者用户代理的端对端的系统保密增强服务。没有保密增强被提供给
通过中间节点转发和增加的消息域。
     鉴别和完整性功能总是应用到整个消息文本，没有不通过鉴别的机密性功能，加
密功能可以有选择的应用到消息的内容部分；这允许在接收者的个人密钥缺失的情况下
消息不太敏感的部分（例如，描述域）被接收者的代理处理。在有些情况下，消息整体
被排除在加密之外，这一特色可以用于不含机密性的鉴别和完整性服务的有效组合。
     为了和internet的不同支持者和使用模式保持一致，定义在文档中的各种方法可以
应用到internet主机和使用范例的广泛的范围。特别下面的属性值得注意：
1．	定义在文档中的机制没有限制针对特殊的主机或操作系统，但是允许在大量系统间
的互操作性。所有的保密增强在应用层实现，不依赖于底层协议的任何保密特色。
2．	被定义的机制和非增强的网络组件相兼容。保密增强在端到端的风格中中间转发的
主机不影响邮件的处理，中间的主机没有加入保密增强功能。然而消息的发送者识
别接收者是否实现保密增强，为了编码。可能加密不会被用于没有对应转换的消息
的目的地。
3．	定义的机制是和一些的邮件传输功能相兼容的。在Internet内，电子邮件传输受各种
SMTP的实现影响。一定的站点凭借SMTP可获取，传送邮件到其他的邮件处理环
境（例如 USENET，CSNET，BITNET）。	保密增强必须能通过SMTP领域操作；
也要求与在SMTP环境和其他连接环境的电子邮件发送保护相一致。
4．	定义的机制和大范围的电子邮件用户代理相一致。各种各样的被用在internet电子邮
件用户代理程序，和相应范围的用户接口范例。为了使电子邮件保密性增强最大可
能的应用于用户交互，所选择的机制应该对于最大可能的各种存在UA程序可用。
对于引导实现的目的，要求保密增强处理被组合成一个单独的程序，对于大多数的
UAs可用，而不是去修改每一个提供保密增强服务的每个UA。
5．	定义的机制允许电子邮件保密增强处理被操作在个人电脑上独立于不同的UA功能
被实现的系统。给定PCs扩展的使用和被放置在许多多用户系统的UA实现的信任
程度，这个属性能允许许多用户以比一个严格基于UA的方法所能允许保证级高的
级别来处理保密增强邮件。
6．	定义的机制支持电子邮件定位的邮件列表保密保护（分发列表，ISO用语）。
7．	定义在本文档中的机制和各种支持的密钥管理方法相兼容，包括（未限制）手工的
预分发，基于对称密码的密钥分发，和公钥证书的使用。不同的密钥管理机制可以
被用于一个广播消息的不同接收者。而为了与本文档的兼容性支持一个特殊的密钥
管理机制不是最小的必要的要求，强烈推荐采用定义在RFC-1114中的公钥证书方
法。
     为了获得对于最大可能范围的网络主机和邮件系统的适用性，便利引导实现和测
试而无须预先修改整个网络，在本文挡中考虑了影响一组方法的三个基本的限制：
1．	方法将被限制于在端点的实现并将受用户代理级等完整性的影响，而不必集成到消
息传输系统（例如，SMTP服务）。
2．	被支持的方法增强而不是限制用户的能力。被信任的实现，包含完整性特色保护软
件不被本地用户颠覆，不能做一般的假设。在这样的特色缺少的情况下，提供增强
对用户服务的便利（例如，通过保护和鉴别中间用户交互）显然比增强对用户行为
限制（内部用户获取控制）更加可行。
3．	被支持的一组方法集中于一组被选择提供广大用户社区重要的和切实的利益的功
能。通过集中最关键的服务组，我们旨在通过普通的实现努力最大化被增加的保密
值。
     由于这些限制，能提供下面的功能：
1．	解密保护，
2．	发送者鉴别，
3．	消息完整性方法，
4．	（如果使用非对称密钥管理）来源不可否认，
     但是下面的与保密相关的影响未提到：
1．	获取控制，
2．	通信流机密性，
3．	地址列表的正确性，
4．	路由控制，
5．	发布关于被多个用户偶尔连续重用的PC机，
6．	消息和他们所要访问的的内容的自动确认，
7．	消息复制检测，重放阻止，或其它的面向流的服务。
    消息的发送者将决定是否对特定的消息进行保密增强服务。因此，一个发送者必须
能决定是否接收者具有处理保密增强邮件的能力。在一个一般的结构中，这些机制将基
于服务器的查询；因此，查询功能能被集成到一个UA避免增加电子邮件使用者的负担
或不便。