?? rfc1113.txt
字號:
4. 消息處理
4.1 消息處理總覽
這個節提供了包括在電子郵件保密增強處理中一個組件和處理步驟的高級的總括和
處理步驟。下面的小節將更詳細定義這些過程。
4.1.1 密鑰類型
一個兩級的密鑰層次被用于支持保密增強消息的傳送:
1. 數據加密密鑰(DEKs)被用于消息文本加密和(在一組算法中可以進行
一定的選擇)用于消息完整性檢查的計算。DEK為每個被傳送的消息個別
的產生;數據加密密鑰的預分發不需要支持保密增強的消息的傳送。
2. 交換密鑰(Iks)被用于加密在消息中傳送的數據加密密鑰。一般地,同樣
的IK將被用于所有的從一個給定的發送者到一個給定接收者的所有的消
息。每個被發送的消息包括一個被用于消息加密和/或MIC計算的數據加
密密鑰的表示,這個密鑰被每個命名接收者的個別交互密鑰加密。與
“X-Sender-ID:”和“X-Recipient-ID:”域相關的表示,允許每個個別接
收者標識被用于加密接受者使用DEKs和/或MIC的IK。給一個適合的
IK,一個接收者能解密相應的被傳送的DEK表述,產生用于消息文本解
密和/或MIC驗證的DEK。一個IK定義的不同取決于用于DEK加密的
是對稱或非對稱密碼系統。
2a. 當使用對稱密碼,一個IK是一個發送者和接收者共享單獨的對稱密鑰。
在這種情況下,相同的IK被用于加密傳送的DEK和MICs。版本/生命
期信息和與發送者和接收者有關的IA驗證信息必須被串聯為了充分的驗
證一個對稱IK。
2b. 當使用非對稱密碼,用于加密DEK的是接收者IK的公共組件。被用于加
密MIC的是發送者IK的私有組件。因此每個消息只需要包括一個被加密
的MIC,而不是每個接收者一個。這些IK中的每一個能被充分標識在
“X-Recipient-ID:”或“X-Sender-ID:”域。
4.1.2 處理過程
當保密增強處理操作在一個發出的消息上,一個DEK被產生由于消息加密和(如
果被選擇的MIC算法需要一個密鑰)各種DEK被產生用于MIC計算。當一個消息的所
有內容不需要加密時無需產生DEK,如果一個被選的MIC計算不需要一個密鑰。
一個“X-Sender-ID:”域被包括在提供用于消息處理的IK的一個驗證組件的頭中。
IK組件被每個個別命名的接收者選擇;一個相應的“X-Recipient-ID:” 域,在前面解釋
的“X-Sender-ID:”域用于標識每個IK。每個“X-Recipient-ID:”域接著一個“X-Key-Info:”
域,傳送一個被對應特定接收者IK加密的DEK。當一個特定的接收者使用對稱密鑰管理,
“X-Key-Info:”域也傳送被接收者的IK加密消息的MIC。當使用非對稱密鑰管理,一個
優先的“X-MIC-Info:”域存儲由發送者的私有組件加密的消息的MIC。
采用了四個階段的處理過程用于以一種通用的傳送形式表示被加密的消息文本和使
被加密在一個主機計算機類型的消息被解密在不同的計算機類型。以本地形式接收的明文
消息,使用主機本地的字符集和行表示。本地形式被轉換為一個規范的消息文本表示,與
內部的SMTP的消息文本的表示形式相同。這個規范的表示形成了MIC計算和加密處理
的輸入。
為了加密,規范的表示按照加密算法的要求填充。被填充的規范的表示被加密(除
了那些明確表示無需加密的域)。被加密的文本(以及無需加密的域的規范的表示)被編
碼成一個可打印的形式。可打印的形式由一個嚴格的字符集組成,這個字符集是每個站點
通用的,不會被在MTS實體內和之間的處理破壞。
編碼過程的輸出結合了帶有密碼控制信息的頭域集。被傳送給電子郵件系統的結果
被封裝為被傳送文本部分。
當一個保密增強消息被處理,文本中的密碼控制域提供給被鑒別的接收方需要的信
息。首先,可打印的編碼被轉換為一個位串。被傳送的消息的加密的部分被解密。MIC
被鑒別。規范的形式被轉換為接收者本地的形式,不需要和發送者的本地形式相同。
4.2 加密算法和模式
針對本文檔的目的以ANSI X3.92-1981形式定義的塊密碼算法DEA-1將被用于消
息文本的加密。DEA-1與數據加密標準相同(DES),被定義在FIPS PUB 46[3]。當被用
于文本加密,DEA-1將被用于密碼塊鏈接模式(CBC),定義在ISO IS 8372[4]。標識字
符串為“DES-CBC”,被定義在RFC-1115,表示這個算法/模式組合。CBC模式被定義在
IS 8372與在FIPS PUB 81[5]和ANSI X3.106-1993[16]中的定義相同。其他算法的使用和/
或消息文本處理的模式將要求逐個的研究決定應用性和限制。此外在本文檔中贊同使用的
算法和模式將在后續文檔到RFC-1115中定義。
為每個保密增強電子郵件消息產生新的偽隨機初始向量是發送者的責任除非整個消
息不需要加密。參考資料[17]的4.3.1節提到這一要求,甚至在個別DEKs被產生用于個
別消息的情況下,IV也將隨著消息被傳送。
一定的操作要求一個被傳送的密鑰被一個交互的密鑰加密。頭部內容指出了IK被用
于加密的模式。RFC1115規定了加密算法/模式的標識,包括DES-ECB,DES-EDE,和
RSA。所有使用對稱密鑰管理的實現應該支持DES-ECB IK的使用,所有使用非對稱密鑰
管理的實現應該支持RSA IK的使用。
RFC-1114,當前和這個文檔一起發放,規定了非對稱的基于證書的密鑰管理過程支
持定義在這個文檔中的消息處理過程。消息處理過程也能和對稱密鑰管理一起使用,合適
的對稱IKs通過帶外通道預先發放。強烈推薦支持在RFC1114中定義的非對稱方法。
4. 3 保密增強消息轉換
4.3.1 約束
一個電子郵件加密機制必須與底層電子郵件功能的透明約束相兼容。這些約束一般被
建立在預期的用戶要求和預期的端點和傳輸設備的特色,加密機制必須也與所交互的計算
機系統的本地規范相兼容。在我們的建議中,一個規范的步驟是抽象我們的本地規范和操
作一個后續的編碼步驟以與底層郵件傳輸媒體(SMTP)特色相一致。編碼與SMTP的約
束相一致,用于支持人與人之間的通訊。SMTP的規則也以規范的處理過程獨立使用。
RFC-821's的4.5節詳細說明了SMTP's的透明約束。
準備一個進行SMTP傳送的消息必須滿足以下的要求:
1. 所有的字符必須是7位ASCII碼中的一員。
2. 文本行,通過字符對<CR><LF>劃界,不能超過1000個字符長。
3. 因此字符串<CR><LF>,<CR><LF>指出了消息的結束,它必須在文本中先于
消息的結束出現。
盡管SMTP規定了一個標準的行分界符的表述,大量的系統使用一個不同的本地的
行分界的表述。例如,在郵件中使用的行分界符<CR><LF>進入UNIX操作系統被轉換為
單一的<LF>s作為郵件的分界符被寫到本地的郵件箱文件中。郵件中的行引入到面向記錄
的系統(例如VAX VMS)可以被目的SMTP服務器轉換成合適的記錄。因此如果加密處
理產生<CR>s 或 <LF>s,這些字符可能被一個使用不同行分界規則的接收用戶代理進程
獲取。也可能Tabs和空格的轉換可以在SMTP內部和本地格式映射的過程中被處理;這
是一個本地選擇的問題。如果這樣的轉換改變了被傳送的密文的形式,解密將不能產生被
傳送的明文,被傳送的MIC將不能和在目的計算機上計算出來的MIC相比較。
在采用EBCDIC作為本地字符集的系統中被SMTP服務器操作的轉換甚至有更嚴重
的影響,因此從EBCDIC到ACSII的轉換是一個信息損失的轉換。在原則上,在SMTP
內部規范ASCII消息表示和本地格式之間的映射轉換功能可以從SMTP服務器上移到用
戶代理上,給定的管理SMTP服務器的手段不應該再進行那種轉換。這個方法有很大的
缺陷:內部的文件(例如,郵件箱)格式和它所駐留的本地文件形式不兼容。此外,它將
要求修改SMTP服務器,郵件將以一種與現在被傳遞的不同的表述被傳遞給SMTP服務
器。
4.3.2 建議
我們建議支持保密增強郵件通過一個中間轉換可以發生的環境,編碼郵件以一種統一
的表述風格通過保密增強用戶代理不論他們的系統采用何種本地字符集。這種編碼的形式
被用于表示從發送者到接受者的郵件文本,但是編碼未被用于封裝郵件傳輸頭或去封裝插
入到載有保密增強用戶代理之間的控制信息的頭中。編碼的特色使在預期的發送者和接收
者用戶代理之間的轉換不會阻止一個被編碼的消息在它的目的地被正常解密。
一個發送者從加密處理可以排除一個消息一個或更多的部分,但是鑒別處理總是被應
用到這個消息文本。將一定比例的消息排除在加密處理之外是被明確要求的;默認的加密
被應用到整個消息文本。規定這一排除操作的用戶級的分界符是本地的操作,因此可以在
發送者和接受者之間變動,但是所有的系統應該提供一個手段明確的標識被排除在加密處
理之外的域。
外部的保密增強消息進行四步轉換,在下面的四個小節描述。
4.3.2.1 步驟一:本地形式
消息文本被以本地的系統的字符集創建,行的分界與本地規則相一致。
4.3.2.2 步驟二:規范形式
整個文本消息,包括需要加密處理的部分和不需要加密處理的部分,被轉換為一個通
用的規范形式,與在RFC-821和RFC-822[10]中定義的SMTP之間的表述類似(ASCII碼
字符集,<CR><LF>行分界符)。這個處理要求在本地字符集是ASCII碼時進行的轉換最
小。(注意:規范編碼處理的輸出將永遠不會被直接傳給SMTP,而是傳給保密增強編碼
處理的后續步驟,圓點填充的轉換在RFC-821中討論,因此一個消息在加密前被轉換成
一個標準的字符集和表述,它能被解密并且它的MIC能在任何類型的目的主機計算機上
被驗證。解密和MIC驗證在轉換(將消息轉換到一個規定的本地形式)前進行。
4.3.2.3 步驟三:鑒別和加密
規范形式被輸入到被選擇的MIC計算算法中為了計算消息的一組完整性檢查值。在
提交給MIC計算算法之前沒有值被填充到規范形式,盡管一定的MIC算法將在計算MIC
的過程中將進行他們自己的填充。
應用到規范形式的填充在DEA-1 CBC模式的加密中是需要的,如下:加密字節數由
從總長中減去無須加密的字節的長度來決定。在加密的文本需要時16進制的字符FF與
被填充的字符一起被附加到規范形式中,用8字節加密量的整數值來添滿。如果所加密的
字符數已經是8的整數倍則無須填充。16進制FF(一個值超出7位ASCII字符集)填充
值允許在沒有包括一個明確的填充個數的指示時與有效的數據相區別。
沒有被排除在加密之外的消息域被加密。為了支持可選的加密處理,一個實現必須保
留加密區域和非加密域的內部的標識,以便這些域在步驟四定義的編碼過程中能被適當的
分界。如果無須加密的域插入到加密域之間,密碼狀態(例如,IVs和進行加密的字符)
被保留在這個被排除的域之后繼續。
4.3.2.4 步驟四:可打印的編碼
繼續從左到右,步驟三的位串被編碼成在所有的站點都通用的字符表示,盡管不必是
同樣的位模式(例如,盡管字符“E”在基于ASCII碼字符的系統中被表示為16進制的
45在基于EBCDIC的系統中被表示為16進制的C5,兩種表述的本地意義是相同的)。這
個編碼步驟在所有的保密增強消息中進行,即使整個消息不需要加密。
一個國際的字符IA5的一個被使用64字符集,每個可打印的字符由6位表示。(建
議的字符集在IA5和ASCII中的表示是相同的。)兩個額外的字符,“=”和“*”被用于
表示特殊的處理功能。字符“=”被用于在可打印的編碼過程中填充。字符“*”被用于
分界無須加密域的開始和結束。編碼功能的輸出被劃分為文本行(使用本地規范),除了
最后一行每一行確切地包含64個可打印的字符,最后一行包含64或少于64的可打印字
符。(這一行長度是易被打印的并保證滿足SMTP的每行最多1000個字符的限制。)
編碼過程將輸入的每組24位表示為輸出的4個字符。從左到右的一個24位輸入組從
步驟三的輸出中獲得,每6位組被用作一個64位可打印的字符的索引。被索引指定的字
符被放置在輸出串中。這些字符,被標識在表0中,被選擇作為通用的表示,對SMTP
有特殊意義的字符被排除(例如,“.”,“<CR>”,“<LF>”)。
如果輸入的一組少于24位進行特殊的處理,要么在一個消息尾(當可選的加密功能
被調用)要么在一個被加密的域或未加密的域的末端。全部的編碼總是在消息末和分界符
“*”被輸出初始或終止一個無需加密的塊之前被完成。當輸入的一個組消息少于24位,
位0被填充使消息是6的整數倍。不需要表示實際輸入數據的輸出字符位被置為字符“=”。
因此所有的通用編碼的輸出是一個8位字節的整數,只有下面的情況能出現:(1)編碼輸
入的最后的量是24位的整數倍;這,編碼輸出的最后的單元是不含“=”填充的4的整
數倍,(2)編碼輸入的最后量確定為8位;這,編碼輸出的最后的單元將兩個字符并跟有
兩個“=”的填充字符,或(3)編碼輸入的最后的量確定為16位;這,編碼輸出的最后
的單元將是三個字符并跟有一個“=”填充字符。
4.3.2.5 轉換概述
總的說,發送的消息服從下面的轉換式:
Transmit_Form = Encode(Encipher(Canonicalize(Local_Form)))
相反的操作以相反的順序轉換處理接收的保密增強郵件:
Local_Form = Decanonicalize(Decipher(Decode(Transmit_Form)))
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -