息不需要加密 。參考資料[17]的4.3.1節(jié)提到這一要求，甚至在個別DEKs被產生用于個
別消息的情況下，IV也將隨著消息被傳送 。
一定的操作要求一個被傳送的密鑰被一個交互的密鑰加密 。頭部內容指出了IK被用
于加密的模式 。RFC1115規(guī)定了加密算法/模式的標識，包括DES-ECB，DES-EDE，和
RSA 。所有使用對稱密鑰治理的實現(xiàn)應該支持DES-ECBIK的使用，所有使用非對稱密鑰
治理的實現(xiàn)應該支持RSAIK的使用 。
RFC-1114，當前和這個文檔一起發(fā)放，規(guī)定了非對稱的基于證書的密鑰治理過程支
持定義在這個文檔中的消息處理過程 。消息處理過程也能和對稱密鑰治理一起使用，合適
的對稱IKs通過帶外通道預先發(fā)放 。強烈推薦支持在RFC1114中定義的非對稱方法 。
4.3保密增強消息轉換
4.3.1約束
一個電子郵件加密機制必須與底層電子郵件功能的透明約束相兼容 。這些約束一般被
建立在預期的用戶要求和預期的端點和傳輸設備的特色，加密機制必須也與所交互的計算
機系統(tǒng)的本地規(guī)范相兼容 。在我們的建議中，一個規(guī)范的步驟是抽象我們的本地規(guī)范和操
作一個后續(xù)的編碼步驟以與底層郵件傳輸媒體（SMTP）特色相一致 。編碼與SMTP的約
束相一致，用于支持人與人之間的通訊 。SMTP的規(guī)則也以規(guī)范的處理過程獨立使用 。
RFC-821"s的4.5節(jié)具體說明了SMTP"s的透明約束 。
預備一個進行SMTP傳送的消息必須滿足以下的要求：
１． 所有的字符必須是7位ASCII碼中的一員 。
２． 文本行，通過字符對
３． 因此字符串
消息的結束出現(xiàn) 。
盡管SMTP規(guī)定了一個標準的行分界符的表述，大量的系統(tǒng)使用一個不同的本地的
行分界的表述 。例如，在郵件中使用的行分界符
單一的
的系統(tǒng)（例如VAXVMS）可以被目的SMTP服務器轉換成合適的記錄 。因此假如加密處
理產生
獲取 。也可能Tabs和空格的轉換可以在SMTP內部和本地格式映射的過程中被處理；這
是一個本地選擇的問題 。假如這樣的轉換改變了被傳送的密文的形式，解密將不能產生被
傳送的明文，被傳送的MIC將不能和在目的計算機上計算出來的MIC相比較 。
在采用EBCDIC作為本地字符集的系統(tǒng)中被SMTP服務器操作的轉換甚至有更嚴重
的影響，因此從EBCDIC到ACSII的轉換是一個信息損失的轉換 。在原則上，在SMTP
內部規(guī)范ASCII消息表示和本地格式之間的映射轉換功能可以從SMTP服務器上移到用
戶代理上，給定的治理SMTP服務器的手段不應該再進行那種轉換 。這個方法有很大的
缺陷：內部的文件（例如，郵件箱）格式和它所駐留的本地文件形式不兼容 。此外，它將
要求修改SMTP服務器，郵件將以一種與現(xiàn)在被傳遞的不同的表述被傳遞給SMTP服務
器 。
4.3.2建議
我們建議支持保密增強郵件通過一個中間轉換可以發(fā)生的環(huán)境，編碼郵件以一種統(tǒng)一
的表述風格通過保密增強用戶代理不論他們的系統(tǒng)采用何種本地字符集 。這種編碼的形式
被用于表示從發(fā)送者到接受者的郵件文本，但是編碼未被用于封裝郵件傳輸頭或去封裝插
入到載有保密增強用戶代理之間的控制信息的頭中 。編碼的特色使在預期的發(fā)送者和接收
推薦閱讀
- 網(wǎng)絡中心數(shù)據(jù)庫的保密和準確性問題
- 什么是WINS解析
- CECT A2000所不認知的隱形保密菜單
- HSRP技術在校園網(wǎng)的應用
- IPX協(xié)議概述
- 異步傳輸模式——ATM
- 如何撤消電子郵件
- IPv6 Internet協(xié)議第六版規(guī)范(1)
- RIP協(xié)議－中興
- Internet協(xié)議