rfc2633.txt

很多RFC的中文文档

为了确定在发送将来CMS envelopedData消息给一个特别的接收器时的证书管理
密钥, 应该遵从下列步骤:
-	如果在一个从预期的接收器收到签名数据对象中发现一个
SMIMEEncryptionKeyPreference的属性,这可识别x.509 证书,此证书应该用来作为
接收者的x.509密钥管理证书. 
-	如果没能在预期的接收器收到数据对象中发现一个SMIMEEncryptionKeyPreference
的属性, 那应该用这类x.509证书来搜寻与x.509相同题目的证书,以此作为可用作
密钥管理的签名x.509证书.
-	或者用一些其他方法来确定用户的管理密钥. 如果一个x.509 密钥管理证书没找到,
那么密码术不能处理消息的签名.如果找到多个x.509密钥管理证书,那么S/MIME
代理可以在它们之间任意选择.
2.6 SignerIdentifier的SignerInfo类型
版本3.0的S/MIME要求使用版本1.0的SignerInfo,这是IssuerAndSeriaINumber 选
择必须用作SignerIdentifier.
2.7 ContentEncryptionAlgorithmldentifier
收发代理必须支持用DES EDE3 CBC来加密和解密,以下称
为"tripleDES"[3DES][DES]. 接收代理应该支持加密术和用RC2[RC2]解密或者用
一致的40bit大小的密钥来加密,以下成为"RC2/40".
2.7.1 确定用哪种加密方法
当一个发送代理产生一条加密消息时,它必须同时确定用哪类的加密术. 决定过程
包含使用存储在容量表里的信息,此表包含从接收器收到的消息, 也包含不相连的
信息比如私人协议,用户参数选择,合法限制等等.2.5节说明一种发送代理能随意定
义的方法,其它的例如它的优先顺序解密性能. 以下方法用来处理和记忆在引入签
名消息里的加密性能属性,这种方法应该使用.
-	如果接收代理还没为发送方的公共密钥创立个接收表,那在校验了引入的签名消息
和检查了时间标志后,接收代理应该创立个起码能容下签名时间和匀称性能的表.
-	如果这样的表已经存在,那接收代理应该校验引入消息的签名时间是否大于存储在
表里的签名时间且签名是否有效. 如果是,那接收代理应该同时更新表里的签名时
间和性能. 签名时间的值是个离将来很远的值,接收能力列在签名不能被校验的消
息里,它不必被接收. 存储性能表应该将来可用来产生消息.发送一条消息前,发送代
理必须决定是否对消息里的特殊数据使用不牢固的加密术.如果发送代理确定这不
牢固的加密术对此数据来说是不可接收的,那发送代理不必使用例如RC2/40的不牢
固加密术. 是否使用弱加密术不用考虑其它部分使用的加密算法. 2.7.2.1节到
2.7.2.4节写了一个发送代理决定选哪类加密术应用到消息中去.这些规则是安排好
的,所有发送代理应该根据安排好的规则来决定.
2.7.1.1 规则1:公开接收容量
如果接收代理已经从他打算加密的消息接收器里收到了一容量,那发送代理应该通
过选在表里的第一个容量来使用那信息,因为发送代理知道怎样加密. 如果代理很
希望接收方能解密消息的话,那发送代理应该表里的其中一个容量.
2.7.1.2 规则2:没公开接收容量,公开使用加密
		如果:
-	发送代理不知接收方的加密容量;
-	发送代理已从接收方收到不止一条消息;
-	从接收方收到的最后的加密消息里有可信任的签名.
那流出的消息应该使用相同的加密运算法则,这被用在最后的签名和从接收方收到
的加密消息.
2.7.1.3 规则3:没公开的容量,不知的S/MIME版本
		如果:
-	发送代理不知接收方的加密容量;
-	发送代理不知接收方的S/MIME版本;
那发送代理应该使用tripleDES因为它是一条更严格的运算法则且是S/MIME V3.0
所要求的.如果这一步发送代理不选择使用tripleDES,那它必须使用RC2/40.
2.7.2 选择弱加密术
像所有运算法则都用到40bit的密钥一样,RC2/40被许多人当作是弱加密术. 一个由
人控制的发送代理应该允许寄件人去决定使用RC2/40发送数据的风险或者在发送
数据前决定用相似的弱加密运算法则，或者可能允许他使用更严格的加密术比如
tripleDES．
２.7.3 多个收接人
如果发送代理是给一组接受人构成加密消息,这里说的接收方的加密容量是没有交
迭的.那么发送代理被迫发送多条消息. 应该注意如果发送代理选择的发送严格加
密的消息和用弱加密法则加密的同条消息的话,查看信道的人可能会发现用严格加
密的消息的内容被弱加密的消息所简化.
—————周梦龄部分

—————岑斌部分
3.创建s/mime信息
这部分描述了s/mime信息的格式和他们是怎样创建的。s/mime信息是mime体和cmc对象
的结合体。多种mime种类和cms对象被用到，保证安全的数据总是规范的mime实体。
Mime实体和诸如认证，签名算法等其它数据，提供给cms处理程序（此程序生成cms实体）。
Cms对象最后被包装在mime中。对s/mime加强的安全服务[ess]文件提供怎样s/mime信息
是如何嵌套，保证安全的。Ess提供一个说明如何使用适合于署名的multipart/signed 和
application/pkcs7来建立三重包装的s/mime信息。
s/mime提供一种邮件(只含数据)的格式,多种署名数据的格式，多种署名和邮件数据的格式，
为了适合多种环境，多种格式是需要的，特别对于署名信息来说。在这些信息种选择合适的
格式亦有描述。
这部分的读者期望能理解[MIME-SPEC]和[MIME-SECURE]中描述的MIME
3.1为署名和封装MIME实体作准备
s/mime用于MIME实体的安全性,一个MIME实体可能是一个信息的一个部分，或者是数据
的整个部分。MIME体是包含MIME头和MIME实体，但不包含RFC822头。注意：s/mime
能在保护MIME实体的安全方面的应用，除了应用于internet邮件，还应用于应用程序。被
保证安全的MIME实体部分在本部分认为是在内部MIME，也就是说，这是可能更大的
MIME信息的最深层的部分。把外部MIME实体处理成CMS对象在3.2 3.4 和其他的章节
中进行描述。
准备MIME实体的过程在[MIME-SPEC]中描述，在签名时，相同的过程也会使用，只是增
加了些附加约束条件，从[MIME-SPEC]的角度来看，这个过程的描述在这里是重复的，但
读者可能会想从这篇文档中获得附加的过程。这个章节同时也描述了附加的需要。
单一的过程在创建用于署名，封装，或署名和封装并举的MIME实体中。同时我们也要采
取一些步骤来防止在邮件传输过程中可能会出现的问题，这在使用multipart/signed各式的
clear-signing时特别重要的。同时我们也建议当时用在封装数据，或署名，封装数据上时，
要采取一些额外的步骤，以使数据在不改变的情况下传输到各个环境。
这些步骤与其说是说明性的还不如说是描述性的，只要结果是一样的无论是用何种过程都是
一样的。
第一步：根据本地的规则，准备MIME实体。
第二步：MIME实体的子部分被转换成规范的形式。
第三步：对MIME实体的子部分运用正确的传输编码。
当一条s/mime信息收到时，信息的安全服务首先被处理，其结果是MIME实体，MIME实
体会被传到有处理MIME能力的用户代理，在那里其会被进一步解码，并被传输到用户端。
3.1.1规范化
每一个MIME实体必须转化为一种规范形式，这种形式能在创建署名，和确认署名的环境
能唯一，无二义性的表示。MIME实体必须格式化，使之适合于封装和署名。
规范化的确切细节依靠实体的MIME类型及其子类，这在这里不会被阐述。
作为替代，会讨论特定MIME类型的标准。例如，text/plain类型的规范化和audio/basic的
规范化是不同的。除了文本类型，大多数类型不管计算平台和环境（能考虑他们的规范表示）
的差异只有一种表示。总的来说，规范化会被发送代理的非安全部分而不是S/MIME实现
执行。
文本最平常和重要的规范化在不同环境内的表示是不同的。主要类型text的MIME实体必
须把他们的行结束和字符规范化。行结束必为<cr><lf>对，字符集必是注册的字符集[charsets].
规范化的细节在[MIME-SPEC]中详细描述，选择的字符集应该在字符集参数中命名，以接
受代理能无二意的得出其使用的字符集。
特别要指出的是，一些字符集如[ISO-2022]对不同的字符有不同的表示。当准备要署名的文
本时，为了表示的规范，必须使用特定字符集。
3.1.2传输编码
当产生以下任何的安全MIME实体（除使用multipart/signed格式的署名），传输编码时不需
要的，S/MIME实现必须能处理二进制MIME对象。如果无内容传输编码头，传输编码必须
是7位的。
然而，S/MIME的实现应该使用在3.1.3中描述适合所有安全的MIME实体的传输编码。保
证只有7位的MIME实体（即使是不向传输环节暴露的封装数据也被编码成7位的）原因
是允许MIME实体能在不被篡改的情况下，在任何环境中处理。例如，一个信任的网关会
去掉信息的封装，而非署名，然后继续传输数据至接受端，所以他们能直接确认签名。如果
在诸如带有单独邮件网关的广域网等非8位clean站点内部传输，除非原始的MIME实体是
7位数据，确认署名江市不可能的。
3．1．3署名的传输编码是使用Multi/signed的
如果一个multipart/signed 实体曾经传输通过标准的internet　SMTP的下层结构或其他被约
束为7位文档的传输体系，那么它一定是被编码成7位的文本。7位数据的MIME实体无需
传输编码。8位文档的实体和二进制数据能用打印字符和base-64传输编码进行编码。
7位编码的首要原因是Internet邮件传输的下层结构，不能保证8位数据或二进制数据。即
使很多传输段的下层结构能处理8位和二进制数据，但有时候要知道数据的传输路径是8
位clear的是不可能的。如果8位的邮件信息遭遇不能传输8位或二进制数据的信息传输代
理。代理有三种选择，但无论哪一种对于clear-signed信息是不可接受的。
1．	代理改变传输编码，它是署名无效
2．	代理能传输数据，但很可能破坏第8位数据，这同样使署名无效。
3．	代理返回数据该给发送者。
[MIME-SECURE]禁止代理改变multipart/signed信息第一部分的编码，如果不能传输二
进制和8位数据的兼容的代理遇到第一部分是8位或二进制数据，它可能要把信息返回
该发送端。
3．1．4 简单的规范MIME实体
   这个例子现实一个完全传输编码的multipart/mixed信息，这个例子包含一个文本部分和
附件，这个简单信息文本包含非US-ASCII字符，它必须进行传输编码。这里虽然没显示，
但每一行都是以<CR><LF>结束，MIME头，文本，传输编码部分必须以<CR><LF>结束.
我们来看一下非S/MIME信息的例子：
Content-Type: multipart/mixed; boundary=bar

     --bar
     Content-Type: text/plain; charset=iso-8859-1
     Content-Transfer-Encoding: quoted-printable

     =A1Hola Michael!

     How do you like the new S/MIME specification?

     I agree. It's generally a good idea to encode lines that begin with
     From=20 because some mail transport agents will insert a
     greater-than (>) sign, thus invalidating the signature.

     Also, in some cases it might be desirable to encode any  =20
     trailing whitespace that occurs on lines in order to ensure  =20
     that the message signature is not invalidated when passing  =20
     a gateway that modifies such whitespace (like BITNET).  =20

     --bar
     Content-Type: image/jpeg
     Content-Transfer-Encoding: base64

     iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
     jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
     uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
     HOxEa44b+EI=

     --bar--

3.2 application/pkcs7-mime类型
   application/pkcs7-mime类型被应用于传送包含封装数据和署名数据的多种CMS对象。
构造这些信息的细节在接下来的部分中描述，这部分描述的是application/pkcs7-mime类型
的总体特征。被传输的CMS对象往往包含一个MIME实体，假如ecounttype是id-data那么
实体应像3.1部分描述的那样进行准备。当ecounttype包含不同的值时，其他的内容可能也
要传输。要想获得这种例子和签名收条，请参见[ESS]。
因为CMS对象是二进制对象，在大多数情况下，base-64传输编码是正确的，特别当时用在
SMTP传输中，使用的传输编码依靠发送对象的传送设备，而非MIME类型的特点。
值得注意的是这里的讨论指CMS对象或外部MIME实体的传输编码。它区别于由CMS对
象保证安全性的MIME实体（即是内部对象，在3.1部分描述）的传输编码，同样，和他也
没有联系。因为Application/pkcs-7MIME对象由多种种类，发送代理应尽力使接受代理不强
制对对象进行ASN.1解码就知道对象的内容，所有APPLICATION/PKCS7-MIME对象的
MIME头应包含任选的SMIMETYPE参数，这在以后的章节中会阐述。
3．2．1名称和文件名称参数
对于APPLICATION/PKCS7-MIME来说，为了和旧系统的兼容，发送代理应发出任选
的"NAME"参数给CONTENT-TYPE域，发送代理也应把FILENAME参数发出任选的内容
描述域[CONTDISP]，如果发送方发出了以上参数，他们的值应是一个有着准确扩展名的文
件的名称
MIME Type                                File Extension

   Application/pkcs7-mime (signedData,      .p7m
   envelopedData)

   Application/pkcs7-mime (degenerate       .p7c
   signedData "certs-only" message)

   Application/pkcs7-signature              .p7s
另外，文件名称应被限制在带有三个扩展名和8个字符以内的范围内，8个字符的文件名可
以是任何的能唯一表示的名字，文件名'SMIME'应使用在表示MIME实体和S/MIME相联
系。
包含文件名有两个作用：它能把S/MIME的使用简单化为磁盘上的文件，同时，他亦能转
换种类信息，以使之能通过网关。当一个APPLICATION/PKCS-7MIME类别的MIME实体