Network Working Group M. Elkins
Request for Comments: 3156 Network Associates, Inc.
Updates: 2015 D. Del Torto
Category: Standards Track CryptoRights Foundation
R. Levien
University of California at Berkeley
T. Roessler
August 2001
MIME Security with OpenPGP
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847.
このドキュメントは、OpenPGPのメッセージフォーマットは、RFC 1847で説明MIME（Multipurpose Internet Mail Extensions）のセキュリティコンテンツタイプを使用して、プライバシーと認証を提供するために使用することができる方法を説明します。
Work on integrating PGP (Pretty Good Privacy) with MIME [3] (including the since withdrawn "application/pgp" content type) prior to RFC 2015 suffered from a number of problems, the most significant of which is the inability to recover signed message bodies without parsing data structures specific to PGP. RFC 2015 makes use of the elegant solution proposed in RFC 1847, which defines security multipart formats for MIME. The security multiparts clearly separate the signed message body from the signature, and have a number of other desirable properties. This document revises RFC 2015 to adopt the integration of PGP and MIME to the needs which emerged during the work on the OpenPGP specification.
前RFC 2015 [3]（以降撤回「アプリケーション/ PGP、」コンテンツタイプを含む）MIMEとPGP（プリティグッドプライバシー）を統合する上での作業は、署名されたメッセージを復元することができないことであるそのうち最も重要なの多くの問題、苦しんPGPに固有のデータ構造を解析せずに体。 RFC 2015は、MIMEのためのセキュリティマルチパート形式を定義するRFC 1847で提案されたエレガントなソリューションを利用します。セキュリティ・マルチパートは、明らかに署名から署名されたメッセージ本体を分離し、そして他の望ましい特性の数を有しています。このドキュメントは、OpenPGPの仕様上の作業中に現れたのニーズにPGPとMIMEの統合を採用するRFC 2015を改訂します。
This document defines three content types for implementing security and privacy with OpenPGP: "application/pgp-encrypted", "application/pgp-signature" and "application/pgp-keys".
「アプリケーション/ PGPで暗号化された」、「アプリケーション/ PGP署名」と「アプリケーション/ PGP-キー」：この文書では、3つのコンテンツのOpenPGPでセキュリティとプライバシーを実装するための型を定義します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈されます。
OpenPGP implementations can generate either ASCII armor (described in [1]) or 8-bit binary output when encrypting data, generating a digital signature, or extracting public key data. The ASCII armor output is the REQUIRED method for data transfer. This allows those users who do not have the means to interpret the formats described in this document to be able to extract and use the OpenPGP information in the message.
OpenPGPの実装は、デジタル署名を生成し、データを暗号化、または公開鍵データを抽出するとき、または8ビットのバイナリ出力（[1]に記載）ASCII装甲のいずれかを生成することができます。アスキー装甲出力は、データ転送に必要な方法です。これは、メッセージにOpenPGPの情報を抽出して使用できるようにするには、この文書で説明する形式を解釈するための手段を持たないユーザーができます。
When the amount of data to be transmitted requires that it be sent in many parts, the MIME message/partial mechanism SHOULD be used rather than the multi-part ASCII armor OpenPGP format.
送信されるデータの量は、それが多くの部分で送信されることを必要とする場合、MIMEメッセージ/部分的な機構は、マルチパートASCII装甲OpenPGP形式ではなく、使用されるべきです。
Multipart/signed and multipart/encrypted are to be treated by agents as opaque, meaning that the data is not to be altered in any way [2], [7]. However, many existing mail gateways will detect if the next hop does not support MIME or 8-bit data and perform conversion to either Quoted-Printable or Base64. This presents serious problems for multipart/signed, in particular, where the signature is invalidated when such an operation occurs. For this reason all data signed according to this protocol MUST be constrained to 7 bits (8- bit data MUST be encoded using either Quoted-Printable or Base64). Note that this also includes the case where a signed object is also encrypted (see section 6). This restriction will increase the likelihood that the signature will be valid upon receipt.
マルチパート/署名され、マルチパート/暗号化された不透明なように薬剤によって治療される、データがどのような方法で変更されないことを意味する[2]、[7]。次のホップは、MIMEまたは8ビットのデータをサポートし、quoted-printableのかBase64のいずれかへの変換を行わない場合は、多くの既存のメールゲートウェイが検出されます。これは、このような動作が発生した場合、署名が無効にされ、特に、署名されたマルチパート/について深刻な問題を提示します。この理由のため、このプロトコルに従って署名されたすべてのデータは、7ビット（8ビットデータはquoted-printable形式またはBase64のいずれかを使用して符号化されなければならない）に制限されなければなりません。これはまた、署名されたオブジェクトも（セクション6を参照）暗号化されている場合も含むことに留意されたいです。この制限は、署名がレシートに有効となる可能性が増加します。
Additionally, implementations MUST make sure that no trailing whitespace is present after the MIME encoding has been applied.
また、実装はMIMEエンコーディングが適用された後に何の末尾の空白が存在しないことを確認する必要があります。
Note: In most cases, trailing whitespace can either be removed, or protected by applying an appropriate content-transfer-encoding. However, special care must be taken when any header lines - either in MIME entity headers, or in embedded RFC 822 headers - are present which only consist of whitespace: Such lines must be removed entirely, since replacing them by empty lines would turn them into header delimiters, and change the semantics of the message. The restrictions on whitespace are necessary in order to make the hash calculated invariant under the text and binary mode signature mechanisms provided by OpenPGP [1]. Also, they help to avoid compatibility problems with PGP implementations which predate the OpenPGP specification.
注：ほとんどの場合、末尾の空白のいずれかを除去することができる、または適切なコンテンツ転送符号化を適用することによって保護しました。このような線は、完全に除去されなければならないにそれらを回すことになる空白行によってそれらを置換するため： - いずれかのMIMEエンティティヘッダに、または埋め込みRFC 822ヘッダ内 - 空白のみで構成されている存在する任意のヘッダ行がしかし、特別な注意を払わなければなりません区切り記号、ヘッダ、およびメッセージのセマンティクスを変更します。空白に制限がOpenPGPの[1]によって提供されるテキストとバイナリモード署名メカニズムの下で不変で算出されたハッシュを作るために必要です。また、彼らはOpenPGPの仕様に先行PGPの実装との互換性の問題を回避するのに役立ちます。
Note: If any line begins with the string "From ", it is strongly suggested that either the Quoted-Printable or Base64 MIME encoding be applied. If Quoted-Printable is used, at least one of the characters in the string should be encoded using the hexadecimal coding rule. This is because many mail transfer and delivery agents treat "From " (the word "from" followed immediately by a space character) as the start of a new message and thus insert a right angle-bracket (>) in front of any line beginning with "From " to distinguish this case, invalidating the signature.
注：すべての行は、「から」の文字列で始まる場合、どちらかquoted-printable形式またはBase64のMIMEエンコードが適用されることを強く示唆しています。 quoted-printable形式が使用される場合、文字列内の文字の少なくとも一つは、16進符号化ルールを使用して符号化されるべきです。これは、任意の行の最初の前に（>）多くのメール転送と配信エージェントが扱うため、新しいメッセージの開始のとおりです（空白文字の直後に「から」という単語）「から、」したがって、直角ブラケットを挿入しますこのケースを区別するために「から」、署名を無効と。
Data that is ONLY to be encrypted is allowed to contain 8-bit characters and trailing whitespace and therefore need not undergo the conversion to a 7bit format, and the stripping of whitespace.
ONLY暗号化されるデータは、7ビットフォーマットへの変換、および空白のストリッピングを受ける必要はなく、したがって、8ビット文字と末尾の空白を含有させています。
Implementor's note: It cannot be stressed enough that applications using this standard follow MIME's suggestion that you "be conservative in what you generate, and liberal in what you accept." In this particular case it means it would be wise for an implementation to accept messages with any content-transfer-encoding, but restrict generation to the 7-bit format required by this memo. This will allow future compatibility in the event the Internet SMTP framework becomes 8-bit friendly.
実装者注：これは、この標準を使用するアプリケーションは、あなたがMIMEの提案に従うことを十分に強調することはできません「あなたが生成するもので保守的であるが、あなたが受け入れるものにリベラル。」この特定のケースでは、実装は、任意のコンテンツ転送エンコードでメッセージを受け入れるが、このメモによって必要とされる7ビットのフォーマットに生成を制限することが賢明であろうことを意味します。これは、インターネットSMTPフレームワークは、8ビットフレンドリーになった場合に将来の互換性が可能になります。
Before OpenPGP encryption, the data is written in MIME canonical format (body and headers).
OpenPGPの暗号化の前に、データは、MIME標準形式（ボディとヘッダ）に書き込まれます。
OpenPGP encrypted data is denoted by the "multipart/encrypted" content type, described in [2], and MUST have a "protocol" parameter value of "application/pgp-encrypted". Note that the value of the parameter MUST be enclosed in quotes.
OpenPGPの暗号化されたデータは、[2]に記載の、「マルチパート/暗号化された」コンテンツタイプで示され、そして「アプリケーション/ PGP暗号化」の「プロトコル」パラメータ値を持たなければなりません。パラメータの値は引用符で囲む必要があります。
The multipart/encrypted MIME body MUST consist of exactly two body parts, the first with content type "application/pgp-encrypted". This body contains the control information. A message complying with this standard MUST contain a "Version: 1" field in this body. Since the OpenPGP packet format contains all other information necessary for decrypting, no other information is required here.
マルチパート/暗号化されたMIME本体は、正確に2つの本体部分、コンテンツタイプ「アプリケーション/ PGP暗号化」の最初から構成されなければなりません。このボディは、制御情報が含まれています。このボディに：「1バージョン」フィールドに、この規格に準拠したメッセージが含まれていなければなりません。 OpenPGPのパケットフォーマットを復号するために必要な他のすべての情報が含まれているため、他の情報はここでは必要ありません。
The second MIME body part MUST contain the actual encrypted data. It MUST be labeled with a content type of "application/octet-stream".
二MIMEボディ部は、実際の暗号化されたデータを含まなければなりません。それが「application / octet-stream」のコンテンツタイプで標識されなければなりません。
Example message:
例のメッセージ：
From: Michael Elkins <elkins@aero.org> To: Michael Elkins <elkins@aero.org> Mime-Version: 1.0
投稿者：マイケル・エルキンズ<elkins@aero.org>宛先：マイケル・エルキンズ<elkins@aero.org>マイム・バージョン：1.0
Content-Type: multipart/encrypted; boundary=foo; protocol="application/pgp-encrypted"
コンテンツタイプ：マルチパート/暗号化されました。境界= FOO;プロトコル=「アプリケーション/ PGPで暗号化されました」
--foo Content-Type: application/pgp-encrypted
--fooのContent-Type：アプリケーション/ PGPで暗号化されました
Version: 1
バージョン：1
--foo Content-Type: application/octet-stream
--fooのContent-Type：アプリケーション/オクテットストリーム
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
=zzaA
-----END PGP MESSAGE-----
--foo--
--foo--
OpenPGP signed messages are denoted by the "multipart/signed" content type, described in [2], with a "protocol" parameter which MUST have a value of "application/pgp-signature" (MUST be quoted).
OpenPGPのメッセージがで示されている署名された「アプリケーション/ PGP署名」の値を有しなければならない「プロトコル」パラメータ（引用する必要があります）と、[2]に記載のコンテンツタイプを、「マルチパート/署名されました」。
The "micalg" parameter for the "application/pgp-signature" protocol MUST contain exactly one hash-symbol of the format "pgp-<hash-identifier>", where <hash-identifier> identifies the Message Integrity Check (MIC) algorithm used to generate the signature. Hash-symbols are constructed from the text names registered in [1] or according to the mechanism defined in that document by converting the text name to lower case and prefixing it with the four characters "pgp-".
<ハッシュ識別子>メッセージ整合性チェック（MIC）アルゴリズムを識別する「アプリケーション/ PGP署名」の「micalg」パラメータプロトコルが「pgp- <ハッシュ識別子>」の形式の正確に一つのハッシュシンボルを格納しなければなりません。署名を生成するために使用されます。ハッシュ・シンボルは、に登録テキスト名から構成されている[1]または小文字にテキスト名を変換し、4つの文字「pgp-」でそれを付けることによって、そのドキュメントで定義されたメカニズムに従います。
Currently defined values are "pgp-md5", "pgp-sha1", "pgp-ripemd160", "pgp-md2", "pgp-tiger192", and "pgp-haval-5-160".
現在、定義された値は、 "PGP-MD5"、 "PGP-SHA1"、 "PGP-RIPEMD160"、 "PGP-MD2"、 "PGP-tiger192"、および "PGP-HAVAL-5-160" です。
The multipart/signed body MUST consist of exactly two parts. The first part contains the signed data in MIME canonical format, including a set of appropriate content headers describing the data.
マルチパート/署名された本体は、正確に2つの部分で構成しなければなりません。最初の部分は、データを記述する適切なコンテンツヘッダのセットを含むMIME標準形式で署名されたデータを含みます。
The second body MUST contain the OpenPGP digital signature. It MUST be labeled with a content type of "application/pgp-signature".
第二の本体は、OpenPGPのデジタル署名を含まなければなりません。これは、「アプリケーション/ PGP署名」のコンテンツタイプで標識されなければなりません。
Note: Implementations can either generate "signatures of a canonical text document" or "signatures of a binary document", as defined in [1]. The restrictions on the signed material put forth in section 3 and in this section will make sure that the various MIC algorithm variants specified in [1] and [5] will all produce the same result.
注：[1]で定義されるように実装は、「標準的なテキスト文書の署名」または「バイナリ文書の署名」を生成することができます。セクション3に、このセクションで出す調印材料上の制限は、さまざまなMICアルゴリズム変異体は、[1]、[5]すべてが生成されます、同じ結果に指定されていることを確認します。
When the OpenPGP digital signature is generated:
OpenPGPのデジタル署名が生成されます。
(1) The data to be signed MUST first be converted to its content-type specific canonical form. For text/plain, this means conversion to an appropriate character set and conversion of line endings to the canonical <CR><LF> sequence.
（1）署名されるべきデータは、最初にそのコンテンツ・タイプ固有の正規の形式に変換されなければなりません。 text / plainの場合、これは適切な文字セットと正規<CR> <LF>配列に行末の変換への変換を意味します。
(2) An appropriate Content-Transfer-Encoding is then applied; see section 3. In particular, line endings in the encoded data MUST use the canonical <CR><LF> sequence where appropriate (note that the canonical line ending may or may not be present on the last line of encoded data and MUST NOT be included in the signature if absent).
（2）適切なコンテンツ転送エンコードは、次に印加されます。カノニカルライン終了はしてもしなくてもよい符号化データの最後の行に存在することができるとされてはならないことに注意してください（必要に応じて符号化データで行末が正規<CR> <LF>シーケンスを使用しなければなりません、特にセクション3を参照してください存在しない場合、署名に含まれます）。
(3) MIME content headers are then added to the body, each ending with the canonical <CR><LF> sequence.
（3）MIMEコンテンツヘッダは、各カノニカル<CR> <LF>シーケンスで終わる、体に添加されます。
(4) As described in section 3 of this document, any trailing whitespace MUST then be removed from the signed material.
このドキュメントのセクション3で説明したように（4）、末尾の空白は、次に署名された材料から除去しなければなりません。
(5) As described in [2], the digital signature MUST be calculated over both the data to be signed and its set of content headers.
（5）で説明したように、[2]、デジタル署名は、署名されるべきデータとコンテンツヘッダーのセットの両方に渡って計算しなければなりません。
(6) The signature MUST be generated detached from the signed data so that the process does not alter the signed data in any way.
プロセスは、任意の方法で署名されたデータを変更しないように（6）署名が生成された署名されたデータから取り外さなければなりません。
Note: The accepted OpenPGP convention is for signed data to end with a <CR><LF> sequence. Note that the <CR><LF> sequence immediately preceding a MIME boundary delimiter line is considered to be part of the delimiter in [3], 5.1. Thus, it is not part of the signed data preceding the delimiter line. An implementation which elects to adhere to the OpenPGP convention has to make sure it inserts a <CR><LF> pair on the last line of the data to be signed and transmitted (signed message and transmitted message MUST be identical).
注：受け入れOpenPGPの規則は、<CR> <LF>シーケンスで終了する署名されたデータのためのものです。直ちにMIME境界の区切り線を先行<CR> <LF>シーケンスが[3]、5.1のデリミタの一部であると考えられることに留意されたいです。これにより、区切り線に先行する署名されたデータの一部ではありません。 OpenPGPの規則に準拠することを選択する実装は、（署名されたメッセージ及び送信メッセージは同一でなければならない）、それが署名され、送信すべきデータの最後の行に<CR> <LF>対を挿入を確認しなければなりません。
Example message:
例のメッセージ：
From: Michael Elkins <elkins@aero.org>
To: Michael Elkins <elkins@aero.org>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5; protocol="application/pgp-signature"
コンテンツタイプ：マルチパート/署名しました。境界=バー。 micalg = PGP-MD5;プロトコル=「アプリケーション/ PGP署名」
--bar & Content-Type: text/plain; charset=iso-8859-1 & Content-Transfer-Encoding: quoted-printable & & =A1Hola! & & Did you know that talking to yourself is a sign of senility? & & It's generally a good idea to encode lines that begin with & From=20because some mail transport agents will insert a greater-& than (>) sign, thus invalidating the signature. & & Also, in some cases it might be desirable to encode any =20 & trailing whitespace that occurs on lines in order to ensure =20 & that the message signature is not invalidated when passing =20 & a gateway that modifies such whitespace (like BITNET). =20 & & me
--bar＆コンテンツタイプ：テキスト/平野。文字セット= ISO-8859-1＆コンテンツ転送 - エンコード：＆quoted-printableの＆= A1Hola！ ＆＆あなた自身に話しが老衰の兆候であることを知っていますか？ &&それは一般的に＆から始まる行をエンコードすることをお勧めします=いくつかのメール転送エージェントは、このように署名を無効、（>）記号より＆greater- 20because挿入します。 ＆＆また、ある場合には= 20＆= 20＆（のような、そのような空白を変更するゲートウェイを通過するときにメッセージの署名が無効にされていないことを保証するためにライン上で発生する任意= 20＆末尾の空白を符号化することが望ましいかもしれませんBITNET）。 = 20＆＆私
--bar
- バー
Content-Type: application/pgp-signature
コンテンツタイプ：アプリケーション/ PGP署名
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
HOxEa44b+EI=
=ndaj
-----END PGP MESSAGE-----
--bar--
- バー -
The "&"s in the previous example indicate the portion of the data over which the signature was calculated.
前の例では「＆」の署名が計算された先のデータの部分を示します。
Upon receipt of a signed message, an application MUST:
署名されたメッセージは、アプリケーションMUSTを受信します。
(1) Convert line endings to the canonical <CR><LF> sequence before the signature can be verified. This is necessary since the local MTA may have converted to a local end of line convention.
署名を検証することができる前に、（1）正規の<CR> <LF>配列に改行コードを変換。ローカルMTAは、ライン規則のローカルエンドに変換したかもしれないので、これは必要です。
(2) Pass both the signed data and its associated content headers along with the OpenPGP signature to the signature verification service.
（2）署名検証サービスへのOpenPGP署名と共に署名されたデータとそれに関連するコンテンツヘッダーの両方を渡します。
Sometimes it is desirable to both digitally sign and then encrypt a message to be sent. This protocol allows for two methods of accomplishing this task.
時にはデジタル署名した後、送信されるメッセージを暗号化の両方に望ましいです。このプロトコルは、このタスクを達成するための二つの方法が可能になります。
In [2], it is stated that the data is first signed as a multipart/signature body, and then encrypted to form the final multipart/encrypted body. This is most useful for standard MIME-compliant message forwarding.
[2]、データが最初にマルチパート/署名体として署名、及び最終的なマルチパート/暗号化された本体を形成するために暗号化されることが記載されています。これは、標準のMIME準拠のメッセージ転送のために最も有用です。
Example:
例：
Content-Type: multipart/encrypted;
protocol="application/pgp-encrypted"; boundary=foo
--foo Content-Type: application/pgp-encrypted
--fooのContent-Type：アプリケーション/ PGPで暗号化されました
Version: 1
バージョン：1
--foo Content-Type: application/octet-stream
--fooのContent-Type：アプリケーション/オクテットストリーム
-----BEGIN PGP MESSAGE-----
& Content-Type: multipart/signed; micalg=pgp-md5
& protocol="application/pgp-signature"; boundary=bar
&
& --bar
& Content-Type: text/plain; charset=us-ascii
&
& This message was first signed, and then encrypted.
&
& --bar
& Content-Type: application/pgp-signature
&
& -----BEGIN PGP MESSAGE-----
& Version: 2.6.2
&
& iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
& jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
& uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
& HOxEa44b+EI=
& =ndaj
& -----END PGP MESSAGE-----
&
& --bar--
-----END PGP MESSAGE-----
--foo--
--foo--
(The text preceded by '&' indicates that it is really encrypted, but presented as text for clarity.)
（テキストが前に「＆」それが本当に暗号化されていることを示しているが、明確にするためのテキストとして提示します。）
The OpenPGP packet format [1] describes a method for signing and encrypting data in a single OpenPGP message. This method is allowed in order to reduce processing overhead and increase compatibility with non-MIME implementations of OpenPGP. The resulting data is formatted as a "multipart/encrypted" object as described in Section 4.
OpenPGPのパケットフォーマットは、[1]署名と単一のOpenPGPメッセージ内のデータを暗号化するための方法を記載しています。この方法は、処理オーバーヘッドを減らし、OpenPGPの非MIME実装との互換性を高めるために許可されています。セクション4で説明したように得られたデータは、「マルチパート/暗号化された」オブジェクトとしてフォーマットされます。
Messages which are encrypted and signed in this combined fashion are REQUIRED to follow the same canonicalization rules as multipart/signed objects.
この組み合わせ方式で暗号化され署名されたメッセージは、マルチパート/署名されたオブジェクトと同じ正規化規則に従うために必要とされます。
It is explicitly allowed for an agent to decrypt a combined message and rewrite it as a multipart/signed object using the signature data embedded in the encrypted version.
これは、明示的に組み合わされたメッセージを解読するおよび暗号化されたバージョンに埋め込まれた署名データを用いて、マルチパート/署名されたオブジェクトとしてそれを書き換えるエージェントに許可されています。
Content-Type: application/pgp-keys Required parameters: none Optional parameters: none
コンテンツタイプ：アプリケーション/ PGP-キー必須パラメーター：なしオプションのパラメータ：なし
A MIME body part of the content type "application/pgp-keys" contains ASCII-armored transferable Public Key Packets as defined in [1], section 10.1.
[1]、セクション10.1で定義されているコンテンツタイプ「アプリケーション/ PGP鍵」のMIME本体部分は、ASCII装甲譲渡公開鍵パケットを含みます。
Signatures of a canonical text document as defined in [1] ignore trailing white space in signed material. Implementations which choose to use signatures of canonical text documents will not be able to detect the addition of whitespace in transit.
で定義されている正規のテキスト文書の署名は、[1]署名された材料中に空白を末尾無視します。標準的なテキスト文書の署名を使用することを選択した実装は、輸送中の空白の追加を検出することができません。
See [3], [4] for more information on the security considerations concerning the underlying protocols.
基本的なプロトコルに関するセキュリティ上の考慮事項の詳細については、[4]、[3]を参照してください。
This document defines three media types: "application/pgp-encrypted", "application/pgp-signature" and "application/pgp-keys". The following sections specify the IANA registrations for these types.
「アプリケーション/ PGPで暗号化された」、「アプリケーション/ PGP署名」と「アプリケーション/ PGP-キー」：この文書では、3つのメディアタイプを定義します。次のセクションでは、これらのタイプのIANA登録を指定します。
MIME media type name: application MIME subtype name: pgp-encrypted Required parameters: none Optional parameters: none
MIMEメディアタイプ名：application MIMEサブタイプ名：PGPで暗号化に必要なパラメータ：なしオプションのパラメータ：なし
Encoding considerations:
エンコードの考慮事項：
Currently this media type always consists of a single 7bit text string.
現在、このメディアタイプは、常に単一の7ビットのテキスト文字列で構成されています。
Security considerations:
セキュリティの考慮事項：
See Section 8 and RFC 2440 Section 13.
第8章およびRFC 2440のセクション13を参照してください。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification:
公開された仕様：
This document.
このドキュメント。
Additional information:
追加情報：
Magic number(s): none File extension(s): none Macintosh File Type Code(s): none
マジックナンバー（S）：なしファイルの拡張子（S）：なしMacintoshのファイルタイプコード（S）：なし
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Michael Elkins Email: me@cs.hmc.edu
マイケル・エルキンズEメール：me@cs.hmc.edu
Intended usage: common
意図している用法：共通
Author/Change controller:
著者/変更コントローラ：
Michael Elkins Email: me@cs.hmc.edu
マイケル・エルキンズEメール：me@cs.hmc.edu
MIME media type name: application MIME subtype name: pgp-signature Required parameters: none Optional parameters: none
MIMEメディアタイプ名：application MIMEサブタイプ名：PGP署名必須パラメータ：なしオプションのパラメータ：なし
Encoding considerations:
エンコードの考慮事項：
The content of this media type always consists of 7bit text.
このメディアタイプの内容は、常に7ビットのテキストで構成されています。
Security considerations:
セキュリティの考慮事項：
See Section 8 and RFC 2440 Section 13.
第8章およびRFC 2440のセクション13を参照してください。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification:
公開された仕様：
RFC 2440 and this document.
RFC 2440および本書。
Additional information:
追加情報：
Magic number(s): none File extension(s): asc, sig Macintosh File Type Code(s): pgDS
マジックナンバー（S）：なしファイルの拡張子（S）：ASC、SIG Macintoshのファイルタイプコード（S）：PGDS
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Michael Elkins Email: me@cs.hmc.edu
マイケル・エルキンズEメール：me@cs.hmc.edu
Intended usage: common
意図している用法：共通
Author/Change controller:
著者/変更コントローラ：
Michael Elkins Email: me@cs.hmc.edu
マイケル・エルキンズEメール：me@cs.hmc.edu
MIME media type name: application MIME subtype name: pgp-keys Required parameters: none Optional parameters: none
MIMEメディアタイプ名：application MIMEサブタイプ名：PGP-キー必須パラメーター：なしオプションのパラメータ：なし
Encoding considerations:
エンコードの考慮事項：
The content of this media type always consists of 7bit text.
このメディアタイプの内容は、常に7ビットのテキストで構成されています。
Security considerations:
セキュリティの考慮事項：
See Section 8 and RFC 2440 Section 13.
第8章およびRFC 2440のセクション13を参照してください。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification:
公開された仕様：
RFC 2440 and this document.
RFC 2440および本書。
Additional information:
追加情報：
Magic number(s): none File extension(s): asc Macintosh File Type Code(s): none
マジックナンバー（S）：なしファイルの拡張子（S）：ASC Macintoshファイルタイプコード（S）：なし
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Michael Elkins Email: me@cs.hmc.edu
マイケル・エルキンズEメール：me@cs.hmc.edu
Intended usage: common
意図している用法：共通
Author/Change controller:
著者/変更コントローラ：
Michael Elkins Email: me@cs.hmc.edu
マイケル・エルキンズEメール：me@cs.hmc.edu
"PGP" and "Pretty Good Privacy" are registered trademarks of Network Associates, Inc.
「PGP」や「プリティグッドプライバシー」ネットワークアソシエイツ、Inc.の登録商標です。
This document relies on the work of the IETF's OpenPGP Working Group's definitions of the OpenPGP Message Format. The OpenPGP message format is currently described in RFC 2440 [1].
このドキュメントは、OpenPGPのメッセージフォーマットのIETFのワーキンググループのOpenPGPの定義の作業に依存しています。 OpenPGPのメッセージフォーマットは、現在、RFC 2440に記載されている[1]。
Special thanks are due: to Philip Zimmermann for his original and ongoing work on PGP; to Charles Breed, Jon Callas and Dave Del Torto for originally proposing the formation of the OpenPGP Working Group; and to Steve Schoenfeld for helpful feedback during the draft process. The authors would also like to thank the engineers at Pretty Good Privacy, Inc (now Network Associates, Inc), including Colin Plumb, Hal Finney, Jon Callas, Mark Elrod, Mark Weaver and Lloyd Chambers, for their technical commentary.
特別な感謝が原因です：PGPの彼の元と進行中の作業のためのフィリップ・ツィンマーマンに。チャールズ品種、元々のOpenPGPワーキンググループの形成を提案するジョン・カラスとDaveデルTortoへ。ドラフトプロセス中に有益なフィードバックのためのスティーブ・ショーンフェルドへ。著者はまた、彼らの技術的な解説のために、コリン・プラム、ハル・フィニー、ジョン・カラス、マーク・Elrod、マーク・ウィーバーとロイド・チェンなど、プリティグッドプライバシー社（現在はネットワークアソシエイツ社）、でエンジニアに感謝したいと思います。
Additional thanks are due to Jeff Schiller and Derek Atkins for their continuing support of strong cryptography and PGP freeware at MIT; to Rodney Thayer of Sable Technology; to John Noerenberg, Steve Dorner and Laurence Lundblade of the Eudora team at QUALCOMM, Inc; to Bodo Moeller for proposing the approach followed with respect to trailing whitespace; to John Gilmore, Hugh Daniel and Fred Ringel (at Rivertown) and Ian Bell (at Turnpike) for their timely critical commentary; and to the international members of the IETF's OpenPGP mailing list, including William Geiger, Lutz Donnerhacke and Kazu Yamamoto. The idea to use multipart/mixed with multipart/signed has been attributed to James Galvin. Finally, our gratitude is due to the many members of the "Cypherpunks," "Coderpunks" and "pgp-users" <http://cryptorights.org/pgp-users> mailing lists and the many users of PGP worldwide for helping keep the path to privacy open.
追加のおかげでMITの強力な暗号化とPGPフリーウェアの彼らの継続的な支援のためのジェフ・シラーとデレク・アトキンスによるものです。セーブル技術のロドニーセイヤーへ。ジョンNoerenberg、スティーブ・ドルナーとQUALCOMM社のEudoraのチームのローレンスLundbladeへ。ボーデメラーへのアプローチを提案するための空白を末尾に対して続きます。ジョン・ギルモア、ヒュー・ダニエルと（リバータウンで）フレッドRingelと（ターンパイクで）イアン・ベルへのタイムリーな重要な解説のために、そして、ウィリアム・ガイガー、ルッツDonnerhackeとカズ山本など、IETFのOpenPGPのメーリングリストの国際メンバーに。マルチパート/署名を混合/マルチパートを使用するためのアイデアは、ジェームズ・ガルビンに起因しています。最後に、私たちの感謝の気持ちを保つ助けのために世界中で「サイファーパンク、」「Coderpunks」と「PGP-ユーザー」<http://cryptorights.org/pgp-users>メーリングリストやPGPの多くのユーザーの多くのメンバーによるものですオープンプライバシーへのパス。
The OpenPGP working group can be contacted via the current chair:
OpenPGPのワーキンググループは、現在のいすを介して接触させることができます。
John W. Noerenberg II Qualcomm, Inc. 5775 Morehouse Dr. San Diego, CA 92121 USA
ジョン・W・Noerenberg II韓国コム株式会社5775モアハウス博士サンディエゴ、CA 92121 USA
Phone: +1 619 658 3510 EMail: jwn2@qualcomm.com
電話：+1 619 658 3510 Eメール：jwn2@qualcomm.com
The principal authors of this document are:
この文書の主な著者は、以下のとおりです。
Dave Del Torto CryptoRights Foundation 80 Alviso Street, Mailstop: CRF San Francisco, CA 94127 USA
デイブ・デルTorto CryptoRights財団80アルビソストリート、メールストップ：CRFサンフランシスコ、CA 94127 USA
Phone: +1.415.334.5533, vm: #2 EMail: ddt@cryptorights.org, ddt@openpgp.net
電話：+1.415.334.5533、VM：第2位Eメール：ddt@cryptorights.org、ddt@openpgp.net
Michael Elkins Network Associates, Inc. 3415 S. Sepulveda Blvd Suite 700 Los Angeles, CA 90034 USA
マイケル・エルキンズネットワークアソシエイツ株式会社3415 S.セプルベダブルバードスイート700ロサンゼルス、CA 90034 USA
Phone: +1.310.737.1663 Fax: +1.310.737.1755 Email: me@cs.hmc.edu, Michael_Elkins@NAI.com
電話：+1.310.737.1663ファックス：+1.310.737.1755電子メール：me@cs.hmc.edu、Michael_Elkins@NAI.com
Raph Levien University of California at Berkeley 579 Soda Hall Berkeley, CA 94720 USA
バークレー579ソーダホールバークレー、CA 94720 USAのカリフォルニアラフ・レビアン大学
Phone: +1.510.642.6509 EMail: raph@acm.org
電話：+1.510.642.6509電子メール：raph@acm.org
Thomas Roessler Nordstrasse 99 D-53111 Bonn, Germany
トーマスレスラーのNordstraße99 D-53111ボン、ドイツ
Phone: +49-228-638007 EMail: roessler@does-not-exist.org
電話：+ 49-228-638007 Eメール：roessler@does-not-exist.org
References
リファレンス
[1] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[1]カラス、J.、Donnerhacke、L.、フィニー、H.及びR.セイヤー、 "OpenPGPのメッセージフォーマット"、RFC 2440、1998年11月。
[2] Galvin, J., Murphy, G., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[2]ガルビン、J.、マーフィー、G.、クロッカー、S.およびN.フリードを、 "MIMEマルチパートのセキュリティは：マルチパート/署名およびマルチパート/暗号化"、RFC 1847、1995年10月。
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[3]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[4] Galvin, J., Murphy, G., Crocker, S. and N. Freed, "MIME Object Security Services", RFC 1848, October 1995.
[4]ガルビン、J.、マーフィー、G.、クロッカー、S.およびN.フリード、 "MIMEオブジェクトセキュリティサービス"、RFC 1848、1995年10月。
[5] Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, August 1996.
[5]アトキンス、D.、ストーリングス、W.およびP.ツィンマーマン、 "PGPメッセージ交換形式"、RFC 1991、1996年8月。
[6] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.
[6]エルキンズ、M.、 "プリティグッドプライバシーとMIMEセキュリティ（PGP）"、RFC 2015、1996年10月。
[7] Freed, N., "Gateways and MIME Security Multiparts", RFC 2480, January 1999.
[7]解放され、N.、 "ゲートウェイとMIMEセキュリティマルチパート"、RFC 2480、1999年1月。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。