rfcrfc2633.txt

本程序为在linux下实现FTP传输文件的实现

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：阮健（ruanjian   [e-mail]）
译文发布时间：2001-12-28
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。

Network Working Group                               B. Ramsdell, Editor
Request for Comments: 2633                          Worldtalk
Category: Standards Track                            June 1999


S/多用途网际邮件扩充协议(MIME)版本3信息说明书 
(RFC2633——S/MIME Version 3 Message Specification)
本备忘录的状态
本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建
议以得到改进。请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化
程度和状态。本备忘录的发布不受任何限制。
版权声明
Copyright (C) The Internet Society (1999).

目录
1绪论	2
1.1说明书概要	2
1.2 术语	3
1.3 定义	3
2 CMS 选择	4
2.1运算法则表示符摘要	4
2.2运算法则表示符摘要	4
2.3运算法则表示符密钥	4
2.4 一般语法	4
2.5 签名信息类型的特征	5
2.6 SignerIdentifier的SignerInfo类型	8
2.7 ContentEncryptionAlgorithmldentifier	8
3.创建s/mime信息	10
3.1为署名和封装MIME实体作准备	10
3.2 application/pkcs7-mime类型	14
3.4创建署名信息	16
3.5署名和加密	19
3.6创建只认证信息	20
3.7请求注册	20
3.8识别S/MIME消息	20
4.证书处理	21
4.1产生密钥对	21
5 安全	22
A. ASN.1 模型	22
B. 参考文献	26
C. 致谢	28

1绪论
S/MIME(安全/多用途网际邮件扩充协议)规定一个一致路径去发和收安全MIMI数据.基
于流行的网络MIME标准,S/MIM为电子通讯提供了以下用密码写的安全服务:起因(利
用数字签名),秘密和数据安全(利用加密术)的证明,信息完整性和非批判.S/MIME被传统
的邮件使用代理商用来给要发的邮件加密码安全服务,且给收到的邮件解释用密码写的
安全服务.可是S/MIME没对邮件限制;它可用于任何传输MIME数据的机器中,比如
HTTP.同样的,S/MIME利用基于MIME特征的对象和允许安全信息在混合传输系统中被
交换.更多的,S/MIME用于自动信息传输代理中,这种代理用密码安全服务,是不需要人干
涉的,例如在网络上传送产生软件文档的标签和传真信息的加密术.
1.1说明书概要
本文讲关于加密码的签名和服务于MIME数据密码术的协议.MIME标准[MIME-规
格]规定了一个关于网络信息的内容类型一般结构且允许为新的内容类型应用扩充.
这个备忘录详细说明怎样产生一个MIME实体部分,这个部分已经根据CMS增强了
密码功能, CMS源于PKCS#7.本备忘录也详细说明了MIME类型,此MIME类型能用
来传输那些实体部分.同样本备忘录也讨论怎样用多部分/有符号MIME类型在
[MIME-安全]说明传输S/MIME注释的消息.本备忘录也说明了PKCS7的应用-MIME
类型签名,此MIME类型签名也用来传输S/MIME签名消息.为了产生S/MIME消
息,S/MIME代理商必须在本备忘录里追求规范,说明书也一样有序列在用密码写的
消息里.在整个备忘录里,有要求和建议用来处理接收代理如何控制进来的消息.有部
分要求何建议用来处理发送代理如何产生流出的消息.总的来说,最好的策略是"在呢
收到消息中是自由的而在呢发送消息中是保守的." 大多的要求是来控制流入消息
同时多数建议是来产生流出消息.对收方代理和发方代理有不同要求也因为可能有
S/MIME系统用于不同于传统网络邮件客户的软件.S/MIME能用于任何传输MIME
数据的系统中. 比如,一种自动化发送一条密码化消息过程可能完全不能收到一条密
码化消息.因此,对两种类型的代理,要求和建议是分别在适当时候列出.
1.2 术语
本文中的关键字“必须”，“必须不”，“要求的”，“应该”，“不应该”，“会”，“不会”，
“建议”，“或许”，“可选的”在 [MUSTSHOUD] 中解释。
1.3 定义
本备忘录的目的,应用以下定义.
ASN.1:摘要语法符号 1,在CCITT X.208中有定义.
证明书:把一个实体的显著名字与有数字签名的公共密钥帮定的类型.
DER:用于ASN.1显著的译成密码的规则,在CCITTX.509中定义.
7-bit 数据:少与998特征长的原文数据线,998中没有第8bit装置的特征,也没有
无效的特征. <CR>和<LF>仅发生在线的最后分隔符<CR><LF>部分.
8-bit 数据: 数据:少与998特征长的原文数据线,998中没有第8bit装置的特征,
也没有无效的特征. <CR>和<LF>仅发生在线的最后分隔符<CR><LF>部分.
二元数据:任意的数据.
传递编码:对数据反复翻译那么8-bit或二元数据可以经过一条只有7-bit数据传
输的通道发送.
接方代理:解释和处理S/MIME CMS对象的软件,MIME实体部分包含CMS对象,
或者二者都包括.
发送发代理:产生S/MIMECMS对象的软件,MIME实体部分包含CMS对象或者
二者都包括.
S/MIME 代理:软件用者是一个接方代理,也是个发送方代理,或者二者都是.
1.4 优先实际应用S/MIME的兼容性
版本3,0的S/MIME代理商应该尽力与版本2,0的代理商协同工作.版本2.0 代
理商经RFC 2315改进在RFC 2311中有说明.RFC2311关于S/MIME发展也有一段
历史信息.
2 CMS 选择
CMS允许在内容和运算法则支持中有广泛的选择.为了在所有的S/MIME执行中取
得协同工作的基本水平,这部分提出许多有支持力的要求和建议.[CMS]提供了关于
密码化的运算法则用法的额外详细资料.
2.1运算法则表示符摘要
发送方和接收方代理商必须支持SHA-1[SHA1].接收方代理应该支持MD5[MD5]实
现后面与MD5-摘要 版本2.0 S/MIME 签名数据对象相兼容的目的. 
2.2运算法则表示符摘要
发送方和接收方代理商必须支持在[DSS]定义的符号.运算法则参数必须缺少的(不
能当无效译码). 接收方代理应该支持加密术,在[PKCS-1]里有定义.发送方代理应
该支持加密术.流出的消息签有用户的私人密钥.私人密钥的大小是在密钥产生时决
定的. 版本2.0 S/MIME客户记录只能证明用在加密术算法准则的数字签名.
2.3运算法则表示符密钥
		发送和接收代理商必须支持DH,在[DH]有定义. 接收代理商应该支持加密术. 引入
的加密消息包含对称密钥,它可以用用户的私人密钥来解释明白. 私人密钥的大小时在密钥
产生时决定的. 发送代理商应该支持加密术. 版本2,0 S/MIME 客户记录只能解释用在加密
术运算法则的内容加密密钥中.
2.4 一般语法
  		CMS 定义了多样内容的类型. 这里面,只有有符号数据和信封数据内容类型目前
是用在S/MIME. 
2.4.1 数据内容类型
		发送方代理必须用数据ID类型标签符来说明已应用了安全服务的消息内容.比如,
当把一个数字签名应用到MIME数据时,CMS的有符号数据、encapContentInfo、eContentType
必须包含数据ID对象的表示符且MIME内容必须被保存在有字符串八位字节的符号数据、
encapContentInfo、eContent里(除非发送代理商正使用多个部分或多个符号,在这种情况下
eContent事缺少的,本文的3.4.3节有说明). 举一个另外例子,当应用加密术到MIME数据时, 
CMS的信封数据、加密内容信息、内容类型必须包含数据ID对象的标识符和加密的MIME
内容必须被存在字符串八位的信封数据、加密的内容信息、加密的内容里。
2.4.2 符号数据内容类型
发送方代理必须使用符号数据内容类型把数字签名应用到消息中,或者在没有
签名信息的退化例子里把数字签名应用到证明的传递中.
2.4.3 信封数据内容类型
			内容类型被用来对消息的私人保护. 一个发送方需要用此服务得到开启双方
信件的公共密钥. 内容类型不用提供签名.
2.5 签名信息类型的特征
			签名信息类型允许把有符号的与没符号的属性,随同签名包括在一块. 接收方
代理必须能够处理零或者这种在这里列出的符号属性情况.发送方代理应该产生下列每个
S/MIME消息的符号属性情况:
-	签名时间(在本文2.5.1节)
-	sMIME容量(在本文2.5.2节)
-	sMIMEncryptionKeyPreference(在本文2.5.3节)
更进一步说,接收方代理应该能处理零和一种签名证明属性的符号属性的情况(在
[ESS]第五节). 发送方代理应该产生在每个S/MIME消息里签名证明有符号属性情
况. 另外的属性和值可能在将来被定义.接收方代理应该处理在优美风格里没被承
认的属性和值. 发送代理包括没列在这里的符号属性应该显示给用户,从而使用户
知道所有有符号的数据.
2.5.1	签名时间的属性
签名时间属性用来传达签名消息的时间.除非有可信任时间标印服务器,否则签名时
间将很有可能被消息递交方产生,因此和递交方有相同的信任程度. 发送方代理商
必须通过2049年作为UTCTime把时间签名译成密码;签名时间在2050年或者以后
必须译成GeneralizedTime密码.当UTCTime选择被使用时,S/MIME代理器必须说
明以下年限:
如果年限大于或等于50,那年代就认为是19YY; 如果年限是小于50,那年代就认为
是20YY.
2.5.2 SMIME容量属性
SMIME容量属性包括签名运算法则(比如"有RSAD的sha1加密术"),对称运算法则
(比如"DES-EDE3-CBC"),主要密码术的运算法则(比如RSA加密术).它也包括一种
适用于签名日期的无运算法则性能.SMIME性能是灵活的和可扩展的,这样的话,在
将来,比如对证书另外性能和参数选择进行鉴别,这种功能能在不导致当前客户程序
停止的情况下加进去.如当面的,SMIME容量属性必须是一个签名属性;它不应该是
UnsignedAttribute.CMS把SignedAttributes定义成一套属性. 在签名信息里
SignedAttributes必须不包括SMIMECapabilities属性的多种情况.CMS为ASN.1排
序结构定义了属性包括一套属性值的附加值.一个SMIMECapabilities属性必须仅
仅包括属性值的单个情况.不必有零或在一套属性值中附加值中属性值的多种情
况.SMIMECapabilites属性的语义详细说明了关于SMIMECapabilites能支持的客户
程序的多部分列表.客户程序不必列出所有它支持的性能,也不应该列出,这样可以
使得性能列表不会变的太长. 在一个SMIMECapabilities属性里,0ID根据它们的优
先顺序列出来,但逻辑上应该根据它们的类别分别列出(签名运算法则,均衡运算法
则,加密密钥运算法则,等.) SMIMECapabilities属性的结构有利于简单的表格查询和
为了测定仪器的二进制比较.例如, 有DES EDE3 CBC SMIMECapability的 
DER-encoding 必须不管执行结果一致同仁的译成编码. 在均衡运算法则的情况
下,0ID的相关参数必须详细说明所有必需的参数来区分二种运算法则相同情况. 
例如,除了密钥长度外,RC5的许多圆圈和块大小必须被详细说明. 有一个
0ID(S/MIME用到的0ID)是重点维护的,它是从备忘录里分离出来的. 这个0ID表是
由在<http://www.imc.org/ietf-smime/oids.html>IMC来维护的 注意所有有关联
的0ID必须执行在本文A节提到的运算法则.符合运算法则的0ID应该在实际运用
时使用相同的0ID,除了对0ID来说运算法则的用法是不明确的. 例如,在初期的草
案中,rsaEncryption是不明确的,因为它可以指签名运算法则也可以指加密密钥法则.
在0ID不明确的情况下,需要维护者对已登记的SMIMECapabilities表根据运算法则
的类型使用0ID 作出正确的判断.新的0ID 必须允许smimeCapabilities 的0ID来
满足使用其他的0ID. 已登记的SMIMECapabilities表详细说明了0ID需要的参数,
在变量长度密码对称的情况下,多数主要密钥加长. 结果对特别的0ID来说没有可
区分的参数,那参数必须省略且不能被译成为无效. SMIMECapabilibies属性的额外
值在以后可被定义. 接收代理方必须处理一个SMIMECapabilities对象,它拥有在优
美风格里不被承认的值.
2.5.3 密码密钥的优先属性
密码密钥优先属性允许签名者明确说明签名者的证书有签名者的优先密码密钥. 
设计这属性来增强为了混合那些对加密和签名用不同的密钥的客户的行为能力.用
这种属性来传送任何个列在证书里的属性,这种证书应该用来给以后加密的信息加
密一个回话密钥.如果存在,SMIMEEncryptionKeyPreference属性必须是个
SignedAttribute; 它不必是个UnsignedAttribute. CMS定义SignedAttributes为一类属
性. 签名信息里的SignedAttributes不必包括SMIMEEncryptionKeyPreference属性
的多种情况. CMS为属性定义了ASN.1的排列方式用来包括.属性值的一类额外值. 
SMIMEEncryptionKeyPreference的属性必须仅仅包含属性值的单个情况. 不必有零
或存在属性值里的一类额外值多种情况. 发送代理商应该包含一类证书里的参考
证书,如果此属性被使用那这类证书还包含签名信息. 如果证书先前对接收代理来
说是可利用的那它可以被省略. 如果一般用法或者先前的加密证书与用来消息签
名的证书不一样,那发送代理应该使用这个属性. 如果消息上的签名是有效的和签
名时间大于目前存储的值,那么接收代理应该存储优先的数据.(同样对
SMIMECapabilities,应该检查时钟skew,如果skew太大就不使用数据.) 如可能接收
代理应该尊重发送者的加密密钥的优先选择属性. 但这尊重仅仅是一种优先选择,
接收代理在回答发送者时可使用任何有效的证书.
2.5.3.1 管理证书中接收密钥的选择