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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

32、考慮到在非MIME環(huán)境中的互操作性，采用了幾種不同的機(jī)制來(lái)攜帶類型信息，它成為標(biāo)識(shí)S/MIME報(bào)文的一點(diǎn)點(diǎn)困難。表1列出了判斷報(bào)文是否是S/MIME報(bào)文的準(zhǔn)則如果某報(bào)文符合下列要求，則它可認(rèn)為是S/MIME報(bào)文。表1中的文件后綴取自內(nèi)容類型頭中的“名稱”參數(shù)或內(nèi)容安排頭中“文件名”參數(shù)，給出文件后綴的這些參數(shù)未作為參數(shù)段的部分來(lái)列出。    表1 S/MIME報(bào)文判斷準(zhǔn)則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證書處理    接收代理必須提供某些證書檢索機(jī)制，以便獲得訪問(wèn)數(shù)字信封接收方證書。本文件不涉及S/MIME代理如何處理證書，而只是描述在證書確認(rèn)后或拒收后該代理執(zhí)行什么。對(duì)于最初的S/MIME推廣應(yīng)用，用戶代理最低的要求是能夠?yàn)槠谕慕邮辗阶詣?dòng)生成報(bào)文，該接收方請(qǐng)求在簽名的返回報(bào)文中的接收方證書接收代理和發(fā)送代理也應(yīng)提供一種允許用戶為通信者“存儲(chǔ)和保護(hù)”證書的機(jī)制，通過(guò)這

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

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

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

37、時(shí)可能存在混淆。因此，在本章中，“發(fā)送者”就是發(fā)送包含請(qǐng)求收據(jù)的初始報(bào)文的代理。“接收者”就是收到報(bào)文和生成收據(jù)的一方。6.1.2安全標(biāo)簽    安全標(biāo)簽是通過(guò)S/MIME封裝來(lái)保護(hù)的有關(guān)敏感內(nèi)容的安全信息的集合?！笆跈?quán)”是向用戶授予訪問(wèn)某個(gè)對(duì)象的權(quán)利和或特權(quán)的行為。“訪問(wèn)控制”是實(shí)施這些權(quán)限的手段安全標(biāo)簽中的敏感信息可以與用戶的權(quán)限相比較以確定用戶是否被允許訪問(wèn)通過(guò)S/MIME封裝所保護(hù)的內(nèi)容。安全標(biāo)簽可以用于其他用途諸如路由選擇信息的來(lái)源。這些標(biāo)簽通常描述了分等級(jí)的若干級(jí)別（。秘密的”，“機(jī)密的”，“受限制的”等等）或者這些標(biāo)簽是基于角色的，描述哪種人可以看到

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

54、igned或application/pkcs7-mime簽名結(jié)構(gòu)。    采用這兩種簽名用的muhipart/signed的三重隱蔽包裝報(bào)文的格式是    第八步 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    這里；%一這些行表示計(jì)算內(nèi)部簽名1=這些行表示在第5步被加密，加密的結(jié)果是不透明的，是EnvelopedData塊的一部分。)=這些行表示計(jì)算外部簽名  采用這兩種簽名用的application/pkcs7-mime的三重隱蔽包裝報(bào)文的格式是  第八步 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塊，不僅是無(wú)法理解的，而且包含第2步中用ASN.1編碼的結(jié)果以及控制信息。    I=這些行表示在第5步被加密被加密的結(jié)果是無(wú)法理解的，是EnvelopedData塊的一部分。    )=這些行表示計(jì)算外部簽

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

65、#160;  任何SignedData對(duì)象的簽名屬性可能包含安全標(biāo)簽。在內(nèi)部簽名、或在外部簽名、或在這兩種簽名中都可能含有安全標(biāo)簽屬性。    內(nèi)部安全標(biāo)簽用來(lái)確定對(duì)與初始的明文內(nèi)容有關(guān)的訪問(wèn)控制。內(nèi)部簽名提供鑒別，并以密碼的方式保護(hù)位于內(nèi)部主體的最初簽名者的安全標(biāo)簽的完整性。這種策略便于轉(zhuǎn)發(fā)報(bào)文，因?yàn)樽畛鹾灻叩陌踩珮?biāo)簽被包含在可以被轉(zhuǎn)發(fā)給第三方的SignedData塊中，使第三方可以驗(yàn)證包含內(nèi)部安全標(biāo)簽的內(nèi)部簽名。機(jī)密性安全服務(wù)也可用于內(nèi)部安全標(biāo)簽，方法是加密EnvelopedData塊中的整個(gè)內(nèi)部Signed-Data塊   &

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

67、部簽名，郵件列表代理將修改已散列的數(shù)據(jù)，來(lái)形成這個(gè)外部簽名在這些情況下，郵件列表代理添加或更新mlExpansionHistory屬性，并記錄下郵件列表代理的處理活動(dòng)，最終添加或替換待分發(fā)報(bào)文上的外部簽名。附錄A（資料性附錄）用ASN1描述的語(yǔ)法定義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密碼報(bào)文語(yǔ)法(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隱藏標(biāo)記模式，-1988語(yǔ)法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;擴(kuò)展安全服務(wù)在本模塊中，“SEQUENCE SIZE (1.