事實上，在所有的分布式環境中，電子郵件是最繁重的網絡應用。無論雙方使用何種操作系統和通信軟件，用戶都希望能夠直接或間接與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公鑰證書，用戶的公鑰必須到認證機構注冊。證書存儲和檢索：為了驗證接收到的簽名和