【正文】 重于適合商業(yè)和團(tuán)體使用的工業(yè)標(biāo)準(zhǔn)，而 PGP則仍然維持為許多用戶提供個(gè)人電子郵件的安全性。S/MIME被定義為許多文檔，最重要的RFC3370,3850,3851和 RFC3852 ? 多用途網(wǎng)際郵件擴(kuò)展 MIME是對(duì) RFC5322框架的擴(kuò)展，用于解決 RFC821或其他郵件傳輸協(xié)議，以及RFC5322中存在的問(wèn)題和關(guān)于電子郵件簡(jiǎn)單郵件傳輸協(xié)議 SMTP的局限性。 S/MIME的功能 1. 封裝數(shù)據(jù)（ enveloped data）：它由各種類型的加密內(nèi)容和接收者用于加密內(nèi)容的一個(gè)或多個(gè)密鑰組成。 2. 簽名數(shù)據(jù)（ signed data）：數(shù)字簽名通過(guò)提取待簽名內(nèi)容的數(shù)字摘要，并用簽名者的私鑰加密得到。然后，用 Base64編碼方法重新對(duì)內(nèi)容和簽名編碼，因此，經(jīng)過(guò)簽名的數(shù)據(jù)消息只能被具有 S/MIME能力的接收方處理。 3. 透明簽名（ Clearsigned）數(shù)據(jù)：和簽名的數(shù)據(jù)一樣，形成內(nèi)容的數(shù)字簽名。但是，在這種情況下，只有數(shù)字簽名采用了 Base64編碼。因此，沒(méi)有 S／ MIME能力的接收方雖然無(wú)法驗(yàn)證簽名，但卻可以看到消息內(nèi)容。 4. 簽名并封裝數(shù)據(jù)（ signed and enveloped data）：僅簽名實(shí)體及僅加密實(shí)體可以嵌套，以便對(duì)加密后的數(shù)據(jù)進(jìn)行簽名，以及對(duì)簽名數(shù)據(jù)或透明簽名數(shù)據(jù)進(jìn)行加密。 功能 需求 創(chuàng)建用于形成數(shù)字簽名的報(bào)文摘要 必須支持 SHA1和 MD5 應(yīng)該使用 SHA1 加密報(bào)文摘要以形成數(shù)字簽名 發(fā)送和接收代理必須支持 DSS 發(fā)送代理應(yīng)該支持 RSA加密 接收代理應(yīng)該支持使用長(zhǎng)度為 512到 1024比特的密鑰來(lái)驗(yàn)證 RSA的簽名 加密會(huì)話密鑰和報(bào)文一起傳輸 發(fā)送和接收代理必須支持 DiffieHellman 發(fā)送代理應(yīng)該支持使用長(zhǎng)度為 52比特到 1024比特的密鑰的 RSA加密 接收代理應(yīng)該支持 RSA解密 使用一次性會(huì)話密鑰來(lái)加密傳輸?shù)膱?bào)文 發(fā)送代理應(yīng)該支持 3DES和 RC2/40的加密 接收代理應(yīng)該支持 3DES的解密，必須支持RC2/40的解密 S/MIME中使用的加密算法 發(fā)送代理規(guī)則 1. 如果發(fā)送代理從它想要的接收者那里獲得了解密能力的列表，它應(yīng)該選擇能使用的列表的第一個(gè)（最高優(yōu)先級(jí)）能力 。 2. 如果發(fā)送代理沒(méi)有它想要的接收者的這樣的能力清單，但曾經(jīng)從接收者那里收到過(guò)一個(gè)或多個(gè)報(bào)文，那么輸出的報(bào)文應(yīng)該使用和從那個(gè)接收者那里接收的最后一個(gè)簽名和加密報(bào)文所使用的同樣的加密算法。 3. 如果發(fā)送者沒(méi)有它想要的接收者解密能力的任何知識(shí)，并且愿意冒著接收者可能不能解密報(bào)文的危險(xiǎn)，那么發(fā)送代理應(yīng)該使用 3DES。 4. 如果發(fā)送者沒(méi)有它想要的接收者解密能力的任何知識(shí)，并且不愿意冒著接收者可能不能解密報(bào)文的危險(xiǎn)，那么發(fā)送代理必須使用 RC2／ 40。 5. 如果報(bào)文需要發(fā)送給多個(gè)接收者，但卻不能選擇共同的加密算法，那么發(fā)送代理將需要發(fā)送兩個(gè)報(bào)文。然而，需要注意的是在這種情況下，報(bào)文的安全性依賴于低安全性的報(bào)文的一個(gè)副本的傳輸。 類型 子類型 S/MIME參數(shù) 描述 Multipart Signed 兩部分的透明簽名消息：一部分是消息，另一部分是簽名 Application pkcs7mine 簽名數(shù)據(jù) 簽名的 S/MIME實(shí)體 pkcs7mine 封裝數(shù)據(jù) 加密的 S/MIME實(shí)體 pkcs7mine 退化的簽名數(shù)據(jù) 僅包含公鑰證書(shū)的實(shí)體 pkcs7mime 壓縮數(shù)據(jù) 壓縮的 S/MIM實(shí)體 Pkcs7signature 簽名數(shù)據(jù) 簽 名 子 部 分 內(nèi) 容 類 型 為multipart/signed的消息 S/MIME使用許多新的 MIME內(nèi)容類型，所有新類型都使用PKCS指示， PKCS是 RSA實(shí)驗(yàn)室發(fā)布的一組公鑰加密規(guī)范，在 S/MIME上的努力使之變得可用。 S/MIME內(nèi)容類型 S/MIME證書(shū)處理過(guò)程 ? S/MIME使用公鑰證書(shū)的方式與 3一致。 S/MIME使用的密鑰管理模式是嚴(yán)格的 次結(jié)構(gòu)和 PGP的基于 Web信任方式的一種混合方式。按照 PGP模式， S/MIME的管理者或用戶必須配置每個(gè)客戶端的信任密鑰表和證書(shū)撤銷表。也就是說(shuō)嗎，驗(yàn)證接收到的簽名和對(duì)輸出消息的簽名工作都是通過(guò)在本地維護(hù)證書(shū)實(shí)現(xiàn)的。另一方面，證書(shū)由認(rèn)證機(jī)構(gòu)頒發(fā)。 用戶代理職責(zé)：一個(gè) S/MIME用戶需要執(zhí)行若干密鑰管理職能： 1. 密鑰生成：與一些行政管理機(jī)構(gòu)相關(guān)（如與局域網(wǎng)管理相關(guān)）的用戶必須能夠生成單獨(dú)的 DiffieHellman和DSS密鑰對(duì)，并且應(yīng)該能夠生成 RSA密鑰對(duì)。每個(gè)密鑰對(duì)必須用非確定的隨即輸入生成，并以安全方式保護(hù)。用戶代理應(yīng)該能生成長(zhǎng)度在 7681024比特之間的 RSA密鑰對(duì)，且禁止生成長(zhǎng)度小于 512比特的 RSA密鑰對(duì)。 2. 注冊(cè)：為獲得 ，用戶的公鑰必須到認(rèn)證機(jī)構(gòu)注冊(cè)。 3. 證書(shū)存儲(chǔ)和檢索：為驗(yàn)證接收到的簽名和加密輸出消息，用戶需要訪問(wèn)本地的證書(shū)列表。該列表必須由用戶自己維護(hù)，或由一些管理部門為部分用戶維護(hù)。 增強(qiáng)的安全性服務(wù) 1. 簽名的接收者（ Signed receipt）：在 SignedData對(duì)象中可能需要簽名的接收者。返回簽名的接收者給報(bào)文的發(fā)送者提供了交付證明，使得發(fā)送者可以顯示給第三方看接收者已經(jīng)收到了報(bào)文。本質(zhì)上，接收者對(duì)整個(gè)報(bào)文加上初始（發(fā)送者的）簽名進(jìn)行簽名并且添加新的簽名來(lái)形成新的 S／ MIME報(bào)文。 2. 安全標(biāo)號(hào)（ Security label）：可以在 SignedData對(duì)象的已鑒別的屬性中包括安全標(biāo)號(hào)。安全標(biāo)號(hào)是通過(guò) S／ MIME封裝來(lái)保護(hù)的有關(guān)敏感內(nèi)容的安全信息的集合，該標(biāo)號(hào)可以用于訪問(wèn)控制，指示哪些用戶可以允許訪問(wèn)對(duì)象。其他的使用包括優(yōu)先級(jí)（秘密、機(jī)密、受限等等），或者是基于角色的，描述了哪種類型的人可以看到該信息（例如病人的治療小組、醫(yī)療賬單代理等）。 3. 安全的郵件發(fā)送清單（ Security mailing list）：當(dāng)用戶向多個(gè)接收者發(fā)送報(bào)文時(shí)，需要一定數(shù)量的針對(duì)每個(gè)接收者的處理，包括使用每個(gè)接收者的公開(kāi)密鑰。用戶可以通過(guò)使用 S／ MIME郵件發(fā)送清單代理（ MLA）的服務(wù)從這個(gè)工作中解脫出來(lái)。 MLA可以輸入單個(gè)報(bào)文，對(duì)每個(gè)接收者完成接收者有關(guān)的加密工作，然后將報(bào)文發(fā)送出去。報(bào)文的發(fā)送者只需要將報(bào)文發(fā)送給 MLA，將報(bào)文用 MLA的公開(kāi)密鑰進(jìn)行加密。