组织：中国互动出版网（http://www.china-pub.com/） RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm） E-mail：ouyang@china-pub.com 译者：阮健（ruanjian rj79@sina.com） 译文发布时间：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装置的特征,也没有
无效的特征.
―――――岑斌部分
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实体必
须把他们的行结束和字符规范化。行结束必为
--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实体 到达一个没有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.
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规范以及宣 称更强的加密能力和对方交流的能力，允许发送者生成用强加密处理的消息。除 非别无选择，否则绝不推荐使用弱加密。如果可行，发送和接收代理应该通知发 送者和接收者消息的相关加密长度。 对大多数软件或人来说，评估消息的价值是不可能的。而且，大多数软件或人来说，评 估用特殊长度的密钥加密来加密消息的代价同样是不可能的。而且，假如收件人不能解码消 息，确定一个失败的解密也是相当困难的。因此，在不同的密钥长度作选择也是不可能的。 然而，所做的决定总是基于这些标准，因而本备忘录给出了在选择算法时使用那些评估的框 架。 如果，发送代理用不同长度的加密发送消息，监听通信信道的黑客就能够通过解密弱加 密的消息确定用强加密的消息。换句话说，发送者应该和不发送明文一样不发送弱加密的消 息。 如果也不使用认证，密文的修改将能不被识别，就如发送被封装的数据而没有把他装入 签名的信封中或者没有在其中包含签名信息一样。 A. ASN.1 模型 SecureMimeMessageV3 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) smime(4) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS -- Cryptographic Message Syntax SubjectKeyIdentifier, IssuerAndSerialNumber, RecipientKeyIdentifier FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) };
-- id-aa is the arc with all new authenticated and unauthenticated -- attributes produced the by S/MIME Working Group
-- signingTime OBJECT IDENTIFIER ::= -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) -- 5} -- See [CMS] for a description of how to encode the attribute -- value.
END B. 参考文献 [3DES] ANSI X9.52-1998, "Triple Data Encryption Algorithm Modes of Operation", American National Standards Institute, 1998. [CERT3] Ramsdell, B., Editor, "S/MIME Version 3 Certificate Handling", RFC 2632, June 1999. [CHARSETS] Character sets assigned by IANA. See . [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. [CONTDISP] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. [DES] ANSI X3.106, "American National Standard for Information Systems- Data Link Encryption," American National Standards Institute, 1983. [DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. [DSS] NIST FIPS PUB 186, "Digital Signature Standard", 18 May 1994. [ESS] Hoffman, P., Editor "Enhanced Security Services for S/MIME", RFC 2634, June 1999. [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April 1992. [MIME-SPEC] The primary definition of MIME. "MIME Part 1: Format of Internet Message Bodies", RFC 2045; "MIME Part 2: Media Types", RFC 2046; "MIME Part 3: Message Header Extensions for Non-ASCII Text", RFC 2047; "MIME Part 4: Registration Procedures", RFC 2048; "MIME Part 5: Conformance Criteria and Examples", RFC 2049, September 1993. [MIME-SECURE] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. [mustshould] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP14, RFC 2119, March 1997. [PKCS-1] Kaliski, B., "PKCS #1: RSA Encryption Version 2.0", RFC 2437, October 1998. [PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998. [RANDOM] Eastlake, 3rd, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [RC2] Rivest, R., "A Description of the RC2 (r) Encryption Algorithm", RFC 2268, January 1998. [SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute of Standards and Technology, U.S. Department of Commerce, DRAFT, 31May 1994. [SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998. C. 致谢 非常感谢S/MIME Version 2 Message Specification RFC的其他作者：Steve Dusse, Paul Hoffman, Laurence Lundblade and Lisa Repka。没有v2就不会 有v3。 许多S/MIME工作组的成员也工作很努力，并为本文档作出了贡献。如果把所 有的人都列出来，将会很冗长，我为此深感抱歉。按字母顺序下面这些人名显示 在我的脑海中，因为他们对本文档作出了直接的贡献。 Dave Crocker Bill Flanigan Paul Hoffman Russ Housley John Pawling Jim Schaad
编者通讯地址： Blake Ramsdell Worldtalk 17720 NE 65th St Ste 201 Redmond, WA 98052 Phone: +1 425 376 0225 EMail: blaker@deming.com Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved.
本文档极其译文可以拷贝供他人使用，假如上述版权信息和章节包括在这些 拷贝和派生作品中，评论性或解说性或帮助执行性的派生作品不受任何限制的、 全文或部分的构思、拷贝发行和分发。但是，本文档本身不得以任何形式修改， 诸如删除版权信息、参考书目等。 除了为了制定Internet标准的情况下，必须遵守在Internet标准过程的版权程 序，或者要求翻译成非英语语言，互连网组织不得对本文档作任何修改。 上述申明具有永久性，互连网协会或其后继者或所属部门不得废除。 本文档极其所包含的信息是基于"AS IS"提供的，INTERNET协会和 INTERNET应用任务组否认所有的明确或隐含的警告，（其中）包括但不限制于 任何本文包含的信息的使用不侵犯任何版权或隐含的商业和为了特殊目的警告。 特别感谢 目前为RFC编辑部门提供资金的互连网协会。 RFC2633―S/MIME Version 3 Message Specification S/多用途网际邮件扩充协议(MIME)版本3信息说明书
1 RFC文档中文翻译计划
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8