Internet電子郵件保密增強：Part1-消息編碼和鑒別過程

本備忘錄的狀態
本文檔講述了一種Inte.net社區的Internet標準跟蹤協議，它需要進一步進行討論和建
議以得到改進。請參考最新版的“Internet正式協議標準”(STD1)來獲得本協議的標準化
程度和狀態。本備忘錄的發布不受任何限制。
版權聲明
Copyright(C)TheInternetSociety(2001).
感謝
本文檔是internet構架委員會（IAB）保密特別委員會的一系列會議及在那些會議上分
發的internet工作報告的產物。我想感謝以下列出的保密特別委員會的成員集中了他們在會
議上的觀點和貢獻形成了這個rfc文檔：DavidBalenson,CurtBarker,JimBidzos,Matt
Bishop,DannyCohen,TomDaniel,CharlesFox,MorrieGasser,RussHousley,Steve
Kent(chairman),JohnLaws,SteveLipner,DanNessett,MikePadlipsky,RobShirey,
MilesSmid,SteveWalker,andSteveWilbur.
目錄
1.介紹 3
2.術語 3
3.服務、約束和暗示 3
４.消息處理 5
４.1消息處理總覽 5
４.1.1密鑰類型 5
４.1.２處理過程 6
4.2加密算法和模式 6
4.3保密增強消息轉換 7
4.3.1約束 7
4.3.2建議 8
4.3.2.1步驟一：本地形式 8
4.3.2.2步驟二：規范形式 8
4.3.2.3步驟三：鑒別和加密 8
4.3.2.4步驟四：可打印的編碼 9
4.3.2.5轉換概述 9
4.4封裝機制 10
4.5郵件列表的郵件 12
4.6被封裝的頭域小結 12
4.6.1每個消息被封裝的頭域 14
4.6.1.1X-Proc-Type域 14
4.6.1.2X-DEK-Info域 14
4.6.2一般每個消息被封裝的頭域 15
4.6.2.1X-Sender-ID域 15
4.6.2.2X-Certificate域 15
4.6.2.3X-MIC-Info域 15
4.6.3不定出現的頭域 16
4.6.3.1X-Issuer-Certificate域 16
4.6.4每個接收者被封裝的頭域 16
4.6.4.1X-Recipient-ID域 16
4.6.4.2X-Key-Info域 17
4.6.4.2.1對稱密鑰管理 17
4.6.4.2.2非對稱密鑰管理 17
5.密鑰管理 17
5.1數據加密密鑰（DEKs） 18
5.2交互密鑰（Iks） 18
5.2.1子域的定義 19
5.2.1.1實體標識符子域 19
5.2.1.2發行機構子域 19
5.2.1.3版本/滿期子域 19
5.2.2IK加密期發行 20
6.用戶命名 20
6.1當前的方法 20
6.2發行考慮 20
7.用戶接口和實現的例子 21
8.進一步研究的領域 21
9.參考 21
注意： 22
作者地址： 24

1.介紹
本文檔定義了為在internet上傳輸的電子郵件提供保密增強服務的消息編碼和鑒
別的過程。是四個相關文檔中的一篇。在當前的RFC中定義的步驟試圖與各種密鑰管
理方法保持兼容，包括加密密鑰的數據加密的對稱（秘鑰）和非對稱（公鑰）方法。并
預見了消息文本加密的對稱密碼系統的使用和／或完整性檢查計算。RFC-1114規定了
支持基于公鑰證書使用的密鑰管理機制。RFC-1115規定了算法和與當前文檔和
RFC-1114相關的信息。后續的RFC將提供被建立的密鑰基礎設施的詳細的報告和電
子格式和過程以支持這些服務。
保密增強服務（機密性、可鑒別性、消息完整性保證）是通過發送者和接受者用戶
進程之間的端對端的加密系統提供的，沒有特殊的處理要求強加于端點的消息傳輸系統
或中繼站。這種方法容許保密增強功能被結合到一個站對站或用戶對用戶的基礎之上，
不會影響其他的網絡實體。支持不同種類的的組件和郵件傳輸工具之間的互操作性。
2.術語
為了描述的目的，本RFC文檔使用了定義在OSIX.400消息處理系統（1984年
經CCITT推薦）模型里的術語。這部分復制了X.4002.2.1小節的部分內容，“MHS
模型的描述：總覽”為了使不熟悉OSIMHS模型的的讀者清楚的理解這個術語。
在MHS模型中，一個用戶是一個人或一個計算機應用。一個用戶要么作為發送者
要么作為接收者（當正在接收）。MH服務元素定義了一組消息類型和一個發送者傳送
這些類型消息給一個或多個接收者的能力。
一個發送者在他或她的用戶代理的幫助下準備消息。一個用戶代理（UA）是一個
和傳送消息的消息傳輸系統（MTS）相互影響的應用進程。這個MTS向一個或多個接
受者的用戶代理傳送消息。只是被用戶代理操作而沒有標準化為一個MH服務元素的
一部分的功能被稱為本地用戶代理功能。
MTS有大量的消息傳送代理（MTAs）組成。在一起操作，MTAs轉送消息將它們
傳送給目的接收用戶代理，通過這些代理使消息對于目的接受者可用。
UAs和MTAs總稱為消息處理系統（MHS）。MHS和它的所有用戶作為消息處理
環境。
3.服務、約束和暗示
本文檔定義了增強電子郵件在網絡上保密傳送的機制。在本文檔中討論的功能提供
了基于發送者和接收者用戶代理的端對端的系統保密增強服務。沒有保密增強被提供給
通過中間節點轉發和增加的消息域。
鑒別和完整性功能總是應用到整個消息文本，沒有不通過鑒別的機密性功能，加
密功能可以有選擇的應用到消息的內容部分；這允許在接收者的個人密鑰缺失的情況下
消息不太敏感的部分（例如，描述域）被接收者的代理處理。在有些情況下，消息整體
被排除在加密之外，這一特色可以用于不含機密性的鑒別和完整性服務的有效組合。
為了和internet的不同支持者和使用模式保持一致，定義在文檔中的各種方法可以
應用到internet主機和使用范例的廣泛的范圍。特別下面的屬性值得注意：
1． 定義在文檔中的機制沒有限制針對特殊的主機或操作系統，但是允許在大量系統間
的互操作性。所有的保密增強在應用層實現，不依賴于底層協議的任何保密特色。
2． 被定義的機制和非增強的網絡組件相兼容。保密增強在端到端的風格中中間轉發的
主機不影響郵件的處理，中間的主機沒有加入保密增強功能。然而消息的發送者識
別接收者是否實現保密增強，為了編碼?？赡芗用懿粫挥糜跊]有對應轉換的消息
的目的地。
3． 定義的機制是和一些的郵件傳輸功能相兼容的。在Internet內，電子郵件傳輸受各種
SMTP的實現影響。一定的站點憑借SMTP可獲取，傳送郵件到其他的郵件處理環
境（例如USENET，CSNET，BITNET）。 保密增強必須能通過SMTP領域操作；
也要求與在SMTP環境和其他連接環境的電子郵件發送保護相一致。
4． 定義的機制和大范圍的電子郵件用戶代理相一致。各種各樣的被用在internet電子郵
件用戶代理程序，和相應范圍的用戶接口范例。為了使電子郵件保密性增強最大可
能的應用于用戶交互，所選擇的機制應該對于最大可能的各種存在UA程序可用。
對于引導實現的目的，要求保密增強處理被組合成一個單獨的程序，對于大多數的
UAs可用，而不是去修改每一個提供保密增強服務的每個UA。
5． 定義的機制允許電子郵件保密增強處理被操作在個人電腦上獨立于不同的UA功能
被實現的系統。給定PCs擴展的使用和被放置在許多多用戶系統的UA實現的信任
程度，這個屬性能允許許多用戶以比一個嚴格基于UA的方法所能允許保證級高的
級別來處理保密增強郵件。
6． 定義的機制支持電子郵件定位的郵件列表保密保護（分發列表，ISO用語）。
7． 定義在本文檔中的機制和各種支持的密鑰管理方法相兼容，包括（未限制）手工的
預分發，基于對稱密碼的密鑰分發，和公鑰證書的使用。不同的密鑰管理機制可以
被用于一個廣播消息的不同接收者。而為了與本文檔的兼容性支持一個特殊的密鑰
管理機制不是最小的必要的要求，強烈推薦采用定義在RFC-1114中的公鑰證書方
法。
為了獲得對于最大可能范圍的網絡主機和郵件系統的適用性，便利引導實現和測
試而無須預先修改整個網絡，在本文擋中考慮了影響一組方法的三個基本的限制：
1． 方法將被限制于在端點的實現并將受用戶代理級等完整性的影響，而不必集成到消
息傳輸系統（例如，SMTP服務）。
2． 被支持的方法增強而不是限制用戶的能力。被信任的實現，包含完整性特色保護軟
件不被本地用戶顛覆，不能做一般的假設。在這樣的特色缺少的情況下，提供增強
對用戶服務的便利（例如，通過保護和鑒別中間用戶交互）顯然比增強對用戶行為
限制（內部用戶獲取控制）更加可行。
3． 被支持的一組方法集中于一組被選擇提供廣大用戶社區重要的和切實的利益的功
能。通過集中最關鍵的服務組，我們旨在通過普通的實現努力最大化被增加的保密
值。
由于這些限制，能提供下面的功能：
1． 解密保護，
2． 發送者鑒別，
3． 消息完整性方法，
4． （如果使用非對稱密鑰管理）來源不可否認，
但是下面的與保密相關的影響未提到：
1． 獲取控制，
2． 通信流機密性，
3． 地址列表的正確性，
4． 路由控制，
5． 發布關于被多個用戶偶爾連續重用的PC機，
6． 消息和他們所要訪問的的內容的自動確認，
7． 消息復制檢測，重放阻止，或其它的面向流的服務。
消息的發送者將決定是否對特定的消息進行保密增強服務。因此，一個發送者必須
能決定是否接收者具有處理保密增強郵件的能力。在一個一般的結構中，這些機制將基
于服務器的查詢；因此，查詢功能能被集成到一個UA避免增加電子郵件使用者的負擔
或不便。
４.消息處理
４.1消息處理總覽
這個節提供了包括在電子郵件保密增強處理中一個組件和處理步驟的高級的總括和
處理步驟。下面的小節將更詳細定義這些過程。
４.1.1密鑰類型
一個兩級的密鑰層次被用于支持保密增強消息的傳送：
１． 數據加密密鑰（DEKs）被用于消息文本加密和（在一組算法中可以進行
一定的選擇）用于消息完整性檢查的計算。DEK為每個被傳送的消息個別
的產生；數據加密密鑰的預分發不需要支持保密增強的消息的傳送。
２． 交換密鑰（Iks）被用于加密在消息中傳送的數據加密密鑰。一般地，同樣
的IK將被用于所有的從一個給定的發送者到一個給定接收者的所有的消
息。每個被發送的消息包括一個被用于消息加密和／或MIC計算的數據加
密密鑰的表示，這個密鑰被每個命名接收者的個別交互密鑰加密。與
“X-Sender-ID：”和“X-Recipient-ID：”域相關的表示，允許每個個別接
收者標識被用于加密接受者使用DEKs和／或MIC的IK。給一個適合的
IK，一個接收者能解密相應的被傳送的DEK表述，產生用于消息文本解
密和／或MIC驗證的DEK。一個ＩＫ定義的不同取決于用于DEK加密的
是對稱或非對稱密碼系統。
2a．當使用對稱密碼，一個IK是一個發送者和接收者共享單獨的對稱密鑰。
在這種情況下，相同的IK被用于加密傳送的DEK和MICs。版本／生命
期信息和與發送者和接收者有關的IA驗證信息必須被串聯為了充分的驗
證一個對稱IK。
2b．當使用非對稱密碼，用于加密DEK的是接收者IK的公共組件。被用于加
密MIC的是發送者IK的私有組件。因此每個消息只需要包括一個被加密
的MIC，而不是每個接收者一個。這些IK中的每一個能被充分標識在
“X-Recipient-ID：”或“X-Sender-ID：”域。
４.1.２處理過程
當保密增強處理操作在一個發出的消息上，一個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加密算法和模式
針對本文檔的目的以ANSIX3.92-1981形式定義的塊密碼算法DEA-1將被用于消
息文本的加密。DEA-1與數據加密標準相同（DES），被定義在FIPSPUB46[3]。當被用
于文本加密，DEA-1將被用于密碼塊鏈接模式（CBC），定義在ISOIS8372[4]。標識字
符串為“DES-CBC”，被定義在RFC-1115，表示這個算法/模式組合。CBC模式被定義在
IS8372與在FIPSPUB81[5]和ANSIX3.106-1993[16]中的定義相同。其他算法的使用和/
或消息文本處理的模式將要求逐個的研究決定應用性和限制。此外在本文檔中贊同使用的
算法和模式將在后續文檔到RFC-1115中定義。
為每個保密增強電子郵件消息產生新的偽隨機初始向量是發送者的責任除非整個消
息不需要加密。參考資料[17]的4.3.1節提到這一要求，甚至在個別DEKs被產生用于個
別消息的情況下，IV也將隨著消息被傳送。
一定的操作要求一個被傳送的密鑰被一個交互的密鑰加密。頭部內容指出了IK被用
于加密的模式。RFC1115規定了加密算法/模式的標識，包括DES-ECB，DES-EDE，和
RSA。所有使用對稱密鑰管理的實現應該支持DES-ECBIK的使用，所有使用非對稱密鑰
管理的實現應該支持RSAIK的使用。
RFC-1114，當前和這個文檔一起發放，規定了非對稱的基于證書的密鑰管理過程支
持定義在這個文檔中的消息處理過程。消息處理過程也能和對稱密鑰管理一起使用，合適
的對稱IKs通過帶外通道預先發放。強烈推薦支持在RFC1114中定義的非對稱方法。
4.3保密增強消息轉換
4.3.1約束
一個電子郵件加密機制必須與底層電子郵件功能的透明約束相兼容。這些約束一般被
建立在預期的用戶要求和預期的端點和傳輸設備的特色，加密機制必須也與所交互的計算
機系統的本地規范相兼容。在我們的建議中，一個規范的步驟是抽象我們的本地規范和操
作一個后續的編碼步驟以與底層郵件傳輸媒體（SMTP）特色相一致。編碼與SMTP的約
束相一致，用于支持人與人之間的通訊。SMTP的規則也以規范的處理過程獨立使用。
RFC-821's的4.5節詳細說明了SMTP's的透明約束。
準備一個進行SMTP傳送的消息必須滿足以下的要求：
１． 所有的字符必須是7位ASCII碼中的一員。
２． 文本行，通過字符對<CR><LF>劃界，不能超過1000個字符長。
３． 因此字符串<CR><LF>，<CR><LF>指出了消息的結束，它必須在文本中先于
消息的結束出現。
盡管SMTP規定了一個標準的行分界符的表述，大量的系統使用一個不同的本地的
行分界的表述。例如，在郵件中使用的行分界符<CR><LF>進入UNIX操作系統被轉換為
單一的<LF>s作為郵件的分界符被寫到本地的郵件箱文件中。郵件中的行引入到面向記錄
的系統（例如VAXVMS）可以被目的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-1CBC模式的加密中是需要的，如下：加密字節數由
從總長中減去無須加密的字節的長度來決定。在加密的文本需要時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）））
ValueEncodingValueEncodingValueEncodingValueEncoding
0A17R34i51z
1B18S35j520
2C19T36k531
3D20U37l542
4E21V38m553
5F22W39n564
6G23X40o575
7H24Y41p586
8I25Z42q597
9J26a43r608
10K27b44s619
11L28c45t62+
12M29d46u63/
13N30e47v
14O31f48w(pad)=
15P32g49x
16Q33h50y(1)*

(1)Thecharacter"*"isusedtoencloseportionsofan
encodedmessagetowhichencryptionprocessinghasnot
beenapplied.


PrintableEncodingCharacters
Table1
注意本地的形式和轉換消息到標準形式及從標準形式轉換的功能可以在發送者和接
收者之間無信息損失的變動。
4.4封裝機制
在一個由電子郵件傳輸系統解釋的頭的一個封裝層里的保密增強消息的封裝比一個
簡單的被加密或攜帶密碼控制信息的頭內的一定域的簡單的處理有更多的優勢。封裝提供
了一般性和那些在傳輸時被轉換的消息的用戶對用戶級的隔離的域。被插入到加密/鑒別
過程中的所有的域被放置在封裝的頭中。這個功能為只接收文本沒有從輸入文件或從其它
程序獲得頭域的郵件處理程序提供了兼容性。此外，保密增強處理能被遞歸使用。關于
MTS，合并到密碼鑒別或加密處理的信息將駐留到一個消息的文本部分，而不是頭部分。
用于保密增強郵件的封裝機制來自于RFC-934[11]中的敘述，這一敘述是基于internet
社區消息摘要處理的先例。準備的用于加密或鑒別的一個用戶消息將被轉換為圖1中的表
述。
作為一般的設計原則，敏感的數據通過將數據導入到被封裝的文本而不是通過將數
據導入到封裝的頭里的域的方法來進行保護。潛在的敏感頭信息的域可以包括這些域例
如：“Subject：”，包含的內容對于端到端的用戶和內部的用戶有意義。應用保護的頭域集
（可能是空的）由用戶選擇。不過強烈推薦所有的信息應當在封裝文本里復制
“X-Sender-ID：”和“X-Recipient-ID：”域的拷貝。
如果一個用戶希望對頭域公開保護，他們必須只出現在被封裝的文本中而不在被封
裝的頭中。如果公開保護要求一個消息的主題標識，推薦封裝的頭包含一個“Subject：”
域指出“被加密的郵件跟隨”。
如果要求一個頭信息的被鑒別的版本，除了本身在封裝頭里的數據，包含在被封裝
的本文里的數據也能被復制。例如，一個發送者希望提供接收者一個在一系列被封裝的文
本中的包括一個時間戳或消息計數域的被保護的消息的位置的標識。
一個與帶有消息封裝機制功能的保密增強郵件的完整性有關的特殊的點是值得注
意。被選擇用于傳輸編碼的IA5子集有目的的排除了字符“-”，因此被封裝的文本可以明
確的同一個消息的結束封裝的邊界相區分（Post-EB）不用求助于字符的填充。
boundary(Post-EB)withoutrecoursetocharacterstuffing.

EnclosingHeaderPortion
(ContainsheaderfieldsperRFC-822)

BlankLine
(SeparatesEnclosingHeaderfromEncapsulatedMessage)

EncapsulatedMessage

Pre-EncapsulationBoundary(Pre-EB)
-----PRIVACY-ENHANCEDMESSAGEBOUNDARY-----

EncapsulatedHeaderPortion
(Containsencryptioncontrolfieldsinsertedinplaintext.
Examplesinclude"X-DEK-Info:","X-Sender-ID:",and
"X-Key-Info:".
Notethat,althoughthesecontrolfieldshaveline-oriented
representationssimilartoRFC-822headerfields,theset
offieldsvalidinthiscontextisdisjointfromthoseused
inRFC-822processing.)

BlankLine
(SeparatesEncapsulatedHeaderfromsubsequentencoded
EncapsulatedTextPortion)

EncapsulatedTextPortion
(ContainsmessagedataencodedasspecifiedinSection4.3;
mayincorporateprotectedcopiesofenclosingand
encapsulatedheaderfieldssuchas"Subject:",etc.)

Post-EncapsulationBoundary(Post-EB)
-----PRIVACY-ENHANCEDMESSAGEBOUNDARY-----


MessageEncapsulation
Figure1
4.5郵件列表的郵件
當郵件被定位到郵件列表，可以采用兩種不同的方法：IK-per-list方法和IK-per-recipient
方法。選擇依賴于對于發送者可用的信息和發送者的興趣。
如果一個消息的發送者定位一個消息到一個列表名或別名，表示他將一個IK和那個名
字或別名作為一個實體結合使用（IK-per-list），而不是決定到它的目的地的名字或別名。因
此IK必須對列表的所有成員都是可用的。對于非對稱密鑰管理的情況，列表的私有組件必
須的列表的所有成員都是可用的。另一種是憑借遠端爆增站點發送消息的一般的情況，此時
到這樣的列表的發送者可以不認識個別的接收者。不幸的是，它暴露了共享的IK，使它的
更新變得困難。此外，IK-per-list方法的使用允許列表的IK的任何擁有者可以偽裝成其他的
為了鑒別的目的到這個列表發送者。
與此相對，如果一個消息的發送者可以將目的郵件列表擴展為自己的組成部分并選擇
這么做（IK-per-recipient），消息的DEK（和，在對稱密鑰管理的情況下，MIC）將用每個
接收者的IK加密并且這些被加密的表述將被合并到被傳送的消息中。注意每個接收者的加
密只要求在“X-Key-Info：”中攜帶相對小的DEK和MIC，不像加密消息文本時一般要求更
大。盡管更多的IK在IK-per-recipient方法中被處理，一對IK能被個別調用而且只擁有一
個IK并不能使另一個列表上的使用者成功的進行偽裝。
4.6被封裝的頭域小結
這部分總結了在保密增強處理的過程中被添加到消息中的被封裝的頭域的語法和語義。
這些頭域分三組出現。正常的，一組將按順序出現在被封裝的頭域，盡管在每一組里不是所
有的域都會出現在所有的消息中。在某些特定情況下，這些域被復制到被封裝的消息文本中
也被包括到被封裝的頭中。圖2和3是被封裝的消息的小例子。圖2假設使用對稱的密鑰管
理。圖3假設說明了使用非對稱的密鑰管理的被封裝的消息的示例。
如果沒有其他的特殊的規定，所有的域參數以一種區分大小寫的風格處理。在大多數情
況下，數字量以連續的十六進制數出現在頭域中，每個數字通過從“0”到“9”或大寫的“A”
到“F”的字符來表示。因此公鑰證書和使用非對稱算法加密的量尺寸比較大，一個更節省
空間的編碼技術的使用對這樣的量是合適的，而且定義在本文檔4.3.2.4節的用可打印的字
符表示6位的編碼機制被采用。在圖3中顯示的例子顯示的被加密的非對稱量（例如，
“X-Mic-Info：”，“X-Key-Info：”）用64個可打印的字符表示，對應384位。帶有非對稱加
密量的域也說明了定義在RFC822中的3.1.1節的折疊的使用。
-----PRIVACY-ENHANCEDMESSAGEBOUNDARY-----
X-Proc-Type:3,ENCRYPTED
X-DEK-Info:DES-CBC,F8143EDE5960C597
X-Sender-ID:linn@clearcase/" target="_blank" >ccy.bbn.com::
X-Recipient-ID:linn@ccy.bbn.com:ptf-kmc:3
X-Key-Info:DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,B70665BB9BF7CBCD,
A60195DB94F727D3
X-Recipient-ID:privacy-tf@venera.isi.edu:ptf-kmc:4
X-Key-Info:DES-ECB,RSA-MD2,161A3F75DC82EF26,E2EF532C65CBCFF7,
9F83A2658132DB47

LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
dXd/H5LMDWnonNvPCwQUHt==
-----PRIVACY-ENHANCEDMESSAGEBOUNDARY-----


ExampleEncapsulatedMessage(SymmetricCase)
Figure2


-----PRIVACY-ENHANCEDMESSAGEBOUNDARY-----
X-Proc-Type:3,ENCRYPTED
X-DEK-Info:DES-CBC,F8143EDE5960C597
X-Sender-ID:linn@ccy.bbn.com::
X-Certificate:
jHUlBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIk
YbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUz
agV2IzUpk8tEjmFjHUlBLpvXR0UrUz/zxB+bATMtPjCUWbz8Lr9wloXIkYbkNpk0
X-Issuer-Certificate:
TMtPjCUWbz8Lr9wloXIkYbkNpk0agV2IzUpk8tEjmFjHUlBLpvXR0UrUz/zxB+bA
IkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloX
vXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLp
X-MIC-Info:RSA-MD2,RSA,
5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpotJ6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz
X-Recipient-ID:linn@ccy.bbn.com:RSADSI:3
X-Key-Info:RSA,
lBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHU
X-Recipient-ID:privacy-tf@venera.isi.edu:RSADSI:4
X-Key-Info:RSA,
NcUk2jHEUSoH1nvNSIWL9MLLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72oh
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
dXd/H5LMDWnonNvPCwQUHt==
-----PRIVACY-ENHANCEDMESSAGEBOUNDARY-----
ExampleEncapsulatedMessage(AsymmetricCase)
Figure3
盡管被封裝的頭域類似RFC-822的頭域，他們之間并沒有交集而且不是使用同樣的處
理密封頭域的分析器。對被封裝頭域字典分析的復雜度明顯比RFC-822頭域的分析復雜度
要小。例如，許多對于在依據造句法的級別的RFC-822有特殊意義的字符在被封裝的頭域
中沒有這種特殊的意義。
當被封裝的頭域的長度比一行可打印的字符長度要長時，在RFC-8223.1.1節中可以用
空格折疊這個域。任何這樣空格的加入不會被解釋為這一子集的一部分。作為一個特殊的例
子，由于公鑰證書和使用非對稱算法加密的量的長度，這些量經常需要被折疊成幾行。為了
以統一的方式使用這種折疊，這樣一個量的位表示按順序（最左邊的位置先出現）被劃分0
或多于384位的組（對應64位可打印的字符的表示），最后一組可以是小于384位的任意的
長度。
4.6.1每個消息被封裝的頭域
這組被封裝的頭域包含在一個保密增強消息中出現不止一次的域，一般先于所有其他的
被封裝的頭域。
4.6.1.1X-Proc-Type域
“X-Proc-Type：”被封裝的頭域，是所有的保密增強消息都必須具有的，標識對被傳送
的消息進行的處理類型。在一個消息中該域只出現一次；“X-Proc-Type：”域必須在第一個
出現在被封裝的消息頭中。
“X-Proc-Type：”域必須有兩個子域，被一個逗號分隔。第一個子域是一個十進制數用
于區別不兼容的被封裝的頭域說明可能會在以后對這個標準進行修改后出現。按照本文檔消
息處理將帶有子域值3用于與以前的RFCs989和1040相區別。
第二個子域可以假設為兩個字符串值中的一個：“ENCRYPTED”或“MIC-ONLY”。如
果一個消息的被封裝的文本需要加密，“X-Proc-Type：”域的第二個子域必須規定
“ENCRYPTED”?！癕IC-ONLY”的規定，在和密鑰管理和MIC算法選擇相關聯時，允許
一些未進行加密的域從被封裝的頭域中忽略。尤其“X-Recipient-ID：”和“X-Key-Info：”在
非對稱密鑰算法被使用時能被接收者忽略。假設當前使用一個無密鑰MIC計算算法，
“X-DEK-Info：”域可以被所有的“MIC-ONLY”消息忽略。
4.6.1.2X-DEK-Info域
“X-DEK-Info：”被封裝頭域標識消息文本加密算法和模式，也攜帶用于消息加密的初
始向量。在消息里“X-DEK-Info：”域不止出現一次，在“X-Proc-Type：”域里規定了
“MIC-ONLY”的消息不包含此域。
“X-DEK-Info：”域帶有兩個參數，用逗號分隔。對于本RFC的目的，第一個參數必
須是字符串“DES-CBC”，表示使用CBC模式的DES算法。第二個參數代表了一個64位
的初始向量（IV）以連續的16進制的形式表示。后續的RFC1115修訂版將規定可能作為這
個域的第一個參數出現的任何額外的值。
4.6.2一般每個消息被封裝的頭域
這個被封裝的頭域組包含在每個消息中出現不止一次的頭域。依賴使用的密鑰管理選
項，這些域中的一些可以某些消息中不出現在。在一個消息中“X-Sender-ID”域可以出現
不止一次如果對于不同的接收者必須使用不同的面向發送者的IK組件（也許對應于不同的
版本）。在這種情況下后來的出現取代以前的出現。如果在一個簡單消息里使用對稱和非對
稱的密鑰分發的混合。對于密鑰分發技術的每個接收者應該被組合在一起簡化分析。
4.6.2.1X-Sender-ID域
所有的保密增強消息都要求有“X-Sender-ID：”被封裝的頭域，標識一個消息的發送者
并提供發送者的IK標識組件。它應該在被封裝的文本內被復制。IK標識組件被包含在
“X-Sender-ID：”域與所有后續的“X-Recipient-ID：”相關聯直到另一個“X-Sender-ID：”
域出現；一般的情況是只有一個“X-Sender-ID：”域在任意“X-Recipient-ID：”域前出現。
“X-Sender-ID：”域包含一個實體標識子域，一個（可選的）發行機構子域，和一個（可
選的）版本/滿期子域。這些可選的域可以被忽略如果他們的出現對于后續的
“X-Recipient-ID：”域所帶有的信息來說是多余的。這在使用對稱密碼作為密鑰管理的情況
下是經常的情況。這些子域通過冒號分隔，也可以帶有空格。
在5.2節，交互密鑰，討論了這些子域的語義并規定了他們選擇的字符的形式。注意多
個“X-Sender-ID：”域可以出現在一個簡單的被封裝的頭中。所有的“X-Recipient-ID：”域
在大多數情況下接著“X-Sender-ID：”域；“X-Recipient-ID：”域出現在“X-Sender-ID：”域
之前是不合法的。
4.6.2.2X-Certificate域
“X-Certificate：”域只在非對稱密鑰管理被用于一個或多個消息的接受者時被使用。為
了便于接收者的處理（至少超過一個一般的路徑服務器可用性），強烈推薦在所有的消息中
包括這個域。這個域以數量的形式傳送了發送者的證書，以定義在4.3.2..4節中的編碼的形
式表示。一個證書的語法定義在RFC-1114中。在“X-Certificate：”域中攜帶的證書和
“X-Sender-ID：”域和“X-Recipient-ID：”域一起在非對稱密鑰管理被使用時使用。

4.6.2.3X-MIC-Info域
“X-MIC-Info：”只在至少一個消息的接收者使用非對稱密鑰管理時才使用，帶有三個
參數，通過逗號分隔。第一個消息標識在MIC被計算時使用的算法；RFC-1115規定了可接
受的MIC算法標識集。第二個參標識MIC被加密時使用的算法；在本文檔中必須出現在
RFC-1115中描述的字符串“RSA”，標識RSA算法。第三個參數是一個MIC。
非對稱的加密使用發送者的私鑰。正如本文檔前面所述，非對稱被加密的MIC使用描
述在4.3.2.4節中的技術來表示。
“X-MIC-Info：”域將立即出現在“X-Sender-ID：”域和“X-Certificate：”域或
“X-Issuer-Certificate：”之后。類似“X-Sender-ID：”域，一個“X-MIC-Info：”域由所有的
使用非對稱密鑰的接收者使用。
4.6.3不定出現的頭域
這組被封裝的頭域包含在消息中出現次數不定的域，出現的次數從0到非零的值變動與
接收者的數目無關。
4.6.3.1X-Issuer-Certificate域
“X-Issuer-Certificate：”被封裝的域只在至少一個消息的接收者使用非對稱密鑰管理時
是有意義的。一個典型“X-Issuer-Certificate：”域包含擁有公鑰組件的證書，這個證書被用
于簽包含在“X-Certificate：”域中的證書，接收者通過證書的認證路徑鏈使用。其他的典型
的代表認證鏈上高一級的證書的“X-Issuer-Certificate：”域，也可以被一個發送者包括。被
包括的“X-Issuer-Certificate：”域的順序不需要對應認證路徑的順序；路徑的順序一般可以
與不同的接收者的觀點不同。關于認證路徑的更多的信息可以在RFC-1114中發現。
證書以定義在“X-Certificate：”域中相同的方式表示，任何“X-Issuer-Certificate：”域
一般將直接跟隨“X-Certificate：”域?！癤-Issuer-Certificate：”域這個域甚至在使用非對稱密
鑰管理時也是可選的，盡管在使接收者能獲取發行者的證書的的二選一的路徑服務器缺乏時
強烈推薦使用這個域。
4.6.4每個接收者被封裝的頭域
這組被封裝的頭域對于每一個消息的命名接收者來說一般出現一次。在特殊的情況下，
這些域在發送給使用非對稱密鑰管理的接收者一個“MIC-ONLY”消息的情況下可以被忽略，
給定的被選擇的MIC算法是無密鑰的。
4.6.4.1X-Recipient-ID域
這個“X-Recipient-ID：”標識了一個接收者并提供了接收者IK標識組件。一個
“X-Recipient-ID：”被每個命名的接收者包括。它應該被復制在被封裝的文本中。這個域包
含一個實體標識子域，一個發行機構子域，和一個版本期子域。子域通過冒號分界，可以跟
空格。
5.2節，交互密鑰，討論了子域的語義并規定了他們被選擇的字符。所有
“X-Recipient-ID：”域跟在最接近的的“X-Sender-ID：”域之后；“X-Recipient-ID：”域出現
在“X-Sender-ID：”域之前是不合法的。
4.6.4.2X-Key-Info域
一個“X-Key-Info：”被包含在每一個消息的命名接收者中。每一個“X-Key-Info：”域
跟在最近的“X-Recipient-ID：”域之后；通常，一個“X-Key-Info：”域將立即跟著它的相關
的“X-Recipient-ID：”域。對于一個特殊的接收者這個域的參數對于對稱和非對稱的密鑰管
理是不同。
4.6.4.2.1對稱密鑰管理
當對一個給定的接收者使用對稱密鑰管理,“X-Key-Info：”被封裝的頭域傳送4個條目，
通過逗號分隔：一個IK使用標識，一個MIC算法標識，一個DEK和一個MIC。IK使用標
識符標識了算法和被標識的IK用于一個特殊的接收者的DEK加密的模式。對于對稱密鑰
管理被使用的接收者，它可以假設保留的字符串值為“DES-ECB”或“DES-EDE”，定義在
RFC-1115中。
MIC算法標識符標識用于特殊接收者的MIC計算算法；這個子域的值被定義在
RFC-1115中。DEK和MIC使用前面被“X-Sender-ID：”和“X-Recipient-ID：”域標識的IK
來加密；他們以兩個連續的16進制字符串來表示，通過一個逗號分隔。
當DEA-1被用于消息文本的加密，DEK將是16個16進制數字。（對應一個64位的密
鑰）；這個子域能被擴展為32位16進制數字（對應一個128位密鑰）如果需要支持其他的
算法。
MIC的對稱加密也以和消息DEK的加密的相同模式來加密。被加密的MICs，像被加
密的DEKs，以連續的16進制字符串來表示。MIC的大小依賴于規定在MIC算法標識子域
的MIC算法的選擇。
4.6.4.2.2非對稱密鑰管理
當對一個給定的接收者使用非對稱密鑰管理，“X-Key-Info：”域傳送兩個量，通過逗號
分隔。第一個參數是一個IK使用標識符標識加密DEK的算法（和模式，如果可用）；本文
檔，IK使用標識符子域總假設保留字符串為“RSA”（定義在RFC-1115）對于使用非對稱
密鑰管理的接收者，表示RSA算法的使用。第二個參數是一個DEK，在接收者的公共組件
下加密（使用非對稱加密）。
在本文檔中我們采用術語“私有組件”和“公共組件”參考對稱密碼系統中分別保持
保密和使公共可用的兩個量。這個規定被采用避免因為術語“秘鑰”用于指代私有組件和對
密碼中的密鑰引起的困惑。
正如在本文檔前面所討論的，非對稱被加密的DEK使用在4.3.2.4節所描述的方法表示。
5.密鑰管理
幾個密碼元素被使用支持保密增強消息處理的過程。假定了一組基本的元素。數據加密
密鑰（DEKs）被用于加密消息文本和（用于一些MIC計算算法）在消息完整性檢查（MIC）
計算過程。交互密鑰（Iks）被用于加密和消息一起傳送的DEKs和MICs。在一個基于證書
的非對稱密鑰管理的結構中，證書被用于作為一個提供實體的公共組件和被中央權威機構安
全綁定的信息的手段。在這一節的剩余部分提供了關于這些結構的信息。
5.1數據加密密鑰（DEKs）
數據加密密鑰（DEKs）被用于加密消息文本和（帶有一些MIC計算算法）消息完整性
檢查的計算。強烈推薦DEKs對每個消息被產生使用一次。一個被傳送的消息將合并一個被
對每個命名接收者的合適的交互密鑰加密的DEK。
DEK產生可以要么通過密鑰分發中心（KDCs）或通過端系統。專門的KDC系統可以
實現比端系統支持的算法強的隨機DEK產生算法。另一方面，分散允許端是相對獨立的，
減少了必須放在除了消息的接收者和發送者的組件的信任級別。此外，在端點的分散的DEK
的產生減少了發送者為了發送郵件進行實時服務器查詢（潛在的獨一的）的頻率，加強交互
可用性。
當對稱密碼被使用時，一個基于KDC集中產生的優勢是DEKs能在被消息的接收者的
Iks加密后被返回給端點而不是提供IKs給發送者。這減少了IK的暴露并簡化了端點密鑰管
理的要求。如果使用非對稱密鑰管理這個方法沒什么價值，因此每個接收者公共IK組件被
認為一般是可用的而且每個發送者的私有IK組件不需要和KDC共享。
5.2交互密鑰（Iks）
交互密鑰（IK）組件被用于加密DEKs和MICs。一般，IK間隔尺寸是除了發送給包含
多個用戶的地址列表的郵件的每個對等用戶級別。對于使用標準的密碼進行保密增強電子郵
件交互有兩個主要的原則，首先必須處理公共的IK組件（當使用對稱密鑰管理）或補充的
IK組件（當使用非對稱密鑰管理）。當使用對稱密碼，IK由一個單一的組件構成，被用于
加密DEKs和MICs。當使用非對稱密碼，一個接收者的公共組件用做一個IK加密DEKs（一
個相反的轉換只由接收者處理對應私有組件），發送者的私有組件被用于加密MICs（一個相
反的轉換由所有的接收者操作，因此發送者的證書提供了發送者的必要的公共組件）。
而本文檔沒有規定交互密鑰被提供給合適的使用者的手段，注意這些可能被集中（例
如，通過密鑰管理服務器）或分散（例如，通過對等協商和直接在用戶中分發）的手段是有
用的。在任何情況下，任何給定的IK組件和一個對應的發行機構（IA）相關。當基于認證
的在RFC-1114中討論非對稱密鑰管理被采用，IA功能通過一個證書機構實現（CA）。
當一個IA產生和分發一個IK組件，相關的控制信息被提供指導如何使用IK。為了選
擇用于消息加密的合適的Iks，一個發送者必須保留一個在IK組件和與之相關的接收者的通
信。終止時間信息必須被保留，以便可以使存儲的入口無效并被合適的替代。
因此一個消息可以被多個IK組件標識發送給相應的多個接收者，每個接收者的用戶代
理必須能夠決定接收者需要的IK組件。此外，如果當一個消息到達時接收者的數據庫里沒
有相應的IK組件，接收者必須能鑒別需要的IK組件并鑒別與IA相關的IK組件。注意不
同的IK可以在一對通信者之間被用于不同的消息?？紤]，例如，一個從A發送到B的消息
和另一個從A發送到B所在的郵件列表的消息（使用IK-per-list方法）。第一個消息將使用
分別與A和B相關聯的IK組件，但是第二個將使用在列表成員之間共享一個IK組件。
當一個保密增強消息被發送，一個用于加密DEK和MIC的IK指示必須被包括。到此
為止，“X-Sender-ID：”和“X-Recipient-ID：”被封裝的頭域提供下面的數據：
1. 相關發行機構的鑒別（IA子域）
2. 與一個特殊IK組件相關的一個實體的鑒別（實體標識符或實體標識子域）
3. 版本/滿期子域
冒號被用于在一個“X-Sender-ID：”或“X-Recipient-ID：”中進行分界。IA，EI，和版
本/滿期子域從一個嚴格的字符集中產生，通過下面的BNF表述（使用定義在RFC-822，第
2節和3.3節中的符號）：
IKsubfld:=1*ia-char

ia-char:=DIGIT/ALPHA/"'"/"+"/"("/")"/
","/"."/"/"/"="/"?"/"-"/"@"/
"%"/"!"/'"'/"_"/"<"/">"
一個“X-Recipient-ID：”域的示例如下：
X-Recipient-ID:linn@ccy.bbn.com:ptf-kmc:2
這個例子表明IA“ptf-kmc”已經發行了一個IK組件用于發送給linn@ccy.bbn.com的消
息，并且IA提供了數字2作為一個對于那個IK組件的版本標識符。
5.2.1子域的定義
下面的幾節定義了“X-Sender-ID：”和“X-Recipient-ID：”域。
5.2.1.1實體標識符子域
一個實體標識符被構成作為一個Iksubfld。更嚴格地，一個實體標識符子域假設了下面
的形式：
<user>@<domain-qualified-host>
為了支持通用的交互性，必須假設一個命名信息的通用的形式。對于傳送到更廣的網
絡的轉換本地主機名的安裝的情況，強烈推薦主機名被呈現給使用的Internet。
5.2.1.2發行機構子域
一個IA標識符子域被構造成一個Iksubfld。IA標識符必須以一種確保唯一的方式被分
配。這可以在一個集中或分層的結構上使用。
5.2.1.3版本/滿期子域
一個版本/滿期子域被構造成一個Iksubfld。版本/滿期子域格式可以在不同的IAs中變
動，但是必須滿足一定的功能約束。一個IA的版本/滿期子域必須能足夠為一個給定被鑒別
的實體區別被IA發行的IK組件集。單調增加的數的使用足以區別被一個IA提供給一個實
體的IK組件；一個時間戳的使用又允許一個被指定給一個IK組件的滿期時間或日期。
5.2.2IK加密期發行
一個IK的加密期部分是在密鑰間接管理和撤回響應之間的折中規定，它將不需要在一
個使用IK組件加密的消息接收前永久的刪除一個IK組件，這將使這個消息永久不可識別。
將需要獲取一個過期的IK組件，例如，處理被一個已經超過一個期限不活動的使用者（或
系統）接收的郵件。為了使非常舊的IK組件被刪除，一個需要被加密的本地長時間存儲的
消息的接收者應該通過使用本地維護的IK重加密轉換被用于消息文本加密的DEK，而不是
依賴于IA無限期的維護舊的IK組件。
6.用戶命名
6.1當前的方法
為了正確的選擇相應的密鑰對電子郵件的使用者進行唯一的命名是一個重要的課題并
已進行了仔細的研究。我們當前的把IK組件和用戶名聯系起來的結構以一種通用的方式表
示為（user@domain-qualified-host），依賴于以下的屬性：
1. 通用的形式必須通過一個IA說明的當這個IA分發IK組件并當它處理被接收
的IK組件和IK組件標識符時用戶的代理可以識別。如果一個UA或IA以本
地的形式使用地址不同于通用的形式，它必須能在通用形式和本地表示之間進
行明確的映射。
2. 通用形式，當被一個發送者的UA處理時，必須和被用戶規定的一個接收者地
址的形式有一個可以辨認的通信。
在整個Internet上保證這些屬性是困難的。例如，一個對在一個組織內部使用的本地形
式和被用于整個Internet郵件傳輸使用的通用形式之間進行轉換的郵件傳輸系統可能違反屬
性2
6.2發行考慮
平面的（非層次）電子郵件使用者標識符的使用，與用戶所在的主機無關，可以提供價
值。當路徑服務器變得更普遍，尋找需要的基于這種屬性的接收者對于可能成為的發送者來
說是合適的。個人的特色，像社會安全號，是可以考慮的。個別被選擇的標識符能被中央權
威機構注冊，但是一個解決這種名字沖突的手段是必要的。
特殊注意點是為一個個體容納多個名字的需要，為了代表和允許個體可能扮演的多個角
色代理。一個命名機制綁定用戶到需要的密鑰。綁定不可能是不變的因此角色有時改變（例
如，一個公司的審計員被解雇）。
檢查擴展DARPA/DoD域名系統是適宜的并且它和名字服務器相連解決對于單獨用戶
ID的用戶名。一個額外的發行和郵件列表的支持一起出現：名字服務器當前沒有執行用戶
列表的擴展（潛在遞歸的）。ISO和CSNet正在研究用戶級的路徑服務機制，也可以進行考
慮。
7.用戶接口和實現的例子
為了將在本RFC中討論的機制和方法放入到設備環境中，這一節介紹了一個原型實現。
這個實現是一個被用戶調用的獨立的程序，分散在存在的用戶的子層。這樣一個程序能被調
用作為一個在電子郵件用戶代理或文本編輯器內的過濾器，簡化必須被用戶操作的的操作順
序。這個集成形式提供了程序和一定范圍UA程序一起使用的優勢，而不是僅僅和一個特殊
的UA兼容。
當一個用戶希望對一個發出的消息應用保密增強，用戶準備消息的文本并調用單獨的程
序（和程序相互作用為了提供地址信息和其它進行保密增強處理需要的數據），依次產生適
合通過UA傳輸的輸出。當一個用戶接收到一個保密增強消息，UA以被加密的形式傳送消
息，適于被單獨的程序解密和做相關處理。
在這個原型（基于對稱密鑰管理）IK組件的存儲被維護在一個本地的文件中，輸入項
基于發送者和接收者提供的信息手工管理。這個存儲是一個有效簡單的數據庫。IK組件被
選擇用于傳送基于發送者識別和接收者名字的消息，相應的“X-Sender-ID：”和
“X-Recipient-ID：”被放置在消息的頭。當一個消息被接收，這些域被用作一個在數據庫查
循的基礎，服從合適的IK組件入口。DEKs和IVs在程序中動態產生。
選項和目的地址通過傳給單獨程序的命令行參數選擇。規定對于保密增強郵件目的地址
功能邏輯上不同于規定對應于到被MTS使用的UA的地址的功能。這一分別是由于在許多
情況下被規定在一個UA中的一個地址的本地形式和使用在“X-Sender-ID：”和
“X-Recipient-ID：”域中的互連網全球形式不同。
8.進一步研究的領域
定義在本RFC中的過程足以支持在Internet互操作方的保密增強電子郵件傳送的實現。
將需要進一步的努力，然而，為了增強健壯性，一般性，和互操作性。特別以下的領域需要
進一步研究：
1．用戶命名技術，和他們與域名系統，名字服務器，路徑服務，和密鑰管理功能的聯
系。
2．發行機構和路徑服務功能和交互的詳細的標準。
3．和X.400郵件保密增強的互操作性。
我們期待以后的RFC文檔將針對這些課題。
9.參考
這一節標識了可能對于那些打算使用本文檔中定義的機制有用的背景參考。

ISO7498/Part2-SecurityArchitecture,preparedbyISO/TC97/SC
21/WG1AdhocgrouponSecurity,extendstheOSIBasicReference
Modeltocoversecurityaspectswhicharegeneralarchitectural
elementsofcommunicationsprotocols,andprovidesanannexwith
tutorialandbackgroundinformation.

USFederalInformationProcessingStandardsPublication(FIPS
PUB)46,DataEncryptionStandard,15January1977,definesthe
enciphermentalgorithmusedformessagetextencryptionand
MessageAuthenticationCode(MAC)computation.

FIPSPUB81,DESModesofOperation,2December1980,defines
specificmodesinwhichtheDataEncryptionStandardalgorithm
maytobeusedtoperformencryption.

FIPSPUB113,ComputerDataAuthentication,May1985,definesa
specificprocedureforuseoftheDataEncryptionStandard
algorithmtocomputeaMAC.
注意：
[1]KeygenerationforMICcomputationandmessagetextencryption
mayeitherbeperformedbythesendinghostorbyacentralized
server.ThisRFCdoesnotconstrainthisdesignalternative.
Section5.1identifiespossibleadvantagesofacentralized
serverapproachifsymmetrickeymanagementisemployed.

[2]AmericanNationalStandardDataEncryptionAlgorithm(ANSI
X3.92-1981),AmericanNationalStandardsInstitute,Approved30
December1980.

[3]FederalInformationProcessingStandardsPublication46,Data
EncryptionStandard,15January1977.

[4]InformationProcessingSystems:DataEncipherment:Modesof
Operationofa64-bitBlockCipher.

[5]FederalInformationProcessingStandardsPublication81,DES
ModesofOperation,2December1980.

[6]ANSIX9.17-1985,AmericanNationalStandard,Financial
InstitutionKeyManagement(Wholesale),AmericanBankers
Association,April4,1985,Section7.2.

[7]Postel,J.,"SimpleMailTransferProtocol"RFC-821,
USC/InformationSciencesInstitute,August1982.

[8]ThistransformationshouldoccuronlyatanSMTPendpoint,notat
aninterveningrelay,butmaytakeplaceatagatewaysystem
linkingtheSMTPrealmwithotherenvironments.

[9]UseoftheSMTPcanonicalizationprocedureatthisstagewas
selectedsinceitiswidelyusedandimplementedintheInternet
community,notbecauseSMTPinteroperabilitywiththis
intermediateresultisrequired;noprivacy-enhancedmessagewill
bepassedtoSMTPfortransmissiondirectlyfromthisstepinthe
four-phasetransformationprocedure.

[10]Crocker,D.,"StandardfortheFormatofARPAInternetText
Messages",RFC-822,August1982.

[11]Rose,M.andE.Stefferud,"ProposedStandardforMessage
Encapsulation",RFC-934,January1985.

[12]CCITTRecommendationX.411(1988),"MessageHandlingSystems:
MessageTransferSystem:AbstractServiceDefinitionand
Procedures".

[13]CCITTRecommendationX.509(1988),"TheDirectory-
AuthenticationFramework".

[14]Kille,S.,"MappingbetweenX.400andRFC-822",RFC-987,June
1986.

[15]FederalInformationProcessingStandardsPublication113,
ComputerDataAuthentication,May1985.

[16]AmericanNationalStandardforInformationSystems-Data
EncryptionAlgorithm-ModesofOperation(ANSIX3.106-1983),
AmericanNationalStandardsInstitute-Approved16May1983.

[17] Voydock,V.andS.Kent,"SecurityMechanismsinHigh-Level
NetworkProtocols",ACMComputingSurveys,Vol.15,No.2,Pages
135-171,June1983.
作者地址：
JohnLinn
SecureSystems
DigitalEquipmentCorporation
85SwansonRoad,BXB1-2/D04
Boxborough,MA01719-1326

Phone:508-264-5491

EMail:Linn@ultra.enet.dec.com