?? rfc1113.txt
字號:
一個版本/滿期子域被構造成一個Iksubfld。版本/滿期子域格式可以在不同的IAs中變
動,但是必須滿足一定的功能約束。一個IA的版本/滿期子域必須能足夠為一個給定被鑒別
的實體區別被IA發行的IK組件集。單調增加的數的使用足以區別被一個IA提供給一個實
體的IK組件;一個時間戳的使用又允許一個被指定給一個IK組件的滿期時間或日期。
5.2.2 IK加密期發行
一個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. 參考
這一節標識了可能對于那些打算使用本文檔中定義的機制有用的背景參考。
ISO 7498/Part 2 - Security Architecture, prepared by ISO/TC97/SC
21/WG 1 Ad hoc group on Security, extends the OSI Basic Reference
Model to cover security aspects which are general architectural
elements of communications protocols, and provides an annex with
tutorial and background information.
US Federal Information Processing Standards Publication (FIPS
PUB) 46, Data Encryption Standard, 15 January 1977, defines the
encipherment algorithm used for message text encryption and
Message Authentication Code (MAC) computation.
FIPS PUB 81, DES Modes of Operation, 2 December 1980, defines
specific modes in which the Data Encryption Standard algorithm
may to be used to perform encryption.
FIPS PUB 113, Computer Data Authentication, May 1985, defines a
specific procedure for use of the Data Encryption Standard
algorithm to compute a MAC.
注意:
[1] Key generation for MIC computation and message text encryption
may either be performed by the sending host or by a centralized
server. This RFC does not constrain this design alternative.
Section 5.1 identifies possible advantages of a centralized
server approach if symmetric key management is employed.
[2] American National Standard Data Encryption Algorithm (ANSI
X3.92-1981), American National Standards Institute, Approved 30
December 1980.
[3] Federal Information Processing Standards Publication 46, Data
Encryption Standard, 15 January 1977.
[4] Information Processing Systems: Data Encipherment: Modes of
Operation of a 64-bit Block Cipher.
[5] Federal Information Processing Standards Publication 81, DES
Modes of Operation, 2 December 1980.
[6] ANSI X9.17-1985, American National Standard, Financial
Institution Key Management (Wholesale), American Bankers
Association, April 4, 1985, Section 7.2.
[7] Postel, J., "Simple Mail Transfer Protocol" RFC-821,
USC/Information Sciences Institute, August 1982.
[8] This transformation should occur only at an SMTP endpoint, not at
an intervening relay, but may take place at a gateway system
linking the SMTP realm with other environments.
[9] Use of the SMTP canonicalization procedure at this stage was
selected since it is widely used and implemented in the Internet
community, not because SMTP interoperability with this
intermediate result is required; no privacy-enhanced message will
be passed to SMTP for transmission directly from this step in the
four-phase transformation procedure.
[10] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", RFC-822, August 1982.
[11] Rose, M. and E. Stefferud, "Proposed Standard for Message
Encapsulation", RFC-934, January 1985.
[12] CCITT Recommendation X.411 (1988), "Message Handling Systems:
Message Transfer System: Abstract Service Definition and
Procedures".
[13] CCITT Recommendation X.509 (1988), "The Directory -
Authentication Framework".
[14] Kille, S., "Mapping between X.400 and RFC-822", RFC-987, June
1986.
[15] Federal Information Processing Standards Publication 113,
Computer Data Authentication, May 1985.
[16] American National Standard for Information Systems - Data
Encryption Algorithm - Modes of Operation (ANSI X3.106-1983),
American National Standards Institute - Approved 16 May 1983.
[17] Voydock, V. and S. Kent, "Security Mechanisms in High-Level
Network Protocols", ACM Computing Surveys, Vol. 15, No. 2, Pages
135-171, June 1983.
作者地址:
John Linn
Secure Systems
Digital Equipment Corporation
85 Swanson Road, BXB1-2/D04
Boxborough, MA 01719-1326
Phone: 508-264-5491
EMail: Linn@ultra.enet.dec.com
RFC1113 ——Privacy Enhancement for Internet Electronic Mail:
Part I -- Message Encipherment and Authentication Procedures
Internet電子郵件保密增強:Part1-消息編碼和鑒別過程
24
RFC文檔中文翻譯計劃
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -