rfc1113.txt

很多RFC的中文文档

果一个消息的被封装的文本需要加密，“X-Proc-Type：”域的第二个子域必须规定
“ENCRYPTED”。“MIC-ONLY”的规定，在和密钥管理和MIC算法选择相关联时，允许
一些未进行加密的域从被封装的头域中忽略。尤其“X-Recipient-ID：”和“X-Key-Info：”在
非对称密钥算法被使用时能被接收者忽略。假设当前使用一个无密钥MIC计算算法，
“X-DEK-Info：”域可以被所有的“MIC-ONLY”消息忽略。
4.6.1.2 X-DEK-Info域
“X-DEK-Info：”被封装头域标识消息文本加密算法和模式，也携带用于消息加密的初
始向量。在消息里“X-DEK-Info：”域不止出现一次，在“X-Proc-Type：”域里规定了
“MIC-ONLY”的消息不包含此域。
“X-DEK-Info：” 域带有两个参数，用逗号分隔。对于本RFC的目的，第一个参数必
须是字符串“DES-CBC”，表示使用CBC模式的DES算法。第二个参数代表了一个64位
的初始向量（IV）以连续的16进制的形式表示。后续的RFC1115修订版将规定可能作为这
个域的第一个参数出现的任何额外的值。
4.6.2 一般每个消息被封装的头域
    这个被封装的头域组包含在每个消息中出现不止一次的头域。依赖使用的密钥管理选
项，这些域中的一些可以某些消息中不出现在。在一个消息中“X-Sender-ID”域可以出现
不止一次如果对于不同的接收者必须使用不同的面向发送者的IK组件（也许对应于不同的
版本）。在这种情况下后来的出现取代以前的出现。如果在一个简单消息里使用对称和非对
称的密钥分发的混合。对于密钥分发技术的每个接收者应该被组合在一起简化分析。
4.6.2.1 X-Sender-ID域
所有的保密增强消息都要求有“X-Sender-ID：”被封装的头域，标识一个消息的发送者
并提供发送者的IK标识组件。它应该在被封装的文本内被复制。IK标识组件被包含在
“X-Sender-ID：”域与所有后续的“X-Recipient-ID：”相关联直到另一个“X-Sender-ID：”
域出现；一般的情况是只有一个“X-Sender-ID：”域在任意“X-Recipient-ID：”域前出现。
“X-Sender-ID：”域包含一个实体标识子域，一个（可选的）发行机构子域，和一个（可
选的）版本/满期子域。这些可选的域可以被忽略如果他们的出现对于后续的
“X-Recipient-ID：”域所带有的信息来说是多余的。这在使用对称密码作为密钥管理的情况
下是经常的情况。这些子域通过冒号分隔，也可以带有空格。
在5.2节，交互密钥，讨论了这些子域的语义并规定了他们选择的字符的形式。注意多
个“X-Sender-ID：”域可以出现在一个简单的被封装的头中。所有的“X-Recipient-ID：”域
在大多数情况下接着“X-Sender-ID：”域；“X-Recipient-ID：”域出现在“X-Sender-ID：”域
之前是不合法的。
4.6.2.2 X-Certificate域
    “X-Certificate：”域只在非对称密钥管理被用于一个或多个消息的接受者时被使用。为
了便于接收者的处理（至少超过一个一般的路径服务器可用性），强烈推荐在所有的消息中
包括这个域。这个域以数量的形式传送了发送者的证书，以定义在4.3.2..4节中的编码的形
式表示。一个证书的语法定义在RFC-1114中。在“X-Certificate：”域中携带的证书和
“X-Sender-ID：”域和“X-Recipient-ID：”域一起在非对称密钥管理被使用时使用。
    
4.6.2.3 X-MIC-Info域
“X-MIC-Info：”只在至少一个消息的接收者使用非对称密钥管理时才使用，带有三个
参数，通过逗号分隔。第一个消息标识在MIC被计算时使用的算法；RFC-1115规定了可接
受的MIC算法标识集。第二个参标识MIC被加密时使用的算法；在本文档中必须出现在
RFC-1115中描述的字符串“RSA”，标识RSA算法。第三个参数是一个MIC。
非对称的加密使用发送者的私钥。正如本文档前面所述，非对称被加密的MIC使用描
述在4.3.2.4节中的技术来表示。
“X-MIC-Info：”域将立即出现在“X-Sender-ID：”域和“X-Certificate：”域或
“X-Issuer-Certificate：”之后。类似“X-Sender-ID：”域，一个“X-MIC-Info：”域由所有的
使用非对称密钥的接收者使用。
4.6.3 不定出现的头域
    这组被封装的头域包含在消息中出现次数不定的域，出现的次数从0到非零的值变动与
接收者的数目无关。
4.6.3.1 X-Issuer-Certificate域
“X-Issuer-Certificate：”被封装的域只在至少一个消息的接收者使用非对称密钥管理时
是有意义的。一个典型“X-Issuer-Certificate：”域包含拥有公钥组件的证书，这个证书被用
于签包含在“X-Certificate：”域中的证书，接收者通过证书的认证路径链使用。其他的典型
的代表认证链上高一级的证书的“X-Issuer-Certificate：”域，也可以被一个发送者包括。被
包括的“X-Issuer-Certificate：”域的顺序不需要对应认证路径的顺序；路径的顺序一般可以
与不同的接收者的观点不同。关于认证路径的更多的信息可以在RFC-1114中发现。
证书以定义在“X-Certificate：”域中相同的方式表示，任何“X-Issuer-Certificate：”域
一般将直接跟随“X-Certificate：”域。“X-Issuer-Certificate：”域这个域甚至在使用非对称密
钥管理时也是可选的，尽管在使接收者能获取发行者的证书的的二选一的路径服务器缺乏时
强烈推荐使用这个域。
4.6.4 每个接收者被封装的头域
    这组被封装的头域对于每一个消息的命名接收者来说一般出现一次。在特殊的情况下，
这些域在发送给使用非对称密钥管理的接收者一个“MIC-ONLY”消息的情况下可以被忽略，
给定的被选择的MIC算法是无密钥的。
4.6.4.1 X-Recipient-ID域
这个“X-Recipient-ID：”标识了一个接收者并提供了接收者IK标识组件。一个
“X-Recipient-ID：”被每个命名的接收者包括。它应该被复制在被封装的文本中。这个域包
含一个实体标识子域，一个发行机构子域，和一个版本期子域。子域通过冒号分界，可以跟
空格。
5.2节，交互密钥，讨论了子域的语义并规定了他们被选择的字符。所有
“X-Recipient-ID：”域跟在最接近的的“X-Sender-ID：”域之后；“X-Recipient-ID：”域出现
在“X-Sender-ID：”域之前是不合法的。
4.6.4.2 X-Key-Info域
    一个“X-Key-Info：”被包含在每一个消息的命名接收者中。每一个“X-Key-Info：”域
跟在最近的“X-Recipient-ID：”域之后；通常，一个“X-Key-Info：”域将立即跟着它的相关
的“X-Recipient-ID：”域。对于一个特殊的接收者这个域的参数对于对称和非对称的密钥管
理是不同。
4.6.4.2.1 对称密钥管理
当对一个给定的接收者使用对称密钥管理, “X-Key-Info：”被封装的头域传送4个条目，
通过逗号分隔：一个IK使用标识，一个MIC算法标识，一个DEK和一个MIC。IK使用标
识符标识了算法和被标识的IK用于一个特殊的接收者的DEK加密的模式。对于对称密钥
管理被使用的接收者，它可以假设保留的字符串值为“DES-ECB”或“DES-EDE”，定义在
RFC-1115中。
MIC算法标识符标识用于特殊接收者的MIC计算算法；这个子域的值被定义在
RFC-1115中。DEK和MIC使用前面被“X-Sender-ID：”和“X-Recipient-ID：”域标识的IK
来加密；他们以两个连续的16进制字符串来表示，通过一个逗号分隔。
当DEA-1被用于消息文本的加密，DEK将是16个16进制数字。（对应一个64位的密
钥）；这个子域能被扩展为32位16进制数字（对应一个128位密钥）如果需要支持其他的
算法。
MIC的对称加密也以和消息DEK的加密的相同模式来加密。被加密的MICs，像被加
密的DEKs，以连续的16进制字符串来表示。MIC的大小依赖于规定在MIC算法标识子域
的MIC算法的选择。
4.6.4.2.2 非对称密钥管理
当对一个给定的接收者使用非对称密钥管理，“X-Key-Info：”域传送两个量，通过逗号
分隔。第一个参数是一个IK使用标识符标识加密DEK的算法（和模式，如果可用）；本文
档，IK使用标识符子域总假设保留字符串为“RSA”（定义在RFC-1115）对于使用非对称
密钥管理的接收者，表示RSA算法的使用。第二个参数是一个DEK，在接收者的公共组件
下加密（使用非对称加密）。
在本文档中我们采用术语“私有组件”和“公共组件”参考对称密码系统中分别保持
保密和使公共可用的两个量。这个规定被采用避免因为术语“秘钥”用于指代私有组件和对
密码中的密钥引起的困惑。
正如在本文档前面所讨论的，非对称被加密的DEK使用在4.3.2.4节所描述的方法表示。
5. 密钥管理
    几个密码元素被使用支持保密增强消息处理的过程。假定了一组基本的元素。数据加密
密钥（DEKs）被用于加密消息文本和（用于一些MIC计算算法）在消息完整性检查（MIC）
计算过程。交互密钥（Iks）被用于加密和消息一起传送的DEKs和MICs。在一个基于证书
的非对称密钥管理的结构中，证书被用于作为一个提供实体的公共组件和被中央权威机构安
全绑定的信息的手段。在这一节的剩余部分提供了关于这些结构的信息。
5.1 数据加密密钥（DEKs）
数据加密密钥（DEKs）被用于加密消息文本和（带有一些MIC计算算法）消息完整性
检查的计算。强烈推荐DEKs对每个消息被产生使用一次。一个被传送的消息将合并一个被
对每个命名接收者的合适的交互密钥加密的DEK。
DEK产生可以要么通过密钥分发中心（KDCs）或通过端系统。专门的KDC系统可以
实现比端系统支持的算法强的随机DEK产生算法。另一方面，分散允许端是相对独立的，
减少了必须放在除了消息的接收者和发送者的组件的信任级别。此外，在端点的分散的DEK
的产生减少了发送者为了发送邮件进行实时服务器查询（潜在的独一的）的频率，加强交互
可用性。
当对称密码被使用时，一个基于KDC集中产生的优势是DEKs能在被消息的接收者的
Iks加密后被返回给端点而不是提供IKs给发送者。这减少了IK的暴露并简化了端点密钥管
理的要求。如果使用非对称密钥管理这个方法没什么价值，因此每个接收者公共IK组件被
认为一般是可用的而且每个发送者的私有IK组件不需要和KDC共享。
5.2 交互密钥（Iks）
交互密钥（IK）组件被用于加密DEKs和MICs。一般，IK间隔尺寸是除了发送给包含
多个用户的地址列表的邮件的每个对等用户级别。对于使用标准的密码进行保密增强电子邮
件交互有两个主要的原则，首先必须处理公共的IK组件（当使用对称密钥管理）或补充的
IK组件（当使用非对称密钥管理）。当使用对称密码，IK由一个单一的组件构成，被用于
加密DEKs和MICs。当使用非对称密码，一个接收者的公共组件用做一个IK加密DEKs（一
个相反的转换只由接收者处理对应私有组件），发送者的私有组件被用于加密MICs（一个相
反的转换由所有的接收者操作，因此发送者的证书提供了发送者的必要的公共组件）。
而本文档没有规定交互密钥被提供给合适的使用者的手段，注意这些可能被集中（例
如，通过密钥管理服务器）或分散（例如，通过对等协商和直接在用户中分发）的手段是有
用的。在任何情况下，任何给定的IK组件和一个对应的发行机构（IA）相关。当基于认证
的在RFC-1114中讨论非对称密钥管理被采用，IA功能通过一个证书机构实现（CA）。
当一个IA产生和分发一个IK组件，相关的控制信息被提供指导如何使用IK。为了选
择用于消息加密的合适的Iks，一个发送者必须保留一个在IK组件和与之相关的接收者的通
信。终止时间信息必须被保留，以便可以使存储的入口无效并被合适的替代。
因此一个消息可以被多个IK组件标识发送给相应的多个接收者，每个接收者的用户代
理必须能够决定接收者需要的IK组件。此外，如果当一个消息到达时接收者的数据库里没
有相应的IK组件，接收者必须能鉴别需要的IK组件并鉴别与IA相关的IK组件。注意不
同的IK可以在一对通信者之间被用于不同的消息。考虑，例如，一个从A发送到B的消息
和另一个从A发送到B所在的邮件列表的消息（使用IK-per-list方法）。第一个消息将使用
分别与A和B相关联的IK组件，但是第二个将使用在列表成员之间共享一个IK组件。
当一个保密增强消息被发送，一个用于加密DEK和MIC的IK指示必须被包括。到此
为止，“X-Sender-ID：”和“X-Recipient-ID：”被封装的头域提供下面的数据：
1.	相关发行机构的鉴别（IA子域）
2.	与一个特殊IK组件相关的一个实体的鉴别（实体标识符或实体标识子域）
3.	版本/满期子域
冒号被用于在一个“X-Sender-ID：”或“X-Recipient-ID：”中进行分界。IA，EI，和版
本/满期子域从一个严格的字符集中产生，通过下面的BNF表述（使用定义在RFC-822，第
2节和3.3节中的符号）：
IKsubfld       :=       1*ia-char
 
ia-char        :=       DIGIT / ALPHA / "'" / "+" / "(" / ")" /
                       "," / "." / "/" / "=" / "?" / "-" / "@" /
                       "%" / "!" / '"' / "_" / "<" / ">"
一个“X-Recipient-ID：”域的示例如下：
X-Recipient-ID: [e-mail]:ptf-kmc:2
这个例子表明IA“ptf-kmc”已经发行了一个IK组件用于发送给[e-mail]的消
息，并且IA提供了数字2作为一个对于那个IK组件的版本标识符。
5.2.1 子域的定义
    下面的几节定义了“X-Sender-ID：”和“X-Recipient-ID：”域。
5.2.1.1 实体标识符子域
一个实体标识符被构成作为一个Iksubfld。更严格地，一个实体标识符子域假设了下面
的形式：
<user>@<domain-qualified-host>
为了支持通用的交互性，必须假设一个命名信息的通用的形式。对于传送到更广的网
络的转换本地主机名的安装的情况，强烈推荐主机名被呈现给使用的Internet。
5.2.1.2 发行机构子域	
    一个IA标识符子域被构造成一个Iksubfld。IA标识符必须以一种确保唯一的方式被分
配。这可以在一个集中或分层的结构上使用。
5.2.1.3 版本/满期子域