RFC1113_Internet电子邮件秘密增强第一部分- 信息加密和身份验证步骤
介绍
本文档定义了为在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避免增加电子邮件使用者的负担或不便。

















