Network Working Group P. Hoffman
Request for Comments: 3854 IMC
Category: Standards Track C. Bonatti
IECA
A. Eggen
FFI
July 2004
Securing X.400 Content with Secure/Multipurpose Internet Mail
Extensions (S/MIME)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（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).
この文書では、/セキュア多目的インターネットメール拡張（S / MIME）とX.400コンテンツに暗号署名および暗号化サービスを追加するためのプロトコルを記述しています。
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).
暗号メッセージ構文[CMS明細書に記載された技術は、多くの異なるコンテンツタイプをサポートするのに十分に一般的です。 [CMS]仕様は、このように異なるセキュリティ・メカニズムを提供するための多くのオプションを提供します。 X.400コミュニティ内のシステムの相互運用性を確保するためには、（このドキュメントの「CMS-X.400」と呼ばれる）X.400コンテンツを保護するためにCMS機能の使用を指定する必要があります。
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).
この文書は、それがコンテンツX.400ではなく、MIME（Multipurpose Internet Mail Extensions）のの要件に合わせて調整されていること以外は、S / MIMEバージョン3.1メッセージ仕様[MSG]に類似であることを意図しています。
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.400コンテンツタイプを作成する方法を定義します。 X.400のコンテンツを運ぶS / MIMEメッセージを作成するためには、S / MIMEエージェントは、このドキュメントの仕様に従うだけでなく、[CMS]に記載された仕様があります。また、このメモは、これらの身体部分を輸送するために使用することができるアプリケーション/ PKCS7-MIMEの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.
この文書では、またはIPMSメッセージかもしれかもしれない全体のX.400メッセージの内容にセキュリティサービスを適用するについて説明します。これらのオブジェクトは、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.
CMSオブジェクトがRFC 822メッセージの一部として送信された場合は、標準MIXERゲートウェイは、[MIXER]最も可能性の高いメッセージをカプセル化することを選択します。これは、X.400の受信者が使用可能なフォーマットになりそうではありません。 MIXERは、特にX.420対人メッセージと非セキュアRFC822 / MIMEメッセージ間の変換に焦点を当てています。セクション7.3と[BODYMAP]の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オブジェクトのリレーをサポートするためのゲートウェイサービスの定義は、この文書の範囲を超えています。
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」、「必須」、「推奨」、「SHOULD」「SHALL」とは、本書ではBCP 14、RFC 2119 [MUSTSHOULD]で説明されるように解釈される「場合があります」。
For the purposes of this document, the following definitions apply.
このドキュメントの目的のために、以下の定義が適用されます。
ASN.1: Abstract Syntax Notation One, as defined in ISO/IEC 8824.
ASN.1：抽象構文記法1、ISO / IEC 8824で定義されています。
BER: Basic Encoding Rules for ASN.1, as defined in ISO/IEC 8825-1.
BER：ASN.1のための基本的な符号化規則、ISO / IEC 8825から1に定義されています。
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 / IEC 8825から1に定義されています。
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ビットのデータ：文字のいずれも8ビットが設定されていない、およびNO NULL文字が含まれていない未満998の文字行とテキストデータ。 <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.
転送エンコーディング：データ上で行わ可逆変換ので、8ビットまたはバイナリデータは、7ビットのデータを送信するチャネルを介して送信されてもよいです。
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エージェント：受信エージェント、送信エージェント、またはその両方をあるユーザーソフトウェア。
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 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をサポートするX.400とMIMEシステム間の相互運用性を容易に達成可能であると考えられていない署名され、また、S / MIMEバージョン2をサポートしていない既存のX.400実装はないと考えられています。したがって、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.
可能な場合は、S / MIME v3.1のラッパを採用し、既存のX.400実装との下位互換性を維持するために、このドキュメントの目標です。
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]は、暗号アルゴリズムの使用に関する追加の詳細を提供します。
Sending and receiving agents MUST support SHA-1 [CMSALG].
送信側と受信側エージェントは、SHA-1 [CMSALG]サポートしなければなりません。
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].
受信エージェントは、ID-DSA-WITH-SHA1 [CMSALG]で定義をサポートしなければなりません。アルゴリズムのパラメータは、（NULLとしてエンコードされていない）に存在してはなりません。受信エージェントは、[CMSALG]で定義rsaEncryptionをサポートしなければなりません。
Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption.
エージェントを送信すると、ID-DSA-と-SHA1のいずれかまたはrsaEncryptionをサポートしなければなりません。
Sending and receiving agents MUST support rsaEncryption, defined in [CMSALG].
送信および[CMSALG]で定義rsaEncryptionをサポートしなければならない薬剤を受けます。
Sending and receiving agents SHOULD support Diffie-Hellman defined in [CMSALG].
送信およびエージェントを受信する[CMSALG]で定義されたディフィー - ヘルマンをサポートする必要があります。
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コンテンツタイプの1つを含むContentInfo構造体のインスタンスから成ります。 CMSは、複数のコンテンツタイプを定義します。これらのうち、唯一のSignedDataとEnvelopedDataのコンテンツタイプは、CMS-X.400のために使用されています。
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コンテンツタイプを使用するかしなければなりません。
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.
送信者は、メッセージにプライバシー保護を適用するためにEnvelopedDataのコンテンツタイプを使用しなければなりません。送信者は、このサービスを使用するために意図された各メッセージ受信者の公開鍵へのアクセス権を持っている必要があります。このコンテンツタイプは、認証を提供しません。
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つのインスタンスを扱うことができなければなりません。送信エージェントは、各CMS-X400メッセージの次の署名された属性のそれぞれの1つのインスタンスを生成する必要があります。
- signingTime - sMIMECapabilities - sMIMEEncryptionKeyPreference
- 署名タイム - S MIME機能を - SMIME暗号化キープ
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メッセージ仕様[MSG]に従ってしていなければなりません。 signingTime属性の取り扱いは[MSG]の節2.5.1に従わなければなりません。 SMIMEケーパビリティ属性の取り扱いは[MSG]の節2.5.2に従わなければなりません。 sMIMEEncryptionKeyPreference属性の取り扱いは[MSG]の節2.5.3に従わなければなりません。
Further, receiving agents SHOULD be able to handle zero or one instance in the signed attributes of the signingCertificate attribute [ESS].
さらに、受信エージェントは[ESS] signingCertificate属性の署名された属性にゼロまたは1つのインスタンスを扱うことができるべきです。
Sending agents SHOULD generate one instance of the signingCertificate signed attribute in each CMS-X400 message.
送信エージェントは、各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.
これらの属性のための追加の属性と値は、将来的に定義されてもよいです。受信エージェントは、優雅な方法で認識しない属性または値を処理する必要があります。
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.
ユーザーが署名されているデータのすべてを知っているように、ここに記載されていない署名属性を含め送付エージェントは、ユーザーにこれらの属性が表示されます。
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.
送信とDES EDE3 CBCで暗号化と復号化をサポートしなければならない薬を受け、以下「トリプルDES」[CMSALG]と呼ばれます。送信側と受信側エージェント128、192、および256ビットのキーサイズでAES [CMSAES]と暗号化及び復号化をサポートする必要があります。
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定義コンテンツタイプの1つを含むContentInfo構造）の組み合わせです。そのような証明書やアルゴリズム識別子としてX.400コンテンツおよび他のデータは、CMSオブジェクトを生成するCMS処理施設に与えられます。また、このドキュメントはX.400コンテンツをカプセル化するときにネストされ、固定されたS / MIMEメッセージをフォーマットする方法を説明し、X.400コンテンツ上トリプルラップされた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つのフォーマットを提供します。異なるフォーマットは、署名されたメッセージのための特定のいくつかの環境を、対応するために必要とされます。のみ、これらの署名のいずれかの形式は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.
それはむしろ、テキストエンコーディングよりバイナリであり、そして唯一の「埋め込まれた」コンテンツバージョンが使用されているので、その正規化は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].
[X.400]で説明されるようにし、S / MIME [CMS]と[ESS]に記載されているように、このセクションの読者は、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.402 [X.400]で説明されるように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つの送付工程毎に異なる種々のメッセージの発信者と潜在的な受信者を識別する情報オブジェクトには、その前の搬送を文書化し、メッセージ転送システム（MTS）によってその後の搬送を指示し、そのコンテンツを特徴付けます。
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.
コンテンツ - コンテンツは、元のユーザーエージェントは、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.
封筒が負担した情報のワンピースは、コンテンツの種類を識別します。コンテンツタイプは、全体的なコンテンツの構文およびセマンティクスを表す識別子（ASN.1 OIDまたは整数）です。この識別子は、特定のユーザーへのメッセージのデリバリーを決定するために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.
エンベロープの負担情報の別の部分は、コンテンツに表され符号化された情報のタイプを識別する。符号化情報の種類（EIT）は、コンテンツの個々の部分の媒体フォーマット（例えば、IA5テキスト又はグループ3ファクシミリ）を示す識別子（ASN.1オブジェクト識別子または整数）です。さらに、特定のユーザにメッセージのデリバリーを決定するために、それは別のEITからコンテンツの一部を変換して、メッセージ送達を行うための機会を識別するためにMTSを可能にします。
This document describes how S/MIME CMS is used to secure the content part of X.400 messages.
この文書では、S / MIME CMSは、X.400メッセージの内容の一部を固定するために使用される方法について説明します。
The SignedData format as described in the Cryptographic Message Syntax [CMS] MUST be used for signing of X.400 contents.
暗号メッセージ構文[CMS]で説明したようにのSignedData形式はX.400コンテンツの署名に使用されなければなりません。
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 e-コンテンツフィールドに置かなければなりません。このX.400のコンテンツは、コンテンツタイプによって定義されたエンコーディングを維持する必要がありますが、包まれたMIMEすべきではないことに注意してください。保護されたX.400コンテンツのコンテンツ・タイプのオブジェクト識別子のSignedData encapContentInfoのeContentTypeフィールドに置かれなければなりません。
The signedData object is encapsulated by a ContentInfo SEQUENCE with a contentType of id-signedData.
SignedDataオブジェクトは、ID-たsignedDataのcontentTypeのとContentInfo配列によってカプセル化されます。
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]得られた署名された専用メッセージを輸送するために使用されている場合、オプションのMIMEエンコーディングが使用されるべきことに留意されたいです。例えばX.400などのバイナリトランスポートが使用される場合、オプションのMIMEエンコーディングを使用しないでください。
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.
この要件には多くの理由があります。外側のMIMEラッパーはX.400で使用すべきではありません。さらに、X.400システムは外側のMIMEラッパーが必要になる場合がありますSMTP / MIMEシステムと相互作用する場所があります。この包装は、セキュリティラッパーの外側にあるので、2つのシステム間のギャップを埋める可能性のゲートウェイシステムは、必要に応じて、外側MIMEラッパーを適用または除去するのに十分スマートであろう。
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ラッパーを動的配信経路全体にわたって追加または除去することができます。この場合、S / MIMEバージョンで定義されているアプリケーション/ PKCS7-MIMEタイプ3.1メッセージ仕様[MSG]以下のパラメータを使用する必要があります。
Content-Type: application/pkcs7-mime; smime-type=signed-x400 Content-Transfer-Encoding: base64
コンテンツタイプ：アプリケーション/ PKCS7-MIME; SMIME型=署名-X400コンテンツ転送 - エンコード：BASE64
If the application/pkcs7-mime MIME type is used to support 7-bit transport, the steps to create this format are:
アプリケーション/ PKCS7-MIMEの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構造は、ID-たsignedDataのcontentTypeのとContentInfo配列によってカプセル化されます。
Step 3. The CMS object is inserted into an application/pkcs7-mime MIME entity.
ステップ3は、CMSオブジェクトは、アプリケーション/ PKCS7-MIMEのMIME実体に挿入されます。
The smime-type parameter for messages using application/pkcs7-mime with SignedData is "signed-x400" as defined in [TRANSPORT].
SignedDataとアプリケーション/ PKCS7-MIMEを使用してメッセージのSMIME-typeパラメータは[TRANSPORT]で定義されるように "サインインX400" です。
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内容の機密性のために使用されます。
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暗号化コンテンツフィールドに置かなければなりません。このX.400のコンテンツは、コンテンツタイプによって定義されたエンコーディングを維持する必要がありますが、包まれたMIMEすべきではないことに注意してください。保護されたX.400コンテンツのコンテンツ・タイプのオブジェクト識別子はEnvelopedDataのencryptedContentInfoのcontentType分野に置かなければなりません。
The envelopedData object is encapsulated by a ContentInfo SEQUENCE with a contentType of id-envelopedData.
EnvelopedDataのオブジェクトは、ID-EnvelopedDataのののcontentTypeと共にContentInfo配列によってカプセル化されます。
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エンコーディングが使用されるべきことに留意されたいです。バイナリコンテンツのために最適化されている他の輸送（例えば、X.400）を使用する場合、オプションのMIMEエンコーディングを使用しないでください。
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-MIMEタイプ3.1メッセージ仕様[MSG] S / MIMEバージョンで定義されている以下のパラメータを使用する必要があります。
Content-Type: application/pkcs7-mime; smime-type=enveloped-x400 Content-Transfer-Encoding: base64
コンテンツタイプ：アプリケーション/ PKCS7-MIME; SMIME型=包ま-X400のコンテンツ転送 - エンコード：BASE64
If the application/pkcs7-mime MIME type is used to support 7-bit transport, the steps to create this format are:
アプリケーション/ PKCS7-MIMEの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オブジェクトに処理されます。受信者ごとにコンテンツの暗号化キーのコピーを暗号化することに加えて、コンテンツの暗号化キーのコピーは、発信のために暗号化する必要があり、（[CMS]セクション6を参照）EnvelopedDataの中に含まれています。 EnvelopedDataの構造は、ID-EnvelopedDataのののcontentTypeと共にContentInfo配列によってカプセル化されます。
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 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のMIMEエンティティを使用する場合は[TRANSPORT]で定義されるように、エンベロープのみのメッセージのSMIME-typeパラメータは、「エンベロープ-X400」です。
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 IDデータで識別されることを要求し、IDデータが使用される場合、MIMEラッパーが必要です。これは、潜在的にオーバーヘッドの膨大な量につながることができますし、避けるべきです。 S / MIMEバージョン2互換性がない懸念されるので、実装は、直接現在の構造のe-コンテンツとしてカプセル化されたオブジェクトを符号化するべきです。
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構造の周りに使用することのみを必要とします。この場合、アプリケーション/ PKCS7コンテンツタイプを使用しなければなりません。
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構造を入れ子になりました。
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.
S / MIME [ESS]文書のための強化されたセキュリティサービスを確保し、S / MIMEメッセージがフォーマットされ、どのようにネストされた例を提供します。 ESSは、トリプルラップされたS / MIMEメッセージが署名するためのアプリケーション/ PKCS7-MIMEを使用してフォーマットされている方法の例を提供します。
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コンテンツはトリプルラップメッセージ内に搬送することができる方法について説明します。
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.
（「オリジナルコンテンツ」と呼ばれる）X.400内容と手順1.。 X.400の内容は、エンコードされたASN.1する必要がありますが、包まれたMIMEすべきではありません。
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 e-コンテンツフィールドに保護されます。署名される任意の属性を追加します。
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".
単一のブロックとしてステップ3の結果を暗号化するステップ4。 EnvelopedDataのencryptedContentInfo contentTypeのは、ID-たsignedDataに設定しなければなりません。これは、「暗号化されたボディ」と呼ばれています。
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.
ステップ2上記3と同じロジックを使用してステップ5は、単一のブロックとしてステップ4（暗号化された身体）の結果に署名します。 SignedData encapContentInfoのeContentTypeは、ID-のEnvelopedDataに設定しなければなりません。外側のSignedData構造は、ID-たsignedDataのcontentTypeのとContentInfo配列によってカプセル化されます。
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-MIMEコンテンツタイプが使用されなければなりません。 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.
いくつかの例では、SMIME型のみ（署名された専用のメッセージにのみ適用され、このような本命専用として、）つのセキュリティサービスを反映していると作成されます。新しい層が包まれているようしかし、このSMIME型が上向きに伝播されるべきです。本命だけメッセージが暗号化、または新規のSignedData構造に包まれるとしたらこのように、本命専用のSMIME型は、次のMIMEラッパーにまで伝播しなければなりません。換言すれば、最も内側の型が外側に反射されます。
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-コンテンツ。コンテンツタイプ= 1 * DIGIT×（ "" 1 * DIGIT）
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).
コンテンツタイプパラメータ値がある場合のいずれかまたはドット表記のOID（ビルトインコンテンツタイプ用）（拡張されたコンテンツ・タイプのための）単一の整数。
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では、認証局から証明書を取得する方法を指定し、その代わりに、すべての送信エージェントがすでに証明書を持っていることを義務付けていません。 CMP（RFC 2510）とCMC（RFC 2792）：PKIXワーキンググループは、この記事の執筆時点では、証明書登録のための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の展開のために、ユーザエージェントは自動的に署名したリターン・メッセージにその受信者の証明書を要求することを意図した受信者へのメッセージを生成することができます。受信と送信の薬剤はまた、彼らの後に検索を保証するようにユーザーに「ストアおよび保護」できるような方法で特派ための証明書をするためのメカニズムを提供する必要があります。
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アドレスはsubjectAltName拡張であるべきであり、サブジェクト識別名にすべきではありません。
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.
送付エージェントは、X.400コンテンツ内の発信元アドレスは、（例えば、P22の「発信元」フィールド）署名者の証明書でのX.400アドレスを一致させるべきです。
Receiving agents MUST recognize X.400 addresses in the subjectAltName field.
受信エージェントは、のsubjectAltNameフィールドにX.400アドレスを認識しなければなりません。
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 comparison fails, which may be to display a message that shows the recipient the addresses in the certificate or other certificate details.
受信エージェントは、X.400アドレスが証明書に存在していると、発信元アドレスは、コンテンツ内で利用可能な場合X.400コンテンツ内の発信元アドレスは、署名者の証明書でのX.400アドレスと一致していることを確認する必要があります。この比較が失敗した場合、受信エージェントは、受信者に証明書または他の証明書の詳細のアドレスを示すメッセージを表示するためであってもよい、メッセージのいくつかの明示的な代替処理を提供しなければなりません。
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アドレスを伝えるための好ましい手段として、S / MIMEで使用されています。存在する任意のX.400アドレスがx400Address CHOICEのGeneralNameタイプのを使用して符号化されなければなりません。 SubjectAltNameタイプがのGeneralNameのシーケンスであるので、複数のX.400アドレスが存在してもよいです。
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]、[ESS]のセクション6とのSecurity Considerations部[CMS]のセクション5で識別されています。
[CERT31] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[CERT31] Ramsdell、B.、エド。、RFC 3850、2004年7月、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1証明書の取り扱い"。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS] Housley氏、R.、 "暗号メッセージ構文（CMS）"、RFC 3852、2004年7月。
[CMSAES] Schaad, J., "Use of the AES Encryption Algorithm in CMS", RFC 3565, July 2003.
[CMSAES] Schaad、J.、 "CMSでのAES暗号化アルゴリズムの使用"、RFC 3565、2003年7月。
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[CMSALG] Housley氏、R.、 "暗号メッセージ構文（CMS）アルゴリズム"、RFC 3370、2002年8月。
[ESS] Hoffman, P., Editor "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS]ホフマン、P.、エディタ "S / MIMEのためのセキュリティサービスの強化"、RFC 2634、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メッセージ仕様"、RFC 3851、2004年7月。
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[MUSTSHOULD]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[TRANSPORT] Hoffman, P. and C. Bonatti, "Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400", RFC 3855, July 2004.
[TRANSPORT]ホフマン、P.とC. Bonatti、2004年7月、RFC 3855、 "セキュア/多目的インターネットメール拡張（S / MIME）を輸送はX.400内のオブジェクト"。
[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.
勧告の[X.400] ITU-T X.400シリーズ、情報技術 - メッセージハンドリングシステム（MHS）。 X.400：システムとサービスの概要; X.402：全体的なアーキテクチャ。 X.411：メッセージ転送システム：抽象サービス定義と手順。 X.420：対人メッセージングシステム。 1996。
[BODYMAP] Alvestrand, H., Ed., "Mapping between X.400 and RFC-822/MIME Message Bodies", RFC 2157, January 1998.
[BODYMAP] Alvestrand、H.、エド。、RFC 2157、1998年1月、 "X.400およびRFC-822 / MIMEメッセージボディとの間のマッピング"。
[MIXER] Kille, S., Ed., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[MIXER] Kille、S.、エド、 "MIXER（MIMEインターネットX.400拡張リレー）：X.400およびRFC 822 / MIMEの間のマッピング"。、RFC 2156、1998年1月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April, 2001.
[SMTP] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 USA
ポール・ホフマンインターネットメールコンソーシアムセグレ127場所サンタクルス、CA 95060 USA
EMail: phoffman@imc.org
メールアドレス：phoffman@imc.org
Chris Bonatti IECA, Inc. 15309 Turkey Foot Road Darnestown, MD 20878-3640 USA
クリスBonatti IECA、Inc.の15309トルコフット道路Darnestown、MD 20878から3640 USA
EMail: bonattic@ieca.com
メールアドレス：bonattic@ieca.com
Anders Eggen Forsvarets Forskningsinstitutt Postboks 25 2027 Kjeller, Norway
アンダースEggen防衛研究Postboks 25 2027地下室、ノルウェー
EMail: anders.eggen@ffi.no
メールアドレス：anders.eggen@ffi.no
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.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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機能のための基金は現在、インターネット協会によって提供されます。