GB Z 19717-2005 基于多用途互联网邮件扩展(MIME)的安全报文交换.pdf

1、ICS 35. 100.70 L 79 道自中华人民共和国国家标准化指导性技术文件GB/Z 19717-2005 基于多用途互联网邮件扩展(MIME)的安全报文交换2005-04-19发布Secure message interchange based on Multipurpose Internet Mail Extensions 2005-10-01实施中华人民共和国国家质量监督检验检疫总局也舍中国国家标准化管理委员会&叩GB/Z 19717-2005 目次前言.,. III 引言.凹1 范围2 规范性引用文件3 术语、定义和缩略语3. 1 术语和定义3.2 缩略语.24 密码报文语法(C

2、MS). 4. 1 概述.24.2 密码报文语法基本结构25 安全多用途互联网邮件扩展(S/MIME)25. 1 概述25.2 支持S/MIME的CMS选项35. 3 创建S/MIME报文.4 5.4 证书处理66 S/MIME的增强安全服务6.1 概述.6.2 三重隐蔽包装86.3 S/MIME增强安全服务和三重隐蔽包装附录A(资料性附录)用ASN.1描述的语法定义 12 参考文献. . . . . . . . ., . . ., . . ., . . ., . . . . . . .,. . 17 I GB/Z 19717一2005前言本指导性技术文件主要参照Internet工程任务组提出

3、的RFC2630密码报文语法、RFC2633 S/ MIME报文规范第3版和RFC2634增强的S/MIME安全服务制定的。本指导性技术文件的附录A是资料性附录。本指导性技术文件由中华人民共和国信息产业部提出。本指导性技术文件由全国信息安全技术标准化技术委员会归口。本指导性技术文件起草单位:中国电子技术标准化研究所。本指导性技术文件主要起草人:吴志刚、赵菁华、王颜尊。本指导性技术文件仅供参考。mu GB/Z 19717-2005 引Internet的电子邮件在传输中广泛使用简单邮件传输协议(即SMTP)，而SMTP却未提供加密服务。攻击者可在邮件传输中截获数据，并能将邮件中的文本格式、非文本格

4、式的二进制数据(如:.exe 文件)进行轻松地还原。Internet电子邮件面临着各种安全威胁(如信息泄露、冒充身份等)。安全电子邮件能够提供信息加密、身份鉴别、内容完整性、机密性及抗抵赖性等安全服务。目前，Internet工程任务组研究制定的安全多用途互联网邮件扩展CS/MIME)规范已成为安全电子邮件的重要支撑标准。S/MIME系列规范主要采用单向散列算法和公开密钥基础设施(PKD来实现数据加密和数字签名，从而保证邮件的安全性。本指导性技术文件给出了S/MIME系列规范的关键内容，便于对S/MIME系列规范的深入分析及相关产品的开发。本指导性技术文件凡涉及密码相关内容，按国家有关法规实施。

5、本指导性技术文件中所引用的MD5，SHA-l , DSS、RSA、DES、RC2，DH密码算法等均为举例说明。N 1 范围基于多用途互联网邮件扩展(MIME)的安全报文交换GB;Z 19717一2005全多用途互联网邮件扩展，S/向各种Internet报文应用提户代理使用该方法可以向互联网邮件扩展协议(MIME), 种安全服务。传统的邮件用所收报文中的加密服务。输协议，HTTP)。2 规范性引用文励根据本指导RFC 2045 RFC 2630 RFC 2633 RFC 2634 3.1 术语和定义下列术语和定义3. 1. 1 证书certificate 采用数字签名将实体的3. 1. 2 接收

6、代理receiving agent 输机制(如超文本传够交换安全报文。凡是注日期的术文件，然而，鼓不注日期的引用一种软件，它解释并处理S;MIMECMS对象及含有CMS对象的MIME主体部分。3.1.3 发送代理sending agent 一种软件，它创建S/MIMECMS对象和创建含有CMS对象的MIME主体部分。3. 1. 4 多用途互联网邮件扩展Multipurpose Internet Mail Extensions(MIME) MIME容许以下格式文挡作为报文:a) 非ASCII码的字符集的文本报文体;b) 非文本报文体的不同格式的扩展集;G/Z 19717-2005 c) 多部分的

7、报文体;d) 非ASCII码的字符集的文本头信息。3.1.5 S/MIME代理S/MIME agent 一种用户软件，它可以是接收代理或发送代理，或两者都是。3.2 缩略语下列缩略语适用于本指导性技术文件。CMS 密码报文语法ESS 增强安全服务MIME 多用途互联网邮件扩展S/MIME 安全多用途互联网邮件扩展4 密码报文语法(CMS)4. 1 概述密码报文语法(CMS)是以数字方式签名、处理、鉴别或加解密任意报文的语法，并用来描述保护数据的封装语法。它支持数字签名、报文鉴别代码和加密。这种语法允许多重封装，即一个封装包可以嵌套另一个包。同样，一方可以用数字方式给一些先前已经封装过的数据签名

8、。它还允许任意属性(如签名时间)同报文内容一起被签名，以及允许其它属性(如防范签名)与签名相关联。密码报文语法可以支持各种实现基于证书的密钥管理功能的体系结构。RFC2630对密码报文语法CCMS)有详细的规定。密码报文语法(CMS)普遍支持许多不同的内容类型。RFC2630规定了-种保护内容:Contentln fo 0 Contentlnfo可封装一个巳标识的内容类型，这个己标识的类型可以进一步进行封装。RFC2630 规定了六种内容类型:数据、签名数据、包装数据、摘要数据、加密数据和鉴别数据。4.2 密码报文语法基本结构密码报文语法(CMS)将内容类型标识符与内容相关联起来。这种句法包含

9、抽象语法记法1(ASN.1)类型的Contentlnfo宇段:ContentInfo : = SEQUENCE contentType ContentType, content 0. EXPLICIT ANY DEFINED BY contentType ContentType : = OBECT IDENTIFIER Contentlnfo宇段有以下含义:contentType表示相关联内容的类型。它是一个对象标识符，是由定义内容类型的机构分配的唯一整数串。content是关联的内容。内容的类型可以由contentType唯一确定。5 安全多用途互联网邮件扩展情/MIME)5. 1 概述安全

10、多用途互联网邮件扩展CS/MIME)规定了向MIME数据增加加密签名和加密服务的方法。MIME规范规定了Internet报文内容类型的通用结构，并对新的内容类型应用提供扩充机制。RFC2633则定义了如何按照CMS创建经加密的MIME主体部分，以及用于传输加密MIME主体部分的application/ pkcs7 mime内容类型。RFC2633还讨论了如何使用MIME-SECURE所定义的multipart/signed的MIME类型来传输S/MIME签名报文，同时还定义了另一种用于传输S/MIME签名报文的application/ pkcs7 -signa ture的MIME类型。为了创建

11、町MIME报文，S/MIME代理必须遵守RFCGB/Z 19717-2005 2633及RFC2630中所列的其他规范。由于S/MIME系统可能涉及软件而不是传统的Internet邮件客户端，因此接收代理与发送代理的要求是不同的。任何传输MIME数据的系统都能采用S/MIME，例如发送加密报文的自动进程可能完全不能接收加密的报文。5.2 支持S/MIME的CMS选项在内容和算法支持方面，CMS考虑了各种各样的选项。为了使所有支持S/MIME版本3的实现方案间达到基本的互操作性，RFC2633提出了一些支持要求和建议。5.2. 1 摘要算法标识符发送代理和接收代理必须支持同一个算法。这里以SHA

12、-l为例。为了提供对采用MD5摘要的S/MIME版本2签名数据对象的向后兼容性，接收代理应支持MD505.2.2 签名算法标识符发送代理和接收代理必须支持同一个数字签名算法，这里以DSS为例。发送代理和接收代理应支持在DSS中定义的id-dsa，算法参数不必存在。接收代理应支持PKCS-l所定义的rsaEncryption，发送代理应支持rsaEncryption。采用用户私有密钥对出去的报文进行签名，并在密钥生成期间确定私有密钥的长度。注:S/MIME版本2客户只能够验证采用rsaEncryption算法的数字签名。5.2.3 密钥加密算法标识符发送代理和接收代理必须支持同一个密钥交换算法，

13、这里以Diffie-H ellman算法为例。接收代理应支持rsaEncryption。进入的加密报文包含着多个对称密钥，这些密钥可以通过用户的私有密钥来解密，在密钥生成期间确定私有密钥的长度。发送代理应支持rsaEncryption。注:S/MIME版本2的客户只能解密使用rsaEncryption算法的内容加密密钥。5.2.4 通用语法CMS规定了多种内容类型，其中S/MIME目前可用的只有数据、签名数据及包装的数据这三种内容类型。5.2.4.1 数据内容类型发送代理必须使用id-data内容类型标识符来指明那些已采用安全服务的报文内容。例如，当对MIME数据采用数字签名时，CMSsign

14、edData encapContentInfo eContentType必须包括id-data对象标识符，并且MIME内容必须被存放在SignedDatae配apContentlnfoeContent的八位位组串中(除非发送代理使用多部分/签字，此时eContent可以不存在)。另一个例子，当对MIME数据进行加密时，CMS EnvelopedData encryptedContentInfo ContentType必须包含id-data对象标识符，并且加密的MIME内容必须存放在envelopedDataencryptedContentInfo encryptedContent的八位位组串中

15、。5.2.4.2 签名数据内窑类型发送代理必须对应用数字签名的报文使用签名数据内容类型，或者在用于传输无签名信息的证书的退化情况下必须使用签名内容类型。5.2.4.3 包装数据内容类型该内容类型用来向报文提供隐私性保护。发送者必须能够获得应用该服务所涉及的每一报文接收者的公开密钥。5.2.5 属性签名者信息类型Signerlnfo类型允许同签名一起包含无签名属性和签名属性。接收代理必须能够处理在此列出的每个签名属性的零个或一个实例。发送代理应在每个S/MIME报文中生成下列每个签名属性中一个实例:a) signingTime; b) sMIMECapabilities; c) s岛11肌1EE

16、ncryptionKeyPreference。3 GB/Z 19717-2005 此外，接收代理应能处理signingCertificate属性内签名属性的零个或一个实例。发送代理应能在每个S/MIME报文中生成signingCertificate签名属性的一个实例。以后可能会对这些属性的附加属性和值进行定义。接收代理应能通过友好的方式来处理那些它不识别的属性或值。那些含有此处禾列出的签名属性的发送代理应能向用户显示这些属性，以便用户知道被签名数据的所有属性。5.2.6 Signerldentifier Signerlnfo类型S/MIME版本3要求使用Signerlnfo版本1，即对于Sig

17、nerIdentifier必须使用issuerAndSerial Number的选项。5.2.7 内容加密运算标识符发送代理和接收代理必须支持采用同一数字加密算法。这里以DESEDE3 CBC为例进行加密和5. 3 创建S/MIME报文S/MIME报文是MIME主被保护的数据总是规范的MS/MIME被所有子部分的整/1RFC 822的头。、给出了准备MIM电子规范中的规程描述第三步:对离开的MIME王，S/MIME报文的实、了甩种格式，并为签名。MIME规范重复了MIME了，自防邮件传输期间式的清晰签名尤当接收到一个S/MIME报文肉、吾处理对报ff雳耐带的安全县号，该结果就是MIME实体。该

18、MIME实体将传递给具备MIME处理自F阳也国户代理，由院里将该MIME实体进行解码和表示后提交给用户或接收应用程序。有关准备签名或包装用的MIME实体的详细要求见RFC26330 5. 3.2 application/pkcs7-mime类型application/ pkcs7-mime类型被用来携带几种类型envelopedData和signedData的CMS对象。本条描述了application/pkcs7-mime类型的一般特性:如果eContentType是id-data，携带的CMS对象通常包含了按5.3.1所描述方式准备的MIME实体;当eContentType包括了不同的值时

19、，可以携带其它内容。由于CMS对象是二进制数据，大多数情况下64基的传送编码是适合的，尤其是采用SMTP传输方式。所用的传送编码依赖于被发送对象的传输方式，它不是MIME类型的特征。4 GB/Z 19717-2005 注意:本讨论涉及的CMS对象或外部MIME实体的传送编码，完全不同于由CMS对象保护的MIME实体的传送编码，且与其无关。因为application/ pkcs7 -mime对象有几种类型，所以发送代理应该尽可能地帮助接收代理在无需对对象的ASN.l进行解码的条件下就能了解对象的内容。所有的application/pkcs7-mime对象的MIME头应该包括smime-type可

20、选参数。5.3.3 创建Enveloped-only报文本条描述了对MIME实体只包装不签名的格式。值得注意的是，发送只包装不签名的报文不能提供数据完整性，这可能是通过经处理的报文将依然有效而可能改变了其意义的方式来替换密文。第一步:按照5.3.1准备将要包装的MIME实体。第二步:将MIME实体和其他所需的数第二步:将MIME第二步:将CMS采用带有SignedData报文的文件扩展是.p7m。5. 3.4.3 采用multipart/本格式是清晰签名格式。不用了multipart/signedMIME类型。Mu唱.t，6;ignedMI MIME实体;第二部分包括分离签名的CMSSig e

21、Content宇段。5.3. 5 签名和加密为了完成签名和加密，可以嵌套任何signed-only格式和encrypted-only格式。由于上述的格式全部是MIME实体，并且这些格式都能保护MIME实体，所以允许这种嵌套方式。S/MIME实现方案必须能够在接收方计算机合理有限的资源内接收和处理任意嵌套的S/MIME。或者首先对报文进行签名，或者首先对报文进行包装，由实施者和用户来决定选择何种方式。当首先进行签名时，签名人就通过包装被安全地隐藏起来了。当首先进行包装，签名人是暴露的，但无需去除包装就可能验证签名。edData类型的CMS对象。除了为每个接起方加密内容加密密钥的副本并收方加密co

22、ntent-encrypt.l 将该副本包含于env结edData中第三步:将CMS对象插enveloped-only报文的5. 3.4 创建只有签名的对于定义的S/MImultipart/ signed。5. 3.4. 1 选择当选择了特定带有能验证该签名重要性，因此不存不论接收者报文。无论接收到。在该上下文MIME结构。接但是，如果接收方5. 3. 4. 2 采用带这种签名格式格式签名的文还能被观察文，包含其他signed-data ，该类型使的它名。签文所报含该包察分观部娘一相第收分接部两，有5 GB/Z 19717一2005无论选择首先签名还是首先加密都存在安全分歧。对于先加密后签名报

23、文的接收方能够确认加密块没被改变，但不能确定签名者和未加密报文内容之间的关系。对于先签名后加密报文的接收方能够假设签名的报文本身未被改变，但是某些细致的攻击者可能己更改了加密报文的未经鉴别的部分。5.3.6 创建Certificates-only报文Certifica tes-only报文或certificates-onlyMIME实体用来传输证书(诸如对注册请求的响应)，这种格式也能够用来传输证书撤销列表。第一步:要使生成signedData类CMS对象的CMS生成进程能够使用证书，signedDataencapCon tentlnfo eContent宇段必须不存在，并且signerlnf

24、os字段必须为空。第二步:将CMSsignedData对象装入application/pkcs7-mimeMIME实体中。certs-only报文的smime-type参数是certs-only。该类型报文的文件扩展是.p7c。5.3.7 注册请求对报文进行签名的发送代理必须拥有签名证书，以便接收代理能够验证签名。5.3.8 标识S/MIME报文因为S/MIME考虑到在非MIME环境中的互操作性，采用了几种不同的机制来携带类型信息，它成为标识S/MIME报文的一点点困难。表1列出了判断报文是否是S/MIME报文的准则。如果某报文符合下列要求，则它可认为是S/MIME报文。表1中的文件后缀取自内

25、容类型头中的名称参数或内容安排头中文件名参数，给出文件后缀的这些参数未作为参数段的部分来列出。表1S/MIME报文判断准则MIME类型:application/pkcs7-mime 参数:any 文件后缀:any MIME类型:multipart/ signed 参数:protocol = application/ pkcs7-signature 文件后缀:any MIME类型:application/octet-stream 参数:any 文件后缀:p7m , p7s , p7c 5.4 证书处理接收代理必须提供某些证书检索机制，以便获得访问数字信封接收方证书。本文件不涉及S/MIME代理如

26、何处理证书，而只是描述在证书确认后或拒收后该代理执行什么。对于最初的S/MIME推广应用，用户代理最低的要求是能够为期望的接收方自动生成报文，该接收方请求在签名的返回报文中的接收方证书。接收代理和发送代理也应提供一种允许用户为通信者存储和保护证书的机制，通过这种机制可以保证以后可以检索这些证书。5.4. 1 密钥对的生成如果S/MIME代理需要生成一个密钥对，那么S/MIME代理或某些相关的管理性实用程序或功能必须能以用户的名义生成分开的DH和DSA公开密钥/私有密钥对。每一密钥对必须根据非确定性随机输入RANDOM的良好来源来生成，并且私有密钥必须以安全方式加以保护。如果S/MIME代理需要

27、生成一个密钥对，那么S/MIME代理或相关的管理性实用程序或功能应生成RSA密钥对。6 S/MIME的增强安全服务6. 1 概述S/MIME可提供下列四种可选的增强安全服务:a) 签名收据;6 GB/Z 19717-2005 b) 安全标签;c) 安全邮件发送列表及管理;d) 签名证书属性。G. 1. 1 签名收据报文始发者可以请求来自报文接收者的签名收据。通过把receiptRequest属性增加到请求收据的SignerInfo对象的SignedAttri bu tes宇段中来指出该请求。当请求这样做时，接收用户代理软件应自动地创建签名的证书，并按照邮件发送列表扩充选项，本地安全策略和配置选

28、项返回该收据。返回签名收据给始发者提供了报文交付证明，并且使得始发者可向第三方表明接收者曾验证过初始报文的签名。通过签名已把该收据与初始报文捆绑起来;因此，仅当要签名报文时，才可以请求该服务。收据发送者也可以有选择地加密某一收据，以便在收据发送者和收据接收者之间提供机密性。收据请求可以指出这些收据被发送给许多地点，不仅仅发送给该发送者(在事实上，收据请求可能指出这些收据不宜都发给该发送者)。为了验证收据，收据的接收者必须是初始报文的始发者或接收者。因此，该发送者应不请求将收据发送给没有准确的报文副本的任何人。由于收据涉及双方的交互，收据这一术语有时可能存在混淆。因此，在本章中，发送者就是发送包

29、含请求收据的初始报文的代理。接收者就是收到报文和生成收据的一方。6.1.2 安全标签安全标签是通过S/MIME封装来保护的有关敏感内容的安全信息的集合。授权是向用户授予访问某个对象的权利和/或特权的行为。访问控制是实施这些权限的手段。安全标签中的敏感信息可以与用户的权限相比较，以确定用户是否被允许访问通过S/MIME封装所保护的内容。安全标签可以用于其他用途，诸如路由选择信息的来源。这些标签通常描述了分等级的若干级别(秘密的，机密的，受限制的等等)或者这些标签是基于角色的，描述哪种人可以看到该信息(患者的保健小组，医疗账单代理，不受限制的等等)。6. 1.3 安全邮件发送到表及管理发送代理必须

30、为加密报文的每个接收者创建特定于接收者的数据结构。这个过程可能损害发送给大量接收者的报文性能。因此，通常要求邮件列表代理(MLA)对于每个接收者可以采用单个报文或执行特定于接收者的加密。对报文始发者来说，MLA似乎是常规的报文接收者，但是，MLA担当邮件列表(ML)的报文扩充点。报文发送者将报文送给MLA，然后，将报文再分发给ML的成员。这个过程卸下了各个用户代理按每个接收者的处理工作量，并且便于更有效管理大量MLoML是受MLA服务的真实报文接收者，该MLA为邮件发送列表提供了密码服务和扩充服务。除了对报文进行密码处理外，安全邮件发送列表还必须防止邮件循环。邮件循环是指，其中某一个邮件发送列

31、表是第二个邮件发送列表的成员，而第二个邮件发送列表又是第一个邮件发送列表的成员。一个报文将按向各列表的所有其他成分发邮件的快速级联连续方式从某一个列表到达另一个列表。为了防止邮件循环，MLA使用了三重隐蔽包装报文的外部签名的mlExpansionHistory属性。mlExpansionHistory属性在本质上是已经处理该报文的所有MLA的列表。如果MLA看到了在该列表中的它自己的唯一实体标识符，那么它就知道已经形成了一次循环，并且它不会再向该列发送报文。6. 1. 4 签名证书属性令人们担心的事是，要求CMSSignedData对象的签名者与SignedData对象的验证过程被捆绑起来的证

32、书不是以密码方式与该签名自身捆绑起来。本条也提出了对一组可能攻击的描述，这些攻击涉及被替换的某一证书用来验证所要求的证书的签名。针对可能的签名验证过程至少可以发起三种不同的攻击，其手法是替换签名验证过程中所使用的一个证书或多个证书。a) 第一种攻击涉及用某一证书替换另一证书。在这种攻击中，SignedInfo中的证书签发者和序列号被修改，以便提供新的证书。在签名验证过程期间使用这个新的证书。这种攻击的第17 GB/Z 19717一.2005个版本是一种简单的拒绝服务攻击，其中，无效证书替换了有效证书。当证书中的公开密钥不再与签名该报文所使用的私有密钥相匹配时，这就使该报文成为不可验证的。其第二

33、个版本是用某个有效证书替换初始有效证书，其中，两个证书中的两个公开密钥相匹配。这样做允许根据与该报文的始发者潜在不同的证书限制来确认该签名。b) 第二种攻击涉及重新颁发签名证书(或可能是其证书之一)的认证机构CA。随着认证机构重新颁发它们自己的根证书，或随着认证机构在重新颁发它们的根证书的同时改变证书的策略，这种攻击可能开始变为更频繁。在验证签名的过程中使用交叉证书(带有可能的不同限制)时就会出现这个问题。c) 第三种攻击涉及建立一个CA的虚假实体，而这个虚假实体企图重复现有CA的结构。特别=的公开密钥来颁发新证书，但该虚假实体为了防止或指出对应这些攻证书的替换可以用签名属性的攻击转b) 对重

34、新签认证机构是不可信防止基于大的变化证书。当怕击方使用时，问题4出啡，同时该证书并不出现明确的证书策略也可以用作签名把的明确的证书策略，则该策略需要以密码方式J阳节策略声明集合作为签名证书属性的一部分加以列出。6.2 三重隐蔽包装6.2. 1 基本概念每项S/MIME增强安全服务的一些特性都采用三重隐蔽包装的概念对报文进行包装。即一个被三重隐蔽包装的报文要先被签名，然后被加密，最后又被签名。这里，对内部和外部签名的人可能是不同的实体或是同一个实体。6.2. 2 三重隐蔽包装的目的GB/Z 19717-2005 并非所有的报文都需要三重隐蔽包装。当必须对报文签名、然后再加密，最后将签了名的报文属

35、性装配到被加密的主体上时，需要使用三重隐蔽包装。发出报文的人或中间代理可以添加或删除其外部属性，且外部属性也可以被中间代理或最终的收件人签名。内部签名可用于保证内容的完整性、抗抵赖、对信源的鉴别以及将报文的属性(如安全标签)捆绑到报文的初始内容中。这些属性从发件人传到收件人，无论中间实体(如处理报文的邮件清单代理)有多少个。这种签名属性可以用来控制对内部主体的民问，并且在内部签名中还带有发方索要签名收据的请求。被加密的主体具有机密性，包括在内部签名中所携带的这些属性的机密性。外部签名可用于鉴别被逐级处理的信息并可保证其完整性。每一级是一个中间实体，如l邮件列表，这些属性常用于访问控制和路囱选择

36、。6. 2.3 三重隐蔽包装的步骤以下是创建一个三重隐蔽包a) 先从报文主体开始，b) 用适当的MIME(内容类型:文头中。plication/ pkcs7-SignedData的) ， 文中。所得出内容类型mul-7-s.ignature、可opedData encry -mlme对象。Enveltao EnvelopedData结e) f) 添加适当的MIME头:Conten t-t ransfer-encoding g) 用与上述第3步相同的逻辑，将第签名。h ) 用与上述第4步相同的逻辑，将适当的MIME结构添加到第7步的被签名的报文中。所得到的结果称为外部签名，且是三重隐蔽包装的报文

37、。6.2. 4 三重隐蔽包装报文的格式一个被三重隐蔽包装的报文具有多层的封装。其结构会因报文中被签名的部分的格式的不同而不同。由于MIME封装数据的方式，这些封装层不按次序出现，使得层的概念变得模糊起来。由于已知接受方能够处理S/MIME报文(因为他们解密了中间伪装器)，因此无需在内部签名中使GB;Z 19717-2005 用mul ti part/ signed格式。发送代理了解选择在外层使用multipart/signed格式，这样，非S/MIME代理可以知道下-个内层被加密;然而，这没有什么价值，这是因为收方可以发现报文的其余部分是无法读的。由于许多发送代理通常使用mul ti part

38、/ signed结构，因此所有接收代理必须能够解释multipart/ signed或application/pkcs7 -mime签名结构。采用这两种签名用的mul ti part/ signed的三重隐蔽包装报文的格式是t第八步Content-type: multipart/ signed; 第八步protocol= application/pkcs7-signature; 第八步boundary=outerboundary 第八步第八步一-outerboundaryC第六步Content-type: application/pkcs7-mime; 第六步smime-type= envel

39、oped-data 第六步第四步Content-type: multipart/signed; 第四步protocol= application/pkcs7-signature; 第四步boundary = innerboundary 第四步第四步一-innerboundary第二步Content-type: text/plain 第二步f第一步Original content 第四步第四步一一innerboundary第四步Content-type: a叩pp附lica剖tion/p内kcs7-唁-SI剑ignatu盯1江r第四步第三步inner SignedData block (eCon

40、tent is missing) 第四步f第四步一一一innerboundary一一一第八步第八步一一outerboundary第八步Content-type: application/ pkcs7-signature 第八步第七步outer SignedData block (eContent is missing) 第八步第八步一一outerboundary一这里z%=这些行表示计算内部签名。1=这些行表示在第5步被加密。加密的结果是不透明的，是EnvelopedData块的一部分。) =这些行表示计算外部签名。采用这两种签名用的application/pkcs7 -mime的三重隐蔽包装

41、报文的格式是:第八步Content-type: applica tion/ pkcs7 -mime; 第八步smme- type= signed-data 第八步10 、，、，F、，、，、，、，、，、，J、a/、，、，/、，/、，、，、，F% 第七步outer SignedData block (eContent is present) 第六步Content-type: application/ pkcs7 -mime; 第六步smime-type= e盯eloped-data;第六步第四步Content-type: application/ pkcs7-mime; 第四步smime-type

42、= signed-data 第四步第三步inner SignedData block (eContent is present) 第二步Content-type: text/ plain 第二步第一步Original content 这里:。) 0 ) 0 ) 0 1 ) 0 1 ) 0 1 ) 0 1 1 ) 0 1 1 ) 0 1 1 ) 0 1 1 ) 0 GB/Z 19717-2005 1=这些行是内部SignedData块，不仅是无法理解的，而且包含第2步中用ASN.l编码的结果以及控制信息。1=这些行表示在第5步被加密。被加密的结果是无法理解的，是EnvelopedData块的一部

43、分。) =这些行表示计算外部签名。=这些行是外部SignedData块，不仅无法理解，而且还包含第6步中用ASN.l编码的结果和控制信息。6.3 S/MIME增强安全服务和三重隐蔽包装6.3. 1 签名收据与三重隐蔽包装在任何SignedData对象中，可能要求使用签名收据。如三重隐蔽包装的报文要求收件人回送收到该报文的签名收据给发件人时，其收据请求必须包含在内部签名中，而不能在外部签名中。因为，当邮件发送列表处理三重隐蔽包装报文时，安全邮件发送列表代理可能会改变该报文的外部签名中的收据策略。6.3.2 安全标签与三重隐蔽包装任何SignedData对象的签名属性可能包含安全标签。在内部签名、

44、或在外部签名、或在这两种签名中都可能含有安全标签属性。内部安全标签用来确定对与初始的明文内容有关的访问控制。内部签名提供鉴别，并以密码的方式保护位于内部主体的最初签名者的安全标签的完整性。这种策略便于转发报文，因为最初签名者的安全标签被包含在可以被转发给第三方的SignedData块中，使第三方可以验证包含内部安全标签的内部签名。机密性安全服务也可用于内部安全标签，方法是加密EnvelopedData块中的整个内部SignedData块。外部SignedData块的签名属性也可包含安全标签，且该块可包含敏感的加密报文。外部安全标签用来确定与加密报文有关的访问控制和路由选择。注意:安全标签属性只

45、可以在signedAttributes块中使用。在EnvelopedData或未签名属性中不得使用eSSSecurityLabel属性。6.3.3 安全邮件发送列表与三重隐蔽包装安全邮件列表报文处理取决于发送给邮件列表代理的报文中所呈现的S/MIME各层的结构。如果存在内部签名，邮件列表代理决不会改变已散列(hashed)的数据，来形成内部签名。如果存在外部签名，邮件列表代理将修改己散列的数据，来形成这个外部签名。在这些情况下，邮件列表代理添加或更新mlExpansionHistory属性，并记录下邮件列表代理的处理活动，最终添加或替换待分发报文上的外部签名。11 GB/Z 19717-200

46、5 附录A(资料性附录)用ASN.1描述的语法定义ExtendedSecuri tyServices iso(l) member- body( 2) us(840) rsadsi ( 11 3549) pkcs(l) pkcs-9(9) smime( 16) modules(O) ess(2) BEGIN IMPORTS tifier 一-PKIX证书一一收据请求语法(ReceiptRcq uest Synt ReceiptRequest : = SEQUENCE signedContentldentifier Content Iden tifier , receiptsFrom Receip

47、tsFrom , receiptsTo SEQUENCE SIZE (1. . ub- receiptsTo) OF GeneralNames ub-receiptsTo INTEGER : = 16 id-aa-receiptRequest OBJECT IDENTIFIER : = iso(1) member-body(2) us(840) rsadsi(1 13549) pkcs (1) pkcs-9(9) smime(1 6) id-aa (2) l 12 r , u bj ectKey Iden-(5) mechanisms General-Contentldentifier : = OCTET STRI NG id-aa-contentldentifier OBJECT IDENTIFIER : = iso(l) member-body(2) us(840) rsadsi(13549) pkcs