RFC1847 日本語訳

Network Working Group                                          J. Galvin
Request For Comments: 1847                                     S. Murphy
Category: Standards Track                    Trusted Information Systems
                                                              S. Crocker
                                                         CyberCash, Inc.
                                                                N. Freed
                                            Innosoft International, Inc.
                                                            October 1995

コメントを求めるワーキンググループJ.ガルビン要求をネットワークでつないでください: 1847秒間マーフィーCategory: 標準化過程の信じられた情報システムS.医者サイバーキャッシュInc.N.はInc.1995年10月の国際のInnosoftを解放しました。

                     Security Multiparts for MIME:
                Multipart/Signed and Multipart/Encrypted

MIMEのためのセキュリティMultiparts: 署名していて複合の/が暗号化した複合/

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   This document defines a framework within which security services may
   be applied to MIME body parts.  MIME, an acronym for "Multipurpose
   Internet Mail Extensions", defines the format of the contents of
   Internet mail messages and provides for multi-part textual and non-
   textual message bodies.  The new content types are subtypes of
   multipart: signed and encrypted.  Each will contain two body parts:
   one for the protected data and one for the control information
   necessary to remove the protection.  The type and contents of the
   control information body parts are determined by the value of the
   protocol parameter of the enclosing multipart/signed or
   multipart/encrypted content type, which is required to be present.

このドキュメントはセキュリティー・サービスがMIME身体の部分に適用されるかもしれないフレームワークを定義します。 MIME(「マルチパーパスインターネットメールエクステンション」のための頭文字語)は、インターネットメール・メッセージのコンテンツの書式を定義して、複合原文の、そして、非原文のメッセージ本体に備えます。 新しいcontent typeは複合の血液型亜型です: 署名されて、暗号化されます。 それぞれが2つの身体の部分を含むでしょう: 保護されたデータのためのものと保護を取り除くのに必要な制御情報のためのもの。 複合/が署名した同封か必要である複合の、または、暗号化されたcontent typeのプロトコルパラメタの値で、制御情報身体の部分のタイプとコンテンツを存在させていると決心しています。

Table of Contents

目次

   1.  Introduction ..............................................    2
   2.  Definition of Security Subtypes of Multipart ..............    2
   2.1   Definition of Multipart/Signed ..........................    3
   2.2   Definition of Multipart/Encrypted .......................    6
   3.  Definition of Control Information Content Types ...........    9
   4.  Definition of Key Management Content Types ................    9
   5.  Security Considerations ...................................   10
   6.  Acknowledgements ..........................................   10
   7.  References ................................................   10
   8.  Authors' Addresses ........................................   11

1. 序論… 2 2. 複合のセキュリティ血液型亜型の定義… 2 2.1 複合か署名されることの定義… 3 2.2 複合か暗号化されることの定義… 6 3. コントロール情報量の定義… 9 4. Key Management content typeの定義… 9 5. セキュリティ問題… 10 6. 承認… 10 7. 参照… 10 8. 作者のアドレス… 11

Galvin, et al               Standards Track                     [Page 1]

RFC 1847                  Security Multiparts               October 1995

ガルビン、他Standards Track[1ページ]RFC1847Security Multiparts1995年10月

1.  Introduction

1. 序論

   An Internet electronic mail message consists of two parts: the
   headers and the body.  The headers form a collection of field/value
   pairs structured according to STD 11, RFC 822 [1], whilst the body,
   if structured, is defined according to MIME [2].  The basic MIME
   specification does not provide specific security protection.

インターネット電子メールメッセージは2つの部品から成ります: ヘッダーとボディー。 ヘッダーはSTD11によると、構造化された分野/値の組の収集を形成します、RFC822[1]、構造化されるなら、MIME[2]に従って、ボディーが定義されますが。 基本のMIME仕様は特定の機密保持を提供しません。

   This document defines a framework whereby security protection
   provided by other protocols may be used with MIME in a complementary
   fashion.  By itself, it does not specify security protection.  A MIME
   agent must include support for both the framework defined here and a
   mechanism to interact with a security protocol defined in a separate
   document.  The resulting combined service provides security for
   single-part and multi-part textual and non-textual messages.

このドキュメントは他のプロトコルによって提供された機密保持がMIMEと共に補足的なファッションで使用されるかもしれないフレームワークを定義します。 それ自体は機密保持を指定しません。 ここで定義されたフレームワークとメカニズムの両方が別々のドキュメントで定義されたセキュリティプロトコルと対話するように、MIMEエージェントはサポートを入れなければなりません。 結果として起こる結合したサービスはただ一つの部分と複合原文の、そして、非原文のメッセージにセキュリティを提供します。

   The framework is provided by defining two new security subtypes of
   the MIME multipart content type: signed and encrypted.  In each of
   the security subtypes, there are exactly two related body parts: one
   for the protected data and one for the control information.  The type
   and contents of the control information body parts are determined by
   the value of the protocol parameter of the enclosing multipart/signed
   or multipart/encrypted content type, which is required to be present.
   By registering new values for the required protocol parameter, the
   framework is easily extended to accommodate a variety of protocols.

MIMEの複合content typeの2の新しいセキュリティ血液型亜型を定義することによって、フレームワークを提供します: 署名されて、暗号化されます。 それぞれのセキュリティ血液型亜型には、2つの関連する身体の部分がまさにあります: 保護されたデータのためのものと制御情報のためのもの。 複合/が署名した同封か必要である複合の、または、暗号化されたcontent typeのプロトコルパラメタの値で、制御情報身体の部分のタイプとコンテンツを存在させていると決心しています。 必要なプロトコルパラメタのために新しい値を示すことによって、フレームワークはさまざまなプロトコルに対応するために容易に広げられます。

   A MIME agent that includes support for this framework will be able to
   recognize a security multipart body part and to identify its
   protected data and control information body parts.  If the value of
   the protocol parameter is unrecognized the MIME agent will not be
   able to process the security multipart.  However, a MIME agent may
   continue to process any other body parts that may be present.

このフレームワークのサポートを含んでいるMIMEエージェントは、セキュリティの複合身体の部分を認識して、保護されたデータと制御情報身体の部分を特定できるでしょう。 プロトコルパラメタの値が認識されていないなら、MIMEエージェントはセキュリティを処理できないでしょう。複合。 しかしながら、MIMEエージェントは、いかなる他の存在するかもしれない身体の部分も処理し続けるかもしれません。

2.  Definition of Security Subtypes of Multipart

2. 複合のセキュリティ血液型亜型の定義

   The multipart/signed content type specifies how to support
   authentication and integrity services via digital signature.  The
   control information is carried in the second of the two required body
   parts.

複合の、または、署名しているcontent typeは認証と保全がサービスであるとデジタル署名でサポートする方法を指定します。 制御情報は2つの必要な身体の部分の2番目で運ばれます。

   The multipart/encrypted content type specifies how to support
   confidentiality via encryption.  The control information is carried
   in the first of the two required body parts.

複合の、または、暗号化されたcontent typeは暗号化で秘密性をサポートする方法を指定します。 制御情報は2つの必要な身体の部分の1番目で運ばれます。

   A three-step process is described for the origination and reception
   of the multipart/signed and multipart/encrypted contents.  The
   details of the processing performed during each step is left to be
   specified by the security protocol being used.

3ステップのプロセスは複合か署名されるのと複合の、または、暗号化されたコンテンツの創作とレセプションのために説明されます。 使用されるセキュリティプロトコルによって各ステップの間に実行された処理の詳細が指定されるのが残されます。

Galvin, et al               Standards Track                     [Page 2]

RFC 1847                  Security Multiparts               October 1995

ガルビン、他Standards Track[2ページ]RFC1847Security Multiparts1995年10月

2.1.  Definition of Multipart/Signed

2.1. 複合か署名されることの定義

   (1)  MIME type name: multipart

(1) MIMEの種類名: 複合

   (2)  MIME subtype name: signed

(2) MIME「副-タイプ」は以下を命名します。 署名されます。

   (3)  Required parameters: boundary, protocol, and micalg

(3) 必要なパラメタ: 境界、プロトコル、およびmicalg

   (4)  Optional parameters: none

(4)の任意のパラメタ: なし

   (5)  Security considerations: Must be treated as opaque while in
        transit

(5) セキュリティ問題: トランジットにはある間、不透明なものとして扱わなければなりません。

   The multipart/signed content type contains exactly two body parts.
   The first body part is the body part over which the digital signature
   was created, including its MIME headers.  The second body part
   contains the control information necessary to verify the digital
   signature.  The first body part may contain any valid MIME content
   type, labeled accordingly.  The second body part is labeled according
   to the value of the protocol parameter.

複合の、または、署名しているcontent typeはちょうど2つの身体の部分を含んでいます。 最初の身体の部分はMIMEヘッダーを含んでいて、デジタル署名が作成された身体の部分です。 2番目の身体の部分はデジタル署名について確かめるのに必要な制御情報を含んでいます。 最初の身体の部分はそれに従って、ラベルされたどんな有効なMIME content typeも含むかもしれません。 プロトコルパラメタの値に従って、2番目の身体の部分はラベルされます。

   The attribute token for the protocol parameter is "protocol", i.e.,

すなわち、プロトコルパラメタのための属性トークンは「プロトコル」です。

    parameter := "protocol" "=" value

パラメタ:=「プロトコル」「=」価値

   The value token is comprised of the type and sub-type tokens of the
   Content-Type: header of the second body part, i.e.,

値のトークンはコンテントタイプのタイプとサブタイプトークンから成ります: すなわち、2番目の身体の部分のヘッダー

    value := <"> type "/" subtype <">

「値の:=<「>タイプ」/」「副-タイプ」<">"

   where the type and subtype tokens are defined by the MIME [2]
   specification.  The semantics of the protocol parameter are defined
   according to its value.

タイプと「副-タイプ」トークンがMIME[2]仕様で定義されるところ。 値に従って、プロトコルパラメタの意味論は定義されます。

   The attribute token for the micalg parameter is "micalg", i.e.,

すなわち、micalgパラメタのための属性トークンは"micalg"です。

    parameter := "micalg" "=" value

パラメタ:="micalg"「=」価値

   The Message Integrity Check (MIC) is the name given to the quantity
   computed over the body part with a message digest or hash function,
   in support of the digital signature service.  Valid value tokens are
   defined by the specification for the value of the protocol parameter.
   The value may be a comma (",") separated list of tokens, indicating
   the use of multiple MIC algorithms.  As a result, the comma (",")
   character is explicitly excluded from the list of characters that may
   be included in a token used as a value of the micalg parameter.  If
   multiple MIC algorithms are specified, the purpose and use of the
   multiple algorithms is defined by the protocol.  If the MIC algorithm

Message Integrity Check(MIC)はメッセージダイジェストかハッシュ関数に従った身体の部分の上計算された量に与えられた名前です、デジタル署名サービスを支持して。 有効値トークンはプロトコルパラメタの値のための仕様で定義されます。 切り離されて、トークンについて記載してください、複数のミックアルゴリズムの使用を示して。値がコンマであるかもしれない、(「」、)、aとして、なってください、コンマ、(「」、)、キャラクタはmicalgパラメタの値として使用されるトークンに含まれるかもしれないキャラクタのリストから明らかに除かれます。 複数のMICアルゴリズムが指定されるなら、複数のアルゴリズムの目的と使用はプロトコルによって定義されます。 MICアルゴリズムです。

Galvin, et al               Standards Track                     [Page 3]

RFC 1847                  Security Multiparts               October 1995

ガルビン、他Standards Track[3ページ]RFC1847Security Multiparts1995年10月

   is also specified in the control information and the value there does
   not agree with the value in this parameter, it must be treated as an
   error.

また、指定されたコネは制御情報です、そして、そこの値はこのパラメタの値に同意しません、そして、誤りとしてそれを扱わなければなりません。

    NOTE: The presence of the micalg parameter on the
    multipart/signed content type header is explicitly intended to
    support one-pass processing.  MIME implementations may locate
    the second body part by inputting the first body part and
    computing the specified MIC values until the boundary
    identifying the second body part is found.

以下に注意してください。 明らかに、複合の、または、署名しているcontent typeヘッダーに関するmicalgパラメタの存在が1パスの処理をサポートすることを意図します。 MIME実装は、2番目の身体の部分を特定する境界が見つけられるまで、最初の身体の部分を入力して、指定されたMIC値を計算することによって、2番目の身体の部分の場所を見つけるかもしれません。

   The entire contents of the multipart/signed container must be treated
   as opaque while it is in transit from an originator to a recipient.
   Intermediate message transfer agents must not alter the content of a
   multipart/signed in any way, including, but not limited to, changing
   the content transfer encoding of the body part or any of its
   encapsulated body parts.

それが創始者から受取人までのトランジット中である間、複合の、または、署名しているコンテナの全体のコンテンツを不透明なものとして扱わなければなりません。 中間的メッセージ転送エージェントはカプセル化された身体の部分の複合の、または、サインインしているどんな道、包含、他、身体の部分の満足している転送コード化を変えるか、またはどれかの内容も変更してはいけません。

   The signature in a multipart/signed only applies to the material that
   is actually within the multipart/signed object.  In particular, it
   does not apply to any enclosing message material, nor does it apply
   to entities that are referenced (e.g. via a MIME message/external-
   body) by rather than included in the signed content.

署名される複合/の署名は実際に複合の、または、署名しているオブジェクトの中にある材料に適用されるだけです。 特に、それがメッセージの材料を同封しながらいずれにも適用されないで、また署名している内容に含まれているよりむしろそれが参照をつけられる(例えば、MIMEメッセージ/外部のボディーを通して)実体に適用されません。

   When creating a multipart/signed body part, the following sequence of
   steps describes the processing necessary.  It must be emphasized that
   these steps are descriptive, not prescriptive, and in no way impose
   restrictions or requirements on implementations of this
   specification.

複合の、または、署名している身体の部分を作成するとき、ステップの以下の系列は必要な状態で処理について説明します。 これらのステップが規範的であるのではなく、描写的であり、この仕様の実装に制限か要件を決して課さないと強調しなければなりません。

   (1)  The content of the body part to be protected is prepared
        according to a local convention.  The content is then
        transformed into a MIME body part in canonical MIME format,
        including an appropriate set of MIME headers.

(1) 地方のコンベンションによると、保護されるべき身体の部分の内容は準備されます。 次に、内容は正準なMIME形式でMIME身体の部分に変えられます、適切なセットのMIMEヘッダーを含んでいて。

        In addition, if the multipart/signed object is EVER to be
        transferred over the standard Internet SMTP infrastructure, the
        resulting MIME body is constrained to 7 bits -- that is, the use
        of material requiring either 8bit or binary
        content-transfer-encoding is NOT allowed.  Such 8bit or binary
        material MUST be encoded using either the quoted-printable or
        base64 encodings.

さらに、結果として起こるMIME本体は複合の、または、署名しているオブジェクトが標準のインターネットSMTPインフラストラクチャの上に移されるべきEVERであるなら、7ビットに抑制されます--すなわち、8ビットか2進の満足している転送コード化のどちらかを必要とする材料の使用は許されていません。 引用されて印刷可能かbase64 encodingsのどちらかを使用して、そのような8ビットか2進の材料をコード化しなければなりません。

        This requirement exists because it is not generally possible,
        given the current characteristics of Internet SMTP, for a
        message originator to guarantee that a message will travel only
        along paths capable of carrying 8bit or binary material.

インターネットSMTPの現在の特性を考えて、それが一般に可能でないので、メッセージ創始者が、メッセージが8ビットか2進の材料を運ぶことができる経路だけに沿って移動するのを保証するように、この要件は存在しています。

Galvin, et al               Standards Track                     [Page 4]

RFC 1847                  Security Multiparts               October 1995

ガルビン、他Standards Track[4ページ]RFC1847Security Multiparts1995年10月

        SMTP clients normally have the option of either converting the
        message to eliminate the use of 8bit or binary encoding or
        returning a nondelivery notification to the originator.
        However, conversion is not viable in the case of signed objects
        since conversion would necessarily invalidate the signature.
        This leaves a nondelivery notification as the only available
        option, which is not acceptable.

SMTPクライアントには、通常、不着損害通知を創始者にコード化するか、または返す8のビットかバイナリーの使用を排除するメッセージを変換するオプションがあります。 変換は必ず署名を無効にするでしょう、しかしながら、したがって、変換が署名しているオブジェクトのケースで実行可能ではありません。 これは唯一の利用可能なオプションとして不着損害通知を残します。(それは、許容できません)。

   (2)  The body part (headers and content) to be digitally signed is
        prepared for signature according to the value of the protocol
        parameter.  The MIME headers of the signed body part are
        included in the signature to protect the integrity of the MIME
        labeling of the data that is signed.

(2) プロトコルパラメタの値に従って、デジタルに署名される身体の部分(ヘッダーと内容)は署名のために準備されます。 署名している身体の部分のMIMEヘッダーは、署名されるデータのMIMEラベリングの保全を保護するために署名に含まれています。

   (3)  The prepared body part is made available to the signature creation
        process according to a local convention.  The signature creation
        process must make available to a MIME implementation two data
        streams: the control information necessary to verify the
        signature, which the MIME implementation will place in the second
        body part and label according to the value of the protocol
        parameter, and the digitally signed body part, which the MIME
        implementation will use as the first body part.

(3) 準備された身体の部分を地方のコンベンションによると、署名作成プロセスに利用可能にします。 署名作成プロセスで、2つのデータストリームがMIME実装に利用可能にならなければなりません: プロトコルパラメタの値に応じてMIME実装が2番目の身体の部分とラベルに置く署名、およびMIME実装が最初の身体の部分として使用するデジタルに署名している身体の部分について確かめるのに必要な制御情報。

   When receiving a multipart/signed body part, the following sequence
   of steps describes the processing necessary to verify the signature
   or signatures.  It must be emphasized that these steps are
   descriptive, not prescriptive, and in no way impose restrictions or
   requirements on implementations of this specification.

複合の、または、署名している身体の部分を受け取るとき、ステップの以下の系列は署名か署名について確かめるのに必要な処理について説明します。 これらのステップが規範的であるのではなく、描写的であり、この仕様の実装に制限か要件を決して課さないと強調しなければなりません。

   (1)  The first body part and the control information in the second body
        part must be prepared for the signature verification process
        according to the value of the protocol parameter.

(1) プロトコルパラメタの値に従って、署名照合プロセスのために最初の身体の部分と2番目の身体の部分の制御情報を準備しなければなりません。

   (2)  The prepared body parts must be made available to the signature
        verification process according to a local convention.  The
        signature verification process must make available to the MIME
        implementation the result of the signature verification and the
        body part that was digitally signed.

(2) 準備された身体の部分を地方のコンベンションによると、署名照合プロセスに利用可能にしなければなりません。 署名照合プロセスで、署名照合の結果とデジタルに署名された身体の部分はMIME実装に利用可能にならなければなりません。

            NOTE: The result of the signature verification is likely to
            include a testament of the success or failure of the
            verification.  Also, in the usual case, the body part
            returned after signature verification will be the same as
            the body part that was received.  We do not insist that
            this be the case to allow for protocols that may modify the
            body part during the signature processing.

以下に注意してください。 署名照合の結果は検証の成否の遺書を含んでいそうです。 また、普通の場合では、署名照合が同じに受け取られた身体の部分になった後に身体の部分は戻りました。 私たちは、署名処理の間に身体の部分を変更するかもしれないプロトコルを考慮するためにこれがそうであると主張しません。

Galvin, et al               Standards Track                     [Page 5]

RFC 1847                  Security Multiparts               October 1995

ガルビン、他Standards Track[5ページ]RFC1847Security Multiparts1995年10月

   (3)  The result of the signature verification process is made available
        to the user and the MIME implementation continues processing with
        the verified body part, i.e., the body part returned by the
        signature verification process.

(3) 署名照合プロセスの結果をユーザにとって利用可能にします、そして、MIME実装は確かめられた身体の部分がある処理、すなわち、署名照合プロセスによって返された身体の部分を続けています。

   The following example is an illustration of a multipart/signed body
   part.  It is necessarily incomplete since the control information is
   defined by the security protocol, which must be specified in a
   separate document.

以下の例は複合の、または、署名している身体の部分のイラストです。 セキュリティプロトコル(別々のドキュメントで指定しなければならない)によって制御情報が定義されるので、それは必ず不完全です。

    Content-Type: multipart/signed; protocol="TYPE/STYPE";
            micalg="MICALG"; boundary="Signed Boundary"

コンテントタイプ: 複合か署名される。 =「タイプ/STYPE」について議定書の中で述べてください。 micalgは"MICALG"と等しいです。 「境界であると署名される」境界=

    --Signed Boundary
    Content-Type: text/plain; charset="us-ascii"

--署名している境界コンテントタイプ: テキスト/平野。 charsetが等しい、「私たち、-、ASCII、」

    This is some text to be signed although it could be
    any type of data, labeled accordingly, of course.

それがそれに従って、ラベルされたどんなタイプに関するデータであるかもしれませんが、これが署名される何らかのテキストである、もちろん。

    --Signed Boundary
    Content-Type: TYPE/STYPE

--署名している境界コンテントタイプ: タイプ/STYPE

    CONTROL INFORMATION for protocol "TYPE/STYPE" would be here

プロトコル「タイプ/STYPE」へのCONTROL情報がここにあるでしょう。

    --Signed Boundary--

--境界であると署名されます--

2.2.  Definition of Multipart/Encrypted

2.2. 複合か暗号化されることの定義

   (1)  MIME type name: multipart

(1) MIMEの種類名: 複合

   (2)  MIME subtype name: encrypted

(2) MIME「副-タイプ」は以下を命名します。 暗号化されます。

   (3)  Required parameters: boundary, protocol

(3) 必要なパラメタ: 境界、プロトコル

   (4)  Optional parameters: none

(4)の任意のパラメタ: なし

   (5)  Security considerations: none

(5) セキュリティ問題: なし

   The multipart/encrypted content type contains exactly two body parts.
   The first body part contains the control information necessary to
   decrypt the data in the second body part and is labeled according to
   the value of the protocol parameter.  The second body part contains
   the data which was encrypted and is always labeled
   application/octet-stream.

複合の、または、暗号化されたcontent typeはちょうど2つの身体の部分を含んでいます。 最初の身体の部分は、2番目の身体の部分にデータを解読するのに必要な制御情報を含んでいて、プロトコルパラメタの値に従って、ラベルされます。 2番目の身体の部分は暗号化されて、いつも八重奏アプリケーション/ストリームとラベルされるデータを含んでいます。

   The attribute token for the protocol parameter is "protocol", i.e.,

すなわち、プロトコルパラメタのための属性トークンは「プロトコル」です。

    parameter := "protocol" "=" value

パラメタ:=「プロトコル」「=」価値

Galvin, et al               Standards Track                     [Page 6]

RFC 1847                  Security Multiparts               October 1995

ガルビン、他Standards Track[6ページ]RFC1847Security Multiparts1995年10月

   The value token is comprised of the type and sub-type tokens of the
   Content-Type: header of the first body part, i.e.,

値のトークンはコンテントタイプのタイプとサブタイプトークンから成ります: すなわち、最初の身体の部分のヘッダー

    value := <"> type "/" subtype <">

「値の:=<「>タイプ」/」「副-タイプ」<">"

   where the type and subtype tokens are defined by the MIME [2]
   specification.  The semantics of the protocol parameter are defined
   according to its value.

タイプと「副-タイプ」トークンがMIME[2]仕様で定義されるところ。 値に従って、プロトコルパラメタの意味論は定義されます。

   When creating a multipart/encrypted body part, the following sequence
   of steps describes the processing necessary.  It must be emphasized
   that these steps are descriptive, not prescriptive, and in no way
   impose restrictions or requirements on implementations of this
   specification.

複合の、または、暗号化された身体の部分を作成するとき、ステップの以下の系列は必要な状態で処理について説明します。 これらのステップが規範的であるのではなく、描写的であり、この仕様の実装に制限か要件を決して課さないと強調しなければなりません。

   (1)  The contents of the body part to be protected is prepared according
        to a local convention.  The contents are then transformed into a
        MIME body part in canonical MIME format, including an appropriate
        set of MIME headers.

(1) 地方のコンベンションによると、保護されるべき身体の部分のコンテンツは準備されます。 次に、内容は正準なMIME形式でMIME身体の部分に変えられます、適切なセットのMIMEヘッダーを含んでいて。

   (2)  The body part (headers and content) to be encrypted is prepared for
        encryption according to the value of the protocol parameter.  The
        MIME headers of the encrypted body part are included in the
        encryption to protect from disclosure the MIME labeling of the
        data that is encrypted.

(2) プロトコルパラメタの値に従って、暗号化されるべき身体の部分(ヘッダーと内容)は暗号化のために準備されます。 暗号化された身体の部分のMIMEヘッダーは、公開から暗号化されたデータのMIMEラベリングを保護するために暗号化に含まれています。

   (3)  The prepared body part is made available to the encryption process
        according to a local convention.  The encryption process must make
        available to a MIME implementation two data streams: the control
        information necessary to decrypt the body part, which the MIME
        implementation will place in the first body part and label
        according to the value of the protocol parameter, and the
        encrypted body part, which the MIME implementation will place in
        the second body part and label application/octet-stream.  Thus,
        when used in a multipart/encrypted, the application/octet-stream
        data is comprised of a nested MIME body part.

(3) 準備された身体の部分を地方のコンベンションによると、暗号化プロセスに利用可能にします。 暗号化プロセスで、2つのデータストリームがMIME実装に利用可能にならなければなりません: ボディーがプロトコルパラメタの値に応じてMIME実装が最初の身体の部分とラベルに置く部分と、MIME実装が2番目の身体の部分とラベル八重奏アプリケーション/ストリームに置く暗号化された身体の部分であると解読するのに必要な制御情報。 したがって、暗号化された複合/で使用されると、八重奏アプリケーション/ストリームデータは入れ子にされたMIME身体の部分から成ります。

   When receiving a multipart/encrypted body part, the following
   sequence of steps describes the processing necessary to decrypt the
   enclosed data.  It must be emphasized that these steps are
   descriptive, not prescriptive, and in no way impose restrictions or
   requirements on implementations of this specification.

複合の、または、暗号化された身体の部分を受け取るとき、ステップの以下の系列は同封のデータを解読するのに必要な処理について説明します。 これらのステップが規範的であるのではなく、描写的であり、この仕様の実装に制限か要件を決して課さないと強調しなければなりません。

   (1)  The second body part and the control information in the first body
        part must be prepared for the decryption process according to the
        value of the protocol parameter.

(1) プロトコルパラメタの値に従って、復号化プロセスのために2番目の身体の部分と最初の身体の部分の制御情報を準備しなければなりません。

Galvin, et al               Standards Track                     [Page 7]

RFC 1847                  Security Multiparts               October 1995

ガルビン、他Standards Track[7ページ]RFC1847Security Multiparts1995年10月

   (2)  The prepared body parts must be made available to the decryption
        process according to a local convention.  The decryption process
        must make available to the MIME implementation the result of the
        decryption and the decrypted form of the encrypted body part.

(2) 準備された身体の部分を地方のコンベンションによると、復号化プロセスに利用可能にしなければなりません。 復号化プロセスで、復号化の結果と暗号化された身体の部分の解読されたフォームはMIME実装に利用可能にならなければなりません。

            NOTE: The result of the decryption process is likely to
            include a testament of the success or failure of the
            decryption.  Failure may be due to an inability to locate
            the proper decryption key or the proper recipient field,
            etc.  Implementors should note that the data, if any, of a
            failed decryption process is pretty much guaranteed to be
            garbage.

以下に注意してください。 復号化プロセスの結果は復号化の成否の遺書を含んでいそうです。 失敗は適切な復号化キーか適切な受取人分野の場所を見つけることができないことなどのためであるかもしれません。 作成者は、もしあれば失敗した復号化プロセスに関するデータがゴミになるようにほとんど保証されることに注意するべきです。

   (3)  The result of the decryption process is made available to the user
        and the MIME implementation continues processing with the decrypted
        body part, i.e., the body part returned by the decryption process.

(3) 復号化プロセスの結果をユーザにとって利用可能にします、そして、MIME実装は解読された身体の部分がある処理、すなわち、復号化プロセスによって返された身体の部分を続けています。

            NOTE: A MIME implementation will not be able to display the
            received form of the second body part because the
            application of encryption will transform the body part.
            This transformation will not be described in the MIME
            headers (Content-Type: and Content-Transfer-Encoding:) but,
            rather, will be described in the content of the first body
            part.  Therefore, an implementation should wait until the
            encryption has been removed before attempting to display
            the content.

以下に注意してください。 暗号化の応用が身体の部分を変えるので、MIME実装は2番目の身体の部分の受け取られていている書式を表示できないでしょう。 この変換は、MIMEヘッダー(コード化して、Contentが移しているコンテントタイプ:)で説明されませんが、最初の身体の部分の内容でむしろ説明されるでしょう。 したがって、実装は内容を表示するのを試みる前に暗号化を取り除くまで待つべきです。

   The following example is an illustration of a multipart/encrypted
   body part.  It is necessarily incomplete since the control
   information is defined by the security protocol, which must be
   specified in a separate document.

以下の例は複合の、または、暗号化された身体の部分のイラストです。 セキュリティプロトコル(別々のドキュメントで指定しなければならない)によって制御情報が定義されるので、それは必ず不完全です。

    Content-Type: multipart/encrypted; protocol="TYPE/STYPE";
            boundary="Encrypted Boundary"

コンテントタイプ: 複合か暗号化される。 =「タイプ/STYPE」について議定書の中で述べてください。 境界=は「境界を暗号化しました」。

    --Encrypted Boundary
    Content-Type: TYPE/STYPE

--暗号化された境界コンテントタイプ: タイプ/STYPE

    CONTROL INFORMATION for protocol "TYPE/STYPE" would be here

プロトコル「タイプ/STYPE」へのCONTROL情報がここにあるでしょう。

    --Encrypted Boundary
    Content-Type: application/octet-stream

--暗号化された境界コンテントタイプ: 八重奏アプリケーション/ストリーム

        Content-Type: text/plain; charset="us-ascii"

コンテントタイプ: テキスト/平野。 charsetが等しい、「私たち、-、ASCII、」

Galvin, et al               Standards Track                     [Page 8]

RFC 1847                  Security Multiparts               October 1995

ガルビン、他Standards Track[8ページ]RFC1847Security Multiparts1995年10月

        All of this indented text, including the indented headers,
        would be unreadable since it would have been encrypted by
        the protocol "TYPE/STYPE".  Also, this encrypted data could
        be any type of data, labeled accordingly, of course.

それはプロトコル「タイプ/STYPE」によって暗号化されたでしょう、したがって、入り込まれたヘッダーを含むこの入り込まれたテキストのすべてが読みにくいでしょう。 また、この暗号化されたデータがそれに従って、ラベルされたどんなタイプに関するデータであるかもしれない、もちろん。

    --Encrypted Boundary--

--境界を暗号化します--

3.  Definition of Control Information Content Types

3. コントロール情報量の定義

   This document defines a framework within which security services may
   be applied to MIME body parts.  A minimal MIME implementation will be
   able to recognize multipart/signed and multipart/encrypted body parts
   and be able to identify the protected data and control information
   body parts within them.

このドキュメントはセキュリティー・サービスがMIME身体の部分に適用されるかもしれないフレームワークを定義します。 最小量のMIME実装は、署名される複合/と複合の、または、暗号化された身体の部分を認識して、それらの中で保護されたデータと制御情報身体の部分を特定できるでしょう。

   Complete support for security services requires the MIME agent to
   recognize the value of the protocol parameter and to continue
   processing based on its value.  The value of the protocol parameter
   is the same value used to label the content type of the control
   information.

セキュリティー・サービスの完全なサポートは、MIMEエージェントが、プロトコルパラメタの値を認めて、値に基づいて処理し続けているのを必要とします。 プロトコルパラメタの値はコントロールのcontent typeを情報とラベルするのに使用される同じ値です。

   The value of the protocol parameter and the resulting processing
   required must be specified in the document defining the security
   protocol used.  That document must also precisely specify the
   contents of the control information body part.

セキュリティプロトコルが使用したドキュメント定義でプロトコルパラメタの値と処理が必要とした結果になることを指定しなければなりません。 また、そのドキュメントは正確に制御情報身体の部分のコンテンツを指定しなければなりません。

4.  Definition of Key Management Content Types

4. Key Management content typeの定義

   This specification recognizes that the complete specification of a
   MIME-based security protocol must include a mechanism for
   distributing the cryptographic material used in support of the
   security services.  For example, a digital signature service
   implemented with asymmetric cryptography requires that a signer's
   public key be available to the signee.

この仕様は、MIMEベースのセキュリティプロトコルの完全な仕様がセキュリティー・サービスを支持して使用される暗号の材料を分配するためのメカニズムを含まなければならないと認めます。 例えば、非対称の暗号で実装されたデジタル署名サービスは、署名者の公開鍵がsigneeに利用可能であることを必要とします。

   One possible mechanism for distributing cryptographic material is to
   define two additional body parts: one for the purpose of requesting
   cryptographic information and one for the purpose of returning the
   cryptographic information requested.  The specification of a security
   protocol may include a definition of two such body parts or it may
   specify an alternate mechanism for the distribution of cryptographic
   material.

暗号の材料を分配するための1台の可能なメカニズムは2つの追加身体の部分を定義することです: 暗号の情報を要求する目的のためのものと暗号の情報が要求した帰りの目的のためのもの。 セキュリティプロトコルの仕様がそのような2つの身体の部分の定義を含むかもしれませんか、またはそれは暗号の材料の分配に代替のメカニズムを指定するかもしれません。

Galvin, et al               Standards Track                     [Page 9]

RFC 1847                  Security Multiparts               October 1995

ガルビン、他Standards Track[9ページ]RFC1847Security Multiparts1995年10月

5.  Security Considerations

5. セキュリティ問題

   This specification describes an enhancement to MIME to support signed
   and encrypted body parts.  In that context this entire document is
   about security.

この仕様は、署名していて暗号化された身体の部分をサポートするために増進についてMIMEに説明します。 その文脈では、この全体のドキュメントはセキュリティに関するものです。

6.  Acknowledgements

6. 承認

   David H. Crocker suggested the use of a multipart structure for the
   MIME and PEM interaction.

デヴィッド・H.クロッカーは複合構造のMIMEとPEM相互作用の使用を勧めました。

7.  References

7. 参照

   [1] Crocker, D., "Standard for the Format of ARPA Internet Text
       Messages", STD 11, RFC 822, University of Delaware, August 1982.

[1] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、デラウエア大学(1982年8月)。

   [2] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
       Extension) Part One: Mechanisms for Specifying and Describing the
       Format of Internet Message Bodies", RFC 1521, Bellcore and
       Innosoft, September 1993.

[2] Borenstein、N.、およびN.フリード、「(マルチパーパスインターネットメールエクステンション)パート1をまねてください」 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」とRFC1521とBellcoreとInnosoft、1993年9月。

Galvin, et al               Standards Track                    [Page 10]

RFC 1847                  Security Multiparts               October 1995

ガルビン、他Standards Track[10ページ]RFC1847Security Multiparts1995年10月

8.  Authors' Addresses

8. 作者のアドレス

   Jim Galvin
   Trusted Information Systems
   3060 Washington Road
   Glenwood, MD  21738

ジム・ガルビンは情報システム3060ワシントン道路グレンウッド、MD 21738を信じました。

   Phone: +1 301 854 6889
   Fax: +1 301 854 5363
   EMail:  galvin@tis.com

以下に電話をしてください。 +1 301 854、6889Fax: +1 5363年の301 854メール: galvin@tis.com

   Sandy Murphy
   Trusted Information Systems
   3060 Washington Road
   Glenwood, MD  21738

砂地のマーフィーは情報システム3060ワシントン道路グレンウッド、MD 21738を信じました。

   Phone: +1 301 854 6889
   Fax: +1 301 854 5363
   EMail:  sandy@tis.com

以下に電話をしてください。 +1 301 854、6889Fax: +1 5363年の301 854メール: sandy@tis.com

   Steve Crocker
   CyberCash, Inc.
   2086 Hunters Crest Way
   Vienna, VA 22181

スティーブ医者サイバーキャッシュInc.2086ハンターは道ウィーン(ヴァージニア)22181の前立てを付けます。

   Phone::    +1 703 620 1222
   Fax:    +1 703 391 2651
   EMail:  crocker@cybercash.com

以下に電話をしてください: +1 703 620、1222Fax: +1 2651年の703 391メール: crocker@cybercash.com

   Ned Freed
   Innosoft International, Inc.
   1050 East Garvey Avenue South
   West Covina, CA 91790

ネッドはSouth Westコビーナ、Innosoftの国際Inc.1050の東ガーヴェーAvenueカリフォルニア 91790を解放しました。

   Phone: +1 818 919 3600
   Fax: +1 818 919 3614
   EMail:  ned@innosoft.com

以下に電話をしてください。 +1 818 919、3600Fax: +1 3614年の818 919メール: ned@innosoft.com

Galvin, et al               Standards Track                    [Page 11]

ガルビン、他のStandards Track[11ページ]