組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：金鳳（phoenix_jin  take.a.bow@263.net）
譯文發布時間：2001-10-28
版權：本中文翻譯文檔版權歸中國互動出版網所有?？梢杂糜诜巧虡I用途自由轉載，但必須
保留本文檔的翻譯及版權信息。




Network Working Group                                            J. Linn
Request for Comments:  1113                                         DEC
Obsoletes RFCs: 989, 1040                         IAB Privacy Task Force
                                                                August 1989
Internet電子郵件保密增強：Part1-消息編碼和鑒別過程 
（RFC1113 ——Privacy Enhancement for Internet Electronic Mail:
      Part I -- Message Encipherment and Authentication Procedures） 


本備忘錄的狀態
本文檔講述了一種Internet社區的Internet標準跟蹤協議，它需要進一步進行討論和建
議以得到改進。請參考最新版的“Internet正式協議標準” (STD1)來獲得本協議的標準化
程度和狀態。本備忘錄的發布不受任何限制。
版權聲明
Copyright (C) The Internet Society (2001).
感謝
本文檔是internet構架委員會（IAB）保密特別委員會的一系列會議及在那些會議上分
發的internet工作報告的產物。我想感謝以下列出的保密特別委員會的成員集中了他們在會
議上的觀點和貢獻形成了這個rfc文檔：David Balenson, Curt Barker, Jim Bidzos, Matt 
Bishop, Danny Cohen, Tom Daniel, Charles Fox, Morrie Gasser, Russ Housley, Steve 
Kent (chairman), John Laws, Steve Lipner, Dan Nessett, Mike Padlipsky, Rob Shirey, 
Miles Smid, Steve Walker, and Steve Wilbur.
目錄
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.1 X-Proc-Type域	14
4.6.1.2 X-DEK-Info域	14
4.6.2 一般每個消息被封裝的頭域	15
4.6.2.1 X-Sender-ID域	15
4.6.2.2 X-Certificate域	15
4.6.2.3 X-MIC-Info域	15
4.6.3 不定出現的頭域	16
4.6.3.1 X-Issuer-Certificate域	16
4.6.4 每個接收者被封裝的頭域	16
4.6.4.1 X-Recipient-ID域	16
4.6.4.2 X-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.2 IK加密期發行	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文檔使用了定義在OSI X.400消息處理系統（1984年
經CCITT推薦）模型里的術語。這部分復制了X.400 2.2.1小節的部分內容，“MHS
模型的描述：總覽”為了使不熟悉OSI MHS模型的的讀者清楚的理解這個術語。
在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避免增加電子郵件使用者的負擔
或不便。