rfc2633.txt

很多RFC的中文文档

到达一个没有S/MIME专门的知识的网关时，它可能会默认实体的MIME类型是
APPLICATION/OCTET-STREAM类型，并把它当成一般的附件，这样就损失了类型信息，
然而，附件的文件名常常会被带过网关。这常常允许接收系统确定正确的应用来把附件卸下
来交给单独的S/MIME处理应用。值得注意的是：这个机制是为了在某些环境中方便实现
而提供的，正确的S/MIME实现以使用MIME类型，而非依靠文件的扩展。
3．2．2 S/MIME类型的参数
APPLICATION/PKCS7-MIME内容类型定义了任选的'SMIME-TYPE'参数，参数的目的是转
化成和包含内容的信息一起的安全性的细节，这个备忘录定义了以下的SMIME-TYPE.
   Name                   Security                Inner Content

   enveloped-data         EnvelopedData           id-data

   signed-data            SignedData              id-data

   certs-only             SignedData              none

为了在未来实现一致性，当分配一个新的SMIME参数时应遵守以下要点：
1：如内容要进行署名和加密，SMIME-TYPE的两个值应被赋
为"SIGNED-*","ENCRYPTED"。如果一个操作被赋值，那么其可被忽略。这样，即使只
有"CERTS-ONLY"被署名，“SIGNED-”也会被忽视。
2．要赋给内容OID一个通用的字符串，当MIME是内部内容，我们使用“DATA”作为ID-
数据内容OID。
3．如果不赋予通用字符串，那么建议使用OID.<OID>的通用字符串（如
"OID.1.3.6.1.5.5.7.6.1"表示DES40）。
3.3 创建只被封装的信息
这部分描述不署名封装的MIME实体的格式。这一点很重要：发送封装但未署名的信息部
提供数据的完整性服务。它可以用密码进行更替，这样信息虽然是有效的，但其意义可能以
改变了。
第一步：依3.1节准备封装MIME实体。
第二步：MIME实体和其他必需数据处理成封装数据的CMS对象，除了为每一个接收者加
密内容加密钥匙的拷贝，内容加密钥匙的拷贝亦应为创作者加密，保存在封装数据中（见
CMS第6节）
第三步：把CMS对象插入APPLICATION/PKCS-MIME MIME实体中。只封装数据的
SMIME-TYPE参数是“封装数据”，这种信息的文件扩展是'.P7M'.
例举一个简单的消息：
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
            name=smime.p7m
       Content-Transfer-Encoding: base64
       Content-Disposition: attachment; filename=smime.p7m

       rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
       7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
       f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
       0GhIGfHfQbnj756YT64V
3.4创建署名信息
   在S/MIME中定义的署名信息有两种格式： APPLICATION/PKCS7-MIME和署名数据，
以及MULTIPART/SIGNED;总的来说，MULTIPART/SIGNED格式最适合于发送，接受代理
应能处理以上两种。
3．4．1 为署名信息选择格式
因为依靠接受者的能力和同没有可以浏览信息的S/MIME软件的重要性相比较更重要的接
收端认证署名的能力，当要选择特定的只署名格式，没有即快又坚决的规则。
使用MULTIPART/SIGNED格式的签名信息无论接收端有没有安装S/MIME软件，总能浏览
信息。他们被看成使用MIME本地用户代理或信息被网关转发。在这篇文章中，‘被看到’
意思是说本质上处理信息的能力就像处理非署名信息，当然，信息也可包含其他MIME结
构。
如果接受端有S/MIME能力，那其能看到使用署名数据 格式的署名信息。然而，如果其有
S/MIME能力且在传输构成中信息不被改变，信息总是可以被确认的。
3．4．2 使用APPLICATION/PKCS7-MIME和署名数据的署名
署名格式使用APPLICATION/PKCS7-MIME MIME类型，创建这种格式的步骤如下：
第一步：依照,3.1节准备MIME实体。
第二步：MIME实体和其它需要的数据处理成署名数据类型CMS对象。
第三步：把CMS对象插入APPLICATION/PKCS7-MIME MIME实体.
使用APPLICATION/PKCS7-MIME 的SMIME-TYPE参数和署名数据是“署名数据”，文件
扩展是'.P7M'。
一个简单的例子：
Content-Type: application/pkcs7-mime; smime-type=signed-data;
            name=smime.p7m
       Content-Transfer-Encoding: base64
       Content-Disposition: attachment; filename=smime.p7m

       567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
       77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
       HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
       6YT64V0GhIGfHfQbnj75
3．4．3 使用MULTIPART/SIGNED格式的署名
这种格式是CLEANIGN-SIGNING格式。没有S/MIME或CMS处理能力的接受端能看到信
息，他使用了描述在[MIME-SECURE]中的MULTIPART/SIGNED MIME类型。
MULTIPART/SIGNED MIME类型有两部分：第一部分包含署名的MIME实体，第二部分包
含分离的署名CMS署名数据对象，在其中,ENCAPCONTENTINFO ECONTENT域时空的。
3．4．3.1 APPLICATION/PKCS7-MIME类型
这种MIME类型总是包含单个的署名数据类型的CMS对象。署名数据的
ENCAPCONTENTINFO ECONTENT域必是空的。SIGNERINFOS域包含MIME实体的署名。
使用APPLICATION/PKCS署名的只署名信息的文件扩展是‘.P7S’。
3．4．3．2 创建MULTIPART/SIGNED信息
第一步：依照3.1节准备要署名的MIME实体，特别注意CLEAN_SIGNING。
第二步：为了获得署名数据对象(其ENCAPCONTENTINFO ECONTENTZ域是空的)，把
MIME实体提供给CMS处理。
第三步：把MIME实体插入MULTIPART/SIGNED信息的首部，MULTIPART/SIGNED信息
没有经过处理，和在3.1节描述的不一样。
第四步：转换编码应用于分离的署名CMS署名数据对象，他亦会被插入于
APPLICATION/PKCS署名的MIME实体
第五步：MULTIPART/SIGNED实体的第二部分应插入APPLICATION/PKCS7-SIGNATURE
的MIME实体
MULTIPART/SIGNED内容类型有两个参数：协议参数和MICALG参数。
协议参数必是application/pkcs7-signature，注意因为MIME要求：在参数中的‘/’
字符必用引号，在协议参数的旁边需要引号。
当署名被确认后，MICALG参数允许单通处理。MICALG参数的值依靠用在消
息完整性检测计算的消息数字计算法则。如果使用了多个消息数字算法，他们必
须每个[MIME-SECURE]用逗号进行分割。在MICALG参数的值应依据以下：
Algorithm   Value
   used

   MD5         md5
   SHA-1       sha1
   Any other   unknown
(历史标注：一些早期的S/MIME实现程序发送和期望用于MICALG参数
的 "RSA-MD5","RSA-SHA1".)
接受代理应能从他们不认识的MICALG参数中恢复。
3.4.3.3简单的MULTIPART/SIGNED消息
Content-Type: multipart/signed;
          protocol="application/pkcs7-signature";
          micalg=sha1; boundary=boundary42

       --boundary42
       Content-Type: text/plain

       This is a clear-signed message.

       --boundary42
       Content-Type: application/pkcs7-signature; name=smime.p7s
       Content-Transfer-Encoding: base64
       Content-Disposition: attachment; filename=smime.p7s

       ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
       4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
       n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
       7GhIGfHfYT64VQbnj756

       --boundary42--
3.5署名和加密
为了获得署名和封装，会嵌套只署名或只加密的格式。因为以上的格式是所有MIME实体，
同时他们也是安全的MIME实体，所以这是允许的。
在接受端计算机的合理能力范围内，S/MIME实现程序必能接受和处理任意的S/MIME嵌套。
对一个信息首先进行署名或封装是可能的，这是依靠实现程序和用户的选择。当署名优先时，
在封装中署名会被隐藏。当封装优先时，署名会被暴露，但这使在不移去封装的情况下确认
署名。这在自动署名认证的环境中是有用的，因为这时认证书明无需私匙。
选择首先署名还是首先加密有两种不同的安全分叉。首先加密，然后署名的数据的接受者能
不改变加密的数据块，但不能确定署名者和没加密的信息内容的关系。首先署名后加密的信
息接受者能确认署名信息本身没改变，但小心的攻击者能改变加密数据的没有认证的部分
3.6创建只认证信息
只有证书的消息或MIME实体用于传输证书，诸如对注册请求地响应。这种格式亦能被用
于传输CRL
第一步：把证书变换成适合产生署名数据的CMS对象的CMS产生过程。署名数据的
encapcontentInfo eContent 域必须空缺，singerInfos 域亦必须空缺。
第二步：CMS署名数据对象包含在application/pkcs7-mime MIME实体中。
Certs_only 信息的Smime-type参数是"certs-only"的。文件的扩展名为“.p7c”。

—————岑斌部分
—————汤琼部分
3.7请求注册
给消息签名的发送代理必须拥有签名证书，这样，接收代理才能验证签名。取得证书通
常有几种方法，如通过与证书机构交流或通过硬件记号或磁盘等等来获得证书。
S/MIME v2给出了一种使用application/pkcs10 主体部分来向证书机构注册公钥的方
法。The IETF's PKIX Working Group则提供了请求证书的另外一种方法；然而，在写本备忘
录时该方法还没完成。S/MIME v3没有具体指出怎样去请求证书，而是管理每一个发送代
理已经有的证书管理标准由IETF制定。
3.8识别S/MIME消息
因为S/MIME考虑到与非S/MIME环境的互操作性，采用了几种不同的机制传送信息，
这使得S/MIME消息的识别有了一些困难。下面表格列出了判断一条消息是否是S/MIME
消息的标准。符合下表的消息就被认为是S/MIME消息。
列表中的文件后缀来自内容类型报头的"name"参数，或者来自内容部分报头的
"filename"参数。给出文件后缀的这些参数没有作为参数部分列在下表中。
MIME type:   application/pkcs7-mime
   parameters:  any
   file suffix: any
   MIME type:   multipart/signed
   parameters:  protocol="application/pkcs7-signature"
   file suffix: any
   MIME type:   application/octet-stream
   parameters:  any
   file suffix: p7m, p7s, p7c

4.证书处理
接受代理为了访问数字信封的收件人的证书，必须提供一些证书检索机制。本备忘录不
涉及S/MIME代理怎样处理证书，只是说明在证书被确认有效或被否定后，他们作什么。
S/MIME证书事项在[CERT3]中有说明。
对于S/MIME的初始配置，用户代理至少能产生一条消息给指定的收件人，要求他的
签署证书返回消息。接收代理和发送代也应该提供容许用户为通信者“存储和保护”证书，
这样就能够保证他们以后的检索。
4.1产生密钥对
如果S/MIME需要产生密钥对，那么，S/MIME代理商或相关的执行部门必须能够为用
户生成DH和DSS公钥/私钥对。每对密钥必须由好的非确定性的随机输入源产生，而且，
私钥必须以某种安全的方式保护起来。
如果S/MIME代理需要生成密钥对，那么该S/MIME代理或相关的执行部门应该生成
RSA密钥对。
用户代理应该生成至少768位长度的RSA密钥对。用户代理不应该产生少于512位的
RSA密钥对。生成的密钥长于1024位将会使一些老的S/MIME接收代理不能验证签名，但
具有更好的安全性，因此是有价值的。接收代理应该能验证用任何超过512位的密钥的签名。
在美国一些代理为了获得更有利的出口许可而选择生成512位密钥。然而，用512位密钥加
密在很多人士看来是不安全的。实现者应该注意到个人可联合使用多对密钥。例如，一对密
钥可用来保证机密性，而另一对密钥则用来作认证。
5 安全
该整编的备忘录（全用来）讨论安全问题。在其他部分没有涉及的安全事项包括：
大多数译解密码者都认为40位加密是脆弱的。在S/MIME中使用脆弱的加密方法和发
送明文一样不具有实际的安全性。然而，S/MIME的其他特征，如tripleDES规范以及宣
称更强的加密能力和对方交流的能力，允许发送者生成用强加密处理的消息。除
非别无选择，否则绝不推荐使用弱加密。如果可行，发送和接收代理应该通知发
送者和接收者消息的相关加密长度。
对大多数软件或人来说，评估消息的价值是不可能的。而且，大多数软件或人来说，评
估用特殊长度的密钥加密来加密消息的代价同样是不可能的。而且，假如收件人不能解码消
息，确定一个失败的解密也是相当困难的。因此，在不同的密钥长度作选择也是不可能的。
然而，所做的决定总是基于这些标准，因而本备忘录给出了在选择算法时使用那些评估的框