Network Working Group N. Freed
Request for Comments: 2480 Innosoft International, Inc.
Category: Standards Track January 1999
Network Working Group N. Freed
Request for Comments: 2480 Innosoft International, Inc.
Category: Standards Track January 1999
Gateways and MIME Security Multiparts
网关和MIME安全多部分
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document examines the problems associated with use of MIME security multiparts and gateways to non-MIME environments. A set of requirements for gateway behavior are defined which provide facilities necessary to properly accomodate the transfer of security multiparts through gateways.
本文档研究与MIME安全多部分和非MIME环境网关的使用相关的问题。定义了网关行为的一组要求，这些要求提供了通过网关适当容纳安全多部分传输所需的设施。
This document occasionally uses terms that appear in capital letters. When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of the terms "MUST", "SHOULD", and "MAY" appears in RFC 1123 [2]; the terms "MUST NOT" and "SHOULD NOT" are logical extensions of this usage.
本文档偶尔使用大写字母表示的术语。当术语“必须”、“不得”、“应该”、“不应该”和“可能”出现大写时，它们用于表示本规范的特殊要求。RFC 1123[2]中对术语“必须”、“应该”和“可能”的含义进行了讨论；术语“不得”和“不应”是此用法的逻辑扩展。
Security multiparts [RFC-1847] provide an effective way to add integrity and confidentiality services to protocols that employ MIME objects [RFC-2045, RFC-2046]. Difficulties arise, however, in heterogeneous environments involving gateways to environments that don't support MIME. Specifically:
安全多部分[RFC-1847]为使用MIME对象的协议添加完整性和机密性服务提供了一种有效的方法[RFC-2045，RFC-2046]。然而，在异构环境中会出现一些困难，这些环境涉及到不支持MIME的环境的网关。明确地：
(1) Security services have to be applied to MIME objects in their entirety. Failure to do so can lead to security exposures.
(1) 安全服务必须全部应用于MIME对象。不这样做可能会导致安全风险。
For example, a signature that covers only object data and not the object's MIME labels would allow someone to tamper with the labels in an undetectable fashion. Similarly, failure to encrypt MIME label information exposes information about the content that could facilitate traffic analysis.
例如，仅覆盖对象数据而不覆盖对象MIME标签的签名将允许有人以无法检测的方式篡改标签。类似地，未能加密MIME标签信息会暴露有关内容的信息，从而有助于流量分析。
Composite MIME objects (e.g., multipart/mixed, message/rfc822) also have to be secured as a unit. Again, failure to do so may facilitate tampering, reveal important information unnecessarily, or both.
复合MIME对象（例如，多部分/混合、消息/rfc822）也必须作为一个单元进行保护。同样，如果不这样做，可能会导致篡改、不必要地泄露重要信息，或者两者兼而有之。
(2) Gateways that deal with MIME objects have to be able to convert them to non-MIME formats.
(2) 处理MIME对象的网关必须能够将它们转换为非MIME格式。
For example, gateways often have to transform MIME labelling information into other forms. MIME type information may end up being expressed as a file extension or as an OID.
例如，网关通常必须将MIME标签信息转换为其他形式。MIME类型信息可能最终表示为文件扩展名或OID。
Gateways also have to take apart composite MIME objects into their component parts, converting the resulting set of parts into whatever form the non-MIME environments uses for composite objects. Failure to do so makes the objects unusable in any environment that doesn't support MIME. In many cases this also means that multi-level MIME structures have to be converted into a sequential list of parts.
网关还必须将复合MIME对象分解为其组件部分，将生成的部分集转换为非MIME环境用于复合对象的任何形式。如果不这样做，对象将无法在任何不支持MIME的环境中使用。在许多情况下，这也意味着必须将多级MIME结构转换为一系列部件。
(3) Security services have to be deployed in an end-to-end fashion. Failure to do so again can lead to security exposures.
(3) 必须以端到端的方式部署安全服务。再次不这样做可能会导致安全风险。
An integrity service deployed at something other than a connection end point means a region exists between the point where the integrity service is applied and the actual end point where object tampering is possible. A confidentiality service deployed at something other than a connection end point means a region exists where the object is transferred in the clear. And worse, distributed private keys are usually necessary whenever someone other than the originator applies an integrity service or someone other than the recipient removes a confidentiality service, which in turn may make theft of private key information a possibility.
在连接端点以外的位置部署的完整性服务意味着在应用完整性服务的点和可能篡改对象的实际端点之间存在一个区域。在连接端点以外的位置部署的保密服务意味着存在一个区域，在该区域中对象以明文形式传输。更糟糕的是，当发起人以外的人应用完整性服务或接收方以外的人删除保密服务时，通常需要分发私钥，这反过来可能导致私钥信息被盗。
All of these issues can be addressed, of course. For example, it may be possible to use multiple overlapping security services to assure that no exposure exists even though there is no end-to-end security per se. And keys can be distributed in a secure fashion. However, such designs tend to be quite complex, and complexity in a security system is highly
当然，所有这些问题都可以解决。例如，可以使用多个重叠的安全服务来确保即使不存在端到端安全本身也不存在暴露。密钥可以以安全的方式分发。然而，此类设计往往相当复杂，安全系统的复杂性非常高
undesireable.
不受欢迎的。
The preceeding three requirments are fundamentally in conflict: It is possible to satisfy two of them at once, but not all three at once.
上述三项要求基本上是冲突的：可以同时满足其中两项要求，但不能同时满足所有三项要求。
In fact the conflict is even worse than it first appears. In most situations of this sort some sort of compromise is possible which, while not satisfying any of the requirements completely, does optimize some sort of average of all the requirements. Such a solution does not exist in this case, however, because many real world situations exist where any one of these requirements absolutely must be satisfied.
事实上，这场冲突比最初出现的还要严重。在这种类型的大多数情况下，某种折衷是可能的，虽然不能完全满足任何需求，但确实优化了所有需求的某种平均值。然而，在这种情况下不存在这样的解决方案，因为存在许多实际情况，其中任何一个需求都必须得到满足。
Since the previously described problem doesn't allow for a single solution the only viable approach is to require that gateways provide multiple solutions. In particular, gateways
由于前面描述的问题不允许单一解决方案，因此唯一可行的方法是要求网关提供多个解决方案。特别是网关
(1) MUST provide the ability to tunnel multipart/signed and multipart/encrypted objects as monolithic entities if there is any chance whatsoever that MIME capabilities exist on the non-MIME side of the gateway. No changes to content of the multipart are permitted, even when the content is itself a composite MIME object.
(1) 如果网关的非MIME端存在MIME功能，则必须提供将多部分/签名和多部分/加密对象作为单片实体进行隧道的能力。即使内容本身是复合MIME对象，也不允许更改多部分的内容。
This option must be provided so that entities behind the gateway that are capable of processing security multiparts and their MIME content will work properly. As mentioned previously, situations exist where application security requirements are absolute and must be accomodated, even when meeting them causes problems for other agents.
必须提供此选项，以便网关后面能够处理安全多部分及其MIME内容的实体能够正常工作。如前所述，存在应用程序安全性要求是绝对的，必须满足的情况，即使满足这些要求会给其他代理带来问题。
Exceptions are allowed only when there is no possibility of MIME support on one side of the gateway. For example, a gateway to a voice messaging system may have no useful way to represent a signed MIME object.
只有当网关一侧不可能支持MIME时，才允许出现异常。例如，语音消息系统的网关可能没有表示签名MIME对象的有用方法。
(2) MUST provide the ability to take apart multipart/signed objects, exposing the content (and in the process ruining the signature). When this approach is selected, gateways SHOULD NOT remove the signature. Instead, gateways SHOULD keep the signature intact and add to it a note that it will probably be invalid for checking the message contents, but may still be contain valuable information about the sender.
(2) 必须提供拆分多部分/签名对象的能力，公开内容（并在过程中破坏签名）。选择此方法时，网关不应删除签名。相反，网关应该保持签名完好无损，并在签名中添加一条注释，即它可能对检查消息内容无效，但可能仍然包含关于发送者的有价值信息。
This option must be provided so that entities behind the gateway which are incapable of processing MIME will work properly.
必须提供此选项，以便网关后面无法处理MIME的实体能够正常工作。
(3) SHOULD provide the ability to select between the previous two options on per-user basis.
(3) 应能够根据每个用户在前两个选项之间进行选择。
(4) MAY provide facilities to check signatures and decrypt encrypted content. Such facilities MUST NOT be enabled by default; the potential security exposure involved has to be assessed before such capabilities can be used.
(4) 可提供检查签名和解密加密内容的设施。默认情况下不得启用此类设施；在使用这些能力之前，必须评估所涉及的潜在安全风险。
(5) MAY provide facilities to sign and/or encrypt material passing from the non-MIME side to the MIME side of the gateway. Again, such facilities MUST NOT be enabled by default; the potential security exposure involved in the transfer of unsecured content within the application domain behind the gateway has to be assessed before such capabilities can be used.
(5) 可以提供对从网关的非MIME端传递到MIME端的材料进行签名和/或加密的设施。同样，默认情况下不得启用此类设施；在使用这些功能之前，必须评估网关后面的应用程序域内传输不安全内容所涉及的潜在安全风险。
A gateway which complies with the above requirements is considered to be security multiparts compliant.
符合上述要求的网关被视为安全多部分兼容。
This entire document is about security.
整个文档都是关于安全性的。
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August, 1982.
[RFC-822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[RFC-1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[RFC-1847]Galvin，J.，Murphy，S.，Crocker，S.和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年10月。
[RFC-1123] Braden, R., Ed., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[RFC-1123]Braden，R.，Ed.“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996.
[RFC-2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年12月。
[RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 1996.
[RFC-2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 2046，1996年12月。
[RFC-2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, December 1996.
[RFC-2049]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第五部分：一致性标准和示例”，RFC 2049，1996年12月。
Ned Freed Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA
Ned Freed Innosoft International，Inc.美国加利福尼亚州西科维纳湖大道1050号，邮编：91790
Phone: +1 626 919 3600
Fax: +1 626 919 3614
EMail: ned.freed@innosoft.com
Phone: +1 626 919 3600
Fax: +1 626 919 3614
EMail: ned.freed@innosoft.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。