RFC1113 日本語訳
1113 Privacy enhancement for Internet electronic mail: Part I -message encipherment and authentication procedures. J. Linn. August 1989. (Format: TXT=89293 bytes) (Obsoletes RFC0989, RFC1040) (Obsoleted by RFC1421) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Linn
Request for Comments: 1113 DEC
Obsoletes RFCs: 989, 1040 IAB Privacy Task Force
August 1989
コメントを求めるワーキンググループJ.リンの要求をネットワークでつないでください: 1113 12月はRFCsを時代遅れにします: 989、1040IABプライバシー特別委員会1989年8月
Privacy Enhancement for Internet Electronic Mail:
Part I -- Message Encipherment and Authentication Procedures
インターネット電子メールのためのプライバシー増進: 部分I--メッセージ暗号文と認証手順
STATUS OF THIS MEMO
このメモの状態
This RFC suggests a draft standard elective 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, 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.
このRFCは一連のIAB Privacy Task Forceミーティングとそれらのミーティングのために配布された内部の働く書類の派生物です。 このRFCの準備につながったミーティングで彼らのコメントと貢献について以下のPrivacy Task Forceメンバーとミーティングゲストに感謝申し上げます: デヴィッドBalenson、そっけないバーカー、ジム・ビゾス、マットトム・ダニエル司教(ダニー・コーエン)、チャールズフォックス、モーリー・ガッサー、ラスHousley、スティーブ・ケント(議長)、警官、スティーブLipner、ダンNessett(マイクPadlipsky)はマイルのShirey、スミート、スティーブ・ウォーカー、およびスティーブ・ウィルバーから略奪します。
Table of Contents
目次
1. Executive Summary 2 2. Terminology 3 3. Services, Constraints, and Implications 3 4. Processing of Messages 7 4.1 Message Processing Overview 7 4.1.1 Types of Keys 7 4.1.2 Processing Procedures 8 4.2 Encryption Algorithms and Modes 9 4.3 Privacy Enhancement Message Transformations 10 4.3.1 Constraints 10 4.3.2 Approach 11 4.3.2.1 Step 1: Local Form 12 4.3.2.2 Step 2: Canonical Form 12 4.3.2.3 Step 3: Authentication and Encipherment 12 4.3.2.4 Step 4: Printable Encoding 13 4.3.2.5 Summary of Transformations 15 4.4 Encapsulation Mechanism 15 4.5 Mail for Mailing Lists 17 4.6 Summary of Encapsulated Header Fields 18
1. 要約2 2。 用語3 3。 サービス、規制、および含意3 4。 概要7 4.1に.1のタイプのキー7 4.1.2の現像処理8の4.2の暗号化アルゴリズムとモード9 4.3のプライバシー増進メッセージ変換10 4.3.1の規制10 4.3.2アプローチ11 4.3.2.1ステップ1を処理するメッセージ7 4.1メッセージの処理: 地方のフォーム12 4.3.2.2ステップ2: 標準形12 4.3.2.3ステップ3: 認証と暗号文12 4.3.2.4ステップ4: 4.5がメーリングリストのために郵送する変換15 4.4カプセル化メカニズム15の印刷可能なコード化13 4.3.2.5概要、17、4.6概要、カプセル化されたヘッダーフィールド18
Linn [Page 1] RFC 1113 Mail Privacy: Procedures August 1989
リン[1ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
4.6.1 Per-Message Encapsulated Header Fields 20 4.6.1.1 X-Proc-Type Field 20 4.6.1.2 X-DEK-Info Field 21 4.6.2 Encapsulated Header Fields Normally Per-Message 21 4.6.2.1 X-Sender-ID Field 22 4.6.2.2 X-Certificate Field 22 4.6.2.3 X-MIC-Info Field 23 4.6.3 Encapsulated Header Fields with Variable Occurrences 23 4.6.3.1 X-Issuer-Certificate Field 23 4.6.4 Per-Recipient Encapsulated Header Fields 24 4.6.4.1 X-Recipient-ID Field 24 4.6.4.2 X-Key-Info Field 24 4.6.4.2.1 Symmetric Key Management 24 4.6.4.2.2 Asymmetric Key Management 25 5. Key Management 26 5.1 Data Encrypting Keys (DEKs) 26 5.2 Interchange Keys (IKs) 26 5.2.1 Subfield Definitions 28 5.2.1.1 Entity Identifier Subfield 28 5.2.1.2 Issuing Authority Subfield 29 5.2.1.3 Version/Expiration Subfield 29 5.2.2 IK Cryptoperiod Issues 29 6. User Naming 29 6.1 Current Approach 29 6.2 Issues for Consideration 30 7. Example User Interface and Implementation 30 8. Areas For Further Study 31 9. References 32 NOTES 32
4.6.1 メッセージが、ヘッダーフィールド20が.2が通常、メッセージあたりのヘッダーフィールズ21 4.6.2.1X送付者ID分野22 4.6.2.2X-証明書分野22 4.6に.2.3X-MIC-インフォメーション分野をカプセル化した4.6.1.1X-Proc-タイプ分野20 4.6.1.2X-DEK-インフォメーション分野21 4.6であるとカプセル化した、23、4.6; 3が、可変発生23 4.6.3.1X発行人証明書分野23 4.6の.4の.2の.2の非対称のヘッダーフィールド24 4.6.4.1X受取人ID分野24 4.6.4.2X主要なインフォメーション分野24 4.6.4.2.1対称鍵であると管理24 4.6にカプセル化された.4受取人キーがあるヘッダーフィールドが管理であるとカプセル化した、25、5 キーズ(DEKs)26 5.2を暗号化するKey Management26 5.1のデータが.2IK Cryptoperiodが発行するキーズ(IKs)26 5.2.1の部分体定義28 5.2.1.1エンティティ識別名部分体28 5.2.1.2発行機関部分体29 5.2.1.3バージョン/満了部分体29 5.2を交換する、29、6 考慮30 7のためのユーザ命名29 6.1の現在のアプローチ29 6.2冊。 例のユーザーインタフェースと実装30 8。 さらなる研究31 9のための領域。 参照32注意32
1. Executive Summary
1. 要約
This RFC defines message encipherment and authentication procedures, in order to provide privacy enhancement services for electronic mail transfer in the Internet. It is one member of a related set of four RFCs. The procedures defined in the current RFC are intended to be compatible with a wide range of key management approaches, including both symmetric (secret-key) and asymmetric (public-key) approaches for encryption of data encrypting keys. Use of symmetric cryptography for message text encryption and/or integrity check computation is anticipated. RFC-1114 specifies supporting key management mechanisms based on the use of public-key certificates. RFC-1115 specifies algorithm and related information relevant to the current RFC and to RFC-1114. A subsequent RFC will provide details of paper and electronic formats and procedures for the key management infrastructure being established in support of these services.
このRFCはメッセージ暗号文と認証手順を定義します、電子メール転送のためのプライバシー増進サービスをインターネットに提供するために。 それは4RFCsの関連するセットの1人のメンバーです。 現在のRFCで定義された手順はさまざまなかぎ管理アプローチと互換性があることを意図します、左右対称の(秘密鍵)とキーを暗号化するデータの暗号化のための非対称の(公開鍵)アプローチの両方を含んでいて。 左右対称の暗号のメッセージ・テキスト暗号化、そして/または、保全チェック計算の使用は予期されます。 かぎ管理が公開鍵証明書の使用に基づくメカニズムであるとサポートしながら、RFC-1114は指定します。 RFC-1115はRFC-1114に現在のRFCと、そして、関連しているアルゴリズムと関連する情報を指定します。 その後のRFCはこれらのサービスを支持して確立されるかぎ管理インフラストラクチャに紙、電子形式、および手順の詳細を明らかにするでしょう。
Privacy enhancement services (confidentiality, authentication, and
そしてプライバシー増進サービス、(秘密性、認証。
Linn [Page 2] RFC 1113 Mail Privacy: Procedures August 1989
リン[2ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
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.
メッセージの保全保証) 終わりから終わりへの暗号の使用で、終点において、または、中間的リレーサイトでMessage Transfer Systemに課された特別な処理所要なしで創始者と受取人Userエージェントプロセスの間に提供します。 このアプローチは、プライバシー増進施設が他のインターネット実体に影響なしでサイトごとのユーザごとのベースで組み込んでいるのを許容します。 異種のコンポーネントとメール運送設備の相互運用性はサポートされます。
2. Terminology
2. 用語
For descriptive purposes, this RFC uses some terms defined in the OSI X.400 Message Handling System Model per the 1984 CCITT Recommendations. 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は1984CCITT Recommendationsあたりの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 or her User Agent (UA). A 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エージェント(UA)の支援でメッセージを準備します。 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 defines 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.
このRFCは、インターネットで移された電子メールのためにプライバシーを高めるためにメカニズムを定義します。 このRFCで議論した施設は終わりから終わりへのベースで送付者と受取人UAsの間にプライバシー増進サービスを供給します。 プライバシー増進を全く加えられるメッセージ分野のために提供もしませんし、中間的リレーポイント変えもしません。
Linn [Page 3] RFC 1113 Mail Privacy: Procedures August 1989
リン[3ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
Authentication and integrity facilities are always applied to the entirety of a message's text. No facility for confidentiality without authentication is provided. Encryption facilities may be applied selectively to portions of a message's contents; this allows less sensitive portions of messages (e.g., descriptive fields) to be processed by a recipient's delegate in the absence of the recipient's personal cryptographic keys. In the limiting case, where the entirety of message text is excluded from encryption, this feature can be used to yield the effective combination of authentication and integrity services without confidentiality.
認証と保全施設はいつもメッセージのテキストの全体に適用されます。 認証のない秘密性のための施設を全く提供しません。 暗号化施設は選択的にメッセージのコンテンツの部分に付けられるかもしれません。 これは、メッセージ(例えば、描写的である分野)の敏感な部分が受取人の個人的な暗号化キーがないとき受取人の代表によって処理されるのをそれほど許容しません。 制限場合では、秘密性なしで有効な認証であって保全サービスの組み合わせをもたらすのにこの特徴を使用できます。そこでは、メッセージ・テキストの全体が暗号化から除かれます。
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 are compatible with non-enhanced
Internet components. Privacy enhancements are 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 are compatible 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 are compatible with a broad range of
electronic mail user agents (UAs). A large variety of
4. 定義されたメカニズムは広範囲な電子メールユーザエージェント(UAs)と互換性があります。 様々
Linn [Page 4] RFC 1113 Mail Privacy: Procedures August 1989
リン[4ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
electronic mail user agent programs, with a corresponding
broad range of user interface paradigms, is used in the
Internet. In order that electronic mail privacy
enhancements be available to the broadest possible user
community, selected mechanisms should 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 each UA with which
privacy-enhanced services are to be provided.
電子メールユーザエージェントはプログラムを作って、対応で、ユーザーインタフェースパラダイムの広い声域はインターネットで使用されています。 可能な限り広いユーザーコミュニティに利用可能です、選択されたメカニズムが可能な限り広いバラエティーの既存のUAプログラムで使用可能であるべきであるということになってください。電子メールプライバシー増進、パイロット実装の目的のために、プライバシー増進処理が供給されるプライバシー高度サービスがことである各UAへの内部の変更を必要とするよりむしろ別々のプログラムにincorporableであって、さまざまなUAsに適切であることは、望ましいです。
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 (distribution
lists, in ISO parlance).
6. 定義されたメカニズムは、プライバシーがメーリングリスト(ISO話法による発送先リスト)に扱われた電子メールの保護であるとサポートします。
7. The mechanisms defined within this RFC are compatible with a
variety of supporting key management approaches, including
(but not limited to) manual pre-distribution, centralized
key distribution based on symmetric cryptography, and the
use of public-key certificates. Different key management
mechanisms may be used for different recipients of a
multicast message. While support for a particular key
management mechanism is not a minimum essential requirement
for compatibility with this RFC, adoption of the public-key
certificate approach defined in companion RFC-1114 is
strongly recommended.
7. このRFCの中で定義されたメカニズムはさまざまなサポートの主要なマネージメント・アプローチと互換性があります、(他)マニュアルプレ分配、左右対称の暗号に基づく、集結された主要な分配、および公開鍵証明書の使用を含んでいて。 異なったかぎ管理メカニズムはマルチキャストメッセージの異なった受取人に使用されるかもしれません。 特定のかぎ管理メカニズムのサポートがこのRFCとの互換性のための最小の必須の条件でない間、仲間RFC-1114で定義された公開鍵証明書アプローチの採用は強く推薦されます。
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)レベルで統合に従順であるか、または上になるでしょう。
Linn [Page 5] RFC 1113 Mail Privacy: Procedures August 1989
リン[5ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
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:
これらの制限の結果、以下の施設を提供できます:
1. disclosure protection,
1. 公開保護
2. sender authenticity,
2. 送付者の信憑性
3. message integrity measures, and
そして3. メッセージの保全が測定する。
4. (if asymmetric key management is used) non-repudiation of
origin,
4. (非対称のかぎ管理が使用されているなら) 発生源の非拒否
but the following privacy-relevant concerns are not addressed:
しかし、以下のプライバシー関連している関心は扱われません:
1. access control,
1. コントロールにアクセスしてください。
2. traffic flow confidentiality,
2. 交通の流れ秘密性
3. address list accuracy,
3. リスト精度を扱ってください。
4. routing control,
4. ルーティングコントロール
5. issues relating to the casual serial reuse of PCs by
multiple users,
5. 複数のユーザによるPCのカジュアルな連続の再利用に関連する問題
6. assurance of message receipt and non-deniability of receipt,
6. メッセージ領収書の保証と領収書の非否認権
7. automatic association of acknowledgments with the messages
to which they refer, and
そして7. それらが参照するメッセージがある承認の自動協会。
8. message duplicate detection, replay prevention, or other
8. メッセージ写し検出、何らかの再生防止
Linn [Page 6] RFC 1113 Mail Privacy: Procedures August 1989
リン[6ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
stream-oriented services.
ストリーム指向のサービス。
A message's sender will determine whether privacy enhancements are to be performed on a particular message. Therefore, a sender must be able to 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.
この小区分はステップが電子メールプライバシー増進処理に伴ったコンポーネントと処理のハイレベルの概要を提供します。 その後の小区分はさらに詳細に手順を定義するでしょう。
4.1.1 Types of Keys
4.1.1 キーのタイプ
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 text and (with certain choices among a set of
alternative algorithms) for computation of message integrity
check (MIC) quantities. DEKs are generated individually for
each transmitted message; no predistribution of DEKs is
needed to support privacy-enhanced message transmission.
1. そして、データEncryptingキーズ(DEKs)がメッセージ・テキストの暗号化に使用される、(代替のアルゴリズムのセットの中に、ある選択がある) メッセージの保全の計算がないかどうか、(MIC)量をチェックしてください。 DEKsはそれぞれの伝えられたメッセージのために個別に生成されます。 プライバシーで高められたメッセージ送信はDEKsの前分配が全くサポートされる必要はありません。
2. Interchange Keys (IKs) are used to encrypt DEKs for
transmission within messages. Ordinarily, the same IK will
be used for all messages sent from a given originator to a
given recipient over a period of time. Each transmitted
message includes a representation of the DEK(s) used for
message encryption and/or MIC computation, encrypted under
an individual IK per named recipient. The representation is
associated with "X-Sender-ID:" and "X-Recipient-ID:" fields,
which allow each individual recipient to identify the IK
used to encrypt DEKs and/or MICs for that recipient's use.
Given an appropriate IK, a recipient can decrypt the
corresponding transmitted DEK representation, yielding the
DEK required for message text decryption and/or MIC
verification. The definition of an IK differs depending on
whether symmetric or asymmetric cryptography is used for DEK
encryption:
2. 置き換えキーズ(IKs)は、メッセージの中のトランスミッションのためにDEKsを暗号化するのに使用されます。 通常、同じIKは期間の間に与えられた創始者から与えられた受取人に送られたすべてのメッセージに使用されるでしょう。 それぞれの伝えられたメッセージはメッセージ暗号化、そして/または、MIC計算に中古の、そして、命名された受取人あたり1個々のIKの下で暗号化されたDEK(s)の表現を含んでいます。 表現が関連している、「X送付者ID:」 そして、「X受取人ID:」 分野であり、それぞれの個々の受取人がどれでIKを特定できるかがその受取人の使用のために以前はよくDEKs、そして/または、MICsを暗号化していました。 適切なIKを考えて、受取人は、対応する伝えられたDEKが表現であると解読することができます、メッセージ・テキスト復号化、そして/または、MIC検証に必要であるDEKをもたらして。 左右対称の、または、非対称の暗号がDEK暗号化に使用されるかどうかによって、IKの定義は異なります:
Linn [Page 7] RFC 1113 Mail Privacy: Procedures August 1989
リン[7ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
2a. When symmetric cryptography is used for DEK
encryption, an IK is a single symmetric key shared
between an originator and a recipient. In this
case, the same IK is used to encrypt MICs as well
as DEKs for transmission. Version/expiration
information and IA identification associated with
the originator and with the recipient must be
concatenated in order to fully qualify a symmetric
IK.
2a。 左右対称の暗号がDEK暗号化に使用されるとき、IKは創始者と受取人の間で共有された単一の対称鍵です。 この場合、同じIKは、トランスミッションのためのDEKsと同様にMICsを暗号化するのに使用されます。 左右対称のIKに完全に資格を与えるためにバージョン/満了情報と創始者と受取人に関連しているアイオワの識別を連結しなければなりません。
2b. When asymmetric cryptography is used, the IK
component used for DEK encryption is the public
component of the recipient. The IK component used
for MIC encryption is the private component of the
originator, and therefore only one encrypted MIC
representation need be included per message, rather than
one per recipient. Each of these IK
components can be fully qualified in an
"X-Recipient-ID:" or "X-Sender-ID:" field,
respectively.
2b。 非対称の暗号が使用されているとき、DEK暗号化に使用されるIKの部品は受取人の公共のコンポーネントです。 MIC暗号化に使用されるIKの部品は創始者の個人的なコンポーネントです、そして、したがって、1つの暗号化されたMIC表現だけが1受取人あたり1つよりむしろメッセージ単位で含まれなければなりません。 それぞれのこれらのIKの部品は完全に資格がある場合がある、「X受取人ID:」 または、「X送付者ID:」 それぞれ、さばきます。
4.1.2 Processing Procedures
4.1.2 現像処理
When privacy enhancement processing is to be performed on an outgoing message, a DEK is generated [1] for use in message encryption and (if a chosen MIC algorithm requires a key) a variant of the DEK is formed for use in MIC computation. DEK generation can be omitted for the case of a message in which all contents are excluded from encryption, unless a chosen MIC computation algorithm requires a DEK.
プライバシー増進処理が送信されるメッセージに実行されることであるときに、DEKはメッセージ暗号化における使用のための[1]であると生成されます、そして、DEKの(選ばれたMICアルゴリズムがキーを必要とするなら)異形はMIC計算における使用のために形成されます。 すべての内容が暗号化から除かれるメッセージに関するケースのためにDEK世代を省略できます、選ばれたMIC計算アルゴリズムがDEKを必要としない場合。
An "X-Sender-ID:" field is included in the header to provide one identification component for the IK(s) used for message processing. IK components are selected for each individually named recipient; a corresponding "X-Recipient-ID:" field, interpreted in the context of a prior "X-Sender-ID:" field, serves to identify each IK. Each "X- Recipient-ID:" field is followed by an "X-Key-Info:" field, which transfers a DEK encrypted under the IK appropriate for the specified recipient. When symmetric key management is used for a given recipient, the "X-Key-Info:" field also transfers the message's computed MIC, encrypted under the recipient's IK. When asymmetric key management is used, a prior "X-MIC-Info:" field carries the message's MIC encrypted under the private component of the sender.
「X送付者ID:」 分野は、1つの識別コンポーネントをメッセージ処理に使用されるIK(s)に供給するためにヘッダーに含まれています。 IKの部品はそれぞれの個別に命名された受取人のために選択されます。 対応、「X受取人ID:」 aの文脈で優先的に解釈された分野、「X送付者ID:」 分野、各IKを特定するサーブ。 それぞれ、「X受取人ID:」 野原が続かれている、「X主要なインフォメーション:」 分野。(その分野は指定された受取人にとって、適切なIKの下で暗号化されたDEKを移します)。 対称鍵管理が与えられた受取人に使用されるとき「X主要なインフォメーション:」 また、分野は受取人のIKの下で暗号化されたメッセージの計算されたMICを移します。 使用される、非対称のかぎ管理、aである、先、「X-MIC-インフォメーション:」 分野は送付者の個人的なコンポーネントの下で暗号化されたメッセージのMICを運びます。
A four-phase transformation procedure is employed in order to represent encrypted message text in a universally transmissible form and to enable messages encrypted on one type of host computer to be decrypted on a different type of host computer. A plaintext message is accepted in local form, using the host's native character set and
4相数変換の手順は、一般に伝えられるフォームに暗号化メッセージテキストを表して、1つのタイプのホストコンピュータで暗号化されたメッセージが異なったタイプのホストコンピュータの上で解読されるのを可能にするのに使われます。 そしてホストのネイティブの文字集合を使用して、地方のフォームで平文メッセージを受け入れる。
Linn [Page 8] RFC 1113 Mail Privacy: Procedures August 1989
リン[8ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
line representation. The local form is converted to a canonical message text representation, defined as equivalent to the inter-SMTP representation of message text. This canonical representation forms the input to the MIC computation and encryption processes.
表現を裏打ちしてください。 地方のフォームはメッセージ・テキストの相互SMTP表現に同じくらい同等な状態で定義された正準なメッセージ・テキスト表現に変換されます。 この正準な表現はMIC計算と暗号化プロセスに入力を形成します。
For encryption purposes, the canonical representation is padded as required by the encryption algorithm. The padded canonical representation is encrypted (except for any regions which are explicitly excluded from encryption). The encrypted text (along with the canonical representation of regions which were excluded from encryption) 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.
暗号化目的のために、正準な表現は必要に応じて暗号化アルゴリズムで水増しされます。 そっと歩いている正準な表現は暗号化されています(暗号化から明らかに除かれるどんな領域を除いたも)。 暗号化されたテキスト(暗号化から除かれた領域の正準な表現に伴う)は印刷可能なフォームにコード化されます。 印刷可能なフォームはサイトの向こう側に一般に「表-可能」になるように選ばれていて、実体とMTS実体の間の処理で混乱させられない制限された文字集合で構成されます。
The output of the encoding procedure is combined with a set of header fields 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セットのヘッダーフィールドに結合されます。 結果は伝えられたメッセージのテキスト部分としてカプセル化される電子メール・システムに通過されます。
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 MIC verification and decryption of the received message text. First, the printable encoding is converted to a bitstring. Encrypted portions of the transmitted message are decrypted. The MIC is verified. The canonical representation is converted to the recipient's local form, which need not be the same as the sender's local form.
プライバシーで高められたメッセージが受信されているとき、テキスト部分の中の暗号の制御フィールドは認可された受取人が受け取られていているメッセージ・テキストのMIC検証と復号化を実行するのに必要である情報を提供します。 まず最初に、印刷可能なコード化はbitstringに変換されます。 伝えられたメッセージの暗号化された部分は解読されます。 MICは確かめられます。 正準な表現は受取人の地方のフォームに変換されます。(それは、送付者の地方のフォームと同じである必要はありません)。
4.2 Encryption Algorithms and Modes
4.2 暗号化アルゴリズムとモード
For purposes of this RFC, the Block Cipher Algorithm DEA-1, defined in ANSI X3.92-1981 [2] shall be used for encryption of message text. The DEA-1 is equivalent to the Data Encryption Standard (DES), as defined in FIPS PUB 46 [3]. When used for encryption of text, the DEA-1 shall be used in the Cipher Block Chaining (CBC) mode, as defined in ISO IS 8372 [4]. The identifier string "DES-CBC", defined in RFC-1115, signifies this algorithm/mode combination. The CBC mode definition in IS 8372 is equivalent to that provided in FIPS PUB 81 [5] and in ANSI X3.106-1983 [16]. Use of other algorithms and/or modes for message text processing will require case-by-case study to determine applicability and constraints. Additional algorithms and modes approved for use in this context will be specified in successors to RFC-1115.
このRFCの目的において、ANSI X3.92-1981で定義されたBlock Cipher Algorithm DEA-1[2]はメッセージ・テキストの暗号化に使用されるものとします。 DEA-1はFIPS PUB46[3]で定義されるようにデータ暗号化規格(DES)に同等です。 テキストの暗号化に使用されると、DEA-1はCipher Block Chaining(CBC)モードで使用されるものとします、ISO IS8372[4]で定義されるように。 RFC-1115で定義された識別子ストリング「デス-CBC」はこのアルゴリズム/モード組み合わせを意味します。 中のCBCモード定義は8372がFIPS PUB81[5]とANSI X3.106-1983[16]に提供されたそれに同等であるということです。 他のアルゴリズム、そして/または、モードのメッセージ・テキスト処理の使用は、適用性と規制を決定するためにその場その場の研究を必要とするでしょう。 追加アルゴリズムと使用のために承認されたモードはRFC-1115の後継者でこのような関係においては指定されるでしょう。
It is an originator's responsibility to generate a new pseudorandom initializing vector (IV) for each privacy-enhanced electronic mail message unless the entirety of the message is excluded from
それ、新しい擬似ランダムを生成するメッセージの全体が初期化しない場合それぞれのプライバシーで高められた電子メールメッセージのためにベクトル(IV)を初期化する創始者の責任が除かれます。
Linn [Page 9] RFC 1113 Mail Privacy: Procedures August 1989
リン[9ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
encryption. Section 4.3.1 of [17] provides rationale for this requirement, even in a context where individual DEKs are generated for individual messages. The IV will be transmitted with the message.
暗号化。 [17]について4.3に.1を区分してください。個々のDEKsが個々のメッセージのために生成されるところにこの要件と、文脈にさえ原理を提供します。 IVはメッセージで伝えられるでしょう。
Certain operations require that one key be encrypted under an interchange key (IK) for purposes of transmission. A header facility indicates the mode in which the IK is used for encryption. RFC-1115 specifies encryption algorithm/mode identifiers, including DES-ECB, DES-EDE, and RSA. All implementations using symmetric key management should support DES-ECB IK use, and all implementations using asymmetric key management should support RSA IK use.
ある操作は、1個のキーがトランスミッションの目的のために置き換えキー(IK)の下で暗号化されるのを必要とします。 ヘッダー施設はIKが暗号化に使用されるモードを示します。 RFC-1115はDES-ECB、DES-EDE、およびRSAを含む暗号化アルゴリズム/モード識別子を指定します。 対称鍵管理を使用するすべての実装が、DES-ECB IKが使用であるとサポートするべきです、そして、非対称のかぎ管理を使用するすべての実装がRSA IKが使用であるとサポートするべきです。
RFC-1114, released concurrently with this RFC, specifies asymmetric, certificate-based key management procedures to support the message processing procedures defined in this document. The message processing procedures can also be used with symmetric key management, given prior distribution of suitable symmetric IKs through out-of- band means. Support for the asymmetric approach defined in RFC-1114 is strongly recommended.
同時にこのRFCと共にリリースされたRFC-1114は、メッセージが本書では定義された現像処理であるとサポートするために非対称の、そして、証明書ベースのかぎ管理手順を指定します。 また、対称鍵管理でメッセージ現像処理を使用できます、外を通した適当な左右対称のIKsの事前分布を考えて-、バンド手段について。 RFC-1114で定義された非対称のアプローチのサポートは強く推薦されます。
4.3 Privacy Enhancement Message Transformations
4.3 プライバシー増進メッセージ変換
4.3.1 Constraints
4.3.1 規制
An electronic mail encryption mechanism 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 and transport facilities. An encryption mechanism must also be compatible with the local conventions of the computer systems which it interconnects. In our approach, a canonicalization step is performed to abstract out local conventions and a subsequent encoding step is performed to conform to the characteristics of the underlying mail transport medium (SMTP). The encoding conforms to SMTP constraints, established to support interpersonal messaging. SMTP's rules are also used independently in the canonicalization process. RFC-821's [7] Section 4.5 details SMTP's transparency constraints.
電子メール暗号化メカニズムは基本的な電子メール施設の透明規制と互換性があるに違いありません。 一般に、これらの規制は予想されたユーザ要件に基づいた予期された終点と運送設備の特性の上で確立されます。 また、暗号化メカニズムもそれがインタコネクトするコンピュータ・システムの地方のコンベンションと互換性があるに違いありません。 私たちのアプローチでは、canonicalizationステップは抽象的な出ている地方のコンベンションに実行されます、そして、その後のコード化ステップは、輸送培地(SMTP)を基本的なメールの特性に従わせるために実行されます。 コード化は個人間のメッセージングをサポートするために確立されたSMTP規制に従います。 また、SMTPの規則はcanonicalizationプロセスで独自に使用されます。 RFC-821[7]のセクション4.5はSMTPの透明規制を詳しく述べます。
To prepare a message for SMTP transmission, the following requirements must be met:
SMTPトランスミッションのためにメッセージを準備するために、以下の必要条件を満たさなければなりません:
1. All characters must be members of the 7-bit ASCII character
set.
1. すべてのキャラクタが7ビットのASCII文字の組のメンバーであるに違いありません。
2. Text lines, delimited by the character pair <CR><LF>, must
be no more than 1000 characters long.
2. 長い間、形質対<CR><LF>によって区切られたテキスト系列は1000のキャラクタであるにすぎないに違いありません。
Linn [Page 10] RFC 1113 Mail Privacy: Procedures August 1989
リン[10ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
3. Since the string <CR><LF>.<CR><LF> indicates the end of a
message, it must not occur in text prior to the end of a
message.
3. <CR><LF>ストリング<CR><LF>がメッセージの終わりを示すので、それはメッセージの終わりまでにテキストに起こってはいけません。
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 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 [8] 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 which uses 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 MIC would fail to compare with that computed at the destination.
SMTPは系列デリミタ(ASCII<CR><LF>)の標準の表現を指定しますが、多数のシステムは、系列を区切るのに異なった固有の表現を使用します。 例えば、UNIXシステムへの本国行きのメールで系列を区切る<CR><LF>系列は、メールがローカルのメールボックスファイルの中に書かれているとき<LF>sを選抜するために変えられます。 記録指向のシステム(VAX VMSなどの)へのメール入来における線は、目的地SMTP[8]サーバで記録を当てるために変換されるかもしれません。その結果、暗号化プロセスが、<がCR>sか<LF>sであると生成するなら、それらのキャラクタは異なった系列を使用する目的地でコンベンションを区切るのにおいて受取人UAプログラムにアクセスしやすくないでしょうに。 また、タブと空間の間の変換が相互SMTPと地方の形式の間のマッピングの間に実行されるのも、可能です。 これは地方選択権の問題です。 そのような変換が伝えられた暗号文のフォームを変えるなら、復号化は伝えられた平文を作り直さないでしょうに、そして、伝えられたMICは目的地で計算されるそれと比較しないでしょう。
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 a major disadvantage: internal file (e.g., mailbox) formats would be incompatible with the native forms used on the systems where they reside. 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に通過されるだろうというとき。
4.3.2 Approach
4.3.2 アプローチ
Our approach to supporting privacy-enhanced mail across an environment in which intermediate conversions may occur encodes mail in a fashion which is uniformly representable across the set of privacy-enhanced UAs regardless of their systems' native character sets. This encoded form is used to represent mail text from sender to recipient, but the encoding is not applied to enclosing mail transport headers or to encapsulated headers inserted to carry control information between privacy-enhanced UAs. The encoding's characteristics are such that the transformations anticipated between sender and recipient UAs will not prevent an encoded message from being decoded properly at its destination.
中間的変換が起こるかもしれない環境の向こう側にプライバシーで高められたメールを支持することへの私たちのアプローチは彼らのシステムの固有の文字の組にかかわらずプライバシーで高められたUAsのセットの向こう側に一様に「表-可能」なファッションによるメールをコード化します。 このコード化されたフォームは送付者から受取人までメールテキストを表すのに使用されますが、コード化はメール輸送ヘッダーを同封すること、または、プライバシーで高められたUAsの間まで制御情報を運ぶために挿入された要約のヘッダーに適用されません。 コード化による特性が送付者と受取人UAsの間で予期された変化が、コード化されたメッセージが目的地で適切に解読されるのを防がないようにものであるということです。
Linn [Page 11] RFC 1113 Mail Privacy: Procedures August 1989
リン[11ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
A sender may exclude one or more portions of a message from encryption processing, but authentication processing is always applied to the entirety of message text. Explicit action is required to exclude a portion of a message from encryption processing; by default, encryption 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 processing.
送付者は暗号化処理からメッセージの複数の部分を除くかもしれませんが、認証処理はいつもメッセージ・テキストの全体に適用されます。 明白な動作が暗号化処理にメッセージの部分を入れないようにするのに必要です。 デフォルトで、暗号化はメッセージ・テキストの全体に適用されます。 そのような除外を指定するユーザレベルデリミタは、地域にかかわる事柄であり、したがって、送付者と受取人の間で異なるかもしれませんが、すべてのシステムが暗号化処理から除かれた領域の明確な同定のための手段を提供するはずです。
An outbound privacy-enhanced message undergoes four transformation steps, described in the following four subsections.
外国行きのプライバシーで高められたメッセージは以下の4つの小区分で説明された4変化ステップを受けます。
4.3.2.1 Step 1: Local Form
4.3.2.1 ステップ1: 地方のフォーム
The message text is created in the system's native character set, with lines delimited in accordance with local convention.
地方のコンベンションによると、線が区切られている状態で、メッセージ・テキストはシステムの固有の文字の組で作成されます。
4.3.2.2 Step 2: Canonical Form
4.3.2.2 ステップ2: 標準形
The entire message text, including both those portions subject to encipherment processing and those portions excluded from such processing, is converted to a universal canonical form, analogous to the inter-SMTP representation [9] as defined in RFC-821 and RFC-822 [10] (ASCII character set, <CR><LF> line delimiters). The processing required to perform this conversion is minimal on systems whose native character set is ASCII. (Note: Since the output of the canonical encoding process will never be submitted directly to SMTP, but only to subsequent steps of the privacy enhancement encoding process, the dot-stuffing transformation discussed in RFC-821, section 4.5.2, is not required.) Since a message is converted to a standard character set and representation before encryption, it can be decrypted and its MIC can be verified at any type of destination host computer. The decryption and MIC verification is performed before any conversions which may be necessary to transform the message into a destination-specific local form.
そのような処理から除かれた暗号文処理とそれらの部分を条件としてそれらの部分の両方を含む全体のメッセージ・テキストは普遍的な標準形に変換されます、RFC-821とRFC-822[10](ASCII文字の組、<CR><LF>線デリミタ)で定義される相互SMTP表現[9]に類似しています。 この変換を実行するのに必要である処理は固有の文字の組がASCIIであるシステムの上で最小限です。 (注意: 正準なコード化の過程の出力が直接SMTPに提出しますが、プライバシー増進のその後のステップだけに過程を決してコード化しないので、RFC-821で議論したドットを詰める変化(セクション4.5.2)は必要ではありません。) 以来、暗号化、それを解読することができて、どんなタイプの目的地ホストコンピュータでもMICについて確かめることができる前にメッセージは標準文字セットと表現に変換されます。 復号化とMIC検証はどんなメッセージを目的地特有の地方のフォームに変えるのに必要であるかもしれない変換の前にも実行されます。
4.3.2.3 Step 3: Authentication and Encipherment
4.3.2.3 ステップ3: 認証と暗号文
The canonical form is input to the selected MIC computation algorithm in order to compute an integrity check quantity for the message. No padding is added to the canonical form before submission to the MIC computation algorithm, although certain MIC algorithms will apply their own padding in the course of computing a MIC.
標準形は、メッセージのために保全チェック量を計算するために選択されたMIC計算アルゴリズムに入力されます。 水増しでないのはMIC計算アルゴリズムへの服従の前に標準形に加えられます、あるMICアルゴリズムが、MICを計算することの間にそれら自身がそっと歩くのに当てはまるでしょうが。
Padding is applied to the canonical form as needed to perform encryption in the DEA-1 CBC mode, as follows: The number of octets to be encrypted is determined by subtracting the number of octets
詰め物は以下の通りDEA-1CBCモードにおける暗号化を実行するために必要に応じて標準形に適用されます: コード化されるべき八重奏の数は、八重奏の数を引き算することによって、測定されます。
Linn [Page 12] RFC 1113 Mail Privacy: Procedures August 1989
リン[12ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
excluded from encryption from the total length of the canonically encoded text. Octets with the hexadecimal value FF (all ones) are appended to the canonical form as needed so that the text octets to be encrypted, along with the added padding octets, fill an integral number of 8-octet encryption quanta. No padding is applied if the number of octets to be encrypted is already an integral multiple of 8. The use of hexadecimal FF (a value outside the 7-bit ASCII set) as a padding value allows padding octets to be distinguished from valid data without inclusion of an explicit padding count indicator.
暗号化から、正準なコード化されたテキストの全長から除かれます。 必要に応じて16進価値のFF(すべてのもの)との八重奏を標準形に追加するので、加えられた詰め物八重奏と共にコード化されるべきテキスト八重奏は整数の8八重奏の暗号化量子をいっぱいにしています。 水増しはコード化されるべき八重奏の数が既に8の不可欠の倍数であるなら適用されていません。 詰め物値としての16進FF(7ビットのASCIIの外における値はセットした)の使用で、有効データと明白な詰め物カウントインディケータの包含なしで区別されるために八重奏を水増しします。
The regions of the message which have not been excluded from encryption are encrypted. To support selective encipherment processing, an implementation must retain internal indications of the positions of excluded areas excluded from encryption with relation to non-excluded areas, so that those areas can be properly delimited in the encoding procedure defined in step 4. If a region excluded from encryption intervenes between encrypted regions, cryptographic state (e.g., IVs and accumulation of octets into encryption quanta) is preserved and continued after the excluded region.
暗号化から除かれていないメッセージの領域はコード化されています。 選択している暗号文処理を支持するために、実現は関係による暗号化から非除かれた領域まで除かれた除かれた領域の位置の内部のしるしを保有しなければなりません、ステップ4で定義されたコード化手順で適切にそれらの領域を区切ることができるように。 暗号化から除かれた領域がコード化された領域を仲裁するなら、暗号の状態(暗号化量子への八重奏の例えば、IVsと蓄積)は、除かれた領域の後に保持されて、続けられています。
4.3.2.4 Step 4: Printable Encoding
4.3.2.4 ステップ4: 印刷可能なコード化
Proceeding from left to right, the bit string resulting from step 3 is 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). This encoding step is performed for all privacy-enhanced messages, even if an entire message is excluded from encryption.
左から右まで続いて、必ずはありませんが、ステップ3から生じるビット列は同じビット・パターンですべてのサイトで一般に「表-可能」なキャラクタにコード化されます(例えば、キャラクタ「E」はEBCDICベースのシステムで16進45とした16進C5としたASCIIベースのシステムで代理をされますが、2つの表現のローカルの意味は同等です)。 全体のメッセージが暗号化から除かれても、このコード化ステップはすべてのプライバシーで高められたメッセージのために実行されます。
A 64-character subset of International Alphabet IA5 is used, 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 character "=" is used for padding within the printable encoding procedure. The character "*" is used to delimit the beginning and end of a region which has been excluded from encipherment processing. The encoding function's output is delimited into text lines (using local conventions), with each line except the last containing exactly 64 printable characters and the final line containing 64 or fewer printable characters. (This line length is easily printable and is guaranteed to satisfy SMTP's 1000- character transmitted line length limit.)
6ビットが印刷可能なキャラクタ単位で表されるのを可能にして、国際Alphabet IA5の64文字サブセットが使用されています。 (キャラクタの提案された部分集合は同様にIA5とASCIIで表されます。) 「=」と「*」という2つの添字が、特別な処理機能を意味するのに使用されます。 キャラクタ「=」は、印刷可能なコード化手順の中でそっと歩くのに使用されます。 キャラクタ「*」は、暗号文処理から除かれた領域の首尾を区切るのに使用されます。 コード化機能の出力はテキスト線に区切られます(地方のコンベンションを使用して)、最終以外の各線がまさに印刷可能な64文字を含んでいて、最終的な線が64か、より少ない印刷可能なキャラクタを含んでいて。 (この行長は、容易に印刷可能であり、1000年のSMTPのキャラクタの伝えられた行長限界を満たすために保証されます。)
The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right across a 24-bit input group extracted from the output of step 3, each 6-bit
4の出力ストリングがキャラクタをコード化したので、コード化の過程は入力ビットの24ビットのグループを代表します。 ステップ3の出力、各6ビットから抜粋された24ビットの入力グループの向こう側に左から右まで続きます。
Linn [Page 13] RFC 1113 Mail Privacy: Procedures August 1989
リン[13ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
group 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 0, are selected so as to be universally representable, and the set excludes characters with particular significance to SMTP (e.g., ".", "<CR>", "<LF>").
グループはインデックスとして64の印刷可能なキャラクタのアレイに使用されます。 インデックスによって参照をつけられるキャラクタは出力ストリングに置かれます。 「Table0で特定されたこれらのキャラクタが一般に「表-可能」になるように選ばれて、セットが特定の意味でSMTPまでキャラクタを除く、(例えば」、」、「<CR>」、「<LF>」)
Special processing is performed if fewer than 24 bits are available in an input group, either at the end of a message or (when the selective encryption facility is invoked) at the end of an encrypted region or an excluded region. A full encoding quantum is always completed at the end of a message and before the delimiter "*" is output to initiate or terminate the representation of a block excluded from encryption. When fewer than 24 input bits are available in an input group, 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 the character "=". Since all canonically encoded output is an integral number of octets, only the following cases can arise: (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding, (2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters, or (3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character.
または、24ビット未満が入力グループで有効であるなら、特別な処理は実行されます、どちらかメッセージの終わりで(選択している暗号化施設が呼び出されるとき) コード化された領域か除かれた領域の端で。 メッセージの終わり、デリミタ「*」が暗号化から除かれた1ブロックの表現を開始するか、または終えるために出力される前に完全なコード化量子はいつも完成します。 24入力ビット未満が入力グループで有効であるときに、ゼロ・ビットは、整数の6ビットのグループを結成するために加えられます(右で)。 実際の入力データを表すのに必要でない出力欄はキャラクタ「=」に設定されます。 すべての正準なコード化された出力が整数の八重奏であるので、以下のケースしか起こることができません: (1) 入力をコード化する最終的な量子は24ビットの不可欠の倍数です。 (2) ここで、コード化された出力の最終的なユニットが「=」が全くそっと歩いていない4つのキャラクタの不可欠の倍数になる、入力をコード化する最終的な量子はちょうど8ビットです。 (3) ここで、コード化された出力の最終的なユニットは2人の「=」暫定記号によっていうことになられた2つのキャラクタになるだろうか、入力をコード化する最終的な量子はまさに16ビットです。 ここで、コード化された出力の最終的なユニットは1人の「=」暫定記号によっていうことになられた3つのキャラクタになるでしょう。
Linn [Page 14] RFC 1113 Mail Privacy: Procedures August 1989
リン[14ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
4.3.2.5 Summary of Transformations
4.3.2.5 変化の概要
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(暗号文の解読(解読してください(_書式を伝えてください)))
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) *
評価..18秒間..C..44秒間..パッド..33時間
(1) The character "*" is used to enclose portions of an encoded message to which encryption processing has not been applied.
(1) キャラクタ「*」は、暗号化処理が適用されていないコード化されたメッセージの部分を同封するのに使用されます。
Printable Encoding Characters
Table 1
印刷可能なコード化キャラクターは1を見送ります。
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.
標準形と標準形からのメッセージを変える地方のフォームと機能が送付者と受取人システムの間で情報の損失なしで異なるかもしれないことに注意してください。
4.4 Encapsulation Mechanism
4.4 カプセル化メカニズム
Encapsulation of privacy-enhanced messages within an enclosing layer
同封層の中のプライバシーで高められたメッセージのカプセル化
Linn [Page 15] RFC 1113 Mail Privacy: Procedures August 1989
リン[15ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
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. 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 processing can be applied recursively. 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.
電子メールによって解釈されたヘッダーでは、輸送システムは独身のヘッダーの中のある一定の分野がコード化されている、そして/または、暗号の制御情報を運ぶ平坦なアプローチに比較における多くの利点を示します。 カプセル化は、ユーザからユーザへの意味でトランジットで変えられたものから、一般性を提供して、野原を隔離します。 暗号化/認証処理の間に挿入されたすべての野原が要約のヘッダーに置かれます。 これは入力ファイルか他のプログラムからヘッダーフィールドではなく、テキストだけを受け入れるメール取り扱いプログラムとの互換性を容易にします。さらに、プライバシー増進処理は再帰的に適用できます。 MTSに関する限り、暗号の認証か暗号化処理に組み入れられた情報はヘッダー部分ではなく、メッセージのテキスト部分にあるでしょう。
The encapsulation mechanism to be used for privacy-enhanced mail is derived from that described in RFC-934 [11] 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.
順番にインターネットコミュニティでのメッセージダイジェストの処理における先例に基づいているRFC-934[11]で説明されたそれからプライバシーで高められたメールに使用されるべきカプセル化メカニズムを得ます。 コード化されたか認証されたトランスミッションのためにユーザメッセージを準備するために、それは図1に示された表現に変えられるでしょう。
As a general design principle, sensitive data is 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. It is strongly recommended, however, that all implementations should replicate copies of "X-Sender-ID:" and "X-Recipient-ID:" fields within the encapsulated text.
一般的な設計原理として、極秘データは、選択的に同封のヘッダーの分野に測定を適用することによってというよりむしろ要約のテキストの中にデータを組み込むことによって、保護されます。 潜在的に機密のヘッダー情報に関する例は「Subject:」などの分野を含むかもしれません、終わりから終わりで重要な内容で、相互ユーザ基礎。 適用されている保護がことである(ことによると空)のセットのヘッダーはユーザ・オプションです。 しかしながら、それが強く推薦されて、それが実現がコピーを模写するべきであるすべて、「X送付者ID:」 そして、「X受取人ID:」 要約のテキストの中の分野。
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 a message's subject indication, it is recommended that the enclosing header contain a "Subject:" field indicating that "Encrypted Mail Follows".
ユーザが、公開がヘッダーフィールドのための保護であることを願うなら、それらは同封の、または、要約のヘッダーに起こるのではなく、要約のテキストだけに起こらなければなりません。 公開保護がメッセージの対象の指示のために望まれているなら、同封のヘッダーが「Subject:」を含むのは、お勧めです。 「暗号化メールは続く」表示をさばいてください。
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. For example, a sender wishing to provide recipients with a protected indication of a message's position in a series of messages could include a copy of a timestamp or message counter field within the encapsulated text.
ヘッダー情報の認証されたバージョンが望まれているなら、同封のヘッダーでの包含に加えた要約のテキスト部分の中でそのデータを模写できます。 例えば、一連のメッセージにおける、メッセージの位置の保護されたしるしを受取人に提供したがっている送付者は要約のテキストの中でタイムスタンプかメッセージカウンタ分野のコピーを入れることができました。
A specific point regarding the integration of privacy-enhanced mail
プライバシーで高められたメールの統合に関する特定のポイント
Linn [Page 16] RFC 1113 Mail Privacy: Procedures August 1989
リン[16ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
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.
カプセル化メカニズムが注意にふさわしいというメッセージがある施設。 トランスミッションコード化のために選択されたIA5の部分集合は故意にキャラクタ「-」を除いて、明白に償還請求のないメッセージの終わりのカプセル化境界(ポスト-EB)からキャラクタ詰め物までそのように要約のテキストは区別できます。
Enclosing Header Portion
(Contains header fields per RFC-822)
ヘッダー部分を同封します。(1RFC-822あたりのヘッダーフィールドを含んでいます)
Blank Line
(Separates Enclosing Header from Encapsulated Message)
空白行(要約のメッセージからヘッダーを同封するセパレーツ)
Encapsulated Message
要約のメッセージ
Pre-Encapsulation Boundary (Pre-EB)
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
プレカプセル化境界(プレEB)-----プライバシーで高められたメッセージ限界-----
Encapsulated Header Portion
(Contains encryption control fields inserted in plaintext.
Examples include "X-DEK-Info:", "X-Sender-ID:", and
"X-Key-Info:".
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.)
要約のヘッダー部分(平文に挿入された暗号化制御フィールドを含んでいます。 例が含んでいる、「X-DEK-インフォメーション:」、「X送付者ID: 」 「X主要なインフォメーション:」 . これらの制御フィールドにはRFC-822ヘッダーフィールドと同様の線指向の表現がありますが、この文脈で有効な分野のセットがRFC-822処理に使用されるものからばらばらになることであることに注意してください。)
Blank Line
(Separates Encapsulated Header from subsequent encoded
Encapsulated Text Portion)
空白行(その後のコード化されたEncapsulated Text PortionとEncapsulated Headerを切り離します)
Encapsulated Text Portion
(Contains message data encoded as specified in Section 4.3;
may incorporate protected copies of enclosing and
encapsulated header fields such as "Subject:", etc.)
要約のテキスト部分(セクション4.3で指定されるようにコード化されたメッセージデータ; 保護されたコピーの同封を取り入れるかもしれないのを含んでいて、「Subject:」などのヘッダーフィールドなどを要約します)
Post-Encapsulation Boundary (Post-EB)
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
ポストカプセル化境界(ポスト-EB)-----プライバシーで高められたメッセージ限界-----
Message Encapsulation
Figure 1
メッセージカプセル化図1
4.5 Mail for Mailing Lists
4.5 メーリングリストのためのメール
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
メールがメーリングリストに記述されるとき、処理の2つの異なった方法が適切である場合があります: 1リストあたりのIK方法と1受取人あたりのIK方法。 この選択は利用可能の情報次第です。
Linn [Page 17] RFC 1113 Mail Privacy: Procedures August 1989
リン[17ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
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. For the case of asymmetric key management, the list's private component must 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.
メッセージの送付者がリスト名か別名にメッセージを記述するなら、実体(1リストあたりのIK)が構成している目的地への名前か別名の解決よりむしろ含意されるようにIKの使用はその名前か別名と交際しました。 したがって、そのようなIKは、メンバーを皆、記載するために利用可能でなければなりません。 非対称のかぎ管理に関するケースに、リストの個人的なコンポーネントは、メンバーを皆、記載するために利用可能でなければなりません。 この代替手段は遠く離れた発破器サイトを通して送られたメッセージのために正常なケースになるでしょう、そのようなリストへの送付者が個々の受取人のセットを認識していないとき。 残念ながら、それは、共有されたIKのために望ましくないレベルの露出を含意して、取消しは難しくなります。 そのうえ、1リストあたりのIK方法の使用で、リストのIKのどんな所有者も認証目的のためのリストに別の送付者のふりをすることができます。
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, in the symmetric key management case, MIC) 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 MIC 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.
メッセージの送付者が、対照的に、目的地メーリングリストを個々の成分に広げるために備えられて、そう(1受取人あたりのIK)をするのを選ぶと、メッセージのDEK(そして、対称鍵管理場合におけるMIC)は各1受取人あたりのIKの下でコード化されるでしょう、そして、そのようなすべてのコード化された表現が伝えられたメッセージに組み入れられるでしょう。 1受取人あたりの暗号化が比較的小さいDEKにだけ必要であり、MIC量が運び込んだことに注意してください、「X主要なインフォメーション:」 いずれの一般に、はるかに大きいメッセージ・テキストのためにも、さばきません。 より多くのIKsが1受取人あたりのIK方法の下で処理にかかわりますが、個別に対状IKsを取り消すことができます、そして、1IKの所持はリストにおける別のユーザのうまくいっている仮面舞踏会を可能にしません。
4.6 Summary of Encapsulated Header Fields
4.6 要約のヘッダーフィールドの概要
This section summarizes the syntax and semantics of the encapsulated header fields to be added to messages in the course of privacy enhancement processing. The fields are presented in three groups. Normally, the groups will appear in encapsulated headers in the order in which they are shown, though not all fields in each group will appear in all messages. In certain indicated cases, it is recommended that the fields be replicated within the encapsulated text portion as well as being included within the encapsulated header. Figures 2 and 3 show the appearance of small example encapsulated messages. Figure 2 assumes the use of symmetric cryptography for key management. Figure 3 illustrates an example encapsulated message in which asymmetric key management is used.
このセクションは、プライバシー増進処理の間にメッセージに追加されるために要約のヘッダーフィールドの構文と意味論をまとめます。 分野は3つのグループで提示されます。 通常、グループは彼らが見せられるオーダーにおける要約のヘッダーに現れるでしょう、各グループのすべての野原がすべてのメッセージに現れるというわけではないでしょうが。 ある示された場合では、分野が要約のテキスト部分の中で模写されて、要約のヘッダーの中に含まれているのは、お勧めです。 数字2と3は小さい例の要約のメッセージの外観を示しています。 図2は左右対称の暗号のかぎ管理の使用を仮定します。 図3は非対称のかぎ管理が使用されている例の要約のメッセージを例証します。
Unless otherwise specified, all field arguments are processed in a case-sensitive fashion. In most cases, numeric quantities are represented in header fields as contiguous strings of hexadecimal digits, where each digit is represented by a character from the
別の方法で指定されない場合、すべての分野議論が大文字と小文字を区別するファッションで処理されます。 多くの場合、数値量は16進数字の隣接のストリングとして各ケタがキャラクタによって表されるところにヘッダーフィールドで表されます。
Linn [Page 18] RFC 1113 Mail Privacy: Procedures August 1989
リン[18ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
ranges "0"-"9" or upper case "A"-"F". Since public-key certificates and quantities encrypted using asymmetric algorithms are large in size, use of a more space-efficient encoding technique is appropriate for such quantities, and the encoding mechanism defined in Section 4.3.2.4 of this RFC, representing 6 bits per printed character, is adopted. The example shown in Figure 3 shows asymmetrically encrypted quantities (e.g., "X-MIC-Info:", "X-Key-Info:") with 64- character printed representations, corresponding to 384 bits. The fields carrying asymmetrically encrypted quantities also illustrate the use of folding as defined in RFC-822, section 3.1.1.
範囲、「0インチ--」 9インチか大文字「A」--「F。」 非対称のアルゴリズムを使用することでコード化される公開カギ証明書と量がサイズで大きいので、そのような量に、よりスペース効率的なコード化のテクニックの使用が適切であり、コード化メカニズムは、1印刷された文字あたり6ビットを表して、セクション4.3.2でこの.4RFCを定義して、採用されます。 図3ショーで示された例が量を非対称的にコード化した、(例えば、「X-MIC-インフォメーション:」、「Xはインフォメーションを合わせる」、)、64で、キャラクタが表現を印刷しました、384ビットに対応しています。 また、非対称的にコード化された量を運ぶ分野はRFC-822、セクション3.1.1で定義されるように折り重なることの使用を例証します。
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
X-Proc-Type: 3,ENCRYPTED
X-DEK-Info: DES-CBC,F8143EDE5960C597
X-Sender-ID: linn@ccy.bbn.com::
X-Recipient-ID: linn@ccy.bbn.com:ptf-kmc:3
X-Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,B70665BB9BF7CBCD,
A60195DB94F727D3
X-Recipient-ID: privacy-tf@venera.isi.edu:ptf-kmc:4
X-Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,E2EF532C65CBCFF7,
9F83A2658132DB47
-----プライバシーで高められたメッセージ限界----- X-Proc-タイプ: 3 コード化されたX-DEK-インフォメーション: DES-CBC、F8143EDE5960C597X送付者ID: linn@ccy.bbn.com :、: X受取人ID: linn@ccy.bbn.com : ptf-kmc: 3 X主要なインフォメーション: デス-ECB、RSA-MD2、9FD3AAD2F2691B9A、B70665BB9BF7CBCD、A60195DB94F727D3X受取人ID: privacy-tf@venera.isi.edu : ptf-kmc: 4 X主要なインフォメーション: デス-ECB、RSA-MD2,161A3F75DC82EF26、E2EF532C65CBCFF7、9F83A2658132DB47
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M 8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot dXd/H5LMDWnonNvPCwQUHt== -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M 8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot dXd/H5LMDWnonNvPCwQUHt=-----プライバシーで高められたメッセージ限界-----
Example Encapsulated Message (Symmetric Case)
Figure 2
例の要約のメッセージ(左右対称のケース)図2
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
X-Proc-Type: 3,ENCRYPTED
X-DEK-Info: DES-CBC,F8143EDE5960C597
X-Sender-ID: linn@ccy.bbn.com::
X-Certificate:
jHUlBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIk
YbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUz
agV2IzUpk8tEjmFjHUlBLpvXR0UrUz/zxB+bATMtPjCUWbz8Lr9wloXIkYbkNpk0
X-Issuer-Certificate:
TMtPjCUWbz8Lr9wloXIkYbkNpk0agV2IzUpk8tEjmFjHUlBLpvXR0UrUz/zxB+bA
IkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloX
vXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLp
X-MIC-Info: RSA-MD2,RSA,
5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpotJ6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz
X-Recipient-ID: linn@ccy.bbn.com:RSADSI:3
-----プライバシーで高められたメッセージ限界----- X-Proc-タイプ: 3 コード化されたX-DEK-インフォメーション: DES-CBC、F8143EDE5960C597X送付者ID: linn@ccy.bbn.com :、: X-証明書: jHUlBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIk YbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUz agV2IzUpk8tEjmFjHUlBLpvXR0UrUz/zxB+bATMtPjCUWbz8Lr9wloXIkYbkNpk0 X-Issuer-Certificate: TMtPjCUWbz8Lr9wloXIkYbkNpk0agV2IzUpk8tEjmFjHUlBLpvXR0UrUz/zxB+Ba IkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloX vXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLp X-MICインフォメーション: RSA-MD2、RSA、oNvqu6z7Xs5Xfz X-受取人5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpotJ6UiRRGcDSvzrsoK+ID: linn@ccy.bbn.com :RSADSI:3
Linn [Page 19] RFC 1113 Mail Privacy: Procedures August 1989
リン[19ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
X-Key-Info: RSA,
lBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHU
X-Recipient-ID: privacy-tf@venera.isi.edu:RSADSI:4
X-Key-Info: RSA,
NcUk2jHEUSoH1nvNSIWL9MLLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72oh
X主要なインフォメーション: RSA、bATMtPjCUWbz8Lr9wloXIkjHU X-受取人lBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+ID: privacy-tf@venera.isi.edu : RSADSI: 4 X主要なインフォメーション: RSA、NcUk2jHEUSoH1nvNSIWL9MLLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72oh
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M 8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot dXd/H5LMDWnonNvPCwQUHt== -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M 8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot dXd/H5LMDWnonNvPCwQUHt=-----プライバシーで高められたメッセージ限界-----
Example Encapsulated Message (Asymmetric Case)
Figure 3
例の要約のメッセージ(非対称のケース)図3
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 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.
要約のヘッダーフィールドはRFC-822ヘッダーフィールドに類似していますが、それらはaがセットをばらばらにならせて、一般に、ヘッダーフィールドを同封するのを作動させるのと同じパーサによって処理されないということです。 要約のヘッダーフィールド処理に、必要で適切な字句解析の複雑さはかなりRFC-822ヘッダー処理にそんなにあまり適切ではありません。 例えば、構文のレベルにおけるRFC-822への特別な意味がある多くのキャラクタにはどんなそのような意味もないので、ヘッダーフィールドは中で要約されました。
When the length of an encapsulated header field is longer than the size conveniently printable on a line, whitespace may be used to fold the field in the manner of RFC-822, section 3.1.1. Any such inserted whitespace is not to be interpreted as a part of a subfield. As a particular example, due to the length of public-key certificates and of quantities encrypted using asymmetric algorithms, such quantities may often need to be folded across multiple printed lines. In order to facilitate such folding in a uniform manner, the bits representing such a quantity are to be divided into an ordered set (with leftmost bits first) of zero or more 384-bit groups (corresponding to 64- character printed representations), followed by a final group of bits which may be any length up to 384 bits.
要約のヘッダーフィールドの長さが線、空白で便利に印刷可能なサイズが分野を折り重ねるのに使用されるかもしれないより長い間RFC-822の方法であるとき、セクション3.1.1です。 部分体の一部としてそのようなどんな挿入された空白も解釈してはいけません。 特定の例として、非対称のアルゴリズムを使用することでコード化された公開カギ証明書と量の長さのため、そのような量は、しばしば複数の印刷された線の向こう側に折り重ねられる必要があるかもしれません。 そのような量を表すビットが一定の方法でそのような折り重なりを容易にするために順序集合に分割されることである、(一番左ビット、1番目) ゼロかどんな最大384ビットの長さであるかもしれないビットの最終的なグループによっても従われた384ビット以上のグループ(64のキャラクタの印刷された表現に対応する)について。
4.6.1 Per-Message Encapsulated Header Fields
4.6.1 1メッセージあたりの要約のヘッダーフィールド
This group of encapsulated header fields contains fields which occur no more than once in a privacy-enhanced message, generally preceding all other encapsulated header fields.
要約のヘッダーフィールドのこのグループはプライバシーで高められたメッセージの一度よりそれ以上起こらない分野を含みます、一般に、他のすべての要約のヘッダーフィールドに先行して。
4.6.1.1 X-Proc-Type Field
4.6.1.1 X-Proc-タイプ分野
The "X-Proc-Type:" encapsulated header field, required for all privacy-enhanced messages, identifies the type of processing
「X-Proc-タイプ:」 すべてのプライバシーで高められたメッセージに必要である要約のヘッダーフィールドは処理のタイプを特定します。
Linn [Page 20] RFC 1113 Mail Privacy: Procedures August 1989
リン[20ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
performed on the transmitted message. Only one "X-Proc-Type:" field occurs in a message; the "X-Proc-Type:" field must be the first encapsulated header field in the message.
伝えられたメッセージに実行されます。 1つは「以下をX-Procタイプするだけです」。 分野はメッセージに起こります。 「X-Proc-タイプ:」 分野はメッセージで最初の要約のヘッダーフィールドであるに違いありません。
The "X-Proc-Type:" field has two subfields, separated by a comma. The first subfield is a decimal number which is used to distinguish among incompatible encapsulated header field interpretations which may arise as changes are made to this standard. Messages processed according to this RFC will carry the subfield value "3" to distinguish them from messages processed in accordance with prior RFCs 989 and 1040.
「X-Proc-タイプ:」 分野には、コンマによって切り離された2つの部分体があります。 最初の部分体は変更をこの規格にするとき起こるかもしれない両立しない要約のヘッダーフィールド解釈の中で区別するのに使用される10進数です。 これに従って処理されて、RFCが部分体を運ぶというメッセージは「先のRFCs989と1040に従って処理されたメッセージとそれらを区別する3インチ」を評価します。
The second subfield may assume one of two string values: "ENCRYPTED" or "MIC-ONLY". Unless all of a message's encapsulated text is excluded from encryption, the "X-Proc-Type:" field's second subfield must specify "ENCRYPTED". Specification of "MIC-ONLY", when applied in conjunction with certain combinations of key management and MIC algorithm options, permits certain fields which are superfluous in the absence of encryption to be omitted from the encapsulated header. In particular, "X-Recipient-ID:" and "X-Key-Info:" fields can be omitted for recipients for whom asymmetric cryptography is used, assuming concurrent use of a keyless MIC computation algorithm. The "X-DEK-Info:" field can be omitted for all "MIC-ONLY" messages.
2番目の部分体は2つのストリング値の1つを仮定するかもしれません: 「コード化された」か、「ミックだけ。」 メッセージのすべてが要約されなかったならテキストが暗号化から除かれる、「X-Proc-タイプ:」 フィールドの2番目の部分体は「コード化されていた」状態で指定しなければなりません。 かぎ管理とミックのアルゴリズムオプションのある組み合わせに関連して適用されると、「ミックだけ」の仕様は、暗号化がないとき余計なある一定の分野が要約のヘッダーから省略されることを許可します。 特に、「X受取人ID:」 そして、「Xはインフォメーションを合わせます」。 非対称の暗号が使用されている受取人のために分野を省略できます、鍵のないMIC計算アルゴリズムの同時発生の使用を仮定して。 「X-DEK-インフォメーション:」 すべての「ミックだけ」メッセージのために分野を省略できます。
4.6.1.2 X-DEK-Info Field
4.6.1.2 X-DEK-インフォメーション分野
The "X-DEK-Info:" encapsulated header field identifies the message text encryption algorithm and mode, and also carries the Initializing Vector used for message encryption. No more than one "X-DEK-Info:" field occurs in a message; the field is required except for messages specified as "MIC-ONLY" in the "X-Proc-Type:" field.
「X-DEK-インフォメーション:」 要約のヘッダーフィールドは、メッセージ・テキスト暗号化アルゴリズムとモードを特定して、また、メッセージ暗号化に使用されるInitializing Vectorを運びます。 1未満、「X-DEK-インフォメーション:」 分野はメッセージに起こります。 「ミックONLY」として中で指定されたメッセージを除いて、分野が必要である、「X-Proc-タイプ:」 さばきます。
The "X-DEK-Info:" field carries two arguments, separated by a comma. For purposes of this RFC, the first argument must be the string "DES-CBC", signifying (as defined in RFC-1115) use of the DES algorithm in the CBC mode. The second argument represents a 64-bit Initializing Vector (IV) as a contiguous string of 16 hexadecimal digits. Subsequent revisions of RFC-1115 will specify any additional values which may appear as the first argument of this field.
「X-DEK-インフォメーション:」 分野はコンマによって切り離された2つの議論を運びます。 このRFCの目的のために、最初の議論はストリング「デス-CBC」でなければなりません、CBCモードにおけるデスアルゴリズムの使用を意味して(RFC-1115で定義されるように)。 2番目の議論は16の16進数字の隣接のストリングとして64ビットのInitializing Vector(IV)を表します。 RFC-1115のその後の改正はこの分野の最初の議論として現れるどんな加算値も指定するでしょう。
4.6.2 Encapsulated Header Fields Normally Per-Message
4.6.2 通常、要約のヘッダーはメッセージをさばきます。
This group of encapsulated header fields contains fields which ordinarily occur no more than once per message. Depending on the key management option(s) employed, some of these fields may be absent from some messages. The "X-Sender-ID" field may occur more than once in a message if different sender-oriented IK components (perhaps corresponding to different versions) must be used for different
要約のヘッダーフィールドのこのグループは1メッセージあたりの一度より通常、それ以上起こらない分野を含みます。 使われたかぎ管理オプションによって、これらの分野のいくつかがいくつかのメッセージから欠けているかもしれません。 「X送付者ID」分野がコンポーネント(恐らく異なった見解に対応する)が異なった送付者指向のIKであるならメッセージの一度あるに違いないより使用されていた状態で起こるかもしれない、相違
Linn [Page 21] RFC 1113 Mail Privacy: Procedures August 1989
リン[21ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
recipients. In this case later occurrences override prior occurrences. If a mixture of symmetric and asymmetric key distribution is used within a single message, the recipients for each type of key distribution technology should be grouped together to simplify parsing.
受取人。 この場合、後の発生は先の発生をくつがえします。 左右対称の、そして、非対称の主要な分配の混合物がただ一つのメッセージの中で使用されるなら、それぞれのタイプの主要な分配技術のための受取人は、構文解析を簡素化するために一緒に分類されるべきです。
4.6.2.1 X-Sender-ID Field
4.6.2.1 X送付者ID分野
The "X-Sender-ID:" encapsulated header field, required for all privacy-enhanced messages, identifies a message's sender and provides the sender's IK identification component. It should be replicated within the encapsulated text. The IK identification component carried in an "X-Sender-ID:" field is used in conjunction with all subsequent "X-Recipient-ID:" fields until another "X-Sender-ID:" field occurs; the ordinary case will be that only a single "X- Sender-ID:" field will occur, prior to any "X-Recipient-ID:" fields.
「X送付者ID:」 すべてのプライバシーで高められたメッセージに必要である要約のヘッダーフィールドは、メッセージの送付者を特定して、送付者のIK識別の部品を提供します。 それは要約のテキストの中で模写されるべきです。 IK識別の部品が運び込んだ、「X送付者ID:」 分野がその後に関連して使用される、「X受取人ID:」 別のものまでの分野、「X送付者ID:」 分野は起こります。 よくある事例がその唯一のaシングルになる、「X送付者ID:」 分野がどんな前にも起こる、「X受取人ID:」 分野。
The "X-Sender-ID:" field contains (in order) an Entity Identifier
subfield, an (optional) Issuing Authority subfield, and an (optional)
Version/Expiration subfield. The optional subfields are omitted if
their use is rendered redundant by information carried in subsequent
"X-Recipient-ID:" fields; this will ordinarily be the case where
symmetric cryptography is used for key management. The subfields are
delimited by the colon character (":"), optionally followed by
whitespace.
「X送付者ID:」 分野は(in order)を含んでいます。Entity Identifier部分体、(任意)の発行しているAuthority部分体、および(任意)のバージョン/満了部分体。 彼らの使用がその後で運ばれた情報によって余分にされるなら任意の部分体が省略される、「X受取人ID:」 分野。 通常、これは左右対称の暗号がかぎ管理に使用されるそうになるでしょう。 部分体がコロンキャラクタによって区切られる、(「:」、)、空白は任意にあとに続きます。
Section 5.2, Interchange Keys, discusses the semantics of these subfields and specifies the alphabet from which they are chosen. Note that multiple "X-Sender-ID:" fields may occur within a single encapsulated header. All "X-Recipient-ID:" fields are interpreted in the context of the most recent preceding "X-Sender-ID:" field; it is illegal for an "X-Recipient-ID:" field to occur in a header before an "X-Sender-ID:" has been provided.
セクション5.2、Interchangeキーズは、これらの部分体の意味論について議論して、それらが選ばれているアルファベットを指定します。 その倍数に注意してください、「X送付者ID:」 分野は独身の要約のヘッダーの中に起こるかもしれません。 すべて、「X受取人ID:」 分野が最新の先行の文脈で解釈される、「X送付者ID:」 分野。 それが不法である、「X受取人ID:」 以前ヘッダーに起こるようにさばく、「X送付者ID:」 提供しました。
4.6.2.2 X-Certificate Field
4.6.2.2 X-証明書分野
The "X-Certificate:" encapsulated header field is used only when asymmetric key management is employed for one or more of a message's recipients. To facilitate processing by recipients (at least in advance of general directory server availability), inclusion of this field in all messages is strongly recommended. The field transfers a sender's certificate as a numeric quantity, represented with the encoding mechanism defined in Section 4.3.2.4 of this RFC. The semantics of a certificate are discussed in RFC-1114. The certificate carried in an "X-Certificate:" field is used in conjunction with "X-Sender-ID:" and "X-Recipient-ID:" fields for which asymmetric key management is employed.
「X-証明書:」 非対称のかぎ管理がメッセージの受取人のより多くのひとりに使われるときだけ、要約のヘッダーフィールドは使用されています。 受取人(少なくとも一般的なディレクトリサーバの有用性の前の)で処理するのを容易にするために、すべてのメッセージでのこの分野の包含は強く推薦されます。 コード化メカニズムがセクション4.3.2で定義されているこの.4RFCが、分野が数値量として送付者の証明書を移すと表しました。 RFC-1114で証明書の意味論について議論します。 証明書が運び込んだ、「X-証明書:」 に関連して分野が使用されている、「X送付者ID:」 そして、「X受取人ID:」 非対称のかぎ管理が採用している分野。
Linn [Page 22] RFC 1113 Mail Privacy: Procedures August 1989
リン[22ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
4.6.2.3 X-MIC-Info Field
4.6.2.3 X-MIC-インフォメーション分野
The "X-MIC-Info:" encapsulated header field, used only when asymmetric key management is employed for at least one recipient of a message, carries three arguments, separated by commas. The first argument identifies the algorithm under which the accompanying MIC is computed; RFC-1115 specifies the acceptable set of MIC algorithm identifiers. The second argument identifies the algorithm under which the accompanying MIC is encrypted; for purposes of this RFC, the string "RSA" as described in RFC-1115 must occur, identifying use of the RSA algorithm. The third argument is a MIC, asymmetrically encrypted using the originator's private component. As discussed earlier in this section, the asymmetrically encrypted MIC is represented using the technique described in Section 4.3.2.4 of this RFC.
「X-MIC-インフォメーション:」 非対称のかぎ管理がメッセージの少なくとも1人の受取人に使われるときだけ使用される要約のヘッダーフィールドはコンマによって切り離された3つの議論を運びます。 最初の議論は付随のMICが計算されるアルゴリズムを特定します。 RFC-1115は許容できるセットのMICアルゴリズム識別子を指定します。 2番目の議論は付随のMICがコード化されているアルゴリズムを特定します。 このRFCの目的のために、RSAアルゴリズムの使用を特定して、RFC-1115で説明されるストリング"RSA"は起こらなければなりません。 3番目の議論は創始者の個人的なコンポーネントを使用することで非対称的にコード化されたMICです。 非対称的にコード化されたMICによる表されて、テクニックを使用するとこの.4RFCがセクション4.3.2で説明されたという以前に検討したことであるがこのセクションでは、ことです。
The "X-MIC-Info:" field will occur immediately following the message's "X-Sender-ID:" field and any "X-Certificate:" or "X- Issuer-Certificate:" fields. Analogous to the "X-Sender-ID:" field, an "X-MIC-Info:" field applies to all subsequent recipients for whom asymmetric key management is used.
「X-MIC-インフォメーション:」 すぐにメッセージのものに続いて、分野が起こる、「X送付者ID:」 分野といずれも「以下をXで証明します」。 または、「X以下を発行人で証明してください」 分野。 類似、「X送付者ID:」 分野、「X-MIC-インフォメーション:」 分野は非対称のかぎ管理が使用されているすべてのその後の受取人に適用されます。
4.6.3 Encapsulated Header Fields with Variable Occurrences
4.6.3 可変発生を伴う要約のヘッダーフィールド
This group of encapsulated header fields contains fields which will normally occur variable numbers of times within a message, with numbers of occurrences ranging from zero to non-zero values which are independent of the number of recipients.
要約のヘッダーフィールドのこのグループは通常、起こる分野を含みます。発生の数がゼロ〜受取人の数の如何にかかわらずある非ゼロ値まで及んでいるメッセージの中の可変数の回。
4.6.3.1 X-Issuer-Certificate Field
4.6.3.1 X発行人証明書分野
The "X-Issuer-Certificate:" encapsulated header field is meaningful only when asymmetric key management is used for at least one of a message's recipients. A typical "X-Issuer-Certificate:" field would contain the certificate containing the public component used to sign the certificate carried in the message's "X-Certificate:" field, for recipients' use in chaining through that certificate's certification path. Other "X-Issuer-Certificate:" fields, typically representing higher points in a certification path, also may be included by a sender. The order in which "X-Issuer-Certificate:" fields are included need not correspond to the order of the certification path; the order of that path may in general differ from the viewpoint of different recipients. More information on certification paths can be found in RFC-1114.
「X発行人証明書:」 非対称のかぎ管理が少なくともメッセージの受取人のひとりに使用されるときだけ、要約のヘッダーフィールドは重要です。 A典型的である、「X発行人証明書:」 分野は「以下をXで証明してください」というメッセージのもので運ばれた証明書にサインするのに使用される公共のコンポーネントを含んでいて、証明書を含んでいるでしょう。 その証明書の証明経路を通して鎖を作ることにおける受取人の使用のために、さばきます。 他、「X発行人証明書:」 また、証明経路により高いポイントを通常表して、分野は送付者によって入れられるかもしれません。 どれを入るように命じてくださいか、「X発行人証明書:」 含まれていた分野は証明経路の注文と食い違わなければなりません。 一般に、その経路の注文は異なった受取人の観点と異なるかもしれません。 RFC-1114で証明経路に関する詳しい情報を見つけることができます。
The certificate is represented in the same manner as defined for the "X-Certificate:" field, and any "X-Issuer-Certificate:" fields will ordinarily follow the "X-Certificate:" field directly. Use of the
証明書が定義されるのと同じ方法で表される、「X-証明書:」 分野、およびいずれ、も「X発行人証明書:」 通常、野原が続く、「X-証明書:」 直接、さばきます。 使用
Linn [Page 23] RFC 1113 Mail Privacy: Procedures August 1989
リン[23ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
"X-Issuer-Certificate:" field is optional even when asymmetric key management is employed, although its incorporation is strongly recommended in the absence of alternate directory server facilities from which recipients can access issuers' certificates.
「X発行人証明書:」 非対称のかぎ管理が採用してさえいるとき、分野は任意です、編入が受取人が発行人の証明書にアクセスできる交互のディレクトリサーバ施設がないとき強く推薦されますが。
4.6.4 Per-Recipient Encapsulated Header Fields
4.6.4 1受取人あたりの要約のヘッダーフィールド
This group of encapsulated header fields normally appears once for each of a message's named recipients. As a special case, these fields may be omitted in the case of a "MIC-ONLY" message to recipients for whom asymmetric key management is employed, given that the chosen MIC algorithm is keyless.
通常、要約のヘッダーフィールドのこのグループは一度メッセージの命名された受取人各人の弁護に出廷します。 特殊なものとして、これらの分野は「ミックだけ」メッセージの場合で非対称のかぎ管理が採用している受取人に省略されるかもしれません、選ばれたミックアルゴリズムがキーがないなら。
4.6.4.1 X-Recipient-ID Field
4.6.4.1 X受取人ID分野
The "X-Recipient-ID:" encapsulated header field identifies a
recipient and provides the recipient's IK identification component.
One "X-Recipient-ID:" field is included for each of a message's named
recipients. It should be replicated within the encapsulated text.
The field contains (in order) an Entity Identifier subfield, an
Issuing Authority subfield, and a Version/Expiration subfield. The
subfields are delimited by the colon character (":"), optionally
followed by whitespace.
「X受取人ID:」 要約のヘッダーフィールドは、受取人を特定して、受取人のIK識別の部品を提供します。 1つ、「X受取人ID:」 分野はメッセージの命名された受取人各人のために含まれています。 それは要約のテキストの中で模写されるべきです。 分野は(in order)を含んでいます。Entity Identifier部分体、Issuing Authority部分体、およびバージョン/満了部分体。 部分体がコロンキャラクタによって区切られる、(「:」、)、空白は任意にあとに続きます。
Section 5.2, Interchange Keys, discusses the semantics of the subfields and specifies the alphabet from which they are chosen. All "X-Recipient-ID:" fields are interpreted in the context of the most recent preceding "X-Sender-ID:" field; it is illegal for an "X- Recipient-ID:" field to occur in a header before an "X-Sender-ID:" has been provided.
セクション5.2、Interchangeキーズは、部分体の意味論について議論して、それらが選ばれているアルファベットを指定します。 すべて、「X受取人ID:」 分野が最新の先行の文脈で解釈される、「X送付者ID:」 分野。 それが不法である、「X受取人ID:」 以前ヘッダーに起こるようにさばく、「X送付者ID:」 提供しました。
4.6.4.2 X-Key-Info Field
4.6.4.2 X主要なインフォメーション分野
One "X-Key-Info:" field is included for each of a message's named recipients. Each "X-Key-Info:" field is interpreted in the context of the most recent preceding "X-Recipient-ID:" field; normally, an "X-Key-Info:" field will immediately follow its associated "X- Recipient-ID:" field. The field's argument(s) differ depending on whether symmetric or asymmetric key management is used for a particular recipient.
1つ、「X主要なインフォメーション:」 分野はメッセージの命名された受取人各人のために含まれています。 それぞれ、「Xはインフォメーションを合わせます」。 分野が最新の先行の文脈で解釈される、「X受取人ID:」 分野。 通常、「X主要なインフォメーション:」 野原がすぐに続く、それが関連している、「X受取人ID:」 さばきます。 左右対称の、または、非対称のかぎ管理が特定の受取人に使用されるかどうかによって、フィールドの議論は異なります。
4.6.4.2.1 Symmetric Key Management
4.6.4.2.1 対称鍵管理
When symmetric key management is employed for a given recipient, the "X-Key-Info:" encapsulated header field transfers four items, separated by commas: an IK Use Indicator, a MIC Algorithm Indicator, a DEK and a MIC. The IK Use Indicator identifies the algorithm and mode in which the identified IK was used for DEK encryption for a
対称鍵管理が与えられた受取人に使われるとき「X主要なインフォメーション:」 要約のヘッダーフィールドはコンマによって切り離された4個の商品を移します: IKはインディケータ、MICアルゴリズムインディケータ、DEK、およびMICを使用します。 IK Use Indicatorは特定されたIKがaのためのDEK暗号化に使用されたアルゴリズムとモードを特定します。
Linn [Page 24] RFC 1113 Mail Privacy: Procedures August 1989
リン[24ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
particular recipient. For recipients for whom symmetric key management is used, it may assume the reserved string values "DES- ECB" or "DES-EDE", as defined in RFC-1115.
特定の受取人。 対称鍵管理が使用されている受取人に関しては、予約されたストリング値が「デスECB」か「デス-エーデ」であると仮定するかもしれません、RFC-1115で定義されるように。
The MIC Algorithm Indicator identifies the MIC computation algorithm used for a particular recipient; values for this subfield are defined in RFC-1115. The DEK and MIC are encrypted under the IK identified by a preceding "X-Recipient-ID:" field and prior "X-Sender-ID:" field; they are represented as two strings of contiguous hexadecimal digits, separated by a comma.
MIC Algorithm Indicatorは特定の受取人に使用されるMIC計算アルゴリズムを特定します。 この部分体のための値はRFC-1115で定義されます。 DEKとMICが先行で特定されたIKの下でコード化される、「X受取人ID:」 分野と先、「X送付者ID:」 分野。 それらはコンマによって切り離された隣接の16進数字の2個のストリングとして表されます。
When DEA-1 is used for message text encryption, 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.
DEA-1がメッセージ・テキスト暗号化に使用されるとき、DEK表現は16の16進数字(64の噛み付いているキーに対応する)でしょう。 この部分体はそうであることができます。必要なら、他のアルゴリズムを支持するために、32の16進数字(128ビットのキーに対応する)に達しました。
Symmetric encryption of MICs is always performed in the same encryption mode used to encrypt the message's DEK. Encrypted MICs, like encrypted DEKs, are represented as contiguous strings of hexadecimal digits. The size of a MIC is dependent on the choice of MIC algorithm as specified in the MIC Algorithm Indicator subfield.
MICsの左右対称の暗号化はメッセージのDEKをコード化するのに使用される同じ暗号化モードでいつも実行されます。 コード化されたDEKsのように、コード化されたMICsは16進数字の隣接のストリングとして表されます。 MICのサイズはMIC Algorithm Indicator部分体における指定されるとしてのMICアルゴリズムの選択に依存しています。
4.6.4.2.2 Asymmetric Key Management
4.6.4.2.2 非対称のKey Management
When asymmetric key management is employed for a given recipient, the "X-Key-Info:" field transfers two quantities, separated by commas. The first argument is an IK Use Indicator identifying the algorithm (and mode, if applicable) in which the DEK is encrypted; for purposes of this RFC, the IK Use Indicator subfield will always assume the reserved string value "RSA" (as defined in RFC-1115) for recipients for whom asymmetric key management is employed, signifying use of the RSA algorithm. The second argument is a DEK, encrypted (using asymmetric encryption) under the recipient's public component.
非対称のかぎ管理が与えられた受取人に使われるとき「X主要なインフォメーション:」 分野はコンマによって切り離された2つの量を移します。 そして、最初の議論がアルゴリズムを特定するIK Use Indicatorである、(モード、適切であるならDEKがどれであるかで、コード化されます。 このRFCの目的のために、IK Use Indicator部分体は、いつも予約されたストリングが非対称のかぎ管理が採用している受取人のために、"RSA"(RFC-1115で定義されるように)を評価すると仮定するでしょう、RSAアルゴリズムの使用を意味して。 2番目の議論は受取人の公共のコンポーネントの下でコード化された(非対称の暗号化を使用します)DEKです。
Throughout this RFC we have adopted the terms "private component" and "public component" to refer to the quantities which are, respectively, kept secret and made publically available in asymmetric cryptosystems. This convention is adopted to avoid possible confusion arising from use of the term "secret key" to refer to either the former quantity or to a key in a symmetric cryptosystem.
このRFC中では、私たちは、非対称の暗号系でそれぞれ秘密にされて、publicallyに利用可能にされる量について言及するために用語「個人的なコンポーネント」と「公共のコンポーネント」を採用しました。このコンベンションは、左右対称の暗号系で前の量かキーを参照するために「秘密鍵」という用語の使用から起こる可能な混乱を避けるために採用されます。
As discussed earlier in this section, the asymmetrically encrypted DEK is represented using the technique described in Section 4.3.2.4 of this RFC.
非対称的にコード化されたDEKによる表されて、テクニックを使用するとこの.4RFCがセクション4.3.2で説明されたという以前に検討したことであるがこのセクションでは、ことです。
Linn [Page 25] RFC 1113 Mail Privacy: Procedures August 1989
リン[25ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
5. Key Management
5. Key Management
Several cryptographic constructs are involved in supporting the privacy-enhanced message processing procedure. A set of fundamental elements is assumed. Data Encrypting Keys (DEKs) are used to encrypt message text and (for some MIC computation algorithms) in the message integrity check (MIC) computation process. Interchange Keys (IKs) are used to encrypt DEKs and MICs for transmission with messages. In a certificate-based asymmetric key management architecture, certificates are used as a means to provide entities' public components and other information in a fashion which is securely bound by a central authority. The remainder of this section provides more information about these constructs.
いくつかの暗号の構造物がプライバシーで高められたメッセージ現像処理を支持するのにかかわります。 1セットの基本的な要素は想定されます。 データEncryptingキーズ(DEKs)は、メッセージ・テキストをコード化して、メッセージの保全で(MIC)計算の過程をチェックすること(いくつかのMIC計算アルゴリズムのために)に使用されます。 置き換えキーズ(IKs)は、トランスミッションのためにメッセージでDEKsとMICsをコード化するのに使用されます。 証明書ベースの非対称のかぎ管理構造では、証明書は実体の公共のコンポーネントと他の情報を主要な権威によってしっかりと縛られるファッションに提供する手段として使用されます。 このセクションの残りはこれらの構造物に関する詳しい情報を提供します。
5.1 Data Encrypting Keys (DEKs)
5.1 データコード化キー(DEKs)
Data Encrypting Keys (DEKs) are used for encryption of message text and (with some MIC computation algorithms) for computation of message integrity check quantities (MICs). It is strongly recommended that DEKs be generated and used on a one-time, per-message, basis. A transmitted message will incorporate a representation of the DEK encrypted under an appropriate interchange key (IK) for each of the named recipients.
そして、データEncryptingキーズ(DEKs)がメッセージ・テキストの暗号化に使用される、(いくつかのMIC計算アルゴリズムがある) メッセージの保全の計算がないかどうか、量(MICs)をチェックしてください。 DEKsが1メッセージあたりの1回のa、ベースで発生して、使用されることが強く勧められます。 伝えられたメッセージは命名された受取人各人のために適切な置き換えキー(IK)の下でコード化されたDEKの表現を取り入れるでしょう。
DEK generation can be performed either centrally by key distribution centers (KDCs) or by endpoint systems. Dedicated KDC systems may be able to implement stronger algorithms for random DEK 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 at 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システムは無作為のDEK世代には、終点システムで支持できるより強いアルゴリズムを実行できるかもしれません。 そのうえ、終点の分散DEK世代は送付者がメールを送るために(潜在的にユニーク)のサーバのリアルタイムの質問をしなければならない頻度を減少させます、コミュニケーションの有用性を高めて。
When symmetric cryptography is used, one advantage of centralized KDC-based generation is that DEKs can be returned to endpoints already encrypted under the IKs of message recipients rather than providing the IKs to the senders. This reduces IK exposure and simplifies endpoint key management requirements. This approach has less value if asymmetric cryptography is used for key management, since per-recipient public IK components are assumed to be generally available and per-sender private IK components need not necessarily be shared with a KDC.
左右対称の暗号が使用されているとき、集結されたKDCを拠点とする世代の1つの利点はIKsを送付者に提供するよりメッセージ受取人のIKsの下で既にむしろコード化された終点にDEKsを返すことができるということです。 これは、IK露出を抑えて、終点かぎ管理要件を簡素化します。 このアプローチには、非対称の暗号がかぎ管理に使用されるなら、より少ない値があります、一般に、1受取人あたりの公共のIKの部品が利用可能であると思われて、1送付者あたりの個人的なIKの部品が必ずKDCと共有されなければならないというわけではないので。
5.2 Interchange Keys (IKs)
5.2 置き換えキー(IKs)
Interchange Key (IK) components are used to encrypt DEKs and MICs.
置き換えKey(IK)の部品は、DEKsとMICsをコード化するのに使用されます。
Linn [Page 26] RFC 1113 Mail Privacy: Procedures August 1989
リン[26ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
In general, IK granularity 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 possess common IK components (when symmetric key management is used) or complementary IK components (when asymmetric key management is used). When symmetric cryptography is used, the IK consists of a single component, used to encrypt both DEKs and MICs. When asymmetric cryptography is used, a recipient's public component is used as an IK to encrypt DEKs (a transformation invertible only by a recipient possessing the corresponding private component), and the originator's private component is used to encrypt MICs (a transformation invertible by all recipients, since the originator's certificate provides the necessary public component of the originator).
一般に、IK粒状が複数のユーザを包括するリストを記述するために送られたメール以外の1ユーザあたりの対状レベルにあります。 従来の暗号を使用することで2人の校長がプライバシーで高められた電子メールの役に立つ交換に従事するように、最初に、彼らには一般的なIKの部品(対称鍵管理が使用されているとき)か補足的なIKの部品がなければなりません(非対称のかぎ管理が使用されているとき)。 左右対称の暗号が使用されているとき、IKはDEKsとMICsの両方をコード化するのに使用されるただ一つのコンポーネントから成ります。 非対称の暗号が使用されているとき、受取人の公共のコンポーネントはDEKs(単に対応する個人的なコンポーネントを持っている受取人によるa変化invertible)をコード化するのにIKとして使用されます、そして、創始者の個人的なコンポーネントは、MICs(創始者の証明書が創始者の必要な公共のコンポーネントを提供して以来のすべての受取人によるa変化invertible)をコード化するのに使用されます。
While this RFC does not prescribe the means by which interchange keys are provided to appropriate parties, it is useful to note that such means may be centralized (e.g., via key management servers) or decentralized (e.g., via pairwise agreement and direct distribution among users). In any case, any given IK component is associated with a responsible Issuing Authority (IA). When certificate-based asymmetric key management, as discussed in RFC-1114, is employed, the IA function is performed by a Certification Authority (CA).
このRFCは置き換えキーがパーティーを当てるために提供される手段を定めませんが、そのような手段が集結されるか(例えば、かぎ管理サーバで)、または分散されるかもしれないことに(ユーザの中の対状協定と例えば、直接販売で)注意するのは役に立ちます。 どのような場合でも、どんな与えられたIKの部品も責任があるIssuing Authority(アイオワ)に関連しています。 RFC-1114で議論する証明書を拠点とする非対称のかぎ管理が採用しているとき、アイオワの機能は認証局(カリフォルニア)によって実行されます。
When an IA generates and distributes an IK component, associated control information is provided to direct how it is to be used. In order to select the appropriate IK(s) to use in message encryption, a sender must retain a correspondence between IK components 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 appropriate.
アイオワがIKの部品を発生して、分配するとき、それによってどう使用されていることになっているかを指示するために関連制御情報を提供します。 メッセージ暗号化における使用への適切なIK(s)を選択するために、送付者は彼らが関連しているIKの部品と受取人の間との通信を保有しなければなりません。 また、適宜キャッシュされたエントリーを無効にして、取り替えることができるように有効期限の情報を保有しなければなりません。
Since a message may be sent with multiple IK components identified, corresponding to multiple intended recipients, each recipient's UA must be able to determine that recipient's intended IK component. Moreover, if no corresponding IK component is available in the recipient's database when a message arrives, the recipient must be able to identify the required IK component and identify that IK component'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 IK components associated individually with A and B, but the second would use an IK component shared among list members.
複数の意図している受取人に文通していて、複数のIKの部品が特定されている状態でメッセージを送るかもしれないので、各受取人のUAはその受取人の意図しているIKの部品を決定できなければなりません。 そのうえ、メッセージが到着するとき、どんな対応するIKの部品も受取人のデータベースで利用可能でないなら、受取人は、必要なIKの部品を特定して、そのIKコンポーネントの関連アイオワを特定できなければなりません。 異なったIKsが1組の聖餐拝受者の間の異なったメッセージに使用されるかもしれないことに注意してください。 例えば、1つのメッセージがAからBまで発信して、別のメッセージがAからBがメンバーであるメーリングリストまで発信した(1リストあたりのIKメソッドを使用する)と考えてください。 最初のメッセージは個別にAとBに関連づけられたIKの部品を使用するでしょうが、2番目はリストメンバーの中で共有されたIKの部品を使用するでしょう。
When a privacy-enhanced message is transmitted, an indication of the
プライバシーで高められたメッセージが送られるとき指示
Linn [Page 27] RFC 1113 Mail Privacy: Procedures August 1989
リン[27ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
IK components used for DEK and MIC encryption must be included. To this end, the "X-Sender-ID:" and "X-Recipient-ID:" encapsulated header fields provide the following data:
DEKに使用されるIKの部品とMIC暗号化を含まなければなりません。 これに、終わってください、「X送付者ID:」 そして、「X受取人ID:」 カプセル化されたヘッダーフィールドは以下のデータを提供します:
1. Identification of the relevant Issuing Authority (IA subfield)
1. 関連Issuing Authorityの識別(アイオワ部分体)
2. Identification of an entity with which a particular IK
component is associated (Entity Identifier or EI subfield)
2. 特定のIKの部品が関連している実体の識別(実体IdentifierかEI部分体)
3. Version/Expiration subfield
3. バージョン/満了部分体
The colon character (":") is used to delimit the subfields within an
"X-Sender-ID:" or "X-Recipient-ID:". The IA, EI, and
version/expiration 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):
コロンキャラクタ、(「:」、)、部分体を区切る以内で使用されている、「X送付者ID:」 または、「X受取人ID:」 アイオワ、EI、およびバージョン/満了部分体は制限された文字集合から生成されます、以下のBNFによって処方されるように(RFC-822、セクション2と3.3で定義されるように記法を使用して):
IKsubfld := 1*ia-char
IKsubfld:=1*ia-炭
ia-char := DIGIT / ALPHA / "'" / "+" / "(" / ")" /
"," / "." / "/" / "=" / "?" / "-" / "@" /
"%" / "!" / '"' / "_" / "<" / ">"
An example "X-Recipient-ID:" field is as follows:
:=DIGIT/アルファー/をia炭にしてください。「「'」 「/「+」/「(「/」)」/」、/」、」、' / "/" / "=" / "?" / "-" / "@" / "%" / "!" /、'、「'/"_"/"<"/">"、例、「X受取人ID:」、'、」 分野は以下の通りです:
X-Recipient-ID: linn@ccy.bbn.com:ptf-kmc:2
X受取人ID: linn@ccy.bbn.com :ptf-kmc:2
This example field indicates that IA "ptf-kmc" has issued an IK component for use on messages sent to "linn@ccy.bbn.com", and that the IA has provided the number 2 as a version indicator for that IK component.
この例の分野は、アイオワ"ptf-kmc"が" linn@ccy.bbn.com "に送られたメッセージにおける使用のためにIKの部品を発行して、アイオワがそのIKの部品のためのバージョンインディケータとしてNo.2を提供したのを示します。
5.2.1 Subfield Definitions
5.2.1 部分体定義
The following subsections define the subfields of "X-Sender-ID:" and "X-Recipient-ID:" fields.
以下の小区分が部分体を定義する、「X送付者ID:」 そして、「X受取人ID:」 分野。
5.2.1.1 Entity Identifier Subfield
5.2.1.1 エンティティ識別名部分体
An entity identifier is constructed as an IKsubfld. More restrictively, an entity identifier subfield assumes the following form:
エンティティ識別名はIKsubfldとして構成されます。 より制限的に、エンティティ識別名部分体は以下のフォームを仮定します:
<user>@<domain-qualified-host>
<のユーザ>@<ドメインで適任のホスト>。
In order to support universal interoperability, it is necessary to assume a universal form for the naming information. For the case of installations which transform local host names before transmission into the broader Internet, it is strongly recommended that the host
普遍的な相互運用性をサポートするために、命名情報のための普遍的なフォームを仮定するのが必要です。 トランスミッションの前にローカル・ホスト名をより広いインターネットに変えるインストールに関するケースにおいて、それがそれに強く推薦される、ホスト
Linn [Page 28] RFC 1113 Mail Privacy: Procedures August 1989
リン[28ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
name as presented to the Internet be employed.
名前、インターネットに提示されるように、使われてください。
5.2.1.2 Issuing Authority Subfield
5.2.1.2 発行機関部分体
An IA identifier subfield is constructed as an IKsubfld. IA identifiers must be assigned in a manner which assures uniqueness. This can be done on a centralized or hierarchic basis.
アイオワ識別子部分体はIKsubfldとして構成されます。 ユニークさを保証する方法でアイオワ識別子を割り当てなければなりません。 集結されたか階層的なベースでこれができます。
5.2.1.3 Version/Expiration Subfield
5.2.1.3 バージョン/満了部分体
A version/expiration subfield is constructed as an IKsubfld. The version/expiration subfield format may vary among different IAs, but must satisfy certain functional constraints. An IA's version/expiration subfields must be sufficient to distinguish among the set of IK components issued by that IA for a given identified entity. Use of a monotonically increasing number is sufficient to distinguish among the IK components provided for an entity by an IA; use of a timestamp additionally allows an expiration time or date to be prescribed for an IK component.
バージョン/満了部分体はIKsubfldとして構成されます。 バージョン/満了部分体形式は、異なったIAsの中で異なるかもしれませんが、ある関数制約条件を満たさなければなりません。 アイオワのバージョン/満了部分体は、与えられた特定された実体のためにそのアイオワによって発行されたIKの部品のセットの中で区別するために十分でなければなりません。 単調に増加する数の使用がアイオワによって実体に提供されたIKの部品の中で区別できるくらいの。 タイムスタンプの使用は、満了時間か日付がIKの部品に定められるのをさらに、許容します。
5.2.2 IK Cryptoperiod Issues
5.2.2 IK Cryptoperiod問題
An IK component's cryptoperiod is dictated in part by a tradeoff between key management overhead and revocation responsiveness. It would be undesirable to delete an IK component permanently before receipt of a message encrypted using that IK component, as this would render the message permanently undecipherable. Access to an expired IK component 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 IK components 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 IK components for indefinite periods.
IKコンポーネントのcryptoperiodはかぎ管理オーバーヘッドと取消しの反応性の間の見返りで一部書き取られます。 これとしてそのIKの部品を使用することで暗号化されたメッセージの領収書が永久に非解読可能にメッセージを伝える前に永久にIKの部品を削除するのは望ましくないでしょう。 例えば、満期のIKの部品へのアクセスが、ユーザ(または、システム)によって受け取られた時間の長期間の間不活発であったメールを処理するのに必要でしょう。 非常に古いIKの部品が削除されるのを可能にするために、暗号化された地方の長期ストレージを望んでいるメッセージの受取人はメッセージ・テキスト暗号化に無期限の間、古いIKの部品のアイオワのメインテナンスに依存するより局所的に維持されたIKの下の再暗号化でむしろ使用されるDEKを変えるべきです。
6. User Naming
6. ユーザ命名
6.1 Current Approach
6.1 現在のアプローチ
Unique naming of electronic mail users, as is needed in order to
select corresponding keys correctly, is an important topic and one
which has received significant study. Our current architecture
associates IK components with user names represented in a universal
form ("user@domain-qualified-host"), relying on the following
properties:
正しく対応するキーを選択するのに必要である電子メールユーザのユニークな命名は、重要な話題と重要な研究を受け取ったものです。 以下の特性を当てにして、私たちの現在のアーキテクチャは普遍的なフォーム(" user@domain-qualified-host ")に表されるユーザ名にIKの部品を関連づけます:
1. The universal form must be specifiable by an IA as it
distributes IK components and known to a UA as it processes
1. IKの部品を分配して、処理するのでUAにおいて知られていて、普遍的なフォームはアイオワが明記できるに違いありません。
Linn [Page 29] RFC 1113 Mail Privacy: Procedures August 1989
リン[29ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
received IK components and IK component identifiers. 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.
容認されたIKの部品とIKコンポーネント識別子。 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 universal form as used for Internet mail transmission may cause property 2 to be violated.
インターネット中でこれらの特性を確実にするのは難しいです。 例えば、インターネット・メール送信に使用されるように組織の中で使用された地方のフォームと普遍的な用紙の間のアドレス表現を変えるMTSは特性2を違反させるかもしれません。
6.2 Issues for Consideration
6.2 考慮のための問題
The use of flat (non-hierarchic) electronic mail user identifiers, which are unrelated to the hosts on which the users reside, may offer value. As directory servers become more widespread, it may become appropriate for would-be senders to search for desired recipients based on such attributes. 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 DARPA/DoD domain 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 consideration.
ユニークユーザーIDにユーザ名を決議するためにDARPA/DoDドメインシステムとその関連ネームサーバを広げるという見通しを調べるのは適切であるかもしれません。 追加設定はメーリングリストサポートに関して起こります: ネームサーバは現在、リストの(潜在的に再帰的)の拡張をユーザに実行しません。 ISOとCSNetはユーザレベルディレクトリサービスメカニズムに取り組んでいます。(また、メカニズムは考慮に堪えるかもしれません)。
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 which is
このRFCで文脈と議論したメカニズムとアプローチを置くために、このセクションはプロトタイプ実装の概要を提示します。 この実装はそうするスタンドアロンプログラムです。
Linn [Page 30] RFC 1113 Mail Privacy: Procedures August 1989
リン[30ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
invoked by a user, and lies above the existing UA sublayer. In the UNIX 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. 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.
既存のUA副層を超えてユーザで呼び出して、横たわりました。 UNIXシステム、およびことによるとまた、他の環境で、電子メールの中の「フィルタ」UAかテキストエディタとしてそのようなプログラムを呼び出すことができます、ユーザが実行しなければならない操作の系列を簡素化して。 この形式の統合は特定のUAだけと互換性があるよりむしろさまざまな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.
ユーザがプライバシー増進を送信されるメッセージに適用したがっているとき、ユーザは、メッセージのテキストを準備して、スタンドアロンプログラム(アドレス情報と他のデータを提供するためにプログラムと対話するのがプライバシー増進処理を実行するのが必要である)を呼び出します。(順番に、それは、UAを通してトランスミッションに適した出力を生成します)。 ユーザがプライバシーで高められたメッセージを受け取るとき、UAは暗号化されたフォームでメッセージを提供します、スタンドアロンプログラムは復号化と関連処理に適しています。
In this prototype implementation (based on symmetric key management), a cache of IK components is maintained in a local file, with entries managed manually based on information provided by originators and recipients. This cache is, effectively, a simple database. IK components are selected for transmitted messages based on the sender's identity and on recipient names, and corresponding "X- Sender-ID:" and "X-Recipient-ID:" fields are placed into the message's encapsulated header. When a message is received, these fields are used as a basis for a lookup in the database, yielding the appropriate IK component entries. DEKs and IVs are generated dynamically within the program.
このプロトタイプ実装(対称鍵管理に基づいている)では、IKの部品のキャッシュはローカルファイルで維持されます、エントリーが創始者と受取人によって提供された情報に基づいた手動で管理にされるので。 事実上、このキャッシュは簡単なデータベースです。 IKの部品が送付者のアイデンティティに基づく伝えられたメッセージと受取人名の上で選択されて、対応している、「X送付者ID:」 そして、「X受取人ID:」 野原はメッセージのカプセル化されたヘッダーに置かれます。 メッセージが受信されているとき、これらの分野はデータベースのルックアップの基礎として使用されます、適切なIKコンポーネントエントリーをもたらして。 DEKsとIVsはプログラムの中でダイナミックに生成されます。
Options and destination addresses are selected by command line arguments to the standalone program. 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 in "X-Sender-ID:" and "X-Recipient-ID:" fields.
オプションと送付先アドレスはコマンドライン議論でスタンドアロンプログラムに選択されます。 MTSによる使用において、プライバシーエンハンスプログラムに送付先アドレスを指定する機能は論理的に対応するアドレスを指定する機能からUAまで異なっています。 この分離がUAへの指定されるとしてのアドレスの地方のフォームが中で使用されるように多くの場合においてインターネットのグローバルなフォームと異なっているという事実から生じる、「X送付者ID:」 そして、「X受取人ID:」 分野。
8. Areas For Further Study
8. さらなる研究への領域
The procedures defined in this RFC are sufficient to support 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 [Page 31] RFC 1113 Mail Privacy: Procedures August 1989
リン[31ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
functions.
機能。
2. Detailed standardization of Issuing Authority and directory
service functions and interactions.
2. Issuing Authority、ディレクトリサービス機能、および相互作用の詳細な標準化。
3. Privacy-enhanced interoperability with X.400 mail.
3. 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
Message Authentication Code (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
may to be used to perform encryption.
FIPS PUB81、OperationのDES Modes(1980年12月2日)は暗号化を実行するのに使用されるために、データ暗号化規格アルゴリズムがそうするかもしれない特定のモードを定義します。
FIPS PUB 113, Computer Data Authentication, May 1985, defines a
specific procedure for use of the Data Encryption Standard
algorithm to compute a MAC.
FIPS PUB113、データ暗号化規格アルゴリズムの使用がMACを計算するように、コンピュータData Authentication(1985年5月)は特定の手順を定義します。
NOTES:
注意:
[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.
[1] MIC計算とメッセージ・テキスト暗号化のためのキー生成は送付ホストか集結されたサーバによって実行されるかもしれません。このRFCはこのデザイン代替手段を抑制しません。 対称鍵管理が採用しているなら、セクション5.1は集結されたサーバアプローチの可能な利点を特定します。
[2] American National Standard Data Encryption Algorithm (ANSI
X3.92-1981), American National Standards Institute, Approved 30
December 1980.
[2] 米国標準規格データ暗号化アルゴリズム(ANSI X3.92-1981)、American National Standards Institut、承認された1980年12月30日。
[3] Federal Information Processing Standards Publication 46, Data
Encryption Standard, 15 January 1977.
[3] 連邦政府の情報処理規格、公表46、データ暗号化規格、1977年1月15日。
Linn [Page 32] RFC 1113 Mail Privacy: Procedures August 1989
リン[32ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
[4] Information Processing Systems: Data Encipherment: Modes of
Operation of a 64-bit Block Cipher.
[4] 情報処理システム: データ暗号文: 64ビットのブロックの運転モードは解かれます。
[5] Federal Information Processing Standards Publication 81, DES
Modes of Operation, 2 December 1980.
[5] 連邦政府の情報処理規格、公表81、DES運転モード、1980年12月2日。
[6] ANSI X9.17-1985, American National Standard, Financial
Institution Key Management (Wholesale), American Bankers
Association, April 4, 1985, Section 7.2.
[6]ANSI X9.17-1985、米国標準規格、金融機関Key Management(大量の)、アメリカ銀行家協会、1985年4月4日、セクション7.2。
[7] Postel, J., "Simple Mail Transfer Protocol" RFC-821,
USC/Information Sciences Institute, August 1982.
[7] USC/情報科学は、1982年8月にポステル、J.、「簡単なメール転送プロトコル」RFC-821を設けます。
[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.
[8] この変換は、介入しているリレーに起こるのではなく、SMTP終点だけに起こるべきですが、SMTP分野を他の環境にリンクしながら、ゲートウェイシステムで行われるかもしれません。
[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.
[9] この中間結果があるSMTP相互運用性が必要であるので選択されたのではなく、それがインターネットコミュニティで広く使用して、実装されるので、SMTP canonicalization手順の使用は現在のところ、選択されました。 プライバシーで高められたメッセージは全くトランスミッションのために直接4相数変換の手順におけるこのステップよりSMTPに移られないでしょう。
[10] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", RFC-822, August 1982.
[10] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、RFC-822、1982年8月。
[11] Rose, M. and E. Stefferud, "Proposed Standard for Message
Encapsulation", RFC-934, January 1985.
[11] ローズとM.とE.Stefferud、「メッセージカプセル化の提案された標準」、RFC-934、1985年1月。
[12] CCITT Recommendation X.411 (1988), "Message Handling Systems:
Message Transfer System: Abstract Service Definition and
Procedures".
[12] CCITT推薦X.411(1988)、「メッセージハンドリングシステム:」 メッセージ転送システム: 「抽象的なサービス定義と手順。」
[13] CCITT Recommendation X.509 (1988), "The Directory -
Authentication Framework".
[13] CCITT推薦X.509(1988)、「ディレクトリ--認証、フレームワーク、」
[14] Kille, S., "Mapping between X.400 and RFC-822", RFC-987, June
1986.
[14]Kille、S.、「X.400とRFC-822の間のマッピング」、RFC-987、1986年6月。
[15] Federal Information Processing Standards Publication 113,
Computer Data Authentication, May 1985.
[15] 公表113(コンピュータのデータ認証)が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.
[16] 情報システムのための米国標準規格--データ暗号化アルゴリズム--運転モード(ANSI X3.106-1983)、American National Standards Institut--承認された1983年5月16日。
[17] Voydock, V. and S. Kent, "Security Mechanisms in High-Level
[17]VoydockとV.とS.ケント、「ハイレベルのセキュリティー対策」
Linn [Page 33] RFC 1113 Mail Privacy: Procedures August 1989
リン[33ページ]RFC1113はプライバシーを郵送します: 手順1989年8月
Network Protocols", ACM Computing Surveys, Vol. 15, No. 2, Pages
135-171, June 1983.
「ネットワーク・プロトコル」、135-171と、1983年6月に調査、Vol.15、No.2、ページを計算するACM。
Author's Address
作者のアドレス
John Linn
Secure Systems
Digital Equipment Corporation
85 Swanson Road, BXB1-2/D04
Boxborough, MA 01719-1326
DEC85スワンソンRoad、BXB1-2/D04 Boxborough、ジョン・リンSecureのSystems MA01719-1326
Phone: 508-264-5491
以下に電話をしてください。 508-264-5491
EMail: Linn@ultra.enet.dec.com
メール: Linn@ultra.enet.dec.com
Linn [Page 34]
リン[34ページ]
一覧
スポンサーリンク
