网络安全与信息加密技术-第十九章

事实上，在所有的分布式环境中，电子邮件是最繁重的网络应用。无论双方使用何种操作系统和通信软件，用户都希望能够直接或间接与Internet连接着的对方发送电子邮件。随着对电子邮件依赖性的爆炸式增长，认证性和保密性服务需求也在日益增长。两种被广泛应用的方法：PGP和S/MIME脱颖而出。本章将阐述这两种方法。第19章电子邮件主要由PhilZimmermann提出的PGP提供了可用于电子邮件和文件存储应用的保密性和认证性。基本上，Zimmermann做了如下工作：1.在构建数据块时，选用了最合适、可用的密码算法。2.将这些算法整合到通用应用程序中，这些应用程序独立于不同操作系统和处理器，并且是基于一个小规模的易用指令集。3.将其制作成软件包并形成文档，包括源代码。这些资源都可以通过Internet，广告牌和诸如AOL(AmericaOnLine)的商用网络免费获取。4.与Viacrypt(现在的NetworkAssociates)公司达成协议，提供完全兼容、低成本的商用版PGP。19.1PGP第19章电子邮件PGP的应用迅速普及，呈爆炸式增长。其原因大致可归纳如下：1.提供了在世界范围内的各种免费可用的版本，可运行于各种平台，包括Windows，UNIX，Macintosh等。另外，其商用版满足了用户的需求并获得了商家的支持。2.使用的算法是经过广泛的使用检验并被认为是非常安全的算法。值得指出的是，这个软件包中包含了用于公钥加密的RSA，DSS和Diffie-Hellman算法，用于对称加密的CAST-128，IDEA和3DES算法以及用SHA-1做Hash编码。3.应用范围广泛，即可用于公司选择和增强加密文件与消息的标准化模式，也可用于个人通过Internet或其他网络进行安全通信。4.不是由政府或者是标准化组织开发或控制。对那些本能地对上述“组织”有不信任的人们来说，PGP非常有吸引力。19.1PGP

19.1PGP

19.1PGP操作描述与密钥管理相对应，PGP的实际操作由4类服务组成：认证、保密、压缩和电子邮件兼容性[如下表所示]：下面我们一一介绍。19.1PGP认证：下图描述了PGP提供的数字签名服务。该数字签名方案在第13章讨论过。认证过程如下：1.发送方生成消息。2.用SHA-1算法生成消息的160位Hash码。3.用发送方的私钥按RSA算法加密该Hash码并将结果预先加入到消息中。19.1PGP4.接收方用发送方的公钥按RSA算法解密消息并回复Hash码。5.接收方对该消息用相同的Hash函数生成新的Hash码，并比较该Hash码与解密得到的Hash码，如果两者吻合则该消息为可信的。SHA-1和RSA的结合提供了一个高效的数字签名方案。鉴于RSA的安全强度，接收者可以确信如果是不同的消息必定无法生成与该Hash码匹配Hash值。于是保证了原消息签名有效。19.1PGPDSS/SHA-1也是生成数字签名的可选方案。尽管通常情况下签名都会附在消息或者是文件中，但也不尽然：签名也可以被分离出来。一个分离式签名可能会被同对应的消息分开存储或传输。这在一些情形下是有用的，例如某用户可能希望能为所有发送或接收到的消息的各分离式签名建立并保持一个日志。一个可执行程序的分离式签名可用来甄别该程序是否被病毒感染。另外，分离式签名还可以用于多个成员对一份注入合法契约等文件进行签名，每一个成员的签名都是独立的并且只用于该文件，否则签名可能会被嵌套，例如第二个成员会对文档和第一个成员生成的签名进行签名等。19.1PGP保密：PGP提供的另一个服务是保密，这是通过对传输的消息或者是本地存储的文件进行加密来实现的。在如上两种情形下对称加密算法(CAST-128)是可用的。同时，IDEA和3DES也是也用的。使用64位密文反馈模式(DFB)。19.1PGP通常，设计加密时必须讨论密钥分配的问题。在PGP中，每一个对称密钥都只使用一次，这意味着对每一个消息都会随机生成一个128位的自然数用作新密钥。因此，尽管这在标准文档中是指会话密钥，其实是一次性密钥。因为它只是用一次，所以会话密钥会和消息绑定并随之一起传输。用接收者的公开密钥加密以保护该会话密钥[如上图所示]。用文字描述如下：1.发送者生成消息和仅用于加密该消息的会话密钥，该会话密钥为128位随机自然数。2.采用CAST-128(或IDEA或3DES)算法，使用该会话密钥加密消息。3.采用RSA算法，用接收者的公开密钥加密该会话密钥并预先发送给对方。19.1PGP4.接收者采用RSA算法，用自己的私钥解密并恢复会话密钥。5.用会话密钥解密消息。作为用于对密钥进行加密的RSA算法的替换，PGP还提供了Diffie-Hellman算法作为选择。正如第10章中所介绍的那样，Diffie-Hellman是一个密钥交换算法。事实上，PGP使用了大量的Diffie-Hellman来提供加/解密。19.1PGP上述过程中我们会发现一些问题。首先，为了减少加密时间，对称加密和公钥加密的结合在效率上优于仅仅使用RSA或者ElGamal直接对消息进行加密：CAST-128和其他对称加密算法远快于RSA或ElGamal。其次，公钥算法的使用解决了会话密钥分配的问题，因为只有接收者才能还原与消息绑定的会话密钥。值得注意的是，在这里我们不需要使用像在第14章中讨论的会话密钥交换协议，因为我们不会从正在进行的会话中开始，而是对每一个消息都是用独立的一次性密钥。此外，鉴于电子邮件存储转发的特性，使用握手协议来确保通信双方拥有相同的会话密钥也是不切实际的。最后，使用一次性对称密钥也使原本安全强度较高的对称加密方法更安全。每一个密钥都只加密少量的明文，并且密钥与密钥之间没有任何关联。因此，在某种意义上说只要公钥算法是安全的，那么整个方案就是安全的。19.1PGP同时，PGP为用户提供了密钥长度从768位到3072位范围之间的选择(用于数字签名的DSS密钥限制在1024位)。保密性和认证性：如上图所描述，保密性和认证性这两种服务可能会对同一个消息使用。首先，生成一个明文的签名，然后用CAST-128(或IDEA或3DES)对明文消息和签名进行加密，然后用RSA(或ElGamal)对会话密钥加密。这个流程比先加密消息然后生成密文的签名的过程要好。这样更便于保存明文消息的签名。19.1PGP

19.1PGP1.生成签名在压缩之前进行是由于如下两个原因：a.对未压缩的消息进行签名更有利于仅存储未压缩消息和签名以便未来的签名验证。假如压缩后对文档签名，那么必须要么存储消息的一个压缩版或者是当需要时对消息重新压缩以便验证签名。b.即使有用户愿意为验证签名动态的生成消息的压缩版，PGP的压缩算法也表现出不合适。因为该算法是不确定的，在运行速度和压缩比之间权衡时会产生该算法各种不同形式的实现。但是，这些不同的算法实现是可以同时使用的，因为该算法的任何版本都可以正确的解压缩任何其他版本的压缩文件。在Hash函数和签名之后使用可以使所有的PGP实现都统一使用一种版本的压缩算法。2.在压缩之后对消息进行加密是为了增强密码运算的安全性。因为压缩后的消息比原明文的信息冗余少，这让密码分析更加困难。19.1PGP所使用的压缩算法ZIP将在附录0中有介绍。电子邮件兼容性：当使用PGP时，数据块中至少被传输的那部分会被加密。假如使用了数字签名服务，那么消息的摘要会用发送者的私钥加密。假如使用了保密服务，那么消息和签名(如果有签名的话)会用一次性对称密钥加密。因此，数据块的整体或部分会由任意的8字节流组成。但是大多数的电子邮件系统都只允许使用由ACSII文本组成的数据块。为了适应限制，PGP提供了将原字节流转换成可打印的ASCII字符流的服务。Radix-64就是用于该目的的解决方案。每三个字节组成的二进制数据可以映射成四个ASCII字符。这种格式也附加了CRC校验码用来检查传输错误。19.1PGP

19.1PGP下图显示了到目前为止讨论的4种服务之间的关系。19.1PGP在传输方，假如需要可以生产一个明文的Hash码用作签名。然后压缩明文(如果有签名就加上签名)。接着，如果有保密性要求，这个数据块(压缩了的明文或者是压缩了签名和明文的集合)就用对称密钥加密，而该对称密钥则是预先用公钥加密的。最后，将整个数据块转换成Radix-64格式。在接收方，首先把接收到的数据块由Radix-64格式转换成二进制。然后，假如消息是加密的，那么接收者就用自己的私钥恢复出会话密钥并用会话密钥解密消息。然后把得到的结果解压。假如消息是签名的，那么接收者就恢复出传输过来的Hash码并且与自己计算的Hash码进行比较。19.1PGPS/MIME(Secure/MultipurposeInternetMailExtension)是对基于RSA数据安全的MIMEInternet电子邮件格式标准的安全性增强。尽管PGP和S/MIME都是IETF工作组推出的标准，但是S/MIME倾向于推广为商业或组织用于的工业标准，而PGP则用来为个人电子邮件安全提供服务选择。S/MIME在很多的文档中被定义了，其中最重要的是RFC3370,3850,3851和3852。为了理解S/MIME，我们首先得对其使用的电子邮件格式(即MIME)有一个大概的理解。但是为了理解MIME的重要性，又将回到传统的电子邮件格式标准(RFC822)，而该标准仍然广泛使用。最新版本的格式规范是RFC5322(Internet消息格式)。因此，本节将首先介绍那两个较早的标准然后再开始讨论S/MIME。19.2S/MIME第19章电子邮件RFC5322RFC5322定义了用电子邮件发送的文本消息的格式。这已经是基于Internet的文本邮件消息的标准并且仍然在广泛使用。在RFC5322中，消息被视为一个信封和内容的组合。信封包含了任何用来完成传输和发送功能的信息。内容则构成了发送给接收者的对象。RFC5322标准关注的是内容部分。但是，内容标准包含了一系列头域，这些头域是由邮件系统用来生成信封的，而该标准也致力于使程序获取头域信息更方便。符合RFC5322的消息的大体结构非常简单。一个消息包含了若干行的头部(thehead)和随后的无限制的正文(thebody)。头部和正文中间用一空行隔开。另外，消息是ASCII文本，第一个空行之上的所有行都是邮件系统中用户代理部分使用的头部行。19.2S/MIME头部行通常包含关键字、冒号和关键字的参数，该格式允许将一个长行分割成若干短行。使用最频繁的关键字是From，To，Subject和Date。例如：在RFC5322中常见的另一个域是消息标志(Message-ID)，该域包含一个与该消息关联的唯一标志符。19.2S/MIMEMIMEMIME是RFC5322的扩展，目的是解决一些因使用简单邮件传输协议(SMTP，在RFC821中定义)或其他一些邮件传输协议而产生的限制。参考文献列出了SMTP/5322方案的限制。1.SMTP不能传输可执行文件和其他二进制对象。SMTP邮件系统使用了很多用来将二进制文件转换为文本格式的方案，包括闻名的UNIXUUencode/UUdecode方案。但是，没有一个成为标准或者事实上的标准。2.SMTP不能传输含有国际语言字符的文本数据，因为这些字符是由8位码表示的，其值可能是十进制128或者更大的数，而SMTP只能用7位的ASCII码。3.SMTP服务器会拒绝超过一定尺寸的消息。19.2S/MIME4.ASCII码和EBCDIC码之间转换的SMTP网关并未使用一致的映射集，因此常会出现转换错误。5.X.400电子邮件网络的SMTP网关不能处理X.400消息中的非文本数据。6.一些SMTP的实现并没有严格遵守RFC821文档中定义的SMTP标准，因此会导致以下常见的问题：回车和换行的删除、添加和重排。截断或者是限制超过76个字符长度的行。去除白字符(制表符和空格符)。将消息中的行填充为等长。将制表符转换成多个空格符。MIME期望能解决上述这些问题并与现存的RFC5322实现兼容。19.2S/MIME概述：MIME规范包含以下要素：1.定义了5个新的头部域，这些域提供了消息正文的相关信息。2.定义了一些新的内容格式，标准化的表示支持了多媒体的电子邮件。3.定义了编码转换方式，以使邮件系统能将任何形式的内容统一地转换为另一种形式。在本小节中，我们将介绍这5个头部域，在随后的两个小节将讨论内容格式和编码转换方式：MIME-Version(MIME版本)：参数的值必须为1.0，该域表明消息遵循RFC2045和RFC2046的格式。Content-Type(内容类型)：详细地描述了正文中的数据以使接收方的代理能采用合适的代理或机制来为用户展示数据或以一个合适的方法来处理数据。19.2S/MIMEContent-Transer-Encoding(内容转换编码)：指示转换的类型以使其能将消息正文的展现形式可为邮件传输所用。Content-ID(内容标志)：在多重上下文中唯一标志MIME实体。Content-Description(内容描述)：正文对象的文本描述，这对于对象是不可读的情形是很有用的(如音频数据)。通常在一个RFC5322头中会出现一个或多个上述域。一个合适的实现必须支持MIME-Version，Content-Type，Content-Transfer-Encoding域，接收方的实现可以选择使用或忽略Content-ID和Content-Description域。MIME内容类型：MIME规范文档中有很大的篇幅是关于各种内容类型的定义。这也反映了在多媒体环境下提供处理各种信息展现形式的需求。19.2S/MIME下表列出了RFC2046中规定的内容类型。主要有7个不同的大类和总共15个子类。一般而言，用内容类型表示数据的通用类型，用子类型来表示该数据类型的特定格式。19.2S/MIME若正文为文本类型(texttype)，则除了要支持制定字符集外不需要特殊的软件来获取文字的全部意义，因此主要的子类型为纯文本(plaintext)，有简单的ASCII码或ISO8859字符组成的字符串。子类型enriched则允许拥有更多的格式信息。类型为多部分类型(multiparttype)时，表示正文中包含多个相互独立的部分。域Content-Type中包含一个称为分界符的参数，该分界符定义了正文中各部分的分隔符。此分隔符不能随意出现，而必须从一个新行开始，并在两个连字符后跟分界符值，最后一个分界符表示最后一部分的结尾，并有两个连字符做后缀。在每个部分，可以有一个通常的MIME头部。19.2S/MIME以下是一个多部分消息的简单例子，包含由简单文本组成的两个部分：19.2S/MIMEMultipart类型有4种子类型，其语法相同。子类型multipart/mixed用于将相互独立的各部分按一定的顺序绑定。子类型multipart/parallel表示各部分的顺序无关。如果接受系统合适，则各部分可以并行接收。例如，在图片或文本显示时，可同时播放音频。19.2S/MIME子类型multipart/alternative表示这若干个部分是同一个信息的不同表示。例如：19.2S/MIME在此子类型中，各部分按优先级递增的方式排序。例如，如果接收方可以处理text/enriched格式的信息，则按此格式处理，否则就使用纯文本方式。子类型multipart/digest用于将正文的每个部分作为一个带头部的RFC5322消息，从而使得一个消息中可以包含多个独立的消息。例如，可以用一组缓冲器搜集组中各成员的电子邮件消息并将其封装到一个MIME消息中发送。类型message提供了许多MIME的重要特征。子类型message/rfc822表明该正文是一个完整的消息，包含了头和正文。除了子类型的名字外，封装的消息即可以是RFC5322消息，也可以是任何MIME消息。19.2S/MIME子类型message/partial使得可以将一个大消息分段为若干部分，并可以在目的地重新组装。对这个子类型而言，Content-Type：Message/partial域需要说明三个参数：一个对同一个消息所有分片一致的标志id，一个每段唯一的序列号sequencenumber和总的段数total。19.2S/MIME子类型message/external-body表明消息所要表达的数据并未包含在该正文中。而是在正文中包含了对该数据的访问。和其他消息类型一样，子类型message/external-body也有一个外头部和包含其头部的封装。外头部中唯一必须的域为内容类型(Content-Type)域，它指示了子类型message/external-body。内头部是封装消息的头部。外头部中的内容类型(Content-Type)域必须包含一个访问类型(access-type)参数，它指示了访问方法，例如FTP(文件传输协议)。类型application是指其他类型的数据，如不能解释的二进制数据或由邮件应用程序处理的信息。19.2S/MIMEMIME转换编码：MIME规范中另一个主要部分是定义消息正文的转换编码。其目的是在庞大的网络环境中提供可靠的传输方式。MIME标准定义了两种编码方式，但Content-Transfer-Encoding域可以取6个值，如下表所示。其中当值为7位，8位和binary时，并不进行编码，而是提供一些与数据属性相关的信息。对SMTP传输而言，用7位比较安全，而在其他邮件传输协议中可以使用8位和binary格式。19.2S/MIMEContent-Transfer-encoding域也可以取值x-token，用来表示其他编码方式，并提供该方式的名字。这种方式可以是生产商规定的或应用程序规定的方式。目前，有两种方式：quoted-printable和Base64，它们都是为了提供一种将所有数据类型的紧凑表示转换为便于人们阅读的形式而设计的。quoted-printable转换编码使用数据由大量可打印的ASCII字符组成。其本质上是一种不安全的十六进制字符表示方法。并引入软回车来解决每行不得超过76个字符的限制。Base64转换编码是一种Radix-64的编码方式，是一种对二进制数据进行编码的通用方法，在邮件传输过程中无懈可击，也用于PGP。19.2S/MIME规范格式：规范格式是MIME和S/MIME的一个重要概念。规范格式指的是一种与内容类型相对应的格式，可以在系统中作为标准使用。下表可说明此问题。19.2S/MIMES/MIME功能就大体功能而言，S/MIME与PGP非常相似。两者都提供了签名和加密消息的能力。在本节中我们将简要介绍S/MIME的功能，然后再从消息格式的消息准备方面详细叙述每个功能。功能：S/MIME有如下功能：封装数据：由任何类型的加密内容和加密该内容所用的加密密钥组成，密钥可以是与一个或多个接收方的秘钥。签名数据：数字签名通过提取待签名内容的数字摘要，并用签名的私钥加密得到。然后用Base64编码方法重新对内容和签名编码。因此，一个签名了的数据消息只能被具有S/MIME能力的接收方处理。19.2S/MIME透明签名数据：签名的数据形成了内容的数字签名。但在这种情况下，只有数字签名采用了Base64编码，因此没有S/MIME能力的接收方虽然无法验证签名但却可以看到消息内容。签名并封装数据：仅签名实体和仅封装实体可以嵌套，能对加密后的数据进行签名和对签名后的数据或透明签名数据进行加密。19.2S/MIME密码算法：下表总结了在S/MIME中使用的密码算法。S/MIME中使用了如下术语：Must：在规范说明书中表示一定要满足的要求，其实现必须与规范说明中的功能一致。Should：如果在特定条件下有合理的理由也可以忽略，但推荐其实现包含该功能。19.2S/MIMES/MIME整合了三种公钥算法。第13章的DSS(DigitalSignatureStandard)是其推荐的数字签名算法。Diffie-Hellman是其推荐的密钥交换算法。实际上，在S/MIME中使用的是其能加密解密的变体ElGamal(详见第10章)。第9章讲述的RSA既可以用来做签名，也可以用来加密会话密钥。这些算法与PGP中使用的算法相同，提供了高层安全性。文档规范推荐使用160位的SHA-1算法作为数字签名的Hash函数，但是要求接收方能支持128位的MD5算法。第11章对MD5安全性的讨论指出SHA-1的安全性更好一些，但由于MD5已经有了广泛的应用，因此必须提供相关支持。对消息加密而言，推荐使用3DES。但实现时也必须支持40位的RC2，后者是一种弱加密算法，美国允许出口该算法。19.2S/MIMES/MIME文档规范包含如何解决采用何种加密算法。从本质上说，一个发送方代理需要做如下两个选择：一是发送方代理必须确定接收方代理是否能够使用该加密算法进行解密。二是如果接收方代理只能接收弱加密的内容，发送方代理必须确定弱加密方法是否是可以接受的。为能达到上述要求，发送方代理可以在他发送消息之前宣布他的解密能力，由接收方代理将该消息存储，留给将来使用。发送方代理必须按照如下顺序进行：1.如果发送方代理有一个接收方解密性能表，则他应该选择表中的第一个(即优先级最高)。2.如果发送方代理没有接收方代理的解密性能表，但曾经接收到一个或多个来自该接收方的消息，则应该使用与最近接收到的消息一样的加密算法，加密将要发送给接收方的消息。19.2S/MIME3.如果发送方代理没有接收方的任何解密性能方面的知识，并且想冒险一试(接收方可能无法解密消息)，则应该选择3DES。4.如果发送方代理没有接收方任何解密性能方面的知识，并且不想冒险，则发送方代理必须使用RC2/40。如果消息需要发给多个接收方，并且他们没有一个可以共同接受的加密算法，则发送方代理需要发送两条消息，此时，应该特别注意该消息的安全性将由于弱安全性的一份副本而受到威胁。19.2S/MIMES/MIME消息S/MIME使用了一系列新的MIME内容类型，如下表所示。所有新的类型都使用PKCS(Public-KeyCryptographySpecifications)设计，PKCS是纪念为S/MIME做出贡献的RSA实验室及它们发布的一组公钥密码规范说明。下面逐一介绍S/MIME消息处理过程。19.2S/MIME保护MIME实体：S/MIME用签名和/或加密保护MIME实体。一个MIME实体可以是一个整体消息(除RFC5322头部之外)，或当MIME内容类型为multipart时，MIME实体是一个或多个消息的子部分。MIME实体将按照MIME消息准备规则进行准备工作。然后将MIME实体和一些与安全相关的数据(如算法标识符、证书)一起用S/MIME处理，得到所谓的PKCS对象，最后，将PKCS对象作为消息内容封装到MIME中(提供合适的MIME头部)。后面我们将举例说明。总之，将要发送的消息转换成规范形式。特别地，对给定的类型和子类型而言，相应的规范形式将作为消息内容。对一个多部分的消息而言，合适的规范形式被用于每个子部分。19.2S/MIME使用编码转换时应注意，在大多数情况下，使用安全算法会产生部分或全部二进制数据表示的对象，将该对象放入外部MIME消息后，一般用Base64转换编码对其进行转换。而对一个多部分签名的消息，安全处理过程并不改变字部分的消息内容，除了内容用7位表示的以外，其他代码转换应使用Based64或quotedprintable，使得应用签名的内容不会被修改。下面逐个介绍S/MIME内容类型。封装数据：子类型application/pkcs7-mime拥有一个smime-type参数。其结果(对象)采用ITU-T推荐的X.209中定义的BER(BasicEncodingRules)表示法。BER格式由8位字符串组成，即为二进制数据，因此，此对象可在外部MIME消息中使用Base64转换算法编码。首先，看看封装的数据。19.2S/MIMEMIME实体准备封装数据的步骤如下：1.为特定的对称加密算法(RC2/40或3DES)生成伪随机的会话密钥。2.用每个接收方的RSA公钥分别加密会话密钥。3.为每个接收方准备一个接收方信息块(RecipientInfo)，其中包含接收方的公钥证书标志，加密会话密钥的算法标志和加密后的会话密钥。4.用会话密钥加密消息内容。接收方信息块(RecipientInfo)后面紧跟着构成封装数据的加密内容，然后用Base64编码，例如(不包含RFC5322)：19.2S/MIME为了恢复加密的消息，接收方首先去掉Base64编码，然后用其私钥恢复会话密钥，最后，用会话密钥解密得到消息内容。签名数据：signedData的签名数据可以被一个或多个签名者使用。为了简便起见，我们将讨论范围限定在单个数字签名内。MIME实体准备签名数据的步骤如下：1.选择消息摘要算法(SHA或MD5)。2.计算带签名内容的消息摘要或Hash函数。3.用签名者的私钥加密数字摘要。4.准备一个签名者信息块(SignerInfo)，其中包含签名者的公钥证书，消息摘要算法的标识符，加密消息摘要的算法标识符和加密的消息摘要。19.2S/MIME签名数据实体包含一系列块，包含一个消息摘要算法标识符，被签名的消息和签名者信息块(signerInfo)，签名数据实体可以包含一组公钥证书，该证书可以构成从上级认证机构或更高级的认证机构到该签名者的一条链路。最后将这些数据用Base64转换编码。例如(不包含RFC5322头)：为了恢复签名消息并验证签名，接收方首先去掉Base64编码，然后用签名者的公钥解密消息摘要，接收方独立计算消息摘要，并将其与解密得到的消息摘要进行比较，从而验证签名。19.2S/MIME透明签名：透明签名(Clearsigning)在对多部分内容类型的子类型签名时使用。签名过程并不涉及对签名消息的转换，因此该消息发送时是明文。因此，具有MIME能力而不具备S/MIME能力的接收者也能阅读输入的消息。一个multipart/signed消息由两部分组成。第一部分可以是任何MIME类型但必须做好准备，使之在从源端到目的端的传输过程中不被改变，这意味着第一部分不能为7位，需要用Base64或quoted-printable编码。而后其处理过程与签名数据相同，但签名数据格式的对象中消息内容域为空，该对象与签名相分离，再将它用Base64编码，作为multipart/signed消息的第二部分。第二部分MIME内容类型为application，子类型为pkcs7-signature。19.2S/MIME例如：协议的参数表明它是一个由两部分组成的透明签名实体。参数micalg表明使用消息摘要类型。接收方可以从第一部分获得消息摘要，并同第二部分中恢复得到的消息摘要进行比较来进行认证。19.2S/MIME撤销请求：典型地，一个应用或用户向认证机构申请公钥证书。S/MIME的实体application/pkcs10用于传递证书请求。证书请求包括证书的请求信息块，公钥加密算法标识符，用发送方私钥对证书请求信息块的签名。证书请求信息块包含证书主题的名字(拥有待证实的公钥实体)和该用户公钥的标志位串。仅含证书消息：仅包含证书或证书撤销表(CRL)的消息在应答注册请求时发送。该消息的类型/子类型为application/pkcs7-mime，并带一个退化的smime-type参数。其步骤除没有消息内容及签名者信息块为空以外，其他过程与创建签名数据信息相同。19.2S/MIMES/MIME证书处理过程S/MIME使用公钥证书的方式与X.509的版本3一致(详见第14章)。S/MIME使用的密钥管理模式是严格的X.509证书层次和PGP的Web信任的一种混合方式。按照PGP模式，S/MIME的管理者和(或)用户必须配置每个客户端的信任密钥表和证书撤销表。也就是说，验证接收到的签名和输出消息的签名工作都是通过本地维护证书实现的。另一方面，证书由认证机构颁发。19.2S/MIME用户代理角色：一个S/MIME用户需要执行若干密钥管理职能：密钥生成：与一些行政管理机构相关的用户(如与局域网管理相关)必须能生成单独的Diffie-Hellman和DSS密钥对，并且应该能生成RSA密钥对。每个密钥对必须是利用非确定的随机输入生成，并用安全的方式保护。用户代理应该能生成长度为768位到1024位的RSA密钥对，且禁止生成长度大于512位的RSA密钥对。注册：为了获得X.509公钥证书，用户的公钥必须到认证机构注册。证书存储和检索：为了验证接收到的签名和