RFC3854 日本語訳
3854 Securing X.400 Content with Secure/Multipurpose Internet MailExtensions (S/MIME). P. Hoffman, C. Bonatti, A. Eggen. July 2004. (Format: TXT=32801 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Hoffman
Request for Comments: 3854 IMC
Category: Standards Track C. Bonatti
IECA
A. Eggen
FFI
July 2004
コメントを求めるワーキンググループP.ホフマン要求をネットワークでつないでください: 3854年のIMCカテゴリ: 標準化過程C.Bonatti IECA A.Eggen FFI2004年7月
Securing X.400 Content with Secure/Multipurpose Internet Mail
Extensions (S/MIME)
安全な/マルチパーパスインターネットメールエクステンションでX.400が内容であると機密保護します。(S/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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document describes a protocol for adding cryptographic signature and encryption services to X.400 content with Secure/Multipurpose Internet Mail Extensions (S/MIME).
このドキュメントは、Secure/マルチパーパスインターネットメールエクステンション(S/MIME)で暗号の署名と暗号化サービスをX.400内容に追加するためにプロトコルについて説明します。
1. Introduction
1. 序論
The techniques described in the Cryptographic Message Syntax [CMS] specification are general enough to support many different content types. The [CMS] specification thus provides many options for providing different security mechanisms. In order to ensure interoperability of systems within the X.400 community, it is necessary to specify the use of CMS features to protect X.400 content (called "CMS-X.400" in this document).
Cryptographic Message Syntax[CMS]仕様で説明されたテクニックは多くの異なったcontent typeをサポートするほど一般的です。 その結果、[CMS]仕様は異なったセキュリティー対策を提供するための多くのオプションを提供します。X.400共同体の中でシステムの相互運用性を確実にするために、X.400内容(本書では「cm-X.400」と呼ばれる)を保護するCMSの特徴の使用を指定するのが必要です。
1.1. Specification Overview
1.1. 仕様概要
This document is intended to be similar to the S/MIME Version 3.1 Message Specification [MSG] except that it is tailored to the requirements of X.400 content rather than Multipurpose Internet Mail Extensions (MIME).
それがマルチパーパスインターネットメールエクステンション(MIME)よりむしろX.400内容の要件に適合するのを除いて、このドキュメントがS/MIMEバージョン3.1Message Specification[MSG]と同様であることを意図します。
Hoffman, et al. Standards Track [Page 1] RFC 3854 Securing X.400 with S/MIME July 2004
ホフマン、他 2004年7月にS/MIMEでX.400を固定する標準化過程[1ページ]RFC3854
This document defines how to create an X.400 content type that has been cryptographically enhanced according to [CMS]. In order to create S/MIME messages carrying X.400 content, an S/MIME agent has to follow specifications in this document, as well as the specifications listed in [CMS]. This memo also defines new parameter values for the application/pkcs7-mime MIME type that can be used to transport those body parts.
このドキュメントは[CMS]に応じて暗号で高められたX.400content typeを作成する方法を定義します。 X.400内容を運ぶS/MIMEメッセージを作成するために、S/MIMEエージェントは本書では仕様に従わなければなりません、[CMS]にリストアップされた仕様と同様に。 また、このメモはそれらの身体の部分を輸送するのに使用できるpkcs7アプリケーション/パントマイムMIMEの種類のために新しいパラメタ値を定義します。
Throughout this document, there are requirements and recommendations made for how receiving agents handle incoming messages. There are separate requirements and recommendations for how sending agents create outgoing messages. In general, the best strategy is to "be liberal in what you receive and conservative in what you send". Most of the requirements are placed on the handling of incoming messages while the recommendations are mostly on the creation of outgoing messages.
このドキュメント中に、要件がありました、そして、推薦は受信エージェントがどう入力メッセージを扱うかになりました。 送付エージェントがどう送信されるメッセージを作成するか別々の要件と推薦があります。 「一般に、最も良い戦略はあなたが受けるもので寛容であって、あなたが送るもので保守的である」ことです。 推薦がほとんど送信されるメッセージの作成にある間、要件の大部分は入力メッセージの取り扱いに置かれます。
This document does not address transport of CMS-X.400 content. It is assumed that CMS-X.400 content would be transported by Internet mail systems, X.400, or other suitable transport.
このドキュメントはCMS-X.400内容の輸送を扱いません。 CMS-X.400内容がインターネット・メールシステム、X.400、または他の適当な輸送で輸送されると思われます。
This document describes applying security services to the content of entire X.400 messages, which may or may not be IPMS messages. These objects can be carried by several means, including SMTP-based mail and X.400 mail. Note that cooperating S/MIME agents must support common forms of message content in order to achieve interoperability.
このドキュメントは、全体のX.400メッセージの内容へのセキュリティー・サービスを適用すると説明します。メッセージはIPMSメッセージであるかもしれません。 SMTPベースのメールとX.400メールを含むいくつかの手段でこれらのオブジェクトを運ぶことができます。 協力S/MIMEエージェントが相互運用性を達成するために一般的なフォームに関するメッセージ内容をサポートしなければならないことに注意してください。
If the CMS objects are sent as parts of an RFC 822 message, a standard MIXER gateway [MIXER] will most likely choose to encapsulate the message. This is not likely to be a format that is usable by an X.400 recipient. MIXER is specifically focused on translation between X.420 Interpersonal Messages and non-secure RFC822/MIME messages. The discussion of security-related body parts in sections 7.3 and 7.4 of [BODYMAP] is relevant to CMS messages.
RFC822メッセージの部分としてCMSオブジェクトを送ると、標準のMIXERゲートウェイ[MIXER]は、メッセージをカプセル化するのをたぶん選ぶでしょう。 これはX.400受取人が使用可能な形式である傾向がありません。 MIXERは明確にX.420 Interpersonal Messagesと非安全なRFC822/MIMEメッセージの間の翻訳に集中しています。 [BODYMAP]のセクション7.3と7.4でのセキュリティ関連の身体の部分の議論はCMSメッセージに関連しています。
Definition of gateway services to support relay of CMS object between X.400 and SMTP environments is beyond the scope of this document.
X.400とSMTP環境の間でCMSオブジェクトのリレーを支えるゲートウェイサービスの定義はこのドキュメントの範囲を超えています。
1.2. Terminology
1.2. 用語
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14, RFC 2119 [MUSTSHOULD].
“MUST"(“SHALL")が、このドキュメントで“SHOULD"、「推薦された」、および「5月」が「必要であった」というキーワードはBCP14RFC2119[MUSTSHOULD]で説明されるように解釈されることです。
Hoffman, et al. Standards Track [Page 2] RFC 3854 Securing X.400 with S/MIME July 2004
ホフマン、他 2004年7月にS/MIMEでX.400を固定する標準化過程[2ページ]RFC3854
1.3. Definitions
1.3. 定義
For the purposes of this document, the following definitions apply.
このドキュメントの目的のために、以下の定義は申し込まれます。
ASN.1: Abstract Syntax Notation One, as defined in
ISO/IEC 8824.
ASN.1: ISO/IEC8824で定義されるような抽象的なSyntax Notation One。
BER: Basic Encoding Rules for ASN.1, as defined in
ISO/IEC 8825-1.
BER: ASN.1のためのISO/IEC8825-1で定義されるような基本的なEncoding Rules。
Certificate: A type that binds an entity's distinguished name
to a public key with a digital signature.
以下を証明してください。 デジタル署名で実体の分類名を公開鍵に縛るタイプ。
DER: Distinguished Encoding Rules for ASN.1, as defined
in ISO/IEC 8825-1.
DER: ASN.1のためのISO/IEC8825-1で定義されるような顕著なEncoding Rules。
7-bit data: Text data with lines less than 998 characters
long, where none of the characters have the 8th
bit set, and there are no NULL characters. <CR>
and <LF> occur only as part of a <CR><LF> end of
line delimiter.
7ビットのデータ: 系列998キャラクタが長いテキストデータ、キャラクタのだれにも8番目のビットがないところにセットしてください。そうすれば、NULLキャラクタが全くありません。 <CR>と<LF>は単に<CR><LF>行末デリミタの一部として現れます。
8-bit data: Text data with lines less than 998 characters, and
where none of the characters are NULL characters.
<CR> and <LF> occur only as part of a <CR><LF> end
of line delimiter.
8ビットのデータ: 系列が998のキャラクタとキャラクタのだれもどこのNULLキャラクタでないかより少ないテキストデータ。 <CR>と<LF>は単に<CR><LF>行末デリミタの一部として現れます。
Binary data: Arbitrary data.
バイナリ・データ: 任意のデータ。
Transfer Encoding: A reversible transformation made on data so 8-bit
or binary data may be sent via a channel that only
transmits 7-bit data.
コード化を移してください: 7ビットのデータを送るだけであるチャンネルであまりに8ビットであるデータでされた可逆的な変換かバイナリ・データを送るかもしれません。
Receiving agent: Software that interprets and processes S/MIME CMS
objects.
エージェントを受けます: S/MIME CMSを解釈して、処理するソフトウェアが反対します。
Sending agent: Software that creates S/MIME CMS objects.
エージェントを送ります: S/MIME CMSを作成するソフトウェアが反対します。
S/MIME agent: User software that is a receiving agent, a sending
agent, or both.
S/MIMEエージェント: 受信エージェント、送付エージェント、または両方であるユーザソフトウェア。
1.4. Compatibility with Prior Practice of S/MIME
1.4. S/MIMEの先の習慣との互換性
There are believed to be no existing X.400 implementations that support S/MIME version 2. Further, signed interoperability between X.400 and MIME systems that support S/MIME version 2 is not believed
S/MIMEがバージョン2であるとサポートするX.400実装は存在であると信じられていません。 さらに、S/MIMEがバージョン2であるとサポートするX.400とMIMEシステムの間の署名している相互運用性は信じられていません。
Hoffman, et al. Standards Track [Page 3] RFC 3854 Securing X.400 with S/MIME July 2004
ホフマン、他 2004年7月にS/MIMEでX.400を固定する標準化過程[3ページ]RFC3854
to be easily achievable. Therefore backward compatibility with S/MIME version 2 is not considered to be a requirement for this document.
容易に達成可能になるように。 したがって、S/MIMEバージョン2との後方の互換性はこのドキュメントのための要件であると考えられません。
It is a goal of this document to, if possible, maintain backward compatibility with existing X.400 implementations that employ S/MIME v3.1 wrappers.
それはできれば、既存のX.400実装との互換性がその雇用S/MIME v3.1ラッパーであることを後方に支持するこのドキュメントの目標です。
2. CMS Options
2. cmはゆだねます。
CMS allows for a wide variety of options in content and algorithm support. This section puts forth a number of support requirements and recommendations in order to achieve a base level of interoperability among all CMS-X.400 implementations. [CMS] provides additional details regarding the use of the cryptographic algorithms.
CMSは内容とアルゴリズムサポートにおけるさまざまなオプションを考慮します。 このセクションは、すべてのCMS-X.400実装の中で基準面の相互運用性を達成するために多くのサポート要件と推薦を差し出します。 [CMS]は暗号アルゴリズムの使用に関する追加詳細を明らかにします。
2.1. DigestAlgorithmIdentifier
2.1. DigestAlgorithmIdentifier
Sending and receiving agents MUST support SHA-1 [CMSALG].
送受信エージェントはSHA-1[CMSALG]をサポートしなければなりません。
2.2. SignatureAlgorithmIdentifier
2.2. SignatureAlgorithmIdentifier
Receiving agents MUST support id-dsa-with-sha1 defined in [CMSALG]. The algorithm parameters MUST be absent (not encoded as NULL). Receiving agents MUST support rsaEncryption, defined in [CMSALG].
エージェントを受けると、sha1とイドdsaは[CMSALG]で定義されていた状態でサポートしなければなりません。 アルゴリズムパラメタは欠けているに違いありません(NULLとして、コード化されません)。 エージェントを受けると、[CMSALG]で定義されたrsaEncryptionはサポートしなければなりません。
Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption.
送付エージェントはsha1とイドdsaかrsaEncryptionのどちらかをサポートしなければなりません。
2.3. KeyEncryptionAlgorithmIdentifier
2.3. KeyEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support rsaEncryption, defined in [CMSALG].
送受信エージェントは[CMSALG]で定義されたrsaEncryptionをサポートしなければなりません。
Sending and receiving agents SHOULD support Diffie-Hellman defined in [CMSALG].
ディフィー-ヘルマンが[CMSALG]で定義したエージェントSHOULDサポートを送って、受けます。
2.4. General Syntax
2.4. 一般構文
The general syntax of CMS objects consist of an instance of the ContentInfo structure containing one of several defined CMS content types. CMS defines multiple content types. Of these, only the SignedData and EnvelopedData content types are used for CMS-X.400.
CMSオブジェクトの一般的な構文はいくつかの定義されたCMS content typeの1つを含むContentInfo構造のインスタンスから成ります。 CMSは複数のcontent typeを定義します。 これらでは、SignedDataとEnvelopedData content typeだけがCMS-X.400に使用されます。
2.4.1. SignedData Content Type
2.4.1. SignedData content type
Sending agents MUST use the signedData content type to apply a digital signature to a message or, in a degenerate case where there is no signature information, to convey certificates.
送付エージェントがデジタル署名をメッセージに適用するのにsignedData content typeを使用しなければならない、堕落した場合では、さもなければ、そこのどこが、証明書を伝えるためには署名情報でないか。
Hoffman, et al. Standards Track [Page 4] RFC 3854 Securing X.400 with S/MIME July 2004
ホフマン、他 2004年7月にS/MIMEでX.400を固定する標準化過程[4ページ]RFC3854
2.4.2. EnvelopedData Content Type
2.4.2. EnvelopedData content type
Senders MUST use the envelopedData content type to apply privacy protection to a message. A sender needs to have access to a public key for each intended message recipient to use this service. This content type does not provide authentication.
Sendersは、プライバシー保護をメッセージに適用するのにenvelopedData content typeを使用しなければなりません。 送付者は、それぞれの意図しているメッセージ受取人がこのサービスを利用するように公開鍵に近づく手段を持つ必要があります。 このcontent typeは認証を提供しません。
2.5. Attribute SignerInfo Type
2.5. 属性SignerInfoはタイプします。
The SignerInfo type allows the inclusion of unsigned and signed attributes to be included along with a signature.
SignerInfoタイプは署名と共に未署名の、そして、署名している属性の包含を含めさせます。
Receiving agents MUST be able to handle zero or one instance of each of the signed attributes listed here. Sending agents SHOULD generate one instance of each of the following signed attributes in each CMS- X400 message:
エージェントを受けると、ここに記載されたそれぞれの署名している属性のゼロか1つのインスタンスを扱うことができなければなりません。 送付エージェントSHOULDはそれぞれのCMS- X400メッセージの属性であると署名されるそれぞれの以下の1つのインスタンスを生成します:
- signingTime - sMIMECapabilities - sMIMEEncryptionKeyPreference
- signingTime--sMIMECapabilities--sMIMEEncryptionKeyPreference
Requirements for processing of these attributes MUST be in accordance with the S/MIME Message Specification [MSG]. Handling of the signingTime attribute MUST comply with clause 2.5.1 of [MSG]. Handling of the sMIMECapabilities attribute MUST comply with clause 2.5.2 of [MSG]. Handling of the sMIMEEncryptionKeyPreference attribute MUST comply with clause 2.5.3 of [MSG].
S/MIME Message Specification[MSG]によると、これらの属性の処理のための要件があるに違いありません。 signingTime属性の取り扱いは.1 2.5番目の節[MSG]に従わなければなりません。 sMIMECapabilities属性の取り扱いは.2 2.5番目の節[MSG]に従わなければなりません。 sMIMEEncryptionKeyPreference属性の取り扱いは.3 2.5番目の節[MSG]に従わなければなりません。
Further, receiving agents SHOULD be able to handle zero or one instance in the signed attributes of the signingCertificate attribute [ESS].
エージェントSHOULDを受けて、さらに、signingCertificate属性[ESS]の署名している属性におけるゼロか1つのインスタンスを扱うことができてください。
Sending agents SHOULD generate one instance of the signingCertificate signed attribute in each CMS-X400 message.
送付エージェントSHOULDはそれぞれのCMS-X400メッセージの属性であると署名されるsigningCertificateの1つのインスタンスを生成します。
Additional attributes and values for these attributes may be defined in the future. Receiving agents SHOULD handle attributes or values that they do not recognize in a graceful manner.
これらの属性のための追加属性と値は将来、定義されるかもしれません。 受信エージェントSHOULDは彼らが優しい物腰で認識しない属性か値を扱います。
Sending agents that include signed attributes that are not listed here SHOULD display those attributes to the user, so that the user is aware of all of the data being signed.
ここに記載されていない署名している属性を含んでいるエージェントを送って、SHOULDはそれらの属性をユーザに表示します、ユーザが署名されるデータのすべてを意識しているように。
Hoffman, et al. Standards Track [Page 5] RFC 3854 Securing X.400 with S/MIME July 2004
ホフマン、他 2004年7月にS/MIMEでX.400を固定する標準化過程[5ページ]RFC3854
2.6. ContentEncryptionAlgorithmIdentifier
2.6. ContentEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support encryption and decryption with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG]. Sending and receiving agents SHOULD support encryption and decryption with AES [CMSAES] at a key size of 128, 192 and 256 bits.
「tripleDES」[CMSALG]は、以下に、送受信エージェントがDES EDE3 CBCと共に暗号化と復号化をサポートしなければならないと呼びました。 送受信エージェントSHOULDはAES[CMSAES]と共に128、192、および256ビットの主要なサイズで暗号化と復号化をサポートします。
3. Creating S/MIME Messages
3. S/MIMEメッセージを作成します。
This section describes the S/MIME message formats and how they can be used to secure X.400 contents. The S/MIME messages are a combination of X.400 contents and CMS objects (i.e., a ContentInfo structure containing one of the CMS-defined content types). The X.400 content and other data, such as certificates and algorithm identifiers, are given to CMS processing facilities which produces a CMS object. This document also describes how nested, secured S/MIME messages should be formatted when encapsulating an X.400 content, and provides an example of how a triple-wrapped S/MIME message over X.400 content should be created if backwards compatibility with S/MIME version 2 is of no concern.
このセクションはS/MIMEメッセージ・フォーマットとX.400がコンテンツであると機密保護するのにどうそれらを使用できるかを説明します。 S/MIMEメッセージはX.400コンテンツとCMSオブジェクト(すなわち、CMSによって定義されたcontent typeの1つを含むContentInfo構造)の組み合わせです。 証明書やアルゴリズム識別子などのX.400内容と他のデータをCMS処理施設に与えます(CMSオブジェクトを作り出します)。 このドキュメントは、また、X.400が内容であるとカプセル化するときS/MIMEメッセージがどれくらい入れ子にされて、機密保護されるべきであるかをフォーマットされていた状態で説明して、X.400内容の上の3倍包装されたS/MIMEメッセージがどう後方になら作成されて、S/MIMEバージョン2との互換性が関心の全くものでないということであるべきであるかに関する例を前提とします。
S/MIME provides one format for enveloped-only data, several formats for signed-only data, and several formats for signed and enveloped data. The different formats are required to accommodate several environments, in particular for signed messages. Only one of these signed formats is applicable to X.400.
S/MIMEはおおわれて唯一のデータのための1つの形式、署名されて唯一のデータのためのいくつかの形式、および署名していておおわれたデータのためのいくつかの形式を提供します。 異なった形式が、いくつかの環境を収容するのに特に署名しているメッセージに必要です。 形式であると署名されるこれらの1つだけがX.400に適切です。
Note that canonicalization is not required for X.400 content because it is a binary rather than text encoding, and only the "embedded" content version is used. These dramatically simplify the description of S/MIME productions.
それがテキストコード化よりむしろバイナリーであり、満足している「埋め込まれた」バージョンだけが使用されているので、canonicalizationはX.400内容に必要でないことに注意してください。 これらはS/MIME創作の記述を劇的に簡素化します。
The reader of this section is expected to understand X.400 as described in [X.400] and S/MIME as described in [CMS] and [ESS].
このセクションの読者が[CMS]と[ESS]で説明されるように[X.400]とS/MIMEで説明されるようにX.400を理解していると予想されます。
3.1. The X.400 Message Structure
3.1. X.400メッセージ構造
This section reviews the X.400 message format. An X.400 message has two parts, the envelope and the content, as described in X.402 [X.400]:
このセクションはX.400メッセージ・フォーマットを見直します。 X.400メッセージには、2つの部品、封筒、および内容がX.402[X.400]で説明されるようにあります:
Envelope -- An information object whose composition varies from one transmittal step to another and that variously identifies the message's originator and potential recipients, documents its previous conveyance and directs its subsequent conveyance by the Message Transfer System (MTS), and characterizes its content.
封筒--構成が別のものと1譲渡ステップからそれに異なる情報オブジェクトは、Message Transfer System(MTS)で、さまざまにメッセージの創始者と潜在的受取人を特定して、前の運送を記録して、その後の運送を指示して、内容を特徴付けます。
Hoffman, et al. Standards Track [Page 6] RFC 3854 Securing X.400 with S/MIME July 2004
ホフマン、他 2004年7月にS/MIMEでX.400を固定する標準化過程[6ページ]RFC3854
Content -- The content is the piece of information that the originating User Agent wants to be delivered to one or more recipients. The MTS neither examines nor modifies the content, except for conversion, during its conveyance of the message. MTS conversion is not applicable to the scenario of this document because such conversion is incompatible with CMS protection mechanisms.
内容--内容は起因しているUserエージェントを1人以上の受取人に提供されたいという情報の断片です。 MTSはメッセージの運送の間の変換以外の内容を審査でない、また変更しません。 そのような変換がCMS保護メカニズムと両立しないので、MTS変換はこのドキュメントのシナリオに適切ではありません。
One piece of information borne by the envelope identifies the type of the content. The content type is an identifier (an ASN.1 OID or Integer) that denotes the syntax and semantics of the content overall. This identifier enables the MTS to determine the message's deliverability to particular users, and enables User Agents and Message Stores to interpret and process the content.
封筒によって持たれている1つの情報が内容のタイプを特定します。 content typeは全体的に見て内容の構文と意味論を指示する識別子(ASN.1OIDかInteger)です。 この識別子は、UserエージェントとMessageストアが内容を解釈して、処理するのをMTSがメッセージのデリベラビリティを特定のユーザに決定するのを可能にして、可能にします。
Another piece of information borne by the envelope identifies the types of encoded information represented in the content. An encoded information type (EIT) is an identifier (an ASN.1 Object Identifier or Integer) that denotes the medium and format (e.g., IA5 text or Group 3 facsimile) of individual portions of the content. It further enables the MTS to determine the message's deliverability to particular users, and to identify opportunities for it to make the message deliverable by converting a portion of the content from one EIT to another.
封筒によって持たれているもう1片の情報は内容に表されたコード化された情報のタイプを特定します。 コード化された情報タイプ(EIT)は内容の個々の部分の媒体と形式(例えば、IA5テキストかGroup3ファクシミリ)を指示する識別子(ASN.1Object IdentifierかInteger)です。 それは、MTSがメッセージのデリベラビリティを特定のユーザに決定して、1EITから別のEITまで内容の部分を変換することによってメッセージ提出物を作る機会を特定するのをさらに可能にします。
This document describes how S/MIME CMS is used to secure the content part of X.400 messages.
このドキュメントはS/MIME CMSがX.400メッセージの満足している部分を保証するのにどう使用されるかを説明します。
3.2. Creating a Signed-only Message with X.400 Content
3.2. aを作成する、署名されて唯一のメッセージ、X.400内容
The SignedData format as described in the Cryptographic Message Syntax [CMS] MUST be used for signing of X.400 contents.
X.400コンテンツの署名にCryptographic Message Syntax[CMS]で説明されるSignedData形式を使用しなければなりません。
The X.400 content to be protected MUST be placed in the SignedData encapContentInfo eContent field. Note that this X.400 content SHOULD maintain the encoding defined by the content type, but SHOULD NOT be MIME wrapped. The object identifier for the content type of the protected X.400 content MUST be placed in the SignedData encapContentInfo eContentType field.
保護されるべきX.400内容をSignedData encapContentInfo eContent分野に置かなければなりません。 コード化がしかし、content type、SHOULD NOTで定義したSHOULDが、主張するこのX.400内容が包装されたMIMEであることに注意してください。 保護されたX.400内容のcontent typeのためのオブジェクト識別子をSignedData encapContentInfo eContentType分野に置かなければなりません。
The signedData object is encapsulated by a ContentInfo SEQUENCE with a contentType of id-signedData.
signedDataオブジェクトはイド-signedDataのcontentTypeと共にContentInfo SEQUENCEによってカプセルに入れられます。
Note that if SMTP [SMTP] is used to transport the resulting signed- only message then the optional MIME encoding SHOULD be used. If binary transports such as X.400 are used then the optional MIME encoding SHOULD NOT be used.
SMTP[SMTP]が結果になることを輸送するのに使用されるならそれが、SHOULDをコード化しながら次に、唯一のメッセージが任意のMIMEであると署名したことに注意してください。使用されます。 X.400などの2進の輸送がその時使用される、任意のMIME、SHOULD NOTをコード化して、使用されてください。
Hoffman, et al. Standards Track [Page 7] RFC 3854 Securing X.400 with S/MIME July 2004
ホフマン、他 2004年7月にS/MIMEでX.400を固定する標準化過程[7ページ]RFC3854
There are many reasons for this requirement. An outer MIME wrapper should not be used in X.400. Further, there are places where X.400 systems will interact with SMTP/MIME systems where the outer MIME wrapper might be necessary. Because this wrapping is outside the security wrappers, any gateway system that might bridge the gap between the two systems will be smart enough to apply or remove the outer MIME wrapper as appropriate.
この要件の多くの理由があります。 X.400で外側のMIMEラッパーを使用するべきではありません。 さらに、場所がX.400システムが外側のMIMEラッパーが必要であるかもしれないSMTP/MIMEシステムと対話するところにあります。 セキュリティラッパーの外でこのラッピングがあるので、2台のシステムのギャップをブリッジするかもしれないどんなゲートウェイシステムも適宜外側のMIMEラッパーを適用するか、または取り除くことができるくらい賢くなるでしょう。
3.2.1. MIME Wrapping to Dynamically Support 7-bit Transport
3.2.1. ラッピングをまねて、ダイナミックに7ビットの輸送をサポートしてください。
The signedData object MAY optionally be wrapped in MIME. This allows the system to support 7-bit transport when required. This outer MIME wrapper MAY be dynamically added or removed throughout the delivery path since it is outside the signature and encryption wrappers. In this case the application/pkcs7-mime type as defined in S/MIME Version 3.1 Message Specification [MSG] SHOULD be used with the following parameters:
signedDataオブジェクトはMIMEで任意に包装されるかもしれません。 これで、必要であると、システムは7ビットの輸送をサポートすることができます。 署名と暗号化ラッパーの外でそれがあるので、配送経路中でこの外側のMIMEラッパーをダイナミックに加えるか、または取り除くかもしれません。 この場合、pkcs7アプリケーション/パントマイムは定義されるとしてタイプします。S/MIMEバージョン3.1Message Specification[エムエスジー]SHOULDでは、以下のパラメタと共に使用されてください:
Content-Type: application/pkcs7-mime; smime-type=signed-x400 Content-Transfer-Encoding: base64
コンテントタイプ: pkcs7アプリケーション/パントマイム。 smime-タイプは署名しているx400 Content-転送コード化と等しいです: base64
If the application/pkcs7-mime MIME type is used to support 7-bit transport, the steps to create this format are:
pkcs7アプリケーション/パントマイムMIMEの種類が7ビットの輸送をサポートするのに使用されるなら、この形式を作成するステップは以下の通りです。
Step 1. The X.400 content to be signed is ASN.1 encoded.
1を踏んでください。 署名されるX.400内容はコード化されたASN.1です。
Step 2. The ASN.1 encoded X.400 content and other required data is processed into a CMS object of type SignedData. The SignedData structure is encapsulated by a ContentInfo SEQUENCE with a contentType of id-signedData.
2を踏んでください。 ASN.1はX.400内容をコード化しました、そして、他の必要なデータはタイプSignedDataのCMSオブジェクトに処理されます。 SignedData構造はイド-signedDataのcontentTypeと共にContentInfo SEQUENCEによってカプセル化されます。
Step 3. The CMS object is inserted into an application/pkcs7-mime MIME entity.
3を踏んでください。 CMSオブジェクトはpkcs7アプリケーション/パントマイムMIME実体に挿入されます。
The smime-type parameter for messages using application/pkcs7-mime with SignedData is "signed-x400" as defined in [TRANSPORT].
SignedDataがあるpkcs7アプリケーション/パントマイムを使用するメッセージのためのsmime-型引数は[TRANSPORT]で定義されるように「署名しているx400」です。
3.3. Creating an Enveloped-only Message with X.400 Content
3.3. 作成、おおわれて唯一のメッセージ、X.400内容
This section describes the format for enveloping an X.400 content without signing it. It is important to note that sending enveloped but not signed messages does not provide for data integrity. It is possible to replace ciphertext in such a way that the processed message will still be valid, but the meaning is altered.
このセクションは、それに署名しないでX.400内容をおおうために形式について説明します。 おおわれますが、メッセージであることは署名されない発信がデータ保全に備えないことに注意するのが重要です。 処理メッセージがまだ有効になっていますが、意味が変更されるような方法で暗号文を取り替えるのは可能です。
The EnvelopedData format as described in [CMS] is used for confidentiality of the X.400 contents.
[CMS]で説明されるEnvelopedData形式はX.400コンテンツの秘密性に使用されます。
Hoffman, et al. Standards Track [Page 8] RFC 3854 Securing X.400 with S/MIME July 2004
ホフマン、他 2004年7月にS/MIMEでX.400を固定する標準化過程[8ページ]RFC3854
The X.400 content to be protected MUST be placed in the EnvelopedData encryptedContentInfo encryptedContent field. Note that this X.400 content SHOULD maintain the encoding defined by the content type, but SHOULD NOT be MIME wrapped. The object identifier for content type of the protected X.400 content MUST be placed in the EnvelopedData encryptedContentInfo contentType field.
保護されるべきX.400内容をEnvelopedData encryptedContentInfo encryptedContent分野に置かなければなりません。 コード化がしかし、content type、SHOULD NOTで定義したSHOULDが、主張するこのX.400内容が包装されたMIMEであることに注意してください。 保護されたX.400内容のcontent typeのためのオブジェクト識別子をEnvelopedData encryptedContentInfo contentType分野に置かなければなりません。
The envelopedData object is encapsulated by a ContentInfo SEQUENCE with a contentType of id-envelopedData.
envelopedDataオブジェクトはイド-envelopedDataのcontentTypeと共にContentInfo SEQUENCEによってカプセルに入れられます。
Note that if SMTP is used to transport the resulting enveloped-only message then the optional MIME encoding SHOULD be used. If other transport (e.g., X.400) that is optimized for binary content is used then the optional MIME encoding SHOULD NOT be used.
SMTPがその時おおわれて唯一の結果として起こるメッセージを輸送するのに使用されるならそれに注意してください、任意のMIME、SHOULDをコード化して、使用されてください。 2進の内容のために最適化される他の輸送(例えば、X.400)がその時使用される、任意のMIME、SHOULD NOTをコード化して、使用されてください。
3.3.1. MIME Wrapping to Dynamically Support 7-bits Transport
3.3.1. ラッピングをまねて、ダイナミックに7ビットの輸送をサポートしてください。
The envelopedData object MAY optionally be wrapped in MIME. This allows the system to support 7-bit transport when required. This outer MIME wrapper MAY be dynamically added or removed throughout the delivery path since it is outside the signature and encryption wrappers. In this case, the application/pkcs7-mime type as defined in S/MIME Version 3.1 Message Specification [MSG] SHOULD be used with the following parameters:
envelopedDataオブジェクトはMIMEで任意に包装されるかもしれません。 これで、必要であると、システムは7ビットの輸送をサポートすることができます。 署名と暗号化ラッパーの外でそれがあるので、配送経路中でこの外側のMIMEラッパーをダイナミックに加えるか、または取り除くかもしれません。 この場合、pkcs7アプリケーション/パントマイムは定義されるとしてタイプします。S/MIMEバージョン3.1Message Specification[エムエスジー]SHOULDでは、以下のパラメタと共に使用されてください:
Content-Type: application/pkcs7-mime; smime-type=enveloped-x400 Content-Transfer-Encoding: base64
コンテントタイプ: pkcs7アプリケーション/パントマイム。 smime-タイプはおおわれたx400 Content-転送コード化と等しいです: base64
If the application/pkcs7-mime MIME type is used to support 7-bit transport, the steps to create this format are:
pkcs7アプリケーション/パントマイムMIMEの種類が7ビットの輸送をサポートするのに使用されるなら、この形式を作成するステップは以下の通りです。
Step 1. The X.400 content to be enveloped is ASN.1 encoded.
1を踏んでください。 おおわれるべきX.400内容はコード化されたASN.1です。
Step 2. The ASN.1 encoded X.400 content and other required data is processed into a CMS object of type EnvelopedData. In addition to encrypting a copy of the content-encryption key for each recipient, a copy of the content encryption key SHOULD be encrypted for the originator and included in the EnvelopedData (see [CMS] Section 6). The EnvelopedData structure is encapsulated by a ContentInfo SEQUENCE with a contentType of id-envelopedData.
2を踏んでください。 ASN.1はX.400内容をコード化しました、そして、他の必要なデータはタイプEnvelopedDataのCMSオブジェクトに処理されます。 各受取人、満足している暗号化の主要なSHOULDのコピーに、主要な満足している暗号化のコピーを暗号化することに加えて、創始者のために暗号化されていて、EnvelopedDataで含められてください([CMS]セクション6を見てください)。 EnvelopedData構造はイド-envelopedDataのcontentTypeと共にContentInfo SEQUENCEによってカプセル化されます。
Step 3. The CMS object is inserted into an application/pkcs7-mime MIME entity to allow for 7-bit transport.
3を踏んでください。 CMSオブジェクトは、7ビットの輸送を考慮するためにpkcs7アプリケーション/パントマイムMIME実体に挿入されます。
If the application/pkcs7-mime MIME entity is used, the smime-type parameter for enveloped-only messages is "enveloped-x400" as defined in [TRANSPORT].
pkcs7アプリケーション/パントマイムMIME実体が使用されているなら、おおわれて唯一のメッセージのためのsmime-型引数は[TRANSPORT]で定義されるように「おおわれたx400」です。
Hoffman, et al. Standards Track [Page 9] RFC 3854 Securing X.400 with S/MIME July 2004
ホフマン、他 2004年7月にS/MIMEでX.400を固定する標準化過程[9ページ]RFC3854
3.4. Nested CMS Structures
3.4. 入れ子にされたcm構造
To achieve signing and enveloping, any of the signed-only and encrypted-only CMS objects may be nested.
署名とおおうことを達成するために、署名されて唯一で暗号化されて唯一のCMSオブジェクトのいずれも入れ子にされるかもしれません。
When nesting is used, backwards compatibility with S/MIME version 2 requires that each layer of the nested message are identified with the OID id-data, and when id-data is used a MIME wrapper is required. This can potentially lead to an enormous amount of overhead and should be avoided. Because S/MIME version 2 compatibility is of no concern, implementations SHOULD directly encode the encapsulated object as the eContent of the current structure.
巣篭もりが後方に使用されるとき、S/MIMEバージョン2との互換性は、入れ子にされたメッセージの各層がOIDイドデータと同一視されているのを必要とします、そして、イドデータが使用されているとき、MIMEラッパーが必要です。 これは、潜在的にオーバーヘッドの巨額に通じることができて、避けられるべきです。 S/MIMEバージョン2の互換性が関心の全くものでないので、実装SHOULDは現在の構造のeContentとして直接カプセル化オブジェクトをコード化します。
MIME wrapping to support 7-bit transport is optional and need only be used around the outermost CMS structure. In this case, the application/pkcs7 content type MUST be used.
7ビットの輸送をサポートするMIMEラッピングは、任意であり、一番はずれのCMS構造の周りで使用されるだけでよいです。 この場合、アプリケーション/pkcs7content typeを使用しなければなりません。
An S/MIME implementation MUST be able to receive and process arbitrarily nested CMS structures within reasonable resource limits of the recipient computer.
S/MIME実装は、受取人コンピュータの妥当なリソース限界の中で任意に入れ子にされたCMS構造を、受けて、処理できなければなりません。
3.4.1. Creating a Triple Wrapped Message With an X.400 Content
3.4.1. X.400内容で三重の包装されたメッセージを作成します。
The Enhanced Security Services for S/MIME [ESS] document provides examples of how nested, secured S/MIME messages are formatted. ESS provides an example of how a triple-wrapped S/MIME message is formatted using application/pkcs7-mime for the signatures.
[ESS]が記録するS/MIMEのためのEnhanced Security Servicesは入れ子にされて、機密保護しているS/MIMEメッセージがどうフォーマットされるかに関する例を提供します。 ESSは3倍包装されたS/MIMEメッセージが署名にpkcs7アプリケーション/パントマイムを使用することでどうフォーマットされるかに関する例を提供します。
This section explains how an X.400 content may be conveyed within a Triple Wrapped Message because S/MIME version 2 compatibility is of no concern:
このセクションはS/MIMEバージョン2の互換性が関心の全くものでないのでX.400内容がTriple Wrapped Messageの中でどう伝えられるかもしれないかを説明します:
Step 1. Start with the X.400 content (called the "original content"). The X.400 content MUST be ASN.1 encoded, but SHOULD NOT be MIME wrapped.
1を踏んでください。 X.400内容(「オリジナルコンテンツ」と呼ばれる)から始まってください。 内容がしかし、ASNがコード化された.1、SHOULD NOTであったならMIMEが包装されていたならそうしなければならないX.400。
Step 2. Place the ASN.1 encoded X.400 content to be protected in the SignedData encapContentInfo eContent field. Add any attributes that are to be signed.
2を踏んでください。 ASN.1のコード化されたX.400内容を置いて、SignedData encapContentInfo eContent分野に保護されてください。 署名されることになっているあらゆる属性を加えてください。
Step 3. Sign the result of step 2 (the original content). The SignedData encapContentInfo eContentType MUST contain the object identifier of the X.400 content.
3を踏んでください。 ステップ2の結果が(オリジナルコンテンツ)であると署名してください。 SignedData encapContentInfo eContentTypeはX.400内容に関するオブジェクト識別子を含まなければなりません。
Step 4. Encrypt the result of step 3 as a single block. The EnvelopedData encryptedContentInfo contentType MUST be set to id- signedData. This is called the "encrypted body".
4を踏んでください。 単滑車としてステップ3の結果を暗号化してください。 EnvelopedData encryptedContentInfo contentTypeはイドsignedDataに用意ができなければなりません。 これは「暗号化されたボディー」と呼ばれます。
Hoffman, et al. Standards Track [Page 10] RFC 3854 Securing X.400 with S/MIME July 2004
ホフマン、他 2004年7月にS/MIMEでX.400を固定する標準化過程[10ページ]RFC3854
Step 5. Using the same logic as in step 2 and 3 above, sign the result of step 4 (the encrypted body) as a single block. The SignedData encapContentInfo eContentType MUST be set to id- envelopedData. The outer SignedData structure is encapsulated by a ContentInfo SEQUENCE with a contentType of id-signedData.
5を踏んでください。 同じ論理を使用して、上では、ステップ2と3のように単滑車としてステップ4の結果が(暗号化されたボディー)であると署名してください。 SignedData encapContentInfo eContentTypeはイドenvelopedDataに用意ができなければなりません。 外側のSignedData構造はイド-signedDataのcontentTypeと共にContentInfo SEQUENCEによってカプセル化されます。
Step 6. The resulting message is called the "outer signature", and is also the triple wrapped message.
6を踏んでください。 結果として起こるメッセージは、「外側の署名」と呼ばれて、また、三重の包装されたメッセージです。
MIME wrapping to support 7-bit transport is optional and MUST only be used around the outermost CMS structure. In this case, the application/pkcs7-mime content type MUST be used. The smime-type in the case of adding a MIME wrapper MUST be consistent with that appropriate to the innermost protection layer.
7ビットの輸送をサポートするMIMEラッピングを任意であり、一番はずれのCMS構造の周りで使用するだけでよいです。 この場合、pkcs7アプリケーション/パントマイムcontent typeを使用しなければなりません。 MIMEラッパーを加える場合におけるsmime-タイプはそれと最も奥深い保護層に適切な状態で一致しているに違いありません。
In some instances, an smime-type will be created that only reflects one security service (such as certs-only, which applies only to signed-only messages). However, as new layers are wrapped, this smime-type SHOULD be propagated upwards. Thus if a certs-only message were to be encrypted, or wrapped in a new SignedData structure, the smime-type of certs-only should be propagated up to the next MIME wrapper. In other words, the innermost type is reflected outwards.
ある場合に、1つのセキュリティー・サービス(署名されて唯一のメッセージだけに適用する本命だけなどの)しか反映しないsmime-タイプは創造されるでしょう。 新しい層が包装されるのでこれがどのようにSHOULDをsmimeタイプしても、上向きに伝播されてください。 したがって、本命だけメッセージが新しいSignedData構造で暗号化されるか、または包装されることであるなら、本命だけのsmime-タイプは次のMIMEラッパーまで伝播されます。 言い換えれば、最も奥深いタイプは外へ反映されます。
3.5. Carrying Plaintext X.400 Content in SMTP
3.5. SMTPの平文X.400内容を運びます。
While the objectives of this document focus on protecting X.400 content with CMS wrappers, it is a reality that users do not generally send all message using security. It therefore stands to reason that a means to carry non-secured X.400 content over the chosen transport system must be seamlessly provided. While transporting X.400 content in an X.400 system is trivial, carrying X.400 content in SMTP requires additional definition.
このドキュメントの目的は、CMSラッパーでX.400内容を保護するのは焦点を合わせますが、一般に、ユーザがセキュリティを使用することですべてのメッセージを送るというわけではないのは、現実のものです。 したがって、シームレスに非機密保護しているX.400内容を選ばれた輸送システムの上まで運ぶ手段を提供しなければならないのは理にかなわれています。 X.400システムのX.400内容を輸送するのは些細ですが、SMTPのX.400内容を運ぶのは追加定義を必要とします。
Content-Type: application/x400-content; content-type = 1*DIGIT *( "." 1*DIGIT)
コンテントタイプ: x400アプリケーション/内容。 content type=1*DIGIT*(「. 」 1*ケタ、)
where the content-type parameter value is either a single integer (for a built-in content-type) or an OID in dotted notation (for an extended content-type).
content typeパラメタ価値がただ一つの整数(内蔵のcontent typeのための)か点を打たされた記法(拡張content typeのための)でOIDのどちらかであるところ。
Hoffman, et al. Standards Track [Page 11] RFC 3854 Securing X.400 with S/MIME July 2004
ホフマン、他 2004年7月にS/MIMEでX.400を固定する標準化過程[11ページ]RFC3854
4. Use of Certificates
4. 証明書の使用
4.1. Certificate Enrollment
4.1. 証明書登録
S/MIME v3.1 does not specify how to get a certificate from a certificate authority, but instead mandates that every sending agent already has a certificate. The PKIX Working Group has, at the time of this writing, produced two separate standards for certificate enrollment: CMP (RFC 2510) and CMC (RFC 2792).
S/MIME v3.1は、認証局から証明書を手に入れる方法を指定しませんが、すべての送付エージェントには証明書が既にあるのを代わりに強制します。 PKIX作業部会はこの書くこと時点で、証明書登録の2つの別々の規格を生産しました: CMP(RFC2510)とCMC(RFC2792)。
4.2. Certificate Processing
4.2. 証明書処理
A receiving agent MUST provide some certificate retrieval mechanism in order to gain access to certificates for recipients of digital envelopes. This document does not cover how S/MIME agents handle certificates, only what they do after a certificate has been validated or rejected. S/MIME certification issues are covered in [CERT31].
受信エージェントは、デジタル封筒の受取人への証明書へのアクセスを得るために何らかの証明書回収機構を提供しなければなりません。 このドキュメントはS/MIMEエージェントがどう証明書を扱うかをカバーしていません、証明書が有効にされるか、または拒絶された後にそれらがすることだけ。 S/MIME証明問題は[CERT31]でカバーされています。
At a minimum, for initial S/MIME deployment, a user agent could automatically generate a message to an intended recipient requesting that recipient's certificate in a signed return message. Receiving and sending agents SHOULD also provide a mechanism to allow a user to "store and protect" certificates for correspondents in such a way so as to guarantee their later retrieval.
最小限では、初期のS/MIME展開のために、ユーザエージェントは自動的に署名しているリターンメッセージのその受取人の証明書を要求する意図している受取人にメッセージを生成することができました。 また、エージェントSHOULDを受けて、送ると、メカニズムは、彼らの後の検索を保証するためにユーザが通信員のためにそのような方法で証明書を「保存して、保護すること」を許容するために提供されます。
4.3. Certificate Name Use for X.400 Content
4.3. X.400内容の証明書名前使用
End-entity certificates used in the context of this document MAY contain an X.400 address as described in [X.400]. The address must be in the form of an "ORAddress". The X.400 address SHOULD be in the subjectAltName extension, and SHOULD NOT be in the subject distinguished name.
このドキュメントの文脈で使用される終わり実体証明書は[X.400]で説明されるようにX.400アドレスを含むかもしれません。 アドレスが「ORAddress」の形にあるに違いありません。 X.400アドレスSHOULDはsubjectAltName拡張子でそうです、そして、SHOULD NOTは対象の分類名においてそうです。
Sending agents SHOULD make the originator address in the X.400 content (e.g., the "originator" field in P22) match an X.400 address in the signer's certificate.
送付エージェントSHOULDはX.400内容(例えば、P22の「創始者」分野)の創始者アドレスに署名者の証明書のX.400アドレスを合わせます。
Receiving agents MUST recognize X.400 addresses in the subjectAltName field.
エージェントを受けると、X.400アドレスはsubjectAltName分野で認識されなければなりません。
Receiving agents SHOULD check that the originator address in the X.400 content matches an X.400 address in the signer's certificate, if X.400 addresses are present in the certificate and an originator address is available in the content. A receiving agent SHOULD provide some explicit alternate processing of the message if this
受信エージェントSHOULDは、X.400内容の創始者アドレスが署名者の証明書のX.400アドレスに合っているのをチェックします、X.400アドレスが証明書に存在していて、創始者アドレスが内容で利用可能であるなら。 SHOULDがこれであるならメッセージの何らかの明白な代替の処理を提供する受信エージェント
Hoffman, et al. Standards Track [Page 12] RFC 3854 Securing X.400 with S/MIME July 2004
ホフマン、他 2004年7月にS/MIMEでX.400を固定する標準化過程[12ページ]RFC3854
comparison fails, which may be to display a message that shows the recipient the addresses in the certificate or other certificate details.
証明書か他の証明書の詳細にアドレスを受取人に示しているメッセージを表示することであるかもしれない比較は失敗します。
The subject alternative name extension is used in S/MIME as the preferred means to convey the X.400 address(es) that correspond to the entity for this certificate. Any X.400 addresses present MUST be encoded using the x400Address CHOICE of the GeneralName type. Since the SubjectAltName type is a SEQUENCE OF GeneralName, multiple X.400 addresses MAY be present.
X.400を運ぶ都合のよい手段がこの証明書のために実体に対応する(es)を扱うとき、拡大という対象の代替名はS/MIMEに使用されます。 GeneralNameタイプのx400Address CHOICEを使用して、現在のどんなX.400アドレスもコード化しなければなりません。 SubjectAltNameタイプがSEQUENCE OF GeneralNameであるので、複数のX.400アドレスが存在しているかもしれません。
5. Security Considerations
5. セキュリティ問題
This specification introduces no new security concerns to the CMS or S/MIME models. Security issues are identified in section 5 of [MSG], section 6 of [ESS] and the Security Considerations section of [CMS].
この仕様はCMSかS/MIMEモデルにどんな新しい安全上の配慮も取り入れません。 安全保障問題は[MSG]のセクション5、[ESS]のセクション6、および[CMS]のSecurity Considerations部で特定されます。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[CERT31] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Certificate Handling",
RFC 3850, July 2004.
[CERT31] Ramsdell、B.、エド「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1証明書は扱う」RFC3850、2004年7月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[cm] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。
[CMSAES] Schaad, J., "Use of the AES Encryption Algorithm in
CMS", RFC 3565, July 2003.
[CMSAES]Schaad、J.、「cmにおけるAES暗号化アルゴリズムの使用」、RFC3565、2003年7月。
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[CMSALG] Housley、R.、「暗号のメッセージ構文(cm)アルゴリズム」、RFC3370、2002年8月。
[ESS] Hoffman, P., Editor "Enhanced Security Services for
S/MIME", RFC 2634, June 1999.
[ESS]ホフマン、P.、「S/のための警備の強化サービスはまねる」エディタ、RFC2634、1999年6月。
[MSG] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[MSG] Ramsdell、B.、エド、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1は仕様を通信する」RFC3851、7月2004日
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MUSTSHOULD] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[TRANSPORT] Hoffman, P. and C. Bonatti, "Transporting
Secure/Multipurpose Internet Mail Extensions (S/MIME)
Objects in X.400", RFC 3855, July 2004.
[輸送] ホフマンとP.とC.Bonatti、「X.400で安全な/マルチパーパスインターネットメールエクステンション(S/MIME)オブジェクトを輸送する」RFC3855、2004年7月。
Hoffman, et al. Standards Track [Page 13] RFC 3854 Securing X.400 with S/MIME July 2004
ホフマン、他 2004年7月にS/MIMEでX.400を固定する標準化過程[13ページ]RFC3854
[X.400] ITU-T X.400 Series of Recommendations, Information
technology - Message Handling Systems (MHS). X.400:
System and Service Overview; X.402: Overall
Architecture; X.411: Message Transfer System: Abstract
Service Definition and Procedures; X.420: Interpersonal
Messaging System; 1996.
Recommendationsの[X.400]ITU-T X.400 Series、情報技術--メッセージHandling Systems(MHS)。 X.400: システムとサービス概要。 X.402: 総合的なアーキテクチャ。 X.411: メッセージ転送システム: 抽象的なサービス定義と手順。 X.420: 個人間のメッセージシステム。 1996.
6.2. Informative References
6.2. 有益な参照
[BODYMAP] Alvestrand, H., Ed., "Mapping between X.400 and RFC-
822/MIME Message Bodies", RFC 2157, January 1998.
[BODYMAP] エドAlvestrand、H.、RFC2157、「X.400とRFC822/MIMEメッセージの間でボディーを写像すること」での1月1998日
[MIXER] Kille, S., Ed., "MIXER (Mime Internet X.400 Enhanced
Relay): Mapping between X.400 and RFC 822/MIME", RFC
2156, January 1998.
[ミキサー] Kille、S.、エド、「ミキサー(パントマイムインターネットX.400はリレーを機能アップしました):」 「X.400とRFC822/の間でMIMEを写像します」、RFC2156、1998年1月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April, 2001.
[SMTP] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
7. Editors' Addresses
7. エディタのアドレス
Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 USA
ポールホフマンインターネットメール共同体127セグレ・Placeカリフォルニア95060サンタクルス(米国)
EMail: phoffman@imc.org
メール: phoffman@imc.org
Chris Bonatti IECA, Inc. 15309 Turkey Foot Road Darnestown, MD 20878-3640 USA
フット・ロードDarnestown、クリスBonatti IECA Inc.15309トルコMD20878-3640米国
EMail: bonattic@ieca.com
メール: bonattic@ieca.com
Anders Eggen Forsvarets Forskningsinstitutt Postboks 25 2027 Kjeller, Norway
Kjeller、アンダースEggen Forsvarets Forskningsinstitutt Postboks25 2027ノルウェー
EMail: anders.eggen@ffi.no
メール: anders.eggen@ffi.no
Hoffman, et al. Standards Track [Page 14] RFC 3854 Securing X.400 with S/MIME July 2004
ホフマン、他 2004年7月にS/MIMEでX.400を固定する標準化過程[14ページ]RFC3854
8. Full Copyright Statement
8. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Hoffman, et al. Standards Track [Page 15]
ホフマン、他 標準化過程[15ページ]
一覧
スポンサーリンク
