RFC1421 日本語訳
1421 Privacy Enhancement for Internet Electronic Mail: Part I: MessageEncryption and Authentication Procedures. J. Linn. February 1993. (Format: TXT=103894 bytes) (Obsoletes RFC1113) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Linn Request for Comments: 1421 IAB IRTF PSRG, IETF PEM WG Obsoletes: 1113 February 1993
コメントを求めるワーキンググループJ.リンの要求をネットワークでつないでください: 1421IAB IRTF PSRG、IETF PEM WGは以下を時代遅れにします。 1113 1993年2月
Privacy Enhancement for Internet Electronic Mail:
Part I: Message Encryption and Authentication Procedures
インターネット電子メールのためのプライバシー増進: 部分I: メッセージ暗号化と認証手順
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Acknowledgements
承認
This document is the outgrowth of a series of meetings of the Privacy and Security Research Group (PSRG) of the IRTF and the PEM Working Group of the IETF. I would like to thank the members of the PSRG and the IETF PEM WG, as well as all participants in discussions on the "pem-dev@tis.com" mailing list, for their contributions to this document.
このドキュメントはIRTFのPrivacyとSecurity Research Group(PSRG)とIETFのPEM作業部会の一連のミーティングの派生物です。 PSRGとIETF PEM WGのメンバーに感謝申し上げます、" pem-dev@tis.com "メーリングリストについての議論のすべての関係者と同様に、このドキュメントへの彼らの貢献のために。
1. Executive Summary
1. 要約
This document defines message encryption and authentication procedures, in order to provide privacy-enhanced mail (PEM) services for electronic mail transfer in the Internet. It is intended to become one member of a related set of four RFCs. The procedures defined in the current document 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 1422 specifies supporting key management mechanisms based on the use of public-key certificates. RFC 1423 specifies algorithms, modes, and associated identifiers relevant to the current RFC and to RFC 1422. RFC 1424 provides details of paper and electronic formats and procedures for the key management infrastructure being established in support of these services.
このドキュメントはメッセージ暗号化と認証手順を定義します、電子メール転送のためのプライバシーで高められたメール(PEM)サービスをインターネットに提供するために。 4RFCsの関連するセットの1人のメンバーになるのは意図しています。 現在のドキュメントで定義された手順はさまざまなかぎ管理アプローチと互換性があることを意図します、左右対称の(秘密鍵)とキーを暗号化するデータの暗号化のための非対称の(公開鍵)アプローチの両方を含んでいて。 左右対称の暗号のメッセージ・テキスト暗号化、そして/または、保全チェック計算の使用は予期されます。 かぎ管理が公開鍵証明書の使用に基づくメカニズムであるとサポートしながら、RFC1422は指定します。 RFC1423はRFC1422に現在のRFCと、そして、関連しているアルゴリズム、モード、および関連識別子を指定します。 RFC1424はこれらのサービスを支持して確立されるかぎ管理インフラストラクチャに紙、電子形式、および手順の詳細を明らかにします。
Privacy enhancement services (confidentiality, authentication, message integrity assurance, and non-repudiation of origin) are offered through the use of end-to-end cryptography between originator and recipient processes at or above the User Agent level. No special processing requirements are imposed on the Message Transfer System at
終わりから終わりへの暗号の使用でプライバシー増進サービス(発生源の秘密性、認証、メッセージの保全保証、および非拒否)を創始者と受取人プロセスの間にレベルにおいてUserエージェントレベルより上まで提供します。 どんな特別な処理所要もMessage Transfer Systemに課されません。
Linn [Page 1] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[1ページ]RFC1421プライバシー増進
endpoints or at intermediate relay sites. This approach allows privacy enhancement facilities to be incorporated selectively 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.
終点か中間的では、サイトをリレーしてください。 このアプローチは、プライバシー増進施設が他のインターネット実体に影響なしでサイトごとのユーザごとのベースで選択的に組み込んでいるのを許容します。 異種のコンポーネントとメール運送設備の相互運用性はサポートされます。
The current specification's scope is confined to PEM processing procedures for the RFC-822 textual mail environment, and defines the Content-Domain indicator value "RFC822" to signify this usage. Follow-on work in integration of PEM capabilities with other messaging environments (e.g., MIME) is anticipated and will be addressed in separate and/or successor documents, at which point additional Content-Domain indicator values will be defined.
現在の仕様の範囲は、RFC-822の原文のメール環境のためにPEM現像処理に閉じ込められて、この用法を意味するようにContent-ドメインインディケータ価値の"RFC822"を定義します。 他のメッセージング環境(例えば、MIME)があるPEM能力の統合におけるフォローオン仕事は、予期されて、別々である、そして/または、後継者ドキュメントで扱われるでしょう。そこでは、追加Content-ドメインインディケータが評価するポイントが定義されるでしょう。
2. Terminology
2. 用語
For descriptive purposes, this RFC uses some terms defined in the OSI X.400 Message Handling System Model per the CCITT Recommendations. This section replicates a portion of (1984) 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はCCITT RecommendationsあたりのOSI X.400 Message Handling System Modelで定義されたいくつかの用語を使用します。 このセクションは「MHSの記述は以下をモデル化する」(1984)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とまとめて呼ばれます。
Linn [Page 2] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[2ページ]RFC1421プライバシー増進
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 originator and recipient processes residing at the UA level or above. No privacy enhancements are offered for message fields which are added or transformed by intermediate relay points between PEM processing components.
このRFCは、インターネットで移された電子メールのためにプライバシーを高めるためにメカニズムを定義します。 このRFCで議論した施設は、UAレベルにおいて上に住みながら、創始者と受取人プロセスの間の終わりから終わりへのベースでプライバシー増進サービスを提供します。 プライバシー増進を全く加えられるメッセージ分野のために提供もしませんし、PEM処理の部品の間の中間的リレーポイント変えもしません。
If an originator elects to perform PEM processing on an outbound message, all PEM-provided security services are applied to the PEM message's body in its entirety; selective application to portions of a PEM message is not supported. Authentication, integrity, and (when asymmetric key management is employed) non-repudiation of origin services are applied to all PEM messages; confidentiality services are optionally selectable.
創始者が、外国行きのメッセージにPEM処理を実行するのを選ぶなら、すべてのPEMによって提供されたセキュリティー・サービスがPEMメッセージのボディーに全体として当てられます。 PEMメッセージの部分への選択しているアプリケーションはサポートされません。 発生源サービスの認証、保全、および(非対称のかぎ管理が採用しているとき)非拒否はすべてのPEMメッセージに適用されます。 秘密性サービスは任意に選択可能です。
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 originator to be
cognizant of whether a message's intended recipient
implements privacy enhancements, in order that encoding and
possible encryption will not be performed on a message whose
destination is not equipped to perform corresponding inverse
transformations. (Section 4.6.1.1.3 of this RFC describes a
PEM message type ("MIC-CLEAR") which represents a signed,
unencrypted PEM message in a form readable without PEM
processing capabilities yet validatable by PEM-equipped
recipients.)
2. 定義されたメカニズムは非高められたインターネットコンポーネントと互換性があります。 プライバシー増進は終わりから終わりへの中間的中継ホストによるメール処理に影響を与えないファッションで実装されます(プライバシー増進施設を取り入れません)。 しかしながら、メッセージの意図している受取人が、プライバシーが増進であると実装するかどうかをメッセージの創始者が認識しているのが必要です、コード化していて可能な暗号化が対応する逆さの変換を実行するために目的地を備えていないメッセージに実行されないように。 (セクション4.6 .1 .1 この.3RFCがPEMによって備えられている受取人でまだ有効に可能なPEM処理能力なしで読み込み可能なフォームに署名しているunencrypted PEMメッセージを表すPEMメッセージタイプ(「ミックCLEAR」)について説明します。)
3. The defined mechanisms are compatible with a range of mail
transport facilities (MTAs). Within the Internet,
3. 定義されたメカニズムはさまざまなメール運送設備(MTAs)と互換性があります。 インターネットの中で
Linn [Page 3] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[3ページ]RFC1421プライバシー増進
electronic mail transport is effected by a variety of SMTP
[2] 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.
電子メール輸送はさまざまなSMTP[2]実装で作用します。 ある一定の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
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 PEM
services are to be provided.
4. 定義されたメカニズムは広範囲な電子メールユーザエージェント(UAs)と互換性があります。 ユーザーインタフェースパラダイムの対応する広い声域で、さまざまな電子メールユーザエージェントプログラムがインターネットで使用されます。 可能な限り広いユーザーコミュニティに利用可能です、選択されたメカニズムが可能な限り広いバラエティーの既存のUAプログラムで使用可能であるべきであるということになってください。電子メールプライバシー増進、パイロット実装の目的のために、プライバシー増進処理が供給されるPEMサービスがことである各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 PEM with a higher assurance level than a strictly
UA-integrated approach would allow.
5. 定義されたメカニズムで、電子メールプライバシー増進処理はUA機能が実装されるシステムから別々のパーソナルコンピュータ(PC)に働きます。 PCの拡張使用と多くのユーザが置かれたコネが多くのマルチユーザーシステム、この属性に関するUA実装であったかもしれないならaより高い保証レベルで厳密にPEMを処理できる限られた度合いの信頼を考えて、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 per RFC 1422. Different
key management mechanisms may be used for different
recipients of a multicast message. For two PEM
implementations to interoperate, they must share a common
key management mechanism; support for the mechanism defined
in RFC 1422 is strongly encouraged.
7. このRFCの中で定義されたメカニズムはさまざまなサポートの主要なマネージメント・アプローチと互換性があります、(他)マニュアルプレ分配、左右対称の暗号に基づく、集結された主要な分配、およびRFC1422あたりの公開鍵証明書の使用を含んでいて。 異なったかぎ管理メカニズムはマルチキャストメッセージの異なった受取人に使用されるかもしれません。 2つのPEM実装が共同利用するために、一般的なかぎ管理メカニズムを共有しなければなりません。 RFC1422で定義されたメカニズムのサポートは強く奨励されます。
Linn [Page 4] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[4ページ]RFC1421プライバシー増進
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 and pervasive modifications throughout the Internet, the following design principles were applied in selecting the set of features specified in this RFC:
可能な限り広範囲のインターネット・ホストとメールシステムへの適用性を達成して、パイロット実装とインターネット中の先の、そして、普及している変更の必要性なしでテストするのを容易にするために、以下の設計原理はこのRFCで指定された特徴のセットを選択する際に適用されました:
1. This RFC's measures are restricted to implementation at
endpoints and are amenable to integration with existing
Internet mail protocols at the user agent (UA) level or
above, rather than necessitating modifications to existing
mail protocols or integration into the message transport
system (e.g., SMTP servers).
1. このRFCの測定は、既存のメールプロトコルへの変更かメッセージ輸送システムへの統合(例えば、SMTPサーバー)を必要とするよりむしろ終点の実装に制限されて、ユーザエージェントのインターネット・メールプロトコル(UA)が平らにする存在によって統合に従順であるか、または上です。
2. The set of supported measures enhances rather than restricts
user capabilities. Trusted implementations, incorporating
integrity features protecting software from subversion by
local users, cannot be assumed in general. No mechanisms
are assumed to prevent users from sending, at their
discretion, messages to which no PEM processing has been
applied. 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. サポートしている測定のセットは制限するよりむしろユーザ能力を高めます。 一般に、地元のユーザによる転覆からソフトウェアにプロテクトをかける保全機能を取り入れて、信じられた実装を想定できません。 ユーザがメカニズムによって全く発信できないと思われません、自己判断で、PEM処理がそれのノーに適用されたメッセージ。 そのような特徴がないとき、それはユーザサービス(例えば、相互ユーザトラフィックを保護して、認証するのによる)を機能アップする施設を提供するのにおいてユーザ動作のときに制限(例えば、相互ユーザアクセスコントロール)を実施するより可能に見えます。
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セットの機能的な能力に焦点を合わせます。 最も重要なサービスに集中することによって、私たちは、穏やかなレベルの実装取り組みを提供できる加えられたプライバシー値を最大にすることを目指します。
Based on these principles, the following facilities are provided:
これらの原則に基づいて、以下の施設を提供します:
1. disclosure protection,
1. 公開保護
2. originator 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. コントロールにアクセスしてください。
Linn [Page 5] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[5ページ]RFC1421プライバシー増進
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
stream-oriented services
8. メッセージ写し検出、再生防止、または他のストリーム指向のサービス
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 PEM transmission:
階層構造を合わせる2レベルがPEMがトランスミッションであるとサポートするのに使用されます:
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. In the asymmetric key management
environment, DEKs are also used to encrypt the signed
representations of MICs in PEM messages to which
confidentiality has been applied. DEKs are generated
individually for each transmitted message; no
predistribution of DEKs is needed to support PEM
transmission.
1. そして、データEncryptingキーズ(DEKs)がメッセージ・テキストの暗号化に使用される、(代替のアルゴリズムのセットの中に、ある選択がある) メッセージの保全の計算がないかどうか、(MIC)量をチェックしてください。 また、非対称のかぎ管理環境DEKsは秘密性が適用されたPEMメッセージにおける、MICsの署名している表現を暗号化するのにおいて使用されています。 DEKsはそれぞれの伝えられたメッセージのために個別に生成されます。 DEKsの前分配は全くPEMがトランスミッションであるとサポートされる必要はありません。
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
2. 置き換えキーズ(IKs)は、メッセージの中のトランスミッションのためにDEKsをコード化するのに使用されます。 通常、同じIKは期間の間に与えられた創始者から与えられた受取人に送られたすべてのメッセージに使用されるでしょう。 それぞれの伝えられたメッセージはメッセージ暗号化、そして/または、MIC計算に中古の、そして、命名された受取人あたり1個々のIKの下でコード化されたDEK(s)の表現を含んでいます。 表現はそうです。
Linn [Page 6] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[6ページ]RFC1421プライバシー増進
associated with Originator-ID and Recipient-ID fields
(defined in different forms so as to distinguish symmetric
from asymmetric cases), 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 validation. The definition of an IK
differs depending on whether symmetric or asymmetric
cryptography is used for DEK encryption:
Originator-IDとRecipient-ID分野(異なったフォームで、非対称のケースのために左右対称の状態で区別するために定義される)に関連していて、それぞれの個々の受取人がどれでIKを特定できるかがその受取人の使用のために以前はよくDEKs、そして/または、MICsをコード化していました。 適切なIKを考えて、受取人は、対応する伝えられたDEKが表現であると解読することができます、メッセージ・テキスト復号化、そして/または、MIC合法化に必要であるDEKをもたらして。 左右対称の、または、非対称の暗号がDEK暗号化に使用されるかどうかによって、IKの定義は異なります:
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 [8] 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 a Recipient-ID
or Originator-ID field, respectively.
Alternatively, an originator's IK component may be
determined from a certificate carried in an
"Originator-Certificate:" field.
2b。 非対称の暗号が使用されているとき、DEK暗号化に使用されるIKの部品は受取人の公共のコンポーネント[8]です。 MIC暗号化に使用されるIKの部品は創始者の個人的なコンポーネントです、そして、したがって、1つのコード化されたMIC表現だけが1受取人あたり1つよりむしろメッセージ単位で含まれなければなりません。 それぞれのこれらのIKの部品は完全にRecipient-IDかOriginator-ID分野でそれぞれ資格がある場合があります。 証明書から運び込む、あるいはまた、創始者のIKの部品が決定しているかもしれない「創始者証明書:」 さばきます。
4.1.2 Processing Procedures
4.1.2 現像処理
When PEM 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 where confidentiality is not to be applied, unless a chosen MIC computation algorithm requires a DEK. Other parameters (e.g., Initialization Vectors (IVs)) as required by selected encryption algorithms are also generated.
PEM処理が送信されるメッセージに実行されることであるときに、DEKはメッセージ暗号化における使用のための発生している[1]です、そして、DEKの(選ばれたMICアルゴリズムがキーを必要とするなら)異形はMIC計算における使用のために形成されます。 秘密性を適用していてはいけないメッセージに関するケースのためにDEK世代を省略できます、選ばれたMIC計算アルゴリズムがDEKを必要としない場合。 また、他のパラメタ(例えば、初期設定Vectors(IVs))は必要に応じて選択された暗号化アルゴリズムで発生します。
One or more Originator-ID and/or "Originator-Certificate:" fields are included in a PEM message's encapsulated header to provide recipients with an identification component for the IK(s) used for message
より多くのOne Originator-ID、「以下を創始者と同じくらい証明してください」 分野は、メッセージに使用されるIK(s)のために識別コンポーネントを受取人に提供するためにPEMメッセージの要約のヘッダーに含まれています。
Linn [Page 7] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[7ページ]RFC1421プライバシー増進
processing. All of a message's Originator-ID and/or "Originator- Certificate:" fields are assumed to correspond to the same principal; the facility for inclusion of multiple such fields accomodates the prospect that different keys, algorithms, and/or certification paths may be required for processing by different recipients. When a message includes recipients for which asymmetric key management is employed as well as recipients for which symmetric key management is employed, a separate Originator-ID or "Originator-Certificate:" field precedes each set of recipients.
処理。 メッセージのOriginator-ID、そして/または、「創始者は以下を証明する」すべて 分野が同じ校長に相当すると思われます。 複数のそのような分野の包含のための施設は異なったキー、アルゴリズム、そして/または、証明経路が処理のために異なった受取人によって必要とされるかもしれないという見通しをaccomodatesします。 メッセージがどの非対称のキーのために受取人を含んでいるかと、管理は、受取人と同様にどの対称鍵に使われて、管理が採用しています、別々のOriginator-IDということであるか「以下を創始者と同じくらい証明します」。 分野はそれぞれのセットの受取人に先行します。
In the symmetric case, per-recipient IK components are applied for each individually named recipient in preparation of ENCRYPTED, MIC- ONLY, and MIC-CLEAR messages. A corresponding "Recipient-ID- Symmetric:" field, interpreted in the context of the most recent preceding "Originator-ID-Symmetric:" field, serves to identify each IK. In the asymmetric case, per-recipient IK components are applied only for ENCRYPTED messages, are independent of originator-oriented header elements, and are identified by "Recipient-ID-Asymmetric:" fields. Each Recipient-ID field is followed by a "Key-Info:" field, which transfers the message's DEK encrypted under the IK appropriate for the specified recipient.
左右対称の場合では、ENCRYPTED、ミックだけ、およびミック-CLEARメッセージの準備でそれぞれ個別に受取人と命名されていた状態で1受取人あたりのIKの部品に申し込みます。 対応、「受取人ID左右対称:、」 最新の先行の文脈で解釈された分野、「創始者ID左右対称である、:、」 分野、各IKを特定するサーブ。 1受取人あたりのIKの部品が非対称の場合では、ENCRYPTEDメッセージのためだけに適用されて、創始者指向のヘッダー要素から独立していて、特定される、「受取人ID非対称、:、」 分野。 aがそれぞれのRecipient-ID野原のあとに続いている、「主要なインフォメーション:」 分野。(その分野は指定された受取人にとって、適切なIKの下でコード化されたメッセージのDEKを移します)。
When symmetric key management is used for a given recipient, the "Key-Info:" field following the corresponding "Recipient-ID- Symmetric:" field also transfers the message's computed MIC, encrypted under the recipient's IK. When asymmetric key management is used, a "MIC-Info:" field associated with an "Originator-ID- Asymmetric:" or "Originator-Certificate:" field carries the message's MIC, asymmetrically signed using the private component of the originator. If the PEM message is of type ENCRYPTED (as defined in Section 4.6.1.1.1 of this RFC), the asymmetrically signed MIC is symmetrically encrypted using the same DEK, algorithm, encryption mode and other cryptographic parameters as used to encrypt the message text, prior to inclusion in the "MIC-Info:" field.
対称鍵管理が与えられた受取人に使用されるとき「主要なインフォメーション:」 対応に続く分野、「受取人ID左右対称:、」 また、分野は受取人のIKの下でコード化されたメッセージの計算されたMICを移します。 使用される、非対称のかぎ管理、aである、「MIC-インフォメーション:」 交際した分野、「創始者ID非対称:、」 または、「以下を創始者と同じくらい証明してください」 分野は創始者の個人的なコンポーネントを使用することで非対称的にサインされたメッセージのMICを運びます。 タイプENCRYPTEDにPEMメッセージがある、(中で定義される、セクション4.6 .1 .1 この.1RFC) 非対称的にサインされたMICがメッセージ・テキストをコード化するのに使用されるように同じDEK、アルゴリズム、暗号化モード、および他の暗号のパラメタを使用することで対称的にコード化される、中の包含の前、「MIC-インフォメーション:」 さばきます。
4.1.2.1 Processing Steps
4.1.2.1 処理ステップ
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 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 step (applicable to ENCRYPTED, MIC- ONLY, and MIC-CLEAR messages) and the encryption process (applicable to ENCRYPTED messages only).
4相数変換の手順は、一般に伝えられるフォームに暗号化メッセージテキストを表して、1つのタイプのホストコンピュータの上でコード化されたメッセージが異なったタイプのホストコンピュータの上で解読されるのを可能にするのに使われます。 ホストの固有の文字の組と線表現を使用して、地方のフォームで平文メッセージを受け入れます。 地方のフォームはメッセージ・テキストの相互SMTP表現に同じくらい同等な状態で定義された正準なメッセージ・テキスト表現に変換されます。 この正準な表現はMIC計算ステップ(ENCRYPTED、ミックだけ、およびミック-CLEARメッセージに適切な)と暗号化の過程(ENCRYPTEDメッセージだけに適切な)に入力を形成します。
Linn [Page 8] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[8ページ]RFC1421プライバシー増進
For ENCRYPTED PEM messages, the canonical representation is padded as required by the encryption algorithm, and this padded canonical representation is encrypted. The encrypted text (for an ENCRYPTED message) or the unpadded canonical form (for a MIC-ONLY message) is then 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. MIC-CLEAR PEM messages omit the printable encoding step.
ENCRYPTED PEMメッセージに関しては、正準な表現は必要に応じて暗号化アルゴリズムで水増しされます、そして、このそっと歩いている正準な表現はコード化されています。 そして、コード化されたテキスト(ENCRYPTEDメッセージのための)か非水増し標準形(ミックだけメッセージのための)が印刷可能なフォームにコード化されます。 印刷可能なフォームはサイトの向こう側に一般に「表-可能」になるように選ばれていて、実体とMTS実体の間の処理で混乱させられない制限された文字の組で構成されます。 ミック-CLEAR PEMメッセージは印刷可能なコード化ステップを省略します。
The output of the previous processing steps is combined with a set of header fields carrying cryptographic control information. The resulting PEM message is passed to the electronic mail system to be included within the text portion of a transmitted message. There is no requirement that a PEM message comprise the entirety of an MTS message's text portion; this allows PEM-protected information to be accompanied by (unprotected) annotations. It is also permissible for multiple PEM messages (and associated unprotected text, outside the PEM message boundaries) to be represented within the encapsulated text of a higher-level PEM message. PEM message signatures are forwardable when asymmetric key management is employed; an authorized recipient of a PEM message with confidentiality applied can reduce that message to a signed but unencrypted form for forwarding purposes or can re-encrypt that message for subsequent transmission.
前の処理ステップの出力は暗号の制御情報を運ぶ1セットのヘッダーフィールドに結合されます。 結果として起こるPEMメッセージは、伝えられたメッセージのテキスト部分の中に含まれるように電子メール・システムに通過されます。 PEMメッセージがMTSメッセージのテキスト部分の全体を包括するという要件が全くありません。 これは、(保護のない)の注釈でPEMによって保護された情報が伴われるのを許容します。 また、複数のPEMメッセージ(そして、PEMメッセージ限界の外の関連保護のないテキスト)において、よりハイレベルのPEMメッセージの要約のテキストの中に表されるのも許されています。 非対称のかぎ管理が採用しているとき、PEMメッセージ署名は前進可能です。 秘密性が適用されているPEMメッセージの認可された受取人は、推進目的のためにサインされましたが、非コード化されたフォームにそのメッセージを減らすことができるか、またはその後のトランスミッションのためにそのメッセージを再コード化できます。
When a PEM message is received, the cryptographic control fields within its encapsulated header provide the information required for each authorized recipient to perform MIC validation and decryption of the received message text. For ENCRYPTED and MIC-ONLY messages, the printable encoding is converted to a bitstring. Encrypted portions of the transmitted message are decrypted. The MIC is validated. Then, the recipient PEM process converts the canonical representation to its appropriate local form.
PEMメッセージが受信されているとき、要約のヘッダーの中の暗号の制御フィールドはそれぞれの認可された受取人が受け取られていているメッセージ・テキストのMIC合法化と復号化を実行するのに必要である情報を提供します。 ENCRYPTEDとミックだけメッセージに関しては、印刷可能なコード化はbitstringに変換されます。 伝えられたメッセージのコード化された部分は解読されます。 MICは有効にされます。 そして、受取人PEMの過程は適切な地方のフォームに正準な表現を変換します。
4.1.2.2 Error Cases
4.1.2.2 誤り事件
A variety of error cases may occur and be detected in the course of processing a received PEM message. The specific actions to be taken in response to such conditions are local matters, varying as functions of user preferences and the type of user interface provided by a particular PEM implementation, but certain general recommendations are appropriate. Syntactically invalid PEM messages should be flagged as such, preferably with collection of diagnostic information to support debugging of incompatibilities or other failures. RFC 1422 defines specific error processing requirements relevant to the certificate-based key management mechanisms defined therein.
さまざまな誤り事件が、起こって、受信されたPEMメッセージを処理することの間に検出されるかもしれません。 ユーザー選択の関数とユーザーインタフェースのタイプが特定のPEM実現で提供しましたが、ある一般的な推薦が適切であるときに異なって、そのような状態に対応して取られるべき特定の動作は地域にかかわる事柄です。 シンタクス上無効のPEMメッセージは望ましくは診断情報の収集によってそういうものとして両立し難いことか他の失敗のサポートデバッグに旗を揚げられるべきです。 RFC1422はそこに定義された証明書ベースのかぎ管理メカニズムに関連している特定のエラー処理要件を定義します。
Linn [Page 9] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[9ページ]RFC1421プライバシー増進
Syntactically valid PEM messages which yield MIC failures raise special concern, as they may result from attempted attacks or forged messages. As such, it is unsuitable to display their contents to recipient users without first indicating the fact that the contents' authenticity and integrity cannot be guaranteed and then receiving positive user confirmation of such a warning. MIC-CLEAR messages (discussed in Section 4.6.1.1.3 of this RFC) raise special concerns, as MIC failures on such messages may occur for a broader range of benign causes than are applicable to other PEM message types.
MICの故障をもたらすシンタクス上有効なPEMメッセージが特別な関心を高めます、試みられた攻撃か偽造メッセージから生じるとき。 そういうものとして、最初に、コンテンツの信憑性と保全を保証できないという事実を示して、次に、そのような警告の積極的なユーザ確認を受け取らないで受取人ユーザにそれらのコンテンツを表示するのは不適当です。 ミック-CLEARメッセージ、(議論する、セクション4.6 .1 .1 この.3RFC) 特別な関心を高めてください、そのようなメッセージに関するMICの故障が他のPEMメッセージタイプに適切であるより広い範囲の優しい原因のために起こるとき。
4.2 Encryption Algorithms, Modes, and Parameters
4.2 暗号化アルゴリズム、モード、およびパラメタ
For use in conjunction with this RFC, RFC 1423 defines the appropriate algorithms, modes, and associated identifiers to be used for encryption of message text with DEKs.
このRFC、RFCに関連した1423が暗号化に使用されるべき適切なアルゴリズム、モード、および関連識別子を定義する使用には、DEKsと共にテキストを通信させてください。
The mechanisms defined in this RFC incorporate facilities for transmission of cryptographic parameters (e.g., pseudorandom Initializing Vectors (IVs)) with PEM messages to which the confidentiality service is applied, when required by symmetric message encryption algorithms and modes specified in RFC 1423.
このRFCで定義されたメカニズムは秘密性サービスが適用されているPEMメッセージがある暗号のパラメタ(例えば、擬似ランダムInitializing Vectors(IVs))の伝達のために施設を取り入れます、左右対称のメッセージ暗号化アルゴリズムとRFC1423で指定されたモードが必要であると。
Certain operations require encryption of DEKs, MICs, and digital signatures under an IK for purposes of transmission. A header facility indicates the mode in which the IK is used for encryption. RFC 1423 specifies encryption algorithm and mode identifiers and minimum essential support requirements for key encryption processing.
ある操作はトランスミッションの目的のためにIKの下でDEKs、MICs、およびデジタル署名の暗号化を必要とします。 ヘッダー施設はIKが暗号化に使用されるモードを示します。 RFC1423は暗号化アルゴリズム、モード識別子、および最小の不可欠のサポート要件を主要な暗号化処理に指定します。
RFC 1422 specifies asymmetric, certificate-based key management procedures based on CCITT Recommendation X.509 to support the message processing procedures defined in this document. Support for the key management approach defined in RFC 1422 is strongly recommended. The message processing procedures can also be used with symmetric key management, given prior distribution of suitable symmetric IKs, but no current RFCs specify key distribution procedures for such IKs.
RFC1422は本書では定義されたメッセージ現像処理を支持するためにCCITT Recommendation X.509に基づく非対称の、そして、証明書ベースのかぎ管理手順を指定します。 RFC1422で定義されたかぎ管理アプローチのサポートは強く推薦されます。 また、適当な左右対称のIKsの事前分布を考えて、対称鍵管理でメッセージ現像処理を使用できますが、どんな現在のRFCsも主要な分配手順をそのようなIKsに指定しません。
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. Our approach uses a canonicalization step to abstract out local conventions and a subsequent encoding step to
電子メール暗号化メカニズムは基本的な電子メール施設の透明規制と互換性があるに違いありません。 一般に、これらの規制は予想されたユーザ要件に基づいた予期された終点と運送設備の特性の上で確立されます。 また、暗号化メカニズムもそれがインタコネクトするコンピュータ・システムの地方のコンベンションと互換性があるに違いありません。 私たちのアプローチは出ている地方のコンベンションとその後のコード化ステップを抜き取るcanonicalizationステップを使用します。
Linn [Page 10] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[10ページ]RFC1421プライバシー増進
conform to the characteristics of the underlying mail transport medium (SMTP). The encoding conforms to SMTP constraints. Section 4.5 of RFC 821 [2] details SMTP's transparency constraints.
輸送培地(SMTP)を基本的なメールの特性に従わせてください。 コード化はSMTP規制に従います。 RFC821[2]のセクション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のキャラクタであるにすぎないに違いありません。
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 in the Internet 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 server [3]. 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サーバ[3]で記録を当てるために変換されるかもしれません。 その結果、暗号化の過程が<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に通過されるだろうというとき。
Linn [Page 11] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[11ページ]RFC1421プライバシー増進
4.3.2 Approach
4.3.2 アプローチ
Our approach to supporting PEM across an environment in which intermediate conversions may occur defines an encoding for mail which is uniformly representable across the set of PEM UAs regardless of their systems' native character sets. This encoded form is used (for specified PEM message types) to represent mail text in transit from originator to recipient, but the encoding is not applied to enclosing MTS headers or to encapsulated headers inserted to carry control information between PEM UAs. The encoding's characteristics are such that the transformations anticipated between originator and recipient UAs will not prevent an encoded message from being decoded properly at its destination.
中間的変換が起こるかもしれない環境の向こう側にPEMを支持することへの私たちのアプローチは彼らのシステムの固有の文字の組にかかわらずPEM UAsのセットの向こう側に一様に「表-可能」なメールのためのコード化を定義します。 このコード化されたフォームは創始者から受取人までのトランジットにおけるメールテキストを表すのに使用されますが(指定されたPEMメッセージタイプのために)、コード化はMTSヘッダーを同封すること、または、PEM UAsの間まで制御情報を運ぶために挿入された要約のヘッダーに適用されません。 コード化による特性が創始者と受取人UAsの間で予期された変化が、コード化されたメッセージが目的地で適切に解読されるのを防がないようにものであるということです。
Four transformation steps, described in the following four subsections, apply to outbound PEM message processing:
以下の4つの小区分で説明された4変化ステップは外国行きのPEMメッセージ処理に適用されます:
4.3.2.1 Step 1: Local Form
4.3.2.1 ステップ1: 地方のフォーム
This step is applicable to PEM message types ENCRYPTED, MIC-ONLY, and MIC-CLEAR. The message text is created in the system's native character set, with lines delimited in accordance with local convention.
このステップはPEMメッセージタイプのENCRYPTED、ミックだけ、およびミック-CLEARに適切です。 地方のコンベンションによると、線が区切られている状態で、メッセージ・テキストはシステムの固有の文字の組で作成されます。
4.3.2.2 Step 2: Canonical Form
4.3.2.2 ステップ2: 標準形
This step is applicable to PEM message types ENCRYPTED, MIC-ONLY, and MIC-CLEAR. The message text is converted to a universal canonical form, similar to the inter-SMTP representation [4] as defined in RFC 821 [2] and RFC 822 [5]. The procedures performed in order to accomplish this conversion are dependent on the characteristics of the local form and so are not specified in this RFC.
このステップはPEMメッセージタイプのENCRYPTED、ミックだけ、およびミック-CLEARに適切です。 メッセージ・テキストは普遍的な標準形に変換されます、RFC821[2]とRFC822[5]で定義される相互SMTP表現[4]と同様です。 この変換を実行するために実行された手順は、地方のフォームの特性に依存しているので、このRFCで指定されません。
PEM canonicalization assures that the message text is represented with the ASCII character set and "<CR><LF>" line delimiters, but does not perform the dot-stuffing transformation discussed in RFC 821, Section 4.5.2. Since a message is converted to a standard character set and representation before encryption, a transferred PEM message can be decrypted and its MIC can be validated at any type of destination host computer. Decryption and MIC validation is performed before any conversions which may be necessary to transform the message into a destination-specific local form.
RFC821、セクション4.5.2で議論したドットを詰める変化を実行しないのを除いて、PEM canonicalizationは、メッセージ・テキストがASCII文字の組と「<CR><LF>」線デリミタで表されることを保証します。 以来、暗号化、わたっているPEMメッセージを解読することができて、どんなタイプの目的地ホストコンピュータでもMICを有効にすることができる前にメッセージは標準文字セットと表現に変換されます。 復号化とMIC合法化はどんなメッセージを目的地特有の地方のフォームに変えるのに必要であるかもしれない変換の前にも実行されます。
4.3.2.3 Step 3: Authentication and Encryption
4.3.2.3 ステップ3: 認証と暗号化
Authentication processing is applicable to PEM message types ENCRYPTED, MIC-ONLY, and MIC-CLEAR. The canonical form is input to the selected MIC computation algorithm in order to compute an
認証処理はPEMメッセージタイプのENCRYPTED、ミックだけ、およびミック-CLEARに適切です。 標準形は、計算するために選択されたMIC計算アルゴリズムに入力されます。
Linn [Page 12] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[12ページ]RFC1421プライバシー増進
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を計算することの間にそれら自身がそっと歩くのに当てはまるでしょうが。
Encryption processing is applicable only to PEM message type ENCRYPTED. RFC 1423 defines the padding technique used to support encryption of the canonically-encoded message text.
暗号化処理はPEMメッセージタイプENCRYPTEDだけに適切です。 RFC1423は正準によってコード化されたメッセージ・テキストの暗号化を支持するのに使用される詰め物のテクニックを定義します。
4.3.2.4 Step 4: Printable Encoding
4.3.2.4 ステップ4: 印刷可能なコード化
This printable encoding step is applicable to PEM message types ENCRYPTED and MIC-ONLY. The same processing is also employed in representation of certain specifically identified PEM encapsulated header field quantities as cited in Section 4.6. 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).
この印刷可能なコード化ステップはPEMメッセージタイプのENCRYPTEDとミックだけに適切です。 また、同じ処理は確信することの明確に特定されたPEMがセクション4.6で引用されるようにヘッダーフィールド量を要約したのを表現で使われます。 左から右まで続いて、必ずはありませんが、ステップ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.) The character "=" signifies a special processing function used for padding within the printable encoding procedure.
6ビットが印刷可能なキャラクタ単位で表されるのを可能にして、国際Alphabet IA5の64文字サブセットが使用されています。 (キャラクタの提案された部分集合は同様にIA5とASCIIで表されます。) キャラクタ「=」は印刷可能なコード化手順の中でそっと歩くのに使用される特別な処理機能を意味します。
To represent the encapsulated text of a PEM message, 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.) This folding requirement does not apply when the encoding procedure is used to represent PEM header field quantities; Section 4.6 discusses folding of PEM encapsulated header fields.
PEMメッセージの要約のテキストを表すために、コード化機能の出力はテキスト線に区切られます(地方のコンベンションを使用して)、最終以外の各線がまさに印刷可能な64文字を含んでいて、最終的な線が64か、より少ない印刷可能なキャラクタを含んでいて。 (この行長は、容易に印刷可能であり、SMTPの1000キャラクタの伝えられた行長限界を満たすために保証されます。) コード化手順がPEMヘッダーフィールド量を表すのに用いられるとき、この折りたたみの要件は適用されません。 4.6が折り重ねるのを議論するPEMのセクションはヘッダーフィールドを要約しました。
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 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 1, are selected so as to be universally representable, and the set excludes characters with particular significance to SMTP (e.g., ".", "<CR>", "<LF>").
4の出力ストリングがキャラクタをコード化したので、コード化の過程は入力ビットの24ビットのグループを代表します。 ステップ3の出力から抜粋された24ビットの入力グループの向こう側に左から右まで続いて、それぞれの6ビットのグループはインデックスとして64の印刷可能なキャラクタのアレイに使用されます。 インデックスによって参照をつけられるキャラクタは出力ストリングに置かれます。 「Table1で特定されたこれらのキャラクタが一般に「表-可能」になるように選ばれて、セットが特定の意味でSMTPまでキャラクタを除く、(例えば」、」、「<CR>」、「<LF>」)
Linn [Page 13] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[13ページ]RFC1421プライバシー増進
Special processing is performed if fewer than 24 bits are available in an input group at the end of a message. A full encoding quantum is always completed at the end of a message. 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ビット未満がメッセージの終わりの入力グループで有効であるなら、特別な処理は実行されます。 完全なコード化量子はいつもメッセージの終わりに完成します。 24入力ビット未満が入力グループで有効であるときに、ゼロ・ビットは、整数の6ビットのグループを結成するために加えられます(右で)。 実際の入力データを表すのに必要でない出力欄はキャラクタ「=」に設定されます。 すべての正準なコード化された出力が整数の八重奏であるので、以下のケースしか起こることができません: (1) 入力をコード化する最終的な量子は24ビットの不可欠の倍数です。 (2) ここで、コード化された出力の最終的なユニットが「=」が全くそっと歩いていない4つのキャラクタの不可欠の倍数になる、入力をコード化する最終的な量子はちょうど8ビットです。 (3) ここで、コード化された出力の最終的なユニットは2人の「=」暫定記号によっていうことになられた2つのキャラクタになるだろうか、入力をコード化する最終的な量子はまさに16ビットです。 ここで、コード化された出力の最終的なユニットは1人の「=」暫定記号によっていうことになられた3つのキャラクタになるでしょう。
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
評価..18秒間..C..44秒間..パッド..33時間
Printable Encoding Characters
Table 1
印刷可能なコード化キャラクターは1を見送ります。
4.3.2.5 Summary of Transformations
4.3.2.5 変化の概要
In summary, the outbound message is subjected to the following composition of transformations (or, for some PEM message types, a subset thereof):
概要では、外国行きのメッセージは変化(または、何人かのPEMメッセージタイプのためのそれの部分集合)の以下の構成にかけられます:
Transmit_Form = Encode(Encrypt(Canonicalize(Local_Form)))
_フォーム=エンコードを伝えてください。(コード化します(Canonicalize(地方の_フォーム)))
Linn [Page 14] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[14ページ]RFC1421プライバシー増進
The inverse transformations are performed, in reverse order, to process inbound PEM messages:
逆さの変化は本国行きのPEMメッセージを処理するために逆順で実行されます:
Local_Form = DeCanonicalize(Decipher(Decode(Transmit_Form)))
地方の_フォーム=DeCanonicalize(暗号文の解読(解読してください(_書式を伝えてください)))
Note that the local form and the functions to transform messages to and from canonical form may vary between the originator and recipient systems without loss of information.
標準形と標準形からのメッセージを変える地方のフォームと機能が創始者と受取人システムの間で情報の損失なしで異なるかもしれないことに注意してください。
4.4 Encapsulation Mechanism
4.4 カプセル化メカニズム
The encapsulation techniques defined in RFC-934 [6] are adopted for encapsulation of PEM messages within separate enclosing MTS messages carrying associated MTS headers. This approach offers a number of advantages relative to a flat approach in which certain fields within a single header are encrypted and/or carry cryptographic control information. As far as the MTS is concerned, the entirety of a PEM message will reside in an MTS message's text portion, not the MTS message's header portion. 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.
RFC-934[6]で定義されたカプセル化技術は、メッセージが中に切り離すPEMのカプセル化のために関連MTSヘッダーを運ぶMTSメッセージを同封しながら、採用されます。 このアプローチは独身のヘッダーの中のある一定の分野がコード化されている、そして/または、暗号の制御情報を運ぶ平坦なアプローチに比例して多くの利点を示します。 MTSに関する限り、PEMメッセージの全体がMTSメッセージのヘッダー部分ではなく、MTSメッセージのテキスト部分にあるでしょう。 カプセル化は、ユーザからユーザへの意味でトランジットで変えられたものから、一般性を提供して、野原を隔離します。 暗号化/認証処理の間に挿入されたすべての野原が要約のヘッダーに置かれます。 これは入力ファイルか他のプログラムからヘッダーフィールドではなく、テキストだけを受け入れるメール取り扱いプログラムとの互換性を容易にします。
The encapsulation techniques defined in RFC-934 are consistent with existing Internet mail forwarding and bursting mechanisms. These techniques are designed so that they may be used in a nested manner. The encapsulation techniques may be used to encapsulate one or more PEM messages for forwarding to a third party, possibly in conjunction with interspersed (non-PEM) text which serves to annotate the PEM messages.
RFC-934で定義されたカプセル化技術はメカニズムを進めて、押し破く既存のインターネット・メールと、一致しています。これらのテクニックは、入れ子にされた方法でそれらを使用できるように設計されています。 カプセル化技術は推進への1つ以上のPEMメッセージを第三者に要約するのに使用されるかもしれません、ことによるとPEMメッセージを注釈するのに役立つ点在している(非PEMの)テキストに関連して。
Two encapsulation boundaries (EB's) are defined for delimiting encapsulated PEM messages and for distinguishing encapsulated PEM messages from interspersed (non-PEM) text. The pre-EB is the string "-----BEGIN PRIVACY-ENHANCED MESSAGE-----", indicating that an encapsulated PEM message follows. The post-EB is either (1) another pre-EB indicating that another encapsulated PEM message follows, or (2) the string "-----END PRIVACY-ENHANCED MESSAGE-----" indicating that any text that immediately follows is non-PEM text. A special point must be noted for the case of MIC-CLEAR messages, the text portions of which may contain lines which begin with the "-" character and which are therefore subject to special processing per RFC-934 forwarding procedures. When the string "- " must be prepended to such a line in the course of a forwarding operation in order to distinguish that line from an encapsulation boundary, MIC
2つのカプセル化境界(EBのもの)が、要約のPEMメッセージを区切って、点在している(非PEMの)テキストと要約のPEMメッセージを区別するために定義されます。 「プレEBはストリングです」-----プライバシーで高められたメッセージを始めてください。-----「要約のPEMメッセージが従うのを示します」 「EBを掲示するのは、(1) 別のものが要約したのを示す別のプレEB PEMメッセージがいうことになるどちらかか(2)はストリングです」-----プライバシーで高められたメッセージを終わらせてください。-----「すぐに従うどんなテキストも非PEMテキストであることを示します。」 特別なポイントはミック-CLEARメッセージ(それの部分が「-」キャラクタと共に始まっている、したがってRFC-934推進手順あたりの特別な処理を受けることがある線を含むかもしれないテキスト)に関するケースで有名でなければなりません。 MIC、それを区別するために推進操作の間のそのような線にストリング「-」をprependedしなければならなかったら、カプセル化境界から、立ち並んでください。
Linn [Page 15] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[15ページ]RFC1421プライバシー増進
computation is to be performed prior to prepending the "- " string. Figure 1 depicts the encapsulation of a single PEM message.
計算は「-」ストリングをprependingする前に実行されることです。 図1はただ一つのPEMメッセージのカプセル化について表現します。
This RFC places no a priori limits on the depth to which such encapsulation may be nested nor on the number of PEM messages which may be grouped in this fashion at a single nesting level for forwarding. A implementation compliant with this RFC must not preclude a user from submitting or receiving PEM messages which exploit this encapsulation capability. However, no specific requirements are levied upon implementations with regard to how this capability is made available to the user. Thus, for example, a compliant PEM implementation is not required to automatically detect and process encapsulated PEM messages.
このRFCはそのようなカプセル化が入れ子にされるかもしれない深さと、そして、推進のためにこんなやり方でただ一つの入れ子のレベルで分類されるかもしれないPEMメッセージの数に先験的な限界を全く置きません。 このRFCに伴う対応することの実現は、このカプセル化能力を開発するPEMメッセージを提出するか、または受け取るので、ユーザを排除してはいけません。 しかしながら、決められた一定の要求は全くどうこの能力をユーザにとって利用可能にするかに関して実現に徴収されません。 このようにして、そして、例えば、対応するPEM実現は、自動的に要約のPEMメッセージを検出して、処理するのに必要ではありません。
In using this encapsulation facility, it is important to note that it is inappropriate to forward directly to a third party a message that is ENCRYPTED because recipients of such a message would not have access to the DEK required to decrypt the message. Instead, the user forwarding the message must transform the ENCRYPTED message into a MIC-ONLY or MIC-CLEAR form prior to forwarding. Thus, in order to comply with this RFC, a PEM implementation must provide a facility to enable a user to perform this transformation, while preserving the MIC associated with the original message.
このカプセル化施設を使用するのにおいて、そのようなメッセージの受取人はメッセージを解読しなければならなかったDEKに近づく手段を持っていないでしょう、したがって、ENCRYPTEDであるメッセージを直接第三者に転送するのが不適当であることに注意するのが重要です。 代わりに、メッセージを転送するユーザは推進の前にENCRYPTEDメッセージをミックだけかミック-CLEARフォームに変えなければなりません。 したがって、このRFCに従って、PEM実現は、ユーザがこの変化を実行するのを可能にするためにオリジナルのメッセージに関連しているMICを保存している間、施設を提供しなければなりません。
If a user wishes PEM-provided confidentiality protection for transmitted information, such information must occur in the encapsulated text of an ENCRYPTED PEM message, not in the enclosing MTS header or PEM encapsulated header. If a user wishes to avoid
ユーザが、PEMによって提供された秘密性が伝達情報量のための保護であることを願うなら、そのような情報はENCRYPTED PEMメッセージの要約のテキストに現れなければならなくて、同封でないのでは、MTSヘッダーかPEMがヘッダーをカプセルに入れりました。 ユーザは避けたがっています。
Linn [Page 16] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[16ページ]RFC1421プライバシー増進
Encapsulated Message
要約のメッセージ
Pre-Encapsulation Boundary (Pre-EB)
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
プレカプセル化境界(プレEB)-----プライバシーで高められたメッセージを始めてください。-----
Encapsulated Header Portion
(Contains encryption control fields inserted in plaintext.
Examples include "DEK-Info:" and "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.)
要約のヘッダー部分(平文に挿入された暗号化制御フィールドを含んでいます。 例が含んでいる、「DEK-インフォメーション:」 そして、「主要なインフォメーション:」 . これらの制御フィールドにはRFC822ヘッダーフィールドと同様の線指向の表現がありますが、この文脈で有効な分野のセットがそれらからばらばらになることであるというメモがRFCで822処理を使用しました。)
Blank Line
(Separates Encapsulated Header from subsequent
Encapsulated Text Portion)
空白行(その後のEncapsulated Text PortionとEncapsulated Headerを切り離します)
Encapsulated Text Portion
(Contains message data encoded as specified in Section 4.3.)
要約のテキスト部分(セクション4.3で指定されるようにコード化されたメッセージデータを含んでいます。)
Post-Encapsulation Boundary (Post-EB)
-----END PRIVACY-ENHANCED MESSAGE-----
ポストカプセル化境界(ポスト-EB)-----プライバシーで高められたメッセージを終わらせてください。-----
Encapsulated Message Format
Figure 1
要約のメッセージ・フォーマット図1
disclosing the actual subject of a message to unintended parties, it is suggested that the enclosing MTS header contain a "Subject:" field indicating that "Encrypted Mail Follows".
メッセージの実際の対象を故意でないパーティーに明らかにして、同封のMTSヘッダーが「Subject:」を含むことが提案されます。 「暗号化メールは続く」表示をさばいてください。
If an integrity-protected representation of information which occurs within an enclosing header (not necessarily in the same format as that in which it occurs within that header) is desired, that data can be included within the encapsulated text portion in addition to its inclusion in the enclosing MTS header. For example, an originator wishing to provide recipients with a protected indication of a message's position in a series of messages could include within the encapsulated text a copy of a timestamp or message counter value possessing end-to-end significance and extracted from an enclosing MTS header field. (Note: mailbox specifiers as entered by end users incorporate local conventions and are subject to modification at intermediaries, so inclusion of such specifiers within encapsulated text should not be regarded as a suitable alternative to the authentication semantics defined in RFC 1422 and based on X.500 Distinguished Names.) The set of header information (if any) included within the encapsulated text of messages is a local matter, and this
同封の中に現れる情報の保全で保護された表現であるなら、ヘッダー(必ずそれがそのヘッダーの中に起こるそれと同じ形式でないのにおける)を望んでいて、要約のテキスト部分の中に同封のMTSヘッダーでの包含に加えてそのデータを含むことができます。 例えば、一連のメッセージにおける、メッセージの位置の保護されたしるしを受取人に提供したがっている創始者は、意味であって同封MTSから抽出された終わりから終わりへのヘッダーフィールドを持ちながら、要約のテキストの中でタイムスタンプかメッセージ対価のコピーを入れることができました。 (注意: エンドユーザによって入られるメールボックス特許説明書の作成書は地方のコンベンションを法人組織にして、仲介者で変更を受けることがあるので、要約のテキストの中のそのような特許説明書の作成書の包含をRFC1422で定義されて、X.500 Distinguished Namesに基づく認証意味論への適当な代替手段と見なすべきではありません。) メッセージの要約のテキストの中にヘッダー情報(もしあれば)を含むセットは、地域にかかわる事柄と、これです。
Linn [Page 17] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[17ページ]RFC1421プライバシー増進
RFC does not specify formatting conventions to distinguish replicated header fields from other encapsulated text.
RFCは、他の要約のテキストと模写されたヘッダーフィールドを区別するために形式コンベンションを指定しません。
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. Hybrid approaches are also possible, as in the case of IK-per-list protection of a message on its path from an originator to a PEM-equipped mailing list exploder, followed by IK- per-recipient protection from the exploder to individual list recipients.
メールがメーリングリストに記述されるとき、処理の2つの異なった方法が適切である場合があります: 1リストあたりのIK方法と1受取人あたりのIK方法。 また、ハイブリッド手法も可能です、創始者からPEMによって備えられている1受取人あたりの発破器から個々のリスト受取人までのIK保護があとに続いたメーリングリスト発破器までの経路におけるメッセージの1リストあたりのIK保護に関するケースのように。
If a message's originator is equipped to expand a 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 "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量が運び込んだことに注意してください、「主要なインフォメーション:」 いずれの一般に、はるかに大きいメッセージ・テキストのためにも、さばきません。 より多くのIKsが1受取人あたりのIK方法の下で処理にかかわりますが、個別に対状IKsを取り消すことができます、そして、1IKの所持はリストにおける別のユーザのうまくいっている仮面舞踏会を可能にしません。
If a message's originator 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. 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 originator to the list for authentication purposes.
メッセージの創始者がリスト名か別名にメッセージを記述するなら、実体(1リストあたりのIK)が構成している目的地への名前か別名の解決よりむしろ含意されるようにIKの使用はその名前か別名と交際しました。 したがって、そのようなIKは、メンバーを皆、記載するために利用可能でなければなりません。 残念ながら、それは、共有されたIKのために望ましくないレベルの露出を含意して、取消しは難しくなります。 そのうえ、1リストあたりのIK方法の使用で、リストのIKのどんな所有者も認証目的のためのリストに別の創始者のふりをすることができます。
Pure IK-per-list key management in the asymmetric case (with a common private key shared among multiple list members) is particularly disadvantageous in the asymmetric environment, as it fails to preserve the forwardable authentication and non-repudiation characteristics which are provided for other messages in this environment. Use of a hybrid approach with a PEM-capable exploder is therefore particularly recommended for protection of mailing list traffic when asymmetric key management is used; such an exploder would reduce (per discussion in Section 4.4 of this RFC) incoming ENCRYPTED messages to MIC-ONLY or MIC-CLEAR form before forwarding them (perhaps re-encrypted under individual, per-recipient keys) to list members.
非対称の場合(一般的な秘密鍵が複数のリストメンバーの中で共有されている)における純粋な1リストあたりのIKかぎ管理は非対称の環境で特に不利です、この環境における他のメッセージに提供される前進可能認証と非拒否の特性を保存しないとき。 したがって、非対称のかぎ管理が使用されているとき、PEMできる発破器に関するハイブリッド手法の使用はメーリングリスト交通の保護のために特に推薦されます。 そのような発破器が入って来るENCRYPTEDメッセージをミックだけに減らすだろうか(このRFCのセクション4.4における議論単位で)、またはメンバーを記載するために、それら(恐らく1受取人あたりの個人の下で再コード化されたキー)を進める前に、ミック-CLEARは形成します。
Linn [Page 18] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[18ページ]RFC1421プライバシー増進
4.6 Summary of Encapsulated Header Fields
4.6 要約のヘッダーフィールドの概要
This section defines 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. The following figures 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 ENCRYPTED message in which asymmetric key management is used.
分野は3つのグループで提示されます。 通常、グループは彼らが見せられるオーダーにおける要約のヘッダーに現れるでしょう、各グループのすべての野原がすべてのメッセージに現れるというわけではないでしょうが。 以下の数字は小さい例の要約のメッセージの外観を示しています。 図2は左右対称の暗号のかぎ管理の使用を仮定します。 図3は非対称のかぎ管理が使用されている例の要約のENCRYPTEDメッセージを例証します。
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,ENCRYPTED
Content-Domain: RFC822
DEK-Info: DES-CBC,F8143EDE5960C597
Originator-ID-Symmetric: linn@zendia.enet.dec.com,,
Recipient-ID-Symmetric: linn@zendia.enet.dec.com,ptf-kmc,3
Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,
B70665BB9BF7CBCDA60195DB94F727D3
Recipient-ID-Symmetric: pem-dev@tis.com,ptf-kmc,4
Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,
E2EF532C65CBCFF79F83A2658132DB47
-----プライバシーで高められたメッセージを始めてください。----- Proc-タイプ: 4、コード化された満足しているドメイン: RFC822 DEK-インフォメーション: DES-CBC、F8143EDE5960C597、創始者ID左右対称である、: linn@zendia.enet.dec.com 、受取人ID左右対称である、: linn@zendia.enet.dec.com 、ptf-kmc、3の主要なインフォメーション: デス-ECB、RSA-MD2、9FD3AAD2F2691B9A、B70665BB9BF7CBCDA60195DB94F727D3、受取人ID左右対称である、: pem-dev@tis.com 、ptf-kmc、4の主要なインフォメーション: デス-ECB、RSA-MD2,161A3F75DC82EF26、E2EF532C65CBCFF79F83A2658132DB47
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M 8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot dXd/H5LMDWnonNvPCwQUHt== -----END PRIVACY-ENHANCED MESSAGE-----
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M 8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot dXd/H5LMDWnonNvPCwQUHt=-----プライバシーで高められたメッセージを終わらせてください。-----
Example Encapsulated Message (Symmetric Case)
Figure 2
例の要約のメッセージ(左右対称のケース)図2
Figure 4 illustrates an example encapsulated MIC-ONLY message in which asymmetric key management is used; since no per-recipient keys are involved in preparation of asymmetric-case MIC-ONLY messages, this example should be processable for test purposes by arbitrary PEM implementations.
図4は非対称のかぎ管理が使用されている例の要約のミックだけメッセージを例証します。 1受取人あたりのキーが全く非対称のケースミックだけメッセージの準備にかかわらないので、この例はテスト目的のために任意のPEM実現で処理可能であるはずです。
Fully-qualified domain names (FQDNs) for hosts, appearing in the mailbox names found in entity identifier subfields of "Originator- ID-Symmetric:" and "Recipient-ID-Symmetric:" fields, are processed in a case-insensitive fashion. Unless specified to the contrary, other field arguments (including the user name components of mailbox names)
メールボックスが備え付けることのコネをエンティティ識別名部分体と命名するコネに見えるホストへの完全修飾ドメイン名(FQDNs)、「創始者ID左右対称:、」 そして、「受取人ID左右対称である、:、」 分野は処理コネです。大文字と小文字を区別しないファッション。 それと反対に、そして、別に指定されない場合、議論をさばいてください。(コンポーネントというメールボックス名のユーザ名を含んでいます)
Linn [Page 19] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[19ページ]RFC1421プライバシー増進
are to be 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 ranges "0"-"9" or upper case "A"-"F". Since public-key certificates and quantities encrypted
多くの場合、数値量は16進数字の隣接のストリングとしてヘッダーフィールドで表されます。(そこでは、各ケタがキャラクタによって範囲から表されます)。「0インチ--」 9インチか大文字「A」--「F。」 証明書と量がコード化した公開カギ以来
Linn [Page 20] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[20ページ]RFC1421プライバシー増進
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,ENCRYPTED
Content-Domain: RFC822
DEK-Info: DES-CBC,BFF968AA74691AC1
Originator-Certificate:
MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN
BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx
CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEU
MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i+
yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3F
LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+YPtcIq
iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/
5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w==
Key-Info: RSA,
I3rRIGXUGWAF8js5wCzRTkdhO34PTHdRZY9Tuvm03M+NM7fx6qc5udixps2Lng0+
wGrtiUm/ovtKdinz6ZQ/aQ==
Issuer-Certificate:
MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1UEBhMCVVMxIDAeBgNV
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL
BgNVBAsTBFRMQ0EwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc1OTU5WjBRMQsw
CQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN
BgNVBAsTBkJldGEgMTEPMA0GA1UECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw
XwJYCsnp6lQCxYykNlODwutF/jMJ3kL+3PjYyHOwk+/9rLg6X65B/LD4bJHtO5XW
cqAz/7R7XhjYCm0PcqbdzoACZtIlETrKrcJiDYoP+DkZ8k1gCk7hQHpbIwIDAQAB
MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMGOx
dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUWRBcXUpE+x
EREZd9++32ofGBIXaialnOgVUn0OzSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h
MIC-Info: RSA-MD5,RSA,
UdFJR8u/TIGhfH65ieewe2lOW4tooa3vZCvVNGBZirf/7nrgzWDABz8w9NsXSexv
AjRFbHoNPzBuxwmOAFeA0HJszL4yBvhG
Recipient-ID-Asymmetric:
MFExCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j
LjEPMA0GA1UECxMGQmV0YSAxMQ8wDQYDVQQLEwZOT1RBUlk=,
66
Key-Info: RSA,
O6BS1ww9CTyHPtS3bMLD+L0hejdvX6Qv1HK2ds2sQPEaXhX8EhvVphHYTjwekdWv
7x0Z3Jx2vTAhOYHMcqqCjA==
-----プライバシーで高められたメッセージを始めてください。----- Proc-タイプ: 4、コード化された満足しているドメイン: RFC822 DEK-インフォメーション: DES-CBC、BFF968AA74691AC1創始者証明書: MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEU; 主要なMBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i+yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3F LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+YPtcIq iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w=インフォメーション: 発行人RSA、I3rRIGXUGWAF8js5wCzRTkdhO34PTHdRZY9Tuvm03M+NM7fx6qc5udixps2Lng0+wGrtiUm/ovtKdinz6ZQ/aQ=証明書: MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1UEBhMCVVMxIDAeBgNV BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL BgNVBAsTBFRMQ0EwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc1OTU5WjBRMQsw CQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN BgNVBAsTBkJldGEgMTEPMA0GA1UECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw; XwJYCsnp6lQCxYykNlODwutF/jMJ3kL+3PjYyHOwk+/9rLg6X65B/LD4bJHtO5XW cqAz/7R7XhjYCm0PcqbdzoACZtIlETrKrcJiDYoP+DkZ8k1gCk7hQHpbIwIDAQAB MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMGOx dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUWRBcXUpE+x EREZd9++32ofGBIXaialnOgVUn0OzSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h MIC-インフォメーション: RSA-MD5、RSA、UdFJR8u/TIGhfH65ieewe2lOW4tooa3vZCvVNGBZirf/7nrgzWDABz8w9NsXSexv AjRFbHoNPzBuxwmOAFeA0HJszL4yBvhG、受取人ID非対称、: MFExCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j LjEPMA0GA1UECxMGQmV0YSAxMQ8wDQYDVQQLEwZOT1RBUlk=、66の主要なインフォメーション: RSA、O6BS1ww9CTyHPtS3bMLD+L0hejdvX6Qv1HK2ds2sQPEaXhX8EhvVphHYTjwekdWv 7x0Z3Jx2vTAhOYHMcqqCjA=
qeWlj/YJ2Uf5ng9yznPbtD0mYloSwIuV9FRYx+gzY+8iXd/NQrXHfi6/MhPfPF3d jIqCJAxvld2xgqQimUzoS1a4r7kQQ5c/Iua4LqKeq3ciFzEv/MbZhA== -----END PRIVACY-ENHANCED MESSAGE-----
qeWlj/YJ2Uf5ng9yznPbtD0mYloSwIuV9FRYx+gzY+8iXd/NQrXHfi6/MhPfPF3d jIqCJAxvld2xgqQimUzoS1a4r7kQQ5c/Iua4LqKeq3ciFzEv/MbZhA=-----プライバシーで高められたメッセージを終わらせてください。-----
Example Encapsulated ENCRYPTED Message (Asymmetric Case)
Figure 3
例の要約の暗号化メッセージ(非対称のケース)図3
Linn [Page 21] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[21ページ]RFC1421プライバシー増進
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 for this purpose.
使用の非対称のアルゴリズムはサイズで大きく、aの使用は効率的なコード化のテクニックが適切であるより多くのスペースのそのような量です、そして、1印刷された文字あたり6ビットを表して、この.4コード化メカニズム定義されたコネセクション4.3.2RFCがこのために採用されます。
Encapsulated headers of PEM messages are folded using whitespace per RFC 822 header folding conventions; no PEM-specific conventions are defined for encapsulated header folding. The example shown in Figure 4 shows (in its "MIC-Info:" field) an asymmetrically encrypted quantity in its printably encoded representation, illustrating the use of RFC 822 folding.
PEMメッセージの要約のヘッダーはRFC822のヘッダーの折りたたみのコンベンションあたりの空白を使用することで折り重ねられます。 どんなPEM特有のコンベンションも要約のヘッダーの折り重なりのために定義されません。 中、図4に示された例が目立っている、(「MIC-インフォメーション:」 分野) それはprintablyコード化された表現で非対称的にコード化された量です、RFC822の折り重なりの使用を例証して。
In contrast to the encapsulated header representations defined in RFC 1113 and its precursors, the field identifiers adopted in this RFC do not begin with the prefix "X-" (for example, the field previously denoted "X-Key-Info:" is now denoted "Key-Info:") and such prefixes are not to be emitted by implementations conformant to this RFC. To simplify transition and interoperability with earlier implementations, it is suggested that implementations based on this RFC accept incoming encapsulated header fields carrying the "X-" prefix and act on such fields as if the "X-" were not present.
RFC1113とその先駆で定義された要約のヘッダー表現と対照してこのRFCに採用された分野識別子が接頭語「X」で始まらない、(例えば、分野、以前指示されて、「Xはインフォメーションを合わせる」、現在指示される、「主要なインフォメーション:」、)、そのような接頭語は実現conformantによってこのRFCに放たれないことです。 以前の実現で変遷と相互運用性を簡素化するために、このRFCに基づく実現がまるで「X」が存在していないかのようにそのようなフィールドで「X」接頭語と行為を運びながら入って来る要約のヘッダーフィールドを受け入れることが提案されます。
Linn [Page 22] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[22ページ]RFC1421プライバシー増進
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-ONLY
Content-Domain: RFC822
Originator-Certificate:
MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN
BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx
CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEU
MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i+
yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3F
LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+YPtcIq
iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/
5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w==
Issuer-Certificate:
MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1UEBhMCVVMxIDAeBgNV
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL
BgNVBAsTBFRMQ0EwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc1OTU5WjBRMQsw
CQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN
BgNVBAsTBkJldGEgMTEPMA0GA1UECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw
XwJYCsnp6lQCxYykNlODwutF/jMJ3kL+3PjYyHOwk+/9rLg6X65B/LD4bJHtO5XW
cqAz/7R7XhjYCm0PcqbdzoACZtIlETrKrcJiDYoP+DkZ8k1gCk7hQHpbIwIDAQAB
MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMGOx
dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUWRBcXUpE+x
EREZd9++32ofGBIXaialnOgVUn0OzSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h
MIC-Info: RSA-MD5,RSA,
jV2OfH+nnXHU8bnL8kPAad/mSQlTDZlbVuxvZAOVRZ5q5+Ejl5bQvqNeqOUNQjr6
EtE7K2QDeVMCyXsdJlA8fA==
-----プライバシーで高められたメッセージを始めてください。----- Proc-タイプ: 4 ミックだけの満足しているDomain: RFC822創始者証明書: MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEU; 発行人MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i+yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3F LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+YPtcIq iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w=証明書: MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1UEBhMCVVMxIDAeBgNV BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL BgNVBAsTBFRMQ0EwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc1OTU5WjBRMQsw CQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN BgNVBAsTBkJldGEgMTEPMA0GA1UECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw; XwJYCsnp6lQCxYykNlODwutF/jMJ3kL+3PjYyHOwk+/9rLg6X65B/LD4bJHtO5XW cqAz/7R7XhjYCm0PcqbdzoACZtIlETrKrcJiDYoP+DkZ8k1gCk7hQHpbIwIDAQAB MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMGOx dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUWRBcXUpE+x EREZd9++32ofGBIXaialnOgVUn0OzSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h MIC-インフォメーション: RSA-MD5、RSA、jV2OfH+nnXHU8bnL8kPAad/mSQlTDZlbVuxvZAOVRZ5q5+Ejl5bQvqNeqOUNQjr6 EtE7K2QDeVMCyXsdJlA8fA=
LSBBIG1lc3NhZ2UgZm9yIHVzZSBpbiB0ZXN0aW5nLg0KLSBGb2xsb3dpbmcgaXMg YSBibGFuayBsaW5lOg0KDQpUaGlzIGlzIHRoZSBlbmQuDQo= -----END PRIVACY-ENHANCED MESSAGE-----
LSBBIG1lc3NhZ2UgZm9yIHVzZSBpbiB0ZXN0aW5nLg0KLSBGb2xsb3dpbmcgaXMg YSBibGFuayBsaW5lOg0KDQpUaGlzIGlzIHRoZSBlbmQuDQo=-----プライバシーで高められたメッセージを終わらせてください。-----
Example Encapsulated MIC-ONLY Message (Asymmetric Case)
Figure 4
例の要約のミックだけメッセージ(非対称のケース)図4
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 PEM message, generally preceding all other encapsulated header fields.
要約のヘッダーフィールドのこのグループはPEMメッセージの一度よりそれ以上起こらない分野を含みます、一般に、他のすべての要約のヘッダーフィールドに先行して。
4.6.1.1 Proc-Type Field
4.6.1.1 Proc-タイプ分野
The "Proc-Type:" encapsulated header field, required for all PEM messages, identifies the type of processing performed on the transmitted message. Only one "Proc-Type:" field occurs in a message; the "Proc-Type:" field must be the first encapsulated header
「Proc-タイプ:」 すべてのPEMメッセージに必要である要約のヘッダーフィールドは伝えられたメッセージに実行された処理のタイプを特定します。 1つは「以下をProcタイプするだけです」。 分野はメッセージに起こります。 「Proc-タイプ:」 分野は最初の要約のヘッダーであるに違いありません。
Linn [Page 23] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[23ページ]RFC1421プライバシー増進
field in the message.
メッセージでは、さばきます。
The "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 "4" to distinguish them from messages processed in accordance with prior PEM RFCs. The second subfield assumes one of a set of string values, defined in the following subsections.
「Proc-タイプ:」 分野には、コンマによって切り離された2つの部分体があります。 最初の部分体は変更をこの規格にするとき起こるかもしれない両立しない要約のヘッダーフィールド解釈の中で区別するのに使用される10進数です。 これに従って処理されて、RFCが部分体を運ぶというメッセージは「先のPEM RFCsによると、処理されたメッセージとそれらを区別する4インチ」を評価します。 2番目の部分体は以下の小区分で定義された1セットのストリング値の1つを仮定します。
4.6.1.1.1 ENCRYPTED
4.6.1.1.1 コード化されています。
The "ENCRYPTED" specifier signifies that confidentiality, authentication, integrity, and (given use of asymmetric key management) non-repudiation of origin security services have been applied to a PEM message's encapsulated text. ENCRYPTED messages require a "DEK-Info:" field and individual Recipient-ID and "Key- Info:" fields for all message recipients.
「コード化された」特許説明書の作成書は、起源セキュリティー・サービスの秘密性、認証、保全、および(非対称のかぎ管理の使用を与えます)非拒否がPEMメッセージの要約のテキストに適用されたのを意味します。 ENCRYPTEDメッセージがaを必要とする、「DEK-インフォメーション:」 分野と個々のRecipient-ID、「インフォメーションを合わせてください」 すべてのメッセージ受取人のための分野。
4.6.1.1.2 MIC-ONLY
4.6.1.1.2 ミックだけ
The "MIC-ONLY" specifier signifies that all of the security services specified for ENCRYPTED messages, with the exception of confidentiality, have been applied to a PEM message's encapsulated text. MIC-ONLY messages are encoded (per Section 4.3.2.4 of this RFC) to protect their encapsulated text against modifications at message transfer or relay points.
「ミックだけ」特許説明書の作成書は、秘密性を除いて、暗号化メッセージに指定されるセキュリティー・サービスのすべてがPEMメッセージの要約のテキストに適用されたのを意味します。 ミックだけメッセージがコード化される、(セクション4.3 .2 この.4RFC) それらの要約のテキストを保護するために、メッセージにおける変更は、ポイントを移すか、またはリレーします。
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, when a keyless MIC computation is employed for recipients for whom asymmetric cryptography is used, "Recipient-ID-Asymmetric:" and "Key-Info:" fields can be omitted. The "DEK-Info:" field can be omitted for all "MIC-ONLY" messages.
かぎ管理とMICアルゴリズムオプションのある組み合わせに関連して適用されると、ミックだけの仕様は、暗号化がないとき余計なある一定の分野が要約のヘッダーから省略されることを許可します。 鍵のないMIC計算が非対称の暗号が使用されている受取人に特に使われるとき「受取人ID非対称、:、」 そして、「主要なインフォメーション:」 分野を省略できます。 「DEK-インフォメーション:」 すべての「ミックだけ」メッセージのために分野を省略できます。
4.6.1.1.3 MIC-CLEAR
4.6.1.1.3 はっきりとミック
The "MIC-CLEAR" specifier represents a PEM message with the same security service selection as for a MIC-ONLY message. The set of encapsulated header fields required in a MIC-CLEAR message is the same as that required for a MIC-ONLY message.
「ミックCLEAR」特許説明書の作成書はミックだけメッセージのように同じセキュリティサービス選択でPEMメッセージを表します。 ミック-CLEARメッセージで必要である要約のヘッダーフィールドのセットはそれがミックだけメッセージに必要であるのと同じです。
MIC-CLEAR message processing omits the encoding step defined in Section 4.3.2.4 of this RFC to protect a message's encapsulated text against modifications within the MTS. As a result, a MIC-CLEAR
処理がコード化ステップを省略するというミック-CLEARメッセージは、MTSの中の変更に対してメッセージの要約のテキストを保護するためにセクション4.3.2でこの.4RFCを定義しました。 結果、ミック-CLEARとして
Linn [Page 24] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[24ページ]RFC1421プライバシー増進
message's text can be read by recipients lacking access to PEM software, even though such recipients cannot validate the message's signature. The canonical encoding discussed in Section 4.3.2.2 is performed, so interoperation among sites with different native character sets and line representations is not precluded so long as those native formats are unambiguously translatable to and from the canonical form. (Such interoperability is feasible only for those characters which are included in the canonical representation set.)
PEMソフトウェアへのアクセスを欠いている受取人はメッセージのテキストを読むことができます、そのような受取人がメッセージの署名を有効にすることができませんが。 正準なコード化はセクション4.3で.2について議論しました。.2はそれらのネイティブの形式が標準形と標準形から明白に翻訳できる限り、異なった固有の文字の組と線表現があるサイトの中のinteroperationが実行されているので排除されないということです。 (正準な表現セットに含まれているそれらのキャラクタだけに、そのような相互運用性は可能です。)
Omission of the printable encoding step implies that MIC-CLEAR message MICs will be validatable only in environments where the MTS does not modify messages in transit, or where the modifications performed can be determined and inverted before MIC validation processing. Failed MIC validation on a MIC-CLEAR message does not, therefore, necessarily signify a security-relevant event; as a result, it is recommended that PEM implementations reflect to their users (in a suitable local fashion) the type of PEM message being processed when reporting a MIC validation failure.
印刷可能なコード化ステップの省略が、ミック-CLEARメッセージMICsがMTSがトランジットにおけるメッセージを変更しないところで環境だけで有効に可能になるのを含意するか、MIC合法化処理の前に変更がどこで働いたか、決定して、逆にすることができます。 したがって、ミック-CLEARメッセージにおける失敗したMIC合法化は必ずセキュリティ関連している出来事を意味するというわけではありません。 その結果、PEM実現がMIC合法化の故障を報告するとき処理されるPEMメッセージの(適当なローカルのファッションによる)タイプを彼らのユーザに反映するのは、お勧めです。
A case of particular relevance arises for inbound SMTP processing on systems which delimit text lines with local native representations other than the SMTP-conventional <CR><LF>. When mail is delivered to a UA on such a system and presented for PEM processing, the <CR><LF> has already been translated to local form. In order to validate a MIC-CLEAR message's MIC in this situation, the PEM module must recanonicalize the incoming message in order to determine the inter- SMTP representation of the canonically encoded message (as defined in Section 4.3.2.2 of this RFC), and must compute the reference MIC based on that representation.
特定の関連性に関するケースは本国行きのSMTP処理のためにSMTP従来の<CR><LF>以外のローカルの固有の表現でテキスト線を区切るシステムの上に起こります。 メールがそのようなシステムの上でUAに配達されて、PEM処理のために提示されるとき、<CR><LF>は既に地方のフォームに翻訳されました。 この状況でミック-CLEARメッセージのMICを有効にするために、PEMモジュールは、正準の相互SMTP表現がメッセージをコード化したことを(セクション4.3.2でこの.2RFCを定義するので)決定するために入力メッセージをrecanonicalizeしなければならなくて、その表現に基づく参照MICを計算しなければなりません。
4.6.1.1.4 CRL
4.6.1.1.4 CRL
The "CRL" specifier indicates a special PEM message type, used to transfer one or more Certificate Revocation Lists. The format of PEM CRLs is defined in RFC 1422. No user data or encapsulated text accompanies an encapsulated header specifying the CRL message type; a correctly-formed CRL message's PEM header is immediately followed by its terminating message boundary line, with no blank line intervening.
"CRL"特許説明書の作成書は1つ以上の証明書失効リストを移すのに使用される特別なPEMメッセージタイプを示します。 PEM CRLsの書式はRFC1422で定義されます。 どんな利用者データも要約のテキストもCRLメッセージタイプを指定する要約のヘッダーに同伴しません。 空白行介入なしでメッセージ境界を終えるのがすぐに、正しく形成されたCRLメッセージのPEMヘッダーのあとに続きます。
Only three types of fields are valid in the encapsulated header comprising a CRL message. The "CRL:" field carries a printable representation of a CRL, encoded using the procedures defined in Section 4.3.2.4 of this RFC. "CRL:" fields may (as an option) be followed by no more than one "Originator-Certificate:" field and any number of "Issuer-Certificate:" fields. The "Originator-Certificate:" and "Issuer-Certificate:" fields refer to the most recently previous "CRL:" field, and provide certificates useful in validating the
3つのタイプの分野だけがCRLメッセージを含む要約のヘッダーで有効です。 「CRL:」 手順を用いることでCRLの印刷可能な表現を運んで、コード化された分野はセクション4.3.2でこの.4RFCを定義しました。 「CRL:」 分野はことであるかもしれません(オプションとして)「以下を創始者と同じくらい証明してください」という1つ未満があとに続いていて。 分野とどんな数、も「発行人証明書:」 分野。 「創始者証明書:」 そして、「以下を発行人で証明してください」 分野が最近前であることの状態で大部分参照する、「CRL:」 有効にすることで役に立つ証明書をさばいて、提供してください。
Linn [Page 25] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[25ページ]RFC1421プライバシー増進
signature included in the CRL. "Originator-Certificate:" and "Issuer-Certificate:" fields' contents are the same for CRL messages as they are for other PEM message types.
CRLに署名を含んでいます。 「以下を創始者と同じくらい証明してください」 そして、「以下を発行人で証明してください」 CRLメッセージに、分野の内容はそれらが他のPEMメッセージタイプのためのものであるのと同じです。
4.6.1.2 Content-Domain Field
4.6.1.2 満足しているドメイン分野
The "Content-Domain:" encapsulated header field describes the type of content which is represented within a PEM message's encapsulated text. It carries one string argument, whose value is defined as "RFC822" to indicate processing of RFC-822 mail as defined in this specification. It is anticipated that additional "Content-Domain:" values will be defined subsequently, in additional or successor documents to this specification. Only one "Content-Domain:" field occurs in a PEM message; this field is the PEM message's second encapsulated header field, immediately following the "Proc-Type:" field.
「満足しているドメイン:」 要約のヘッダーフィールドはPEMメッセージの要約のテキストの中に表される内容のタイプについて説明します。 それは値がこの仕様に基づき定義されるようにRFC-822メールの処理を示すために"RFC822"と定義される1つのストリング議論を運びます。 それが予期される、それ、追加、「満足しているドメイン:」 値は次に、追加するか後継者ドキュメントでこの仕様と定義されるでしょう。 1だけ、「満足しているドメイン:」 分野はPEMメッセージに起こります。 この分野がすぐに続いて、PEMメッセージが2番目にヘッダーフィールドを要約したということである、「Proc-タイプ:」 さばきます。
4.6.1.3 DEK-Info Field
4.6.1.3 DEK-インフォメーション分野
The "DEK-Info:" encapsulated header field identifies the message text encryption algorithm and mode, and also carries any cryptographic parameters (e.g., IVs) used for message encryption. No more than one "DEK-Info:" field occurs in a message; the field is required for all messages specified as "ENCRYPTED" in the "Proc-Type:" field.
「DEK-インフォメーション:」 要約のヘッダーフィールドは、メッセージ・テキスト暗号化アルゴリズムとモードを特定して、また、メッセージ暗号化に使用されるどんな暗号のパラメタ(例えば、IVs)も運びます。 1未満、「DEK-インフォメーション:」 分野はメッセージに起こります。 分野がメッセージが「コード化される」と指定したすべてに必要である、「Proc-タイプ:」 さばきます。
The "DEK-Info:" field carries either one argument or two arguments separated by a comma. The first argument identifies the algorithm and mode used for message text encryption. The second argument, if present, carries any cryptographic parameters required by the algorithm and mode identified in the first argument. Appropriate message encryption algorithms, modes and identifiers and corresponding cryptographic parameters and formats are defined in RFC 1423.
「DEK-インフォメーション:」 分野は議論か2つの議論がコンマで切り離したどちらかを運びます。 最初の議論はメッセージ・テキスト暗号化に使用されるアルゴリズムとモードを特定します。 存在しているなら、2番目の議論はアルゴリズムによって必要とされた暗号のパラメタと最初の議論で特定されたモードを運びます。 適切なメッセージ暗号化アルゴリズム、モード、識別子、対応する暗号のパラメタ、および書式はRFC1423で定義されます。
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.
要約のヘッダーフィールドのこのグループは1メッセージあたりの一度より通常、それ以上起こらない分野を含みます。 使われたかぎ管理オプションによって、これらの分野のいくつかがいくつかのメッセージから欠けているかもしれません。
4.6.2.1 Originator-ID Fields
4.6.2.1 創始者ID分野
Originator-ID encapsulated header fields identify a message's originator and provide the originator's IK identification component. Two varieties of Originator-ID fields are defined, the "Originator- ID-Asymmetric:" and "Originator-ID-Symmetric:" field. An "Originator-ID-Symmetric:" header field is required for all PEM
創始者IDの要約のヘッダーフィールドは、メッセージの創始者を特定して、創始者のIK識別の部品を提供します。 2つのバラエティーのOriginator-ID分野が定義される、「創始者ID非対称:、」 そして、「創始者ID左右対称である、:、」 さばきます。 「創始者ID左右対称である、:、」 ヘッダーフィールドがすべてのPEMに必要です。
Linn [Page 26] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[26ページ]RFC1421プライバシー増進
messages employing symmetric key management. The analogous "Originator-ID-Asymmetric:" field, for the asymmetric key management case, is used only when no corresponding "Originator-Certificate:" field is included.
対称鍵管理を使うメッセージ。 類似、「創始者ID非対称、:、」 非対称のかぎ管理ケースのために、分野は「以下を創始者と同じくらい証明してください」という対応しないときだけ、使用されて、ことです。 分野は含まれています。
Most commonly, only one Originator-ID or "Originator-Certificate:" field will occur within a message. For the symmetric case, the IK identification component carried in an "Originator-ID-Symmetric:" field applies to processing of all subsequent "Recipient-ID- Symmetric:" fields until another "Originator-ID-Symmetric:" field occurs. It is illegal for a "Recipient-ID-Symmetric:" field to occur before a corresponding "Originator-ID-Symmetric:" field has been provided. For the asymmetric case, processing of "Recipient-ID- Asymmetric:" fields is logically independent of preceding "Originator-ID-Asymmetric:" and "Originator-Certificate:" fields.
1だけOriginator-ID、「以下を創始者と同じくらい証明してください」 分野はメッセージの中に起こるでしょう。 左右対称のケースのために、IK識別の部品が運び込んだ、「創始者ID左右対称である、:、」 分野がその後の処理に適用される、「受取人ID左右対称:、」 別のものまでの分野、「創始者ID左右対称である、:、」 分野は起こります。 aに、それが不法である、「受取人ID左右対称である、:、」 対応の前に起こるようにさばく、「創始者ID左右対称である、:、」 野原を供給しました。 非対称のケース、処理、「受取人ID非対称:、」 分野が先行から論理的に独立している、「創始者ID非対称、:、」 そして、「以下を創始者と同じくらい証明してください」 分野。
Multiple Originator-ID and/or "Originator-Certificate:" fields may occur in a message when different originator-oriented IK components must be used by a message's originator in order to prepare a message so as to be suitable for processing by different recipients. In particular, multiple such fields will occur when both symmetric and asymmetric cryptography are applied to a single message in order to process the message for different recipients.
複数の創始者ID、「以下を創始者と同じくらい証明してください」 メッセージの創始者が異なった受取人による処理に適するようにメッセージを準備するのに異なった創始者指向のIKの部品を使用しなければならないとき、分野はメッセージに起こるかもしれません。 左右対称のものと同様に非対称の暗号が異なった受取人へのメッセージを処理するためにただ一つのメッセージに適用されるとき、特に、そのようなものがさばく倍数は起こるでしょう。
Originator-ID subfields are delimited by the comma character (","),
optionally followed by whitespace. Section 5.2, Interchange Keys,
discusses the semantics of these subfields and specifies the alphabet
from which they are chosen.
創始者ID部分体がコンマキャラクタによって区切られる、(「」、)、空白は任意にあとに続きます。 セクション5.2、Interchangeキーズは、これらの部分体の意味論について議論して、それらが選ばれているアルファベットを指定します。
4.6.2.1.1 Originator-ID-Asymmetric Field
4.6.2.1.1、創始者ID非対称、分野
The "Originator-ID-Asymmetric:" field contains an Issuing Authority subfield, and then a Version/Expiration subfield. This field is used only when the information it carries is not available from an included "Originator-Certificate:" field.
「創始者ID非対称、:、」 分野は、Issuing Authority部分体を含んでいて、次に、バージョン/満了部分体を含んでいます。 それが運ぶ情報が利用可能でない場合にだけこの分野が使用されている、「以下を創始者と同じくらい証明してください」含まれていて、 さばきます。
4.6.2.1.2 Originator-ID-Symmetric Field
4.6.2.1.2、創始者ID左右対称である、分野
The "Originator-ID-Symmetric:" field contains an Entity Identifier subfield, followed by an (optional) Issuing Authority subfield, and then an (optional) Version/Expiration subfield. Optional "Originator-ID-Symmetric:" subfields may be omitted only if rendered redundant by information carried in subsequent "Recipient-ID- Symmetric:" fields, and will normally be omitted in such cases.
「創始者ID左右対称である、:、」 (任意の)発行Authority部分体があとに続いたEntity Identifier部分体を含んでいて、次に、分野は(任意)のバージョン/満了部分体を含んでいます。 任意である、「創始者ID左右対称である、:、」 その後で運ばれた情報によって余分であることへレンダリングされる場合にだけ部分体が省略されるかもしれない、「受取人ID左右対称:、」 通常、そのようなものがケースに入れる省略されたコネであるためにさばいて、望んでください。
Linn [Page 27] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[27ページ]RFC1421プライバシー増進
4.6.2.2 Originator-Certificate Field
4.6.2.2 創始者証明書分野
The "Originator-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 an originator's certificate as a numeric quantity, comprised of the certificate's DER encoding, represented in the header field with the encoding mechanism defined in Section 4.3.2.4 of this RFC. The semantics of a certificate are discussed in RFC 1422.
「創始者証明書:」 非対称のかぎ管理がメッセージの受取人のより多くのひとりに使われるときだけ、要約のヘッダーフィールドは使用されています。 受取人(少なくとも一般的なディレクトリサーバの有用性の前の)で処理するのを容易にするために、すべてのメッセージでのこの分野の包含は強く推薦されます。 数値量としての証明書のDERコード化から成る創始者の証明書がコード化メカニズムでヘッダーフィールドで表した分野転送はセクション4.3.2でこの.4RFCを定義しました。 RFC1422で証明書の意味論について議論します。
4.6.2.3 MIC-Info Field
4.6.2.3 MIC-インフォメーション分野
The "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. The second argument identifies the algorithm under which the accompanying MIC is signed. The third argument represents a MIC signed with an originator's private key.
「MIC-インフォメーション:」 非対称のかぎ管理がメッセージの少なくとも1人の受取人に使われるときだけ使用される要約のヘッダーフィールドはコンマによって切り離された3つの議論を運びます。 最初の議論は付随のMICが計算されるアルゴリズムを特定します。 2番目の議論は付随のMICがサインされるアルゴリズムを特定します。 3番目の議論は創始者の秘密鍵を契約されたMICを表します。
For the case of ENCRYPTED PEM messages, the signed MIC is, in turn, symmetrically encrypted using the same DEK, algorithm, mode and cryptographic parameters as are used to encrypt the message's encapsulated text. This measure prevents unauthorized recipients from determining whether an intercepted message corresponds to a predetermined plaintext value.
ENCRYPTED PEMメッセージに関するケースのために、サインされたMICは同じDEKを使用することで順番に対称的にコード化されて、メッセージのものをコード化するのに使用されるアルゴリズム、モード、および暗号のパラメタはテキストを要約しました。 この測定によって、権限のない受取人は、妨害されたメッセージが予定された平文値に対応するかどうかと決心できません。
Appropriate MIC algorithms and identifiers, signature algorithms and identifiers, and signed MIC formats are defined in RFC 1423.
適切なMICアルゴリズム、識別子、署名アルゴリズム、識別子、およびサインされたMIC書式はRFC1423で定義されます。
A "MIC-Info:" field will occur after a sequence of fields beginning with a "Originator-ID-Asymmetric:" or "Originator-Certificate:" field and followed by any associated "Issuer-Certificate:" fields. A "MIC-Info:" field applies to all subsequent recipients for whom asymmetric key management is used, until and unless overridden by a subsequent "Originator-ID-Asymmetric:" or "Originator-Certificate:" and corresponding "MIC-Info:".
「MIC-インフォメーション:」 分野が系列の後に起こる、「創始者ID非対称、:、」 または、「以下を創始者と同じくらい証明してください」 分野、「以下を発行人で証明してください」関連づけられて、いずれもあとに続いていて、 分野。 「MIC-インフォメーション:」 分野が非対称のかぎ管理が使用されているすべてのその後の受取人に適用される、aその後によってくつがえされない、「創始者ID非対称、:、」 または、「以下を創始者と同じくらい証明してください」 対応、「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.
要約のヘッダーフィールドのこのグループは通常、起こる分野を含みます。発生の数がゼロ〜受取人の数の如何にかかわらずある非ゼロ値まで及んでいるメッセージの中の可変数の回。
Linn [Page 28] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[28ページ]RFC1421プライバシー増進
4.6.3.1 Issuer-Certificate Field
4.6.3.1 発行人証明書分野
The "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 "Issuer-Certificate:" field would contain the certificate containing the public component used to sign the certificate carried in the message's "Originator-Certificate:" field, for recipients' use in chaining through that certificate's certification path. Other "Issuer-Certificate:" fields, typically representing higher points in a certification path, also may be included by an originator. It is recommended that the "Issuer- Certificate:" fields be included in an order corresponding to successive points in a certification path leading from the originator to a common point shared with the message's recipients (i.e., the Internet Certification Authority (ICA), unless a lower Policy Certification Authority (PCA) or CA is common to all recipients.) More information on certification paths can be found in RFC 1422.
「発行人証明書:」 非対称のかぎ管理が少なくともメッセージの受取人のひとりに使用されるときだけ、要約のヘッダーフィールドは重要です。 A典型的である、「発行人証明書:」 分野は「以下を創始者と同じくらい証明してください」というメッセージのもので運ばれた証明書にサインするのに使用される公共のコンポーネントを含んでいて、証明書を含んでいるでしょう。 その証明書の証明経路を通して鎖を作ることにおける受取人の使用のために、さばきます。 もう一方は「以下を発行人で証明します」。 また、証明経路により高いポイントを通常表して、分野は創始者によって入れられるかもしれません。 その「発行人は以下を証明であること」がそれに推薦されます。 創始者から一般的なメッセージの受取人(すなわち、インターネット認証局(ICA)、aが下ろされないなら、すべての受取人にとって、Policy認証局(PCA)かカリフォルニアが一般的です。)と共有されたポイントまで含まれているコネが証明経路先導で連続したポイントに対応するオーダーであったなら、さばきます。 RFC1422で証明経路に関する詳しい情報を見つけることができます。
The certificate is represented in the same manner as defined for the "Originator-Certificate:" field (transporting an encoded representation of the certificate in X.509 [7] DER form), and any "Issuer-Certificate:" fields will ordinarily follow the "Originator- Certificate:" field directly. Use of the "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.509[7]DERフォームにおける、証明書のコード化された表現を輸送します)、いずれもさばいてください、「発行人証明書:」 通常、分野は「創始者は以下を証明すること」を尾行に望んでいます。 直接、さばきます。 使用、「発行人証明書:」 非対称のかぎ管理が採用してさえいるとき、分野は任意です、編入が受取人が発行人の証明書にアクセスできる交互のディレクトリサーバ施設がないとき強く推薦されますが。
4.6.4 Per-Recipient Encapsulated Header Fields
4.6.4 1受取人あたりの要約のヘッダーフィールド
The encapsulated header fields in this group appear for each of an "ENCRYPTED" message's named recipients. For "MIC-ONLY" and "MIC- CLEAR" messages, these fields are omitted for recipients for whom asymmetric key management is employed in conjunction with a keyless MIC algorithm but the fields appear for recipients for whom symmetric key management or a keyed MIC algorithm is employed.
このグループの分野がそれぞれ弁護に出廷する「コード化された」メッセージのものの要約のヘッダーは受取人を命名しました。 「ミックだけ」と「ミッククリアしてください」というメッセージに関しては、これらの分野は非対称のかぎ管理が鍵のないミックアルゴリズムに関連して使われる受取人のために省略されますが、分野は左右対称のかぎ管理か合わせられたミックアルゴリズムが採用している受取人の弁護に出廷します。
4.6.4.1 Recipient-ID Fields
4.6.4.1 受取人ID分野
A Recipient-ID encapsulated header field identifies a recipient and
provides the recipient's IK identification component. One
Recipient-ID field is included for each of a message's named
recipients. Section 5.2, Interchange Keys, discusses the semantics of
the subfields and specifies the alphabet from which they are chosen.
Recipient-ID subfields are delimited by the comma character (","),
optionally followed by whitespace.
Recipient-IDの要約のヘッダーフィールドは、受取人を特定して、受取人のIK識別の部品を提供します。 1つのRecipient-ID分野がメッセージの命名された受取人各人のために含まれています。 セクション5.2、Interchangeキーズは、部分体の意味論について議論して、それらが選ばれているアルファベットを指定します。 受取人ID部分体がコンマキャラクタによって区切られる、(「」、)、空白は任意にあとに続きます。
Linn [Page 29] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[29ページ]RFC1421プライバシー増進
For the symmetric case, all "Recipient-ID-Symmetric:" fields are interpreted in the context of the most recent preceding "Originator- ID-Symmetric:" field. It is illegal for a "Recipient-ID-Symmetric:" field to occur in a header before the occurrence of a corresponding "Originator-ID-Symmetric:" field. For the asymmetric case, "Recipient-ID-Asymmetric:" fields are logically independent of a message's "Originator-ID-Asymmetric:" and "Originator-Certificate:" fields. "Recipient-ID-Asymmetric:" fields, and their associated "Key-Info:" fields, are included following a header's originator- oriented fields.
左右対称のケースのためにすべて、「受取人ID左右対称である、:、」 分野が最新の先行の文脈で解釈される、「創始者ID左右対称:、」 さばきます。 aに、それが不法である、「受取人ID左右対称である、:、」 対応の発生の前にヘッダーに起こるようにさばく、「創始者ID左右対称である、:、」 さばきます。 非対称のケースのために「受取人ID非対称、:、」 分野がメッセージのものから論理的に独立している、「創始者ID非対称、:、」 そして、「以下を創始者と同じくらい証明してください」 分野。 「受取人ID非対称、:、」 分野、それら、関連、「主要なインフォメーション:」 分野は適応するヘッダーの創始者の含まれている次の分野です。
4.6.4.1.1 Recipient-ID-Asymmetric Field
4.6.4.1.1、受取人ID非対称、分野
The "Recipient-ID-Asymmetric:" field contains, in order, an Issuing Authority subfield and a Version/Expiration subfield.
「受取人ID非対称、:、」 分野はオーダーにIssuing Authority部分体とバージョン/満了部分体を含んでいます。
4.6.4.1.2 Recipient-ID-Symmetric Field
4.6.4.1.2、受取人ID左右対称である、分野
The "Recipient-ID-Symmetric:" field contains, in order, an Entity Identifier subfield, an (optional) Issuing Authority subfield, and an (optional) Version/Expiration subfield.
「受取人ID左右対称である、:、」 分野はオーダーにEntity Identifier部分体、(任意の)発行Authority部分体、および(任意)のバージョン/満了部分体を含んでいます。
4.6.4.2 Key-Info Field
4.6.4.2 主要なインフォメーション分野
One "Key-Info:" field is included for each of a message's named recipients. In addition, it is recommended that PEM implementations support (as a locally-selectable option) the ability to include a "Key-Info:" field corresponding to a PEM message's originator, following an Originator-ID or "Originator-Certificate:" field and before any associated Recipient-ID fields, but inclusion of such a field is not a requirement for conformance with this RFC.
1つ、「主要なインフォメーション:」 分野はメッセージの命名された受取人各人のために含まれています。 さらに、PEM実現がaを含む能力を支持するのが(局所的に選択可能なオプションとして)、お勧めである、「主要なインフォメーション:」 Originator-IDに続いて、PEMメッセージの創始者との文通をさばきなさいか、「以下を創始者と同じくらい証明してください」 分野とどんな関連Recipient-ID分野の前にも、そのような分野の唯一の包含はこのRFCとの順応のための要件ではありません。
Each "Key-Info:" field is interpreted in the context of the most recent preceding Originator-ID, "Originator-Certificate:", or Recipient-ID field; normally, a "Key-Info:" field will immediately follow its associated predecessor field. The "Key-Info:" field's argument(s) differ depending on whether symmetric or asymmetric key management is used for a particular recipient.
それぞれ、「主要なインフォメーション:」 分野は「以下を創始者と同じくらい証明してください」という最新の前のOriginator-IDの文脈かRecipient-ID分野で解釈されます。 通常a、「主要なインフォメーション:」 分野はすぐに、関連前任者野原に続くでしょう。 「主要なインフォメーション:」 左右対称の、または、非対称のかぎ管理が特定の受取人に使用されるかどうかによって、フィールドの議論は異なります。
4.6.4.2.1 Symmetric Key Management
4.6.4.2.1 対称鍵管理
When symmetric key management is employed for a given recipient, the "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 and MIC encryption for a particular recipient. The MIC Algorithm Indicator identifies the MIC computation algorithm used for a particular recipient. The DEK and
対称鍵管理が与えられた受取人に使われるとき「主要なインフォメーション:」 要約のヘッダーフィールドはコンマによって切り離された4個の商品を移します: IKはインディケータ、MICアルゴリズムインディケータ、DEK、およびMICを使用します。 IK Use Indicatorは特定の受取人のために、特定されたIKがDEKとMIC暗号化に使用されたアルゴリズムとモードを特定します。 MIC Algorithm Indicatorは特定の受取人に使用されるMIC計算アルゴリズムを特定します。 そしてDEK。
Linn [Page 30] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[30ページ]RFC1421プライバシー増進
MIC are symmetrically encrypted under the IK identified by a preceding "Recipient-ID-Symmetric:" field and/or prior "Originator- ID-Symmetric:" field.
MICが先行で特定されたIKの下で対称的にコード化される、「受取人ID左右対称である、:、」 分野、そして/または、先、「創始者ID左右対称:、」 さばきます。
Appropriate symmetric encryption algorithms, modes and identifiers, MIC computation algorithms and identifiers, and encrypted DEK and MIC formats are defined in RFC 1423.
適切な左右対称の暗号化アルゴリズム、モード、識別子、MIC計算アルゴリズム、識別子、コード化されたDEK、およびMIC書式はRFC1423で定義されます。
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 "Key-Info:" field transfers two quantities, separated by a comma. The first argument is an IK Use Indicator identifying the algorithm and mode in which the DEK is asymmetrically encrypted. The second argument is a DEK, asymmetrically encrypted under the recipient's public component.
非対称のかぎ管理が与えられた受取人に使われるとき「主要なインフォメーション:」 分野はコンマによって切り離された2つの量を移します。 最初の議論はDEKが非対称的にコード化されるアルゴリズムとモードを特定するIK Use Indicatorです。 2番目の議論は受取人の公共のコンポーネントの下で非対称的にコード化されたDEKです。
Appropriate asymmetric encryption algorithms and identifiers, and encrypted DEK formats are defined in RFC 1423.
適切な非対称の暗号化アルゴリズムと識別子の、そして、コード化されたDEK書式はRFC1423で定義されます。
5. Key Management
5. Key Management
Several cryptographic constructs are involved in supporting the PEM 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.
いくつかの暗号の構造物がPEMメッセージ現像処理を支持するのにかかわります。 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). In the asymmetric key management case, they are also used for encrypting signed MICs in ENCRYPTED PEM messages. 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)をチェックしてください。 また、非対称のかぎ管理場合では、それらは、ENCRYPTED PEMメッセージでサインされた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
主要な配送センター(KDCs)か終点システムは中心でDEK世代を実行できます。専用KDCシステムは、無作為のDEK世代には、より強いアルゴリズムを実行できるかもしれません。
Linn [Page 31] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[31ページ]RFC1421プライバシー増進
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 those of a message's originator and recipient. Moreover, decentralized DEK generation at endpoints reduces the frequency with which originators must make real-time queries of (potentially unique) servers in order to send mail, enhancing communications availability.
終点システムで支持できます。他方では、分散は、終点が比較的自給自足しているのを許容します、メッセージの創始者と受取人のもの以外のコンポーネントに置かなければならない信用のレベルを減少させて。 そのうえ、終点の分散DEK世代は創始者がメールを送るために(潜在的にユニーク)のサーバのリアルタイムの質問をしなければならない頻度を減少させます、コミュニケーションの有用性を高めて。
When symmetric key management 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 originators. 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-originator 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. 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 PEM 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 all recipients with the public component required to perform MIC validation.
置き換えKey(IK)の部品は、DEKsとMICsをコード化するのに使用されます。 一般に、IK粒状が複数のユーザを包括するリストを記述するために送られたメール以外の1ユーザあたりの対状レベルにあります。 従来の暗号を使用することで2人の校長がPEMの役に立つ交換に従事するように、最初に、彼らには一般的なIKの部品(対称鍵管理が使用されているとき)か補足的なIKの部品がなければなりません(非対称のかぎ管理が使用されているとき)。 左右対称の暗号が使用されているとき、IKはDEKsとMICsの両方をコード化するのに使用されるただ一つのコンポーネントから成ります。 非対称の暗号が使用されているとき、受取人の公共のコンポーネントはDEKs(対応する個人的なコンポーネントを持っている受取人だけによる変化invertible)をコード化するのにIKとして使用されます、そして、創始者の個人的なコンポーネントは、MICsをコード化するのに使用されます。(すべての受取人による変化invertible、創始者の証明書が提供されるので、公共のコンポーネントをもっているすべての受取人がMIC合法化を実行するのが必要です。
This RFC does not prescribe the means by which interchange keys are made available to appropriate parties; 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 [1422, is employed, the IA function is performed by a Certification Authority (CA).
このRFCは置き換えキーがパーティーを当てるために利用可能にされる手段を定めません。 そのような手段は、集結されるか(例えば、かぎ管理サーバで)、または分散されるかもしれません(ユーザの中の対状協定と例えば、直接販売で)。 どのような場合でも、どんな与えられたIKの部品も責任があるIssuing Authority(アイオワ)に関連しています。 いつ、証明書を拠点とする非対称の同じくらいかぎ管理の、そして、中で同じくらい議論されたRFC、[1422が採用している、アイオワの機能は認証局(カリフォルニア)によって実行されるか。
When an IA generates and distributes an IK component, associated control information is provided to direct how it is to be used. In
アイオワがIKの部品を発生して、分配するとき、それによってどう使用されていることになっているかを指示するために関連制御情報を提供します。 コネ
Linn [Page 32] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[32ページ]RFC1421プライバシー増進
order to select the appropriate IK(s) to use in message encryption, an originator 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(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 PEM message is transmitted, an indication of the IK components used for DEK and MIC encryption must be included. To this end, Originator-ID and Recipient-ID encapsulated header fields provide (some or all of) the following data:
PEMメッセージが送られるとき、DEKとMIC暗号化に使用されるIKの部品のしるしを含まなければなりません。 このためにOriginator-IDとRecipient-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. バージョン/満了部分体
In the asymmetric case, all necessary information associated with an originator can be acquired by processing the certificate carried in an "Originator-Certificate:" field; to avoid redundancy in this case, no "Originator-ID-Asymmetric:" field is included if a corresponding "Originator-Certificate:" appears.
非対称の場合では、証明書が運んだ処理で創始者に関連しているすべての必要事項を取得できる、「創始者証明書:」 分野。 この場合冗長を避けてください、いいえ、「創始者ID非対称、:、」 対応が「以下を創始者と同じくらい証明する」なら、分野は含まれています。 現れます。
The comma character (",") is used to delimit the subfields within an
Originator-ID or 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):
コンマキャラクタ、(「」、)、創始者IDか受取人アイダホ州の中で部分体を区切るために、使用されます。 アイオワ、EI、およびバージョン/満了部分体は制限された文字の組から発生します、以下のBNFによって処方されるように(RFC822、セクション2と3.3で定義されるように記法を使用して):
Linn [Page 33] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[33ページ]RFC1421プライバシー増進
IKsubfld := 1*ia-char
IKsubfld:=1*ia-炭
ia-char := DIGIT / ALPHA / "'" / "+" / "(" / ")" /
"." / "/" / "=" / "?" / "-" / "@" /
"%" / "!" / '"' / "_" / "<" / ">"
ia-炭:=DIGIT/アルファー/「'「/「+」/「(「/」)」/」'。」 / "/" / "=" / "?" / "-" / "@" / "%" / "!" /'「'/"_"/"<"/">"'」
An example Recipient-ID field for the symmetric case is as follows:
左右対称のケースのための例のRecipient-ID分野は以下の通りです:
Recipient-ID-Symmetric: linn@zendia.enet.dec.com,ptf-kmc,2
受取人ID左右対称である、: linn@zendia.enet.dec.com 、ptf-kmc、2
This example field indicates that IA "ptf-kmc" has issued an IK component for use on messages sent to "linn@zendia.enet.dec.com", and that the IA has provided the number 2 as a version indicator for that IK component.
この例の分野は、アイオワ"ptf-kmc"が" linn@zendia.enet.dec.com "に送られたメッセージにおける使用のためにIKの部品を発行して、アイオワがそのIKの部品のためのバージョンインディケータとしてNo.2を提供したのを示します。
An example Recipient-ID field for the asymmetric case is as follows:
非対称のケースのための例のRecipient-ID分野は以下の通りです:
Recipient-ID-Asymmetric:
MFExCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j
LjEPMA0GA1UECxMGQmV0YSAxMQ8wDQYDVQQLEwZOT1RBUlk=,66
受取人ID非対称、: MFExCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j LjEPMA0GA1UECxMGQmV0YSAxMQ8wDQYDVQQLEwZOT1RBUlk=、66
This example field includes the printably encoded BER representation of a certificate's issuer distinguished name, along with the certificate serial number 66 as assigned by that issuer.
この例の分野は証明書の発行人分類名のprintablyコード化されたBER表現を含んでいます、その発行人による割り当てられるとしての証明書通し番号66と共に。
5.2.1 Subfield Definitions
5.2.1 部分体定義
The following subsections define the subfields of Originator-ID and Recipient-ID fields.
以下の小区分はOriginator-IDとRecipient-ID分野の部分体を定義します。
5.2.1.1 Entity Identifier Subfield
5.2.1.1 エンティティ識別名部分体
An entity identifier (used only for "Originator-ID-Symmetric:" and "Recipient-ID-Symmetric:" fields) is constructed as an IKsubfld. More restrictively, an entity identifier subfield assumes the following form:
エンティティ識別名、(中古である、唯一、「創始者ID左右対称である、:、」、「受取人ID左右対称である、: 」 分野) 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 name as presented to the Internet be employed.
普遍的な相互運用性を支持するために、命名情報のための普遍的なフォームを仮定するのが必要です。 トランスミッションの前にローカル・ホスト名をより広いインターネットに変えるインストールに関するケースにおいて、インターネットに提示されるホスト名が使われることが強く勧められます。
Linn [Page 34] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[34ページ]RFC1421プライバシー増進
5.2.1.2 Issuing Authority Subfield
5.2.1.2 発行機関部分体
An IA identifier subfield is constructed as an IKsubfld. This RFC does not define this subfield's contents for the symmetric key management case. Any prospective IAs which are to issue symmetric keys for use in conjunction with this RFC must coordinate assignment of IA identifiers in a manner (centralized or hierarchic) which assures uniqueness.
アイオワ識別子部分体はIKsubfldとして構成されます。 このRFCは対称鍵管理ケースのためにこの部分体のコンテンツを定義しません。 このRFCに関連して使用のための対称鍵を支給することになっているどんな将来のIAsもユニークさを保証する方法(集結されたか階層的な)における、アイオワ識別子の課題を調整しなければなりません。
For the asymmetric key management case, the IA identifier subfield
will be formed from the ASN.1 BER representation of the distinguished
name of the issuing organization or organizational unit. The
distinguished encoding rules specified in Clause 8.7 of
Recommendation X.509 ("X.509 DER") are to be employed in generating
this representation. The encoded binary result will be represented
for inclusion in a transmitted header using the procedure defined in
Section 4.3.2.4 of this RFC.
非対称のかぎ管理ケースにおいて、アイオワ識別子部分体は発行組織か組織的なユニットの分類名のASN.1BER表現から形成されるでしょう。 Recommendation X.509("X.509 DER")のClause8.7で指定された顕著な符号化規則はこの表現を発生させる際に使われることです。 手順を用いている伝えられたヘッダーでの包含がセクション4.3.2でこの.4RFCを定義したので、コード化された2進の結果は表されるでしょう。
5.2.1.3 Version/Expiration Subfield
5.2.1.3 バージョン/満了部分体
A version/expiration subfield is constructed as an IKsubfld. For the symmetric key management case, the version/expiration subfield format is permitted to 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の部品に定められるのをさらに、許容します。
For the asymmetric key management case, the version/expiration subfield's value is the hexadecimal serial number of the certificate being used in conjunction with the originator or recipient specified in the "Originator-ID-Asymmetric:" or "Recipient-ID-Asymmetric:" field in which the subfield occurs.
バージョン/満了部分体の値が非対称のかぎ管理ケースのための、創始者か受取人に関連して中古の存在が指定した証明書の16進通し番号である、「創始者ID非対称、:、」 または、「受取人ID非対称、:、」 部分体が起こる分野。
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
IKコンポーネントのcryptoperiodはかぎ管理オーバーヘッドと取消しの反応性の間の見返りで一部書き取られます。 これとしてそのIKの部品を使用することでコード化されたメッセージの領収書が永久に非解読可能にメッセージを伝える前に永久にIKの部品を削除するのは望ましくないでしょう。 例えば、満期のIKの部品へのアクセスが、ユーザ(または、システム)によって受け取られた時間の長期間の間不活発であったメールを処理するのに必要でしょう。 非常に古いIKの部品が削除されるのを可能にするために、コード化された地方の長期格納を望んでいるメッセージの受取人は可能にするべきです。
Linn [Page 35] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[35ページ]RFC1421プライバシー増進
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の部品のアイオワの維持に依存するより局所的に維持されたIKの下の再暗号化でむしろ使用されるDEKを変えてください。
6. User Naming
6. ユーザ命名
Unique naming of electronic mail users, as is needed in order to
select corresponding keys correctly, is an important topic and one
which has received (and continues to receive) significant study. For
the symmetric case, IK components are identified in PEM headers
through use of mailbox specifiers in traditional Internet-wide form
("user@domain-qualified-host"). Successful operation in this mode
relies on users (or their PEM implementations) being able to
determine the universal-form names corresponding to PEM originators
and recipients. If a PEM implementation operates in an environment
where addresses in a local form differing from the universal form are
used, translations must be performed in order to map between the
universal form and that local representation.
正しく対応するキーを選択するのに必要である電子メールユーザのユニークな命名は、重要な話題と重要な研究を受け取った(そして、受信し続けています)ものです。 左右対称のケースにおいて、IKの部品はPEMヘッダーで伝統的なインターネット全体のフォーム(" user@domain-qualified-host ")におけるメールボックス特許説明書の作成書の使用で特定されます。 このモードにおけるうまくいっている操作は、PEM創始者と受取人にとって、対応する普遍的なフォーム名を決定できて、ユーザ(または、彼らのPEM実現)に頼ります。 PEM実現が普遍的なフォームと異なっている地方のフォームでのアドレスが使用されている環境で作動するなら、普遍的なフォームとそんなに地方の間で表現を写像するために翻訳を実行しなければなりません。
The use of user identifiers unrelated to the hosts on which the users' mailboxes reside offers generality and value. X.500 distinguished names, as employed in the certificates of the recommended key management infrastructure defined in RFC 1422, provide a basis for such user identification. As directory services become more pervasive, they will offer originators a means to search for desired recipients which is based on a broader set of attributes than mailbox specifiers alone. Future work is anticipated in integration with directory services, particularly the mechanisms and naming schema of the Internet OSI directory pilot activity.
ユーザのメールボックスが住んでいるホストにとって、関係ないユーザ識別子の使用は一般性と値を提供します。 RFC1422で定義されたお勧めのかぎ管理インフラストラクチャの証明書で使われるX.500分類名はそのようなユーザ登録名の基礎を提供します。 電話番号案内が、より普及するようになるとき、それらは必要な受取人の捜索への単独でメールボックス特許説明書の作成書より広いセットの属性に基づいている手段を創始者に提供するでしょう。 今後の活動は特にインターネットOSIディレクトリパイロット活動の電話番号案内、メカニズム、および命名図式で統合で予期されます。
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 hypothetical prototype implementation. This implementation is a standalone program which is 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.
このRFCで文脈と議論したメカニズムとアプローチを置くために、このセクションは仮定している原型実現の概観を提示します。 この実現はユーザによって呼び出されて、既存の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, which in turn generates output suitable for transmission via the UA. When a user receives a PEM message, the UA
ユーザがプライバシー増進を送信されるメッセージに適用したがっているとき、ユーザは、メッセージのテキストを準備して、スタンドアロンプログラムを呼び出します。(順番に、それは、UAを通してトランスミッションに適した出力を発生させます)。 ユーザがPEMメッセージ、UAを受け取るとき
Linn [Page 36] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[36ページ]RFC1421プライバシー増進
delivers the message in encrypted form, suitable for decryption and associated processing by the standalone program.
スタンドアロンプログラムで復号化と関連処理に適したコード化されたフォームでメッセージを送ります。
In this prototype implementation, a cache of IK components is maintained in a local file, with entries managed manually based on information provided by originators and recipients. For the asymmetric key management case, certificates are acquired for a user's PEM correspondents; in advance and/or in addition to retrieval of certificates from directories, they can be extracted from the "Originator-Certificate:" fields of received PEM messages.
この原型実現では、IKの部品のキャッシュはローカルファイルで維持されます、エントリーが創始者と受取人によって提供された情報に基づいた手動で管理にされるので。 非対称のかぎ管理ケースにおいて、ユーザのPEM通信員のために証明書を入手します。 あらかじめであることディレクトリからの証明書の検索に加えてそれらを抽出できる、「創始者証明書:」 受信されたPEMメッセージの分野。
The IK/certificate cache is, effectively, a simple database indexed by mailbox names. IK components are selected for transmitted messages based on the originator's identity and on recipient names, and corresponding Originator-ID, "Originator-Certificate:", and 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 cryptographic parameters (e.g., IVs) are generated dynamically within the program.
事実上、IK/証明書キャッシュはメールボックス名によって索引をつけられた簡単なデータベースです。 IKの部品は「以下を創始者と同じくらい証明してください」という受取人名、および創始者のアイデンティティに基づいた対応するOriginator-IDに関する伝えられたメッセージのために選択されます、そして、Recipient-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 "Originator-ID- Symmetric:" and "Recipient-ID-Symmetric:" fields.
オプションと送付先アドレスはコマンドライン議論でスタンドアロンプログラムに選択されます。 MTSによる使用において、プライバシーエンハンスプログラムに送付先アドレスを指定する機能は論理的に対応するアドレスを指定する機能からUAまで異なっています。 この分離がUAへの指定されるとしてのアドレスの地方のフォームが中で使用されるように多くの場合においてインターネットのグローバルなフォームと異なっているという事実から生じる、「創始者ID左右対称:、」 そして、「受取人ID左右対称である、:、」 分野。
8. Minimum Essential Requirements
8. 最小の必須の条件
This section summarizes particular capabilities which an implementation must provide for full conformance with this RFC.
このセクションは実現がこのRFCと共に完全な順応に提供しなければならない特定の能力をまとめます。
RFC 1422 specifies asymmetric, certificate-based key management procedures to support the message processing procedures defined in this document; PEM implementation support for these key management procedures is strongly encouraged. Implementations supporting these procedures must also be equipped to display the names of originator and recipient PEM users in the X.500 DN form as authenticated by the procedures of RFC 1422.
RFC1422は本書では定義されたメッセージ現像処理を支持するために非対称の、そして、証明書ベースのかぎ管理手順を指定します。 これらのかぎ管理手順のPEM実現サポートは強く奨励されます。 また、RFC1422の手順によって認証されるようにX.500 DNフォームに創始者と受取人PEMユーザの名前を表示するためにこれらの手順を支持する実現を備えなければなりません。
The message processing procedures defined here can also be used with symmetric key management techniques, though no RFCs analogous to RFC 1422 are currently available to provide correspondingly detailed description of suitable symmetric key management procedures. A complete PEM implementation must support at least one of these
また、対称鍵管理技術でここで定義されたメッセージ現像処理は使用できます、RFC1422への類似のどんなRFCsも現在、適当な対称鍵管理の対応する詳細な記述に手順を提供するために利用可能ではありませんが。 完全なPEM実現は少なくともこれらの1つを支持しなければなりません。
Linn [Page 37] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[37ページ]RFC1421プライバシー増進
asymmetric and/or symmetric key management modes.
非対称の、そして/または、左右対称のかぎ管理モード。
A full implementation of PEM is expected to be able to send and receive ENCRYPTED, MIC-ONLY, and MIC-CLEAR messages, and to receive CRL messages. Some level of support for generating and processing nested and annotated PEM messages (for forwarding purposes) is to be provided, and an implementation should be able to reduce ENCRYPTED messages to MIC-ONLY or MIC-CLEAR for forwarding. Fully-conformant implementations must be able to emit Certificate and Issuer- Certificate fields, and to include a Key-Info field corresponding to the originator, but users or configurers of PEM implementations may be allowed the option of deactivating those features.
PEMの完全な実施は、ENCRYPTED、ミックだけ、およびミック-CLEARメッセージを送って、受け取って、CRLメッセージを受け取ることができると予想されます。 入れ子にされて注釈されたPEMメッセージ(推進目的のための)を発生して、処理するための何らかのサポート水準が提供されることであり、実現は推進のためにミックだけかミック-CLEARにENCRYPTEDメッセージを減らすことができるべきです。 完全にconformantな実現は、CertificateとIssuer証明書分野を放って、創始者にとって、対応するKey-インフォメーション分野を含むことができなければなりませんが、それらの特徴を非活性化するオプションはPEM実現のユーザかconfigurersに許容されるかもしれません。
9. Descriptive Grammar
9. 記述文法
This section provides a grammar describing the construction of a PEM message.
このセクションはPEMメッセージの工事について説明する文法を提供します。
; PEM BNF representation, using RFC 822 notation.
; RFC822記法を使用するPEM BNF表現。
; imports field meta-syntax (field, field-name, field-body, ; field-body-contents) from RFC-822, sec. 3.2 ; imports DIGIT, ALPHA, CRLF, text from RFC-822 ; Note: algorithm and mode specifiers are officially defined ; in RFC 1423
; RFC-822、秒から分野メタ構文(分野、フィールド名、分野本体; ボディーコンテンツをさばく)を輸入します。 3.2 ; RFC-822からDIGIT、アルファー、CRLF、テキストを輸入します。 以下に注意してください。 アルゴリズムとモード特許説明書の作成書は公式に定義されます。 RFC1423で
<pemmsg> ::= <preeb>
<pemhdr>
[CRLF <pemtext>] ; absent for CRL message
<posteb>
<pemmsg>:、:= <preeb><pemhdr>[CRLF<pemtext>]。 CRLメッセージには、<posteb>を欠席してください。
<preeb> ::= "-----BEGIN PRIVACY-ENHANCED MESSAGE-----" CRLF <posteb> ::= "-----END PRIVACY-ENHANCED MESSAGE-----" CRLF / <preeb>
<preeb>:、:= "-----プライバシーで高められたメッセージを始めてください。-----「CRLF<posteb>:、:、」= "-----プライバシーで高められたメッセージを終わらせてください。-----「CRLF/<preeb>」
<pemtext> ::= <encbinbody> ; for ENCRYPTED or MIC-ONLY messages
/ *(<text> CRLF) ; for MIC-CLEAR
<pemtext>:、:= <encbinbody>。 ENCRYPTEDかミックだけメッセージ/*(<テキスト>CRLF)のために。 はっきりとミックのために
<pemhdr> ::= <normalhdr> / <crlhdr>
<pemhdr>:、:= <normalhdr>/<crlhdr>。
<normalhdr> ::= <proctype>
<normalhdr>:、:= <proctype>。
<contentdomain>
[<dekinfo>] ; needed if ENCRYPTED
(1*(<origflds> *<recipflds>)) ; symmetric case --
; recipflds included for all proc types
/ ((1*<origflds>) *(<recipflds>)) ; asymmetric case --
; recipflds included for ENCRYPTED proc type
<contentdomain>[<dekinfo>]。 ENCRYPTED(1*(<origflds>*<recipflds>))であるなら、必要です。 左右対称のケース--、。 recipfldsはすべてのprocのために、タイプ/((1*<origflds>)*(<recipflds>))を含んでいました。 非対称のケース--、。 ENCRYPTED procのために含まれていたrecipfldsはタイプされます。
Linn [Page 38] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[38ページ]RFC1421プライバシー増進
<crlhdr> ::= <proctype>
1*(<crl> [<cert>] *(<issuercert>))
<crlhdr>:、:= <proctype>1*(<crl>[<本命>]*(<issuercert>))
<asymmorig> ::= <origid-asymm> / <cert>
<asymmorig>:、:= <origid-asymm>/<本命>。
<origflds> ::= <asymmorig> [<keyinfo>] *(<issuercert>)
<micinfo> ; asymmetric
/ <origid-symm> [<keyinfo>] ; symmetric
<origflds>:、:= <asymmorig>[<keyinfo>]*(<issuercert>)<micinfo>。 非対称の/<origid-symm>[<keyinfo>]。 左右対称
<recipflds> ::= <recipid> <keyinfo>
<recipflds>:、:= <recipid><keyinfo>。
; definitions for PEM header fields
; PEMヘッダーフィールドのための定義
<proctype> ::= "Proc-Type" ":" "4" "," <pemtypes> CRLF
<contentdomain> ::= "Content-Domain" ":" <contentdescrip> CRLF
<dekinfo> ::= "DEK-Info" ":" <dekalgid> [ "," <dekparameters> ] CRLF
<symmid> ::= <IKsubfld> "," [<IKsubfld>] "," [<IKsubfld>]
<asymmid> ::= <IKsubfld> "," <IKsubfld>
<origid-asymm> ::= "Originator-ID-Asymmetric" ":" <asymmid> CRLF
<origid-symm> ::= "Originator-ID-Symmetric" ":" <symmid> CRLF
<recipid> ::= <recipid-asymm> / <recipid-symm>
<recipid-asymm> ::= "Recipient-ID-Asymmetric" ":" <asymmid> CRLF
<recipid-symm> ::= "Recipient-ID-Symmetric" ":" <symmid> CRLF
<cert> ::= "Originator-Certificate" ":" <encbin> CRLF
<issuercert> ::= "Issuer-Certificate" ":" <encbin> CRLF
<micinfo> ::= "MIC-Info" ":" <micalgid> "," <ikalgid> ","
<asymsignmic> CRLF
<keyinfo> ::= "Key-Info" ":" <ikalgid> "," <micalgid> ","
<symencdek> "," <symencmic> CRLF ; symmetric case
/ "Key-Info" ":" <ikalgid> "," <asymencdek>
CRLF ; asymmetric case
<crl> ::= "CRL" ":" <encbin> CRLF
<proctype>:、:= 「「Proc-タイプ」」:、」 「「4インチ」」、<pemtypes>CRLF<contentdomain>:、:= 「「満足しているドメイン」」:、」 <contentdescrip>CRLF<dekinfo>:、:= 「「DEK-インフォメーション」」:、」 <dekalgid>、[「」、<dekparameters>] CRLF<symmid>:、:= 」 「<IKsubfld>」、[<IKsubfld>]、」、」 [<IKsubfld>] <asymmid>:、:= 」 「<IKsubfld>」、<IKsubfld><origid-asymm>:、:= 「「創始者ID非対称、」、」、:、」 <asymmid>CRLF<origid-symm>:、:= 「「創始者ID左右対称である、」、」、:、」 <symmid>CRLF<recipid>:、:= <recipid-asymm>/<recipid-symm><recipid-asymm>:、:= 「「受取人ID非対称、」、」、:、」 <asymmid>CRLF<recipid-symm>:、:= 「「受取人ID左右対称である、」、」、:、」 <symmid>CRLF<本命>:、:= 「「創始者証明書」」:、」 <encbin>CRLF<issuercert>:、:= 「「発行人証明書」」:、」 <encbin>CRLF<micinfo>:、:= 「「MIC-インフォメーション」」:、」 」 「<micalgid>」、<ikalgid>、」、」 <asymsignmic>CRLF<keyinfo>:、:= 「「主要なインフォメーション」」:、」 」 「<ikalgid>」、<micalgid>、」、」 <symencdek>、」、」 <symencmic>CRLF。 「左右対称のケース/「主要なインフォメーション」」:、」 」 「<ikalgid>」、<asymencdek>CRLF。 非対称のケース<crl>:、:= 「"CRL"」:、」 <encbin>CRLF
<pemtypes> ::= "ENCRYPTED" / "MIC-ONLY" / "MIC-CLEAR" / "CRL"
<pemtypes>:、:= 「コード化」/「ミックだけ」/「はっきりとミック」/"CRL"
<encbinchar> ::= ALPHA / DIGIT / "+" / "/" / "="
<encbingrp> ::= 4*4<encbinchar>
<encbin> ::= 1*<encbingrp>
<encbinbody> ::= *(16*16<encbingrp> CRLF) [1*16<encbingrp> CRLF]
<IKsubfld> ::= 1*<ia-char>
; Note: "," removed from <ia-char> set so that Orig-ID and Recip-ID
; fields can be delimited with commas (not colons) like all other
; fields
<ia-char> ::= DIGIT / ALPHA / "'" / "+" / "(" / ")" /
"." / "/" / "=" / "?" / "-" / "@" /
"%" / "!" / '"' / "_" / "<" / ">"
<hexchar> ::= DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
; no lower case
<encbinchar>:、:= 「アルファ/ケタ/「+」/」/」 /「=」<encbingrp>:、:= 4*4<encbinchar><encbin>:、:= 1*<encbingrp><encbinbody>:、:= *(16*16<encbingrp>CRLF) [1*16<encbingrp>CRLF] <IKsubfld>:、:= 1*<ia-炭の>。 以下に注意してください。 「」 <iaから、そのように、その炭の>セットのOrig-IDとRecip-IDを取り外します。 すべて他であることのようにコンマ(コロンでない)で分野を区切ることができます。 分野<はiaに>を炭にします:、:= ケタ/アルファ/「'「/「+」/「(「/」)」/」'。」 / "/" / "=" / "?" / "-" / "@" / "%" / "!" /、'、「'/"_"/"<"/">"<hexchar>:、:、'、」= /「B」/ケタ/「C」/「D」/「E」/「F」。 小文字がありません。
Linn [Page 39] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[39ページ]RFC1421プライバシー増進
; This specification defines one value ("RFC822") for
; <contentdescrip>: other values may be defined in future in
; separate or successor documents
;
<contentdescrip> ::= "RFC822"
; この仕様が1つの値("RFC822")を定義する、。 <contentdescrip>: 他の値は中でこれから、定義されるかもしれません。 別々であるか後継者ドキュメント。 <contentdescrip>:、:= "RFC822"
; The following items are defined in RFC 1423 ; <dekalgid> ; <dekparameters> ; <micalgid> ; <ikalgid> ; <asymsignmic> ; <symencdek> ; <symencmic> ; <asymencdek>
; 以下の項目はRFC1423で定義されます。 <dekalgid>。 <dekparameters>。 <micalgid>。 <ikalgid>。 <asymsignmic>。 <symencdek>。 <symencmic>。 <asymencdek>。
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] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC 821, August 1982.
[2] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
[3] 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.
[3] この変化は、介入しているリレーに起こるのではなく、SMTP終点だけに起こるべきですが、SMTP分野を他の環境にリンクしながら、ゲートウェイシステムで行われるかもしれません。
[4] Use of a canonicalization procedure similar to that of SMTP
was selected because its functions are widely used and
implemented within the Internet mail community, not for
purposes of SMTP interoperability with this intermediate
result.
[4] 機能がインターネット・メール共同体の中で広く使用されて、この中間結果があるSMTP相互運用性の目的で実行されるのではなく、実行されるので、SMTPのものと同様のcanonicalization手順の使用は選択されました。
[5] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[5] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[6] Rose, M. T. and Stefferud, E. A., "Proposed Standard for
Message Encapsulation", RFC 934, January 1985.
[6] ローズとM.T.とStefferud、E.A.、「メッセージカプセル化の提案された標準」、RFC934、1985年1月。
[7] CCITT Recommendation X.509 (1988), "The Directory -
Authentication Framework".
[7] CCITT推薦X.509(1988)、「ディレクトリ--認証、フレームワーク、」
Linn [Page 40] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[40ページ]RFC1421プライバシー増進
[8] 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 publicly
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.
[8] このRFC中では、私たちは、それぞれ秘密にされて、非対称の暗号系で公的に利用可能にされる量について言及するために用語「個人的なコンポーネント」と「公共のコンポーネント」を採用しました。このコンベンションは、左右対称の暗号系で前の量かキーを参照するために「秘密鍵」という用語の使用から起こる可能な混乱を避けるために採用されます。
Patent Statement
特許声明
This version of Privacy Enhanced Mail (PEM) relies on the use of patented public key encryption technology for authentication and encryption. The Internet Standards Process as defined in RFC 1310 requires a written statement from the Patent holder that a license will be made available to applicants under reasonable terms and conditions prior to approving a specification as a Proposed, Draft or Internet Standard.
Privacy Enhancedメール(PEM)のこのバージョンは特許をとられた公開鍵暗号技術の認証と暗号化の使用に依存します。 RFC1310で定義されるインターネットStandards ProcessはPatent所有者からのProposed、DraftまたはインターネットStandardとして仕様を承認する前に無理のない条件と条件のもとでライセンスを応募者にとって利用可能にするという書かれた声明を必要とします。
The Massachusetts Institute of Technology and the Board of Trustees of the Leland Stanford Junior University have granted Public Key Partners (PKP) exclusive sub-licensing rights to the following patents issued in the United States, and all of their corresponding foreign patents:
リーランドスタンフォードジュニア大学のTrusteesのマサチューセッツ工科大学とBoardは合衆国で発行された以下の特許への権利、およびそれらの対応する外国特許のすべてをPublic Key Partners(PKP)の排他的なサブ認可に与えました:
Cryptographic Apparatus and Method
("Diffie-Hellman")............................... No. 4,200,770
暗号の装置とメソッド(「ディフィー-ヘルマン」)… No.4,200,770
Public Key Cryptographic Apparatus
and Method ("Hellman-Merkle").................... No. 4,218,582
公開鍵の暗号の装置とメソッド(「ヘルマン-Merkle」)… No.4,218,582
Cryptographic Communications System and
Method ("RSA")................................... No. 4,405,829
暗号の通信網とメソッド("RSA")… No.4,405,829
Exponential Cryptographic Apparatus
and Method ("Hellman-Pohlig").................... No. 4,424,414
指数の暗号の装置とメソッド(「ヘルマン-Pohlig」)… No.4,424,414
These patents are stated by PKP to cover all known methods of practicing the art of Public Key encryption, including the variations collectively known as El Gamal.
これらの特許はPublic Key暗号化の芸術を実施するすべての知られているメソッドをカバーするためにPKPによって述べられています、El Gamalとして一括して知られている変化を含んでいて。
Public Key Partners has provided written assurance to the Internet Society that parties will be able to obtain, under reasonable, nondiscriminatory terms, the right to use the technology covered by these patents. This assurance is documented in RFC 1170 titled "Public Key Standards and Licenses". A copy of the written assurance dated April 20, 1990, may be obtained from the Internet Assigned Number Authority (IANA).
公共のKey Partnersはパーティーが妥当なnondiscriminatory諸条件でこれらの特許でカバーされた技術を使用する権利を得ることができるというインターネット協会への書かれた保証を提供しました。 この保証は「公開鍵規格とライセンス」と題をつけられたRFC1170に記録されます。 ISOCの機関の一つで(IANA)から書かれた1990年4月20日付けの保証のコピーを入手するかもしれません。
Linn [Page 41] RFC 1421 Privacy Enhancement for Electronic Mail February 1993
電子メール1993年2月のためのリン[41ページ]RFC1421プライバシー増進
The Internet Society, Internet Architecture Board, Internet Engineering Steering Group and the Corporation for National Research Initiatives take no position on the validity or scope of the patents and patent applications, nor on the appropriateness of the terms of the assurance. The Internet Society and other groups mentioned above have not made any determination as to any other intellectual property rights which may apply to the practice of this standard. Any further consideration of these matters is the user's own responsibility.
インターネット協会、インターネット・アーキテクチャ委員会、インターネットEngineering Steering Group、およびNational Research Initiativesのための社は特許と特許出願の正当性か範囲の上と、そして、保証に関する諸条件の適切さの上の立場を全く取りません。 前記のようにインターネット協会と他のグループはこの規格の習慣に申請されるかもしれないいかなる他の知的所有権に関しても少しの決断もしていません。 これらの件のどんなさらなる考慮もユーザの自己の責任です。
Security Considerations
セキュリティ問題
This entire document is about security.
この全体のドキュメントはセキュリティに関するものです。
Author's Address
作者のアドレス
John Linn
ジョン・リン
EMail: 104-8456@mcimail.com
メール: 104-8456@mcimail.com
Linn [Page 42]
リン[42ページ]
一覧
スポンサーリンク
