RFC1848 日本語訳
1848 MIME Object Security Services. S. Crocker, N. Freed, J. Galvin,S. Murphy. October 1995. (Format: TXT=95010 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Crocker
Request For Comments: 1848 CyberCash, Inc.
Category: Standards Track N. Freed
Innosoft International, Inc.
J. Galvin
S. Murphy
Trusted Information Systems
October 1995
コメントを求めるワーキンググループS.医者要求をネットワークでつないでください: 1848年のサイバーキャッシュInc.カテゴリ: 解放された標準化過程の国際Inc.J.ガルビン・S.N.Innosoftマーフィーは1995年10月に情報システムを信じました。
MIME Object Security Services
MIMEオブジェクトセキュリティー・サービス
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 MIME Object Security Services (MOSS), a protocol that uses the multipart/signed and multipart/encrypted framework [7] to apply digital signature and encryption services to MIME objects. The services are offered through the use of end-to-end cryptography between an originator and a recipient at the application layer. Asymmetric (public key) cryptography is used in support of the digital signature service and encryption key management. Symmetric (secret key) cryptography is used in support of the encryption service. The procedures are intended to be compatible with a wide range of public key management approaches, including both ad hoc and certificate-based schemes. Mechanisms are provided to support many public key management approaches.
このドキュメントはMIME Object Security Services(モス)(デジタル署名と暗号化サービスをMIMEオブジェクトに適用するのに複合か署名されるのと複合の、または、暗号化されたフレームワーク[7]を使用するプロトコル)を定義します。 応用層で終わりから終わりへの暗号の使用で創始者と受取人の間にサービスを提供します。 非対称の(公開鍵)暗号はデジタル署名サービスと暗号化かぎ管理を支持して使用されます。 左右対称の(秘密鍵)暗号は暗号化サービスを支持して使用されます。 手順はさまざまな公開鍵マネージメント・アプローチと互換性があることを意図します、臨時のものと同様に証明書ベースの体系を含んでいて。 多くの公開鍵マネージメント・アプローチをサポートするためにメカニズムを提供します。
Table of Contents
目次
1. Introduction ............................................. 3 2. Applying MIME Object Security Services ................... 4 2.1 Digital Signature Service ............................... 4 2.1.1 Canonicalization ...................................... 5 2.1.2 Digital Signature Control Information ................. 7 2.1.2.1 Version: ............................................ 8 2.1.2.2 Originator-ID: ...................................... 8 2.1.2.3 MIC-Info: ........................................... 8 2.1.3 application/moss-signature Content Type Definition .... 9 2.1.4 Use of multipart/signed Content Type .................. 10 2.2 Encryption Service ...................................... 11
1. 序論… 3 2. MIMEオブジェクトセキュリティー・サービスを適用します… 4 2.1 デジタル署名サービス… 4 2.1 .1Canonicalization… 5 2.1 .2 デジタル署名制御情報… 7 2.1 .2 .1バージョン: ............................................ 8 2.1.2.2創始者ID: ...................................... 8 2.1 .2 .3MIC-インフォメーション: ........................................... 8 2.1 .3 こけアプリケーション/署名Content Type Definition… 9 2.1 .4 複合の、または、署名しているContent Typeの使用… 10 2.2 暗号化サービス… 11
Crocker, et al Standards Track [Page 1] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[1ページ]RFC1848のMIME Object Security Services1995年10月
2.2.1 Encryption Control Information ........................ 12
2.2.1.1 DEK-Info: ........................................... 13
2.2.1.2 Recipient-ID: ....................................... 14
2.2.1.3 Key-Info: ........................................... 14
2.2.2 application/moss-keys Content Type Definition ......... 15
2.2.3 Use of multipart/encrypted Content Type ............... 16
3. Removing MIME Object Security Services ................... 17
3.1 Digital Signature Service ............................... 18
3.1.1 Preparation ........................................... 18
3.1.2 Verification .......................................... 19
3.1.3 Results ............................................... 19
3.2 Encryption Service ...................................... 20
3.2.1 Preparation ........................................... 20
3.2.2 Decryption ............................................ 20
3.2.3 Results ............................................... 21
4. Identifying Originators, Recipients, and Their Keys ...... 21
4.1 Name Forms .............................................. 23
4.1.1 Email Addresses ....................................... 23
4.1.2 Arbitrary Strings ..................................... 23
4.1.3 Distinguished Names ................................... 23
4.2 Identifiers ............................................. 24
4.2.1 Email Address ......................................... 25
4.2.2 Arbitrary String ...................................... 25
4.2.3 Distinguished Name .................................... 26
4.2.4 Public Key ............................................ 26
4.2.5 Issuer Name and Serial Number ......................... 27
5. Key Management Content Types ............................. 27
5.1 application/mosskey-request Content Type Definition ..... 28
5.2 application/mosskey-data Content Type Definition ........ 29
6. Examples ................................................. 31
6.1 Original Message Prepared for Protection ................ 31
6.2 Sign Text of Original Message ........................... 32
6.3 Sign Headers and Text of Original Message ............... 32
6.4 Encrypt Text of a Message ............................... 33
6.5 Encrypt the Signed Text of a Message .................... 35
6.6 Protecting Audio Content ................................ 37
6.6.1 Sign Audio Content .................................... 37
6.6.2 Encrypt Audio Content ................................. 37
7. Observations ............................................. 38
8. Comparison of MOSS and PEM Protocols ..................... 39
9. Security Considerations .................................. 41
10. Acknowledgements ........................................ 41
11. References .............................................. 41
12. Authors' Addresses ...................................... 43
Appendix A: Collected Grammar .............................. 44
Appendix B: Imported Grammar ............................... 47
2.2.1 暗号化制御情報… 12 2.2 .1 .1DEK-インフォメーション: ........................................... 13 2.2.1.2受取人ID: ....................................... 14 2.2 .1 .3 主要なインフォメーション: ........................................... 14 2.2 .2 こけアプリケーション/キーContent Type Definition… 15 2.2 .3 複合の、または、暗号化されたContent Typeの使用… 16 3. MIMEオブジェクトセキュリティー・サービスを取り除きます… 17 3.1 デジタル署名サービス… 18 3.1 .1準備… 18 3.1 .2検証… 19 3.1 .3 なります… 19 3.2 暗号化サービス… 20 3.2 .1準備… 20 3.2 .2復号化… 20 3.2 .3 なります… 21 4. 創始者、受取人、および彼らのキーを特定します… 21 4.1 フォームを命名してください… 23 4.1 .1のEメールアドレス… 23 4.1 .2 任意のストリング… 23 4.1 .3の分類名… 23 4.2の識別子… 24 4.2 .1Eメールアドレス… 25 4.2 .2の任意のストリング… 25 4.2 .3分類名… 26 4.2 .4公開鍵… 26 4.2 .5の発行人名と通し番号… 27 5. Key Management content type… 27 5.1 mosskeyアプリケーション/要求Content Type Definition… 28 5.2 mosskeyアプリケーション/データContent Type Definition… 29 6. 例… 31 6.1のオリジナルのメッセージは保護の用意をしました… 31 6.2 オリジナルのメッセージのテキストに署名してください… 32 6.3 オリジナルのメッセージのヘッダーとテキストに署名してください… 32 6.4 メッセージのテキストを暗号化してください… 33 6.5 メッセージの署名しているテキストを暗号化してください… 35 6.6 オーディオ内容を保護します… 37 6.6 .1 オーディオ内容に署名してください… 37 6.6 .2 オーディオ内容を暗号化してください… 37 7. 観測… 38 8. こけとPEMプロトコルの比較… 39 9. セキュリティ問題… 41 10. 承認… 41 11. 参照… 41 12. 作者のアドレス… 43 付録A: 文法を集めます… 44 付録B: 文法であるとインポートされます… 47
Crocker, et al Standards Track [Page 2] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[2ページ]RFC1848のMIME Object Security Services1995年10月
1. Introduction
1. 序論
MIME [2], 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. 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. MIME does not provide for the application of security services.
MIME[2](「マルチパーパスインターネットメールエクステンション」のための頭文字語)は、インターネットメール・メッセージのコンテンツの書式を定義して、複合原文の、そして、非原文のメッセージ本体に備えます。 インターネット電子メールメッセージは2つの部品から成ります: ヘッダーとボディー。 ヘッダーはSTD11によると、構造化された分野/値の組の収集を形成します、RFC822[1]、構造化されるなら、MIMEに従って、ボディーが定義されますが。 MIMEはセキュリティー・サービスの応用に備えません。
PEM [3-6], an acronym for "Privacy Enhanced Mail", defines message encryption and message authentication procedures for text-based electronic mail messages using a certificate-based key management mechanism. The specifications include several features that are easily and more naturally supported by MIME, for example, the transfer encoding operation, the Content-Domain header, and the support services specified by its Part IV [6]. The specification is limited by specifying the application of security services to text messages only.
PEM[3-6](「プライバシーはメールを高めた」頭文字語)は、テキストベースの電子メールメッセージのために証明書ベースのかぎ管理メカニズムを使用することでメッセージ暗号化と通報認証手順を定義します。 仕様はMIMEによって簡単により自然にサポートされるいくつかの特徴を含んでいます、と例えば、操作をコード化する転送、Content-ドメインヘッダー、および支援活動はPart IV[6]で指定しました。 仕様は、テキスト・メッセージだけへのセキュリティー・サービスの応用を指定することによって、制限されます。
MOSS is based in large part on the PEM protocol as defined by RFC 1421. Many of PEMs features and most of its protocol specification are included here. A comparison of MOSS and PEM may be found in Section 8.
RFC1421によって定義されるようにモスは主にPEMプロトコルに基づいています。 PEMsの特徴の多く、プロトコル仕様の大部分はここに含まれています。 モスとPEMの比較はセクション8で見つけられるかもしれません。
In order to make use of the MOSS services, a user (where user is not limited to being a human, e.g., it could be a process or a role) is required to have at least one public/private key pair. The public key must be made available to other users with whom secure communication is desired. The private key must not be disclosed to any other user.
モスサービスを利用するために、ユーザ(例えば、それは、そこのユーザが人間に制限されないか、プロセスか役割であるかもしれない)が少なくとも1公衆/秘密鍵組があるのに必要です。 公開鍵を安全なコミュニケーションが望まれている他のユーザにとって利用可能にしなければなりません。 いかなる他のユーザにも秘密鍵を明らかにしてはいけません。
An originator's private key is used to digitally sign MIME objects; a recipient would use the originator's public key to verify the digital signature. A recipient's public key is used to encrypt the data encrypting key that is used to encrypt the MIME object; a recipient would use the corresponding private key to decrypt the data encrypting key so that the MIME object can be decrypted.
創始者の秘密鍵はMIMEがオブジェクトであるとデジタルに署名するのに使用されます。 受取人は、デジタル署名について確かめるのに創始者の公開鍵を使用するでしょう。 受取人の公開鍵はMIMEオブジェクトを暗号化するのに使用されるキーを暗号化しながらデータを暗号化するのに使用されます。 受取人は、MIMEオブジェクトを解読することができるようにキーを暗号化するデータを解読するのに対応する秘密鍵を使用するでしょう。
As long as the private keys are protected from disclosure, i.e., the private keys are accessible only to the user to whom they have been assigned, the recipient of a digitally signed message will know from whom the message was sent and the originator of an encrypted message will know that only the intended recipient is able to read it. For assurance, the ownership of the public keys used in verifying digital signatures and encrypting messages should be verified. A stored public key should be protected from modification.
公開から保護される限り、それらが割り当てられたユーザだけに、すなわち、秘密鍵はアクセスしやすいです、とデジタルに署名しているメッセージの受取人はだれがメッセージを送ったかから知るでしょう、そして、暗号化メッセージの創始者は意図している受取人だけがそれを読むことができるのを知るでしょう。 保証のために、デジタル署名について確かめて、メッセージを暗号化する際に使用される公開鍵の所有権は確かめられるべきです。 保存された公開鍵は変更から保護されるべきです。
Crocker, et al Standards Track [Page 3] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[3ページ]RFC1848のMIME Object Security Services1995年10月
The framework defined in [7] provides an embodiment of a MIME object and its digital signature or encryption keys. When used by MOSS the framework provides digital signature and encryption services to single and multi-part textual and non-textual MIME objects.
[7]で定義されたフレームワークはそのMIMEオブジェクトとデジタル署名か暗号化キーの具体化を提供します。 モスによって使用されると、フレームワークはデジタル署名と単一の、そして、複合の原文の、そして、非原文のMIMEオブジェクトに対する暗号化サービスを提供します。
2. Applying MIME Object Security Services
2. MIMEオブジェクトセキュリティー・サービスを適用します。
The application of the MOSS digital signature service requires the following components.
モスデジタル署名サービスの応用は以下のコンポーネントを必要とします。
(1) The data to be signed.
(1) 署名されるデータ。
(2) The private key of the originator.
(2) 創始者の秘密鍵。
The data to be signed is prepared according to the description below. The digital signature is created by generating a hash of the data and encrypting the hash value with the private key of the originator. The digital signature, some additional ancillary information described below, and the data are then embodied in a multipart/signed body part. Finally, the multipart/signed body part may be transferred to a recipient or processed further, for example, it may be encrypted.
以下での記述によると、署名されるデータは準備されます。 デジタル署名は、データのハッシュを生成して、創始者の秘密鍵でハッシュ値を暗号化することによって、作成されます。 そして、デジタル署名、以下で説明された、何らかの追加補助的情報、およびデータは複合の、または、署名している身体の部分に表現されます。 最終的に、複合の、または、署名している身体の部分を受取人に移すか、またはさらに処理するかもしれません、例えば、それを暗号化するかもしれません。
The application of the MOSS encryption service requires the following components.
モス暗号化サービスの応用は以下のコンポーネントを必要とします。
(1) The data to be encrypted.
(1) 暗号化されるべきデータ。
(2) A data encrypting key to encrypt the data.
(2) データを暗号化するデータ暗号化キー。
(3) The public key of the recipient.
(3) 受取人の公開鍵。
The data to be encrypted is prepared according to the description below. The originator creates a data encrypting key and encrypts the data. The recipient's public key is used to encrypt the data encrypting key. The encrypted data, the encrypted data encrypting key, and some additional ancillary information described below are then embodied in a multipart/encrypted body part, ready to be transferred to a recipient or processed further, for example, it may be signed.
以下での記述によると、暗号化されるべきデータは準備されます。 創始者は、データ暗号化キーを作成して、データを暗号化します。 受取人の公開鍵は、キーを暗号化しながらデータを暗号化するのに使用されます。 次に、暗号化されたデータ、キーを暗号化する暗号化されたデータ、および以下で説明された何らかの追加補助的情報が複合の、または、暗号化された身体の部分に表現されます、受取人に移す準備ができているか、またはさらに処理する準備ができていて、例えば、それに署名するかもしれません。
The next two sections describe the digital signature and encryption services, respectively, in detail.
次の2つのセクションがそれぞれ詳細にデジタル署名と暗号化サービスについて説明します。
2.1. Digital Signature Service
2.1. デジタル署名サービス
The MOSS digital signature service is applied to MIME objects, specifically a MIME body part. The MIME body part is created
モスデジタル署名サービスはMIMEオブジェクト、明確にMIME身体の部分に適用されます。 MIME身体の部分は作成されます。
Crocker, et al Standards Track [Page 4] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[4ページ]RFC1848のMIME Object Security Services1995年10月
according to a local convention and then made available to the digital signature service.
地方のコンベンションとデジタル署名サービスが入手したその時に従って。
The following sequence of steps comprises the application of the digital signature service.
ステップの以下の系列はデジタル署名サービスの応用を包括します。
(1) The body part to be signed must be canonicalized.
(1) 署名される身体の部分をcanonicalizedしなければなりません。
(2) The digital signature and other control information must be gen-
erated.
(2) デジタル署名と他の制御情報はeratedされていた状態で情報を得ることであるに違いありません。
(3) The control information must be embodied in an appropriate MIME
content type.
(3) 適切なMIME content typeに制御情報を表現しなければなりません。
(4) The control information body part and the data body part must be
embodied in a multipart/signed content type.
(4) 制御情報身体の部分とデータ身体の部分を複合の、または、署名しているcontent typeに表現しなければなりません。
Each of these steps is described below.
それぞれのこれらのステップは以下で説明されます。
2.1.1. Canonicalization
2.1.1. Canonicalization
The body part must be converted to a canonical form that is uniquely and unambiguously representable in at least the environment where the digital signature is created and the environment where the digital signature will be verified, i.e., the originator and recipient's environment, respectively. This is required in order to ensure that both the originator and recipient have the same data with which to calculate the digital signature; the originator needs to be able to create the digital signature value while the recipient needs to be able to compare a re-computed value with the received value. If the canonical form is representable on many different host computers, the signed data may be forwarded by recipients to additional recipients, who will also be able to verify the original signature. This service is called forwardable authentication.
身体の部分は、唯一そうである標準形に変換されて、少なくともデジタル署名が作成される環境とすなわち、デジタル署名が確かめられる環境、創始者と受取人の環境で明白にそれぞれ「表-可能」されなければなりません。 これが創始者と受取人の両方にはデジタル署名について計算するのと同じデータがあるのを確実にするのに必要です。 創始者は、受取人が、再計算された値を容認された値と比べることができる必要がある間、デジタル署名値を作成できる必要があります。 標準形が多くの異なったホストコンピュータで「表-可能」であるなら、署名しているデータは受取人によって追加受取人に転送されるかもしれません。(また、その受取人は、オリジナルの署名について確かめることができるでしょう)。 このサービスは前進可能認証と呼ばれます。
The canonicalization transformation is a two step process. First, the body part must be converted to a form that is unambiguously representable on as many different host computers as possible. Second, the body part must have its line delimiters converted to a unique and unambiguous representation.
canonicalization変換はツーステッププロセスです。 まず最初に、できるだけ多くの異なったホストコンピュータで明白に「表-可能」なフォームに身体の部分を変換しなければなりません。 2番目に、身体の部分で、ユニークで明白な表現に系列デリミタを変換しなければなりません。
The representation chosen to satisfy the first step is 7bit, as defined by MIME; the high order bit of each octet of the data to be
第一歩を満たすために選ばれた表現はMIMEによって定義されるように7ビットです。 オーダーがデータの各八重奏に噛み付いた高値
Crocker, et al Standards Track [Page 5] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[5ページ]RFC1848のMIME Object Security Services1995年10月
signed must be zero. A MIME body part is comprised of two parts: headers and content. Since the headers of body parts are already required to be represented in 7bit, this step does not require changes to the headers. This step requires that if the content is not already 7bit then it must be encoded with an appropriate MIME content transfer encoding and a Content-Transfer-Encoding: header must be added to the headers. For example, if the content to be signed contains 8bit or binary data, the content must be encoded with either the quoted-printable or base64 encoding as defined by MIME.
署名されているのは、ゼロであるに違いありません。 MIME身体の部分は2つの部品から成ります: ヘッダーと内容。 7ビットに身体の部分のヘッダーによって既に表されなければならないので、このステップはヘッダーへの変化を必要としません。 このステップは、内容が既に7ビットでないならMIMEの適切な内容転送コード化とContent転送コード化でそれをコード化しなければならないのを必要とします: ヘッダーにヘッダーを加えなければなりません。 例えば、署名される内容が8のビットかバイナリ・データを含んでいるなら、MIMEによって定義されるように引用されて印刷可能であるかbase64コード化で内容をコード化しなければなりません。
IMPLEMENTORS NOTE: Since the MIME standard explicitly disallows
nested content transfer encodings, i.e., the content types
multipart and message may not themselves be encoded, the 7bit
transformation requires each nested body part to be individually
encoded in a 7bit representation. Any valid MIME encoding, e.g.,
quoted-printable or base64, may be used and, in fact, a different
encoding may be used on each of the non-7bit body parts.
作成者は以下に注意します。 メッセージは必要であるかもしれません。そして、MIME規格が明らかに入れ子にされた内容を禁じるので、転送はencodingsされます、すなわち、content type、複合、自分たちがコード化されるというわけではなくて、7ビットの変換が、それぞれの入れ子にされた身体の部分が7ビットの表現で個別にコード化されるのを必要とします。 印刷可能な状態で引用されて、例えばコード化されるどんな有効なMIMEかbase64、使用されるかもしれなくても、事実上、異なったコード化はそれぞれの非7に噛み付いている身体の部分の上で使用されるかもしれません。
Representing all content types in a 7bit format transforms them into text-based content types. However, text-based content types present a unique problem. In particular, the line delimiter used for a text-based content type is specific to a local environment; different environments use the single character carriage-return (<CR>), the single character line-feed (<LF>), or the two character sequence "carriage-return line-feed (<CR><LF>)".
7ビットの形式ですべてのcontent typeを表すと、それらはテキストベースのcontent typeに変えられます。 しかしながら、テキストベースのcontent typeはユニークな問題を提示します。 テキストベースのcontent typeに使用される系列デリミタは地方の環境に特に、特定です。 異なった環境はただ一つのキャラクタ復帰(<CR>)、ただ一つのキャラクタ改行(<LF>)、または2キャラクタシーケンス「復帰改行(<CR><LF>)」を使用します。
The application of the digital signature service requires that the same line delimiter be used by both the originator and the recipient. This document specifies that the two character sequence "<CR><LF>" must be used as the line delimiter. Thus, the second step of the canonicalization transformation includes the conversion of the local line delimiter to the two character sequence "<CR><LF>".
デジタル署名サービスの応用は、同じ系列デリミタが創始者と受取人の両方によって使用されるのを必要とします。 このドキュメントは、系列デリミタとして2キャラクタシーケンス「<CR><LF>」を使用しなければならないと指定します。 したがって、canonicalization変換の第2ステップは2キャラクタシーケンス「<CR><LF>」にローカル線デリミタの変換を含んでいます。
The conversion to the canonical line delimiter is only required for the purposes of computing the digital signature. Thus, originators must apply the line delimiter conversion before computing the digital signature but must transfer the data without the line delimiter conversion. Similarly, recipients must apply the line delimiter conversion before computing the digital signature.
正準な系列デリミタへの変換がデジタル署名を計算する目的に必要であるだけです。 したがって、創始者は、デジタル署名を計算する前に、系列デリミタ変換を適用しなければなりませんが、系列デリミタ変換なしでデータを移さなければなりません。 同様に、デジタル署名を計算する前に、受取人は系列デリミタ変換を適用しなければなりません。
NOTE: An originator can not transfer the content with the line
delimiter conversion intact because the conversion process is not
idempotent. In particular, SMTP servers may themselves convert
the line delimiter to a local line delimiter, prior to the message
being delivered to the recipient. Thus, a recipient has no way of
knowing if the conversion is present or not. If the recipient
applies the conversion to a content in which it is already
present, the resulting content may have two line delimiters
以下に注意してください。 変換プロセスがベキ等元でないので、系列デリミタ変換が完全な状態で創始者は内容を移すことができません。 自分たちに系列デリミタをローカル線デリミタに変換して、メッセージの前に送って、特に、SMTPサーバーはそうするかもしれません。受取人。 したがって、受取人には、変換が存在しているかどうかを知る方法が全くありません。 受取人がそれが既に存在している内容に変換を適用するなら、結果として起こる内容には、2つの系列デリミタがあるかもしれません。
Crocker, et al Standards Track [Page 6] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[6ページ]RFC1848のMIME Object Security Services1995年10月
present, which would cause the verification of the signature to
fail.
プレゼント。(そのプレゼントは署名の検証に失敗されるでしょう)。
IMPLEMENTORS NOTE: Implementors should be aware that the
conversion to a 7bit representation is a function that is required
in a minimally compliant MIME user agent. Further, the line
delimiter conversion required here is distinct from the same
conversion included in that function. Specifically, the line
delimiter conversion applied when a body part is converted to a
7bit representation (transfer encoded) is performed prior to the
application of the transfer encoding. The line delimiter
conversion applied when a body part is signed is performed after
the body part is converted to 7bit (transfer encoded). Both line
delimiter conversions are required.
作成者は以下に注意します。 作成者は7ビットの表現への変換が最少量で言いなりになっているMIMEユーザエージェントで必要である機能であることを意識しているべきです。 さらに、ここで必要であった系列デリミタ変換はその機能に同じ変換を含むのと異なっています。 明確に、身体の部分が7ビットの表現(コード化された転送)に変換されるとき適用された系列デリミタ変換は転送コード化のアプリケーションの前に実行されます。 身体の部分が7ビット(コード化された転送)に変換された後に身体の部分が署名されるとき適用された系列デリミタ変換は実行されます。 両方の系列デリミタ変換が必要です。
2.1.2. Digital Signature Control Information
2.1.2. デジタル署名制御情報
The application of the digital signature service generates control information which includes the digital signature itself. The syntax of the control information is that of a set of RFC 822 headers, except that the folding of header values onto continuation lines is explicitly forbidden. Each header and value pair generated by the digital signature service must be output on exactly one line.
デジタル署名サービスの応用は、コントロールがデジタル署名自体を含んでいる情報であると生成します。 制御情報の構文はRFCの1セットのものです。ヘッダー値の継続行への折り重なりが明らかに禁じられるのを除いた822個のヘッダー。 まさに1つの系列でデジタル署名サービスで生成されたそれぞれのヘッダーと値の組を出力しなければなりません。
The complete set of headers generated by the digital signature service is as follows.
デジタル署名サービスで生成された完全なセットのヘッダーは以下の通りです。
Version:
indicates which version of the MOSS protocol the remaining headers
represent.
バージョン: 残っているヘッダーがモスプロトコルのどのバージョンを表すかを示します。
Originator-ID:
indicates the private key used to create the digital signature and
the corresponding public key to be used to verify it.
創始者ID: 秘密鍵がそれについて確かめるのに使用されるために以前はよくデジタル署名と対応する公開鍵を作成していたのを示します。
MIC-Info:
contains the digital signature value.
MIC-インフォメーション: デジタル署名値を含んでいます。
Each invocation of the digital signature service must emit exactly one Version: header and at least one pair of Originator-ID: and MIC- Info: headers. The Version: header must always be emitted first. The Originator-ID: and MIC-Info: headers are always emitted in pairs in the order indicated. This specification allows an originator to generate multiple signatures of the data, presumably with different signature algorithms, and to include them all in the control information. The interpretation of the presence of multiple signatures is outside the scope of this specification except that a MIC-Info: header is always interpreted in the context of the
各デジタル署名サービスの実施はまさに1つのバージョンを放たなければなりません: Originator-IDのヘッダーと少なくとも1組: MICインフォメーション: ヘッダー。 バージョン: 最初に、いつもヘッダーを放たなければなりません。 創始者ID: MIC-インフォメーション: ヘッダーは指示された順番で組でいつも放たれています。 この仕様で、創始者は、データと、おそらく異なった署名アルゴリズムで複数の署名を生成して、制御情報でそれらを皆、入れます。 この仕様の範囲の外にそのa MIC-インフォメーションを除いて、複数の署名の存在の解釈があります: ヘッダーは文脈でいつも解釈されます。
Crocker, et al Standards Track [Page 7] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[7ページ]RFC1848のMIME Object Security Services1995年10月
immediately preceding Originator-ID: header.
すぐに前のOriginator-ID: ヘッダー。
2.1.2.1. Version:
2.1.2.1. バージョン:
The version header is defined by the grammar token <version> as follows.
バージョンヘッダーは以下の文法トークン<バージョン>によって定義されます。
<version> ::= "Version:" "5" CRLF
<バージョン>:、:= 「バージョン:」 「5インチのCRLF」
Its value is constant and MOSS implementations compliant with this specification must recognize only this value and generate an error if any other value is found.
値が一定であり、他の値が見つけられるなら、この仕様による対応することのモス実装は、この値だけを認識して、エラーを起こさなければなりません。
2.1.2.2. Originator-ID:
2.1.2.2. 創始者ID:
The purpose of the originator header is two-fold: to directly identify the public key to be used to verify the digital signature and to indirectly identify the user who owns both it and its corresponding private key. Typically, a recipient is less interested in the actual public key value, although obviously the recipient needs the value to verify the signature, and more interested in identifying its owner. Thus, the originator header may convey either or both pieces of information:
創始者ヘッダーの目的は二面です: デジタル署名について確かめて、間接的にそれとその対応する秘密鍵の両方を所有しているユーザを特定するのに使用されるために直接公開鍵を特定するために。 通常、受取人は、受取人が署名について確かめるために明らかに値を必要としますが、それほど実際の公開鍵値に興味を持っていなくて、所有者をさらに特定したがっています。 したがって、創始者ヘッダーはどちらかか両方の情報を伝えるかもしれません:
the public key to be used to verify the signature
署名について確かめるのに使用されるべき公開鍵
the name of the owner and which of the owner's public keys to use
to verify the signature
所有者の名前と署名について確かめるのに所有者の公開鍵のどれを使用したらよいですか。
The decision as to what information to place in the value rests entirely with the originator. The suggested value is to include both. Recipients with whom the originator has previously communicated will have to verify that the information presented is consistent with what is already known. New recipients will want all of the information, which they will need to verify prior to storing in their local database.
どんな情報を値に置いたらよいかに関する決定は創始者に完全に責任があります。 提案された値は両方を含むことです。 以前に創始者と交信した受取人は、提示された情報が既に知られていることと一致していることを確かめなければならないでしょう。 新しい受取人は情報のすべてが欲しくなるでしょう。(彼らは情報が地元のデータベースにおける保存の前に確かめる必要があります)。
The originator header is defined by the grammar token <origid> as follows.
創始者ヘッダーは以下の文法トークン<origid>によって定義されます。
<origid> ::= "Originator-ID:" <id> CRLF
<origid>:、:= 「創始者ID:」 <イド>CRLF
The grammar token <id> is defined in Section 4.
文法トークン<イド>はセクション4で定義されます。
2.1.2.3. MIC-Info:
2.1.2.3. MIC-インフォメーション:
The purpose of the Message Integrity Check (MIC) header is to convey the digital signature value. Its value is a comma separated list of
Message Integrity Check(MIC)ヘッダーの目的はデジタル署名値を伝えることです。 値はコンマの切り離されたリストです。
Crocker, et al Standards Track [Page 8] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[8ページ]RFC1848のMIME Object Security Services1995年10月
three arguments: the hash (or MIC) algorithm identifier, the signature algorithm identifier, and the digital signature.
3つの議論: ハッシュ(または、MIC)アルゴリズム識別子、署名アルゴリズム識別子、およびデジタル署名。
The MIC header is defined by the grammar token <micinfo> as follows.
MICヘッダーは以下の文法トークン<micinfo>によって定義されます。
<micinfo> ::= "MIC-Info:" <micalgid> "," <ikalgid> ","
<asymsignmic> CRLF
<micinfo>:、:= 「MIC-インフォメーション:」 」 「<micalgid>」、<ikalgid>、」、」 <asymsignmic>CRLF
The grammar tokens for the MIC algorithms and identifiers (<micalgid>), signature algorithms and identifiers (<ikalgid>), and signed MIC formats (<asymsignmic>) are defined by RFC 1423. They are also reprinted in Appendix B.
MICアルゴリズムと識別子のための文法トークン(<micalgid>)、署名アルゴリズム、識別子(<ikalgid>)、および署名しているMIC書式はRFC1423によって定義されます(<asymsignmic>)。 また、それらはAppendix Bで増刷されます。
IMPLEMENTORS NOTE: RFC 1423 is referenced by the PEM protocol,
which includes support for symmetric signatures and key
management. As a result, some of the grammar tokens defined
there, for example, <ikalgid>, will include options that are not
legal for this protocol. These options must be ignored and have
not been included in the appendix.
作成者は以下に注意します。 RFC1423はPEMプロトコルによって参照をつけられます。(それは、左右対称の署名とかぎ管理のサポートを含んでいます)。 その結果、そこで定義された文法トークンのいくつか(例えば、<ikalgid>)がこのプロトコルには、法的でないオプションを含むでしょう。 これらのオプションを、無視して、付録に含んでいてはいけません。
2.1.3. application/moss-signature Content Type Definition
2.1.3. こけアプリケーション/署名Content Type Definition
(1) MIME type name: application
(1) MIMEの種類名: アプリケーション
(2) MIME subtype name: moss-signature
(2) MIME「副-タイプ」は以下を命名します。 こけ署名
(3) Required parameters: none
(3) 必要なパラメタ: なし
(4) Optional parameters: none
(4)の任意のパラメタ: なし
(5) Encoding considerations: quoted-printable is always sufficient
(5) 問題をコード化します: いつも引用されて印刷可能であるのが、そうである、十分
(6) Security considerations: none
(6) セキュリティ問題: なし
The "application/moss-signature" content type is used on the second body part of an enclosing multipart/signed. Its content is comprised of the digital signature of the data in the first body part of the enclosing multipart/signed and other control information required to verify that signature, as defined by Section 2.1.2. The label "application/moss-signature" must be used as the value of the protocol parameter of the enclosing multipart/signed; the protocol parameter must be present.
「こけアプリケーション/署名」content typeは同封の2番目の身体の部分の上で複合か署名された状態で使用されます。 内容は複合か署名された状態で同封の最初の身体の部分でのデータのデジタル署名から成ります、そして、他の制御情報がその署名について確かめるのが必要です、セクション2.1.2で定義されるように。 同封のプロトコルパラメタの値として複合か署名された状態でラベル「こけアプリケーション/署名」を使用しなければなりません。 プロトコルパラメタは存在していなければなりません。
Part of the signature verification information will be the Message Integrity Check (MIC) algorithm(s) used during the signature creation process. The MIC algorithm(s) identified in this body part must match the MIC algorithm(s) identified in the micalg parameter of the enclosing multipart/signed. If it does (they do) not, a user agent
署名照合情報の一部が署名作成プロセスの間に使用されるMessage Integrity Check(MIC)アルゴリズムになるでしょう。 この身体の部分で特定されたMICアルゴリズムは同封のmicalgパラメタで複合か署名された状態で特定されたMICアルゴリズムに合わなければなりません。 そうする、(それらはそうします)ユーザエージェント
Crocker, et al Standards Track [Page 9] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[9ページ]RFC1848のMIME Object Security Services1995年10月
should identify the discrepancy to a user and it may choose to either halt or continue processing, giving precedence to the algorithm(s) identified in this body part.
ユーザに食い違いを特定するべきであり、停止するか、または処理し続けているのを選ぶかもしれません、この身体の部分で特定されたアルゴリズムに優先権を与えて。
An application/moss-signature body part is constructed as follows:
こけアプリケーション/署名身体の部分は以下の通り構成されます:
Content-Type: application/moss-signature
コンテントタイプ: こけアプリケーション/署名
<mosssig>
<mosssig>。
where the grammar token <mosssig> is defined as follows.
文法トークン<mosssig>が以下の通り定義されるところ。
<mosssig> ::= <version> ( 1*<origasymflds> )
<mosssig>:、:= <バージョン>。(1*<origasymflds>)
<version> ::= "Version:" "5" CRLF
<バージョン>:、:= 「バージョン:」 「5インチのCRLF」
<origasymflds> ::= <origid> <micinfo>
<origasymflds>:、:= <origid><micinfo>。
<origid> ::= "Originator-ID:" <id> CRLF
<origid>:、:= 「創始者ID:」 <イド>CRLF
<micinfo> ::= "MIC-Info:" <micalgid> "," <ikalgid> ","
<asymsignmic> CRLF
<micinfo>:、:= 「MIC-インフォメーション:」 」 「<micalgid>」、<ikalgid>、」、」 <asymsignmic>CRLF
The token <id> is defined in Section 4. All other tokens are defined in Section 2.1.2.3.
トークン<イド>はセクション4で定義されます。 他のすべてのトークンがセクション2.1.2で.3に定義されます。
2.1.4. Use of multipart/signed Content Type
2.1.4. 複合の、または、署名しているContent Typeの使用
The definition of the multipart/signed content type in [7] specifies three steps for creating the body part.
[7]との複合の、または、署名しているcontent typeの定義は身体の部分を作成するための3ステップを指定します。
(1) The body part to be digitally signed is created according to a
local convention, for example, with a text editor or a mail user
agent.
(1) 例えば、地方のコンベンションによると、デジタルに署名される身体の部分はテキストエディタかメールユーザエージェントと共に作成されます。
(2) The body part is prepared for the digital signature service
according to the protocol parameter, in this case according to
Section 2.1.1.
(2) プロトコルパラメタによると、身体の部分はこの場合デジタル署名サービスのためにセクション2.1.1で準備されます。
(3) The prepared body part is digitally signed according to the
protocol parameter, in this case according to Section 2.1.2.
(3) プロトコルパラメタによると、この場合セクション2.1.2で準備された身体の部分にデジタルに署名します。
The multipart/signed content type is constructed as follows.
複合の、または、署名しているcontent typeは以下の通り構成されます。
Crocker, et al Standards Track [Page 10] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[10ページ]RFC1848のMIME Object Security Services1995年10月
(1) The value of its required parameter "protocol" is set to
"application/moss-signature".
(1) 「プロトコル」という必要なパラメタの値は「こけアプリケーション/署名」に設定されます。
(2) The signed body part becomes its first body part.
(2) 署名している身体の部分は最初の身体の部分になります。
(3) Its second body part is labeled "application/moss-signature" and
is filled with the control information generated by the digital
signature service.
(3) 2番目の身体の部分は、「こけアプリケーション/署名」とラベルされて、デジタル署名サービスで生成された制御情報で満たされます。
(4) The value of its required parameter "micalg" is set to the same
value used in the MIC-Info: header in the control information.
If there is more than one MIC-Info: header present the value is
set to a comma separated list of values from the MIC-Info
headers. The interpretation of the order of the list of values
is outside the scope of this specification.
(4) "micalg"という必要なパラメタの値はMIC-インフォメーションで使用される同じ値に設定されます: 制御情報のヘッダー。 1つ以上のMIC-インフォメーションがあれば: ヘッダーは値を提示します。MIC-インフォメーションヘッダーからの値のコンマの切り離されたリストに設定されます。 この仕様の範囲の外に値のリストの注文の解釈があります。
A multipart/signed content type with the MOSS protocol might look as follows:
モスプロトコルがある複合の、または、署名しているcontent typeは以下の通りに見えるかもしれません:
Content-Type: multipart/signed;
protocol="application/moss-signature";
micalg="rsa-md5"; boundary="Signed Message"
コンテントタイプ: 複合か署名される。 =「こけアプリケーション/署名」について議定書の中で述べてください。 micalgは"rsa-md5""と等しいです。 「メッセージであると署名される」境界=
--Signed Message
Content-Type: text/plain
--署名しているメッセージコンテントタイプ: テキスト/平野
This is some example text.
これは何らかの例のテキストです。
--Signed Message
Content-Type: application/moss-signature
--署名しているメッセージコンテントタイプ: こけアプリケーション/署名
Version: 5
Originator-ID: ID-INFORMATION
MIC-Info: RSA-MD5,RSA,SIGNATURE-INFORMATION
--Signed Message--
バージョン: 5創始者ID: ID-情報MIC-インフォメーション: RSA-MD5、RSA、署名情報--メッセージであると署名されます--
where ID-INFORMATION and SIGNATURE-INFORMATION are descriptive of the content that would appear in a real body part.
ID-情報とSIGNATURE-情報が内容で描写的であるところに、それは本当の身体の部分に現れるでしょう。
2.2. Encryption Service
2.2. 暗号化サービス
The MOSS encryption service is applied to MIME objects, specifically a MIME body part. The MIME body part is created according to a local convention and then made available to the encryption service.
モス暗号化サービスはMIMEオブジェクト、明確にMIME身体の部分に適用されます。 MIME身体の部分を地方のコンベンションに従って作成されて、そして、暗号化サービスは入手します。
Crocker, et al Standards Track [Page 11] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[11ページ]RFC1848のMIME Object Security Services1995年10月
The following sequence of steps comprises the application of the encryption service.
ステップの以下の系列は暗号化サービスの応用を包括します。
(1) The body part to be encrypted must be in MIME canonical form.
(1) 暗号化されるべき身体の部分がMIME標準形にあるに違いありません。
(2) The data encrypting key and other control information must be
generated.
(2) 主要で他の制御情報を暗号化するデータを生成しなければなりません。
(3) The control information must be embodied in an appropriate MIME
content type.
(3) 適切なMIME content typeに制御情報を表現しなければなりません。
(4) The control information body part and the encrypted data body
part must be embodied in a multipart/encrypted content type.
(4) 制御情報身体の部分と暗号化されたデータ身体の部分を複合の、または、暗号化されたcontent typeに表現しなければなりません。
The first step is defined by MIME. The latter three steps are described below.
第一歩はMIMEによって定義されます。 後者の3ステップは以下で説明されます。
2.2.1. Encryption Control Information
2.2.1. 暗号化制御情報
The application of the encryption service generates control information which includes the data encrypting key used to encrypt the data itself. The syntax of the control information is that of a set of RFC 822 headers, except that the folding of header values onto continuation lines is explicitly forbidden. Each header and value pair generated by the encryption service must be output on exactly one line.
暗号化サービスの応用は、コントロールがデータ自体を暗号化するのに使用されるキーを暗号化するデータを含んでいる情報であると生成します。 制御情報の構文はRFCの1セットのものです。ヘッダー値の継続行への折り重なりが明らかに禁じられるのを除いた822個のヘッダー。 まさに1つの系列で暗号化サービスで生成されたそれぞれのヘッダーと値の組を出力しなければなりません。
First, the originator must retrieve the public key of the recipient. The retrieval may be from a local database or from a remote service. The acquisition of the recipient's public key is outside the scope of the specification, although Section 5 defines one possible mechanism.
まず最初に、創始者は受取人の公開鍵を検索しなければなりません。 検索がローカルのデータベース、または、リモートサービスからあるかもしれません。 仕様の範囲の外に受取人の公開鍵の獲得があります、セクション5は1台の可能なメカニズムを定義しますが。
With the public key, the originator encrypts the data encrypting key according to the Key-Info: header defined below. The complete set of headers generated by the encryption service is as follows.
公開鍵で、創始者はKey-インフォメーションによると、主要なデータ暗号化を暗号化します: 以下で定義されたヘッダー。 暗号化サービスで生成された完全なセットのヘッダーは以下の通りです。
Version:
indicates which version of the MOSS protocol the remaining headers
represent and is defined in Section 2.1.2.1.
バージョン: 残っているヘッダーがモスプロトコルのどのバージョンを表すかを示して、セクション2.1.2で.1に定義されます。
DEK-Info:
indicates the algorithm and mode used to encrypt the data.
DEK-インフォメーション: アルゴリズムとモードが以前はよくデータを暗号化していたのを示します。
Crocker, et al Standards Track [Page 12] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[12ページ]RFC1848のMIME Object Security Services1995年10月
Recipient-ID:
indicates the public key used to encrypt the data encrypting key
that was used to encrypt the data.
受取人ID: 公開鍵が以前はデータを暗号化するのに使用されたキーを暗号化しながらよくデータを暗号化していたのを示します。
Key-Info:
contains data encrypting key encrypted with the recipient's public
key.
主要なインフォメーション: 受取人の公開鍵で暗号化されたキーを暗号化するデータを含んでいます。
Each invocation of the encryption service must emit exactly one Version: header, exactly one DEK-Info: header, and at least one pair of Recipient-ID: and Key-Info: headers. Headers are always emitted in the order indicated. The Recipient-ID: and Key-Info: headers are always emitted in pairs in the order indicated, one pair for each recipient of the encrypted data. A Key-Info: header is always interpreted in the context of the immediately preceding Recipient-ID: header.
各暗号化サービスの実施はまさに1つのバージョンを放たなければなりません: ヘッダー、まさに1つのDEK-インフォメーション: ヘッダー、および少なくとも1組のRecipient-ID: 主要なインフォメーション: ヘッダー。 ヘッダーは指示された順番でいつも放たれています。 受取人ID: 主要なインフォメーション: ヘッダーは指示された順番における、暗号化されたデータの各受取人あたり1組の組でいつも放たれています。 主要なインフォメーション: ヘッダーはすぐに前のRecipient-IDの文脈でいつも解釈されます: ヘッダー。
IMPLEMENTORS NOTE: Implementors should always generate a
Recipient-ID: and Key-Info header pair representing the originator
of the encrypted data. By doing so, if an originator sends a
message to a recipient that is returned undelivered, the
originator will be able to decrypt the message and determine an
appropriate course of action based on its content. If not, an
originator will not be able to review the message that was sent.
作成者は以下に注意します。 作成者はいつもRecipient-IDを生成するべきです: そして、暗号化されたデータの創始者の代理をするKey-インフォメーションヘッダー組。 創始者が発信するならそうすることによって、返される受取人へのメッセージが非提供されて、創始者は、メッセージを解読して、内容に基づく動作の適切な方針を決定できるでしょう。 そうでなければ、創始者は送られたメッセージを再検討できないでしょう。
2.2.1.1. DEK-Info:
2.2.1.1. DEK-インフォメーション:
The purpose of the data encrypting key information header is to indicate the algorithm and mode used to encrypt the data, along with any cryptographic parameters that may be required, e.g., initialization vectors. Its value is either a single argument indicating the algorithm and mode or a comma separated pair of arguments where the second argument carries any cryptographic parameters required by the algorithm and mode indicated in the first argument.
データが主要な情報ヘッダーを暗号化する目的はアルゴリズムとモードが以前はよくデータを暗号化していたのを示すことです、必要である暗号のパラメタと共に、例えば、初期化ベクトル。 値は、2番目の議論がアルゴリズムによって必要とされた暗号のパラメタと最初の議論で示されたモードを運ぶ議論のアルゴリズムとモードを示すただ一つの議論かコンマ切り離された組のどちらかです。
The data encrypting key information header is defined by the grammar token <dekinfo> as follows.
主要な情報ヘッダーを暗号化するデータは以下の文法トークン<dekinfo>によって定義されます。
<dekinfo> ::= "DEK-Info" ":" <dekalgid>
[ "," <dekparameters> ] CRLF
<dekinfo>:、:= 「「DEK-インフォメーション」」:、」 <dekalgid>、[「」、<dekparameters>] CRLF
The grammar tokens for the encryption algorithm and mode identifier (<dekalgid>) and the optional cryptographic parameters (<dekparameters>) are defined by RFC 1423. They are also reprinted in Appendix B.
暗号化アルゴリズムとモード識別子のための文法トークン(<dekalgid>)と任意の暗号のパラメタ(<dekparameters>)はRFC1423によって定義されます。 また、それらはAppendix Bで増刷されます。
Crocker, et al Standards Track [Page 13] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[13ページ]RFC1848のMIME Object Security Services1995年10月
2.2.1.2. Recipient-ID:
2.2.1.2. 受取人ID:
The purpose of the recipient header is to identify the private key that must be used to decrypt the data encrypting key that will be used to decrypt the data. Presumably the recipient owns the private key and thus is less interested in identifying the owner of the key and more interested in the private key value itself. Nonetheless, the recipient header may convey either or both pieces of information:
受取人ヘッダーの目的はデータを解読するのに使用されるキーを暗号化するデータを解読するのに使用しなければならない秘密鍵を特定することです。 おそらく、その結果、受取人は、秘密鍵を所有していて、それほどキーの所有者を特定するのに興味を持っていなくて、秘密鍵値自体にさらに興味を持っています。 それにもかかわらず、受取人ヘッダーはどちらかか両方の情報を伝えるかもしれません:
the public key corresponding to the private key to be used to
decrypt the data encrypting key
キーを暗号化するデータを解読するのに使用されるために秘密鍵に対応する公開鍵
the name of the owner and which of the owner's private keys to use
to decrypt the data encrypting key
所有者の名前とキーを暗号化するデータを解読するのに所有者の秘密鍵のどれを使用したらよいですか。
The decision as to what information to place in the value rests entirely with the originator. The suggested choice is to include just the public key. However, some recipients may prefer that originators not include their public key. How this preference is conveyed to and managed by the originator is outside the scope of this specification.
どんな情報を値に置いたらよいかに関する決定は創始者に完全に責任があります。 提案された選択はまさしく公開鍵を含むことです。 しかしながら、何人かの受取人が、創始者が彼らの公開鍵を入れないのを好むかもしれません。 この仕様の範囲の外にこの好みが創始者によって運ばれてどう管理されているかがあります。
The recipient header is defined by the grammar token <recipid> as follows.
受取人ヘッダーは以下の文法トークン<recipid>によって定義されます。
<recipid> ::= "Recipient-ID:" <id> CRLF
<recipid>:、:= 「受取人ID:」 <イド>CRLF
The grammar token <id> is defined in Section 4.
文法トークン<イド>はセクション4で定義されます。
2.2.1.3. Key-Info:
2.2.1.3. 主要なインフォメーション:
The purpose of the key information header is to convey the encrypted data encrypting key. Its value is a comma separated list of two arguments: the algorithm and mode identifier in which the data encrypting key is encrypted and the encrypted data encrypting key.
主要な情報ヘッダーの目的はキーを暗号化する暗号化されたデータを伝えることです。 値は2つの議論のコンマの切り離されたリストです: アルゴリズム、キーを暗号化するデータが暗号化されているモード識別子、およびキーを暗号化する暗号化されたデータ。
The key information header is defined by the grammar token <asymkeyinfo> as follows.
主要な情報ヘッダーは以下の文法トークン<asymkeyinfo>によって定義されます。
<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF
<asymkeyinfo>:、:= 「「主要なインフォメーション」」:、」 」 「<ikalgid>」、<asymencdek>CRLF
The grammar tokens for the encryption algorithm and mode identifier (<ikalgid>) and the encrypted data encrypting key format (<asymsignmic>) are defined by RFC 1423. They are also reprinted in Appendix B.
暗号化アルゴリズムとモード識別子のための文法トークン(<ikalgid>)と主要な形式を暗号化する暗号化されたデータ(<asymsignmic>)はRFC1423によって定義されます。 また、それらはAppendix Bで増刷されます。
IMPLEMENTORS NOTE: RFC 1423 is referenced by the PEM protocol,
which includes support for symmetric signatures and key
作成者は以下に注意します。 RFC1423はPEMプロトコルによって参照をつけられます。(それは、左右対称の署名とキーのサポートを含んでいます)。
Crocker, et al Standards Track [Page 14] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[14ページ]RFC1848のMIME Object Security Services1995年10月
management. As a result, some of the grammar tokens defined
there, for example, <ikalgid>, will include options that are not
legal for this protocol. These options must be ignored and have
not been included in the appendix.
管理。 その結果、そこで定義された文法トークンのいくつか(例えば、<ikalgid>)がこのプロトコルには、法的でないオプションを含むでしょう。 これらのオプションを、無視して、付録に含んでいてはいけません。
2.2.2. application/moss-keys Content Type Definition
2.2.2. こけアプリケーション/キーContent Type Definition
(1) MIME type name: application
(1) MIMEの種類名: アプリケーション
(2) MIME subtype name: moss-keys
(2) MIME「副-タイプ」は以下を命名します。 こけキー
(3) Required parameters: none
(3) 必要なパラメタ: なし
(4) Optional parameters: none
(4)の任意のパラメタ: なし
(5) Encoding considerations: quoted-printable is always sufficient
(5) 問題をコード化します: いつも引用されて印刷可能であるのが、そうである、十分
(6) Security considerations: none
(6) セキュリティ問題: なし
The "application/moss-keys" content type is used on the first body part of an enclosing multipart/encrypted. Its content is comprised of the data encryption key used to encrypt the data in the second body part and other control information required to decrypt the data, as defined by Section 2.2.1. The label "application/moss-keys" must be used as the value of the protocol parameter of the enclosing multipart/encrypted; the protocol parameter must be present.
「こけアプリケーション/キー」content typeは同封の最初の身体の部分の上で複合か暗号化されていた状態で使用されます。 内容は部分と他の制御情報がデータを解読するのを必要とした2番目のボディーでデータを暗号化するのに使用されるデータ暗号化キーから成ります、セクション2.2.1によって定義されるように。 同封のプロトコルパラメタの値として複合か暗号化されていた状態でラベル「こけアプリケーション/キー」を使用しなければなりません。 プロトコルパラメタは存在していなければなりません。
An application/moss-keys body part is constructed as follows:
こけアプリケーション/キー身体の部分は以下の通り構成されます:
Content-Type: application/moss-keys
コンテントタイプ: こけアプリケーション/キー
<mosskeys>
<mosskeys>。
where the <mosskeys> token is defined as follows.
<mosskeys>トークンが以下の通り定義されるところ。
<mosskeys> ::= <version> <dekinfo> 1*<recipasymflds>
<mosskeys>:、:= <バージョン><dekinfo>1*<recipasymflds>。
<version> ::= "Version:" "5" CRLF
<バージョン>:、:= 「バージョン:」 「5インチのCRLF」
<dekinfo> ::= "DEK-Info" ":" <dekalgid>
[ "," <dekparameters> ] CRLF
<dekinfo>:、:= 「「DEK-インフォメーション」」:、」 <dekalgid>、[「」、<dekparameters>] CRLF
<recipasymflds> ::= <recipid> <asymkeyinfo>
<recipasymflds>:、:= <recipid><asymkeyinfo>。
<recipid> ::= "Recipient-ID:" <id> CRLF
<recipid>:、:= 「受取人ID:」 <イド>CRLF
<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF
<asymkeyinfo>:、:= 「「主要なインフォメーション」」:、」 」 「<ikalgid>」、<asymencdek>CRLF
Crocker, et al Standards Track [Page 15] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[15ページ]RFC1848のMIME Object Security Services1995年10月
The token <id> is defined in Section 4. The token <version> is defined in Section 2.1.2.1. All other tokens are defined in Section 2.2.1.3.
トークン<イド>はセクション4で定義されます。 トークン<バージョン>はセクション2.1.2で.1に定義されます。 他のすべてのトークンがセクション2.2.1で.3に定義されます。
2.2.3. Use of multipart/encrypted Content Type
2.2.3. 複合の、または、暗号化されたContent Typeの使用
The definition of the multipart/encrypted body part in [7] specifies three steps for creating the body part.
[7]との複合の、または、暗号化された身体の部分の定義は身体の部分を作成するための3ステップを指定します。
(1) The body part to be encrypted is created according to a local
convention, for example, with a text editor or a mail user
agent.
(1) 例えば、地方のコンベンションによると、暗号化されるべき身体の部分はテキストエディタかメールユーザエージェントと共に作成されます。
(2) The body part is prepared for encryption according to the
protocol parameter, in this case the body part must be in MIME
canonical form.
(2) プロトコルパラメタによって、身体の部分は暗号化のために準備されて、この場合、身体の部分がMIME標準形にあるに違いありません。
(3) The prepared body part is encrypted according to the protocol
parameter, in this case according to Section 2.2.1.
(3) プロトコルパラメタによると、準備された身体の部分はこの場合セクション2.2.1で暗号化されます。
The multipart/encrypted content type is constructed as follows.
複合の、または、暗号化されたcontent typeは以下の通り構成されます。
(1) The value of its required parameter "protocol" is set to
"application/moss-keys".
(1) 「プロトコル」という必要なパラメタの値は「こけアプリケーション/キー」に設定されます。
(2) The first body part is labeled "application/moss-keys" and is
filled with the control information generated by the encryption
service.
(2) 最初の身体の部分は、「こけアプリケーション/キー」とラベルされて、暗号化サービスで生成された制御情報で満たされます。
(3) The encrypted body part becomes the content of its second body
part, which is labeled "application/octet-stream".
(3) 暗号化された身体の部分は2番目の身体の部分の内容になります。(それは、「八重奏アプリケーション/ストリーム」とラベルされます)。
A multipart/encrypted content type with the MOSS protocol might look as follows:
モスプロトコルがある複合の、または、暗号化されたcontent typeは以下の通りに見えるかもしれません:
Crocker, et al Standards Track [Page 16] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[16ページ]RFC1848のMIME Object Security Services1995年10月
Content-Type: multipart/encrypted;
protocol="application/moss-keys";
boundary="Encrypted Message"
コンテントタイプ: 複合か暗号化される。 =「こけアプリケーション/キー」について議定書の中で述べてください。 境界=「暗号化メッセージ」
--Encrypted Message
Content-Type: application/moss-keys
--暗号化メッセージコンテントタイプ: こけアプリケーション/キー
Version: 5
DEK-Info: DES-CBC,DEK-INFORMATION
Recipient-ID: ID-INFORMATION
Key-Info: RSA,KEY-INFORMATION
バージョン: 5DEK-インフォメーション: デス-CBC、DEK-情報受取人ID: ID-情報の主要なインフォメーション: RSA、主要な情報
--Encrypted Message
Content-Type: application/octet-stream
--暗号化メッセージコンテントタイプ: 八重奏アプリケーション/ストリーム
ENCRYPTED-DATA
--Encrypted Message--
暗号化されたデータ--メッセージを暗号化します--
where DEK-INFORMATION, ID-INFORMATION, and KEY-INFORMATION are descriptive of the content that would appear in a real body part.
DEK-情報、ID-情報、およびKEY-情報が内容で描写的であるところに、それは本当の身体の部分に現れるでしょう。
3. Removing MIME Object Security Services
3. MIMEオブジェクトセキュリティー・サービスを取り除きます。
The verification of the MOSS digital signature service requires the following components.
モスデジタル署名サービスの検証は以下のコンポーネントを必要とします。
(1) A recipient to verify the digital signature.
(1) デジタル署名について確かめる受取人。
(2) A multipart/signed body part with two body parts: the signed
data and the control information.
(2) 2つの身体の部分がある複合の、または、署名している身体の部分: 署名しているデータと制御情報。
(3) The public key of the originator.
(3) 創始者の公開鍵。
The signed data and control information of the enclosing multipart/signed are prepared according to the description below. The digital signature is verified by re-computing the hash of the data, decrypting the hash value in the control information with the originator's public key, and comparing the two hash values. If the two hash values are equal, the signature is valid.
以下での記述によると、複合/が署名した同封に関する署名しているデータと制御情報は準備されます。 デジタル署名はデータのハッシュを再計算することによって、確かめられます、創始者の公開鍵でハッシュが制御情報の値であると解読して、2つのハッシュ値を比較して。 2つのハッシュ値が等しいなら、署名は有効です。
The decryption of the MOSS encryption service requires the following components.
モス暗号化サービスの復号化は以下のコンポーネントを必要とします。
Crocker, et al Standards Track [Page 17] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[17ページ]RFC1848のMIME Object Security Services1995年10月
(1) A recipient to decrypt the data.
(1) データを解読する受取人。
(2) A multipart/encrypted body part with two body parts: the
encrypted data and the control information.
(2) 2つの身体の部分がある複合の、または、暗号化された身体の部分: 暗号化されたデータと制御情報。
(3) The private key of the recipient.
(3) 受取人の秘密鍵。
The encrypted data and control information of the enclosing multipart/encrypted are prepared according to the description below. The data encrypting key is decrypted with the recipient's private key and used to decrypt the data.
以下での記述によると、複合/が暗号化した同封に関する暗号化されたデータと制御情報は準備されます。 キーを暗号化するデータは、受取人の秘密鍵で解読されて、データを解読するのに使用されます。
The next two sections describe the digital signature and encryption services in detail, respectively.
次の2つのセクションが詳細に、それぞれデジタル署名と暗号化サービスについて説明します。
3.1. Digital Signature Service
3.1. デジタル署名サービス
This section describes the processing steps necessary to verify the MOSS digital signature service. The definition of the multipart/signed body part in [7] specifies three steps for receiving it.
このセクションは、モスデジタル署名サービスについて確かめるために処理必要なステップについて説明します。 [7]との複合の、または、署名している身体の部分の定義はそれを受けるための3ステップを指定します。
(1) The digitally signed body part and the control information body
part are prepared for processing.
(1) デジタルに署名している身体の部分と制御情報身体の部分は処理のために準備されます。
(2) The prepared body parts are made available to the digital
signature verification process.
(2)デジタル署名検証プロセスは準備された身体の部分を入手します。
(3) The results of the digital signature verification process are
made available to the user and processing continues with the
digitally signed body part, as returned by the digital signature
verification process.
(3) デジタル署名検証プロセスの結果をユーザにとって利用可能にします、そして、処理はデジタルに署名している身体の部分を続行します、デジタル署名検証プロセスで返すように。
Each of these steps is described below.
それぞれのこれらのステップは以下で説明されます。
3.1.1. Preparation
3.1.1. 準備
The digitally signed body part (the data) and the control information body part are separated from the enclosing multipart/signed body part.
デジタルに署名している身体の部分(データ)と制御情報身体の部分は身体の部分であると署名される同封の複合/と切り離されます。
Crocker, et al Standards Track [Page 18] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[18ページ]RFC1848のMIME Object Security Services1995年10月
The control information is prepared by removing any content transfer encodings that may be present.
制御情報は、どんな存在するかもしれない満足している転送encodingsも取り外すことによって、準備されます。
The digitally signed body part is prepared by leaving the content transfer encodings intact and canonicalizing the line delimiters according to Step 2 of Section 2.1.1.
デジタルに署名している身体の部分は、満足している転送をencodingsに完全なままにし、セクション2.1.1のStep2によると、系列デリミタをcanonicalizingすることによって、準備されます。
3.1.2. Verification
3.1.2. 検証
First, the recipient must obtain the public key of the originator. The public key may be contained in the control information or it may be necessary for the recipient to retrieve the public key based on information present in the control information. The retrieval may be from a local database or from a remote service. The acquisition of the originator's public key is outside the scope of the specification, although Section 5 defines one possible mechanism.
まず最初に、受取人は創始者の公開鍵を得なければなりません。 公開鍵が制御情報に含まれるかもしれませんか、または受取人が制御情報の現在の情報に基づく公開鍵を検索するのが必要であるかもしれません。 検索がローカルのデータベース、または、リモートサービスからあるかもしれません。 仕様の範囲の外に創始者の公開鍵の獲得があります、セクション5は1台の可能なメカニズムを定義しますが。
With the public key, the recipient decrypts the hash value contained in the control information. Then, a new hash value is computed over the body part purported to have been digitally signed.
公開鍵で、受取人は、ハッシュが制御情報に含まれた値であると解読します。 そして、新しいハッシュ値は部分がデジタルに署名されたことを意味したボディーの上で計算されます。
Finally, the two hash values are compared to determine the accuracy of the digital signature.
最終的に、2つのハッシュ値が、デジタル署名の精度を決定するために比較されます。
3.1.3. Results
3.1.3. 結果
There are two required components of the results of the verification process. The first is an indication as to whether a public key could be found that allows the hash values in the previous step to compare equal. Such an indication verifies only that the data received is the same data that was digitally signed.
検証プロセスの結果の2つの必要なコンポーネントがあります。 1番目は前のステップにおけるハッシュ値が同輩を比較できる公開鍵を見つけることができたかどうかに関する指示です。 指示が確かめるデータが受けた唯一のそのようなものはデジタルに署名された同じデータです。
The second indication identifies the owner of the public key who is presumably the holder of the private key that created the digital signature. The indication must include a testament as to the accuracy of the owner identification.
2番目の指示はおそらく、デジタル署名を作成した秘密鍵の所有者である公開鍵の所有者を特定します。 指示は所有者識別の精度に関して遺書を含まなければなりません。
At issue is a recipient knowing who created the digital signature. In order for the recipient to know with certainty who digitally signed the message, the binding between the owner's name and the public key must have been verified by the recipient prior to the verification of the digital signature. The verification of the binding may have been completed offline and stored in a trusted, local database or, if the owner's name and public key are embodied in a certificate, it may be possible to complete it in realtime. See Section 5 for more information.
問題には、だれがデジタル署名を作成したかを知っている受取人がいます。 受取人が、確実性でだれがメッセージにデジタルに署名したかを知るように、所有者の名前と公開鍵の間の結合はデジタル署名の検証の前に受取人によって確かめられたに違いありません。 結合の検証が、信じられて、ローカルのデータベースにオフラインで終了して、保存されたかもしれませんか、または所有者の名前と公開鍵が証明書に表現されるなら、リアルタイムででそれを完成するのは可能であるかもしれません。 詳しい情報に関してセクション5を見てください。
Crocker, et al Standards Track [Page 19] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[19ページ]RFC1848のMIME Object Security Services1995年10月
3.2. Encryption Service
3.2. 暗号化サービス
This section describes the processing steps necessary to decrypt the MOSS encryption service. The definition of the multipart/encrypted body part in [7] specifies three steps for receiving it.
このセクションは、モス暗号化がサービスであると解読するために処理必要なステップについて説明します。 [7]との複合の、または、暗号化された身体の部分の定義はそれを受けるための3ステップを指定します。
(1) The encrypted body part and the control information body part
are prepared for processing.
(1) 暗号化された身体の部分と制御情報身体の部分は処理のために準備されます。
(2) The prepared body parts are made available to the decryption
process.
(2)復号化プロセスは準備された身体の部分を入手します。
(3) The results of the decryption process are made available to the
user and processing continues with the decrypted body part, as
returned by the decryption process.
(3) 復号化プロセスの結果をユーザにとって利用可能にします、そして、処理は解読された身体の部分を続行します、復号化プロセスで返すように。
Each of these steps is described below.
それぞれのこれらのステップは以下で説明されます。
3.2.1. Preparation
3.2.1. 準備
The encrypted body part (the data) and the control information body part are separated from the enclosing multipart/encrypted body part. The body parts are prepared for the decryption process by removing any content transfer encodings that may be present.
暗号化された身体の部分(データ)と制御情報身体の部分は同封の複合の、または、暗号化された身体の部分と切り離されます。 身体の部分は、復号化プロセスのためにどんな存在するかもしれない満足している転送encodingsも取り外すことによって、準備されます。
3.2.2. Decryption
3.2.2. 復号化
First, the recipient must locate the encrypted data encrypting key in the control information. Each Recipient-ID: header is checked in order to see if it identifies the recipient or a public key of the recipient.
まず最初に、受取人は制御情報で主要な暗号化されたデータ暗号化の場所を見つけなければなりません。 それぞれの受取人ID: ヘッダーは、それが受取人の受取人か公開鍵を特定するかどうか確認するためにチェックされます。
If it does, the immediately following Key-Info: header will contain the data encrypting key encrypted with the public key of the recipient. The recipient must use the corresponding private key to decrypt the data encrypting key.
そうするならすぐに次のKey-インフォメーション: ヘッダーは受取人の公開鍵で暗号化されたキーを暗号化するデータを含むでしょう。 受取人は、キーを暗号化するデータを解読するのに対応する秘密鍵を使用しなければなりません。
The data is decrypted with the data encrypting key. The decrypted data will be a MIME object, a body part, ready to be processed by a MIME agent.
データがキーを暗号化している状態で、データは解読されます。 解読されたデータはMIMEオブジェクト、MIMEエージェントによって処理される準備ができている身体の部分になるでしょう。
Crocker, et al Standards Track [Page 20] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[20ページ]RFC1848のMIME Object Security Services1995年10月
3.2.3. Results
3.2.3. 結果
If the recipient is able to locate and decrypt a data encrypting key, from the point of view of MOSS the decryption should be considered successful. An indication of the owner of the private key used to decrypt the data encrypting key must be made available to the user.
受取人がモスの観点からデータ暗号化キーを場所を見つけて、解読することができるなら、復号化はうまくいくと考えられるべきです。 キーを暗号化するデータを解読するのに使用される秘密鍵の所有者のしるしをユーザにとって利用可能にしなければなりません。
Ultimately, the success of the decryption is dependent on the ability of a MIME agent to continue processing with the decrypted body part.
結局、復号化の成功はMIMEエージェントが解読された身体の部分で処理し続ける能力に依存しています。
4. Identifying Originators, Recipients, and Their Keys
4. 創始者、受取人、および彼らのキーを特定します。
In the PEM specifications, public keys are required to be embodied in certificates, an object that binds each public key with a distinguished name. A distinguished name is a name form that identifies the owner of the public key. The embodiment is issued by a certification authority, a role that is expected to be trustworthy insofar as the certification authority would have procedures to verify the identity of the owner prior to issuing the certificate.
PEM仕様では、公開鍵が、証明書(分類名で各公開鍵を縛るオブジェクト)に表現されるのに必要です。 分類名は公開鍵の所有者を特定する名前フォームです。 証明権威(証明書を発行する前に所有者のアイデンティティについて確かめるために証明権威に手順があるだろう限り、信頼できると予想される役割)によって具体化は発行されます。
In MOSS, a user is not required to have a certificate. The MOSS services require that the user have at least one public/private key pair. The MOSS protocol requires the digital signature and encryption services to emit Originator-ID: and Recipient-ID: headers, as appropriate. In the discussion above the actual value of these headers was omitted, having been relegated to this section. Although the value of each of these headers serves a distinct purpose, for simplicity the single grammar token <id> represents the value that may be assigned to either header.
モスでは、ユーザは、証明書を持つのに必要ではありません。 モスサービスは、ユーザには少なくとも1公衆/秘密鍵組があるのを必要とします。 モスプロトコルは、デジタル署名と暗号化サービスがOriginator-IDを放つのを必要とします: 受取人ID: 適宜ヘッダー。 議論では、このセクションに左遷されて、上では、これらのヘッダーの実価が省略されました。 これらのヘッダー各人の値はただ一つの文法トークン<イドに簡単さのための異なった目的に役立ちますが、>はどちらのヘッダーにも割り当てられるかもしれない値を表します。
One possible value for the Originator-ID: and Recipient-ID: headers is the public key values themselves. However, while it is true that the public keys alone could be exchanged and used by users to communicate, the values are, in fact, large and cumbersome. In addition, public keys would appear as a random sequence of characters and, as a result, would not be immediately consumable by human users.
1つのOriginator-IDに、可能な値: 受取人ID: ヘッダーは公開鍵値自体です。 しかしながら、ユーザが交信するのに公開鍵だけを交換して、使用できたのが、本当ですが、値は、事実上、大きくて、厄介です。 さらに、公開鍵は、キャラクタのランダム・シーケンスとして現れて、人間のユーザはすぐに、その結果消費できないでしょう。
NOTE: It should be pointed out that a feature of being able to
specify the public key explicitly is that it allows users to
exchange encrypted, anonymous mail. In particular, receiving
users will always know a message comes from the same originating
user even if the real identity of the originating user is unknown.
以下に注意してください。 できるのが明らかに公開鍵を指定する特徴がユーザがそれで暗号化されて、匿名のメールを交換できるということであると指摘されるべきです。 特に、ユーザを受けるのは、起因しているユーザの正体が未知であってもメッセージが同じ起因しているユーザから来るのをいつも知るでしょう。
Recognizing that the use of public keys is, in general, unsuitable for use by humans, MOSS allows other identifiers in Originator-ID: and Recipient-ID: headers. These other identifiers are comprised of two parts: a name form and a key selector.
人間による使用には、一般に、公開鍵の使用が不適当であると認めて、モスはOriginator-IDに他の識別子を許容します: 受取人ID: ヘッダー。 これらの他の識別子は2つの部品から成ります: 名前フォームと主要なセレクタ。
Crocker, et al Standards Track [Page 21] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[21ページ]RFC1848のMIME Object Security Services1995年10月
The name form is chosen and asserted by the user who owns the public/private key pair. Three name forms are specified by this document. The use of a distinguished name is retained for compatibility with PEM (and compatibility with the X.500 Directory should it become a ubiquitous service). However, the Internet community has a great deal of experience with the use of electronic mail addresses as a name form. Also, arbitrary strings are useful to identify the owners of public keys when private name forms are used. Hence, email addresses and arbitrary strings are included as name forms to increase flexibility.
名前フォームは、公衆/秘密鍵組を所有しているユーザによって、選ばれていて、断言されます。 3つの名前フォームがこのドキュメントによって指定されます。 分類名の使用がPEMとの互換性のために保有される、(互換性、X.500ディレクトリで、それが遍在しているサービスになるべきである、) しかしながら、インターネットコミュニティで、名前としての電子メールアドレスの使用の大きな経験が形成されます。 また、任意のストリングも、個人的な名前フォームが使用されているとき、公開鍵の所有者を特定するために役に立ちます。 したがって、Eメールアドレスと任意のストリングは、柔軟性を増強するために名前フォームとして含まれています。
Since a user may have more than one public key and may wish to use the same name form for each public key, a name form is insufficient for uniquely identifying a public key. A unique "key selector" must be assigned to each public key. The combination of a name form and the key selector uniquely identifies a public key. Throughout this document, this combination is called an identifier. There are 5 identifiers specified by this document.
ユーザが1つ以上の公開鍵を持って、各公開鍵に同じ名前フォームを使用したがっているかもしれないので、唯一公開鍵を特定するのに、名前フォームは不十分です。 ユニークな「主要なセレクタ」を各公開鍵に割り当てなければなりません。 名前フォームと主要なセレクタの組み合わせは唯一公開鍵を特定します。 このドキュメント中では、この組み合わせは識別子と呼ばれます。 このドキュメントによって指定された5つの識別子があります。
NOTE: In the simplest case, key selectors will be assigned by the
owners of the public/private key pairs. This works best when
users generate their own key pairs for personal use, from which
they distribute their public key to others asserting by
declaration that the public key belongs to them. When the
assertion that the public key belongs to them is made by a third
party, for example when a certification authority issues a
certificate to a user according to [4], the key selector may be
assigned by that third party.
以下に注意してください。 最も簡単な場合では、主要なセレクタは公衆/秘密鍵組の所有者によって割り当てられるでしょう。 ユーザが個人的な使用(彼らは公開鍵が彼らに属すという宣言による他のもの断言に自分達の公開鍵を分配する)のためにそれら自身の主要な組を生成すると、これはうまくいきます。 公開鍵がそれらに属すという主張が第三者によってされるとき、例えば、[4]によると、証明権威がユーザに証明書を下付するとき、主要なセレクタはその第三者によって割り当てられるかもしれません。
The value of the key selector must be unique with respect to the name form with which it forms an identifier. Although the same key selector value may be used by more than one name form it must not be used for two different keys with the same name form. When considered separately, neither a name form nor a key selector is sufficient for identifying the public key to be used. Either could be used to determine a set of public keys that may be tried in turn until the desired public key is identified.
主要なセレクタの値はそれが識別子を形成する名前フォームに関してユニークであるに違いありません。 同じ主要なセレクタ値は1つ以上の名前フォームによって使用されるかもしれませんが、2個の異なったキーに同じ名前フォームでそれは使用してはいけません。 別々に考えられる場合、名前フォームも主要なセレクタも使用されるべき公開鍵を特定するのに十分ではありません。 必要な公開鍵が特定されるまで順番に試みられるかもしれない1セットの公開鍵を決定するのにどちらかを使用できました。
With a public/private key pair for one's self and software that is MOSS aware, an originating user may digitally sign arbitrary data and send it to one or more recipients. With the public keys of the recipients, a user may encrypt the data so that only the intended recipients can decrypt and read it. With the name forms assigned to the public keys, originators and recipients can easily recognize their peers in a communication.
意識していて、起因しているユーザは、モスである人の自己とソフトウェアのための公衆/秘密鍵組と共に、任意のデータにデジタルに署名して、1人以上の受取人にそれを送るかもしれません。 受取人の公開鍵で、ユーザは、意図している受取人だけがそれを解読して、読むことができるように、データを暗号化するかもしれません。 名前フォームが公開鍵に割り当てられている状態で、創始者と受取人はコミュニケーションで容易に彼らの同輩を見分けることができます。
In the next section the 3 name forms are described in detail. Following that is the specification of the 5 identifiers.
次のセクションで、3つの名前フォームが詳細に説明されます。 それに続くのは、5つの識別子の仕様です。
Crocker, et al Standards Track [Page 22] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[22ページ]RFC1848のMIME Object Security Services1995年10月
4.1. Name Forms
4.1. 名前フォーム
There are 3 name forms specified by this document: email addresses, distinguished names, and arbitrary strings.
このドキュメントによって指定された3つの名前フォームがあります: Eメールアドレス、分類名、および任意のストリング。
4.1.1. Email Addresses
4.1.1. Eメールアドレス
The email address (grammar token <emailstr>) used must be a valid RFC822 address, which is defined in terms of one of the two grammar tokens <addr-spec> or <route-addr>. The grammar for these two tokens is included in the Appendix as a convenience; the definitive source for these tokens is necessarily RFC822 [1].
(文法トークン<emailstr>)が使用したEメールアドレスは有効なRFC822アドレスであるに違いありませんか<ルート-addrが>です。(それは、2文法トークン<addr-仕様>の1つで定義されます)。 これらの2つのトークンのための文法は便利としてAppendixに含まれています。 これらのトークンのための決定的なソースは必ずRFC822[1]です。
<emailstr> ::= <addr-spec> / <route-addr>
; an electronic mail address as defined by
; one of these two tokens from RFC822
<emailstr>:、:= <addr-仕様<ルート>/addr>。 定義される電子メールアドレス。 RFC822からのこれらの2つのトークンの1つ
For example, the strings "crocker@tis.com", "galvin@tis.com", "murphy@tis.com", and "ned@innosoft.com" are all email addresses.
例えば、ストリングの" crocker@tis.com "、「galvin@tis.com」、" murphy@tis.com "、および" ned@innosoft.com "はすべてEメールアドレスです。
4.1.2. Arbitrary Strings
4.1.2. 任意のストリング
The arbitrary string (grammar token <string>) must have a length of at least 1. There are no other restrictions on the value chosen.
任意のストリング(文法トークン<ストリング>)には、少なくとも1の長さがなければなりません。 他の制限が全く選ばれた値にありません。
<string> ::= ; a non-null sequence of characters
<ストリング>:、:= ; キャラクタの非零列
For example, the string
例えば、ストリング
the SAAG mailing list maintainer
SAAGメーリングリスト維持装置
is an arbitrary string.
任意のストリング。
4.1.3. Distinguished Names
4.1.3. 分類名
The distinguished name (grammar token <dnamestr>) must be constructed according to the guidelines of the X.500 Directory. The actual syntax of the distinguished name is outside the scope of this specification. However, RFC1422, for example, specifies syntactic restrictions based on its choice of a certification hierarchy for certificates.
X.500ディレクトリのガイドラインによると、分類名(文法トークン<dnamestr>)を構成しなければなりません。 この仕様の範囲の外に分類名の実際の構文があります。 しかしながら、例えば、RFC1422は証明階層構造の選択に基づく構文の制限を証明書に指定します。
For the purposes of conveying a distinguished name from an originator to a recipient, it must be ASN.1 encoded and then printably encoded according to the base64 encoding defined by MIME.
創始者から受取人まで分類名を伝える目的のために、MIMEによって定義されたbase64コード化に従って、それはコード化されて、次にprintablyにコード化されたASN.1でなければならない。
Crocker, et al Standards Track [Page 23] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[23ページ]RFC1848のMIME Object Security Services1995年10月
<dnamestr> ::= <encbin>
; a printably encoded, ASN.1 encoded
; distinguished name (as defined by the 'Name'
; production specified in X.501 [8])
<dnamestr>:、:= <encbin>。 コード化されたprintably、コード化されたASN.1。 分類名(定義される、'名前'で; 生産はX.501[8])で指定しました。
For example,
例えば
/Country Name=US
/State or Province Name=MD
/Organization Name=Trusted Information Systems
/Organizational Unit Name=Glenwood
/Common Name=James M. Galvin/
/国名前=米国/州か州名前=MD/組織名前=信じられた情報システム/組織的なユニット名前=グレンウッド/俗称=ジェームスM.ガルビン/
is a distinguished name in a user friendly format (line breaks and leading spaces present only to improve readability). When encoded, it would appear as follows (line breaks present only to improve readability):
ユーザフレンドリーな形式(読み易さを改良するためにはだけ現在のラインブレイクと主な空間)には分類名がありますか? コード化されると、以下の通りに(読み易さを改良するためにはだけ現在のラインブレイク)見えるでしょう:
MG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3RlZCBJ
bmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1UEAxMP
SmFtZXMgTS4gR2Fsdmlu
MG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3RlZCBJ bmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1UEAxMP SmFtZXMgTS4gR2Fsdmlu
4.2. Identifiers
4.2. 識別子
There are 5 types of identifiers specified by this document:
このドキュメントによって指定された5つのタイプに関する識別子があります:
email address identifiers
Eメールアドレス識別子
arbitrary string identifiers
任意のストリング識別子
distinguished name identifiers
分類名識別子
the public keys themselves
公開鍵自体
issuer name serial number pairs from a certificate
証明書からの発行人名前通し番号組
All of these have approximately the same structure (except issuer name and serial number which has 'TYPE, STRING, KEYSEL' for historical reasons):
これらすべて、にはほとんど同じ構造(発行人名と歴史的な理由で'TYPE、STRING、KEYSEL'を持っている通し番号を除いた)があります:
TYPE, KEYSEL, STRING
タイプ、KEYSEL、ストリング
The TYPE field is a literal string chosen from the set "EN", "STR", "DN", "PK", and "IS", one for each of the possible identifiers.
TYPE分野は、セット「アン」から選ばれた、文字通りのストリング、"STR"、"DN""PK"であり、「あります」、それぞれの可能な識別子のためのもの。
The KEYSEL field is used to distinguish between the multiple public keys that may be associated with the name form in the STRING field. Its value must be unique with respect to all other key selectors used
KEYSEL分野は、STRING分野の名前フォームに関連するかもしれない複数の公開鍵を見分けるのに使用されます。 値は他の主要なセレクタが使用したすべてに関してユニークであるに違いありません。
Crocker, et al Standards Track [Page 24] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[24ページ]RFC1848のMIME Object Security Services1995年10月
with the same name form. An example would be to use a portion (low- order 16 or 32 bits) or all of the actual public key used.
同じ名前で、形成してください。 実際の公開鍵の部分(少ないオーダー16か32ビット)かすべてが使用した使用には例があるでしょう。
The STRING field is the name form and has a different syntax according to the value of the TYPE field.
STRING分野は、名前フォームであり、TYPE分野の値に従って、異なった構文を持っています。
The identifier used in each of the originator and recipient fields is described by the following grammar. The definition of the key selector token is included here since it used by several of the identifiers below.
それぞれの創始者と受取人分野で使用される識別子は以下の文法によって説明されます。それ以来主要なセレクタトークンの定義はここに以下のいくつかの識別子によって使用されていた状態で含まれています。
<id> ::= <id-email> / <id-string> / <id-dname>
/ <id-publickey> / <id-issuer>
<イド>:、:= <イドメール<イド>/ストリング<イド>/dname<イド>/パブリックキー<イド>/発行人>。
<keysel> ::= 1*<hexchar>
; hex dump of a non-null sequence of octets
<keysel>:、:= 1*<hexchar>。 八重奏の非零列の十六進法ダンプ
Each of the identifier name forms is described below.
形成というそれぞれの識別子名は以下で説明されます。
4.2.1. Email Address
4.2.1. Eメールアドレス
The email address identifier has the following syntax.
Eメールアドレス識別子には、以下の構文があります。
<id-email> ::= "EN" "," <keysel> "," <emailstr> CRLF
<イドメール>:、:= 」 「「アン」」、<keysel>、」、」 <emailstr>CRLF
The syntax of the token <emailstr> is defined in Section 4.1.1.
トークン<emailstr>の構文はセクション4.1.1で定義されます。
For example:
例えば:
EN,1,galvin@tis.com
アン、1、 galvin@tis.com
is an email address identifier.
Eメールアドレスは識別子ですか?
4.2.2. Arbitrary String
4.2.2. 任意のストリング
The arbitrary string identifier has the following syntax.
任意のストリング識別子には、以下の構文があります。
<id-string> ::= "STR" "," <keysel> "," <string> CRLF
<イドストリング>:、:= 」 「"STR"」、<keysel>、」、」 <ストリング>CRLF
The syntax of the token <string> is defined in Section 4.1.2.
トークン<ストリング>の構文はセクション4.1.2で定義されます。
For example:
例えば:
STR,1,The SAAG mailing list maintainer
STR、1、SAAGメーリングリスト維持装置
is an arbitrary string identifier.
任意のストリングは識別子ですか?
Crocker, et al Standards Track [Page 25] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[25ページ]RFC1848のMIME Object Security Services1995年10月
4.2.3. Distinguished Name
4.2.3. 分類名
The distinguished name identifier has the following syntax.
分類名識別子には、以下の構文があります。
<id-dname> ::= "DN" "," <keysel> "," <dnamestr> CRLF
<イドdname>:、:= 」 「"DN"」、<keysel>、」、」 <dnamestr>CRLF
The syntax of the token <dnamestr> is defined in Section 4.1.3.
トークン<dnamestr>の構文はセクション4.1.3で定義されます。
For example (line breaks present only to improve readability):
例えば、(読み易さを改良するためには唯一のラインブレイクプレゼント):
DN,1,MG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3R
lZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1U
EAxMPSmFtZXMgTS4gR2Fsdmlu
DN、1、MG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3R lZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1U EAxMPSmFtZXMgTS4gR2Fsdmlu
is a distinguished name identifier.
分類名は識別子ですか?
4.2.4. Public Key
4.2.4. 公開鍵
The public key identifier has the following syntax.
公開鍵識別子には、以下の構文があります。
<id-publickey> ::= "PK" "," <publickey> [ "," <id-subset> ] CRLF
<イドパブリックキー>:、:= 「"PK"」、」 <パブリックキー>、[「>] 」 <イド部分集合CRLF
<publickey> ::= <encbin>
; a printably encoded, ASN.1 encoded public
; key (as defined by the
; 'SubjectPublicKeyInfo' production specified
; in X.509 [9])
<パブリックキー>:、:= <encbin>。 printablyがコード化されて、ASN.1は公衆をコード化しました。 キー(; 生産が指定した'SubjectPublicKeyInfo';コネで、X.509[9])を定義します。
<id-subset> ::= <id-email> / <id-string> / <id-dname>
<イド部分集合>:、:= <イドメール<イド>/ストリング<イド>/dname>。
The production SubjectPublicKeyInfo is imported from the X.500 Directory from the certificate object. It is currently the best choice for a general purpose public key encoding.
生産SubjectPublicKeyInfoはX.500ディレクトリから証明書オブジェクトからインポートされます。 現在、それは汎用の公開鍵コード化のための最も良い選択です。
For example, (line breaks present only to improve readability):
例えば、(読み易さを改良するためには唯一のラインブレイクプレゼント):
PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6BekJmG
4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn
0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB
PK、MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6BekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB
is a public key identifier without the optional <id-subset>.
公開鍵識別子が任意の<イド部分集合>なしでありますか?
In normal usage, the token <id-subset> is expected to be present. It represents a mechanism by which an identifier (name form and key selector) can be associated with a public key. Recipients of a public key identifier must take care to verify the accuracy of the purported association. If they do not, it may be possible for a malicious originator to assert an identifier that accords the
正常な用法で、トークン<イド部分集合>を存在させていると予想されます。 それは識別子(名前フォームと主要なセレクタ)を公開鍵に関連づけることができるメカニズムを表します。 公開鍵識別子の受取人は、主張された協会の精度について確かめるために注意しなければなりません。 そうしないなら、悪意がある創始者が一致する識別子について断言するのは、可能であるかもしれません。
Crocker, et al Standards Track [Page 26] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[26ページ]RFC1848のMIME Object Security Services1995年10月
originator unauthorized privileges. See Section 5.2 for more details.
創始者の権限のない特権。 その他の詳細に関してセクション5.2を見てください。
For example, (line breaks present only to improve readability):
例えば、(読み易さを改良するためには唯一のラインブレイクプレゼント):
PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6BekJmG
4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn
0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,2,galvin@tis.com
PK、MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6BekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB、アン、2、 galvin@tis.com
is a public key identifier with the optional <id-subset>.
任意の<イド部分集合がある公開鍵識別子は>ですか?
4.2.5. Issuer Name and Serial Number
4.2.5. 発行人名と通し番号
The issuer name and serial number identifier has the following syntax.
発行人名と通し番号識別子には、以下の構文があります。
<id-issuer> ::= "IS" "," <dnamestr> "," <serial> CRLF
<イド発行人>:、:= 」 「「存在」」、<のdnamestr>、」、」 <の連続の>CRLF
<serial> ::= 1*<hexchar>
; hex dump of a certificate serial number
<の連続の>:、:= 1*<hexchar>。 証明書通し番号の十六進法ダンプ
The <id-issuer> identifier is included for compatibility with the ID-ASymmetric fields defined in [3] (and compatibility with X.500 Directory certificates should they become ubiquitously available). Its syntax was chosen such that the older fields are easily converted to this new form by prefixing the old value with "IS" (and replacing the field name of [3] with an appropriate new ID field name). For example, (line breaks present only to improve readability):
そして、<イド、-発行人>識別子が[3]で定義されるID-ASymmetric分野との互換性のために含まれている、(遍在して利用可能になるならX.500ディレクトリとの互換性が証明する、) より古い分野が容易にこの新しいフォームに変換されるようなものは、「存在」がある古い値を前に置くことによって、構文に選ばれました([3]のフィールド名を適切な新しいIDフィールド名に取り替えて)。 例えば、(読み易さを改良するためには唯一のラインブレイクプレゼント):
IS,MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3
RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA==,02
MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3 RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=、02
is an issuer name and serial number identifier according to MOSS, while
モスによると、発行人は、名義と通し番号識別子です。
MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3
RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA==,02
MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3 RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=、02
is an issuer name and serial number identifier according to PEM.
PEMに従った発行人名と通し番号識別子はそうですか?
5. Key Management Content Types
5. Key Management content type
This document defines two key management content types: one for requesting cryptographic key material and one for sending cryptographic key material. Since MOSS depends only on the existence of public/private key pairs, these content types provide a means for conveying public keys and an assertion as to the identity of the owner. In addition, in order to be compatible with the certificate-
このドキュメントは2つのかぎ管理content typeを定義します: 暗号化キーの材料を要求するためのものと送付暗号化キーの材料のためのもの。 モスが公衆/秘密鍵組の存在だけによるので、これらのcontent typeは所有者のアイデンティティに関して公開鍵と主張を伝えるための手段を提供します。 さらに、証明書と互換性があります。
Crocker, et al Standards Track [Page 27] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[27ページ]RFC1848のMIME Object Security Services1995年10月
base key management system proposed by RFC 1422, the content types may also be used to convey certificate and certificate revocation list material.
ベースかぎ管理システムはRFC1422で提案しました、また、content typeが、証明書と証明書失効リストの材料を伝えるのに使用されるかもしれません。
The functions defined here are based on the exchange of body parts. In particular, a user would send a message containing at least one application/mosskey-request content, as defined below. In response, a user would expect to receive a message containing at least one application/mosskey-data content, as defined below. MIME provides a convenient framework for a user to send several request body parts and to receive several data (response) body parts in one message.
ここで定義された機能は身体の部分の交換に基づいています。 特に、ユーザは以下で定義されるように少なくとも1つのmosskeyアプリケーション/要求内容を含むメッセージを送るでしょう。 応答では、ユーザは、以下で定義されるように少なくとも1つのmosskeyアプリケーション/データ内容を含むメッセージを受け取ると予想するでしょう。 MIMEは、ユーザがいくつかの要求身体の部分を送って、1つのメッセージにいくつかのデータ(応答)身体の部分を受け取るために便利なフレームワークを提供します。
5.1. application/mosskey-request Content Type Definition
5.1. mosskeyアプリケーション/要求Content Type Definition
(1) MIME type name: application
(1) MIMEの種類名: アプリケーション
(2) MIME subtype name: mosskey-request
(2) MIME「副-タイプ」は以下を命名します。 mosskey-要求
(3) Required parameters: none
(3) 必要なパラメタ: なし
(4) Optional parameters: none
(4)の任意のパラメタ: なし
(5) Encoding considerations: quoted-printable is always sufficient
(5) 問題をコード化します: いつも引用されて印刷可能であるのが、そうである、十分
(6) Security Considerations: none
(6) セキュリティ問題: なし
The content of this body part corresponds to the following production.
この身体の部分の内容は以下の生産に対応しています。
<request> ::= <version>
( <subject> / <issuer> / <certification> )
<要求>:、:= <バージョン>。(<の対象の>/<発行人>/<証明>)
<version> ::= "Version:" "5" CRLF
<バージョン>:、:= 「バージョン:」 「5インチのCRLF」
<subject> ::= "Subject:" <id> CRLF
<の対象の>:、:= 「Subject:」 <イド>CRLF
<issuer> ::= "Issuer:" <id> CRLF
<発行人>:、:= 「発行人:」 <イド>CRLF
<certification> ::= "Certification:" <encbin> CRLF
<証明>:、:= 「証明:」 <encbin>CRLF
A user would use this content type to specify needed cryptographic key information. The message containing this content type might be directed towards an automatic or manual responder, which may be mail-based, depending on the local implementation and environment. The application/mosskey-request content type is an independent body part because it is entirely independent of any other body part.
ユーザは、必要な暗号化キー情報を指定するのにこのcontent typeを使用するでしょう。 このcontent typeを含むメッセージは自動であるか手動の応答者に向けられるかもしれません、地方の実装と環境によって。(その応答者は、メールベースであるかもしれません)。 それがいかなる他の身体の部分からも完全に独立しているので、mosskeyアプリケーション/要求content typeは独立機関部分です。
Crocker, et al Standards Track [Page 28] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[28ページ]RFC1848のMIME Object Security Services1995年10月
If the application/mosskey-request content contains a Certification: field it requests certification of the self-signed certificate in the field value. If the content contains an Issuer: field it requests the Certificate Revocation List (CRL) chain beginning with the CRL of the issuer identified in the field value. If the content contains a Subject: field it requests either the public key of the subject or a certificate chain beginning with the subject identified in the field value, or both if both exist.
mosskeyアプリケーション/要求内容がCertificationを含んでいるなら: それが、その分野での自己署名入りの証書の証明が評価するよう要求する分野。 内容がIssuerを含んでいるなら: それが、発行人のCRLがあるCertificate Revocation List(CRL)チェーン始めが分野値で特定したよう要求する分野。 内容がSubject:を含んでいるなら 対象で始まるそれが、対象の公開鍵か証明書のどちらかがチェーニングするよう要求する分野は、分野値、または両方で両方が存在するかどうか特定しました。
The Subject: and Issuer: fields each contain a value of type <id>, which is defined in Section 4.
Subject: 発行人: 分野はそれぞれタイプ<イド>の値を含んでいます。(>はセクション4で定義されます)。
One possible response to receiving an application/mosskey-request body part is to construct and return an application/mosskey-data body part. When returning public keys, certificate chains, and certificate revocation list chains, if there exists more than one, several application/mosskey-data body parts are to be returned in the reply message, one for each.
mosskeyアプリケーション/要求身体の部分を受け取ることへの1つの可能な応答は、mosskeyアプリケーション/データ身体の部分を構成して、返すことです。 1つ以上が存在しているなら公開鍵、証明書チェーン、および証明書失効リストチェーンを返すとき、いくつかのmosskeyアプリケーション/データ身体の部分は応答メッセージ(それぞれのためのもの)で返されることになっています。
5.2. application/mosskey-data Content Type Definition
5.2. mosskeyアプリケーション/データContent Type Definition
The principal objective of this content type is to convey cryptographic keying material from a source to a destination. This might be in response to the receipt of an application/mosskey-request content type or it might be in anticipation of receiving an application/mosskey-request if it is not sent, e.g., it may be combined with a multipart/signed object by an originator to ensure that a recipient has the cryptographic keying material necessary to verify the signature. When combined with other content types, the processing by a recipient is enhanced if the application/mosskey-data content type is positioned in its enclosing content type prior to the content types that will make use of its cryptographic keying material.
このcontent typeの主要な目的はソースから目的地まで暗号の合わせることの材料を運ぶことです。 それが送られないならmosskeyアプリケーション/要求を受け取ることを予測してあるかもしれません、そして、これがmosskeyアプリケーション/要求content typeの領収書に対応しているかもしれませんか、または例えば、それは、受取人が暗号の合わせることの材料を署名について確かめるのに必要にするのを保証するために創始者によって複合の、または、署名しているオブジェクトに結合されるかもしれません。 他のcontent typeに結合されると、暗号の合わせることの使用を物質的にするcontent typeの前にcontent typeを同封する際にmosskeyアプリケーション/データcontent typeが置かれるなら、受取人による処理は機能アップされます。
However, no explicit provision is made in this document for determining the authenticity or accuracy of the data being conveyed. In particular, when a public key and its identifier is conveyed, there is nothing to prevent the source or an interloper along the path from the source to the destination from substituting alternate values for either the public key or the identifier.
しかしながら、本書では伝えられるデータの信憑性か精度を決定するためにどんな明白な設備もしません。 公開鍵とその識別子が伝えられるとき、特に、何もソースから目的地までの経路に沿ったソースか侵入者が代替の値を公開鍵か識別子のどちらかの代わりに用いるのを防ぐものがありません。
It is incumbent upon a recipient to verify the authenticity and accuracy of the data received in this way prior to its use. This problem can be addressed by the use of certificates, since a certification hierarchy is a well-defined mechanism that conveniently supports the automatic verification of the data. Alternatively, the source of the application/mosskey-data body part could digitally sign it. In this way, if the destination believes that a correct source's
受取人では、使用の前にこのように受け取られたデータの信憑性と精度について確かめるのは義務です。 証明書の使用でこの問題を扱うことができます、証明階層構造が便利にデータの自動証明をサポートする明確なメカニズムであるので。 あるいはまた、mosskeyアプリケーション/データ身体の部分の源はそれにデジタルに署名するかもしれません。 目的地がそのaを信じているなら、このように、ソースのものの誤りを正してください。
Crocker, et al Standards Track [Page 29] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[29ページ]RFC1848のMIME Object Security Services1995年10月
public key is available locally and if the destination believes the source would convey accurate data, then the contents of the application/mosskey-data from the source could be believed to be accurate.
公開鍵は局所的に利用可能です、そして、目的地が、ソースが正確なデータを伝えると信じているなら、ソースからのmosskeyアプリケーション/データのコンテンツは正直なところ信じられるかもしれません。
NOTE: Insofar as a certificate represents a mechanism by which a
third party vouches for the binding between a name and a public
key, the signing of an application/mosskey-data body part is a
similar mechanism.
以下に注意してください。 証明書が第三者が名前と公開鍵の間の結合を保証するメカニズムを表す限り、mosskeyアプリケーション/データ身体の部分の署名は同様のメカニズムです。
(1) MIME type name: application
(1) MIMEの種類名: アプリケーション
(2) MIME subtype name: mosskey-data
(2) MIME「副-タイプ」は以下を命名します。 mosskey-データ
(3) Required parameters: none
(3) 必要なパラメタ: なし
(4) Optional parameters: none
(4)の任意のパラメタ: なし
(5) Encoding considerations: quoted-printable is always sufficient.
(5) 問題をコード化します: いつも引用されて印刷可能であるのは、そうです。十分。
(6) Security Considerations: none
(6) セキュリティ問題: なし
The content of this body part corresponds to the following production.
この身体の部分の内容は以下の生産に対応しています。
<mosskeydata> ::= <version>
( <publickeydata> / <certchain> / <crlchain> )
<mosskeydata>:、:= <バージョン>。(<publickeydata>/<certchain>/<crlchain>)
<version> ::= "Version:" "5" CRLF
<バージョン>:、:= 「バージョン:」 「5インチのCRLF」
<publickeydata> ::= "Key:" "PK" "," <publickey> ","
<id-subset> CRLF
<publickeydata>:、:= 「キー:」 「"PK"」、」 <パブリックキー>、」、」 <イド部分集合>CRLF
<certchain> ::= <cert> *( [ <crl> ] <cert> )
<certchain>:、:= <本命>*([<crl>]<本命>)
<crlchain> ::= 1*( <crl> [ <cert> ] )
<crlchain>:、:= 1*(<crl>[<本命>])
<cert> ::= "Certificate:" <encbin> CRLF
<本命>:、:= 「以下を証明してください」 <encbin>CRLF
<crl> ::= "CRL:" <encbin> CRLF
<crl>:、:= 「CRL:」 <encbin>CRLF
This content type is used to transfer public keys, certificate chains, or Certificate Revocation List (CRL) chains. The information in the body part is entirely independent of any other body part. (Note that the converse is not true: the validity of a protected body part cannot be determined without the proper public keys, certificates, or current CRL information.) As such, the application/mosskey-data content type is an independent body part.
このcontent typeは、公開鍵、証明書チェーン、またはCertificate Revocation List(CRL)チェーンを移すのに使用されます。 身体の部分の情報はいかなる他の身体の部分からも完全に独立しています。 (逆が本当でないことに注意してください: 保護された身体の部分の正当性は適切な公開鍵も、証明書も、または現在のCRL情報なしで決定できません。) そういうものとして、mosskeyアプリケーション/データcontent typeは独立機関部分です。
Crocker, et al Standards Track [Page 30] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[30ページ]RFC1848のMIME Object Security Services1995年10月
The <publickeydata> production contains exactly one public key. It is used to bind a public key with its corresponding name form and key selector. It is recommended that when responders are returning this information that the enclosing body part be digitally signed by the responder in order to protect the information. The <id-subset> token is defined in Section 4.2.4.
<publickeydata>生産はまさに1つの公開鍵を含んでいます。 それは、その対応する名前フォームと主要なセレクタで公開鍵を縛るのに使用されます。 応答者がこの情報を返しているとき、それは情報を保護するために応答者によってデジタルに署名されて、同封ボディーが離れることが勧められます。 <イド、-部分集合>トークンはセクション4.2で.4に定義されます。
The <certchain> production contains one certificate chain. A certificate chain starts with the requested certificate and continues with the certificates of subsequent issuers. Each issuer certificate included must have issued the preceding certificate. For each issuer, a CRL may be supplied. A CRL in the chain belongs to the immediately following issuer. Therefore, it potentially contains the immediately preceding certificate.
<certchain>生産は1つの証明書チェーンを含みます。 証明書チェーンは、要求された証明書から始まって、その後の発行人の証明書を続行します。 それぞれの発行人証明書を含んでいると、前の証明書は発行されたに違いありません。 各発行人において、CRLを供給するかもしれません。 チェーンにおけるCRLはすぐに次の発行人のものです。 したがって、それは潜在的にすぐに前の証明書を含んでいます。
The <crlchain> production contains one certificate revocation list chain. The CRLs in the chain begin with the requested CRL and continue with the CRLs of subsequent issuers. The issuer of each CRL is presumed to have issued a certificate for the issuer of the preceding CRL. For each CRL, the issuer's certificate may be supplied. A certificate in the chain must belong to the issuer of the immediately preceding CRL.
<crlchain>生産は1つの証明書失効リストチェーンを含みます。 チェーンにおけるCRLsは要求されたCRLと共に始まって、その後の発行人のCRLsを続行します。 それぞれのCRLの発行人は前のCRLの発行人のためにあえて証明書を下付されました。 各CRLにおいて、発行人の証明書を提供するかもしれません。 チェーンにおける証明書はすぐに前のCRLの発行人のものなければなりません。
The relationship between a certificate and an immediately preceding CRL is the same in both <certchain> and <crlchain>. In a <certchain> the CRLs are optional. In a <crlchain> the certificates are optional.
証明書とすぐに前のCRLとの関係は<certchain>と<crlchain>の両方で同じです。 <certchain>では、CRLsは任意です。 <crlchain>では、証明書は任意です。
6. Examples
6. 例
Each example is included as a separate section for ease of reference.
各例は別々のセクションとして参照する場合に便利なように含まれています。
6.1. Original Message Prepared for Protection
6.1. オリジナルのメッセージは保護の用意をしました。
Except as explicitly indicated, the following message is used as the message to be protected.
明らかに示されるのを除いて、以下のメッセージは保護されるべきメッセージとして使用されます。
To: Ned Freed <ned@innosoft.com>
Subject: Hi Ned!
To: ネッド Freed <ned@innosoft.com 、gt;、Subject: こんにちは、ネッド!
How do you like the new MOSS?
新しいモスはいかがでしょうか?
Jim
ジム
Crocker, et al Standards Track [Page 31] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[31ページ]RFC1848のMIME Object Security Services1995年10月
6.2. Sign Text of Original Message
6.2. オリジナルのメッセージのサインテキスト
When the text of the original message is signed, it will look like this, where lines with an ampersand '&' are digitally signed (note the use of the public key identifier with the included email name identifier, on the lines marked with an asterisk '*'):
オリジナルのメッセージのテキストが署名されるとき、これに似るでしょう、アンパーサンド'&'がある系列がデジタルに署名されるところで(公開鍵識別子の識別子という含まれているメール名がアスタリスク'*'でマークされた系列にある使用に注意してください):
To: Ned Freed <ned@innosoft.com>
Subject: Hi Ned!
MIME-Version: 1.0
Content-Type: multipart/signed;
protocol="application/moss-signature";
micalg="rsa-md5"; boundary="Signed Boundary"
To: ネッド Freed <ned@innosoft.com 、gt;、Subject: こんにちは、ネッド! MIMEバージョン: 1.0コンテントタイプ: 複合か署名される。 =「こけアプリケーション/署名」について議定書の中で述べてください。 micalgは"rsa-md5""と等しいです。 「境界であると署名される」境界=
--Signed Boundary
& Content-Type: text/plain; charset="us-ascii"
& Content-ID: <21436.785186814.2@tis.com>
&
& How do you like the new MOSS?
&
& Jim
--署名している境界とコンテントタイプ: テキスト/平野。 charsetが等しい、「私たち、-、ASCII、」 コンテントID: <21436.785186814.2@tis.com>、Howは新しいモス?のようにあなたをします。 ジム
--Signed Boundary
Content-Type: application/moss-signature
Content-ID: <21436.785186814.1@tis.com>
Content-Transfer-Encoding: quoted-printable
--署名している境界コンテントタイプ: こけアプリケーション/署名コンテントID: <21436.785186814の.1@tis.comの>の満足している転送コード化: 引用されて印刷可能です。
Version: 5
* Originator-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4f=
* qQ61aoC1fO6BekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8=
* KRGJ9wh1HU4TrghGdhn0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,=
* 2,galvin@tis.com
MIC-Info: RSA-MD5,RSA,PnEvyFV3sSyTSiGh/HFgWUIFa22jbHoTrFIMVERf=
MZXUKzFsHbmKtIowJlJR56OoImo+t7WjRfzpMH7MOKgPgzRnTwk0T5dOcP/lfb=
sOVJjleV7vTe9yoNp2P8mi/hs7
バージョン: 5 *創始者ID: PK、MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4f=*qQ61aoC1fO6BekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8=*KRGJ9wh1HU4TrghGdhn0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB(アン)は*2、 galvin@tis.com MIC-インフォメーションと等しいです: RSA-MD5、RSA、PnEvyFV3sSyTSiGh/HFgWUIFa22jbHoTrFIMVERf= MZXUKzFsHbmKtIowJlJR56OoImo+t7WjRfzpMH7MOKgPgzRnTwk0T5dOcP/lfb= sOVJjleV7vTe9yoNp2P8mi/hs7
--Signed Boundary--
--境界であると署名されます--
6.3. Sign Headers and Text of Original Message
6.3. オリジナルのメッセージのサインヘッダーとテキスト
If, instead, we choose to protect the headers with the text of the original message, it will look like this, where lines with an ampersand '&' are encrypted:
私たちが、オリジナルのメッセージのテキストでヘッダーを保護するのを代わりに選ぶと、これに似るでしょう、アンパーサンド'&'がある系列が暗号化されているところで:
Crocker, et al Standards Track [Page 32] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[32ページ]RFC1848のMIME Object Security Services1995年10月
To: Ned Freed <ned@innosoft.com>
Subject: Hi Ned!
MIME-Version: 1.0
Content-Type: multipart/signed;
protocol="application/moss-signature";
micalg="rsa-md5"; boundary="Signed Boundary"
To: ネッド Freed <ned@innosoft.com 、gt;、Subject: こんにちは、ネッド! MIMEバージョン: 1.0コンテントタイプ: 複合か署名される。 =「こけアプリケーション/署名」について議定書の中で述べてください。 micalgは"rsa-md5""と等しいです。 「境界であると署名される」境界=
--Signed Boundary
& Content-Type: message/rfc822
& Content-ID: <21468.785187044.2@tis.com>
&
& To: Ned Freed <ned@innosoft.com>
& Subject: Hi Ned!
&
&
& How do you like the new MOSS?
&
& Jim
--署名している境界とコンテントタイプ: メッセージ/rfc822とコンテントID: <21468.785187044.2@tis.com>、To: ネッド Freed <ned@innosoft.com 、gt;、Subject: こんにちは、ネッド! 新しいモス?はいかがです。 ジム
--Signed Boundary
Content-Type: application/moss-signature
Content-ID: <21468.785187044.1@tis.com>
Content-Transfer-Encoding: quoted-printable
--署名している境界コンテントタイプ: こけアプリケーション/署名コンテントID: <21468.785187044の.1@tis.comの>の満足している転送コード化: 引用されて印刷可能です。
Version: 5
Originator-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4f=
qQ61aoC1fO6BekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8=
KRGJ9wh1HU4TrghGdhn0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,=
2,galvin@tis.com
MIC-Info: RSA-MD5,RSA,ctbDBgkYtFW1sisb5w4/Y/p94LftgQ0IrEn3d6WT=
wjfxFBvAceVWfawsZPLijVKZUYtbIqJmjKtzTJlagBawfA/KhUsvTZdR6Dj+4G=
d8dBBwMKvqMKTHAUxGXYxwNdbK
バージョン: 5創始者ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4f= qQ61aoC1fO6BekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8= KRGJ9wh1HU4TrghGdhn0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,= 2,galvin@tis.com MIC-Info: RSA-MD5、RSA、ctbDBgkYtFW1sisb5w4/Y/p94LftgQ0IrEn3d6WT=wjfxFBvAceVWfawsZPLijVKZUYtbIqJmjKtzTJlagBawfA/KhUsvTZdR6Dj+4Gはd8dBBwMKvqMKTHAUxGXYxwNdbKと等しいです。
--Signed Boundary--
--境界であると署名されます--
6.4. Encrypt Text of a Message
6.4. メッセージのテキストを暗号化してください。
If we choose to encrypt the text of the following message, that is, encrypt the lines marked with asterisk '*':
私たちが、以下のメッセージのテキストを暗号化するのを選ぶなら、すなわち、アスタリスク'*'でマークされた系列を暗号化してください:
To: Jim Galvin <galvin@tis.com>
Subject: an encrypted message
To: ジム Galvin <galvin@tis.com 、gt;、Subject: 暗号化メッセージ
* How do you like the new MOSS?
*
* Jim
* 新しいモスはいかがでしょうか? * * ジム
Crocker, et al Standards Track [Page 33] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[33ページ]RFC1848のMIME Object Security Services1995年10月
the message would look as follows (note the use of the email name identifier, on the line marked with an asterisk '*'):
メッセージは以下の通りに見えるでしょう(アスタリスク'*'でマークされた系列における識別子というメール名の使用に注意してください):
To: Jim Galvin <galvin@tis.com>
Subject: an encrypted message
MIME-Version: 1.0
Content-Type: multipart/encrypted;
protocol="application/moss-keys";
boundary="Encrypted Boundary"
To: ジム Galvin <galvin@tis.com 、gt;、Subject: 暗号化メッセージMIMEバージョン: 1.0コンテントタイプ: 複合か暗号化される。 =「こけアプリケーション/キー」について議定書の中で述べてください。 境界=は「境界を暗号化しました」。
--Encrypted Boundary
Content-Type: application/moss-keys
Content-ID: <21535.785187667.1@tis.com>
Content-Transfer-Encoding: quoted-printable
--暗号化された境界コンテントタイプ: こけアプリケーション/キーコンテントID: <21535.785187667の.1@tis.comの>の満足している転送コード化: 引用されて印刷可能です。
Version: 5
DEK-Info: DES-CBC,D488AAAE271C8159
* Recipient-ID: EN,2,galvin@tis.com
Key-Info: RSA,ISbC3IR01BrYq2rp493X+Dt7WrVq3V3/U/YXbxOTY5cmiy1/=
7NvSqqXSK/WZq05lN99RDUQhdNxXI64ePAbFWQ6RGoiCrRs+Dc95oQh7EFEPoT=
9P6jyzcV1NzZVwfp+u
バージョン: 5DEK-インフォメーション: デス-CBC、D488AAAE271C8159*受取人ID: アン、2、 galvin@tis.com の主要なインフォメーション: RSA、ISbC3IR01BrYq2rp493X+Dt7WrVq3V3/U/YXbxOTY5cmiy1/=7NvSqqXSK/WZq05lN99RDUQhdNxXI64ePAbFWQ6RGoiCrRs+Dc95oQh7EFEPoTは9P6jyzcV1NzZVwfp+uと等しいです。
--Encrypted Boundary
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
--暗号化された境界コンテントタイプ: 八重奏アプリケーション/ストリームContent転送コード化: base64
AfR1WSeyLhy5AtcX0ktUVlbFC1vvcoCjYWy/yYjVj48eqzUVvGTGMsV6MdlynU
d4jcJgRnQIQvIxm2VRgH8W8MkAlul+RWGu7jnxjp0sNsU562+RZr0f4F3K3n4w
onUUP265UvvMj23RSTguZ/nl/OxnFM6SzDgV39V/i/RofqI=
AfR1WSeyLhy5AtcX0ktUVlbFC1vvcoCjYWy/yYjVj48eqzUVvGTGMsV6MdlynU d4jcJgRnQIQvIxm2VRgH8W8MkAlul+RWGu7jnxjp0sNsU562+RZr0f4F3K3n4w onUUP265UvvMj23RSTguZ/nl/OxnFM6SzDgV39V/i/RofqI=
--Encrypted Boundary--
--境界を暗号化します--
Crocker, et al Standards Track [Page 34] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[34ページ]RFC1848のMIME Object Security Services1995年10月
6.5. Encrypt the Signed Text of a Message
6.5. メッセージの署名しているテキストを暗号化してください。
If, instead, we choose to sign the text before we encrypt it, the structure would be as follows, where lines with an asterisk '*' are digitally signed and lines with an ampersand '&' are encrypted:
私たちが、私たちがそれを暗号化する前にテキストに署名するのを代わりに選ぶなら、構造は以下の通りでしょう、アスタリスク'*'がある系列がデジタルに署名されて、アンパーサンド'&'がある系列が暗号化されているところで:
Content-Type: multipart/encrypted;
protocol="application/moss-keys";
boundary="Encrypted Boundary"
コンテントタイプ: 複合か暗号化される。 =「こけアプリケーション/キー」について議定書の中で述べてください。 境界=は「境界を暗号化しました」。
--Encrypted Boundary
Content-Type: application/moss-keys
--暗号化された境界コンテントタイプ: こけアプリケーション/キー
KEY INFORMATION
主要な情報
--Encrypted Boundary
Content-Type: application/octet-stream
--暗号化された境界コンテントタイプ: 八重奏アプリケーション/ストリーム
& Content-Type: multipart/signed;
& protocol="application/moss-signature";
& micalg="rsa-md5"; boundary="Signed Boundary"
&
& --Signed Boundary
& * Content-Type: text/plain
& *
& * How do you like the new MOSS?
& *
& * Jim
&
& --Signed Boundary
& Content-Type: application/moss-signature
&
& SIGNATURE INFORMATION
&
& --Signed Boundary--
コンテントタイプ: 複合か署名される。 プロトコル=「こけアプリケーション/署名」。 micalg="rsa-md5""。 境界であると署名されました。境界=、「」 --境界と*コンテントタイプであると署名されました: テキスト/平野と*、*新しいモス?はいかがです。 *と*ジム、--署名している境界とコンテントタイプ: こけアプリケーション/署名、SIGNATURE INFORMATION、--署名しているBoundary--
--Encrypted Boundary--
--境界を暗号化します--
where KEY INFORMATION and SIGNATURE INFORMATION are descriptive of the actual content that would appear in a real body part. The actual message would be like this:
KEY INFORMATIONとSIGNATURE INFORMATIONが実際の内容で描写的であるところに、それは本当の身体の部分に現れるでしょう。 実際のメッセージはこの似ているでしょう:
Crocker, et al Standards Track [Page 35] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[35ページ]RFC1848のMIME Object Security Services1995年10月
To: Jim Galvin <galvin@tis.com>
Subject: an encrypted message
MIME-Version: 1.0
Content-Type: multipart/encrypted;
protocol="application/moss-keys";
boundary="Encrypted Boundary"
To: ジム Galvin <galvin@tis.com 、gt;、Subject: 暗号化メッセージMIMEバージョン: 1.0コンテントタイプ: 複合か暗号化される。 =「こけアプリケーション/キー」について議定書の中で述べてください。 境界=は「境界を暗号化しました」。
--Encrypted Boundary
Content-Type: application/moss-keys
Content-ID: <21546.785188458.1@tis.com>
Content-Transfer-Encoding: quoted-printable
--暗号化された境界コンテントタイプ: こけアプリケーション/キーコンテントID: <21546.785188458の.1@tis.comの>の満足している転送コード化: 引用されて印刷可能です。
Version: 5
DEK-Info: DES-CBC,11CC89F8D90F1DFE
Recipient-ID: EN,2,galvin@tis.com
Key-Info: RSA,AZTtlEc6xm0vjkvtVUITUh7sz+nOuOwP0tsym6CQozD9IwVIJz=
Y8+vIfbh5BpR0kS6prq3EGFBFR8gRMUvbgHtEKPD/4ICQ7b6ssZ7FmKhl/cJC5rV=
jpb4EOUlwOXwRZ
バージョン: 5DEK-インフォメーション: DES-CBC、11CC89F8D90F1DFE受取人ID: アン、2、 galvin@tis.com の主要なインフォメーション: RSA、AZTtlEc6xm0vjkvtVUITUh7sz+nOuOwP0tsym6CQozD9IwVIJz= Y8+vIfbh5BpR0kS6prq3EGFBFR8gRMUvbgHtEKPD/4ICQ7b6ssZ7FmKhl/cJC5rV= jpb4EOUlwOXwRZ
--Encrypted Boundary
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
--暗号化された境界コンテントタイプ: 八重奏アプリケーション/ストリームContent転送コード化: base64
ZvWvtosDzRBXJzkDFFRb9Qjrgm2nDWg3zotJ3ZpExpWUG/aRJ7Vwd+PWkSfrDPJ5
2V/wkxwMrum6xJHZonrtyd0AvaztvriMm2zXTefzwpGG1i5zK47PBqreLA3HDTK2
U6B13vzpE8wMSVefzaCTSpXRSCh08ceVEZrIYS53/CKZV2/Sga71pGNlux8MsJpY
Lwdj5Q3NKocg1LMngMo8yrMAe+avMjfOnhui49Xon1Gft+N5XDH/+wI9qxI9fkQv
NZVDlWIhCYEkxd5ke549tLkJjEqHQbgJW5C+K/uxdiD2dBt+nRCXcuO0Px3yKRyY
g/9BgTf36padSHuv48xBg5YaqaEWpEzLI0Qd31vAyP23rqiPhfBn6sjhQ2KrWhiF
2l3TV8kQsIGHHZUkaUbqkXJe6PEdWWhwsqCFPDdkpjzQRrTuJH6xleNUFg+CG1V+
tL4IgMjQqm3KVojRXx8bG2auVN89NfwFswmoq4fXTrh3xyVS1VgxjKkcYI8SVVmk
YjCxVviJP3zO2UzBvCoMfADtBVBz1njYETtVGDO97uT39MqL85uEgiF4E5TkOj/m
04+88G0/vvN/RISKJiFQJ3FyVIB/ShX9Dixl8WCx3rxwN5g2QFLiyQVulzuNhimS
D4ZxEo7smcTsAXUjwSLRtdjmTTutw2GmFESUaIrY81NcpQJRPNAvF0IkN6ddwL4q
vzUS99vjQp15g9FUv82lHtHwhM18a9GokVG8xYOjBBsn9anp9abh4Tp/c/vpbunQ
UqnpV29rF4wj+8OwUOMi9ymGabBXAjw7DhNH2RdRVr1upQO896OX81VWB0LsA0cp
+ymxhTrEI+wCHcrsNMoRK/7zAeuAi0f1t9bN594EFlLoIrBnKEa1/OUAhMT7kG1f
NkSRnc8BZswIoPyRetsTurQfD40nsVHvNwE9Jz7wbBo00gd6blPADOUYFxfW5zu6
ubygBqJiKPM4II2fCdNj7CptfQcoRTeguKMVPLVmFg/EINuWBFm10GqlYT7p4zhf
zysV/3r5LVZ1E8armTCRJ2GoYG5h+SKcytaQ0IT8S2nLPCZl1hzdajsrqHFe8omQ
ZvWvtosDzRBXJzkDFFRb9Qjrgm2nDWg3zotJ3ZpExpWUG/aRJ7Vwd+PWkSfrDPJ5 2V/wkxwMrum6xJHZonrtyd0AvaztvriMm2zXTefzwpGG1i5zK47PBqreLA3HDTK2 U6B13vzpE8wMSVefzaCTSpXRSCh08ceVEZrIYS53/CKZV2/Sga71pGNlux8MsJpY Lwdj5Q3NKocg1LMngMo8yrMAe+avMjfOnhui49Xon1Gft+N5XDH/+wI9qxI9fkQv; NZVDlWIhCYEkxd5ke549tLkJjEqHQbgJW5C+K/uxdiD2dBt+nRCXcuO0Px3yKRyY g/9BgTf36padSHuv48xBg5YaqaEWpEzLI0Qd31vAyP23rqiPhfBn6sjhQ2KrWhiF2l3TV8kQsIGHHZUkaUbqkXJe6PEdWWhwsqCFPDdkpjzQRrTuJH6xleNUFg+CG1V+tL4IgMjQqm3KVojRXx8bG2auVN89NfwFswmoq4fXTrh3xyVS1VgxjKkcYI8SVVmk; YjCxVviJP3zO2UzBvCoMfADtBVBz1njYETtVGDO97uT39MqL85uEgiF4E5TkOj/m04+88G0/vvN/RISKJiFQJ3FyVIB/ShX9Dixl8WCx3rxwN5g2QFLiyQVulzuNhimS D4ZxEo7smcTsAXUjwSLRtdjmTTutw2GmFESUaIrY81NcpQJRPNAvF0IkN6ddwL4q vzUS99vjQp15g9FUv82lHtHwhM18a9GokVG8xYOjBBsn9anp9abh4Tp/c/vpbunQ UqnpV29rF4wj+8OwUOMi9ymGabBXAjw7DhNH2RdRVr1upQO896OX81VWB0LsA0cp+ymxhTrEI+wCHcrsNMoRK/7zAeuAi0f1t9bN594EFlLoIrBnKEa1/OUAhMT7kG1f NkSRnc8BZswIoPyRetsTurQfD40nsVHvNwE9Jz7wbBo00gd6blPADOUYFxfW5zu6 ubygBqJiKPM4II2fCdNj7CptfQcoRTeguKMVPLVmFg/EINuWBFm10GqlYT7p4zhf zysV/3r5LVZ1E8armTCRJ2GoYG5h+SKcytaQ0IT8S2nLPCZl1hzdajsrqHFe8omQ
--Encrypted Boundary--
--境界を暗号化します--
Crocker, et al Standards Track [Page 36] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[36ページ]RFC1848のMIME Object Security Services1995年10月
6.6. Protecting Audio Content
6.6. オーディオ内容を保護します。
In addition to text, the MOSS services as defined here will protect arbitrary body parts, for example, the following audio body part:
テキストに加えて、ここで定義されるモスサービスは例えば以下のオーディオ身体の部分の任意の身体の部分を保護するでしょう:
Content-Type: audio/basic
コンテントタイプ: オーディオ的であるか、または基本的です。
AUDIO DATA HERE
ここのオーディオデータ
6.6.1. Sign Audio Content
6.6.1. サインオーディオ内容
When signed an audio content would appear as follows, where lines with an ampersand '&' are digitally signed:
オーディオであると署名されると、アンパーサンド'&'がある系列がデジタルに署名されるところで内容は以下の通りに見えるでしょう:
Content-Type: multipart/signed;
protocol="application/moss-signature";
micalg="rsa-md5"; boundary="Signed Boundary"
コンテントタイプ: 複合か署名される。 =「こけアプリケーション/署名」について議定書の中で述べてください。 micalgは"rsa-md5""と等しいです。 「境界であると署名される」境界=
--Signed Boundary
& Content-Type: audio/basic
& Content-Transfer-Encoding: base64
&
& base64(AUDIO-DATA-HERE)
--署名している境界とコンテントタイプ: 基本的でコード化して、Contentが移しているオーディオ/: base64、base64(ここのオーディオデータ)
--Signed Boundary
Content-Type: application/moss-signature
--署名している境界コンテントタイプ: こけアプリケーション/署名
SIGNATURE-INFORMATION-HERE
ここの署名情報
--Signed Boundary--
--境界であると署名されます--
where AUDIO-DATA-HERE and SIGNATURE-INFORMATION-HERE are descriptive of the content that would appear in a real body part.
AUDIO-DATA-HEREとSIGNATURE情報HEREが内容で描写的であるところに、それは本当の身体の部分に現れるでしょう。
6.6.2. Encrypt Audio Content
6.6.2. オーディオ内容を暗号化してください。
When encrypted an audio content would appear as follows, where lines with an ampersand '&' are encrypted:
暗号化されると、アンパーサンド'&'がある系列が暗号化されているところでオーディオ内容は以下の通りに見えるでしょう:
Crocker, et al Standards Track [Page 37] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[37ページ]RFC1848のMIME Object Security Services1995年10月
Content-Type: multipart/encrypted;
protocol="application/moss-keys";
boundary="Encrypted Boundary"
コンテントタイプ: 複合か暗号化される。 =「こけアプリケーション/キー」について議定書の中で述べてください。 境界=は「境界を暗号化しました」。
--Encrypted Boundary
Content-Type: application/moss-keys
--暗号化された境界コンテントタイプ: こけアプリケーション/キー
KEY-INFORMATION-HERE
ここの主要な情報
--Encrypted Boundary
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
--暗号化された境界コンテントタイプ: 八重奏アプリケーション/ストリームContent転送コード化: base64
& Content-Type: audio/basic
&
& base64(encrypted(AUDIO-DATA-HERE))
コンテントタイプ: オーディオ的か基本的である、base64((ここのオーディオデータ)を暗号化します)
--Encrypted Boundary--
--境界を暗号化します--
where KEY-INFORMATION-HERE and AUDIO-DATA-HERE are descriptive of the content that would appear in a real body part.
KEY情報HEREとAUDIO-DATA-HEREが内容で描写的であるところに、それは本当の身体の部分に現れるでしょう。
7. Observations
7. 観測
The use of MIME and the framework defined by [7] exhibits several properties:
[7]によって定義されたMIMEとフレームワークの使用は数個の特性を示します:
(1) It allows arbitrary content types to be protected, not just the
body of an RFC822 message.
(1) それは、任意のcontent typeがRFC822メッセージのボディーであるだけではないのに保護されるのを許容します。
(2) It allows a message to contain several body parts which may or
may not be protected.
(2) それは保護されるかもしれないいくつかの身体の部分を含むメッセージを許容します。
(3) It allows the components of a multipart or message content to be
protected with different services.
(3) それは、複合かメッセージ内容の成分が異なったサービスで保護されるのを許容します。
The use of a MIME-capable user agent makes complex nesting of protected message body parts much easier. For example, the user can separately sign and encrypt a message. This allows complete separation of the confidentiality security service from the digital signature security service. That is, different key pairs could be used for the different services and could be protected separately.
MIME有能なユーザエージェントの使用で、保護されたメッセージ身体の部分の複雑な巣篭もりははるかに簡単になります。 例えば、ユーザは、別々にメッセージに署名して、暗号化できます。 これはデジタル署名セキュリティー・サービスから秘密性セキュリティー・サービスの完全分離を許容します。 すなわち、異なった主要な組を異なったサービスに使用できて、別々に保護できました。
Crocker, et al Standards Track [Page 38] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[38ページ]RFC1848のMIME Object Security Services1995年10月
This is useful for at least two reasons. First, some public key algorithms do not support both digital signatures and encryption; two key pairs would be required in this case. Second, an employee's company could be given access to the (private) decryption key but not the (private) signature key, thereby granting the company the ability to decrypt messages addressed to the employee in emergencies without also granting the company the ability to sign messages as the employee.
これは少なくとも2つの理由の役に立ちます。 まず最初に、いくつかの公開鍵アルゴリズムはデジタル署名と暗号化の両方をサポートしません。 主要な2組がこの場合必要でしょう。 2番目に、(個人的)の署名キーではなく、(個人的)の復号化キーへのアクセスを従業員の会社に与えることができました、その結果、非常時にまた、従業員としてメッセージに署名する能力を会社に与えないで従業員に扱われたメッセージを解読する能力を会社に与えます。
8. Comparison of MOSS and PEM Protocols
8. こけとPEMプロトコルの比較
MOSS differs from PEM in the following ways.
モスは以下の方法でPEMと異なっています。
(1) When using PEM, users are required to have certificates. When
using MOSS, users need only have a public/private key pair.
(1) PEMを使用するとき、ユーザには、証明書がなければなりません。 モスを使用するとき、ユーザには、公衆/秘密鍵組があるだけでよいです。
(2) MOSS broadens the allowable name forms that users may use to
identify their public keys, including arbitrary strings, email
addresses, or distinguished names.
(2) モスは形成というユーザが彼らの公開鍵を特定するのに使用するかもしれない許容できる名前を広くします、任意のストリング、Eメールアドレス、または分類名を含んでいて。
(3) PEM currently only supports text-based electronic mail messages
and the message text is required to be represented by the ASCII
character set with "<CR><LF>" line delimiters. These
restrictions no longer apply.
(3) PEMは現在テキストベースの電子メールメッセージをサポートするだけです、そして、メッセージ・テキストが、「<CR><LF>」系列デリミタがあるASCII文字の組で表されるのに必要です。 これらの制限はもう適用されません。
(4) The PEM specification currently requires that encryption
services be applied only to message bodies that have been
signed. By providing for each of the services separately, they
may be applied in any order according to the needs of the
requesting application.
(4) PEM仕様は、現在、暗号化サービスが署名されたメッセージ本体だけに適用されるのを必要とします。 別々にそれぞれのサービスに備えることによって、要求アプリケーションの必要性に従って、それらは順不同に適用されるかもしれません。
(5) MIME includes transfer encoding operations to ensure the
unmodified transfer of body parts. Therefore, unlike PEM, MOSS
does not need to include these functions.
(5) MIMEは身体の部分の変更されていない転送を確実にするために操作をコード化する転送を含んでいます。 したがって、PEMと異なって、モスはこれらの機能を含む必要はありません。
(6) PEM specifies a Proc-Type: header field to identify the type of
processing that was performed on the message. This
functionality is subsumed by the MIME Content-Type: headers.
The Proc-Type: header also includes a decimal number that is
used to distinguish among incompatible encapsulated header field
interpretations which may arise as changes are made to the PEM
standard. This functionality is replaced by the Version: header
(6) PEMはProc-タイプを指定します: それを処理するタイプを特定するヘッダーフィールドはメッセージに実行されました。 この機能性はMIMEコンテントタイプによって包括されています: ヘッダー。 Proc-タイプ: また、ヘッダーは変更をPEM規格にするとき起こるかもしれない両立しないカプセル化されたヘッダーフィールド解釈の中で区別するのに使用される10進数を入れます。 この機能性をバージョンに取り替えます: ヘッダー
Crocker, et al Standards Track [Page 39] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[39ページ]RFC1848のMIME Object Security Services1995年10月
specified in this document.
このドキュメントでは、指定されています。
(7) PEM specifies a Content-Domain: header, the purpose of which is
to describe the type of the content which is represented within
a PEM message's encapsulated text. This functionality is
subsumed by the MIME Content-Type: headers.
(7) PEMはContent-ドメインを指定します: ヘッダー。(それの目的はそのヘッダーのためにPEMメッセージのカプセル化されたテキストの中に表される内容のタイプについて説明することです)。 この機能性はMIMEコンテントタイプによって包括されています: ヘッダー。
(8) The PEM specifications include a document that defines new types
of PEM messages, specified by unique values used in the Proc-
Type: header, to be used to request certificate and certificate
revocation list information. This functionality is subsumed by
two new content types specified in this document:
application/mosskey- request and application/mosskey-data.
(8) PEM仕様はProcタイプで使用されるユニークな値によって指定された新しいタイプに関するPEMメッセージを定義するドキュメントを含んでいます: ヘッダーは、要求するのにおいて使用されているために、取消しリスト情報を証明して、証明してください。 この機能性は本書では指定された2つの新しいcontent typeによって包括されています: アプリケーション/mosskey要求とmosskeyアプリケーション/データ。
(9) The header fields having to do with certificates (Originator-
Certificate: and Issuer-Certificate:) and CRLs (CRL:) are
relegated for use only in the application/mosskey-data and
application/mosskey-request content types and are no longer
allowed in the header portion of a PEM signed or encrypted
message. This separates key management services from the
digital signature and encryption services.
(9) ヘッダーが証明書(創始者以下を証明してください、そして、以下をIssuer証明する)と関係があって、CRLsをさばく、(CRL:、)、mosskeyアプリケーション/データとmosskeyアプリケーション/要求content typeだけにおける使用のために左遷されて、もう署名されるPEMか暗号化メッセージのヘッダー部分に許容されていません。 これはデジタル署名と暗号化サービスとかぎ管理サービスを切り離します。
(10) The grammar specified here explicitly separates the header
fields that may appear for the encryption and signature security
services. It is the intent of this document to specify a
precise expression of the allowed header fields; there is no
intent to disallow the functionality of combinations of
encryption and signature security found in [3].
(10) ここで明らかに指定された文法は暗号化と署名セキュリティー・サービスの弁護に出廷するかもしれないヘッダーフィールドを切り離します。 許容ヘッダーフィールドの正確な式を指定するのは、このドキュメントの意図です。 [3]で見つけられた暗号化と署名セキュリティの組み合わせの機能性を禁じる意図が全くありません。
(11) With the separation of the encryption and signature security
services, there is no need for a MIC-Info: field in the headers
associated with an encrypted message.
(11) 暗号化と署名セキュリティー・サービスの分離と共に、MIC-インフォメーションの必要は全くありません: 暗号化メッセージに関連しているヘッダーでは、さばきます。
(12) In [3], when asymmetric key management is used, an Originator-ID
field is required in order to identify the private key used to
sign the MIC argument in the MIC-Info: field. Because no MIC-
Info: field is associated with the encryption security service
under asymmetric key management, there is no requirement in that
case to include an Originator-ID field.
(12) 非対称のかぎ管理が使用されているとき、[3]では、Originator-ID分野がMIC-インフォメーションにおけるMIC議論に署名するのに使用される秘密鍵を特定するのに必要です: さばきます。 MICインフォメーションがありません: 分野が非対称のかぎ管理での暗号化セキュリティー・サービスに関連している、Originator-ID分野を含むように、要件は全くその場合ありません。
(13) The protocol specified here explicitly excludes symmetric key
(13) ここで明らかに指定されたプロトコルは対称鍵を除きます。
Crocker, et al Standards Track [Page 40] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[40ページ]RFC1848のMIME Object Security Services1995年10月
management.
管理。
(14) This document requires all data that is to be digitally signed
to be represented in 7bit form.
(14) このドキュメントは、デジタルに署名されることになっているすべてのデータが7ビットのフォームに表されるのを必要とします。
9. Security Considerations
9. セキュリティ問題
This entire document is about security.
この全体のドキュメントはセキュリティに関するものです。
10. Acknowledgements
10. 承認
David H. Crocker suggested the use of a multipart structure for the MIME and PEM interaction, which has evolved into the MOSS protocol.
デヴィッド・H.クロッカーは複合構造のMIMEとPEM相互作用の使用を勧めました。(それは、モスプロトコルに発展しました)。
The MOSS protocol is a direct descendant of the PEM protocol. The authors gratefully acknowledge the editors of those specification, especially John Linn and Steve Kent. This work would not have been possible had it not been for all of the PEM developers, users, and interested persons who are always present on the PEM developers mailing list and at PEM working group meetings at IETF meetings, especially, Amanda Walker, Bob Juenemann, Steve Dusse, Jeff Thomson, and Rhys Weatherly.
モスプロトコルはPEMプロトコルのダイレクト子孫です。 作者はそれらのエディタのために感謝して仕様、特にジョン・リン、およびスティーブ・ケントを承認します。 特にPEM開発者、ユーザ、IETFミーティングにPEM開発者メーリングリストの上と、そして、PEMワーキンググループミーティングにいつも出席している関心がある人々、アマンダ・ウォーカー、ボブJuenemann、スティーブDusse、ジェフ・トムソン、およびリスWeatherlyのすべてがなければ、この仕事は可能でなかったでしょう。
11. References
11. 参照
[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月。
[3] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
I: Message Encryption and Authentication Procedures", RFC 1421,
IAB IRTF PSRG, IETF PEM WG, February 1993.
[3] リン、J.、「インターネット電子メールのためのプライバシー増進:」 部分I: 「メッセージ暗号化と認証手順」、RFC1421、IAB IRTF PSRG、IETF PEM WG、2月1993日
[4] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part
II: Certificate-Based Key Management", RFC 1422, BBN
Communications, February 1993.
[4] ケント、S.、「インターネット電子メールのためのプライバシー増進:」 パートII: 「証明書ベースのKey Management」、RFC1422、BBNコミュニケーション、1993年2月。
[5] Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
Part III: Algorithms, Modes, and Identifiers", RFC 1423, Trusted
Information Systems, February 1993.
[5]Balenson、D.、「インターネット電子メールのためのプライバシー増進:」 パートIII: 「アルゴリズム、モード、および識別子」、RFC1423、信じられた情報システム、2月1993
Crocker, et al Standards Track [Page 41] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[41ページ]RFC1848のMIME Object Security Services1995年10月
[6] Kaliski, B., "Privacy Enhancement for Internet Electronic Mail:
Part IV: Key Certification and Related Services", RFC 1424, RSA
Laboratories, February 1993.
[6]Kaliski、B.、「インターネット電子メールのためのプライバシー増進:」 パートIV: 「主要な証明の、そして、関連のサービス」、RFC1424、RSA研究所、1993年2月。
[7] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, Trusted Information Systems and Innosoft, September
1995.
[7] ガルビン、J.、マーフィー、S.、クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMultiparts:」 「署名していて複合の/が暗号化した複合/」とRFC1847と信じられた情報システムとInnosoft、1995年9月。
[8] The Directory -- Models. X.501, 1988. Developed in
collaboration, and technically aligned, with ISO 9594-2.
[8]、ディレクトリ--モデル。 X.501、1988。 共同で開発されて、ISO9594-2に技術的に並べられます。
[9] The Directory -- Authentication Framework. X.509, 1988.
Developed in collaboration, and technically aligned, with ISO
9594-8.
[9]、ディレクトリ--認証フレームワーク。 X.509、1988。 共同で開発されて、ISO9594-8に技術的に並べられます。
Crocker, et al Standards Track [Page 42] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[42ページ]RFC1848のMIME Object Security Services1995年10月
12. Authors' Addresses
12. 作者のアドレス
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
James M. Galvin Trusted Information Systems 3060 Washington Road Glenwood, MD 21738
ジェームス・M.ガルビンは情報システム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
Sandra Murphy Trusted Information Systems 3060 Washington Road Glenwood, MD 21738
サンドラ・マーフィーは情報システム3060ワシントン道路グレンウッド、MD 21738を信じました。
Phone: +1 301 854 6889 Fax: +1 301 854 5363 EMail: murphy@tis.com
以下に電話をしてください。 +1 301 854、6889Fax: +1 5363年の301 854メール: murphy@tis.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
Crocker, et al Standards Track [Page 43] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[43ページ]RFC1848のMIME Object Security Services1995年10月
Appendix A: Collected Grammar
付録A: 集まっている文法
The version of the grammar in this document is as follows:
文法のバージョンは本書では以下の通りです:
<version> ::= "Version:" "5" CRLF
<バージョン>:、:= 「バージョン:」 「5インチのCRLF」
The following grammar tokens are used throughout this specification:
以下の文法トークンはこの仕様中で使用されます:
<encbin> ::= 1*<encbingrp>
<encbin>:、:= 1*<encbingrp>。
<encbingrp> ::= 4*4<encbinchar>
<encbingrp>:、:= 4*4<encbinchar>。
<encbinchar> ::= <ALPHA> / <DIGIT> / "+" / "/" / "="
<encbinchar>:、:= 「<アルファー>/<ケタ>/「+」/」/、」 /は「等しいです」。
<hexchar> ::= <DIGIT> / "A" / "B" / "C" / "D" / "E" / "F"
; no lower case
<hexchar>:、:= <ケタ/「B」/>/「C」/「D」/「E」/「F」。 小文字がありません。
The content of an application/moss-signature body part is as follows:
こけアプリケーション/署名身体の部分の内容は以下の通りです:
<mosssig> ::= <version> ( 1*<origasymflds> )
<mosssig>:、:= <バージョン>。(1*<origasymflds>)
<version> ::= "Version:" "5" CRLF
<バージョン>:、:= 「バージョン:」 「5インチのCRLF」
<origasymflds> ::= <origid> <micinfo>
<origasymflds>:、:= <origid><micinfo>。
<origid> ::= "Originator-ID:" <id> CRLF
<origid>:、:= 「創始者ID:」 <イド>CRLF
<micinfo> ::= "MIC-Info:" <micalgid> "," <ikalgid> ","
<asymsignmic> CRLF
<micinfo>:、:= 「MIC-インフォメーション:」 」 「<micalgid>」、<ikalgid>、」、」 <asymsignmic>CRLF
The content of an application/moss-keys body part is as follows:
こけアプリケーション/キー身体の部分の内容は以下の通りです:
<mosskeys> ::= <version> <dekinfo> 1*<recipasymflds>
<mosskeys>:、:= <バージョン><dekinfo>1*<recipasymflds>。
<version> ::= "Version:" "5" CRLF
<バージョン>:、:= 「バージョン:」 「5インチのCRLF」
<dekinfo> ::= "DEK-Info" ":" <dekalgid>
[ "," <dekparameters> ] CRLF
<dekinfo>:、:= 「「DEK-インフォメーション」」:、」 <dekalgid>、[「」、<dekparameters>] CRLF
<recipasymflds> ::= <recipid> <asymkeyinfo>
<recipasymflds>:、:= <recipid><asymkeyinfo>。
<recipid> ::= "Recipient-ID:" <id> CRLF
<recipid>:、:= 「受取人ID:」 <イド>CRLF
<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF
<asymkeyinfo>:、:= 「「主要なインフォメーション」」:、」 」 「<ikalgid>」、<asymencdek>CRLF
Crocker, et al Standards Track [Page 44] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[44ページ]RFC1848のMIME Object Security Services1995年10月
Identifiers are defined as follows:
識別子は以下の通り定義されます:
<id> ::= <id-subset> / <id-publickey> / <id-issuer>
<イド>:、:= <イド部分集合<イド>/パブリックキー<イド>/発行人>。
<id-subset> ::= <id-email> / <id-string> / <id-dname>
<イド部分集合>:、:= <イドメール<イド>/ストリング<イド>/dname>。
<id-email> ::= "EN" "," <keysel> "," <emailstr> CRLF
<イドメール>:、:= 」 「「アン」」、<keysel>、」、」 <emailstr>CRLF
<id-string> ::= "STR" "," <keysel> "," <string> CRLF
<イドストリング>:、:= 」 「"STR"」、<keysel>、」、」 <ストリング>CRLF
<id-dname> ::= "DN" "," <keysel> "," <dnamestr> CRLF
<イドdname>:、:= 」 「"DN"」、<keysel>、」、」 <dnamestr>CRLF
<id-publickey> ::= "PK" "," <publickey> [ "," <id-subset> ] CRLF
<イドパブリックキー>:、:= 「"PK"」、」 <パブリックキー>、[「>] 」 <イド部分集合CRLF
<id-issuer> ::= "IS" "," <dnamestr> "," <serial> CRLF
<イド発行人>:、:= 」 「「存在」」、<のdnamestr>、」、」 <の連続の>CRLF
<keysel> ::= 1*<hexchar>
; hex dump of a non-null sequence of octets
<keysel>:、:= 1*<hexchar>。 八重奏の非零列の十六進法ダンプ
<emailstr> ::= <addr-spec> / <route-addr>
; an electronic mail address as defined by
; these two tokens from RFC822
<emailstr>:、:= <addr-仕様<ルート>/addr>。 定義される電子メールアドレス。 RFC822からのこれらの2つのトークン
<string> ::= ; a non-null sequence of characters
<ストリング>:、:= ; キャラクタの非零列
<dnamestr> ::= <encbin>
; a printably encoded, ASN.1 encoded
; distinguished name (as defined by the 'Name'
; production specified in X.501 [8])
<dnamestr>:、:= <encbin>。 コード化されたprintably、コード化されたASN.1。 分類名(定義される、'名前'で; 生産はX.501[8])で指定しました。
<publickey> ::= <encbin>
; a printably encoded, ASN.1 encoded public
; key (as defined by the
; 'SubjectPublicKeyInfo' production specified
; in X.509 [9])
<パブリックキー>:、:= <encbin>。 printablyがコード化されて、ASN.1は公衆をコード化しました。 キー(; 生産が指定した'SubjectPublicKeyInfo';コネで、X.509[9])を定義します。
<serial> ::= 1*<hexchar>
; hex dump of a certificate serial number
<の連続の>:、:= 1*<hexchar>。 証明書通し番号の十六進法ダンプ
The content of an application/mosskey-request body part is as follows:
mosskeyアプリケーション/要求身体の部分の内容は以下の通りです:
<request> ::= <version>
( <subject> / <issuer> / <certification> )
<要求>:、:= <バージョン>。(<の対象の>/<発行人>/<証明>)
<version> ::= "Version:" "5" CRLF
<バージョン>:、:= 「バージョン:」 「5インチのCRLF」
Crocker, et al Standards Track [Page 45] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[45ページ]RFC1848のMIME Object Security Services1995年10月
<subject> ::= "Subject:" <id> CRLF
<の対象の>:、:= 「Subject:」 <イド>CRLF
<issuer> ::= "Issuer:" <id> CRLF
<発行人>:、:= 「発行人:」 <イド>CRLF
<certification> ::= "Certification:" <encbin> CRLF
<証明>:、:= 「証明:」 <encbin>CRLF
The content of an application/mosskey-data body part is as follows:
mosskeyアプリケーション/データ身体の部分の内容は以下の通りです:
<mosskeydata> ::= <version>
( <publickeydata> / <certchain> / <crlchain> )
<mosskeydata>:、:= <バージョン>。(<publickeydata>/<certchain>/<crlchain>)
<version> ::= "Version:" "5" CRLF
<バージョン>:、:= 「バージョン:」 「5インチのCRLF」
<publickeydata> ::= "Key:" "PK" "," <publickey> ","
<id-subset> CRLF
<publickeydata>:、:= 「キー:」 「"PK"」、」 <パブリックキー>、」、」 <イド部分集合>CRLF
<certchain> ::= <cert> *( [ <crl> ] <cert> )
<certchain>:、:= <本命>*([<crl>]<本命>)
<crlchain> ::= 1*( <crl> [ <cert> ] )
<crlchain>:、:= 1*(<crl>[<本命>])
<cert> ::= "Certificate:" <encbin> CRLF
<本命>:、:= 「以下を証明してください」 <encbin>CRLF
<crl> ::= "CRL:" <encbin> CRLF
<crl>:、:= 「CRL:」 <encbin>CRLF
Crocker, et al Standards Track [Page 46] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[46ページ]RFC1848のMIME Object Security Services1995年10月
Appendix B: Imported Grammar
付録B: 文法であるとインポートされます。
Options normally present in the grammar reprinted here which are illegal in MOSS are excluded in this reprinting, for the convenience of the reader.
通常、ここで増刷された文法における現在のモスで不法なオプションはこの翻刻で除かれます、読者の都合のために。
The following productions are taken from [5]. The grammar presented in [5] remains the authoritative source for these productions; they are repeated here for the convenience of the reader.
[5]から以下の創作を取ります。 [5]に提示された文法はこれらの創作のための権威筋のままで残っています。 それらは読者の都合のためにここで繰り返されます。
<dekalgid> ::= "DES-CBC"
<ikalgid> ::= "RSA"
<micalgid> ::= "RSA-MD2" / "RSA-MD5"
<dekalgid>:、:= "DES-CBC"<ikalgid>:、:= "RSA"<micalgid>:、:= 「RSA-MD2"/"RSA-MD5""
<dekparameters> ::= <DESCBCparameters>
<DESCBCparameters> ::= <IV>
<IV> ::= <hexchar16>
<hexchar16> ::= 16*16<hexchar>
<dekparameters>:、:= <DESCBCparameters><DESCBCparameters>:、:= <IV><IV>:、:= <hexchar16><hexchar16>:、:= 16*16<hexchar>。
<asymsignmic> ::= <RSAsignmic>
<RSAsignmic> ::= <encbin>
<asymsignmic>:、:= <RSAsignmic><RSAsignmic>:、:= <encbin>。
<asymencdek> ::= <RSAencdek>
<RSAencdek> ::= <encbin>
<asymencdek>:、:= <RSAencdek><RSAencdek>:、:= <encbin>。
The following productions are taken from [1]. The grammar presented in [1] remains the authoritative source for these productions; they are repeated here for the convenience of the reader.
[1]から以下の創作を取ります。 [1]に提示された文法はこれらの創作のための権威筋のままで残っています。 それらは読者の都合のためにここで繰り返されます。
<route-addr> ::= "<" [ <route> ] <addr-spec> ">"
addrを発送している<>:、:= "<"[<ルート>]<addr-仕様>">"
<route> ::= 1# ( "@" <domain> ) ":" ; path-relative
<ルート>:、:= 「1#@""<ドメイン(>)」:、」 ; 経路相対的です。
<addr-spec> ::= <local-part> "@" <domain>; global address
<addr-仕様>:、:= <の地方のパート>"@"<ドメイン>。 グローバルアドレス
<local-part> ::= <word> *( "." <word> ) ; uninterpreted
; case-preserved
<の地方のパート>:、:= <単語>*、(「. 」 <単語>、)、。 非解釈しました。 ケースで、保存されています。
<domain> ::= <sub-domain> *( "." <sub-domain> )
<ドメイン>:、:= <サブドメイン>*(「. 」 <サブドメイン>、)
<sub-domain> ::= <domain-ref> / <domain-literal>
<サブドメイン>:、:= <ドメイン審判>/<ドメイン文字通りの>。
<domain-ref> ::= <atom> ; symbolic
; reference
<ドメイン審判>:、:= <原子>。 シンボリック。 参照
<domain-literal>::= "[" *( <dtext> / <quoted-pair> ) "]"
<ドメイン文字通りの>:、:= 「[「*(<dtext>/<の引用された組の>)」]」
Crocker, et al Standards Track [Page 47] RFC 1848 MIME Object Security Services October 1995
クロッカー、他Standards Track[47ページ]RFC1848のMIME Object Security Services1995年10月
<dtext> ::= <any CHAR excluding "[", "]",
"\" & <CR>, & including
linear-white-space>
; => may be folded
<dtext>:、:= <、どんなCHAR除外、も「[「」、]、」、「\」と、<CR>と、直線的な余白>を含んでいます。 =>は折り重ねられるかもしれません。
<word> ::= <atom> / <quoted-string>
<単語>:、:= <原子>/<引用文字列>。
<quoted-string> ::= """ *( <qtext> / <quoted-pair> ) """
<引用文字列>:、:= 「「「*(<qtext>/<の引用された組の>)、「「」」
<qtext> ::= (any <CHAR> excepting """, "\", and CR,
and including <linear-white-space>)
<qtext>:、:= (どんな<CHAR>除外、も「「「「\」と、CRと、<直線的な余白>を含んでいる、)、」
<quoted-pair> ::= "\" <CHAR> ; may quote any
; char
<は、->を対にするように引用しました:、:= 「\」<炭の>。 いずれも引用するかもしれません。 炭
<linear-white-space> ::= 1*( [ CRLF ] <LWSP-char> )
; semantics = SPACE
; CRLF => folding
<直線的な余白>:、:= 1 *([CRLF]<LWSP-炭の>)。 意味論はSPACEと等しいです。 CRLFは>の折り重なりと等しいです。
<LWSP-char> ::= SPACE / HTAB ; semantics = SPACE
<LWSP-炭の>:、:= スペース/HTAB。 意味論はSPACEと等しいです。
<atom> ::= 1*(any <CHAR>
except <specials>, SPACE and <CTL>s)
<原子>:、:= 1*(<スペシャルの>、スペース、および<CTL>s以外のどんな<炭の>も)
<CHAR> ::= <any ASCII character>
<炭の>:、:= <はあらゆるASCII文字>です。
<CTL> ::= <any ASCII control character and DEL>
<CTL>:、:= <はあらゆるASCII制御文字とDEL>です。
<specials> ::= "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / "\" / <">
/ "." / "[" / "]"
; Must be in quoted-
; string, to use
; within a word.
<特別番組>:、:= 「「」 (「/」)」 /「<」 /">"/"@"/」、/」」 / ":" 「/「\」/<「>/」。」 / "[" / "]" ; 引用されるところにあるに違いありません。 使用へのストリング。 単語の中で。
<ALPHA> ::= <any ASCII alphabetic character>
; (101-132, 65.-90.)
; (141-172, 97.-122.)
<アルファー>:、:= <、どんなASCII英字>も。 (101-132, 65.-90.) ; (141-172, 97.-122.)
<DIGIT> ::= <any ASCII decimal digit>; (60-71, 48.-57.)
<ケタ>:、:= <、どんなASCII10進数字>も。 (60-71, 48.-57.)
Crocker, et al Standards Track [Page 48]
クロッカー、他のStandards Track[48ページ]
一覧
スポンサーリンク
