1、ICS 35.100.70一一L”荡摹中华人民共和国国家标准化指导性技术文件GB/Z 19717-2005基于多用途互联网邮件扩展（MIME）的安全报文交换Secure message interchange based onMultipurpose Internet Mail Extensions2005-04-19发布2005-10-01实施率督黔M瓣譬 O臀臀M+ w M 4 k R f M发布 cs/z 19717-2005前言本指导性技术文件主要参照Internet工程任务组提出的RFC 2630密码报文语法、RFC 2633 S/MIME报文规范第3版和RFC 2634增强的S/M
2、IME安全服务制定的。本指导性技术文件的附录A是资料性附录。本指导性技术文件由中华人民共和国信息产业部提出。本指导性技术文件由全国信息安全技术标准化技术委员会归口。本指导性技术文件起草单位：中国电子技术标准化研究所。本指导性技术文件主要起草人：吴志刚、赵著华、王颜尊。本指导性技术文件仅供参考。GB/Z 19717-2005引言Internet的电子邮件在传输中广泛使用简单邮件传输协议（即SMTP)，而SMTP却未提供加密服务。攻击者可在邮件传输中截获数据，并能将邮件中的文本格式、非文本格式的二进制数据（如：. exe文件）进行轻松地还原。Internet电子邮件面临着各种安全威胁（如信息泄露、
3、冒充身份等）。安全电子邮件能够提供信息加密、身份鉴别、内容完整性、机密性及抗抵赖性等安全服务。目前，Internet工程任务组研究制定的安全多用途互联网邮件扩展（S/MIME）规范已成为安全电子邮件的重要支撑标准。S/MIME系列规范主要采用单向散列算法和公开密钥基础设施（PKI)来实现数据加密和数字签名，从而保证邮件的安全性。本指导性技术文件给出了S/MIME系列规范的关键内容，便于对S/MIME系列规范的深人分析及相关产品的开发。本指导性技术文件凡涉及密码相关内容，按国家有关法规实施。本指导性技术文件中所引用的MD5, SHA-1, DSS, RSA, DES, RC2, DH密码算法等均
4、为举例说明。 GB/Z 19717-2005基于多用途互联网邮件扩展（MIME）的安全报文交换1范围本指导性技术文件阐述了安全发送和接收多用途互联网邮件扩展（MIME）数据的基本方法（即安全多用途互联网邮件扩展，S/MIME)。该方法基于广泛使用的多用途互联网邮件扩展协议（MIME),向各种Internet报文应用提供鉴别、报文的完整性、抗抵赖性、机密性等多种安全服务。传统的邮件用户代理使用该方法可以向所发送的报文增加各种加密服务，并能够有效处理所收报文中的加密服务。本指导性技术文件还描述了S/MIME的增强安全服务。本指导性技术文件不限于电子邮件，它还可以用于任何传输MIME数据的传输机制（
5、如超文本传输协议，HTTP)。该规范利用了MIME面向对象的特点，使得在各种传输系统中能够交换安全报文。2规范性引用文件下列文件中的条款通过本指导性技术文件的引用而成为本指导性技术文件的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本指导性技术文件，然而，鼓励根据本指导性技术文件达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本指导性技术文件。RFC 2045多用途Internet邮件扩展（MIME）第1部分Internet报文体的格式RFC 2630密码报文语法RFC 2633 S/MIME报文规范第3版RFC 2
6、634增强的S/MIME安全服务3术语、定义和缩略语3.1术语和定义下列术语和定义适用于本指导性技术文件。3.11证书certificate采用数字签名将实体的可辨别名与公开密钥捆绑起来的类型。3.1.2接收代理receiving agent一种软件，它解释并处理S/MIME CMS对象及含有CMS对象的MIME主体部分。3.1.3发送代理sending agent一种软件，它创建S/MIME CMS对象和创建含有CMS对象的MIME主体部分。3.1.4多用途互联网邮件扩展Multipurpose Internet Mail Extensions(MIME)MIME容许以下格式文档作为报文：a
7、)非ASCII码的字符集的文本报文体；b)非文本报文体的不同格式的扩展集；GB/Z 19717-2005c)多部分的报文体；d)非ASCII码的字符集的文本头信息。3.1.5S/MIME代理S/MIME agent一种用户软件，它可以是接收代理或发送代理，或两者都是。3.2缩略语下列缩略语适用于本指导性技术文件。CMS密码报文语法ESS增强安全服务MIME多用途互联网邮件扩展S/MIME安全多用途互联网邮件扩展4密码报文语法（CMS )4.1概述密码报文语法（CMS)是以数字方式签名、处理、鉴别或加解密任意报文的语法，并用来描述保护数据的封装语法。它支持数字签名、报文鉴别代码和加密。这种语法允
8、许多重封装，即一个封装包可以嵌套另一个包。同样，一方可以用数字方式给一些先前已经封装过的数据签名。它还允许任意属性（如签名时间）同报文内容一起被签名，以及允许其它属性（如防范签名）与签名相关联。密码报文语法可以支持各种实现基于证书的密钥管理功能的体系结构。RFC 2630对密码报文语法（CMS)有详细的规定。密码报文语法（CMS)普遍支持许多不同的内容类型。RFC 2630规定了一种保护内容：ContentIn-foe ContentInf。可封装一个已标识的内容类型，这个已标识的类型可以进一步进行封装。RFC 2630规定了六种内容类型：数据、签名数据、包装数据、摘要数据、加密数据和鉴别数据
9、。4.2密码报文语法基本结构密码报文语法（CMS)将内容类型标识符与内容相关联起来。这种句法包含抽象语法记法1(ASN.1）类型的ContentInfo字段：ContentInfo：SEQUENCEcontentType ContentType,content 0. EXPLICIT ANY DEFINED BY contentTypeContentType：OBJECT IDENTIFIERContentInfo字段有以下含义：contentType表示相关联内容的类型。它是一个对象标识符，是由定义内容类型的机构分配的唯一整数串。content是关联的内容。内容的类型可以由contentTy
10、pe唯一确定。5安全多用途互联网邮件扩展（(S/MIME )51概述安全多用途互联网邮件扩展（S/MIME）规定了向MIME数据增加加密签名和加密服务的方法。MIME规范规定了Internet报文内容类型的通用结构，并对新的内容类型应用提供扩充机制。RFC2633则定义了如何按照CMS创建经加密的MIME主体部分，以及用于传输加密MIME主体部分的application/pkcs7mime内容类型。RFC 2633还讨论了如何使用MIME-SECURE所定义的multipart/signed的MIME类型来传输S/MIME签名报文，同时还定义了另一种用于传输S/MIME签名报文的applica
11、tion/ pkcs7-signature的MIME类型。为了创建S/MIME报文，S/MIME代理必须遵守RFC GB/Z 19717-20052633及RFC 263。中所列的其他规范。由于S/MIME系统可能涉及软件而不是传统的Internet邮件客户端，因此接收代理与发送代理的要求是不同的。任何传输MIME数据的系统都能采用S/MIME,例如发送加密报文的自动进程可能完全不能接收加密的报文。5.2支持S/MIME的CMS选项在内容和算法支持方面，CMS考虑了各种各样的选项。为了使所有支持S/MIME版本3的实现方案间达到基本的互操作性，RFC 2633提出了一些支持要求和建议。5.2.
12、1摘要算法标识符发送代理和接收代理必须支持同一个算法。这里以SHA-1为例。为了提供对采用MD5摘要的S/MIME版本2签名数据对象的向后兼容性，接收代理应支持MD5 05.2.2签名算法标识符发送代理和接收代理必须支持同一个数字签名算法，这里以DSS为例。发送代理和接收代理应支持在DSS中定义的id-dsa，算法参数不必存在。接收代理应支持PKCS-1所定义的rsaEncryption，发送代理应支持rsaEncryption。采用用户私有密钥对出去的报文进行签名，并在密钥生成期间确定私有密钥的长度。注：S/MIME版本2客户只能够验证采用rsaEncryption算法的数字签名。5.2.3
13、密钥加密算法标识符发送代理和接收代理必须支持同一个密钥交换算法，这里以Diffie-Hellman算法为例。接收代理应支持rsaEncryption。进人的加密报文包含着多个对称密钥，这些密钥可以通过用户的私有密钥来解密，在密钥生成期间确定私有密钥的长度。发送代理应支持rsaEncryption,注：S/MIME版本2的客户只能解密使用rsaEncryption算法的内容加密密钥。5.2.4通用语法CMS规定了多种内容类型，其中S/MIME目前可用的只有数据、签名数据及包装的数据这三种内容类型。5.2.4.1数据内容类型发送代理必须使用id-data内容类型标识符来指明那些已采用安全服务的报文
14、内容。例如，当对MIME数据采用数字签名时，CMS signedData encapContentInfo eContentType必须包括id-data对象标识符，并且MIME内容必须被存放在SignedData encapContentInfo eContent的八位位组串中（除非发送代理使用多部分签字，此时。Content可以不存在）。另一个例子，当对MIME数据进行加密时，CMS EnvelopedData encryptedContentInfo ContentType必须包含id-data对象标识符，并且加密的MIME内容必须存放在envelopedData encryptedCo
15、ntentInfo encrypt edContent的八位位组串中。5.2.4.2签名数据内容类型发送代理必须对应用数字签名的报文使用签名数据内容类型，或者在用于传输无签名信息的证书的退化情况下必须使用签名内容类型。5.2.4.3包装数据内容类型该内容类型用来向报文提供隐私性保护。发送者必须能够获得应用该服务所涉及的每一报文接收者的公开密钥。5.2.5属性签名者信息类型SignerInfo类型允许同签名一起包含无签名属性和签名属性。接收代理必须能够处理在此列出的每个签名属性的零个或一个实例。发送代理应在每个S/MIME报文中生成下列每个签名属性中一个实例：a) signmgTime；b) s
16、MIMECapabilities;c) sMIMEEncryptionKeyPreference。GB/Z 19717-2005此外，接收代理应能处理signingCertificate属性内签名属性的零个或一个实例。发送代理应能在每个S/MIME报文中生成signingCertificate签名属性的一个实例。以后可能会对这些属性的附加属性和值进行定义。接收代理应能通过友好的方式来处理那些它不识别的属性或值。那些含有此处未列出的签名属性的发送代理应能向用户显示这些属性，以便用户知道被签名数据的所有属性。5.2. 6 SignerIdentifier SignerInfo类型S/MIME版本3
17、要求使用SignerInfo版本1，即对于SignerIdentifier必须使用issuerAndSerial-Number的选项。5.2.7内容加密运算标识符发送代理和接收代理必须支持采用同一数字加密算法。这里以DES EDE3 CBC为例进行加密和解密，以下简称“tripleDES。接收代理应支持以RC2为例的兼容算法进行加密和解密。5.3创建S/MIME报文S/MIME报文是MIME主体和CMS对象的组合，可以使用几种MIME类型和几种CMS对象。被保护的数据总是规范的MIME实体，并将MIME实体和其他数据（如证书和算法标识符）交给产生CMS对象的CMS处理设施，CMS对象最终被包装
18、在MIME中。S/MIME的增强安全服务规范（见RFC 2634）提供了如何嵌套的实例及构造安全的S/MIME报文的方法。RFC 2634提供了一个如何采用multipart/signed和签名的application/ pkcs7-mime构成一个三重隐蔽包装的S/MIME报文的实例。S/MIME为enveloped-only数据提供了一种格式，为signed-only数据提供了几种格式，并为签名及包装的数据提供了几种格式。5.3.1准备签名或包装用的MIME实体S/MIME被用于安全MIME实体。MIME实体可能是subpart、或是报文的subparts、或是带有其所有子部分的整个报文。
19、作为整个报文的MIME实体只能包括MIME头和MIME主体，而不包括RFC 822的头。注意，S/MIME还能用于Internet邮件以外的应用所使用的安全MIME实体。本指导性技术文件描述的安全的MIME实体可认为是“内部”MIME实体，即它可能是大的MIME报文中“最内部”的对象，在5.3.2,5.3.4和其他部分描述了将“外部”MIME实体处理为CMS对象。MIME规范给出了准备MIME实体的规程。在签名时可使用带有某些附加限制的相同规程。在此重复了MIME规范中的规程描述，本条还描述了一些附加的要求。对于创建签名的、包装的或签名且包装的MIME实体应采用单个的规程。为了预防邮件传输期间
20、可能出现的已知问题，推荐采用某些附加步骤，这些步骤对于采用multipart/signed格式的清晰签名尤为重要。建议对包装的报文或签名且封装的报文实施这些附加步骤，以保证该报文能够无修改地转发到任何环境。第一步：依据本地的约定准备MIME实体。第二步：将MIME实体的叶子部分转换为规范的形式。第三步：对离开的MIME实体应用适当的传送编码。当接收到一个S/MIME报文时，要处理对报文所附带的安全服务，该结果就是MIME实体。该MIME实体将传递给具备MIME处理能力的用户代理，由该代理将该MIME实体进行解码和表示后提交给用户或接收应用程序。有关准备签名或包装用的MIME实体的详细要求见RF
21、C 263305.3.2 application/pkcs7-mime类型application/ pkcs7-mime类型被用来携带几种类型envelopedData和signedData的CMS对象。本条描述了application/ pkcs7-mime类型的一般特性：如果eContentType是id-data,携带的CMS对象通常包含了按5.3.1所描述方式准备的MIME实体；当eContentType包括了不同的值时，可以携带其它内容。由于CMS对象是二进制数据，大多数情况下64基的传送编码是适合的，尤其是采用SMTP传输方式。所用的传送编码依赖于被发送对象的传输方式，它不是MIM
22、E类型的特征。 GB/Z 19717-2005注意：本讨论涉及的CMS对象或“外部”MIME实体的传送编码，完全不同于由CMS对象保护的MIME实体的传送编码，且与其无关。因为application/ pkcs7-mime对象有几种类型，所以发送代理应该尽可能地帮助接收代理在无需对对象的ASN. 1进行解码的条件下就能了解对象的内容。所有的application/ pkcs7-mime对象的MIME头应该包括“smime-type”可选参数。5.3.3创建Enveloped-only报文本条描述了对MIME实体只包装不签名的格式。值得注意的是，发送只包装不签名的报文不能提供数据完整性，这可能是
23、通过经处理的报文将依然有效而可能改变了其意义的方式来替换密文。第一步：按照5.3.1准备将要包装的MIME实体。第二步：将MIME实体和其他所需的数据处理为envelopedData类型的CMS对象。除了为每个接收方加密content-encryption密钥的副本外，还应该为发起方加密内容加密密钥的副本并将该副本包含于envelopedData中。第三步：将CMS对象插入到一个application/ pkcs7-mime MIME实体中。enveloped-only报文的smime-type参数为“envelopeddata，该类型报文的文件扩展是“. p7m o5.3.4创建只有签名的报
24、文对于定义的S/MIME签名报文存在两种格式，即带有SignedData的application/ pkcs7-mime和multipart/signed。发送代理应首选multipart/signed格式，但接收代理应都能处理这两种格式。5.3.4.1选择Signed-only报文格式当选择了特定的signed-only格式时，由于该格式取决于所有接收者的能力，同时该格式还取决于带有能验证该签名的S/MIME设施的接收者与不带有能观察该报文的S/MIME软件的接收者的相对重要性，因此不存在严格的规则。不论接收者是否拥有S/MIME软件，该接收者都能观察到查看采用multipart/signe
25、d格式签名的报文。无论接收者正使用本地MIME用户代理或它们拥有由网关所转换的报文，这些报文还能被观察到。在该上下文中，“观察到”表示处理报文的能力，在实质上就像该报文不是一个签名报文，包含其他MIME结构。接收方不能观察到采用signedData格式签名的报文，除非接收方拥有S/MIME设施。但是，如果接收方拥有S/MIME设施，通常能够验证这些报文是否在传输中没被更改。5.3.4.2采用带有SignedData的application/pkcs7-mime的签名这种签名格式使用application/ pkcs7-mime MIME类型。创建该格式的步骤如下：第一步：按照5.3.1条准备M
26、IME实体。第二步：将MIME实体和其他所需的数据处理为signedData类型的CMS对象。第三步：将CMS对象插入到一个application/ pkcs7-mime MIME实体中。采用带有SignedData的application/ pkcs7-mime报文的smime-type参数为“signed-data，该类型报文的文件扩展是“. p7mo5.3.4.3采用multipart/signed格式的签名本格式是清晰签名格式。不带有任何S/MIME或CMS处理设施的接收方能够观察该报文。它使用了multipart/signed MIME类型。Multipart/signed MIME
27、类型有两部分。第一部分包含所签名的MIME实体；第二部分包括“分离签名”的CMS SignedData对象，该对象中不存在encapContentInfoeContent字段。5.3.5签名和加密为了完成签名和加密，可以嵌套任何signed-only格式和encrypted-only格式。由于上述的格式全部是MIME实体，并且这些格式都能保护MIME实体，所以允许这种嵌套方式。S/MIME实现方案必须能够在接收方计算机合理有限的资源内接收和处理任意嵌套的S/MIME。或者首先对报文进行签名，或者首先对报文进行包装，由实施者和用户来决定选择何种方式。当首先进行签名时，签名人就通过包装被安全地隐藏
28、起来了。当首先进行包装，签名人是暴露的，但无需去除包装就可能验证签名。GB/Z 19717-2005无论选择首先签名还是首先加密都存在安全分歧。对于先加密后签名报文的接收方能够确认加密块没被改变，但不能确定签名者和未加密报文内容之间的关系。对于先签名后加密报文的接收方能够假设签名的报文本身未被改变，但是某些细致的攻击者可能已更改了加密报文的未经鉴别的部分。5.3.6创建Certificates-only报文Certificates-only报文或certificates-only MIME实体用来传输证书（诸如对注册请求的响应），这种格式也能够用来传输证书撤销列表。第一步：要使生成signed
29、Data类CMS对象的CMS生成进程能够使用证书，signedData encapCon-tentInfo eContent字段必须不存在，并且signerInfos字段必须为空。第二步：将CMS signedData对象装人application/pkcs7-mime MIME实体中。certs-only报文的smime-type参数是“certs-only。该类型报文的文件扩展是“. plc,5.3.7注册请求对报文进行签名的发送代理必须拥有签名证书，以便接收代理能够验证签名。5.3.8标识S/MIME报文因为S/MIME考虑到在非MIME环境中的互操作性，采用了几种不同的机制来携带类型信
30、息，它成为标识S/MIME报文的一点点困难。表1列出了判断报文是否是S/MIME报文的准则。如果某报文符合下列要求，则它可认为是S/MIME报文。表1中的文件后缀取自内容类型头中的“名称”参数或内容安排头中“文件名”参数，给出文件后缀的这些参数未作为参数段的部分来列出。表1 S/MIME报文判断准则MIME AN: application/IOr: any3C4A0: anyMIME AM: multipart/si;#It : protocol= applicat3C#fr,: anyMIME AN: application/4Oft: any3C4fail: p7m, p7s, plc一州
31、5.4证书处理接收代理必须提供某些证书检索机制，以便获得访问数字信封接收方证书。本文件不涉及S/MIME代理如何处理证书，而只是描述在证书确认后或拒收后该代理执行什么。对于最初的S/MIME推广应用，用户代理最低的要求是能够为期望的接收方自动生成报文，该接收方请求在签名的返回报文中的接收方证书。接收代理和发送代理也应提供一种允许用户为通信者“存储和保护”证书的机制，通过这种机制可以保证以后可以检索这些证书。5.4.1密钥对的生成如果S/MIME代理需要生成一个密钥对，那么S/MIME代理或某些相关的管理性实用程序或功能必须能以用户的名义生成分开的DH和DSA公开密钥私有密钥对。每一密钥对必须根
32、据非确定性随机输入RANDOM的良好来源来生成，并且私有密钥必须以安全方式加以保护。如果S/MIME代理需要生成一个密钥对，那么S/MIME代理或相关的管理性实用程序或功能应生成RSA密钥对。6 S/MIME的增强安全服务6.1概述S/MIME可提供下列四种可选的增强安全服务：a)签名收据； GB/Z 19717-2005b)安全标签；C安全邮件发送列表及管理；d)签名证书属性。6.1.1签名收据报文始发者可以请求来自报文接收者的签名收据。通过把receiptRequest属性增加到请求收据的SignerInfo对象的SignedAttributes字段中来指出该请求。当请求这样做时，接收用户
33、代理软件应自动地创建签名的证书，并按照邮件发送列表扩充选项，本地安全策略和配置选项返回该收据。返回签名收据给始发者提供了报文交付证明，并且使得始发者可向第三方表明接收者曾验证过初始报文的签名。通过签名已把该收据与初始报文捆绑起来；因此，仅当要签名报文时，才可以请求该服务。收据发送者也可以有选择地加密某一收据，以便在收据发送者和收据接收者之间提供机密性。收据请求可以指出这些收据被发送给许多地点，不仅仅发送给该发送者在事实上，收据请求可能指出这些收据不宜都发给该发送者）。为了验证收据，收据的接收者必须是初始报文的始发者或接收者。因此，该发送者应不请求将收据发送给没有准确的报文副本的任何人。由于收据
34、涉及双方的交互，收据这一术语有时可能存在混淆。因此，在本章中，“发送者”就是发送包含请求收据的初始报文的代理。“接收者”就是收到报文和生成收据的一方。6.1.2安全标签安全标签是通过S/MIME封装来保护的有关敏感内容的安全信息的集合。“授权”是向用户授予访问某个对象的权利和或特权的行为。“访问控制”是实施这些权限的手段。安全标签中的敏感信息可以与用户的权限相比较，以确定用户是否被允许访问通过S/MIME封装所保护的内容。安全标签可以用于其他用途，诸如路由选择信息的来源。这些标签通常描述了分等级的若干级别（“秘密的”，“机密的”，“受限制的”等等）或者这些标签是基于角色的，描述哪种人可以看到该
35、信息（“患者”的保健小组，医疗账单代理，“不受限制的”等等）。6. 1.3安全邮件发送列表及管理发送代理必须为加密报文的每个接收者创建特定于接收者的数据结构。这个过程可能损害发送给大量接收者的报文性能。因此，通常要求邮件列表代理（MLA）对于每个接收者可以采用单个报文或执行特定于接收者的加密。对报文始发者来说，MLA似乎是常规的报文接收者，但是，MLA担当邮件列表（ML)的报文扩充点。报文发送者将报文送给MLA，然后，将报文再分发给ML的成员。这个过程卸下了各个用户代理按每个接收者的处理工作量，并且便于更有效管理大量ML, ML是受MLA服务的真实报文接收者，该MLA为邮件发送列表提供了密码服
36、务和扩充服务。除了对报文进行密码处理外，安全邮件发送列表还必须防止邮件循环。邮件循环是指，其中某一个邮件发送列表是第二个邮件发送列表的成员，而第二个邮件发送列表又是第一个邮件发送列表的成员。一个报文将按向各列表的所有其他成分发邮件的快速级联连续方式从某一个列表到达另一个列表。为了防止邮件循环，MLA使用了三重隐蔽包装报文的外部签名的mlExpansionHistory属性。mlExpansionHistory属性在本质上是已经处理该报文的所有MLA的列表。如果MLA看到了在该列表中的它自己的唯一实体标识符，那么它就知道已经形成了一次循环，并且它不会再向该列发送报文。6.1.4签名证书属性令人们
37、担心的事是，要求CMS SignedData对象的签名者与SignedData对象的验证过程被捆绑起来的证书不是以密码方式与该签名自身捆绑起来。本条也提出了对一组可能攻击的描述，这些攻击涉及被替换的某一证书用来验证所要求的证书的签名。针对可能的签名验证过程至少可以发起三种不同的攻击，其手法是替换签名验证过程中所使用的一个证书或多个证书。a）第一种攻击涉及用某一证书替换另一证书。在这种攻击中，SignedInf。中的证书签发者和序列号被修改，以便提供新的证书。在签名验证过程期间使用这个新的证书。这种攻击的第1GB/Z 19717-2005个版本是一种简单的拒绝服务攻击，其中，无效证书替换了有效证
38、书。当证书中的公开密钥不再与签名该报文所使用的私有密钥相匹配时，这就使该报文成为不可验证的。其第二个版本是用某个有效证书替换初始有效证书，其中，两个证书中的两个公开密钥相匹配。这样做允许根据与该报文的始发者潜在不同的证书限制来确认该签名。b)第二种攻击涉及重新颁发签名证书（或可能是其证书之一）的认证机构CA。随着认证机构重新颁发它们自己的根证书，或随着认证机构在重新颁发它们的根证书的同时改变证书的策略，这种攻击可能开始变为更频繁。在验证签名的过程中使用交叉证书（带有可能的不同限制）时就会出现这个问题。c)第三种攻击涉及建立一个CA的虚假实体，而这个虚假实体企图重复现有CA的结构。特别是，该虚假
39、实体使用与该签名者使用的公开密钥相同的公开密钥来颁发新证书，但该虚假实体却使用其私有密钥对新证书进行签名。为了防止或指出对应这些攻击的一组方法，以便处理一些最简单的攻击：a)对替换攻击的响应：不能防止拒绝服务攻击。在运输中已经修改证书标识符之后，就不可能验证该签名。因为不能辨别被损坏的报文，也就没有任何自动标识出这种攻击的方法。对有效证书的替换可以用两种不同的方式进行响应。第一种方式是作出一个一般性声明，该声明指出在两个不同的证书中使用相同公开密钥是不良习惯并且必须避免这样做。实际上，没有实用的方法可防止用户获及带有相同公开密钥的新证书，而应该假设用户会这样做。将新属性包含在Signer In
40、fo签名属性中，这样做可以把正确的证书标识符捆绑到该签名中去。这样就将一个可能会成功的攻击转换为简单的拒绝服务攻击。b)对重新签发证书的响应：认证机构决不应重新颁发一个带有不同属性的证书。这样的认证机构是跟随不良习惯，并且是不可信赖的。使用散列证书作为证书的基准可以防止针对端实体证书的这种攻击。为了防止基于重新颁发CA证书的攻击，可以要求对提出的SigningCertificate属性的用法有相当大的变化。要求将ESSCertID包含在该证书中，以表示在签名者的认证通路中的该颁发者的证书。当信赖的一方使用交叉证书作为其鉴别过程的一部分时，问题就出现了，同时该证书并不出现在证书列表上。在封闭PK
41、I之外的这些问题使得系统添加这种信息时易于出错，并可能导致有效证书链被拒绝。c)对欺诈复制CA的响应：防止这种攻击的最好方法是避免信任虚假CA。使用散列来标识证书可防止使用来自虚假机构的端实体证书。然而，防止这种攻击的唯一实际方法是决不信任虚假CA,授权信息可以用作签名过程的一部分。该信息可以被携带任一属性证书和其他公开密钥证书中。签名者需要具有限制证书集合用于签名过程的能力，并且对信息需要进行编码，以使对SignedData对象的签名可包括该信息。本条中的方法便于将授权证书集合作为签名证书属性的一部分加以列出。明确的证书策略也可以用作签名验证过程的一部分。如果签名者要求说明在确认该签名时宜使
42、用的明确的证书策略，则该策略需要以密码方式捆绑到该签名过程中去。本条所描述的方法便于将证书策略声明集合作为签名证书属性的一部分加以列出。6.2三，随蔽包装6.2.1基本概念每项S/MIME增强安全服务的一些特性都采用“三重隐蔽包装”的概念对报文进行包装。即一个被三重隐蔽包装的报文要先被签名，然后被加密，最后又被签名。这里，对内部和外部签名的人可能是不同的实体或是同一个实体。6.2.2三孟随蔽包装的目的 GB/Z 19717-2005并非所有的报文都需要三重隐蔽包装。当必须对报文签名、然后再加密，最后将签了名的报文属性装配到被加密的主体上时，需要使用三重隐蔽包装。发出报文的人或中间代理可以添加或
43、删除其外部属性，且外部属性也可以被中间代理或最终的收件人签名。内部签名可用于保证内容的完整性、抗抵赖、对信源的鉴别以及将报文的属性（如安全标签）捆绑到报文的初始内容中。这些属性从发件人传到收件人，无论中间实体（如处理报文的邮件清单代理）有多少个。这种签名属性可以用来控制对内部主体的访问，并且在内部签名中还带有发方索要签名收据的请求。被加密的主体具有机密性，包括在内部签名中所携带的这些属性的机密性。外部签名可用于鉴别被逐级处理的信息并可保证其完整性。每一级是一个中间实体，如邮件列表代理。外部签名将属性（如安全标签）捆绑到被加密的主体上，这些属性常用于访问控制和路由选择。6.2.3三孟隐蔽包装的步
44、骤以下是创建一个三重隐蔽包装报文的步骤：a）先从报文主体开始，称“初始内容”。b）用适当的MIME内容类型(Content-type）头封装初始内容，例如“Content-type: text/plain（内容类型：文本明文）。此MIME封装规则的一个例外是被签名的收据不放在MIME头中。c）给第2步的结果（内部MIME头和初始内容）签名。SignedData encapContentInfo eContent-Type对象标识符必须是id-data。如果您在第4步创建的结构是multipart/signed，则不得有SignedData encapContentInfo eContent。如
45、果您在第4步创建的结构是application/ pkcs7-mime，则SignedData encapContentInfo eContent必须包含上述第2步的结果。SignedData的结构被内容类型（contentType）为id-signedData的ContentInfo序列所封装。d)按照MSG MSG中的定义，将适当的MIME结构添加到第3步的被签名的报文中。所得出的报文称为“内部签名”。如果您用multipart/signed进行签名，则添加的MIME结构包括带参数的内容类型mul-tipart/signed、边界、上述第2步的结果、边界、内容类型application/p
46、kcs7-signature、可选的MIME头（如Content-transfer-encoding和Content-disposition）以及作为上述第3步的结果的主体部分。如果您使用application/ pkcs7-mime进行签名，则所添加的MIME结构包括带参数的内容类型application/ pkcs7-mime、可选的MIME头（如Content-transfer-encoding和Con-tent-disposition）以及上述第3步的结果。e）将第4步的结果作为单个块进行加密，将它变成一个application/ pkcs7-mime对象。Envel-opedData
47、 encryptedContentlnfo的内容类型(contentType）必须是id-data. EnvelopedData结构被内容类型为id-envelopedData的ContentInfo序列所封装，并称为“被加密的主体”。f）添加适当的MIME头：带参数的内容类型application/ pkcs7-mime和可选的MIME头部，如Content-transfer-encoding和Content-disposition.g）用与上述第3步相同的逻辑，将第6步的结果（MIME标题和被加密的主体）作为单个块进行签名。h)用与上述第4步相同的逻辑，将适当的MIME结构添加到第7步的被
48、签名的报文中。所得到的结果称为“外部签名”，且是三重隐蔽包装的报文。6.2.4三贡隐蔽包装报文的格式一个被三重隐蔽包装的报文具有多层的封装。其结构会因报文中被签名的部分的格式的不同而不同。由于MIME封装数据的方式，这些封装层不按次序出现，使得“层”的概念变得模糊起来。由于已知接受方能够处理S/MIME报文（因为他们解密了中间伪装器），因此无需在内部签名中使GB/Z 19717-2005用multipart/signed格式。发送代理了解选择在外层使用multipart/signed格式，这样，非S/MIME代理可以知道下一个内层被加密；然而，这没有什么价值，这是因为收方可以发现报文的其余部分是无法读的。由
