rfc1113.txt

很多RFC的中文文档

      13 N            30 e            47 v
      14 O            31 f            48 w         (pad) =
      15 P            32 g            49 x
      16 Q            33 h            50 y           (1) *
 
   (1) The character "*" is used to enclose portions of an
   encoded message to which encryption processing has not
   been applied.
 
 
                       Printable Encoding Characters
                                  Table 1
      注意本地的形式和转换消息到标准形式及从标准形式转换的功能可以在发送者和接
收者之间无信息损失的变动。
4.4 封装机制
在一个由电子邮件传输系统解释的头的一个封装层里的保密增强消息的封装比一个
简单的被加密或携带密码控制信息的头内的一定域的简单的处理有更多的优势。封装提供
了一般性和那些在传输时被转换的消息的用户对用户级的隔离的域。被插入到加密/鉴别
过程中的所有的域被放置在封装的头中。这个功能为只接收文本没有从输入文件或从其它
程序获得头域的邮件处理程序提供了兼容性。此外，保密增强处理能被递归使用。关于
MTS，合并到密码鉴别或加密处理的信息将驻留到一个消息的文本部分，而不是头部分。
用于保密增强邮件的封装机制来自于RFC-934[11]中的叙述，这一叙述是基于internet
社区消息摘要处理的先例。准备的用于加密或鉴别的一个用户消息将被转换为图1中的表
述。
作为一般的设计原则，敏感的数据通过将数据导入到被封装的文本而不是通过将数
据导入到封装的头里的域的方法来进行保护。潜在的敏感头信息的域可以包括这些域例
如：“Subject：”，包含的内容对于端到端的用户和内部的用户有意义。应用保护的头域集
（可能是空的）由用户选择。不过强烈推荐所有的信息应当在封装文本里复制
“X-Sender-ID：”和“X-Recipient-ID：”域的拷贝。
如果一个用户希望对头域公开保护，他们必须只出现在被封装的文本中而不在被封
装的头中。如果公开保护要求一个消息的主题标识，推荐封装的头包含一个“Subject：”
域指出“被加密的邮件跟随”。
如果要求一个头信息的被鉴别的版本，除了本身在封装头里的数据，包含在被封装
的本文里的数据也能被复制。例如，一个发送者希望提供接收者一个在一系列被封装的文
本中的包括一个时间戳或消息计数域的被保护的消息的位置的标识。
一个与带有消息封装机制功能的保密增强邮件的完整性有关的特殊的点是值得注
意。被选择用于传输编码的IA5子集有目的的排除了字符“-”，因此被封装的文本可以明
确的同一个消息的结束封装的边界相区分（Post-EB）不用求助于字符的填充。
boundary (Post-EB) without recourse to character stuffing.
 
   Enclosing Header Portion
           (Contains header fields per RFC-822)
 
   Blank Line
           (Separates Enclosing Header from Encapsulated Message)
 
   Encapsulated Message
 
       Pre-Encapsulation Boundary (Pre-EB)
           -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
 
       Encapsulated Header Portion
           (Contains encryption control fields inserted in plaintext.
           Examples include "X-DEK-Info:", "X-Sender-ID:", and
           "X-Key-Info:".
           Note that, although these control fields have line-oriented
           representations similar to RFC-822 header fields, the set
           of fields valid in this context is disjoint from those used
           in RFC-822 processing.)
 
       Blank Line
           (Separates Encapsulated Header from subsequent encoded
           Encapsulated Text Portion)
 
       Encapsulated Text Portion
           (Contains message data encoded as specified in Section 4.3;
           may incorporate protected copies of enclosing and
           encapsulated header fields such as "Subject:", etc.)
 
       Post-Encapsulation Boundary (Post-EB)
           -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
 
 
                           Message Encapsulation
                                 Figure 1
4.5 邮件列表的邮件
当邮件被定位到邮件列表，可以采用两种不同的方法：IK-per-list方法和IK-per-recipient
方法。选择依赖于对于发送者可用的信息和发送者的兴趣。
如果一个消息的发送者定位一个消息到一个列表名或别名，表示他将一个IK和那个名
字或别名作为一个实体结合使用（IK-per-list），而不是决定到它的目的地的名字或别名。因
此IK必须对列表的所有成员都是可用的。对于非对称密钥管理的情况，列表的私有组件必
须的列表的所有成员都是可用的。另一种是凭借远端爆增站点发送消息的一般的情况，此时
到这样的列表的发送者可以不认识个别的接收者。不幸的是，它暴露了共享的IK，使它的
更新变得困难。此外，IK-per-list方法的使用允许列表的IK的任何拥有者可以伪装成其他的
为了鉴别的目的到这个列表发送者。
与此相对，如果一个消息的发送者可以将目的邮件列表扩展为自己的组成部分并选择
这么做（IK-per-recipient），消息的DEK（和，在对称密钥管理的情况下，MIC）将用每个
接收者的IK加密并且这些被加密的表述将被合并到被传送的消息中。注意每个接收者的加
密只要求在“X-Key-Info：”中携带相对小的DEK和MIC，不像加密消息文本时一般要求更
大。尽管更多的IK在IK-per-recipient方法中被处理，一对IK能被个别调用而且只拥有一
个IK并不能使另一个列表上的使用者成功的进行伪装。
4.6 被封装的头域小结
这部分总结了在保密增强处理的过程中被添加到消息中的被封装的头域的语法和语义。
这些头域分三组出现。正常的，一组将按顺序出现在被封装的头域，尽管在每一组里不是所
有的域都会出现在所有的消息中。在某些特定情况下，这些域被复制到被封装的消息文本中
也被包括到被封装的头中。图2和3是被封装的消息的小例子。图2假设使用对称的密钥管
理。图3假设说明了使用非对称的密钥管理的被封装的消息的示例。
如果没有其他的特殊的规定，所有的域参数以一种区分大小写的风格处理。在大多数情
况下，数字量以连续的十六进制数出现在头域中，每个数字通过从“0”到“9”或大写的“A”
到“F”的字符来表示。因此公钥证书和使用非对称算法加密的量尺寸比较大，一个更节省
空间的编码技术的使用对这样的量是合适的，而且定义在本文档4.3.2.4节的用可打印的字
符表示6位的编码机制被采用。在图3中显示的例子显示的被加密的非对称量（例如，
“X-Mic-Info：”，“X-Key-Info：”）用64个可打印的字符表示，对应384位。带有非对称加
密量的域也说明了定义在RFC822中的3.1.1节的折叠的使用。
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
   X-Proc-Type: 3,ENCRYPTED
   X-DEK-Info: DES-CBC,F8143EDE5960C597
   X-Sender-ID: [e-mail]::
   X-Recipient-ID: [e-mail]:ptf-kmc:3
   X-Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,B70665BB9BF7CBCD,
    A60195DB94F727D3
   X-Recipient-ID: [e-mail]:ptf-kmc:4
   X-Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,E2EF532C65CBCFF7,
    9F83A2658132DB47
 
   LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
   8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
   J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
   dXd/H5LMDWnonNvPCwQUHt==
   -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
 
 
               Example Encapsulated Message (Symmetric Case)
                                 Figure 2
 
 
   -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
   X-Proc-Type: 3,ENCRYPTED
   X-DEK-Info: DES-CBC,F8143EDE5960C597
   X-Sender-ID: [e-mail]::
   X-Certificate:
    jHUlBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIk
    YbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUz
    agV2IzUpk8tEjmFjHUlBLpvXR0UrUz/zxB+bATMtPjCUWbz8Lr9wloXIkYbkNpk0
   X-Issuer-Certificate:
    TMtPjCUWbz8Lr9wloXIkYbkNpk0agV2IzUpk8tEjmFjHUlBLpvXR0UrUz/zxB+bA
    IkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloX
    vXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLp
   X-MIC-Info: RSA-MD2,RSA,
    5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpotJ6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz
   X-Recipient-ID: [e-mail]:RSADSI:3
   X-Key-Info: RSA,
    lBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHU
   X-Recipient-ID: [e-mail]:RSADSI:4
   X-Key-Info: RSA,
    NcUk2jHEUSoH1nvNSIWL9MLLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72oh
    LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
    8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
    J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
    dXd/H5LMDWnonNvPCwQUHt==
   -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
              Example Encapsulated Message (Asymmetric Case)
                                 Figure 3
尽管被封装的头域类似RFC-822的头域，他们之间并没有交集而且不是使用同样的处
理密封头域的分析器。对被封装头域字典分析的复杂度明显比RFC-822头域的分析复杂度
要小。例如，许多对于在依据造句法的级别的RFC-822有特殊意义的字符在被封装的头域
中没有这种特殊的意义。
    当被封装的头域的长度比一行可打印的字符长度要长时，在RFC-822 3.1.1节中可以用
空格折叠这个域。任何这样空格的加入不会被解释为这一子集的一部分。作为一个特殊的例
子，由于公钥证书和使用非对称算法加密的量的长度，这些量经常需要被折叠成几行。为了
以统一的方式使用这种折叠，这样一个量的位表示按顺序（最左边的位置先出现）被划分0
或多于384位的组（对应64位可打印的字符的表示），最后一组可以是小于384位的任意的
长度。
4.6.1 每个消息被封装的头域
    这组被封装的头域包含在一个保密增强消息中出现不止一次的域，一般先于所有其他的
被封装的头域。
4.6.1.1 X-Proc-Type域
“X-Proc-Type：”被封装的头域，是所有的保密增强消息都必须具有的，标识对被传送
的消息进行的处理类型。在一个消息中该域只出现一次；“X-Proc-Type：”域必须在第一个
出现在被封装的消息头中。
“X-Proc-Type：”域必须有两个子域，被一个逗号分隔。第一个子域是一个十进制数用
于区别不兼容的被封装的头域说明可能会在以后对这个标准进行修改后出现。按照本文档消
息处理将带有子域值3用于与以前的RFCs 989和1040相区别。
第二个子域可以假设为两个字符串值中的一个：“ENCRYPTED”或“MIC-ONLY”。如