基于多用途互聯(lián)網(wǎng)郵件擴展的安全報文交換

1、基于多用途互聯(lián)網(wǎng)郵件擴展(MIME)的安全報文交換1  范圍    本指導性技術文件闡述了安全發(fā)送和接收多用途互聯(lián)網(wǎng)郵件擴展(MIME)數(shù)據(jù)的基本方法(即安全多用途互聯(lián)網(wǎng)郵件擴展，S/MIME)。該方法基于廣泛使用的多用途互聯(lián)網(wǎng)郵件擴展協(xié)議(MIME)，向各種Internet報文應用提供鑒別、報文的完整性、抗抵賴性、機密性等多種安全服務。傳統(tǒng)的郵件用戶代理使用該方法可以向所發(fā)送的報文增加各種加密服務，并能夠有效處理所收報文中的加密服務。本指導性技術文件還描述了S/MIME的增強安全服務。    本指導性技術文件不限于電子郵件

2、，它還可以用于任何傳輸MIME數(shù)據(jù)的傳輸機制(如超文本傳輸協(xié)議，HTTP)。該規(guī)范利用了MIME面向對象的特點，使得在各種傳輸系統(tǒng)中能夠交換安全報文。2規(guī)范性引用文件      下列文件中的條款通過本指導性技術文件的引用而成為本指導性技術文件的條款。凡是注日期的引用文件，其隨后所有的修改單（不包括勘誤的內(nèi)容）或修訂版均不適用于本指導性技術文件，然而，鼓勵根據(jù)本指導性技術文件達成協(xié)議的各方研究是否可使用這些文件的最新版本。凡是不注日期的引用文件，其最新版本適用于本指導性技術文件。    RFC 2045  多用途In

3、ternet郵件擴展(MIME)  第1部分  Internet報文體的格式    ，    RFC 2630  密碼報文語法    RFC 2633    S/MIME報文規(guī)范  第3版    RFC 2634增強的S/MIME安全服務3術語、定義和縮略語3.1  術語和定義    下列術語和定義適用于本指導性技術文件。3.1.1   

4、 證書certificate    采用數(shù)字簽名將實體的可辨別名與公開密鑰捆綁起來的類型。3.1.2    接收代理receiving agent    一種軟件，它解釋并處理S/MIME CMS對象及含有CMS對象的MIME主體部分。3.1.3    發(fā)送代理  sending agent    一種軟件，它創(chuàng)建S/MIME CMS對象和創(chuàng)建含有CMS對象的MIME主體部分。3.1.4    多用途互聯(lián)網(wǎng)

5、郵件擴展  Multipurpose Internet Mail Extensions(MIME)    MIME容許以下格式文檔作為報文    a)  非ASCII碼的字符集的文本報文體；      b)非文本報文體的不同格式的擴展集；    c)多部分的報文體；    d)  非ASCII碼的字符集的文本頭信息。3.1.5    S/MIME代理  S/MIME

6、agent    一種用戶軟件，它可以是接收代理或發(fā)送代理，或兩者都是。3.2縮略語    下列縮略語適用于本指導性技術文件。    CMS密碼報文語法    ESS增強安全服務    MIME多用途互聯(lián)網(wǎng)郵件擴展    S/MIME安全多用途互聯(lián)網(wǎng)郵件擴展4密碼報文語法(CMS)4.1概述    密碼報文語法(CMS)是以數(shù)字方式簽名、處理、鑒別或加解密任意報文的語法，并用來描述保護數(shù)

7、據(jù)的封裝語法。它支持數(shù)字簽名、報文鑒別代碼和加密。這種語法允許多重封裝，即一個封裝包可以嵌套另一個包。同樣，一方可以用數(shù)字方式給一些先前已經(jīng)封裝過的數(shù)據(jù)簽名。它還允許任意屬性（如簽名時間）同報文內(nèi)容一起被簽名，以及允許其它屬性（如防范簽名）與簽名相關聯(lián)。密碼報文語法可以支持各種實現(xiàn)基于證書的密鑰管理功能的體系結構RFC 2630對密碼報文語法(CMS)有詳細的規(guī)定。    密碼報文語法(CMS)普遍支持許多不同的內(nèi)容類型。RFC 2630規(guī)定了一種保護內(nèi)容：Contentln-forContentInfo可封裝一個已標識的內(nèi)容類型，這個已標識的類型可以進一步進行封

8、裝RFC 2630規(guī)定了六種內(nèi)容類型，數(shù)據(jù)、簽名數(shù)據(jù)、包裝數(shù)據(jù)、摘要數(shù)據(jù)、加密數(shù)據(jù)和鑒別數(shù)據(jù)4.2密碼報文語法基本結構    密碼報文語法(CMS)將內(nèi)容類型標識符與內(nèi)容相關聯(lián)起來。這種句法包含抽象語法記法I(ASN1)類型的ContentInfo字段；    ContentInfo:=SEQUENCE    contentType ContentType,    content 0. EXPLICIT ANY DEFINED BY contentType) 

9、60;  ContentType l l=OBJECT IDENTIFIER    ContentInfo字段有以下含義：    contentType表示相關聯(lián)內(nèi)容的類型。它是一個對象標識符，是由定義內(nèi)容類型的機構分配的唯一整數(shù)串。    content是關聯(lián)的內(nèi)容。內(nèi)容的類型可以由contentType唯一確定。5安全多用途互聯(lián)網(wǎng)郵件擴展(S/MIME)5.1概述    安全多用途互聯(lián)網(wǎng)郵件擴展(S/MIME)規(guī)定了向MIME數(shù)據(jù)增加加密簽名和加密服務的方法。M

10、IME規(guī)范規(guī)定了Internet報文內(nèi)容類型的通用結構，并對新的內(nèi)容類型應用提供擴充機制。RFC2633則定義了如何按照CMS創(chuàng)建經(jīng)加街的MIME主體部分，以及用于傳輸加密MIME主體部分的application/pkcsTmime內(nèi)容類型。RFC 2633還討論了如何使用MIME-SECURE所定義的muhipart/signed的MIME類型來傳輸S/MIME簽名報文，同時還定義了另一種用于傳輸S/MIME簽名報文的application/pkcs7-signature的MIME類型。為了創(chuàng)建S/MIME報文，S/MIME代理必須遵守RFC 2633及RFC 2630中所列的其他規(guī)范。由于

11、S/MIME系統(tǒng)可能涉及軟件而不是傳統(tǒng)的Internet郵件客戶端，因此接收代理與發(fā)送代理的要求是不同的。任何傳輸MIME數(shù)據(jù)的系統(tǒng)都能采用S/MIME，例如發(fā)送加密報文的自動進程可能完全不能接收加密的報文。5.2支持S/MIME的CMS選項    在內(nèi)容和算法支持方面，CMS考慮了各種各樣的選項。為了使所有支持S/MIME版本3的實現(xiàn)方案間達到基本的互操作性，RFC 2633提出了一些支持要求和建議。5.2.1摘要算法標識符    發(fā)送代理和接收代理必須支持同一個算法。這里以SHA-1為例。為了提供對采用MD5摘要的S/MIME版本

12、2簽名數(shù)據(jù)對象的向后兼容性，接收代理應支持MD5。5.2.2簽名算法標識符    發(fā)送代理和接收代理必須支持同一個數(shù)字簽名算法，這里以DSS為例。發(fā)送代理和接收代理應支持在DSS中定義的id-dsa，算法參數(shù)不必存在。接收代理應支持PKCS-I所定義的rsaEncryption，發(fā)送代理應支持r Encryption。采用用戶私有密鑰對出去的報文進行簽名，并在密鑰生成期間確定私有密鑰的長度。    注；S/MIME版本2客戶只能夠驗證采用rsacrypdon算法的數(shù)字簽名。5.2.3密鑰加密算法標識符   

13、; 發(fā)送代理和接收代理必須支持同一個密鑰交換算法，這里以Diffie-Hellman算法為例。接收代理應支持rsaEncryptiort。進入的加密報文包含著多個對稱密鑰，這些密鑰可以通過用戶的私有密鑰來解密，在密鑰生成期間確定私有密鑰的長度。發(fā)送代理應支持rsaEncryption。    注：S/MIME版本2的客戶只能解密使用rsaEncryption算法的內(nèi)容加密密鑰。5.2.4通用語法    CMS規(guī)定了多種內(nèi)容類型，其中S/MIME目前可用的只有數(shù)據(jù)、簽名數(shù)據(jù)及包裝的數(shù)據(jù)這三種內(nèi)容類型。數(shù)據(jù)內(nèi)容類型 

14、;   發(fā)送代理必須使用id-data內(nèi)容類型標識符來指明那些已采用安全服務的報文內(nèi)容例如，當對MIME數(shù)據(jù)采用數(shù)字簽名時，CMS signedData encapContentInfo eContentType必須包括id-dato對象標識符，并且MIME內(nèi)容必須被存放在SignedData encapContentInfo eContent的八位位組串中（除非發(fā)送代理使用多部分簽字，此時eContent可以不存在）。另一個例子，當對MIME數(shù)據(jù)進行加密時，CMS EnvelopedData encryptedContentInfo ContentType必須包含id-d

15、ata對象標識符，并且加密的MIME內(nèi)容必須存放在envelopedData encryptedContentInfo encryptedContent的八位位組串中。簽名數(shù)據(jù)內(nèi)容類型    發(fā)送代理必須對應用數(shù)字簽名的報文使用簽名數(shù)據(jù)內(nèi)容類型，或者在用于傳輸無簽名信息的證書的退化情況下必須使用簽名內(nèi)容類型。包裝數(shù)據(jù)內(nèi)容類型    該內(nèi)容類型用來向報文提供隱私性保護。發(fā)送者必須能夠獲得應用該服務所涉及的每一報文接收者的公開密鑰。5.2.5屬性簽名者信息類型    SignerI

16、nfo類型允許同簽名一起包含無簽名屬性和簽名屬性。接收代理必須能夠處理在此列出的每個簽名屬性的零個或一個實例，發(fā)送代理應在每個S/MIME報文中生成下列每個簽名屬性中一個實例：    a)  signingTime；    b)sMIMECapabilities     c)sMIMEEncryptionKeyPreference.     此外，接收代理應能處理signingCertificate屬性內(nèi)簽名屬性的零個或一個實例。發(fā)送代理應能在每個S/MIME報文中

17、生成signingCertificate簽名屬性的一個實例。以后可能會對這些屬性的附加屬性和值進行定義。接收代理應能通過友好的方式來處理那些它不識別的屬性或值。那些含有此處未列出的簽名屬性的發(fā)送代理應能向用戶顯示這些屬性，以便用戶知道被簽名數(shù)據(jù)的所有屬性。5.2.6  Slgnerldentifler SlgnerInfo類型    S/MIME版本3要求使用SignerInfo版本1，即對于Signerldentifier必須使用issuerAndSerial-Number的選項。5.2.7  內(nèi)害加密運算標識符  

18、60; 發(fā)送代理和接收代理必須支持采用同一數(shù)字加密算法。這里以DES EDE3 CBC為例進行加密和解密，以下簡稱“tripleDES”。接收代理應支持以RC2為例的兼容算法進行加密和解密。5.3創(chuàng)建S/MIME報文    S/MIME報文是MIME主體和CMS對象的組合，可以使用幾種MIME類型和幾種CMS對象。被保護的數(shù)據(jù)總是規(guī)范的MIME實體，并將MIME實體和其他數(shù)據(jù)（如證書和算法標識符）交給產(chǎn)生CMS對象的CMS處理設施，CMS對象最終被包裝在MIME中。S/MIME的增強安全服務規(guī)范(見RFC 2634)提供了如何嵌套的實例及構造安全的S/MIME報文

19、的方法RFC 2634提供了一個如何采用muhipart/signed和簽名的application/pkcsT-mime構成一個三重隱蔽包裝的S/MIME報文的實例。S/MIME為enveloped-only數(shù)據(jù)提供了一種格式，為signed-only數(shù)據(jù)提供了幾種格式，并為簽名及包裝的數(shù)據(jù)提供了幾種格式。5.3.1  準備簽名或包裝用的MIME實體    S/MIME被用于安全MIME實體。MIME實體可能是subpart、或是報文的subparts、或是帶有其所有子部分的整個報文。作為整個報文的MIME實體只能包括MIME頭和MIME主體，而不包括

20、RFC 822的頭。注意，S/MIME還能用于Internet郵件以外的應用所使用的安全MIME實體本指導性技術文件描述的安全的MIME實體可認為是“內(nèi)部”MIME實體，即它可能是大的MIME報文中“最內(nèi)部”的對象，在5.3.2、5.3.4和其他部分描述了將“外部”MIME實體處理為CMS對象。MIME規(guī)范給出了準備MIME實體的規(guī)程。在簽名時可使用帶有某些附加限制的相同規(guī)程。在此重復了MIME規(guī)范中的規(guī)程描述，本條還描述了一些附加的要求。    對于創(chuàng)建簽名的、包裝的或簽名且包裝的MIME實體應采用單個的規(guī)程。為了預防郵件傳輸期間可能出現(xiàn)的已知問題，推薦采用某些

21、附加步驟，這些步驟對于采用muhipart/signed格式的清晰簽名尤為重要建議對包裝的報文或簽名且封裝的報文實施這些附加步驟，以保證該報文能夠無修改地轉發(fā)到任何環(huán)境。    第一步：依據(jù)本地的約定準備MIME實體。    第二步：將MIME實體的葉子部分轉換為規(guī)范的形式。    第三步：對離開的MIME實體應用適當?shù)膫魉途幋a。    當接收到一個S/MIME報文時，要處理對報文所附帶的安全服務，該結果就是MIME實體。該MIME實體將傳遞給具備MIME處理能力的用戶代理，

22、由該代理將該MIME實體進行解碼和表示后提交給用戶或接收應用程序。有關準備簽名或包裝用的MIME實體的詳細要求見RFC 2633。5.3.2 applleation/pkcs7-mime類型    applieation/pkcs7-mime類型被用來攜帶幾種類型envelopedData和signedData的CMS對象。本條描述了application/pkcsT-mime類型的一般特性I如果eContentType是id-data攜帶的CMS對象通常包含了按5.3.1所描述方式準備的MIME實體I當eContentType包括了不同的值時，可以攜帶其它內(nèi)容。

23、    由于CMS對象是二迸制數(shù)據(jù)，大多數(shù)情況下64基的傳送編碼是適合的，尤其是采用SMTP傳輸方式。所用的傳送編碼依賴于被發(fā)送對象的傳輸方式，它不是MIME類型的特征。  5.3.3  創(chuàng)建Enveloped-only報文    本條描述了對MIME實體只包裝不簽名的格式。值得注意的是，發(fā)送只包裝不簽名的報文不能提供數(shù)據(jù)完整性，這可能是通過經(jīng)處理的報文將依然有效而可能改變了其意義的方式來替換密文。    第一步；按照5.3.1準備將要包裝的MIME實體。  

24、60; 第二步：將MIME實體和其他所需的數(shù)據(jù)處理為envelopedData類型的CMS對象。除了為每個接 收方加密content-encryption密鑰的副本外，還應該為發(fā)起方加密內(nèi)容加密密鑰的副本并將該副本包含于envelopedData中。    第三步：將CMS對象插入到一個application/pkcs7-mime MIME實體中。    enveloped-only報文的smime-type參數(shù)為“envelopeddata"，該類型報文的文件擴展是“p7m”。5.3.4創(chuàng)建只有簽名的報文  &#

25、160; 對于定義的S/MIME簽名報文存在兩種格式，即帶有SignedData的application/pkcs7-mime和muhipart/signed,發(fā)送代理應首選muhipart/signed格式，但接收代理應都能處理這兩種格式。選擇Signed-only報文格式    當選擇了特定的signed-only格式時，由于該格式取決于所有接收者的能力，同時該格式還取決于帶有能驗證該簽名的S/MIME設施的接收者與不帶有能觀察該報文的S/MIME軟件的接收者的相對重要性，因此不存在嚴格的規(guī)則。    &#

26、160;   不論接收者是否擁有S/MIME軟件，該接收者都能觀察到查看采用muhipart/signed格式簽名的報文。無論接收者正使用本地MIME用戶代理或它們擁有由網(wǎng)關所轉換的報文，這些報文還能被觀察到。在該上下文中，“觀察到”表示處理報文的能力，在實質上就像該報文不是一個簽名報文，包含其他MIME結構。接收方不能觀察到采用signedData格式簽名的報文，除非接收方擁有S/MIME設施。但是，如果接收方擁有.S/MIME設施，通常能夠驗證這些報文是否在傳輸中沒被更改。  采用帶有SignedData的applleatlon/pkcs7-ml

27、me的簽名    這種簽名格式使用application/pkcs7-mime MIME類型。創(chuàng)建該格式的步驟如下：    第一步。按照5.3.1條準備MIME實體。    第二步；將MIME實體和其他所需的數(shù)據(jù)處理為signedData類型的CMS對象。    第三步：將CMS對象插入到一個application/pkcs7-mime MIME實體中    采用帶有SignedData的applieation pkcsT- mime報文的smi

28、metype參數(shù)為“signed-data”，該類型報文的文件擴展是“p7m”。  采用multipart/signed格式的簽名    本格式是清晰簽名格式。不帶有任何S/MIME或CMS處理設施的接收方能夠觀察該報文。它使用了muhipart/signed MIME類型。Muhipart/signed MIME類型有兩部分。第一部分包含所簽名的MIME實體I第二部分包括“分離簽名”的CMS SignedData對象，該對象中不存在encapContentlnfo eContent字段。5.3.5簽名和加密  

29、0; 為了完成簽名和加密，可以嵌套任何signed-only格式和encrypted-only格式。由于上述的格式全部是MIME實體，并且這些格式都能保護MIME實體，所以允許這種嵌套方式。S/MIME實現(xiàn)方案必須能夠在接收方計算機合理有限的資源內(nèi)接收和處理任意嵌套的S/MIME?；蛘呤紫葘笪倪M行簽名，或者首先對報文進行包裝，由實施者和用戶來決定選擇何種方式。當首先進行簽名時，簽名人就通過包裝被安全地隱藏起來了。當首先進行包裝，簽名人是暴露的，但無需去除包裝就可能驗證簽名    無論選擇首先簽名還是首先加密都存在安全分歧。對于先加密后簽名報文的接收方能夠確認加密

30、塊沒被改變，但不能確定簽名者和未加密報文內(nèi)容之間的關系。對于先簽名后加密報文的接收方能夠假設簽名的報文本身未被改變，但是某些細致的攻擊者可能已更改了加密報文的未經(jīng)鑒別的部分。5.3.6  創(chuàng)建Certificates-only報文    Certificates-only報文或certificates-only MIME實體用來傳輸證書（諸如對注冊請求的響應），這種格式也能夠用來傳輸證書撤銷列表，    第一步l要使生成signedData類CMS對象的CMS生成進程能夠使用證書，signedData encapCon-te

31、ntlnfo eContent字段必須不存在，并且signerInfos字段必須為空。    第二步l將CMS signedData對象裝入application/pkcs7-mime MIME實體中。    certs-only報文的smime-type參數(shù)是“certs-only”。該類型報文的文件擴展是“p7c"。5.3.7注冊請求    對報文進行簽名的發(fā)送代理必須擁有簽名證書，以便接收代理能夠驗證簽名。5.3.8標識S/MIME報文    因為S/MIME

32、考慮到在非MIME環(huán)境中的互操作性，采用了幾種不同的機制來攜帶類型信息，它成為標識S/MIME報文的一點點困難。表1列出了判斷報文是否是S/MIME報文的準則如果某報文符合下列要求，則它可認為是S/MIME報文。表1中的文件后綴取自內(nèi)容類型頭中的“名稱”參數(shù)或內(nèi)容安排頭中“文件名”參數(shù)，給出文件后綴的這些參數(shù)未作為參數(shù)段的部分來列出。    表1 S/MIME報文判斷準則MIME類型；application/pkcs7-mime參數(shù)；any文件后綴；any MIME類型；multipart/signed參數(shù)；protocol= "applica

33、tion/pkcs7-signature"文件后緞； any MIME類型；applicationoctet-stream參數(shù)；any文件后綴；p7m, p7s, p7c5.4證書處理    接收代理必須提供某些證書檢索機制，以便獲得訪問數(shù)字信封接收方證書。本文件不涉及S/MIME代理如何處理證書，而只是描述在證書確認后或拒收后該代理執(zhí)行什么。對于最初的S/MIME推廣應用，用戶代理最低的要求是能夠為期望的接收方自動生成報文，該接收方請求在簽名的返回報文中的接收方證書接收代理和發(fā)送代理也應提供一種允許用戶為通信者“存儲和保護”證書的機制，通過這

34、種機制可以保證以后可以檢索這些證書。5.4.1密鑰對的生成    如果S/MIME代理需要生成一個密鑰對，那么S/MIME代理或某些相關的管理性實用程序或功能必須能以用戶的名義生成分開的DH和DSA公開密鑰私有密鑰對每一密鑰對必須根據(jù)非確定性隨機輸入RANDOM的良好來源來生成，并且私有密鑰必須以安全方式加以保護。    如果S/MIME代理需要生成一個密鑰對，那么S/MIME代理或相關的管理性實用程序或功能應生成RSA密鑰對。6.1概述    S/MIME可提供下列四種可選的增強安全服務； &

35、#160;  a)簽名收據(jù)    b)安全標簽；    c)  安全郵件發(fā)送列表及管理；    d)  簽名證書屬性。6.1.1簽名收據(jù)    報文始發(fā)者可以請求來自報文接收者的簽名收據(jù)。通過把receiptRequest屬性增加到請求收據(jù)的Signerlnfo對象的SignedAttributes字段中來指出該請求。當請求這樣做時，接收用戶代理軟件應自動地創(chuàng)建簽名的證書，并按照郵件發(fā)送列表擴充選項，本地安全策略和配置選項返回該收據(jù)。返回簽名收據(jù)

36、給始發(fā)者提供了報文交付證明，并且使得始發(fā)者可向第三方表明接收者曾驗證過初始報文的簽名。通過簽名已把該收據(jù)與初始報文捆綁起來因此，僅當要簽名報文時，才可以請求該服務。收據(jù)發(fā)送者也可以有選擇地加密某一收據(jù)，以便在收據(jù)發(fā)送者和收據(jù)接收者之間提供機密性。    收據(jù)請求可以指出這些收據(jù)被發(fā)送給許多地點，不僅僅發(fā)送給該發(fā)送者（在事實上，收據(jù)請求可能指出這些收據(jù)不宜都發(fā)給該發(fā)送者）。為了驗證收據(jù)，收據(jù)的接收者必須是初始報文的始發(fā)者或接收者。因此，該發(fā)送者應不請求將收據(jù)發(fā)送給沒有準確的報文副本的任何人。    由于收據(jù)涉及雙方的交互，收據(jù)這一術語有

37、時可能存在混淆。因此，在本章中，“發(fā)送者”就是發(fā)送包含請求收據(jù)的初始報文的代理?！敖邮照摺本褪鞘盏綀笪暮蜕墒論?jù)的一方。6.1.2安全標簽    安全標簽是通過S/MIME封裝來保護的有關敏感內(nèi)容的安全信息的集合?！笆跈唷笔窍蛴脩羰谟柙L問某個對象的權利和或特權的行為。“訪問控制”是實施這些權限的手段安全標簽中的敏感信息可以與用戶的權限相比較以確定用戶是否被允許訪問通過S/MIME封裝所保護的內(nèi)容。安全標簽可以用于其他用途諸如路由選擇信息的來源。這些標簽通常描述了分等級的若干級別（。秘密的”，“機密的”，“受限制的”等等）或者這些標簽是基于角色的，描述哪種人可以看到

38、該信息（“患者”的保健小組，醫(yī)療賬單代理，“不受限制的”等等）6.1.3安全郵件發(fā)送列衰及管理    發(fā)送代理必須為加密報文的每個接收者創(chuàng)建特定于接收者的數(shù)據(jù)結構。這個過程可能損害發(fā)送給大量接收者的報文性能。因此，通常要求郵件列表代理(MLA)對于每個接收者可以采用單個報文或執(zhí)行特定予接收者的加密。    對報文始發(fā)者來說，MLA似乎是常規(guī)的報文接收者，但是，MLA擔當郵件列表(ML)的報文擴充點。報文發(fā)送者將報文送給MLA，然后，將報文再分發(fā)給ML的成員。這個過程卸下了各個用戶代理按每個接收者的處理工作量，并且便于更有效管理大量ML

39、ML是受MLA服務的真實報文接收者，該MLA為郵件發(fā)送列表提供了密碼服務和擴充服務。    除了對報文進行密碼處理外，安全郵件發(fā)送列表還必須防止郵件循環(huán)郵件循環(huán)是指，其中某一個郵件發(fā)送列表是第二個郵件發(fā)送列表的成員，而第二個郵件發(fā)送列表又是第一個郵件發(fā)送列表的成員。一個報文將按向各列表的所有其他成分發(fā)郵件的快速級聯(lián)連續(xù)方式從某一個列表到達另一個列表。    為了防止郵件循環(huán)，MLA使用了三重隱蔽包裝報文的外部簽名的mlExpansionHistory屬性。mIExpansionHistory屬性在本質上是已經(jīng)處理該報文的所有MLA的列

40、表。如果MLA看到了在該列表中的它自己的唯一實體標識符，那么它就知道已經(jīng)形成了一次循環(huán)，并且它不會再向該列發(fā)送報文。6.1.4簽名證書屬性    令人們擔心的事是，要求CMS SignedData對象的簽名者與SignedData對象的驗證過程被捆綁起來的證書不是以密碼方式與該簽名自身捆綁起來。本條也提出了對一組可能攻擊的描述，這些攻擊涉及被替換的某一證書用來驗證所要求的證書的簽名。針對可能的簽名驗證過程至少可以發(fā)起三種不同的攻擊。其手法是替換簽名驗證過程中所使用的一個證書或多個證書。    a)第一種攻擊涉及用某一證書替換另一證書。

41、在這種攻擊中，Signedlnfo中的證書簽發(fā)者和序 列號被修改，以便提供新的證書。在簽名驗證過程期間使用這個新的證書這種攻擊的第1個版本是一種簡單的拒絕服務攻擊，其中，無效證書替換了有效證書。當證書中的公開密鑰不再與簽名該報文所使用的私有密鑰相匹配時，這就使該報文成為不可驗證的。其第二個版本是用某個有效證書替換初始有效證書，其中，兩個證書中的兩個公開密鑰相匹配這樣做允許根據(jù)與該報文的始發(fā)者潛在不同的證書限制來確認該簽名。  b)第二種攻擊涉及重新頒發(fā)簽名證書（或可能是其證書之一）的認證機構CA。隨著認證機構重新頒發(fā)它們自己的根證書，或髓著認證機構在重新頒發(fā)它們的根證書的同時改變證書

42、的策略，這種攻擊可能開始變?yōu)楦l繁。在驗證簽名的過程中使用交叉證書（帶有可能的不同限制）時就會出現(xiàn)這個問題。  c)第三種攻擊涉及建立一個CA的虛假實體，而這個虛假實體企圖重復現(xiàn)有CA的結構。特別是，該虛假實體使用與該簽名者使用的公開密鑰相同的公開密鑰來頒發(fā)新證書，但該虛假實體卻使用其私有密鑰對新證書進行簽名。  為了防止或指出對應這些攻擊的一組方法，以便處理一些最簡單的攻擊z  a)對替換攻擊的響應    不能防止拒絕服務攻擊。在運輸中已經(jīng)修改證書標識符之后，就不可能驗證該簽名。因為不能辨別被損壞的報文，也就沒有任何自動標識出這種攻

43、擊的方法。對有效證書的替換可以用兩種不同的方式進行響應。第一種方式是作出一個一般性聲明，該聲明指出在兩個不同的證書中使用相同公開密鑰是不良習慣并且必須避免這樣做實際上，沒有實用的方法可防止用戶獲及帶有相同公開密鑰的新證書，而應該假設用戶會這樣做將新屬性包含在Signer Info 簽名屬性中，這樣做可以把正確的證書標識符捆綁到該簽名中去。這樣就將一個可能會成功的攻擊轉換為簡單的拒絕服務攻擊。  b)對重新簽發(fā)證書的響應    認證機構決不應重新頒發(fā)一個帶有不同屬性的證書這樣的認證機構是跟隨不良習慣，并且是不可信賴的。使用散列證書作為證書的基準可以防止針對

44、端實體證書的這種攻擊。為了防止基于重新頒發(fā)CA證書的攻擊，可以要求對提出的SigningCertificate屬性的用法有相當大的變化。要求將ESSCertlD包含在該證書中，以表示在簽名者的認證通路中的該頒發(fā)者的證書。當信賴的一方使用交叉證書作為其鑒別過程的一部分時，問題就出現(xiàn)了，同時該證書并不出現(xiàn)在證書列表上。在封閉PKI之外的這些問題使得系統(tǒng)添加這種信息時易于出錯并可能導致有效證書鏈被拒絕。    c)對欺詐復制CA的響應；    防止這種攻擊的最好方法是避免信任虛假CA。使用散列來標識證書可防止使用來自虛假機的端實體證書然而，

45、防止這種攻擊的唯一實際方法是決不信任虛假CA    授權信息可以用作簽名過程的一部分。該信息可以被攜帶任一屬性證書和其他公開密鑰證書中。簽名者需要具有限制證書集合用于簽名過程的能力，并且對信息需要進行編碼，以使對SignedData對象的簽名可包括該信息。本條中的方法便于將授權證書集合作為簽名證書屬性的一部分加以列出，明確的證書策略也可以用作簽名驗證過程的一部分如果簽名者要求說明在確認該簽名時宜使用的明確的證書策略，則該策略需要以密碼方式捆綁到該簽名過程中去。本條所描述的方法便于將證書策略聲明集合作為簽名證書屬性的一部分加以列出。6.2三重隱蔽包裝6.2.1基本概

46、念    每項S/MIME增強安全服務的一些特性都采用“三重隱蔽包裝”的概念對報文進行包裝。即一個被三重隱蔽包裝的報文要先被簽名，然后被加密，最后又被簽名。這里，對內(nèi)部和外部簽名的人可能是不同的實體或是同一個實體。6.2.2三I隱蔽包裝的目的    并非所有的報文都需要三重隱蔽包裝。當必須對報文簽名、然后再加密，最后將簽了名的報文屬性裝配到被加密的主體上時，需要使用三重隱蔽包裝。發(fā)出報文的人或中間代理可以添加或刪除其外部屬性，且外部屬性也可以被中間代理或最終的收件人簽名。    內(nèi)部簽名可用于保證內(nèi)容的完

47、整性、抗抵賴、對信源的鑒別以及將報文的屬性（如安全標簽）捆綁到報文的初始內(nèi)容中。這些屬性從發(fā)件人傳到收件人，無論中間實體（如處理報文的郵件清單代理）有多少個。這種簽名屬性可以用來控制對內(nèi)部主體的訪問，并且在內(nèi)部簽名中還帶有發(fā)方索要簽名收據(jù)的請求。    被加密的主體具有機密性，包括在內(nèi)部簽名中所攜帶的這些屬性的機密性    外部簽名可用于鑒別被逐級處理的信息并可保證其完整性。每一級是一個中間實體，如郵件列表代理。外部簽名將屬性（如安全標簽）捆綁到被加密的主體上，這些屬性常用于訪問控制和路由選擇。6.2.3三重隱蔽包裝的步驟 

48、   以下是創(chuàng)建一個三重隱蔽包裝報文的步驟：    a)先從報文主體開始，稱“初始內(nèi)容”。    b)用適當?shù)腗IME內(nèi)容類型(Content-type)頭封裝初始內(nèi)容，例如“Content-type：text/plain”（內(nèi)容類型：文本明文）。此MIME封裝規(guī)則的一個例外是被簽名的收據(jù)不放在MIME 頭中。    c)  給第2步的結果（內(nèi)部MIME頭和初始內(nèi)容）簽名。SignedData encapContentInfo eContent-Type對象標識符必須是id-

49、data如果您在第4步創(chuàng)建的結構是multipart/signed，則不得有SignedData encapContentInfo eContent。如果您在第4步創(chuàng)建的結構是application/pkcs7-mime，則SignedData encapContentlnfo eContent必須包含上述第2步的結果。SignedData的 結構被內(nèi)容類型(contentType)為id-signedData的Contentlnfo序列所封裝。    d)按照MSG MSG中的定義，將適當?shù)腗IME結構添加到第3步的被簽名的報文中。所得出的報文稱為“內(nèi)部簽名”。

50、    如果您用multipart/signed進行簽名，則添加的MIME結構包括帶參數(shù)的內(nèi)容類型mul-tipart/signed、邊界、上述第2步的結果、邊界、內(nèi)容類型applieation/pkcsT-signature、可選的MIME頭(如Content-transfer-encoding和Content-disposition)以及作為上述第3步的結果的主體部分。    如果您使用application/pkcs7-mime進行簽名，則所添加的MIME結構包括帶參數(shù)的內(nèi)容類型application/pkcsT-mime、可選

51、的MIME頭(如Content-transfer-encoding和Con-tent-disposition)以及上述第3步的結果。    e)將第4步的結果作為單個塊進行加密，將它變成一個application/pkcs7-mime對象。Envel-opedData encryptedContentlnIo的內(nèi)容類型(contentType)必須是id-data。EnvelopedData結構被內(nèi)容類型為id-envelopedData的ContentInfo序列所封裝，并稱為“被加密的主體”。    f)添加適當?shù)腗IME頭：帶參

52、數(shù)的內(nèi)容類型application/pkcsT-mime和可選的MIME頭部，如  Content-transfer-encoding和Content-disposition.    g)用與上述第3步相同的邏輯，將第6步的結果（MIME標題和被加密的主體）作為單個塊進行簽名。    h)用與上述第4步相同的邏輯，將適當?shù)腗IME結構添加到第7步的被簽名的報文中。所得到的結果稱為“外部簽名”，且是三重隱蔽包裝的報文。6.2.4三重隱蔽包裝報文的格式    一個被三重隱蔽包裝的報文具有多層的封裝其

53、結構會因報文中被簽名的部分的格式的不同而不同。由于MIME封裝數(shù)據(jù)的方式，這些封裝層不按次序出現(xiàn)，使得“層”的概念變得模糊起來。      由于已知接受方能夠處理S/MIME報文（因為他們解密了中間偽裝器），因此無需在內(nèi)部簽名中使用muhipart/signed格式發(fā)送代理了解選擇在外層使用multipart/signed格式，這樣，非S/MIME代理可以知道下一個內(nèi)層被加密I然而，這沒有什么價值，這是因為收方可以發(fā)現(xiàn)報文的其余部分是無法讀的。由于許多發(fā)送代理通常使用muhipart/signed結構，因此所有接收代理必須能夠解釋multi-part/s

54、igned或application/pkcs7-mime簽名結構。    采用這兩種簽名用的muhipart/signed的三重隱蔽包裝報文的格式是    第八步 Content-typez multipart/signed     第八步  protocol-"application/pkcs7-signature",    第八步  boundaryouterboundary第八步    第八步 -ou

55、terboundary    第六步 Content-type application/pkcs7-mime    第六步 smime-type- enveloped-data    第六步    第四步 Content-typez multipart/signed    第四步  protocol-"application/pkcs7-signature"    第四步  b

56、oundary-innerboundary    第四步    第四步innerboundary    第二步 Content-typel text/plain    第二步    第一步 Original content    第四步    第四步innerboundary    第四步 Content-type, application/pkcsT-si

57、gnature    第四步    第三步 inn.er SignedData block (eContent is missing)    第四步    第四步innerboundary    第八步    第八步二outerboundary    第八步 Content-types application/pkcsT-signature    第八步&#

58、160;   第七步 outer SignedData block (eContent is missing)    第八步    第八步outerboundary    這里；%一這些行表示計算內(nèi)部簽名1=這些行表示在第5步被加密，加密的結果是不透明的，是EnvelopedData塊的一部分。)=這些行表示計算外部簽名  采用這兩種簽名用的application/pkcs7-mime的三重隱蔽包裝報文的格式是  第八步 Content-types applicat

59、ion/pkcs7-mime  第八步  smime-type- signed-data  第八步    第七步 outer SignedData block (eContent is present)    O    第六步 Content-type. application/pkcs7-mime;    )O    第六步  smime-type=enveloped-data;  &

60、#160; ）0    第六步                                  ）O    第四步 Content-type:application/pkcs7-mime# 

61、0;  I)O    第四步  smime-type= signed-data    I）O    第四步                              1）O  &#

62、160; 第三步 inrler SignedData block (eContent is present)    I I)0    第二步 Content-type：text/plain    l I）O    第二步                      

63、60;      I I）O    第一步 Original content    I I）O    這里：    I=這些行是內(nèi)部SignedData塊，不僅是無法理解的，而且包含第2步中用ASN.1編碼的結果以及控制信息。    I=這些行表示在第5步被加密被加密的結果是無法理解的，是EnvelopedData塊的一部分。    )=這些行表示計算外部簽

64、名    O=這些行是外部SignedData塊，不僅無法理解，而且還包含第6步中用ASN.1編碼的結果和控制信息。6.3 S/MIME增強安全服務和三重隱蔽包裝6.3.1  簽名收據(jù)與三重隱蔽包裝    在任何SignedData對象中，可能要求使用簽名收據(jù)。如三重隱蔽包裝的報文要求收件人回送收到該報文的簽名收據(jù)給發(fā)件人時，其收據(jù)請求必須包含在內(nèi)部簽名中，而不能在外部簽名中。因為，當郵件發(fā)送列表處理三重隱蔽包裝報文時，安全郵件發(fā)送列表代理可能會改變該報文的外部簽名中的收據(jù)策略。6.3.2安全標簽與三I隱蔽包裝 &

65、#160;  任何SignedData對象的簽名屬性可能包含安全標簽。在內(nèi)部簽名、或在外部簽名、或在這兩種簽名中都可能含有安全標簽屬性。    內(nèi)部安全標簽用來確定對與初始的明文內(nèi)容有關的訪問控制。內(nèi)部簽名提供鑒別，并以密碼的方式保護位于內(nèi)部主體的最初簽名者的安全標簽的完整性。這種策略便于轉發(fā)報文，因為最初簽名者的安全標簽被包含在可以被轉發(fā)給第三方的SignedData塊中，使第三方可以驗證包含內(nèi)部安全標簽的內(nèi)部簽名。機密性安全服務也可用于內(nèi)部安全標簽，方法是加密EnvelopedData塊中的整個內(nèi)部Signed-Data塊   &

66、#160;外部SignedData塊的簽名屬性也可包含安全標簽，且該塊可包含敏感的加密報文。外部安全標簽用來確定與加密報文有關的訪問控制和路由選擇。    注意;安全標簽屬性只可以在signedAttributes塊中使用。在EnvelopedData或未簽名屬性中不得使用eSSSecurityLabel屬性。6.3.3安全郵件發(fā)送列表與三重隱蔽包裝    安全郵件列表報文處理取決于發(fā)送給郵件列表代理的報文中所呈現(xiàn)的S/MIME各層的結構。如果存在內(nèi)部簽名，郵件列表代理決不會改變已散列(hashed)的數(shù)據(jù)，來形成內(nèi)部簽名。如果存在外

67、部簽名，郵件列表代理將修改已散列的數(shù)據(jù)，來形成這個外部簽名在這些情況下，郵件列表代理添加或更新mlExpansionHistory屬性，并記錄下郵件列表代理的處理活動，最終添加或替換待分發(fā)報文上的外部簽名。附錄A（資料性附錄）用ASN1描述的語法定義ExtendedSecurityServices       iso(1) member-.body(2) us(840) rsadsi(113549)          pkcs(1) pkcs-9

68、(9) smime(16) modules(0) ess(2) DEFINITIONS IMPLICIT TAGS : ,=BEGINIMPORTS密碼報文語法(CMS)    CryptographicMessageSyntaxiso(1) member-body(2) us(840) rsadsi(113549) lkcs(1) pkcs-9(9) smime(16) modules(O) cms(1 中的ContentType, IssuerAndSerialNumber, ubjectKeyIden-    tifierPKI

69、X證書和CRL框架SecA.2隱藏標記模式，-1988語法KIXlImplicit88iso(1)identified-organization(3) dod(6)internet(1)security(5)mechanisms    (5) pkix(7)id-mod(0) id-pkixl-implicit-88(2)中的PolicyInformationX. 509    CertificateExtensionsj oint-iso-ccitt ds (5) module(1)certificateExtensions( 26)0)中的General-Names, CertificateSerialNumber;擴展安全服務在本模塊中，“SEQUENCE SIZE (1.