⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc1113.txt

📁 很多RFC的中文文档
💻 TXT
📖 第 1 页 / 共 5 页
字号:
一个版本/满期子域被构造成一个Iksubfld。版本/满期子域格式可以在不同的IAs中变
动,但是必须满足一定的功能约束。一个IA的版本/满期子域必须能足够为一个给定被鉴别
的实体区别被IA发行的IK组件集。单调增加的数的使用足以区别被一个IA提供给一个实
体的IK组件;一个时间戳的使用又允许一个被指定给一个IK组件的满期时间或日期。
5.2.2 IK加密期发行
    一个IK的加密期部分是在密钥间接管理和撤回响应之间的折中规定,它将不需要在一
个使用IK组件加密的消息接收前永久的删除一个IK组件,这将使这个消息永久不可识别。
将需要获取一个过期的IK组件,例如,处理被一个已经超过一个期限不活动的使用者(或
系统)接收的邮件。为了使非常旧的IK组件被删除,一个需要被加密的本地长时间存储的
消息的接收者应该通过使用本地维护的IK重加密转换被用于消息文本加密的DEK,而不是
依赖于IA无限期的维护旧的IK组件。
6. 用户命名
6.1 当前的方法
为了正确的选择相应的密钥对电子邮件的使用者进行唯一的命名是一个重要的课题并
已进行了仔细的研究。我们当前的把IK组件和用户名联系起来的结构以一种通用的方式表
示为(user@domain-qualified-host),依赖于以下的属性:
1.	通用的形式必须通过一个IA说明的当这个IA分发IK组件并当它处理被接收
的IK组件和IK组件标识符时用户的代理可以识别。如果一个UA或IA以本
地的形式使用地址不同于通用的形式,它必须能在通用形式和本地表示之间进
行明确的映射。
2.	通用形式,当被一个发送者的UA处理时,必须和被用户规定的一个接收者地
址的形式有一个可以辨认的通信。
在整个Internet上保证这些属性是困难的。例如,一个对在一个组织内部使用的本地形
式和被用于整个Internet邮件传输使用的通用形式之间进行转换的邮件传输系统可能违反属
性2
6.2 发行考虑
平面的(非层次)电子邮件使用者标识符的使用,与用户所在的主机无关,可以提供价
值。当路径服务器变得更普遍,寻找需要的基于这种属性的接收者对于可能成为的发送者来
说是合适的。个人的特色,像社会安全号,是可以考虑的。个别被选择的标识符能被中央权
威机构注册,但是一个解决这种名字冲突的手段是必要的。
特殊注意点是为一个个体容纳多个名字的需要,为了代表和允许个体可能扮演的多个角
色代理。一个命名机制绑定用户到需要的密钥。绑定不可能是不变的因此角色有时改变(例
如,一个公司的审计员被解雇)。
检查扩展DARPA/DoD域名系统是适宜的并且它和名字服务器相连解决对于单独用户
ID的用户名。一个额外的发行和邮件列表的支持一起出现:名字服务器当前没有执行用户
列表的扩展(潜在递归的)。ISO和CSNet正在研究用户级的路径服务机制,也可以进行考
虑。
7. 用户接口和实现的例子
为了将在本RFC中讨论的机制和方法放入到设备环境中,这一节介绍了一个原型实现。
这个实现是一个被用户调用的独立的程序,分散在存在的用户的子层。这样一个程序能被调
用作为一个在电子邮件用户代理或文本编辑器内的过滤器,简化必须被用户操作的的操作顺
序。这个集成形式提供了程序和一定范围UA程序一起使用的优势,而不是仅仅和一个特殊
的UA兼容。
当一个用户希望对一个发出的消息应用保密增强,用户准备消息的文本并调用单独的程
序(和程序相互作用为了提供地址信息和其它进行保密增强处理需要的数据),依次产生适
合通过UA传输的输出。当一个用户接收到一个保密增强消息,UA以被加密的形式传送消
息,适于被单独的程序解密和做相关处理。
在这个原型(基于对称密钥管理)IK组件的存储被维护在一个本地的文件中,输入项
基于发送者和接收者提供的信息手工管理。这个存储是一个有效简单的数据库。IK组件被
选择用于传送基于发送者识别和接收者名字的消息,相应的“X-Sender-ID:”和
“X-Recipient-ID:”被放置在消息的头。当一个消息被接收,这些域被用作一个在数据库查
循的基础,服从合适的IK组件入口。DEKs和IVs在程序中动态产生。
选项和目的地址通过传给单独程序的命令行参数选择。规定对于保密增强邮件目的地址
功能逻辑上不同于规定对应于到被MTS使用的UA的地址的功能。这一分别是由于在许多
情况下被规定在一个UA中的一个地址的本地形式和使用在“X-Sender-ID:”和
“X-Recipient-ID:”域中的互连网全球形式不同。
8. 进一步研究的领域
定义在本RFC中的过程足以支持在Internet互操作方的保密增强电子邮件传送的实现。
将需要进一步的努力,然而,为了增强健壮性,一般性,和互操作性。特别以下的领域需要
进一步研究:
1.用户命名技术,和他们与域名系统,名字服务器,路径服务,和密钥管理功能的联
  系。
2.发行机构和路径服务功能和交互的详细的标准。
3.和X.400邮件保密增强的互操作性。
我们期待以后的RFC文档将针对这些课题。
9. 参考
这一节标识了可能对于那些打算使用本文档中定义的机制有用的背景参考。

       ISO 7498/Part 2 - Security Architecture, prepared by ISO/TC97/SC
       21/WG 1 Ad hoc group on Security, extends the OSI Basic Reference
       Model to cover security aspects which are general architectural
       elements of communications protocols, and provides an annex with
       tutorial and background information.
 
       US Federal Information Processing Standards Publication (FIPS
       PUB) 46, Data Encryption Standard, 15 January 1977, defines the
       encipherment algorithm used for message text encryption and
       Message Authentication Code (MAC) computation.
 
       FIPS PUB 81, DES Modes of Operation, 2 December 1980, defines
       specific modes in which the Data Encryption Standard algorithm
       may to be used to perform encryption.
 
       FIPS PUB 113, Computer Data Authentication, May 1985, defines a
       specific procedure for use of the Data Encryption Standard
       algorithm to compute a MAC.
注意:
  [1]  Key generation for MIC computation and message text encryption
       may either be performed by the sending host or by a centralized
       server.  This RFC does not constrain this design alternative.
       Section 5.1 identifies possible advantages of a centralized
       server approach if symmetric key management is employed.
 
  [2]  American National Standard Data Encryption Algorithm (ANSI
       X3.92-1981), American National Standards Institute, Approved 30
       December 1980.
 
  [3]  Federal Information Processing Standards Publication 46, Data
       Encryption Standard, 15 January 1977.

  [4]  Information Processing Systems: Data Encipherment: Modes of
       Operation of a 64-bit Block Cipher.
 
  [5]  Federal Information Processing Standards Publication 81, DES
       Modes of Operation, 2 December 1980.
 
  [6]  ANSI X9.17-1985, American National Standard, Financial
       Institution Key Management (Wholesale), American Bankers
       Association, April 4, 1985, Section 7.2.
 
  [7]  Postel, J., "Simple Mail Transfer Protocol" RFC-821,
       USC/Information Sciences Institute, August 1982.
 
  [8]  This transformation should occur only at an SMTP endpoint, not at
       an intervening relay, but may take place at a gateway system
       linking the SMTP realm with other environments.
 
  [9]  Use of the SMTP canonicalization procedure at this stage was
       selected since it is widely used and implemented in the Internet
       community, not because SMTP interoperability with this
       intermediate result is required; no privacy-enhanced message will
       be passed to SMTP for transmission directly from this step in the
       four-phase transformation procedure.
 
 [10]  Crocker, D., "Standard for the Format of ARPA Internet Text
       Messages", RFC-822, August 1982.
 
 [11]  Rose, M. and E. Stefferud, "Proposed Standard for Message
       Encapsulation", RFC-934, January 1985.
 
 [12]  CCITT Recommendation X.411 (1988), "Message Handling Systems:
       Message Transfer System: Abstract Service Definition and
       Procedures".
 
 [13]  CCITT Recommendation X.509 (1988), "The Directory -
       Authentication Framework".
 
 [14]  Kille, S., "Mapping between X.400 and RFC-822", RFC-987, June
       1986.
 
 [15]  Federal Information Processing Standards Publication 113,
       Computer Data Authentication, May 1985.
 
 [16]  American National Standard for Information Systems - Data
       Encryption Algorithm - Modes of Operation (ANSI X3.106-1983),
       American National Standards Institute - Approved 16 May 1983.
 
[17]	Voydock, V. and S. Kent, "Security Mechanisms in High-Level
     Network Protocols", ACM Computing Surveys, Vol. 15, No. 2, Pages
     135-171, June 1983.
作者地址:
   John Linn
       Secure Systems
       Digital Equipment Corporation
       85 Swanson Road, BXB1-2/D04
       Boxborough, MA  01719-1326
 
       Phone: 508-264-5491
 
       EMail: Linn@ultra.enet.dec.com


RFC1113 ——Privacy Enhancement for Internet Electronic Mail:
Part I -- Message Encipherment and Authentication Procedures
Internet电子邮件保密增强:Part1-消息编码和鉴别过程



24
RFC文档中文翻译计划

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -