RFC989 日本語訳
0989 Privacy enhancement for Internet electronic mail: Part I: Messageencipherment and authentication procedures. J. Linn. February 1987. (Format: TXT=63934 bytes) (Obsoleted by RFC1040, RFC1113) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group John Linn (BBNCC)
Request for Comments: 989 IAB Privacy Task Force
February 1987
ネットワークワーキンググループジョンリン(BBNCC)はコメントのために以下を要求します。 989 IABプライバシー特別委員会1987年2月
Privacy Enhancement for Internet Electronic Mail:
Part I: Message Encipherment and Authentication Procedures
インターネット電子メールのためのプライバシー増進: 部分I: メッセージ暗号文と認証手順
STATUS OF THIS MEMO
このメモの状態
This RFC suggests a proposed protocol for the Internet community and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このRFCは改良のためのインターネットコミュニティ、要求議論、および提案のために提案されたプロトコルを勧めます。 このメモの分配は無制限です。
ACKNOWLEDGMENT
承認
This RFC is the outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. I would like to thank the following Privacy Task Force members and meeting guests for their comments and contributions at the meetings which led to the preparation of this RFC: David Balenson, Matt Bishop, Danny Cohen, Tom Daniel, Charles Fox, Morrie Gasser, Steve Kent (chairman), John Laws, Steve Lipner, Dan Nessett, Mike Padlipsky, Rob Shirey, Miles Smid, Steve Walker, and Steve Wilbur.
このRFCは一連のIAB Privacy Task Forceミーティングとそれらのミーティングのために配布された内部の働く書類の派生物です。 このRFCの準備につながったミーティングで彼らのコメントと貢献について以下のPrivacy Task Forceメンバーとミーティングゲストに感謝申し上げます: デヴィッドBalenson、マットトム・ダニエル司教(ダニー・コーエン)、チャールズフォックス、モーリー・ガッサー、スティーブ・ケント(議長)、警官、スティーブLipner、ダンNessett(マイクPadlipsky)はマイルのShirey、スミート、スティーブ・ウォーカー、およびスティーブ・ウィルバーから略奪します。
1 Executive Summary
1つの要約
This RFC defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. Detailed key management mechanisms to support these procedures will be defined in a subsequent RFC. As a goal of this initial phase, it is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or authentication is anticipated.
このRFCは、電子メール転送のためのプライバシー増進サービスをインターネットに提供するためにメッセージ暗号文と認証手順を取り組みの初期位相と定義します。 これらの手順をサポートする詳細なかぎ管理メカニズムはその後のRFCで定義されるでしょう。 この初期位相の目標として、ここで定義された手順はさまざまなかぎ管理アプローチと互換性があることを意図します、キーを暗号化するデータの暗号化のためのともに従来(左右対称の)、公開鍵の(非対称)のアプローチを含んでいて。 従来の暗号のメッセージ・テキスト暗号化、そして/または、認証の使用は予期されます。
Privacy enhancement services (confidentiality, authentication, and message integrity assurance) are offered through the use of end-to- end cryptography between originator and recipient User Agent processes, with no special processing requirements imposed on the Message Transfer System at endpoints or at intermediate relay sites. This approach allows privacy enhancement facilities to be incorporated on a site-by-site or user-by-user basis without impact on other Internet entities. Interoperability among heterogeneous components and mail transport facilities is supported.
終わりから終わりへの暗号の使用でプライバシー増進サービス(秘密性、認証、およびメッセージの保全保証)を創始者と受取人Userエージェントプロセスの間に提供します、終点において、または、中間的リレーサイトでMessage Transfer Systemに課された特別な処理所要なしで。 このアプローチは、プライバシー増進施設が他のインターネット実体に影響なしでサイトごとのユーザごとのベースで組み込んでいるのを許容します。 異種のコンポーネントとメール運送設備の相互運用性はサポートされます。
Linn, Privacy Task Force [Page 1] RFC 989 February 1987
リン、プライバシー特別委員会[1ページ]RFC989 1987年2月
2 Terminology
2 用語
For descriptive purposes, this RFC uses some terms defined in the OSI X.400 Message Handling System Model. This section replicates a portion of X.400's Section 2.2.1, "Description of the MHS Model: Overview" in order to make the terminology clear to readers who may not be familiar with the OSI MHS Model.
描写的である目的のために、このRFCはOSI X.400 Message Handling System Modelで定義されたいくつかの用語を使用します。 このセクションは「MHSの記述は以下をモデル化する」X.400のセクション2.2.1、部分を模写します。 「概要、」 用語を作るには、OSI MHS Modelに詳しくないかもしれない読者にクリアしてください。
In the [MHS] model, a user is a person or a computer application. A user is referred to as either an originator (when sending a message) or a recipient (when receiving one). MH Service elements define the set of message types and the capabilities that enable an originator to transfer messages of those types to one or more recipients.
[MHS]モデルでは、ユーザは、人かコンピュータアプリケーションです。 ユーザは創始者(メッセージを送るとき)か受取人のどちらかと呼ばれます(1を受け取るとき)。 MH Service要素は創始者がそういったタイプの人のメッセージを1人以上の受取人に移すのを可能にするメッセージタイプと能力のセットを定義します。
An originator prepares messages with the assistance of his User Agent. A User Agent (UA) is an application process that interacts with the Message Transfer System (MTS) to submit messages. The MTS delivers to one or more recipient UAs the messages submitted to it. Functions performed solely by the UA and not standardized as part of the MH Service elements are called local UA functions.
創始者は彼のUserエージェントの支援でメッセージを準備します。 Userエージェント(UA)はメッセージを提出するためにMessage Transfer System(MTS)と対話するアプリケーション・プロセスです。 MTSはそれに提出されたメッセージを1受取人UAsに提供します。 唯一UAによって実行されて、MH Service要素の一部として標準化されなかった機能は地方のUA機能と呼ばれます。
The MTS is composed of a number of Message Transfer Agents (MTAs). Operating together, the MTAs relay messages and deliver them to the intended recipient UAs, which then make the messages available to the intended recipients.
MTSは多くのMessage Transferエージェント(MTAs)で構成されます。 一緒に作動して、MTAsは意図している受取人UAsにメッセージをリレーして、それらを提供します。(次に、UAsはメッセージを意図している受取人にとって利用可能にします)。
The collection of UAs and MTAs is called the Message Handling System (MHS). The MHS and all of its users are collectively referred to as the Message Handling Environment.
UAsとMTAsの収集はMessage Handling System(MHS)と呼ばれます。 ユーザのMHSとすべてがMessage Handling Environmentとまとめて呼ばれます。
3 Services, Constraints, and Implications
3つのサービス、規制、および含意
This RFC's goal is to define mechanisms to enhance privacy for electronic mail transferred in the Internet. The facilities discussed in this RFC provide privacy enhancement services on an end-to-end basis between sender and recipient UAs. No privacy enhancements are offered for message fields which are added or transformed by intermediate relay points. Two distinct privacy enhancement service options are supported:
このRFCの目標はインターネットで移された電子メールのためにプライバシーを高めるためにメカニズムを定義することです。 このRFCで議論した施設は終わりから終わりへのベースで送付者と受取人UAsの間にプライバシー増進サービスを供給します。 プライバシー増進を全く加えられるメッセージ分野のために提供もしませんし、中間的リレーポイント変えもしません。 2つの異なったプライバシーエンハンスサービスオプションがサポートされます:
1. an option providing sender authentication and integrity
verification
1. 認証と保全検証を送付者に提供するオプション
2. an option providing sender authentication and integrity
verification in addition to confidentiality service through
encryption
2. 暗号化による秘密性サービスに加えた認証と保全検証を送付者に提供するオプション
No facility for confidentiality service in the absence of authentication is provided. Encryption and authentication facilities may be applied selectively to portions of a message's contents; this allows less sensitive portions of messages (e.g., descriptive fields)
認証がないとき秘密性サービスのための施設を全く提供しません。 暗号化と認証施設は選択的にメッセージのコンテンツの部分に適用されるかもしれません。 これはメッセージのそれほど敏感でない部分を許容します。(例えば、描写的である分野)
Linn, Privacy Task Force [Page 2] RFC 989 February 1987
リン、プライバシー特別委員会[2ページ]RFC989 1987年2月
to be processed by a recipient's delegate in the absence of the recipient's personal cryptographic keys.
受取人の個人的な暗号化キーがないとき受取人の代表によって処理されるように。
In keeping with the Internet's heterogeneous constituencies and usage modes, the measures defined here are applicable to a broad range of Internet hosts and usage paradigms. In particular, it is worth noting the following attributes:
選挙民と用法がモードであることを異種であるインターネットのもので保つのにおいて、ここで定義された測定は広範囲なインターネット・ホストと用法パラダイムに適切です。以下の属性に注意するのは特に、価値があります:
1. The mechanisms defined in this RFC are not restricted to a
particular host or operating system, but rather allow
interoperability among a broad range of systems. All
privacy enhancements are implemented at the application
layer, and are not dependent on any privacy features at
lower protocol layers.
1. このRFCで定義されたメカニズムは特定のホストかオペレーティングシステムに制限されませんが、広範囲なシステムの中にむしろ相互運用性を許容してください。すべてのプライバシー増進が、応用層で実装されて、低級プロトコル層でどんなプライバシー機能にも依存しているというわけではありません。
2. The defined mechanisms offer compatibility with non-
enhanced Internet components. Privacy enhancements will be
implemented in an end-to-end fashion which does not impact
mail processing by intermediate relay hosts which do not
incorporate privacy enhancement facilities. It is
necessary, however, for a message's sender to be cognizant
of whether a message's intended recipient implements
privacy enhancements, in order that encoding and possible
encipherment will not be performed on a message whose
destination is not equipped to perform corresponding
inverse transformations.
2. 定義されたメカニズムは非高められたインターネットコンポーネントとの互換性を提供します。 プライバシー増進は終わりから終わりへの中間的中継ホストによるメール処理に影響を与えないファッションで実装されるでしょう(プライバシー増進施設を取り入れません)。 しかしながら、メッセージの意図している受取人が、プライバシーが増進であると実装するかどうかをメッセージの送付者が認識しているのが必要です、コード化していて可能な暗号文が対応する逆さの変換を実行するために目的地を備えていないメッセージに実行されないように。
3. The defined mechanisms offer compatibility with a range of
mail transport facilities (MTAs). Within the Internet,
electronic mail transport is effected by a variety of SMTP
implementations. Certain sites, accessible via SMTP,
forward mail into other mail processing environments (e.g.,
USENET, CSNET, BITNET). The privacy enhancements must be
able to operate across the SMTP realm; it is desirable that
they also be compatible with protection of electronic mail
sent between the SMTP environment and other connected
environments.
3. 定義されたメカニズムはさまざまなメール運送設備(MTAs)との互換性を提供します。 インターネットの中では、電子メール輸送はさまざまなSMTP実装で作用します。 ある一定のSMTPを通して理解できるサイトは他のメール処理環境(例えば、USENET、CSNET、Bitnet)にメールを転送します。 プライバシー増進はSMTP分野の向こう側に作動できなければなりません。 また、それらもSMTP環境と他の関連環境の間に送る電子メールの保護と互換性があるのは、望ましいです。
4. The defined mechanisms offer compatibility with a broad
range of electronic mail user agents (UAs). A large
variety of electronic mail user agent programs, with a
corresponding broad range of user interface paradigms, is
used in the Internet. In order that an electronic mail
privacy enhancement be available to the broadest possible
user community, it is desirable that the selected mechanism
be usable with the widest possible variety of existing UA
programs. For purposes of pilot implementation, it is
desirable that privacy enhancement processing be
incorporable into a separate program, applicable to a range
of UAs, rather than requiring internal modifications to
4. 定義されたメカニズムは広範囲な電子メールユーザエージェント(UAs)との互換性を提供します。 ユーザーインタフェースパラダイムの対応する広い声域で、さまざまな電子メールユーザエージェントプログラムがインターネットで使用されます。 可能な限り広いユーザーコミュニティに利用可能です、選択されたメカニズムが可能な限り広いバラエティーの既存のUAプログラムで使用可能であることが、望ましいということになってください。電子メールプライバシー増進、プライバシー増進処理が内部の変更を必要とするよりむしろ別々のさまざまなUAsに適切なプログラムにincorporableすることであることはパイロット実装の目的のために、望ましいです。
Linn, Privacy Task Force [Page 3] RFC 989 February 1987
リン、プライバシー特別委員会[3ページ]RFC989 1987年2月
each UA with which enhanced privacy services are to be
provided.
各UAはどれがプライバシーサービスを機能アップしたかに提供されることになっています。
5. The defined mechanisms allow electronic mail privacy
enhancement processing to be performed on personal
computers (PCs) separate from the systems on which UA
functions are implemented. Given the expanding use of PCs
and the limited degree of trust which can be placed in UA
implementations on many multi-user systems, this attribute
can allow many users to process privacy-enhanced mail with
a higher assurance level than a strictly UA-based approach
would allow.
5. 定義されたメカニズムで、電子メールプライバシー増進処理はUA機能が実装されるシステムから別々のパーソナルコンピュータ(PC)に働きます。 多くのマルチユーザーシステムの上のUA実装に置くことができるPCの拡張使用と限られた度合いの信頼を考えて、多くのユーザがこの属性で厳密にUAベースのアプローチが許容するだろうより高い保証レベルでプライバシーで高められたメールを処理できます。
6. The defined mechanisms support privacy protection of
electronic mail addressed to mailing lists.
6. 定義されたメカニズムは、プライバシーがメーリングリストに扱われた電子メールの保護であるとサポートします。
In order to achieve applicability to the broadest possible range of Internet hosts and mail systems, and to facilitate pilot implementation and testing without the need for prior modifications throughout the Internet, three basic restrictions are imposed on the set of measures to be considered in this RFC:
可能な限り広範囲のインターネット・ホストとメールシステムへの適用性を達成して、パイロット実装とインターネット中の先の変更の必要性なしでテストするのを容易にするために、3つの基本的な制限がこのRFCで考えられるべき測定のセットに課されます:
1. Measures will be restricted to implementation at
endpoints and will be amenable to integration at the user
agent (UA) level or above, rather than necessitating
integration into the message transport system (e.g., SMTP
servers).
1. 測定は、メッセージ輸送システム(例えば、SMTPサーバー)への統合を必要とするよりむしろ終点の実装に制限されて、ユーザエージェント(UA)レベルで統合に従順であるか、または上になるでしょう。
2. The set of supported measures enhances rather than
restricts user capabilities. Trusted implementations,
incorporating integrity features protecting software from
subversion by local users, cannot be assumed in general.
In the absence of such features, it appears more feasible
to provide facilities which enhance user services (e.g.,
by protecting and authenticating inter-user traffic) than
to enforce restrictions (e.g., inter-user access control)
on user actions.
2. サポートしている測定のセットは制限するよりむしろユーザ能力を高めます。 一般に、地元のユーザによる転覆からソフトウェアにプロテクトをかける保全機能を取り入れて、信じられた実装を想定できません。 そのような特徴がないとき、それはユーザサービス(例えば、相互ユーザトラフィックを保護して、認証するのによる)を機能アップする施設を提供するのにおいてユーザ動作のときに制限(例えば、相互ユーザアクセスコントロール)を実施するより可能に見えます。
3. The set of supported measures focuses on a set of
functional capabilities selected to provide significant
and tangible benefits to a broad user community. By
concentrating on the most critical set of services, we
aim to maximize the added privacy value that can be
provided with a modest level of implementation effort.
3. サポートしている測定のセットは広いユーザーコミュニティへの重要で触知できる利益を提供するのが選択された1セットの機能的な能力に焦点を合わせます。 最も重要なサービスに集中することによって、私たちは、穏やかなレベルの実装取り組みを提供できる加えられたプライバシー値を最大にすることを目指します。
As a result of these restrictions, the following facilities can be provided:
これらの制限の結果、以下の施設を提供できます:
-- disclosure protection,
-- 公開保護
Linn, Privacy Task Force [Page 4] RFC 989 February 1987
リン、プライバシー特別委員会[4ページ]RFC989 1987年2月
-- sender authenticity, and
-- そして送付者の信憑性。
-- message integrity measures,
-- メッセージの保全は測定します。
but the following privacy-relevant concerns are not addressed:
しかし、以下のプライバシー関連している関心は扱われません:
-- access control,
-- コントロールにアクセスしてください。
-- traffic flow security,
-- 交通の流れセキュリティ
-- address list accuracy,
-- リスト精度を扱ってください。
-- routing control,
-- コントロールを発送します。
-- issues relating to the serial reuse of PCs by multiple users,
-- 複数のユーザによるPCの連続の再利用に関連する問題
-- assurance of message receipt and non-deniability of receipt, and
-- そしてメッセージ領収書の保証と領収書の非否認権。
-- automatic association of acknowledgments with the messages to
which they refer
-- それらが参照するメッセージがある承認の自動協会
An important goal is that privacy enhancement mechanisms impose a minimum of burden on the users they serve. In particular, this goal suggests eventual automation of the key management mechanisms supporting message encryption and authentication. In order to facilitate deployment and testing of pilot privacy enhancement implementations in the near term, however, compatibility with out- of-band (e.g., manual) key distribution must also be supported.
重要な目標はプライバシーエンハンスメカニズムが彼らが役立つユーザに最小負担を課すということです。 特に、この目標はメッセージ暗号化と認証をサポートするかぎ管理メカニズムの最後のオートメーションを示します。 しかしながら、近いうちにパイロットプライバシー増進実装の展開とテストを容易にするために、また、バンドの外(例えば、マニュアル)がある互換性の主要な分配をサポートしなければなりません。
A message's sender will determine whether privacy enhancements are to be performed on a particular message. This will necessitate mechanisms by which a sender can determine whether particular recipients are equipped to process privacy-enhanced mail. In a general architecture, these mechanisms will be based on server queries; thus, the query function could be integrated into a UA to avoid imposing burdens or inconvenience on electronic mail users.
メッセージの送付者は、プライバシー増進が特定のメッセージに実行されるかどうかことであると決心するでしょう。 これは送付者がプライバシーで高められたメールを処理するために特定の受取人に持たせるかどうかと決心できるメカニズムを必要とするでしょう。 一般的なアーキテクチャでは、これらのメカニズムはサーバ質問に基づくでしょう。 したがって、質問機能は、負担か不便を電子メールユーザに課すのを避けるためにUAと統合されるかもしれません。
4 Processing of Messages
4 メッセージの処理
4.1 Message Processing Overview
4.1 メッセージ処理概要
This subsection provides a high-level overview of the components and processing steps involved in electronic mail privacy enhancement processing. Subsequent subsections will define the procedures in more detail.
この小区分はステップが電子メールプライバシー増進処理に伴ったコンポーネントと処理のハイレベルの概要を提供します。 その後の小区分はさらに詳細に手順を定義するでしょう。
A two-level keying hierarchy is used to support privacy-enhanced message transmission:
階層構造を合わせる2レベルがプライバシーで高められたメッセージ送信をサポートするのに使用されます:
1. Data Encrypting Keys (DEKs) are used for encryption of message
1. データEncryptingキーズ(DEKs)はメッセージの暗号化に使用されます。
Linn, Privacy Task Force [Page 5] RFC 989 February 1987
リン、プライバシー特別委員会[5ページ]RFC989 1987年2月
text and for computation of message authentication codes
(MACs). DEKs are generated individually for each transmitted
message; no predistribution of DEKs is needed to support
privacy-enhanced message transmission.
テキストとメッセージの計算のために、認証は(MACs)をコード化します。 DEKsはそれぞれの伝えられたメッセージのために個別に生成されます。 プライバシーで高められたメッセージ送信はDEKsの前分配が全くサポートされる必要はありません。
2. Interchange Keys (IKs) are used to encrypt DEKs for
transmission. An IK may either be a single symmetric
cryptographic key or, where asymmetric (public-key)
cryptography is used for DEK encryption, the composition of a
public component used by an originator and a secret component
used by a recipient. Ordinarily, the same IK will be used for
all messages sent between a given originator-recipient pair
over a period of time. Each transmitted message includes a
representation of the DEK(s) used for message encryption
and/or authentication, encrypted under an individual IK per
named recipient. This representation is accompanied by an
identifier (IK ID) to enable the recipient to determine which
IK was used, and so to decrypt the representation yielding the
DEK required for message text decryption and/or MAC
verification.
2. 置き換えキーズ(IKs)は、トランスミッションのためにDEKsを暗号化するのに使用されます。 IKは単一の左右対称の暗号化キーか非対称の(公開鍵)暗号がDEK暗号化に使用されるところでの創始者によって使用された公共のコンポーネントと受取人によって使用された秘密のコンポーネントの構成のどちらかであるかもしれません。 通常、同じIKは期間の間に与えられた創始者受取人組の間に送られたすべてのメッセージに使用されるでしょう。 それぞれの伝えられたメッセージはメッセージ暗号化、そして/または、認証に中古の、そして、命名された受取人あたり1個々のIKの下で暗号化されたDEK(s)の表現を含んでいます。 識別子(IK ID)によってこの表現は伴われて、どのIKが使用されたかを決心しているので受取人が、表現のもたらすのがメッセージ・テキスト復号化、そして/または、MAC検証に必要であるDEKであると解読するのを可能にします。
An encoding procedure is employed in order to represent encrypted message text in a universally transmissible form and to enable messages encrypted on one type of system to be decrypted on a different type. Four phases are involved in this process. A plaintext message is accepted in local form, using the host's native character set and line representation. The local form is converted to a canonical message text representation, defined as equivalent to the inter-SMTP representation of message text. The canonical representation is padded to an integral multiple of eight octets, as required by the encryption algorithm. MAC computation is performed, and (if disclosure protection is required), the padded canonical representation is encrypted. The output of this step is encoded into a printable form. The printable form is composed of a restricted character set which is chosen to be universally representable across sites, and which will not be disrupted by processing within and between MTS entities.
コード化手順は、一般に伝えられるフォームに暗号化メッセージテキストを表して、1つのタイプのシステムの上でコード化されたメッセージが異なったタイプの上で解読されるのを可能にするのに使われます。 4つのフェーズがこの過程にかかわります。 ホストの固有の文字の組と線表現を使用して、地方のフォームで平文メッセージを受け入れます。 地方のフォームはメッセージ・テキストの相互SMTP表現に同じくらい同等な状態で定義された正準なメッセージ・テキスト表現に変換されます。 正準な表現は必要に応じて暗号化アルゴリズムで8つの八重奏の不可欠の倍数に水増しされます。 そして、MAC計算が実行される、(公開保護が必要であるなら)、そっと歩いている正準な表現はコード化されています。 このステップの出力は印刷可能なフォームにコード化されます。 印刷可能なフォームはサイトの向こう側に一般に「表-可能」になるように選ばれていて、実体とMTS実体の間の処理で混乱させられない制限された文字の組で構成されます。
The output of the encoding procedure is combined with a set of header fields (to be defined in Section 4.8) carrying cryptographic control information. The result is passed to the electronic mail system to be encapsulated as the text portion of a transmitted message.
コード化手順の出力は暗号の制御情報を運ぶ1セットのヘッダーフィールド(セクション4.8で定義される)に結合されます。 結果は、伝えられたメッセージのテキスト部分として要約されるために電子メール・システムに通過されます。
When a privacy-enhanced message is received, the cryptographic control fields within its text portion provide the information required for the authorized recipient to perform MAC verification and decryption on the received message text. First, the printable encoding is converted to a bitstring. If the transmitted message was encrypted, it is decrypted into the canonical representation. If the message was not encrypted, decoding from the printable form produces the canonical representation directly. The MAC is verified, and the
プライバシーで高められたメッセージが受信されているとき、テキスト部分の中の暗号の制御フィールドは認可された受取人が受け取られていているメッセージ・テキストにMAC検証と復号化を実行するのに必要である情報を提供します。 まず最初に、印刷可能なコード化はbitstringに変換されます。 伝えられたメッセージがコード化されたなら、それは正準な表現に解読されます。 メッセージがコード化されなかったなら、印刷可能なフォームから解読するのは直接正準な表現を作成します。 そしてMACが確かめられる。
Linn, Privacy Task Force [Page 6] RFC 989 February 1987
リン、プライバシー特別委員会[6ページ]RFC989 1987年2月
canonical representation is converted to the recipient's local form, which need not be the same as the sender's local form.
正準な表現は受取人の地方のフォームに変換されます。(それは、送付者の地方のフォームと同じである必要はありません)。
4.2 Encryption Algorithms and Modes
4.2 暗号化アルゴリズムとモード
For purposes of this RFC, the Block Cipher Algorithm DEA-1, defined in ISO draft international standard DIS 8227 [1] shall be used for encryption of message text and for computation of authentication codes on messages. The DEA-1 is equivalent to the Data Encryption Standard (DES), as defined in FIPS PUB 46 [2]. When used for these purposes, the DEA-1 shall be used in the Cipher Block Chaining (CBC) mode, as defined in ISO DIS 8372 [3]. The CBC mode definition in DIS 8372 is equivalent to that provided in FIPS PUB 81 [4]. A unique initializing vector (IV) will be generated for and transmitted with each encrypted electronic mail message.
このRFCの目的において、ISO草稿で定義されたBlock Cipher Algorithm DEA-1世界規格DIS8227[1]はメッセージ・テキストの暗号化とメッセージにおける認証子の計算に使用されるものとします。 DEA-1はFIPS PUB46[2]で定義されるようにデータ暗号化規格(DES)に同等です。 これらの目的に使用されると、DEA-1はCipher Block Chaining(CBC)モードで使用されるものとします、ISO DIS8372[3]で定義されるように。 DIS8372とのCBCモード定義はFIPS PUB81[4]に提供されたそれに同等です。 ユニークな初期値設定ベクトル(IV)はメッセージを、発生して、それぞれのコード化された電子メールで送られるでしょう。
An algorithm other than DEA-1 may be employed, provided that it satisfies the following requirements:
以下の要件を満たせば、DEA-1以外のアルゴリズムは使われるかもしれません:
1. it must be a 64-bit block cipher, enciphering and deciphering
in 8 octet blocks
1. 8八重奏でブロックを暗号化して、解読して、それは64ビットのブロック暗号であるに違いありません。
2. it is usable in the ECB and CBC modes defined in DIS8372
2. それはDIS8372で定義されたECBとCBCモードで使用可能です。
3. it is able to be keyed using the procedures and parameters
defined in this RFC
3. それは、このRFCで定義された手順とパラメタを用いることで合わせることができます。
4. it is appropriate for MAC computation
4. MAC計算に、それは適切です。
5. cryptographic key field lengths are limited to 16 octets
in length
5. 暗号化キーフィールド長は長さにおける16の八重奏に制限されます。
Certain operations require that one key be encrypted under another key (interchange key) for purposes of transmission. For purposes of this RFC, such encryption will be performed using DEA-1 in Electronic Codebook (ECB) mode. An optional facility is available to an interchange key provider to indicate that an associated key is to be used for encryption in another mode (e.g., the Encrypt-Decrypt- Encrypt (EDE) mode used for key encryption and decryption with pairs of 64-bit keys, as described [5] by ASC X3T1).
ある操作は、1個のキーがトランスミッションの目的のために別のキー(置き換えキー)の下でコード化されるのを必要とします。 このRFCの目的のために、そのような暗号化は、Electronic Codebook(ECB)モードでDEA-1を使用することで実行されるでしょう。 任意の施設が関連キーが別のモードにおける暗号化に使用されることになっているのを示す置き換えキープロバイダーに利用可能である、(例えば、解読する、Encrypt-(EDE) ASC X3T1で[5]について説明するとき主要な暗号化と復号化に組の64ビットのキーで使用されるモード)をコード化してください。
Future support of public key algorithms for key encryption is under consideration, and it is intended that the procedures defined in this RFC be appropriate to allow such usage. Support of key encryption modes other than ECB is optional for implementations, however. Therefore, in support of universal interoperability, interchange key providers should not specify other modes in the absence of a priori information indicating that recipients are equipped to perform key encryption in other modes.
主要な暗号化のための公開鍵アルゴリズムの今後のサポートは考慮中であります、そして、このRFCで定義された手順はそのような用法を許容するのが適切であることを意図します。 しかしながら、実現に、ECB以外の主要な暗号化モードのサポートは任意です。したがって、普遍的な相互運用性を支持して、置き換えキープロバイダーは他のモードにおける主要な暗号化を実行するために受取人に持たせるのを示す先験的な情報がないとき他のモードを指定するべきではありません。
Linn, Privacy Task Force [Page 7] RFC 989 February 1987
リン、プライバシー特別委員会[7ページ]RFC989 1987年2月
4.3 Canonical Encoding
4.3 正準なコード化
Any encryption scheme must be compatible with the transparency constraints of its underlying electronic mail facilities. These constraints are generally established based on expected user requirements and on the characteristics of anticipated endpoint transport facilities. SMTP, designed primarily for interpersonal messages and anticipating systems and transport media which may be restricted to a 7-bit character set, can transmit any 7-bit characters (but not arbitrary 8-bit binary data) in message text.
どんな暗号化計画も基本的な電子メール施設の透明規制と互換性があるに違いありません。 一般に、これらの規制は予想されたユーザ要件に基づいた予期された終点運送設備の特性の上で確立されます。 主として個人間のメッセージと7ビットの文字の組に制限されるかもしれないシステムと輸送メディアを予期するように設計されたSMTPはメッセージ・テキストでどんな7ビットのキャラクタ(しかし、任意の8ビットの2進のデータでない)も伝えることができます。
SMTP introduces other transparency constraints related to line lengths and message delimiters. Message text may not contain the string "<CR><LF>.<CR><LF>" in sequence before the end of a message, and must contain the string "<CR><LF>" at least every 1000 characters. Another important SMTP transparency issue must be noted. Although SMTP specifies a standard representation for line delimiters (ASCII <CR><LF>), numerous systems use a different native representation to delimit lines. For example, the <CR><LF> sequences delimiting lines in mail inbound to UNIX(tm) systems are transformed to single <LF>s as mail is written into local mailbox files. Lines in mail incoming to record-oriented systems (such as VAX VMS) may be converted to appropriate records by the destination SMTP [6] server. As a result, if the encryption process generated <CR>s or <LF>s, those characters might not be accessible to a recipient UA program at a destination using different line delimiting conventions. It is also possible that conversion between tabs and spaces may be performed in the course of mapping between inter-SMTP and local format; this is a matter of local option. If such transformations changed the form of transmitted ciphertext, decryption would fail to regenerate the transmitted plaintext, and a transmitted MAC would fail to compare with that computed at the destination.
SMTPは行長とメッセージデリミタに関連する他の透明規制を導入します。 メッセージ・テキストは、連続してメッセージの終わりまでにストリング「<CR><LF><CR><LF>」を含まないかもしれなくて、ストリング「<CR><LF>」を含まなければなりません。少なくともあらゆる1000のキャラクタ。 別の重要なSMTP透明問題に注意しなければなりません。 SMTPは線デリミタ(ASCII<CR><LF>)の標準の表現を指定しますが、多数のシステムは、線を区切るのに異なった固有の表現を使用します。 例えば、UNIX(tm)システムへの本国行きのメールで線を区切る<CR><LF>系列は、メールがローカルのメールボックスファイルの中に書かれているとき<LF>sを選抜するために変えられます。 記録指向のシステム(VAX VMSなどの)へのメール入来における線は、目的地SMTP[6]サーバで記録を当てるために変換されるかもしれません。その結果、暗号化の過程が<CR>sか<LF>sを発生させるなら、それらのキャラクタは目的地で異なった線を使用するのにおいて受取人UAプログラムにコンベンションを区切るのにおいてアクセスしやすくないでしょうに。 また、タブと空間の間の変換が相互SMTPと地方の形式の間のマッピングの間に実行されるのも、可能です。 これは地方選択権の問題です。 そのような変化が伝えられた暗号文のフォームを変えるなら、復号化は伝えられた平文を作り直さないでしょうに、そして、伝えられたMACは目的地で計算されるそれと比較しないでしょう。
The conversion performed by an SMTP server at a system with EBCDIC as a native character set has even more severe impact, since the conversion from EBCDIC into ASCII is an information-losing transformation. In principle, the transformation function mapping between inter-SMTP canonical ASCII message representation and local format could be moved from the SMTP server up to the UA, given a means to direct that the SMTP server should no longer perform that transformation. This approach has the disadvantage that it would imply internal file (e.g., mailbox) formats which would be incompatible with the systems on which they reside, an untenable prospect. Further, it would require modification to SMTP servers, as mail would be passed to SMTP in a different representation than it is passed at present.
固有の文字の組にはさらに厳しい影響力があるので、変換はEBCDICがあるシステムのSMTPサーバーで働きました、ASCIIへのEBCDICからの変換が情報を失う変化であるので。 原則として、SMTPサーバーから相互SMTPの正準なASCIIメッセージ表現と地方の形式の間の変形関数マッピングをUAまで動かすことができました、SMTPサーバーがもうその変化を実行するべきでないよう指示する手段を考えて。 このアプローチには、不都合があります。内部のファイル(例えば、メールボックス)を含意するだろうというのがそれらが住んでいるシステムと非互換なものをフォーマットします、支持できない見通し。 さらに、SMTPサーバーへの変更を必要とするでしょう、メールがそれが現在のところ通過されるのと異なった表現でSMTPに通過されるだろうというとき。
Our approach to this problem selects a canonical character set, uniformly representable across privacy-enhanced UAs regardless of their systems' native character sets, to transport encrypted mail text (but not electronic mail transport headers!) between endpoints.
この問題への私たちのアプローチは正準な文字の組を選択します、彼らのシステムの固有の文字の組にかかわらずプライバシーで高められたUAsの向こう側に一様に「表-可能」です、終点の間の輸送暗号化メールテキスト(しかし、電子メール輸送ヘッダーでない!)に。
Linn, Privacy Task Force [Page 8] RFC 989 February 1987
リン、プライバシー特別委員会[8ページ]RFC989 1987年2月
In this approach, an outbound privacy-enhanced message is transformed between four forms, in sequence:
このアプローチでは、外国行きのプライバシーで高められたメッセージは4つのフォームの間で系列で変えられます:
1. (Local_Form) The message text is created (e.g., via an editor)
in the system's native character set, with lines delimited in
accordance with local convention.
1. (地方の_フォーム) メッセージ・テキストはシステムの固有の文字の組で作成されます(例えば、エディタを通して)、地方のコンベンションによると、線が区切られている状態で。
2. (Canonicalize) The message text is converted to the universal
canonical form, equivalent to the inter-SMTP representation as
defined in RFC822 [7] (ASCII character set, <CR><LF> line
delimiters). (The processing required to perform this
conversion is relatively small, at least on systems whose
native character set is ASCII.)
2. (Canonicalizeします) メッセージ・テキストは普遍的な標準形に変換されます、RFC822[7](ASCII文字の組、<CR><LF>線デリミタ)で定義される相互SMTP表現に、同等です。 (この変換を実行するのに必要である処理は少なくとも固有の文字の組がASCIIであるシステムの上で比較的小さいです。)
3. (Encipher/Authenticate) A padded version of the canonical
plaintext representation is created by appending zero-valued
octets to the end of the representation until the length is an
integral multiple of 8 octets, as is required to perform
encryption in the DEA-1 CBC mode. No padding is applied if
the canonical plaintext representation's length is already a
multiple of 8 octets. This padded representation is used as
the input to the encryption function and to the MAC
computation function.
3. (暗号化するか、または認証します) 正準な平文表現のそっと歩いているバージョンは、DEA-1CBCモードにおける暗号化を実行するために長さが必要であるように8つの八重奏の不可欠の倍数になるまでの表現の終わりに無評価された八重奏を追加することによって、作成されます。 水増しは正準な平文表現の長さが既に8つの八重奏の倍数であるなら適用されていません。 このそっと歩いている表現は入力として暗号化機能と、そして、MAC計算機能に使用されます。
4. (Encode to Printable Form) The bits resulting from the
encryption operation are encoded into characters which are
universally representable at all sites, though not necessarily
with the same bit patterns (e.g., although the character "E"
is represented in an ASCII-based system as hexadecimal 45 and
as hexadecimal C5 in an EBCDIC-based system, the local
significance of the two representations is equivalent). Use
of a 64-character subset of International Alphabet IA5 is
proposed, enabling 6 bits to be represented per printable
character. (The proposed subset of characters is represented
identically in IA5 and ASCII.) Two additional characters, "="
and "*", are used to signify special processing functions.
The encoding function's output is delimited into text lines
(using local conventions), with each line containing 64
printable characters. The encoding process is performed as
follows, transforming strings of 3 arbitrary (8-bit)
characters to strings of 4 encoded characters:
4. (印刷可能なフォームへのエンコード) 必ずはありませんが、暗号化操作から生じるビットは同じビット・パターンですべてのサイトで一般に「表-可能」なキャラクタにコード化されます(例えば、キャラクタ「E」はEBCDICベースのシステムで16進45とした16進C5としたASCIIベースのシステムで代理をされますが、2つの表現のローカルの意味は同等です)。 6ビットが印刷可能なキャラクタ単位で表されるのを可能にして、国際Alphabet IA5の64文字サブセットの使用は提案されます。 (キャラクタの提案された部分集合は同様にIA5とASCIIで表されます。) 「=」と「*」という2つの添字が、特別な処理機能を意味するのに使用されます。 各線が印刷可能な64文字を含んでいて、コード化機能の出力はテキスト線(地方のコンベンションを使用する)に区切られます。 4つのコード化されたキャラクタのストリングへの(8ビット)の任意の3つのキャラクタのストリングを変えて、コード化の過程は以下の通り実行されます:
4a. Proceeding from left to right across the input characters
(considered as a contiguous bitstring), each group of 6
bits is used as an index into an array of 64 printable
characters; the character referenced by the index is
placed in the output string. These characters,
identified in Table 1, are selected so as to be
universally representable, and the set excludes
characters with particular significance to SMTP e.g.,
4a。 入力キャラクタ(隣接のbitstringをみなす)の向こう側に左から右まで続いて、6ビットの各グループはインデックスとして64の印刷可能なキャラクタのアレイに使用されます。 インデックスによって参照をつけられるキャラクタは出力ストリングに置かれます。 Table1で特定されたこれらのキャラクタが一般に「表-可能」になるように選ばれて、セットが特定の意味でSMTPまでキャラクタを除く、例えば。
Linn, Privacy Task Force [Page 9] RFC 989 February 1987
リン、プライバシー特別委員会[9ページ]RFC989 1987年2月
".", "<CR>", "<LF>").
「」、「<CR>」、「<LF>」)
4b. If fewer than 3 input characters are available in a final
quantum, zero bits are added (on the right) to form an
integral number of 6-bit groups. Output character
positions which are not required to represent actual
input data are set to a 65th reserved, universally
representable character ("="). Use of a reserved
character for padding allows compensatory processing to
be performed by a recipient, allowing the decoded message
text's length to be precisely the same as the input
message's length. A final 3-octet input quantum will be
represented as a 4 octet encoding with no terminal "=", a
2-octet input quantum will be represented as 3 octets
followed by one terminal "=", and a 1-octet input quantum
will be represented as 2 octets followed by two
occurrences of "=".
4b。 3つ未満の入力キャラクタが最終的な量子で手があくなら、ゼロ・ビットは、整数の6ビットのグループを結成するために加えられます(右で)。 実際の入力データを表すのに必要でない出力欄は65番目の予約されて、一般に「表-可能」なキャラクタ(「=」)に設定されます。 受取人は控え目なキャラクタの詰め物の使用で補償の処理が働きます、解読されたメッセージ・テキストの長さが入力メッセージの長さと正確に同じであることを許容して。 最終的な3八重奏の入力量子は端末の「=」なしでコード化される4八重奏として表されるでしょう、そして、3つの八重奏が1台の端末のそばで「=」に続いたので、2八重奏の入力量子は表されるでしょう、そして、「=」の2回の発生で2つの八重奏が続いたので、1八重奏の入力量子は表されるでしょう。
A sender may exclude one or more portions of a message from encryption/authentication processing. Explicit action is required to exclude a portion of a message from such processing; by default, encryption/authentication is applied to the entirety of message text. The user-level delimiter which specifies such exclusion is a local matter, and hence may vary between sender and recipient, but all systems should provide a means for unambiguous identification of areas excluded from encryption/authentication processing. An excluded area is represented in the inter-SMTP transmission form (universal across communicating systems) by bracketing with the reserved delimiter "*". Cryptographic state is preserved transparently across an excluded area and continued after the end of the excluded area. A printable encoding quantum (per step 4b) is completed before the delimiter "*" is output to initiate or terminate the representation of an excluded block. Note that the canonicalizing transformation (step 2 above) and the encoding to printable form (step 4 above) are applied to all portions of message text, even those excluded from encryption and authentication.
送付者は暗号化/認証処理からメッセージの複数の部分を除くかもしれません。 明白な動作がそのような処理にメッセージの部分を入れないようにするのに必要です。 デフォルトで、暗号化/認証はメッセージ・テキストの全体に適用されます。 そのような除外を指定するユーザレベルデリミタは、地域にかかわる事柄であり、したがって、送付者と受取人の間で異なるかもしれませんが、すべてのシステムが暗号化/認証処理から除かれた領域の明確な同定のための手段を提供するはずです。 除かれた領域は、相互SMTPトランスミッションフォームに予約されたデリミタ「*」で腕木を付けることによって、(交信システムの向こう側に普遍的)で表されます。 暗号の状態は、除かれた領域の向こう側に透明に保持されて、除かれた領域の端の後に続けられています。 デリミタ「*」が除かれたブロックの表現を開始するか、または終えるために出力される前に印刷可能なコード化量子(ステップ4bあたりの)は完成します。 canonicalizing変化(上のステップ2)と印刷可能なフォームへのコード化(上のステップ4)がメッセージ・テキスト(暗号化と認証から除かれたものさえ)のすべての部分に適用されることに注意してください。
In summary, the outbound message is subjected to the following composition of transformations:
概要では、外国行きのメッセージは変化の以下の構成にかけられます:
Transmit_Form = Encode(Encipher(Canonicalize(Local_Form)))
_フォーム=エンコードを伝えてください。(暗号化します(Canonicalize(地方の_フォーム)))
The inverse transformations are performed, in reverse order, to process inbound privacy-enhanced mail:
逆さの変化は本国行きのプライバシーで高められたメールを処理するために逆順で実行されます:
Local_Form = DeCanonicalize(Decipher(Decode(Transmit_Form)))
地方の_フォーム=DeCanonicalize(暗号文の解読(解読してください(_書式を伝えてください)))
Note that the local form and the functions to transform messages to and from canonical form may vary between the sender and recipient systems without loss of information.
標準形と標準形からのメッセージを変える地方のフォームと機能が送付者と受取人システムの間で情報の損失なしで異なるかもしれないことに注意してください。
Linn, Privacy Task Force [Page 10] RFC 989 February 1987
リン、プライバシー特別委員会[10ページ]RFC989 1987年2月
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 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y (1) *
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 / 13 N 30 e 47 v 14 O 31 f 48 w (pad) = 15 P 32 g 49 x 16 Q 33 h 50 y (1) *
(1) The character "*" is used to delimit portions of an
encoded message to which encryption/authentication
processing has not been applied.
(1) The character "*" is used to delimit portions of an encoded message to which encryption/authentication processing has not been applied.
Printable Encoding Characters
Table 1
Printable Encoding Characters Table 1
4.4 Encapsulation Mechanism
4.4 Encapsulation Mechanism
Encapsulation of privacy-enhanced messages within an enclosing layer of headers interpreted by the electronic mail transport system offers a number of advantages in comparison to a flat approach in which certain fields within a single header are encrypted and/or carry cryptographic control information. Encapsulation provides generality and segregates fields with user-to-user significance from those transformed in transit. As far as the MTS is concerned, information incorporated into cryptographic authentication or encryption processing will reside in a message's text portion, not its header portion.
Encapsulation of privacy-enhanced messages within an enclosing layer of headers interpreted by the electronic mail transport system offers a number of advantages in comparison to a flat approach in which certain fields within a single header are encrypted and/or carry cryptographic control information. Encapsulation provides generality and segregates fields with user-to-user significance from those transformed in transit. As far as the MTS is concerned, information incorporated into cryptographic authentication or encryption processing will reside in a message's text portion, not its header portion.
The encapsulation mechanism to be used for privacy-enhanced mail is derived from that described in RFC934 [8] which is, in turn, based on precedents in the processing of message digests in the Internet community. To prepare a user message for encrypted or authenticated transmission, it will be transformed into the representation shown in Figure 1. Note that, while encryption and/or authentication processing of transmitted mail may depend on information contained in the enclosing header (e.g., "To:"), all fields inserted in the course of encryption/authentication processing are placed in the encapsulated header. This facilitates compatibility with mail handling programs which accept only text, not header fields, from input files or from other programs. Further, privacy enhancement
The encapsulation mechanism to be used for privacy-enhanced mail is derived from that described in RFC934 [8] which is, in turn, based on precedents in the processing of message digests in the Internet community. To prepare a user message for encrypted or authenticated transmission, it will be transformed into the representation shown in Figure 1. Note that, while encryption and/or authentication processing of transmitted mail may depend on information contained in the enclosing header (e.g., "To:"), all fields inserted in the course of encryption/authentication processing are placed in the encapsulated header. This facilitates compatibility with mail handling programs which accept only text, not header fields, from input files or from other programs. Further, privacy enhancement
Linn, Privacy Task Force [Page 11] RFC 989 February 1987
Linn, Privacy Task Force [Page 11] RFC 989 February 1987
processing can be applied recursively.
processing can be applied recursively.
Sensitive data should be protected by incorporating the data within the encapsulated text rather than by applying measures selectively to fields in the enclosing header. Examples of potentially sensitive header information may include fields such as "Subject:", with contents which are significant on an end-to-end, inter-user basis. The (possibly empty) set of headers to which protection is to be applied is a user option. If an authenticated version of header information is desired, that data can be replicated within the encapsulated text portion in addition to its inclusion in the enclosing header. If a user wishes disclosure protection for header fields, they must occur only in the encapsulated text and not in the enclosing or encapsulated header. If disclosure protection is desired for the "Subject:" field, it is recommended that the enclosing header contain a "Subject:" field indicating that "Encrypted Mail Follows".
Sensitive data should be protected by incorporating the data within the encapsulated text rather than by applying measures selectively to fields in the enclosing header. Examples of potentially sensitive header information may include fields such as "Subject:", with contents which are significant on an end-to-end, inter-user basis. The (possibly empty) set of headers to which protection is to be applied is a user option. If an authenticated version of header information is desired, that data can be replicated within the encapsulated text portion in addition to its inclusion in the enclosing header. If a user wishes disclosure protection for header fields, they must occur only in the encapsulated text and not in the enclosing or encapsulated header. If disclosure protection is desired for the "Subject:" field, it is recommended that the enclosing header contain a "Subject:" field indicating that "Encrypted Mail Follows".
A specific point regarding the integration of privacy-enhanced mail facilities with the message encapsulation mechanism is worthy of note. The subset of IA5 selected for transmission encoding intentionally excludes the character "-", so encapsulated text can be distinguished unambiguously from a message's closing encapsulation boundary (Post-EB) without recourse to character stuffing.
A specific point regarding the integration of privacy-enhanced mail facilities with the message encapsulation mechanism is worthy of note. The subset of IA5 selected for transmission encoding intentionally excludes the character "-", so encapsulated text can be distinguished unambiguously from a message's closing encapsulation boundary (Post-EB) without recourse to character stuffing.
4.5 Processing for Authentication Without Confidentiality
4.5 Processing for Authentication Without Confidentiality
When a message is to be authenticated without confidentiality service, a DEK is generated [9] for use in MAC computation, and a MAC is computed using that DEK. For each individually identified recipient, an IK is selected and identified with an "X-IK-ID:" field. Each "X-IK-ID:" field is followed by an "X-Key-Info:" field which transfers the key under which MAC computation was performed, encrypted under the IK identified by the preceding "X-IK-ID:" field, along with a representation of the MAC encrypted under the same IK. The encapsulated text portion following the encapsulated header is canonically encoded, and coded into printable characters for transmission, but not encrypted.
When a message is to be authenticated without confidentiality service, a DEK is generated [9] for use in MAC computation, and a MAC is computed using that DEK. For each individually identified recipient, an IK is selected and identified with an "X-IK-ID:" field. Each "X-IK-ID:" field is followed by an "X-Key-Info:" field which transfers the key under which MAC computation was performed, encrypted under the IK identified by the preceding "X-IK-ID:" field, along with a representation of the MAC encrypted under the same IK. The encapsulated text portion following the encapsulated header is canonically encoded, and coded into printable characters for transmission, but not encrypted.
Linn, Privacy Task Force [Page 12] RFC 989 February 1987
Linn, Privacy Task Force [Page 12] RFC 989 February 1987
Enclosing Header Portion
Enclosing Header Portion
(Contains header fields per RFC-822)
(Contains header fields per RFC-822)
Blank Line
Blank Line
(Separates Enclosing Header from Encapsulated Message)
(Separates Enclosing Header from Encapsulated Message)
Encapsulated Message
Encapsulated Message
Pre-Encapsulation Boundary (Pre-EB)
Pre-Encapsulation Boundary (Pre-EB)
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
Encapsulated Header Portion
Encapsulated Header Portion
(Contains encryption control fields inserted in plaintext.
Examples include "X-IV:", "X-IK-ID:", "X-Key-Info:",
and "X-Pad-Count:". Note that, although these control
fields have line-oriented representations similar to
RFC-822 header fields, the set of fields valid in this
context is disjoint from those used in RFC-822 processing.)
(Contains encryption control fields inserted in plaintext. Examples include "X-IV:", "X-IK-ID:", "X-Key-Info:", and "X-Pad-Count:". Note that, although these control fields have line-oriented representations similar to RFC-822 header fields, the set of fields valid in this context is disjoint from those used in RFC-822 processing.)
Blank Line
Blank Line
(Separates Encapsulated Header from subsequent encoded
Encapsulated Text Portion)
(Separates Encapsulated Header from subsequent encoded Encapsulated Text Portion)
Encapsulated Text Portion
Encapsulated Text Portion
(Contains message data encoded as specified in Section 4.3;
may incorporate protected copies of "Subject:", etc.)
(Contains message data encoded as specified in Section 4.3; may incorporate protected copies of "Subject:", etc.)
Post-Encapsulation Boundary (Post-EB)
Post-Encapsulation Boundary (Post-EB)
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
Message Encapsulation
Figure 1
Message Encapsulation Figure 1
4.6 Processing for Authentication and Confidentiality
4.6 Processing for Authentication and Confidentiality
When a message is to be authenticated with confidentiality service, a DEK is generated for use in MAC computation and a variant of the DEK is formed for use in message encryption. For each individually identified recipient, an IK is selected and identified with an "X- IK-ID:" field. Each "X-IK-ID:" field is followed by an "X-Key-Info:" field, which transfers the DEK and computed MAC, each encrypted under the IK identified in the preceding "X-IK-ID:" field. The encapsulated text portion following the encapsulated header is canonically encoded, encrypted, and coded into printable characters
When a message is to be authenticated with confidentiality service, a DEK is generated for use in MAC computation and a variant of the DEK is formed for use in message encryption. For each individually identified recipient, an IK is selected and identified with an "X- IK-ID:" field. Each "X-IK-ID:" field is followed by an "X-Key-Info:" field, which transfers the DEK and computed MAC, each encrypted under the IK identified in the preceding "X-IK-ID:" field. The encapsulated text portion following the encapsulated header is canonically encoded, encrypted, and coded into printable characters
Linn, Privacy Task Force [Page 13] RFC 989 February 1987
Linn, Privacy Task Force [Page 13] RFC 989 February 1987
for transmission.
for transmission.
4.7 Mail for Mailing Lists
4.7 Mail for Mailing Lists
When mail is addressed to mailing lists, two different methods of processing can be applicable: the IK-per-list method and the IK-per- recipient method. The choice depends on the information available to the sender and on the sender's preference.
When mail is addressed to mailing lists, two different methods of processing can be applicable: the IK-per-list method and the IK-per- recipient method. The choice depends on the information available to the sender and on the sender's preference.
If a message's sender addresses a message to a list name or alias, use of an IK associated with that name or alias as a entity (IK-per- list), rather than resolution of the name or alias to its constituent destinations, is implied. Such an IK must, therefore, be available to all list members. This alternative will be the normal case for messages sent via remote exploder sites, as a sender to such lists may not be cognizant of the set of individual recipients. Unfortunately, it implies an undesirable level of exposure for the shared IK, and makes its revocation difficult. Moreover, use of the IK-per-list method allows any holder of the list's IK to masquerade as another sender to the list for authentication purposes.
If a message's sender addresses a message to a list name or alias, use of an IK associated with that name or alias as a entity (IK-per- list), rather than resolution of the name or alias to its constituent destinations, is implied. Such an IK must, therefore, be available to all list members. This alternative will be the normal case for messages sent via remote exploder sites, as a sender to such lists may not be cognizant of the set of individual recipients. Unfortunately, it implies an undesirable level of exposure for the shared IK, and makes its revocation difficult. Moreover, use of the IK-per-list method allows any holder of the list's IK to masquerade as another sender to the list for authentication purposes.
If, in contrast, a message's sender is equipped to expand the destination mailing list into its individual constituents and elects to do so (IK-per-recipient), the message's DEK and MAC will be encrypted under each per-recipient IK and all such encrypted representations will be incorporated into the transmitted message. (Note that per-recipient encryption is required only for the relatively small DEK and MAC quantities carried in the X-Key-Info field, not for the message text which is, in general, much larger.) Although more IKs are involved in processing under the IK-per- recipient method, the pairwise IKs can be individually revoked and possession of one IK does not enable a successful masquerade of another user on the list.
If, in contrast, a message's sender is equipped to expand the destination mailing list into its individual constituents and elects to do so (IK-per-recipient), the message's DEK and MAC will be encrypted under each per-recipient IK and all such encrypted representations will be incorporated into the transmitted message. (Note that per-recipient encryption is required only for the relatively small DEK and MAC quantities carried in the X-Key-Info field, not for the message text which is, in general, much larger.) Although more IKs are involved in processing under the IK-per- recipient method, the pairwise IKs can be individually revoked and possession of one IK does not enable a successful masquerade of another user on the list.
4.8 Summary of Added Header and Control Fields
4.8 Summary of Added Header and Control Fields
This section summarizes the syntax and semantics of the new header and control fields to be added to messages in the course of privacy enhancement processing, indicating whether a particular field occurs in a message's encapsulated header portion or its encapsulated text portion. Figure 2 shows the appearance of a small example encapsulated message using these fields. In all cases, hexadecimal quantities are represented as contiguous strings of digits, where each digit is represented by a character from the ranges "0"-"9" or upper case "A"-"F". Unless otherwise specified, all arguments are to be processed in a case-sensitive fashion.
This section summarizes the syntax and semantics of the new header and control fields to be added to messages in the course of privacy enhancement processing, indicating whether a particular field occurs in a message's encapsulated header portion or its encapsulated text portion. Figure 2 shows the appearance of a small example encapsulated message using these fields. In all cases, hexadecimal quantities are represented as contiguous strings of digits, where each digit is represented by a character from the ranges "0"-"9" or upper case "A"-"F". Unless otherwise specified, all arguments are to be processed in a case-sensitive fashion.
Although the encapsulated header fields resemble RFC-822 header fields, they are a disjoint set and will not in general be processed by the same parser which operates on enclosing header fields. The complexity of lexical analysis needed and appropriate for
Although the encapsulated header fields resemble RFC-822 header fields, they are a disjoint set and will not in general be processed by the same parser which operates on enclosing header fields. The complexity of lexical analysis needed and appropriate for
Linn, Privacy Task Force [Page 14] RFC 989 February 1987
Linn, Privacy Task Force [Page 14] RFC 989 February 1987
encapsulated header field processing is significantly less than that appropriate to RFC-822 header processing. For example, many characters with special significance to RFC-822 at the syntactic level have no such significance within encapsulated header fields.
encapsulated header field processing is significantly less than that appropriate to RFC-822 header processing. For example, many characters with special significance to RFC-822 at the syntactic level have no such significance within encapsulated header fields.
The "X-IK-ID" and "X-Key-Info" fields are the only encapsulated header fields with lengths which can vary beyond a size conveniently printable on a line. Whitespace may be used between the subfields of these fields to fold them in the manner of RFC-822; such whitespace is not to be interpreted as a part of a subfield.
The "X-IK-ID" and "X-Key-Info" fields are the only encapsulated header fields with lengths which can vary beyond a size conveniently printable on a line. Whitespace may be used between the subfields of these fields to fold them in the manner of RFC-822; such whitespace is not to be interpreted as a part of a subfield.
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
X-Proc-Type: 1,E
X-Pad-Count: 1
X-IV: F8143EDE5960C597
X-IK-ID: JL:3:ECB
X-Key-Info: 9FD3AAD2F2691B9A,B70665BB9BF7CBCD
X-IK-ID: JL:1:ECB
X-Key-Info: 161A3F75DC82EF26,E2EF532C65CBCFF7
-----PRIVACY-ENHANCED MESSAGE BOUNDARY----- X-Proc-Type: 1,E X-Pad-Count: 1 X-IV: F8143EDE5960C597 X-IK-ID: JL:3:ECB X-Key-Info: 9FD3AAD2F2691B9A,B70665BB9BF7CBCD X-IK-ID: JL:1:ECB X-Key-Info: 161A3F75DC82EF26,E2EF532C65CBCFF7
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
dXd/H5LMDWnonNvPCwQUHt==
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M 8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot dXd/H5LMDWnonNvPCwQUHt== -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
Example Encapsulated Message
Figure 2
Example Encapsulated Message Figure 2
X-IK-ID: This field is placed in the encapsulated header
portion of a message to identify the Interchange Key
used for encryption of an associated Data Encrypting
Key or keys (used for message text encryption and/or
MAC computation). This field is used for messages
authenticated without confidentiality service and for
messages authenticated with confidentiality service.
The field contains (in order) an Issuing Authority
subfield and an IK Qualifier subfield, and may also
contain an optional IK Use Indicator subfield. The
subfields are delimited by the colon character (":"),
optionally followed by whitespace. Section 5.1.2,
Interchange Keys, discusses the semantics of these
subfields and specifies the alphabet from which they
are chosen. Note that multiple X-IK-ID fields may
occur within a single encapsulated header. Each X-
IK-ID field is associated with an immediately
subsequent X-Key-Info field.
X-IK-ID: This field is placed in the encapsulated header portion of a message to identify the Interchange Key used for encryption of an associated Data Encrypting Key or keys (used for message text encryption and/or MAC computation). This field is used for messages authenticated without confidentiality service and for messages authenticated with confidentiality service. The field contains (in order) an Issuing Authority subfield and an IK Qualifier subfield, and may also contain an optional IK Use Indicator subfield. The subfields are delimited by the colon character (":"), optionally followed by whitespace. Section 5.1.2, Interchange Keys, discusses the semantics of these subfields and specifies the alphabet from which they are chosen. Note that multiple X-IK-ID fields may occur within a single encapsulated header. Each X- IK-ID field is associated with an immediately subsequent X-Key-Info field.
X-IV: This field is placed in the encapsulated header
portion of a message to carry the Initializing Vector
X-IV: This field is placed in the encapsulated header portion of a message to carry the Initializing Vector
Linn, Privacy Task Force [Page 15] RFC 989 February 1987
Linn, Privacy Task Force [Page 15] RFC 989 February 1987
used for message encryption. It is used only for
messages where confidentiality service is applied.
Following the field name, and one or more delimiting
whitespace characters, a 64-bit Initializing Vector
is represented as a contiguous string of 16
hexadecimal digits.
used for message encryption. It is used only for messages where confidentiality service is applied. Following the field name, and one or more delimiting whitespace characters, a 64-bit Initializing Vector is represented as a contiguous string of 16 hexadecimal digits.
X-Key-Info: This field is placed in a message's encapsulated
header portion to transfer two items: a DEK and a
MAC. Both items are encrypted under the IK
identified by a preceding X-IK-ID field; they are
represented as two strings of contiguous hexadecimal
digits, separated by a comma. For DEA-1, the DEK
representation will be 16 hexadecimal digits
(corresponding to a 64-bit key); this subfield can be
extended to 32 hexadecimal digits (corresponding to a
128-bit key) if required to support other algorithms.
The MAC is a 64-bit quantity, represented as 16
hexadecimal digits. The MAC is computed under an
unmodified version of the DEK. Message encryption is
performed using a variant of the DEK, formed by
modulo-2 addition of the hexadecimal quantity
F0F0F0F0F0F0F0F0 to the DEK.
X-Key-Info: This field is placed in a message's encapsulated header portion to transfer two items: a DEK and a MAC. Both items are encrypted under the IK identified by a preceding X-IK-ID field; they are represented as two strings of contiguous hexadecimal digits, separated by a comma. For DEA-1, the DEK representation will be 16 hexadecimal digits (corresponding to a 64-bit key); this subfield can be extended to 32 hexadecimal digits (corresponding to a 128-bit key) if required to support other algorithms. The MAC is a 64-bit quantity, represented as 16 hexadecimal digits. The MAC is computed under an unmodified version of the DEK. Message encryption is performed using a variant of the DEK, formed by modulo-2 addition of the hexadecimal quantity F0F0F0F0F0F0F0F0 to the DEK.
X-Pad-Count: This field is placed in the encapsulated header
portion of a message to indicate the number of zero-
valued octets which were added to pad the input
stream to the encryption function to an integral
multiple of eight octets, as required by the DEA-1
CBC encryption mode. A decimal number in the range
0-7 follows the field name, and one or more
delimiting whitespace characters. Inclusion of this
field allows disambiguation between terminal zero-
valued octets in message text (admittedly, a
relatively unlikely prospect) and zero-valued octets
inserted for padding purposes.
Xパッドカウント: この野原は必要に応じてDEA-1CBC暗号化モードで8つの八重奏の不可欠の倍数に暗号化機能に水増しするために入力ストリームを加えられた無評価された八重奏の数を示すメッセージの要約のヘッダー部分に置かれます。 範囲0-7の10進数はフィールド名と、空白キャラクタを区切る1つ以上に従います。 この分野の包含はメッセージ・テキスト(明白に比較的ありそうもない見通し)における端末の無評価された八重奏と目的を水増しするために挿入された無評価された八重奏の間の曖昧さの解消を許します。
X-Proc-Type: This field is placed in the encapsulated header
portion of a message to identify the type of
processing performed on the transmitted message. The
first subfield is a decimal version number, which
will be used if future developments make it necessary
to redefine the interpretation of encapsulated header
fields. At present, this field may assume only the
value "1". The second subfield, delimited by a
comma, assumes one of two single-character alphabetic
values: "A" and "E", to signify, respectively, (1)
authentication processing only and (2) the
combination of authentication and confidentiality
service through encryption.
X-Proc-タイプ: この野原は伝えられたメッセージに実行された処理のタイプを特定するメッセージの要約のヘッダー部分に置かれます。 最初の部分体は10進バージョン番号です。(要約のヘッダーフィールドの解釈を再定義するのが未来の発展で必要になると、その番号は使用されるでしょう)。 現在のところ、この分野は、唯一の値が「1インチ」であると仮定するかもしれません。 コンマによって区切られた2番目の部分体は2つの単独のキャラクタのアルファベット値の1つを仮定します: (1) 「A」と「E」、それぞれ意味するように、(2) 認証処理だけと認証と秘密性の組み合わせは通じて暗号化を修理します。
Linn, Privacy Task Force [Page 16] RFC 989 February 1987
リン、プライバシー特別委員会[16ページ]RFC989 1987年2月
5 Key Management
5 Key Management
5.1 Types of Keys
キーの5.1のタイプ
5.1.1 Data Encrypting Keys (DEKs)
5.1.1 キーをコード化するデータ(DEKs)
Data Encrypting Keys (DEKs) are used for encryption of message text and for computation of message authentication codes (MACs). It is strongly recommended that DEKs be generated and used on a one-time basis. A transmitted message will incorporate a representation of the DEK encrypted under an interchange key (IK) known to the authorized recipient.
データEncryptingキーズ(DEKs)はメッセージ・テキストの暗号化とメッセージ確認コード(MACs)の計算に使用されます。 DEKsが1回ベースに発生して、使用されることが強く勧められます。 伝えられたメッセージは認可された受取人にとって知られている置き換えキー(IK)の下でコード化されたDEKの表現を取り入れるでしょう。
DEK generation can be performed either centrally by key distribution centers (KDCs) or by endpoint systems. One advantage of centralized KDC-based generation is that DEKs can be returned to endpoints already encrypted under the IKs of message recipients. This reduces IK exposure and simplifies endpoint key management requirements. Further, dedicated KDC systems may be able to implement better algorithms for random key generation than can be supported in endpoint systems. On the other hand, decentralization allows endpoints to be relatively self-sufficient, reducing the level of trust which must be placed in components other than a message's originator and recipient. Moreover, decentralized DEK generation by endpoints reduces the frequency with which senders must make real- time queries of (potentially unique) servers in order to send mail, enhancing communications availability.
主要な配送センター(KDCs)か終点システムは中心でDEK世代を実行できます。集結されたKDCを拠点とする世代の1つの利点はメッセージ受取人のIKsの下で既にコード化された終点にDEKsを返すことができるということです。 これは、IK露出を抑えて、終点かぎ管理要件を簡素化します。 さらに、専用KDCシステムは無作為のキー生成には、終点システムで支持できるより良いアルゴリズムを実行できるかもしれません。他方では、分散は、終点が比較的自給自足しているのを許容します、メッセージの創始者と受取人以外のコンポーネントに置かなければならない信用のレベルを減少させて。 そのうえ、終点のそばの分散DEK世代は送付者がメールを送るためにリアルタイムを(潜在的にユニーク)のサーバの質問にしなければならない頻度を減少させます、コミュニケーションの有用性を高めて。
5.1.2 Interchange Keys (IKs)
5.1.2 置き換えキー(IKs)
Interchange Keys (IKs) are used to encrypt Data Encrypting Keys. In general, the granularity of IK usage is at the pairwise per-user level except for mail sent to address lists comprising multiple users. In order for two principals to engage in a useful exchange of privacy-enhanced electronic mail using conventional cryptography, they must first share a common interchange key. When asymmetric cryptography is used, an originator and recipient must possess appropriate public and secret components which, in composition, constitute an interchange key.
置き換えキーズ(IKs)は、Data Encryptingキーズをコード化するのに使用されます。 一般に、IK用法の粒状が複数のユーザを包括するリストを記述するために送られたメール以外の1ユーザあたりの対状レベルにあります。 従来の暗号を使用することで2人の校長がプライバシーで高められた電子メールの役に立つ交換に従事するように、彼らは最初に、一般的な置き換えキーを共有しなければなりません。 非対称の暗号が使用されているとき、創始者と受取人には、構成で置き換えキーを構成する適切な公共の、そして、秘密のコンポーネントがなければなりません。
The means by which interchange keys are provided to appropriate parties are outside the scope of this RFC, but may be centralized (e.g., via key management servers) or decentralized (e.g., via direct distribution among users). In any case, a given IK is associated with a responsible Issuing Authority (IA). When an IA generates and distributes an IK, associated control information must be provided to direct how that IK is to be used. In order to select the appropriate IK to use in message encryption, a sender must retain a correspondence between IKs and the recipients with which they are associated. Expiration date information must also be retained, in order that cached entries may be invalidated and replaced as
このRFCの範囲の外に置き換えキーがパーティーを当てるために提供される手段があります、集結されるか(例えば、かぎ管理サーバで)、または分散されるかもしれないのを除いて(例えば、ユーザの中の直接販売で)。 どのような場合でも、与えられたIKは責任があるIssuing Authority(アイオワ)に関連しています。 アイオワがIKを発生して、分配するとき、そのIKによってどう使用されていることになっているかを指示するために関連制御情報を提供しなければなりません。 メッセージ暗号化における使用への適切なIKを選択するために、送付者は彼らが関連しているIKsと受取人の間との通信を保有しなければなりません。 また、情報をキャッシュされたエントリーを無効にすることができるように保有されて、取り替えなければならない有効期限
Linn, Privacy Task Force [Page 17] RFC 989 February 1987
リン、プライバシー特別委員会[17ページ]RFC989 1987年2月
appropriate.
適切。
When a privacy-enhanced message is transmitted, an indication of the IK (or IKs, in the case of a message sent to multiple recipients) used for DEK encryption must be included. To this end, the IK ID construct is defined to provide the following data:
プライバシーで高められたメッセージが送られるとき、DEK暗号化に使用されるIK(または、複数の受取人に送られたメッセージの場合におけるIKs)のしるしを含まなければなりません。 このために、IK ID構造物は以下のデータを提供するために定義されます:
1. Identification of the relevant Issuing Authority (IA
subfield)
1. 関連Issuing Authorityの識別(アイオワ部分体)
2. Qualifier string to distinguish the particular IK within
the set of IKs distributed by the IA (IK qualifier
subfield)
2. アイオワによって分配されたIKsのセットの中で特定のIKを区別する資格を与える人ストリング(IK資格を与える人部分体)
3. (Optional) Indicator of IK usage mode (IK use indicator
subfield)
3. (任意)です。 IK用法モードのインディケータ(IKはインディケータ部分体を使用します)
The subfields of an IK ID are delimited with the colon character
(":"). The IA and IK qualifier subfields are generated from a
restricted character set, as prescribed by the following BNF (using
notation as defined in RFC-822, sections 2 and 3.3):
IK IDの部分体がコロンキャラクタと共に区切られる、(「:」、) アイオワとIK資格を与える人部分体は制限された文字の組から発生します、以下のBNFによって処方されるように(RFC-822、セクション2と3.3で定義されるように記法を使用して):
IAorIKQual := 1*ia-char
IAorIKQual:=1*ia-炭
ia-char := DIGIT / ALPHA / "'" / "+" / "(" / ")" /
"," / "." / "/" / "=" / "?" / "-" / "@" /
"%" / "!" / '"' / "_" / "<" / ">"
:=DIGIT/アルファー/をia炭にしてください。「「'」 「/「+」/「(「/」)」/」、/」、」、' / "/" / "=" / "?" / "-" / "@" / "%" / "!" /'「'/"_"/"<"/">"'」
The IK use indicator subfield assumes a value from a small set of reserved strings, described later in this section.
IKは部分体が後でこのセクションで説明された小さいセットの予約されたストリングから値を仮定するというインディケータを使用します。
IA identifiers must be assigned in a manner which assures uniqueness. This can be done on a centralized or hierarchic basis.
ユニークさを保証する方法でアイオワ識別子を割り当てなければなりません。 集結されたか階層的なベースでこれができます。
The IK qualifier string format may vary among different IAs, but must satisfy certain functional constraints. An IA's IK qualifiers must be sufficient to distinguish among the set of IKs issued by that IA. Since a message may be sent with multiple IK IDs, corresponding to multiple intended recipients, each recipient must be able to determine which IK is intended for it. Moreover, if no corresponding IK is available in the recipient's database when a message arrives, the recipient must be able to determine which IK to request and to identify that IK's associated IA. Note that different IKs may be used for different messages between a pair of communicants. Consider, for example, one message sent from A to B and another message sent (using the IK-per-list method) from A to a mailing list of which B is a member. The first message would use an IK shared between A and B, but the second would use an IK shared among list members.
IK資格を与える人記号列の書式は、異なったIAsの中で異なるかもしれませんが、ある関数制約条件を満たさなければなりません。 アイオワのIK資格を与える人はそのアイオワによって発行されたIKsのセットの中で区別するとは十分であるに違いありません。 複数の意図している受取人に文通していて、複数のIK IDと共にメッセージを送るかもしれないので、それぞれの受取人は、どのIKがそれのために意図するかを決定できなければなりません。 そのうえ、メッセージが到着するとき、どんな対応するIKも受取人のデータベースで利用可能でないなら、受取人は、どのIKを要求したらよいかを決定して、そのIKの関連アイオワを特定できなければなりません。 異なったIKsが1組の聖餐拝受者の間の異なったメッセージに使用されるかもしれないことに注意してください。 例えば、1つのメッセージがAからBまで発信して、別のメッセージがAからBがメンバーであるメーリングリストまで発信した(1リストあたりのIK方法を使用する)と考えてください。 最初のメッセージはAとBとの間に共有されたIKを使用するでしょうが、2番目はリストメンバーの中で共有されたIKを使用するでしょう。
Linn, Privacy Task Force [Page 18] RFC 989 February 1987
リン、プライバシー特別委員会[18ページ]RFC989 1987年2月
While use of a monotonically increasing number as an IK qualifier is sufficient to distinguish among the set of IKs distributed by an IA, it offers no facility for a recipient lacking a matching IK to determine the appropriate IK to request. This suggests that sender and recipient name information should be incorporated into an IK qualifier, along with a number to distinguish among multiple IKs used between a sender/recipient pair. In order to support universal interoperability, it is necessary to assume a universal form for the naming information. General definition of such a form requires further study; issues and possible approaches will be noted in Section 6. As an interim measure, the following IK qualifier format is suggested:
IK資格を与える人としての単調に増加する数の使用はアイオワによって分配されたIKsのセットの中で区別するために十分ですが、それは適切なIKを決定する合っているIKを要求に欠いている受取人のために施設を全く提供しません。 これは、送付者と受取人名前情報がIK資格を与える人に組み入れられるべきであると示唆します、送付者/受取人組の間で使用される複数のIKsの中で区別する数と共に。 普遍的な相互運用性を支持するために、命名情報のための普遍的なフォームを仮定するのが必要です。 そのような形式の一般定義はさらなる研究を必要とします。 問題と可能なアプローチはセクション6に述べられるでしょう。 臨時措置として、以下のIK資格を与える人書式は示されます:
<sender-name>/<recipient-name>/<numid>
<送付者名の<受取人>/名の>/<numid>。
where <sender-name> and <recipient-name> are in the following form:
<送付者名の>と<受取人名の>が以下にあるところに、形成してください:
<user>@<domain-qualified-host>
<のユーザ>@<ドメインで適任のホスト>。
For the case of installations which transform local host names before transmission into the broader Internet, it is strongly recommended that the host name as presented to the Internet be employed. The <numid> is a contiguous string of decimal digits.
トランスミッションの前にローカル・ホスト名をより広いインターネットに変えるインストールに関するケースにおいて、インターネットに提示されるホスト名が使われることが強く勧められます。 <numid>は10進数字の隣接のストリングです。
The IK use indicator subfield is an optional facility, provided to identify the encryption mode in which the IK is to be used. Currently, this subfield may assume the following reserved string values: "ECB" and "EDE"; the default value is ECB.
IKは部分体がIKが使用されていることになっている暗号化モードを特定するために提供された任意の施設であるというインディケータを使用します。 現在、この部分体は、以下がストリング値を予約したと仮定するかもしれません: 「ECB」と"EDE"。 デフォルト値はECBです。
An example IK ID adhering to this recommendation is as follows:
この推薦を固く守る例のIK IDは以下の通りです:
ptf-kmc:linn@CCY.BBN.COM/privacy-tf@C.ISI.EDU/2:ECB
ptf-kmc: linn@CCY.BBN.COM/プライバシーtf@C.ISI.EDU/2: ECB
This IK ID would indicate that IA "ptf-kmc" has issued an IK for use on messages sent from "linn@CCY.BBN.COM" to "privacy-tf@C.ISI.EDU", that the IA has associated number 2 with that IK, and that the IK is to be used in ECB mode.
このIK IDは、アイオワ"ptf-kmc"が" linn@CCY.BBN.COM "から" privacy-tf@C.ISI.EDU "に送られたメッセージにおける使用のためにIKを発行して、アイオワにはそのIKがある近接数2があって、IKがECBモードで使用されることになっているのを示すでしょう。
IKs will remain valid for a period which will be longer than a single message and will be identified by an expiration time distributed along with the IK; IK cryptoperiod is dictated in part by a tradeoff between key management overhead and revocation responsiveness. It would be undesirable to delete an IK permanently before receipt of a message encrypted using that IK, as this would render the message permanently undecipherable. Access to an expired IK would be needed, for example, to process mail received by a user (or system) which had been inactive for an extended period of time. In order to enable very old IKs to be deleted, a message's recipient desiring encrypted local long term storage should transform the DEK used for message text encryption via re-encryption under a locally maintained IK, rather than relying on IA maintenance of old IKs for indefinite
IKsはしばらく、有効なままで残るでしょう(ただ一つのメッセージより長く、IKと共に分配された満了時間までに特定されるでしょう)。 IK cryptoperiodはかぎ管理オーバーヘッドと取消しの反応性の間の見返りで一部書き取られます。 これとしてそのIKを使用することでコード化されたメッセージの領収書が永久に非解読可能にメッセージを伝える前に永久にIKを削除するのは望ましくないでしょう。 例えば、満期のIKへのアクセスが、ユーザ(または、システム)によって受け取られた時間の長期間の間不活発であったメールを処理するのに必要でしょう。 非常に古いIKsが削除されるのを可能にするために、メッセージの受取人の望みは無期で格納が古いIKsのアイオワの維持に依存するよりむしろメッセージ・テキスト暗号化に局所的に維持されたIKの下の再暗号化で使用されるDEKを変えるべきである地方の長期をコード化しました。
Linn, Privacy Task Force [Page 19] RFC 989 February 1987
リン、プライバシー特別委員会[19ページ]RFC989 1987年2月
periods.
期間。
6 User Naming
6 ユーザ命名
Unique naming of electronic mail users, as is needed in order to select corresponding keys correctly, is an important topic and one requiring significant study. A logical association exists between key distribution and name/directory server functions; their relationship is a topic deserving further consideration. These issues have not been fully resolved at this writing. The interim architecture relies on association of IKs with user names represented in a universal form, which has the following properties:
正しく対応するキーを選択するのに必要である電子メールユーザのユニークな命名は、重要な話題と重要な研究を必要とするものです。 論理的な協会は主要な分配と名前/ディレクトリサーバ機能の間に存在します。 それらの関係は話題の値しているより遠い考慮です。 これらの問題は完全にこの文を草するときに解決されるというわけではありませんでした。 当座の構造はユーザ名が普遍的なフォームに表されている以下の特性を持っているIKsの協会を当てにします:
1. The universal form must be specifiable by an IA as it
distributes IKs and known to a UA as it processes
received IKs and IK IDs. If a UA or IA uses addresses in
a local form which is different from the universal form,
it must be able to perform an unambiguous mapping from
the universal form into the local representation.
1. IKsを分配して、容認されたIKsとIK IDを処理するのでUAにおいて知られていて、普遍的なフォームはアイオワが明記できるに違いありません。 UAかアイオワが普遍的なフォームと異なった地方のフォームでアドレスを使用するなら、普遍的なフォームからの明白なマッピングをローカルの表現に実行できなければなりません。
2. The universal form, when processed by a sender UA, must
have a recognizable correspondence with the form of a
recipient address as specified by a user (perhaps
following local transformation from an alias into a
universal form)
2. 普遍的なフォームには、送付者UAによって処理されると、ユーザによる指定されるとしての受取人アドレスのフォームとの認識可能な通信がなければなりません。(恐らく別名から普遍的なフォームに局所変形に続きます)
It is difficult to ensure these properties throughout the Internet. For example, an MTS which transforms address representations between the local form used within an organization and the global form used for Internet mail transmission may cause property 2 to be violated.
インターネット中でこれらの特性を確実にするのは難しいです。 例えば、組織の中で使用された地方のフォームとインターネット・メール送信に使用されるグローバルな用紙の間のアドレス表現を変えるMTSは特性2を違反させるかもしれません。
The use of flat (non-hierarchic) electronic mail user identifiers, which are unrelated to the hosts on which the users reside, appears useful. Personal characteristics, like social security numbers, might be considered. Individually-selected identifiers could be registered with a central authority, but a means to resolve name conflicts would be necessary.
平坦な(非階層的な)電子メールユーザ識別子の使用は役に立つように見えます。(ユーザが住んでいるホストにとって、識別子は関係ありません)。 社会保険番号のように、個人的特徴は考えられるかもしれません。 個別に選択された識別子を主要な権威に登録できましたが、名前闘争を解決する手段が必要でしょう。
A point of particular note is the desire to accommodate multiple names for a single individual, in order to represent and allow delegation of various roles in which that individual may act. A naming mechanism that binds user roles to keys is needed. Bindings cannot be immutable since roles sometimes change (e.g., the comptroller of a corporation is fired).
特定の注意のポイントは単独の個人にとって複数の名前に対応する願望です、その個人が行動するかもしれない様々な役割の代表団を代表して、許容するために。 キーにユーザの役割を縛る命名メカニズムが必要です。 役割が時々変化するので(例えば会社の会計監査官は発火します)、結合は不変であるはずがありません。
It may be appropriate to examine the prospect of extending the Domain Name System and its associated name servers to resolve user names to unique user IDs. An additional issue arises with regard to mailing list support: name servers do not currently perform (potentially recursive) expansion of lists into users. ISO and CSNet are working on user-level directory service mechanisms, which may also bear
ユニークユーザーIDにユーザ名を決議するためにドメインネームシステムとその関連ネームサーバを広げるという見通しを調べるのは適切であるかもしれません。 追加設定はメーリングリストサポートに関して起こります: ネームサーバは現在、リストの(潜在的に再帰的)の拡大をユーザに実行しません。 ISOとCSNetがユーザレベル電話番号案内メカニズムに取り組んでいる、クマ。(また、メカニズムはそうするかもしれません)。
Linn, Privacy Task Force [Page 20] RFC 989 February 1987
リン、プライバシー特別委員会[20ページ]RFC989 1987年2月
consideration.
考慮。
7 Example User Interface and Implementation
7の例のユーザーインタフェースと実現
In order to place the mechanisms and approaches discussed in this RFC into context, this section presents an overview of a prototype implementation. This implementation is a standalone program [10] which is invoked by a user, and lies above the existing UA sublayer. This form of integration offers the advantage that the program can be used in conjunction with a range of UA programs, rather than being compatible only with a particular UA. When a user wishes to apply privacy enhancements to an outgoing message, the user prepares the message's text and invokes the standalone program (interacting with the program in order to provide address information and other data required to perform privacy enhancement processing), which in turn generates output suitable for transmission via the UA. When a user receives a privacy-enhanced message, the UA delivers the message in encrypted form, suitable for decryption and associated processing by the standalone program.
このRFCで文脈と議論したメカニズムとアプローチを置くために、このセクションは原型実現の概観を提示します。 この実現はユーザによって呼び出されて、既存のUA副層を超えてあるスタンドアロンプログラム[10]です。 この形式の統合は特定のUAだけと互換性があるよりむしろさまざまなUAプログラムに関連して使用されていた状態でプログラムがあることができる利点を示します。 ユーザがプライバシー増進を送信されるメッセージに適用したがっているとき、ユーザは、メッセージのテキストを準備して、スタンドアロンプログラム(アドレス情報と他のデータを提供するためにプログラムと対話するのがプライバシー増進処理を実行するのが必要である)を呼び出します。(順番に、それは、UAを通してトランスミッションに適した出力を発生させます)。 ユーザがプライバシーで高められたメッセージを受け取るとき、UAはコード化されたフォームでメッセージを送ります、スタンドアロンプログラムは復号化と関連処理に適しています。
In this prototype implementation, a cache of IKs is maintained in a local file, with entries managed manually based on pairwise agreements between originators and recipients. This cache is, effectively, a simple database. IKs are selected for transmitted messages based on recipient names, and corresponding IK IDs are placed into the message's encapsulated header. When a message is received, the IK ID is used as a basis for a lookup in the database, yielding the appropriate IK entry. DEKs and IVs are generated dynamically within the program.
このプロトタイプ実装では、IKsのキャッシュはローカルファイルで維持されます、エントリーが創始者と受取人との対状協定に基づいた手動で管理にされるので。 事実上、このキャッシュは簡単なデータベースです。 IKsは受取人名に基づく伝えられたメッセージのために選択されます、そして、対応するIK IDはメッセージのカプセル化されたヘッダーに置かれます。 メッセージが受信されているとき、IK IDはデータベースのルックアップの基礎として使用されます、適切なIKエントリーをもたらして。 DEKsとIVsはプログラムの中でダイナミックに生成されます。
Options (e.g., authentication only vs. authentication with confidentiality service) are selected by command line arguments to the standalone program. Destination addresses are specified in the same fashion. The function of specifying destination addresses to the privacy enhancement program is logically distinct from the function of specifying the corresponding addresses to the UA for use by the MTS. This separation results from the fact that, in many cases, the local form of an address as specified to a UA differs from the Internet global form as used for IK ID fields.
オプション(例えば、認証対秘密性サービスによる認証だけ)はコマンドライン議論でスタンドアロンプログラムに選択されます。 送付先アドレスは同じファッションで指定されます。 MTSによる使用において、プライバシーエンハンスプログラムに送付先アドレスを指定する機能は論理的に対応するアドレスを指定する機能からUAまで異なっています。 この分離はUAへの指定されるとしてのアドレスの地方のフォームがIK ID分野に使用されるように多くの場合においてインターネットのグローバルなフォームと異なっているという事実から生じます。
8 Areas For Further Study
さらなる研究への8つの領域
The procedures defined in this RFC are sufficient to support pilot implementation of privacy-enhanced electronic mail transmission among cooperating parties in the Internet. Further effort will be needed, however, to enhance robustness, generality, and interoperability. In particular, further work is needed in the following areas:
このRFCで定義された手順は、協力する中のプライバシーで高められた電子メールトランスミッションのパイロット実装にインターネットのパーティーをサポートするために十分です。 しかしながら、さらなる取り組みが、丈夫さ、一般性、および相互運用性を高めるのに必要でしょう。 さらなる仕事が以下の領域で特に、必要です:
1. User naming techniques, and their relationship to the domain
system, name servers, directory services, and key management
1. ユーザ命名のテクニック、およびドメインシステム、ネームサーバ、ディレクトリサービス、およびかぎ管理とのそれらの関係
Linn, Privacy Task Force [Page 21] RFC 989 February 1987
リン、プライバシー特別委員会[21ページ]RFC989 1987年2月
functions
機能
2. Standardization of Issuing Authority functions, including
protocols for communications among IAs and between User Agents
and IAs
2. IAsとUserエージェントとIAsとのコミュニケーションのためのプロトコルを含んでいて、Issuing Authorityの規格化は機能します。
3. Use of public key encryption algorithms to encrypt data
encrypting keys
3. キーを暗号化しながらデータを暗号化する公開鍵暗号化アルゴリズムの使用
4. Interoperability with X.400 mail
4. X.400メールがある相互運用性
We anticipate generation of subsequent RFCs which will address these topics.
私たちはこれらの話題を扱うその後のRFCsの世代を予期します。
9 References
9つの参照箇所
This section identifies background references which may be useful to those contemplating use of the mechanisms defined in this RFC.
このセクションはこのRFCで定義されたメカニズムの使用を熟考するものの役に立つかもしれないバックグラウンド参照を特定します。
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.
ISO7498/第2部--Securityに関するISO.TC97/サウスカロライナ21/WG1Ad hocグループによって準備されたセキュリティArchitectureは通信規約の一般的な建築要素であるセキュリティ局面をカバーするためにOSI Basic Reference Modelを広げていて、チュートリアルと基礎的な情報を別館に提供します。
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
MAC computation.
米国の連邦政府の情報Processing Standards Publication(FIPS PUB)46、Data Encryption Standard(1977年1月15日)はメッセージ・テキスト暗号化とMAC計算に使用される暗号文アルゴリズムを定義します。
FIPS PUB 81, DES Modes of Operation, 2 December 1980, defines
specific modes in which the Data Encryption Standard algorithm
is to be used to perform encryption and MAC computation.
FIPS PUB81、OperationのDES Modes(1980年12月2日)は暗号化とMAC計算を実行するのに使用されるデータ暗号化規格アルゴリズムがことである特定のモードを定義します。
NOTES:
注意:
[1] Information Processing Systems: Data Encipherment: Block
Cipher Algorithm DEA 1.
[1] 情報処理システム: データ暗号文: 暗号アルゴリズムDEA1を妨げてください。
[2] Federal Information Processing Standards Publication 46, Data
Encryption Standard, 15 January 1977.
[2] 連邦政府の情報処理規格、公表46、データ暗号化規格、1977年1月15日。
[3] Information Processing Systems: Data Encipherment: Modes of
Operation of a 64-bit Block Cipher
[3] 情報処理システム: データ暗号文: 64ビットのブロック暗号の運転モード
[4] Federal Information Processing Standards Publication 81, DES
Modes of Operation, 2 December 1980.
[4] 連邦政府の情報処理規格、公表81、DES運転モード、1980年12月2日。
Linn, Privacy Task Force [Page 22] RFC 989 February 1987
リン、プライバシー特別委員会[22ページ]RFC989 1987年2月
[5] Addendum to the Transport Layer Protocol Definition for
Providing Connection Oriented End to End Cryptographic Data
Protection Using a 64-Bit Block Cipher, X3T1-85-50.3, draft of
19 December 1985, Gaithersburg, MD, p. 15.
[5] End Cryptographic Data Protection Using Block Cipher(X3T1-85-50.3)が作成する1985年12月19日、ゲイザースバーグ、MDの64ビットpへのProviding Connection Oriented EndのためのTransport LayerプロトコルDefinitionへの付加物。 15.
[6] 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.
[6] この変換は、介入しているリレーに起こるのではなく、SMTP終点だけに起こるべきですが、SMTP分野を他の環境にリンクしながら、ゲートウェイシステムで行われるかもしれません。
[7] Crocker, D. Standard for the Format of ARPA Internet Text
Messages (RFC822), August 1982.
[7] クロッカー、アルパインターネットテキスト・メッセージ(RFC822)の形式のD.規格、1982年8月。
[8] Rose, M. T., and Stefferud, E. A., Proposed Standard for
Message Encapsulation, January 1985.
[8] ローズ、M.T.、およびStefferud、E.A.はメッセージカプセル化、1985年1月の規格を提案しました。
[9] Key generation for authentication 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.1 identifies possible advantages of
a centralized server approach.
[9] 認証のためのキー生成とメッセージ・テキスト暗号化は送付ホストか集結されたサーバによって実行されるかもしれません。このRFCはこのデザイン代替手段を抑制しません。 セクション5.1 .1 集結されたサーバアプローチの可能な利点を特定します。
[10] Note that in the UNIX(tm) system, and possibly in other
environments as well, such a program can be invoked as a
"filter" within an electronic mail UA or a text editor,
simplifying the sequence of operations which must be performed
by the user.
[10] UNIX(tm)システム、およびことによるとまた、他の環境で、電子メールの中の「フィルタ」UAかテキストエディタとしてそのようなプログラムを呼び出すことができることに注意してください、ユーザが実行しなければならない操作の系列を簡素化して。
Linn, Privacy Task Force [Page 23]
リン、プライバシー特別委員会[23ページ]
一覧
スポンサーリンク
