本備忘錄的狀態
本文檔講述了一種Internet社區的Internet標準跟蹤協議，它需要進一步進行討論和建
議以得到改進。請參考最新版的“Internet正式協議標準”(STD1)來獲得本協議的標準化
程度和狀態。本備忘錄的發布不受任何限制。
版權聲明
Copyright(C)TheInternetSociety(1999).

目錄
1緒論 2
1.1說明書概要 2
1.2術語 3
1.3定義 3
2CMS選擇 4
2.1運算法則表示符摘要 4
2.2運算法則表示符摘要 4
2.3運算法則表示符密鑰 4
2.4一般語法 4
2.5簽名信息類型的特征 5
2.6SignerIdentifier的SignerInfo類型 8
2.7ContentEncryptionAlgorithmldentifier 8
3.創建s/mime信息 10
3.1為署名和封裝MIME實體作預備 10
3.2application/pkcs7-mime類型 14
3.4創建署名信息 16
3.5署名和加密 19
3.6創建只認證信息 20
3.7請求注冊 20
3.8識別S/MIME消息 20
4.證書處理 21
4.1產生密鑰對 21
5安全 22
A.ASN.1模型 22
B.參考文獻 26
C.致謝 28

1緒論
S/MIME(安全/多用途網際郵件擴充協議)規定一個一致路徑去發和收安全MIMI數據.基
于流行的網絡MIME標準,S/MIM為電子通訊提供了以下用密碼寫的安全服務:起因(利
用數字簽名),秘密和數據安全(利用加密術)的證實,信息完整性和非批判.S/MIME被傳統
的郵件使用代理商用來給要發的郵件加密碼安全服務,且給收到的郵件解釋用密碼寫的
安全服務.可是S/MIME沒對郵件限制;它可用于任何傳輸MIME數據的機器中,比如
HTTP.同樣的,S/MIME利用基于MIME特征的對象和答應安全信息在混合傳輸系統中被
交換.更多的,S/MIME用于自動信息傳輸代理中,這種代理用密碼安全服務,是不需要人干
涉的,例如在網絡上傳送產生軟件文檔的標簽和傳真信息的加密術.
1.1說明書概要
本文講關于加密碼的簽名和服務于MIME數據密碼術的協議.MIME標準[MIME-規
格]規定了一個關于網絡信息的內容類型一般結構且答應為新的內容類型應用擴充.
這個備忘錄具體說明怎樣產生一個MIME實體部分,這個部分已經根據CMS增強了
密碼功能,CMS源于PKCS#7.本備忘錄也具體說明了MIME類型,此MIME類型能用
來傳輸那些實體部分.同樣本備忘錄也討論怎樣用多部分/有符號MIME類型在
[MIME-安全]說明傳輸S/MIME注釋的消息.本備忘錄也說明了PKCS7的應用-MIME
類型簽名,此MIME類型簽名也用來傳輸S/MIME簽名消息.為了產生S/MIME消
息,S/MIME代理商必須在本備忘錄里追求規范,說明書也一樣有序列在用密碼寫的
消息里.在整個備忘錄里,有要求和建議用來處理接收代理如何控制進來的消息.有部
分要求何建議用來處理發送代理如何產生流出的消息.總的來說,最好的策略是"在呢
收到消息中是自由的而在呢發送消息中是保守的."大多的要求是來控制流入消息
同時多數建議是來產生流出消息.對收方代理和發方代理有不同要求也因為可能有
S/MIME系統用于不同于傳統網絡郵件客戶的軟件.S/MIME能用于任何傳輸MIME
數據的系統中.比如,一種自動化發送一條密碼化消息過程可能完全不能收到一條密
碼化消息.因此,對兩種類型的代理,要求和建議是分別在適當時候列出.
1.2術語
本文中的要害字“必須”，“必須不”，“要求的”，“應該”，“不應該”，“會”，“不會”，
“建議”，“或許”，“可選的”在[MUSTSHOUD]中解釋。
1.3定義
本備忘錄的目的,應用以下定義.
ASN.1:摘要語法符號1,在CCITTX.208中有定義.
證實書:把一個實體的顯聞名字與有數字簽名的公共密鑰幫定的類型.
DER:用于ASN.1顯著的譯成密碼的規則,在CCITTX.509中定義.
7-bit數據:少與998特征長的原文數據線,998中沒有第8bit裝置的特征,也沒有
無效的特征.<CR>和<LF>僅發生在線的最后分隔符<CR><LF>部分.
8-bit數據:數據:少與998特征長的原文數據線,998中沒有第8bit裝置的特征,
也沒有無效的特征.<CR>和<LF>僅發生在線的最后分隔符<CR><LF>部分.
二元數據:任意的數據.
傳遞編碼:對數據反復翻譯那么8-bit或二元數據可以經過一條只有7-bit數據傳
輸的通道發送.
接方代理:解釋和處理S/MIMECMS對象的軟件,MIME實體部分包含CMS對象,
或者二者都包括.
發送發代理:產生S/MIMECMS對象的軟件,MIME實體部分包含CMS對象或者
二者都包括.
S/MIME代理:軟件用者是一個接方代理,也是個發送方代理,或者二者都是.
1.4優先實際應用S/MIME的兼容性
版本3,0的S/MIME代理商應該盡力與版本2,0的代理商協同工作.版本2.0代
理商經RFC2315改進在RFC2311中有說明.RFC2311關于S/MIME發展也有一段
歷史信息.
2CMS選擇
CMS答應在內容和運算法則支持中有廣泛的選擇.為了在所有的S/MIME執行中取
得協同工作的基本水平,這部分提出許多有支持力的要求和建議.[CMS]提供了關于
密碼化的運算法則用法的額外具體資料.
2.1運算法則表示符摘要
發送方和接收方代理商必須支持SHA-1[SHA1].接收方代理應該支持md5[MD5]實
現后面與MD5-摘要版本2.0S/MIME簽名數據對象相兼容的目的.
2.2運算法則表示符摘要
發送方和接收方代理商必須支持在[DSS]定義的符號.運算法則參數必須缺少的(不
能當無效譯碼).接收方代理應該支持加密術,在[PKCS-1]里有定義.發送方代理應
該支持加密術.流出的消息簽有用戶的私人密鑰.私人密鑰的大小是在密鑰產生時決
定的.版本2.0S/MIME客戶記錄只能證實用在加密術算法準則的數字簽名.
2.3運算法則表示符密鑰
發送和接收代理商必須支持DH,在[DH]有定義.接收代理商應該支持加密術.引入
的加密消息包含對稱密鑰,它可以用用戶的私人密鑰來解釋明白.私人密鑰的大小時在密鑰
產生時決定的.發送代理商應該支持加密術.版本2,0S/MIME客戶記錄只能解釋用在加密
術運算法則的內容加密密鑰中.
2.4一般語法
CMS定義了多樣內容的類型.這里面,只有有符號數據和信封數據內容類型目前
是用在S/MIME.
2.4.1數據內容類型
發送方代理必須用數據ID類型標簽符來說明已應用了安全服務的消息內容.比如,
當把一個數字簽名應用到MIME數據時,CMS的有符號數據、encapContentInfo、eContentType
必須包含數據ID對象的表示符且MIME內容必須被保存在有字符串八位字節的符號數據、
encapContentInfo、eContent里(除非發送代理商正使用多個部分或多個符號,在這種情況下
eContent事缺少的,本文的3.4.3節有說明).舉一個另外例子,當應用加密術到MIME數據時,
CMS的信封數據、加密內容信息、內容類型必須包含數據ID對象的標識符和加密的MIME
內容必須被存在字符串八位的信封數據、加密的內容信息、加密的內容里。
2.4.2符號數據內容類型
發送方代理必須使用符號數據內容類型把數字簽名應用到消息中,或者在沒有
簽名信息的退化例子里把數字簽名應用到證實的傳遞中.
2.4.3信封數據內容類型
內容類型被用來對消息的私人保護.一個發送方需要用此服務得到開啟雙方
信件的公共密鑰.內容類型不用提供簽名.
2.5簽名信息類型的特征
簽名信息類型答應把有符號的與沒符號的屬性,隨同簽名包括在一塊.接收方
代理必須能夠處理零或者這種在這里列出的符號屬性情況.發送方代理應該產生下列每個
S/MIME消息的符號屬性情況:
- 簽名時間(在本文2.5.1節)
- sMIME容量(在本文2.5.2節)
- sMIMEncryptionKeyPReference(在本文2.5.3節)
更進一步說,接收方代理應該能處理零和一種簽名證實屬性的符號屬性的情況(在
[ESS]第五節).發送方代理應該產生在每個S/MIME消息里簽名證實有符號屬性情
況.另外的屬性和值可能在將來被定義.接收方代理應該處理在美麗風格里沒被承
認的屬性和值.發送代理包括沒列在這里的符號屬性應該顯示給用戶,從而使用戶
知道所有有符號的數據.
2.5.1 簽名時間的屬性
簽名時間屬性用來傳達簽名消息的時間.除非有可信任時間標印服務器,否則簽名時
間將很有可能被消息遞交方產生,因此和遞交方有相同的信任程度.發送方代理商
必須通過2049年作為UTCTime把時間簽名譯成密碼;簽名時間在2050年或者以后
必須譯成GeneralizedTime密碼.當UTCTime選擇被使用時,S/MIME代理器必須說
明以下年限:
假如年限大于或等于50,那年代就認為是19YY;假如年限是小于50,那年代就認為
是20YY.
2.5.2SMIME容量屬性
SMIME容量屬性包括簽名運算法則(比如"有RSAD的sha1加密術"),對稱運算法則
(比如"DES-EDE3-CBC"),主要密碼術的運算法則(比如RSA加密術).它也包括一種
適用于簽名日期的無運算法則性能.SMIME性能是靈活的和可擴展的,這樣的話,在
將來,比如對證書另外性能和參數選擇進行鑒別,這種功能能在不導致當前客戶程序
停止的情況下加進去.如當面的,SMIME容量屬性必須是一個簽名屬性;它不應該是
UnsignedAttribute.CMS把SignedAttributes定義成一套屬性.在簽名信息里
SignedAttributes必須不包括SMIMECapabilities屬性的多種情況.CMS為ASN.1排
序結構定義了屬性包括一套屬性值的附加值.一個SMIMECapabilities屬性必須僅
僅包括屬性值的單個情況.不必有零或在一套屬性值中附加值中屬性值的多種情
況.SMIMECapabilites屬性的語義具體說明了關于SMIMECapabilites能支持的客戶
程序的多部分列表.客戶程序不必列出所有它支持的性能,也不應該列出,這樣可以
使得性能列表不會變的太長.在一個SMIMECapabilities屬性里,0ID根據它們的優
先順序列出來,但邏輯上應該根據它們的類別分別列出(簽名運算法則,均衡運算法
則,加密密鑰運算法則,等.)SMIMECapabilities屬性的結構有利于簡單的表格查詢和
為了測定儀器的二進制比較.例如,有DESEDE3CBCSMIMECapability的
DER-encoding必須不管執行結果一致同仁的譯成編碼.在均衡運算法則的情況
下,0ID的相關參數必須具體說明所有必需的參數來區分二種運算法則相同情況.
例如,除了密鑰長度外,RC5的許多圓圈和塊大小必須被具體說明.有一個
0ID(S/MIME用到的0ID)是重點維護的,它是從備忘錄里分離出來的.這個0ID表是
由在<http://www.imc.org/ietf-smime/oids.Html>IMC來維護的注重所有有關聯
的0ID必須執行在本文A節提到的運算法則.符合運算法則的0ID應該在實際運用
時使用相同的0ID,除了對0ID來說運算法則的用法是不明確的.例如,在初期的草
案中,rsaEncryption是不明確的,因為它可以指簽名運算法則也可以指加密密鑰法則.
在0ID不明確的情況下,需要維護者對已登記的SMIMECapabilities表根據運算法則
的類型使用0ID作出正確的判定.新的0ID必須答應smimeCapabilities的0ID來
滿足使用其他的0ID.已登記的SMIMECapabilities表具體說明了0ID需要的參數,
在變量長度密碼對稱的情況下,多數主要密鑰加長.結果對非凡的0ID來說沒有可
區分的參數,那參數必須省略且不能被譯成為無效.SMIMECapabilibies屬性的額外
值在以后可被定義.接收代理方必須處理一個SMIMECapabilities對象,它擁有在優
美風格里不被承認的值.
2.5.3密碼密鑰的優先屬性
密碼密鑰優先屬性答應簽名者明確說明簽名者的證書有簽名者的優先密碼密鑰.
設計這屬性來增強為了混合那些對加密和簽名用不同的密鑰的客戶的行為能力.用
這種屬性來傳送任何個列在證書里的屬性,這種證書應該用來給以后加密的信息加
密一個回話密鑰.假如存在,SMIMEEncryptionKeyPreference屬性必須是個
SignedAttribute;它不必是個UnsignedAttribute.CMS定義SignedAttributes為一類屬
性.簽名信息里的SignedAttributes不必包括SMIMEEncryptionKeyPreference屬性
的多種情況.CMS為屬性定義了ASN.1的排列方式用來包括.屬性值的一類額外值.
SMIMEEncryptionKeyPreference的屬性必須僅僅包含屬性值的單個情況.不必有零
或存在屬性值里的一類額外值多種情況.發送代理商應該包含一類證書里的參考
證書,假如此屬性被使用那這類證書還包含簽名信息.假如證書先前對接收代理來
說是可利用的那它可以被省略.假如一般用法或者先前的加密證書與用來消息簽
名的證書不一樣,那發送代理應該使用這個屬性.假如消息上的簽名是有效的和簽
名時間大于目前存儲的值,那么接收代理應該存儲優先的數據.(同樣對
SMIMECapabilities,應該檢查時鐘skew,假如skew太大就不使用數據.)如可能接收
代理應該尊重發送者的加密密鑰的優先選擇屬性.但這尊重僅僅是一種優先選擇,
接收代理在回答發送者時可使用任何有效的證書.
2.5.3.1治理證書中接收密鑰的選擇
為了確定在發送將來CMSenvelopedData消息給一個非凡的接收器時的證書治理
密鑰,應該遵從下列步驟:
- 假如在一個從預期的接收器收到簽名數據對象中發現一個
SMIMEEncryptionKeyPreference的屬性,這可識別x.509證書,此證書應該用來作為
接收者的x.509密鑰治理證書.
- 假如沒能在預期的接收器收到數據對象中發現一個SMIMEEncryptionKeyPreference
的屬性,那應該用這類x.509證書來搜尋與x.509相同題目的證書,以此作為可用作
密鑰治理的簽名x.509證書.
- 或者用一些其他方法來確定用戶的治理密鑰.假如一個x.509密鑰治理證書沒找到,
那么密碼術不能處理消息的簽名.假如找到多個x.509密鑰治理證書,那么S/MIME
代理可以在它們之間任意選擇.
2.6SignerIdentifier的SignerInfo類型
版本3.0的S/MIME要求使用版本1.0的SignerInfo,這是IssuerAndSeriaINumber選
擇必須用作SignerIdentifier.
2.7ContentEncryptionAlgorithmldentifier
收發代理必須支持用DESEDE3CBC來加密和解密,以下稱
為"tr一致的40bit大小的密鑰來加密,以下成為"RC2/40".
2.7.1確定用哪種加密方法
當一個發送代理產生一條加密消息時,它必須同時確定用哪類的加密術.決定過程
包含使用存儲在容量表里的信息,此表包含從接收器收到的消息,也包含不相連的
信息比如私人協議,用戶參數選擇,合法限制等等.2.5節說明一種發送代理能隨意定
義的方法,其它的例如它的優先順序解密性能.以下方法用來處理和記憶在引入簽
名消息里的加密性能屬性,這種方法應該使用.
- 假如接收代理還沒為發送方的公共密鑰創立個接收表,那在校驗了引入的簽名消息
和檢查了時間標志后,接收代理應該創立個起碼能容下簽名時間和勻稱性能的表.
- 假如這樣的表已經存在,那接收代理應該校驗引入消息的簽名時間是否大于存儲在
表里的簽名時間且簽名是否有效.假如是,那接收代理應該同時更新表里的簽名時
間和性能.簽名時間的值是個離將來很遠的值,接收能力列在簽名不能被校驗的消
息里,它不必被接收.存儲性能表應該將來可用來產生消息.發送一條消息前,發送代
理必須決定是否對消息里的非凡數據使用不牢固的加密術.假如發送代理確定這不
牢固的加密術對此數據來說是不可接收的,那發送代理不必使用例如RC2/40的不牢
固加密術.是否使用弱加密術不用考慮其它部分使用的加密算法.2.7.2.1節到
2.7.2.4節寫了一個發送代理決定選哪類加密術應用到消息中去.這些規則是安排好
的,所有發送代理應該根據安排好的規則來決定.
2.7.1.1規則1:公開接收容量
假如接收代理已經從他打算加密的消息接收器里收到了一容量,那發送代理應該通
過選在表里的第一個容量來使用那信息,因為發送代理知道怎樣加密.假如代理很
希望接收方能解密消息的話,那發送代理應該表里的其中一個容量.
2.7.1.2規則2:沒公開接收容量,公開使用加密
假如:
- 發送代理不知接收方的加密容量;
- 發送代理已從接收方收到不止一條消息;
- 從接收方收到的最后的加密消息里有可信任的簽名.
那流出的消息應該使用相同的加密運算法則,這被用在最后的簽名和從接收方收到
的加密消息.
2.7.1.3規則3:沒公開的容量,不知的S/MIME版本
假如:
- 發送代理不知接收方的加密容量;
- 發送代理不知接收方的S/MIME版本;
那發送代理應該使用tripleDES因為它是一條更嚴格的運算法則且是S/MIMEV3.0
所要求的.假如這一步發送代理不選擇使用tripleDES,那它必須使用RC2/40.
2.7.2選擇弱加密術
像所有運算法則都用到40bit的密鑰一樣,RC2/40被許多人當作是弱加密術.一個由
人控制的發送代理應該答應寄件人去決定使用RC2/40發送數據的風險或者在發送
數據前決定用相似的弱加密運算法則，或者可能答應他使用更嚴格的加密術比如
tripleDES．
２.7.3多個收接人
假如發送代理是給一組接受人構成加密消息,這里說的接收方的加密容量是沒有交
迭的.那么發送代理被迫發送多條消息.應該注重假如發送代理選擇的發送嚴格加
密的消息和用弱加密法則加密的同條消息的話,查看信道的人可能會發現用嚴格加
密的消息的內容被弱加密的消息所簡化.
—————周夢齡部分

—————岑斌部分
3.創建s/mime信息
這部分描述了s/mime信息的格式和他們是怎樣創建的。s/mime信息是mime體和cmc對象
的結合體。多種mime種類和cms對象被用到，保證安全的數據總是規范的mime實體。
Mime實體和諸如認證，簽名算法等其它數據，提供給cms處理程序（此程序生成cms實體）。
Cms對象最后被包裝在mime中。對s/mime加強的安全服務[ess]文件提供怎樣s/mime信息
是如何嵌套，保證安全的。Ess提供一個說明如何使用適合于署名的multipart/signed和
application/pkcs7來建立三重包裝的s/mime信息。
s/mime提供一種郵件(只含數據)的格式,多種署名數據的格式，多種署名和郵件數據的格式，
為了適合多種環境，多種格式是需要的，非凡對于署名信息來說。在這些信息種選擇合適的
格式亦有描述。
這部分的讀者期望能理解[MIME-SPEC]和[MIME-SECURE]中描述的MIME
3.1為署名和封裝MIME實體作預備
s/mime用于MIME實體的安全性,一個MIME實體可能是一個信息的一個部分，或者是數據
的整個部分。MIME體是包含MIME頭和MIME實體，但不包含RFC822頭。注重：s/mime
能在保護MIME實體的安全方面的應用，除了應用于internet郵件，還應用于應用程序。被
保證安全的MIME實體部分在本部分認為是在內部MIME，也就是說，這是可能更大的
MIME信息的最深層的部分。把外部MIME實體處理成CMS對象在3.23.4和其他的章節
中進行描述。
預備MIME實體的過程在[MIME-SPEC]中描述，在簽名時，相同的過程也會使用，只是增
加了些附加約束條件，從[MIME-SPEC]的角度來看，這個過程的描述在這里是重復的，但
讀者可能會想從這篇文檔中獲得附加的過程。這個章節同時也描述了附加的需要。
單一的過程在創建用于署名，封裝，或署名和封裝并舉的MIME實體中。同時我們也要采
取一些步驟來防止在郵件傳輸過程中可能會出現的問題，這在使用multipart/signed各式的
clear-signing時非凡重要的。同時我們也建議當時用在封裝數據，或署名，封裝數據上時，
要采取一些額外的步驟，以使數據在不改變的情況下傳輸到各個環境。
這些步驟與其說是說明性的還不如說是描述性的，只要結果是一樣的無論是用何種過程都是
一樣的。
第一步：根據本地的規則，預備MIME實體。
第二步：MIME實體的子部分被轉換成規范的形式。
第三步：對MIME實體的子部分運用正確的傳輸編碼。
當一條s/mime信息收到時，信息的安全服務首先被處理，其結果是MIME實體，MIME實
體會被傳到有處理MIME能力的用戶代理，在那里其會被進一步解碼，并被傳輸到用戶端。
3.1.1規范化
每一個MIME實體必須轉化為一種規范形式，這種形式能在創建署名，和確認署名的環境
能唯一，無二義性的表示。MIME實體必須格式化，使之適合于封裝和署名。
規范化的確切細節依靠實體的MIME類型及其子類，這在這里不會被闡述。
作為替代，會討論特定MIME類型的標準。例如，text/plain類型的規范化和audio/basic的
規范化是不同的。除了文本類型，大多數類型不管計算平臺和環境（能考慮他們的規范表示）
的差異只有一種表示?？偟膩碚f，規范化會被發送代理的非安全部分而不是S/MIME實現
執行。
文本最平常和重要的規范化在不同環境內的表示是不同的。主要類型text的MIME實體必
須把他們的行結束和字符規范化。行結束必為<cr><lf>對，字符集必是注冊的字符集[charsets].
規范化的細節在[MIME-SPEC]中具體描述，選擇的字符集應該在字符集參數中命名，以接
受代理能無二意的得出其使用的字符集。
非凡要指出的是，一些字符集如[ISO-2022]對不同的字符有不同的表示。當預備要署名的文
本時，為了表示的規范，必須使用特定字符集。
3.1.2傳輸編碼
當產生以下任何的安全MIME實體（除使用multipart/signed格式的署名），傳輸編碼時不需
要的，S/MIME實現必須能處理二進制MIME對象。假如無內容傳輸編碼頭，傳輸編碼必須
是7位的。
然而，S/MIME的實現應該使用在3.1.3中描述適合所有安全的MIME實體的傳輸編碼。保
證只有7位的MIME實體（即使是不向傳輸環節暴露的封裝數據也被編碼成7位的）原因
是答應MIME實體能在不被篡改的情況下，在任何環境中處理。例如，一個信任的網關會
去掉信息的封裝，而非署名，然后繼續傳輸數據至接受端，所以他們能直接確認簽名。假如
在諸如帶有單獨郵件網關的廣域網等非8位clean站點內部傳輸，除非原始的MIME實體是
7位數據，確認署名江市不可能的。
3．1．3署名的傳輸編碼是使用Multi/signed的
假如一個multipart/signed實體曾經傳輸通過標準的internet　SMTP的下層結構或其他被約
束為7位文檔的傳輸體系，那么它一定是被編碼成7位的文本。7位數據的MIME實體無需
傳輸編碼。8位文檔的實體和二進制數據能用打印字符和base-64傳輸編碼進行編碼。
7位編碼的首要原因是Internet郵件傳輸的下層結構，不能保證8位數據或二進制數據。即
使很多傳輸段的下層結構能處理8位和二進制數據，但有時候要知道數據的傳輸路徑是8
位clear的是不可能的。假如8位的郵件信息遭遇不能傳輸8位或二進制數據的信息傳輸代
理。代理有三種選擇，但無論哪一種對于clear-signed信息是不可接受的。
1． 代理改變傳輸編碼，它是署名無效
2． 代理能傳輸數據，但很可能破壞第8位數據，這同樣使署名無效。
3． 代理返回數據該給發送者。
[MIME-SECURE]禁止代理改變multipart/signed信息第一部分的編碼，假如不能傳輸二
進制和8位數據的兼容的代理碰到第一部分是8位或二進制數據，它可能要把信息返回
該發送端。
3．1．4簡單的規范MIME實體
這個例子現實一個完全傳輸編碼的multipart/mixed信息，這個例子包含一個文本部分和
附件，這個簡單信息文本包含非US-ASCII字符，它必須進行傳輸編碼。這里雖然沒顯示，
但每一行都是以<CR><LF>結束，MIME頭，文本，傳輸編碼部分必須以<CR><LF>結束.
我們來看一下非S/MIME信息的例子：
Content-Type:multipart/mixed;boundary=bar

--bar
Content-Type:text/plain;charset=iso-8859-1
Content-Transfer-Encoding:quoted-printable

=A1HolaMichael!

HowdoyoulikethenewS/MIMEspecification?

Iagree.It'sgenerallyagoodideatoencodelinesthatbeginwith
From=20becausesomemailtransportagentswillinserta
greater-than(>)sign,thusinvalidatingthesignature.

Also,insomecasesitmightbedesirabletoencodeany=20
trailingwhitespacethatoccursonlinesinordertoensure=20
thatthemessagesignatureisnotinvalidatedwhenpassing=20
agatewaythatmodifiessUChwhitespace(likeBITNET).=20

--bar
Content-Type:image/jpeg
Content-Transfer-Encoding:base64

iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
HOxEa44b+EI=

--bar--

3.2application/pkcs7-mime類型
application/pkcs7-mime類型被應用于傳送包含封裝數據和署名數據的多種CMS對象。
構造這些信息的細節在接下來的部分中描述，這部分描述的是application/pkcs7-mime類型
的總體特征。被傳輸的CMS對象往往包含一個MIME實體，假如ecounttype是id-data那么
實體應像3.1部分描述的那樣進行預備。當ecounttype包含不同的值時，其他的內容可能也
要傳輸。要想獲得這種例子和簽名收條，請參見[ESS]。
因為CMS對象是二進制對象，在大多數情況下，base-64傳輸編碼是正確的，非凡當時用在
SMTP傳輸中，使用的傳輸編碼依靠發送對象的傳送設備，而非MIME類型的特點。
值得注重的是這里的討論指CMS對象或外部MIME實體的傳輸編碼。它區別于由CMS對
象保證安全性的MIME實體（即是內部對象，在3.1部分描述）的傳輸編碼，同樣，和他也
沒有聯系。因為Application/pkcs-7MIME對象由多種種類，發送代理應盡力使接受代理不強
制對對象進行ASN.1解碼就知道對象的內容，所有APPLICATION/PKCS7-MIME對象的
MIME頭應包含任選的SMIMETYPE參數，這在以后的章節中會闡述。
3．2．1名稱和文件名稱參數
對于APPLICATION/PKCS7-MIME來說，為了和舊系統的兼容，發送代理應發出任選
的"NAME"參數給CONTENT-TYPE域，發送代理也應把FILENAME參數發出任選的內容
描述域[CONTDISP]，假如發送方發出了以上參數，他們的值應是一個有著準確擴展名的文
件的名稱
MIMETypeFileExtension

Application/pkcs7-mime(signedData,.p7m
envelopedData)

Application/pkcs7-mime(degenerate.p7c
signedData"certs-only"message)

Application/pkcs7-signature.p7s
另外，文件名稱應被限制在帶有三個擴展名和8個字符以內的范圍內，8個字符的文件名可
以是任何的能唯一表示的名字，文件名'SMIME'應使用在表示MIME實體和S/MIME相聯
系。
包含文件名有兩個作用：它能把S/MIME的使用簡單化為磁盤上的文件，同時，他亦能轉
換種類信息，以使之能通過網關。當一個APPLICATION/PKCS-7MIME類別的MIME實體
到達一個沒有S/MIME專門的知識的網關時，它可能會默認實體的MIME類型是
APPLICATION/OCTET-STREAM類型，并把它當成一般的附件，這樣就損失了類型信息，
然而，附件的文件名經常會被帶過網關。這經常答應接收系統確定正確的應用來把附件卸下
來交給單獨的S/MIME處理應用。值得注重的是：這個機制是為了在某些環境中方便實現
而提供的，正確的S/MIME實現以使用MIME類型，而非依靠文件的擴展。
3．2．2S/MIME類型的參數
APPLICATION/PKCS7-MIME內容類型定義了任選的'SMIME-TYPE'參數，參數的目的是轉
化成和包含內容的信息一起的安全性的細節，這個備忘錄定義了以下的SMIME-TYPE.
NameSecurityInnerContent

enveloped-dataEnvelopedDataid-data

signed-dataSignedDataid-data

certs-onlySignedDatanone

為了在未來實現一致性，當分配一個新的SMIME參數時應遵守以下要點：
1：如內容要進行署名和加密，SMIME-TYPE的兩個值應被賦
為"SIGNED-*","ENCRYPTED"。假如一個操作被賦值，那么其可被忽略。這樣，即使只
有"CERTS-ONLY"被署名，“SIGNED-”也會被忽視。
2．要賦給內容OID一個通用的字符串，當MIME是內部內容，我們使用“DATA”作為ID-
數據內容OID。
3．假如不賦予通用字符串，那么建議使用OID.<OID>的通用字符串（如
"OID.1.3.6.1.5.5.7.6.1"表示DES40）。
3.3創建只被封裝的信息
這部分描述不署名封裝的MIME實體的格式。這一點很重要：發送封裝但未署名的信息部
提供數據的完整性服務。它可以用密碼進行更替，這樣信息雖然是有效的，但其意義可能以
改變了。
第一步：依3.1節預備封裝MIME實體。
第二步：MIME實體和其他必需數據處理成封裝數據的CMS對象，除了為每一個接收者加
密內容加密鑰匙的拷貝，內容加密鑰匙的拷貝亦應為創作者加密，保存在封裝數據中（見
CMS第6節）
第三步：把CMS對象插入APPLICATION/PKCS-MIMEMIME實體中。只封裝數據的
SMIME-TYPE參數是“封裝數據”，這種信息的文件擴展是'.P7M'.
例舉一個簡單的消息：
Content-Type:application/pkcs7-mime;smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding:base64
Content-Disposition:attachment;filename=smime.p7m

rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V
3.4創建署名信息
在S/MIME中定義的署名信息有兩種格式：APPLICATION/PKCS7-MIME和署名數據，
以及MULTIPART/SIGNED;總的來說，MULTIPART/SIGNED格式最適合于發送，接受代理
應能處理以上兩種。
3．4．1為署名信息選擇格式
因為依靠接受者的能力和同沒有可以瀏覽信息的S/MIME軟件的重要性相比較更重要的接
收端認證署名的能力，當要選擇特定的只署名格式，沒有即快又果斷的規則。
使用MULTIPART/SIGNED格式的簽名信息無論接收端有沒有安裝S/MIME軟件，總能瀏覽
信息。他們被看成使用MIME本地用戶代理或信息被網關轉發。在這篇文章中，‘被看到’
意思是說本質上處理信息的能力就像處理非署名信息，當然，信息也可包含其他MIME結
構。
假如接受端有S/MIME能力，那其能看到使用署名數據格式的署名信息。然而，假如其有
S/MIME能力且在傳輸構成中信息不被改變，信息總是可以被確認的。
3．4．2使用APPLICATION/PKCS7-MIME和署名數據的署名
署名格式使用APPLICATION/PKCS7-MIMEMIME類型，創建這種格式的步驟如下：
第一步：依照,3.1節預備MIME實體。
第二步：MIME實體和其它需要的數據處理成署名數據類型CMS對象。
第三步：把CMS對象插入APPLICATION/PKCS7-MIMEMIME實體.
使用APPLICATION/PKCS7-MIME的SMIME-TYPE參數和署名數據是“署名數據”，文件
擴展是'.P7M'。
一個簡單的例子：
Content-Type:application/pkcs7-mime;smime-type=signed-data;
name=smime.p7m
Content-Transfer-Encoding:base64
Content-Disposition:attachment;filename=smime.p7m

567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
6YT64V0GhIGfHfQbnj75
3．4．3使用MULTIPART/SIGNED格式的署名
這種格式是CLEANIGN-SIGNING格式。沒有S/MIME或CMS處理能力的接受端能看到信
息，他使用了描述在[MIME-SECURE]中的MULTIPART/SIGNEDMIME類型。
MULTIPART/SIGNEDMIME類型有兩部分：第一部分包含署名的MIME實體，第二部分包
含分離的署名CMS署名數據對象，在其中,ENCAPCONTENTINFOECONTENT域時空的。
3．4．3.1APPLICATION/PKCS7-MIME類型
這種MIME類型總是包含單個的署名數據類型的CMS對象。署名數據的
ENCAPCONTENTINFOECONTENT域必是空的。SIGNERINFOS域包含MIME實體的署名。
使用APPLICATION/PKCS署名的只署名信息的文件擴展是‘.P7S’。
3．4．3．2創建MULTIPART/SIGNED信息
第一步：依照3.1節預備要署名的MIME實體，非凡注重CLEAN_SIGNING。
第二步：為了獲得署名數據對象(其ENCAPCONTENTINFOECONTENTZ域是空的)，把
MIME實體提供給CMS處理。
第三步：把MIME實體插入MULTIPART/SIGNED信息的首部，MULTIPART/SIGNED信息
沒有經過處理，和在3.1節描述的不一樣。
第四步：轉換編碼應用于分離的署名CMS署名數據對象，他亦會被插入于
APPLICATION/PKCS署名的MIME實體
第五步：MULTIPART/SIGNED實體的第二部分應插入APPLICATION/PKCS7-SIGNATURE
的MIME實體
MULTIPART/SIGNED內容類型有兩個參數：協議參數和MICALG參數。
協議參數必是application/pkcs7-signature，注重因為MIME要求：在參數中的‘/’
字符必用引號，在協議參數的旁邊需要引號。
當署名被確認后，MICALG參數答應單通處理。MICALG參數的值依靠用在消
息完整性檢測計算的消息數字計算法則。假如使用了多個消息數字算法，他們必
須每個[MIME-SECURE]用逗號進行分割。在MICALG參數的值應依據以下：
AlgorithmValue
used

MD5md5
SHA-1sha1
Anyotherunknown
(歷史標注：一些早期的S/MIME實現程序發送和期望用于MICALG參數
的"RSA-MD5","RSA-SHA1".)
接受代理應能從他們不熟悉的MICALG參數中恢復。
3.4.3.3簡單的MULTIPART/SIGNED消息
Content-Type:multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1;boundary=boundary42

--boundary42
Content-Type:text/plain

Thisisaclear-signedmessage.

--boundary42
Content-Type:application/pkcs7-signature;name=smime.p7s
Content-Transfer-Encoding:base64
Content-Disposition:attachment;filename=smime.p7s

ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756

--boundary42--
3.5署名和加密
為了獲得署名和封裝，會嵌套只署名或只加密的格式。因為以上的格式是所有MIME實體，
同時他們也是安全的MIME實體，所以這是答應的。
在接受端計算機的合理能力范圍內，S/MIME實現程序必能接受和處理任意的S/MIME嵌套。
對一個信息首先進行署名或封裝是可能的，這是依靠實現程序和用戶的選擇。當署名優先時，
在封裝中署名會被隱藏。當封裝優先時，署名會被暴露，但這使在不移去封裝的情況下確認
署名。這在自動署名認證的環境中是有用的，因為這時認證書明無需私匙。
選擇首先署名還是首先加密有兩種不同的安全分叉。首先加密，然后署名的數據的接受者能
不改變加密的數據塊，但不能確定署名者和沒加密的信息內容的關系。首先署名后加密的信
息接受者能確認署名信息本身沒改變，但小心的攻擊者能改變加密數據的沒有認證的部分
3.6創建只認證信息
只有證書的消息或MIME實體用于傳輸證書，諸如對注冊請求地響應。這種格式亦能被用
于傳輸CRL
第一步：把證書變換成適合產生署名數據的CMS對象的CMS產生過程。署名數據的
encapcontentInfoeContent域必須空缺，singerInfos域亦必須空缺。
第二步：CMS署名數據對象包含在application/pkcs7-mimeMIME實體中。
Certs_only信息的Smime-type參數是"certs-only"的。文件的擴展名為“.p7c”。

—————岑斌部分
—————湯瓊部分
3.7請求注冊
給消息簽名的發送代理必須擁有簽名證書，這樣，接收代理才能驗證簽名。取得證書通
常有幾種方法，如通過與證書機構交流或通過硬件記號或磁盤等等來獲得證書。
S/MIMEv2給出了一種使用application/pkcs10主體部分來向證書機構注冊公鑰的方
法。TheIETF'sPKIXWorkingGroup則提供了請求證書的另外一種方法；然而，在寫本備忘
錄時該方法還沒完成。S/MIMEv3沒有具體指出怎樣去請求證書，而是治理每一個發送代
理已經有的證書治理標準由IETF制定。
3.8識別S/MIME消息
因為S/MIME考慮到與非S/MIME環境的互操作性，采用了幾種不同的機制傳送信息，
這使得S/MIME消息的識別有了一些困難。下面表格列出了判定一條消息是否是S/MIME
消息的標準。符合下表的消息就被認為是S/MIME消息。
列表中的文件后綴來自內容類型報頭的"name"參數，或者來自內容部分報頭的
"filename"參數。給出文件后綴的這些參數沒有作為參數部分列在下表中。
MIMEtype:application/pkcs7-mime
parameters:any
filesuffix:any
MIMEtype:multipart/signed
parameters:protocol="application/pkcs7-signature"
filesuffix:any
MIMEtype:application/octet-stream
parameters:any
filesuffix:p7m,p7s,p7c

4.證書處理
接受代理為了訪問數字信封的收件人的證書，必須提供一些證書檢索機制。本備忘錄不
涉及S/MIME代理怎樣處理證書，只是說明在證書被確認有效或被否定后，他們作什么。
S/MIME證書事項在[CERT3]中有說明。
對于S/MIME的初始配置，用戶代理至少能產生一條消息給指定的收件人，要求他的
簽署證書返回消息。接收代理和發送代也應該提供容許用戶為通信者“存儲和保護”證書，
這樣就能夠保證他們以后的檢索。
4.1產生密鑰對
假如S/MIME需要產生密鑰對，那么，S/MIME代理商或相關的執行部門必須能夠為用
戶生成DH和DSS公鑰/私鑰對。每對密鑰必須由好的非確定性的隨機輸入源產生，而且，
私鑰必須以某種安全的方式保護起來。
假如S/MIME代理需要生成密鑰對，那么該S/MIME代理或相關的執行部門應該生成
RSA密鑰對。
用戶代理應該生成至少768位長度的RSA密鑰對。用戶代理不應該產生少于512位的
RSA密鑰對。生成的密鑰長于1024位將會使一些老的S/MIME接收代理不能驗證簽名，但
具有更好的安全性，因此是有價值的。接收代理應該能驗證用任何超過512位的密鑰的簽名。
在美國一些代理為了獲得更有利的出口許可而選擇生成512位密鑰。然而，用512位密鑰加
密在很多人士看來是不安全的。實現者應該注重到個人可聯合使用多對密鑰。例如，一對密
鑰可用來保證機密性，而另一對密鑰則用來作認證。
5安全
該整編的備忘錄（全用來）討論安全問題。在其他部分沒有涉及的安全事項包括：
大多數譯解密碼者都認為40位加密是脆弱的。在S/MIME中使用脆弱的加密方法和發
送明文一樣不具有實際的安全性。然而，S/MIME的其他特征，如tripleDES規范以及宣
稱更強的加密能力和對方交流的能力，答應發送者生成用強加密處理的消息。除
非別無選擇，否則絕不推薦使用弱加密。假如可行，發送和接收代理應該通知發
送者和接收者消息的相關加密長度。
對大多數軟件或人來說，評估消息的價值是不可能的。而且，大多數軟件或人來說，評
估用非凡長度的密鑰加密來加密消息的代價同樣是不可能的。而且，假如收件人不能解碼消
息，確定一個失敗的解密也是相當困難的。因此，在不同的密鑰長度作選擇也是不可能的。
然而，所做的決定總是基于這些標準，因而本備忘錄給出了在選擇算法時使用那些評估的框
架。
假如，發送代理用不同長度的加密發送消息，監聽通信信道的黑客就能夠通過解密弱加
密的消息確定用強加密的消息。換句話說，發送者應該和不發送明文一樣不發送弱加密的消
息。
假如也不使用認證，密文的修改將能不被識別，就如發送被封裝的數據而沒有把他裝入
簽名的信封中或者沒有在其中包含簽名信息一樣。
A.ASN.1模型
SecureMimeMessageV3
{iso(1)member-body(2)us(840)rsadsi(113549)
pkcs(1)pkcs-9(9)smime(16)modules(0)smime(4)}

DEFINITIONSIMPLICITTAGS::=
BEGIN
IMPORTS
--CryptographicMessageSyntax
SubjectKeyIdentifier,IssuerAndSerialNumber,
RecipientKeyIdentifier
FROMCryptographicMessageSyntax
{iso(1)member-body(2)us(840)rsadsi(113549)
pkcs(1)pkcs-9(9)smime(16)modules(0)cms(1)};

--id-aaisthearcwithallnewauthenticatedandunauthenticated
--attributesproducedthebyS/MIMEWorkingGroup

id-aaOBJECTIDENTIFIER::={iso(1)member-body(2)usa(840)
rsadsi(113549)
pkcs(1)pkcs-9(9)smime(16)attributes(2)}
--S/MIMECapabilitiesprovidesamethodofbroadcastingthesymetric
--capabilitiesunderstood.Algorithmsshouldbeorderedbypreference
--andgroupedbytype
smimeCapabilitiesOBJECTIDENTIFIER::=
{iso(1)member-body(2)us(840)rsadsi(113549)pkcs(1)pkcs-9(9)15}
SMIMECapability::=SEQUENCE{
capabilityIDOBJECTIDENTIFIER,
parametersANYDEFINEDBYcapabilityIDOPTIONAL}
SMIMECapabilities::=SEQUENCEOFSMIMECapability
--EncryptionKeyPreferenceprovidesamethodofbroadcastingthe
--preferredencryptioncertificate.
id-aa-encrypKeyPrefOBJECTIDENTIFIER::={id-aa11}
SMIMEEncryptionKeyPreference::=CHOICE{
issuerAndSerialNumber[0]IssuerAndSerialNumber,
receipentKeyId[1]RecipientKeyIdentifier,
subjectAltKeyIdentifier[2]SubjectKeyIdentifier
}
--TheContentEncryptionAlgorithmsdefinedforSMIMEare:
--Triple-DESisthemanditoryalgorithmwithCBCParameterbeingthe
--parameters
dES-EDE3-CBCOBJECTIDENTIFIER::=
{iso(1)member-body(2)us(840)rsadsi(113549)
encryptionAlgorithm(3)7}
CBCParameter::=IV
IV::=OCTETSTRING(SIZE(8..8))
--RC2(orcompatable)isanoptionalalgorithmw/RC2-CBC-paramter
--astheparameter
rC2-CBCOBJECTIDENTIFIER::=
{iso(1)member-body(2)us(840)rsadsi(113549)
encryptionAlgorithm(3)2}
--Fortheeffective-key-bits(keysize)greaterthan32andlessthan
--256,theRC2-CBCalgorithmparametersareencodedas:
RC2-CBC-parameter::=SEQUENCE{
rc2ParameterVersionINTEGER,
ivIV}
--Fortheeffective-key-bitsof40,64,and128,the
--rc2ParameterVersionvaluesare160,120,58respectively.
--ThefollowinglisttheOIDstobeusedwithS/MIMEV3
--DigestAlgorithms:
--md5OBJECTIDENTIFIER::=
--{iso(1)member-body(2)us(840)rsadsi(113549)
--digestAlgorithm(2)5}
--sha-1OBJECTIDENTIFIER::=
--{iso(1)identified-organization(3)oiw(14)secsig(3)
--algorithm(2)26}
--AsymmetricEncryptionAlgorithms
--
--rsaEncryptionOBJECTIDENTIFIER::=
--{iso(1)member-body(2)us(840)rsadsi(113549)pkcs(1)pkcs-1(1)
--1}
--
--rsaOBJECTIDENTIFIER::=
--{joint-iso-ccitt(2)ds(5)algorithm(8)encryptionAlgorithm(1)1}
--
--id-dsaOBJECTIDENTIFIER::=
--{iso(1)member-body(2)us(840)x9-57(10040)x9cm(4)1}
--SignatureAlgorithms
--
--md2WithRSAEncryptionOBJECTIDENTIFIER::=
--{iso(1)member-body(2)us(840)rsadsi(113549)pkcs(1)pkcs-1(1)
--2}
--
--md5WithRSAEncryptionOBJECTIDENTIFIER::=
--{iso(1)member-body(2)us(840)rsadsi(113549)pkcs(1)pkcs-1(1)
--4}
--
--sha-1WithRSAEncryptionOBJECTIDENTIFIER::=
--{iso(1)member-body(2)us(840)rsadsi(113549)pkcs(1)pkcs-1(1)
--5}
--
--id-dsa-with-sha1OBJECTIDENTIFIER::=
--{iso(1)member-body(2)us(840)x9-57(10040)x9cm(4)3}
--OtherSignedAttributes
--
--signingTimeOBJECTIDENTIFIER::=
--{iso(1)member-body(2)us(840)rsadsi(113549)pkcs(1)pkcs-9(9)
--5}
--See[CMS]foradescriptionofhowtoencodetheattribute
--value.

END
B.參考文獻
[3DES]ANSIX9.52-1998,"TripleDataEncryptionAlgorithm
ModesofOperation",AmericanNationalStandards
Institute,1998.
[CERT3]Ramsdell,B.,Editor,"S/MIMEVersion3Certificate
Handling",RFC2632,June1999.
[CHARSETS]CharactersetsassignedbyIANA.See.
[CMS]Housley,R.,"CryptographicMessageSyntax",RFC2630,
June1999.
[CONTDISP]Troost,R.,Dorner,S.andK.Moore,"Communicating
PresentationInformationinInternetMessages:The
Content-DispositionHeaderField",RFC2183,August
1997.
[DES]ANSIX3.106,"AmericanNationalStandardfor
InformationSystems-DataLinkEncryption,"American
NationalStandardsInstitute,1983.
[DH]Rescorla,E.,"Diffie-HellmanKeyAgreementMethod",
RFC2631,June1999.
[DSS]NISTFIPSPUB186,"DigitalSignatureStandard",18
May1994.
[ESS]Hoffman,P.,Editor"EnhancedSecurityServicesfor
S/MIME",RFC2634,June1999.
[MD5]Rivest,R.,"TheMD5MessageDigestAlgorithm",RFC
1321,April1992.
[MIME-SPEC]TheprimarydefinitionofMIME."MIMEPart1:Format
ofInternetMessageBodies",RFC2045;"MIMEPart2:
MediaTypes",RFC2046;"MIMEPart3:MessageHeader
ExtensionsforNon-ASCIIText",RFC2047;"MIMEPart
4:RegistrationProcedures",RFC2048;"MIMEPart5:
ConformanceCriteriaandExamples",RFC2049,
September1993.
[MIME-SECURE]Galvin,J.,Murphy,S.,Crocker,S.andN.Freed,
"SecurityMultipartsforMIME:Multipart/Signedand
Multipart/Encrypted",RFC1847,October1995.
[mustshould]Bradner,S.,"KeyWordsforuseinRFCstoIndicate
RequirementLevels",BCP14,RFC2119,March1997.
[PKCS-1]Kaliski,B.,"PKCS#1:RSAEncryptionVersion2.0",
RFC2437,October1998.
[PKCS-7]Kaliski,B.,"PKCS#7:CryptographicMessageSyntax
Version1.5",RFC2315,March1998.
[RANDOM]Eastlake,3rd,D.,Crocker,S.andJ.Schiller,
"RandomnessRecommendationsforSecurity",RFC1750,
December1994.
[RC2]Rivest,R.,"ADescriptionoftheRC2(r)Encryption
Algorithm",RFC2268,January1998.
[SHA1]NISTFIPSPUB180-1,"SecureHashStandard,"National
InstituteofStandardsandTechnology,U.S.Department
ofCommerce,DRAFT,31May1994.
[SMIMEV2]Dusse,S.,Hoffman,P.,Ramsdell,B.,Lundblade,L.
andL.Repka,"S/MIMEVersion2Message
Specification",RFC2311,March1998.
C.致謝
非常感謝S/MIMEVersion2MessageSpecificationRFC的其他作者：Steve
Dusse,PaulHoffman,LaurenceLundbladeandLisaRepka。沒有v2就不會
有v3。
許多S/MIME工作組的成員也工作很努力，并為本文檔作出了貢獻。假如把所
有的人都列出來，將會很冗長，我為此深感抱歉。按字母順序下面這些人名顯示
在我的腦海中，因為他們對本文檔作出了直接的貢獻。
DaveCrocker
BillFlanigan
PaulHoffman
RussHousley
JohnPawling
JimSchaad

編者通訊地址：
BlakeRamsdell
Worldtalk
17720NE65thStSte201
Redmond,WA98052
Phone:+14253760225
EMail:blaker@deming.com
FullCopyrightStatement
Copyright(C)TheInternetSociety(1999).AllRightsReserved.

本文檔極其譯文可以拷貝供他人使用，假如上述版權信息和章節包括在這些
拷貝和派生作品中，評論性或解說性或幫助執行性的派生作品不受任何限制的、
全文或部分的構思、拷貝發行和分發。但是，本文檔本身不得以任何形式修改，
諸如刪除版權信息、參考書目等。
除了為了制定Internet標準的情況下，必須遵守在Internet標準過程的版權程
序，或者要求翻譯成非英語語言，互連網組織不得對本文檔作任何修改。
上述申明具有永久性，互連網協會或其后繼者或所屬部門不得廢除。
本文檔極其所包含的信息是基于"ASIS"提供的，INTERNET協會和
INTERNET應用任務組否認所有的明確或隱含的警告，（其中）包括但不限制于
任何本文包含的信息的使用不侵犯任何版權或隱含的商業和為了非凡目的警告。
非凡感謝
目前為RFC編輯部門提供資金的互連網協會。