[要約] RFC 3854は、X.400コンテンツをSecure/Multipurpose Internet Mail Extensions（S/MIME）で保護するためのガイドラインです。このRFCの目的は、X.400メッセージのセキュリティを向上させ、S/MIMEを使用してデータの機密性と整合性を確保することです。
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)
安全/多目的インターネットメール拡張機能（S/MIME）を使用してX.400コンテンツを保護する
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）The Internet Society（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コミュニティ内のシステムの相互運用性を確保するために、X.400コンテンツ（このドキュメントの「CMS-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).
このドキュメントは、S/Mimeバージョン3.1メッセージ仕様[MSG]に似ていることを目的としていますが、除き、多目的インターネットメールエクステンション（MIME）ではなくX.400コンテンツの要件に合わせて調整されています。
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.
このドキュメントでは、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.
CMSオブジェクトがRFC 822メッセージの一部として送信される場合、標準のミキサーゲートウェイ[ミキサー]がメッセージのカプセルをカプセル化することを選択します。これは、X.400の受信者が使用できる形式ではないでしょう。ミキサーは、X.420の対人メッセージと非セキュアーRFC822/MIMEメッセージの間の翻訳に特に焦点を当てています。[ボディマップ]のセクション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オブジェクトのリレーをサポートするゲートウェイサービスの定義は、このドキュメントの範囲を超えています。
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].
このドキュメントの「必須」、「必要」、「必須」、「必須」、「推奨」、および「5月」は、BCP 14、RFC 2119 [必須]で説明されているように解釈されます。
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/IEC 8824で定義されている要約構文表記1。
BER: Basic Encoding Rules for ASN.1, as defined in ISO/IEC 8825-1.
BER：ISO/IEC 8825-1で定義されているASN.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：ISO/IEC 8825-1で定義されているASN.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ビットデータ：長さ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.
転送エンコーディング：データ上に行われた可逆変換が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エージェント：受信エージェント、送信エージェント、またはその両方であるユーザーソフトウェア。
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実装はないと考えられています。さらに、S/MIMEバージョン2をサポートするX.400とMIMEシステム間の署名された相互運用性は、簡単に達成できないと考えられています。したがって、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].
受信エージェントは、[cmsalg]で定義されているid-dsa-with-sha1をサポートする必要があります。アルゴリズムパラメーターは存在しない必要があります（nullとしてエンコードされていません）。受信エージェントは、[cmsalg]で定義されているrsaencryptionをサポートする必要があります。
Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption.
送信エージェントは、id-dsa-with-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]で定義されているdiffie-hellmanをサポートする必要があります。
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コンテンツタイプのいずれかを含むcontentinfo構造のインスタンスで構成されています。CMSは複数のコンテンツタイプを定義します。これらのうち、CMS-X.400には、SignedDataおよびEnvelopedDataコンテンツタイプのみが使用されます。
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.
送信者は、封筒のコンテンツタイプを使用して、プライバシー保護をメッセージに適用する必要があります。送信者は、意図した各メッセージ受信者がこのサービスを使用するために公開キーにアクセスできる必要があります。このコンテンツタイプは認証を提供しません。
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
- 署名時間 - SmimeCapability -SmimeCryptionKeypreference
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]に従っている必要があります。署名時間属性の処理は、[MSG]の条項2.5.1に準拠する必要があります。SmimeCapability属性の取り扱いは、[MSG]の2.5.2項に準拠する必要があります。SMIMECRYCTINGKEYPREFERFING属性の処理は、[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].
さらに、受信エージェントは、signingcertificate属性[ess]の署名された属性でゼロまたは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で暗号化と復号化をサポートする必要があります。送信および受信エージェントは、128、192、および256ビットのキーサイズでAES [CMSAE]で暗号化と復号化をサポートする必要があります。
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つの形式、署名のみのデータ用のいくつかの形式、および署名されたデータと包括的なデータ用のいくつかの形式を提供します。特に署名されたメッセージには、いくつかの環境に対応するには、さまざまな形式が必要です。これらの署名された形式のうちの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]と[cms]および[ess]で説明されているように、x.400とs/mimeを理解することが期待されています。
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メッセージにはエンベロープとコンテンツの2つの部分があります。
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.
エンベロープ - 構成が透過ステップから別のステップまで変化し、メッセージのオリジネーターと潜在的な受信者をさまざまに識別する情報オブジェクトは、以前の伝達を文書化し、その後の伝達をメッセージ転送システム（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は、メッセージの伝達中にコンバージョンを除き、コンテンツを調べたり変更したりしません。MTS変換は、このような変換はCMS保護メカニズムと互換性がないため、このドキュメントのシナリオには適用されません。
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つの情報は、コンテンツのタイプを識別します。コンテンツタイプは、コンテンツ全体の構文とセマンティクスを示す識別子（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オブジェクト識別子または整数）です。さらに、MTSは特定のユーザーへのメッセージの配信可能性を決定し、コンテンツの一部をあるEITから別のEITに変換することにより、メッセージを成果にする機会を特定できます。
This document describes how S/MIME CMS is used to secure the content part of X.400 messages.
このドキュメントでは、X.400メッセージのコンテンツ部分を保護するためにS/MIME CMSを使用する方法について説明します。
The SignedData format as described in the Cryptographic Message Syntax [CMS] MUST be used for signing of X.400 contents.
暗号化メッセージの構文[CMS]で説明されているように、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 Econtentフィールドに配置する必要があります。このX.400コンテンツは、コンテンツタイプで定義されたエンコードを維持する必要があることに注意してください。保護された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.
この要件には多くの理由があります。X.400では、アウターマイムラッパーを使用しないでください。さらに、X.400システムが外側のMIMEラッパーが必要になるSMTP/MIMEシステムと相互作用する場所があります。このラッピングはセキュリティラッパーの外側にあるため、2つのシステム間のギャップを埋める可能性のあるゲートウェイシステムは、必要に応じてアウターマイムラッパーを適用または削除するのに十分なほどスマートになります。
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バージョン3.1メッセージ仕様[MSG]で定義されているアプリケーション/PKCS7-MIMEタイプは、次のパラメーターで使用する必要があります。
Content-Type: application/pkcs7-mime; smime-type=signed-x400
Content-Transfer-Encoding: base64
If the application/pkcs7-mime MIME type is used to support 7-bit transport, the steps to create this format are:
Application/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タイプのパラメーターは、[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]で説明されている封筒形式は、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 EncryptedContentフィールドに配置する必要があります。このX.400コンテンツは、コンテンツタイプで定義されたエンコードを維持する必要があることに注意してください。保護された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ラッパーは、署名ラッパーと暗号化ラッパーの外側にあるため、配信経路全体に動的に追加または削除される場合があります。この場合、S/MIMEバージョン3.1メッセージ仕様[MSG]で定義されているアプリケーション/PKCS7-MIMEタイプは、次のパラメーターで使用する必要があります。
Content-Type: application/pkcs7-mime; smime-type=enveloped-x400
Content-Transfer-Encoding: base64
If the application/pkcs7-mime MIME type is used to support 7-bit transport, the steps to create this format are:
Application/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コンテンツおよびその他の必要なデータは、封筒のタイプのCMSオブジェクトに処理されます。各受信者のコンテンツ暗号化キーのコピーを暗号化することに加えて、コンテンツ暗号化キーのコピーをオリジネーター用に暗号化し、EnvelopedDataに含める必要があります（[CMS]セクション6を参照）。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].
Application/PKCS7-MIME MIMEエンティティを使用する場合、[輸送]で定義されているように、封筒のみのメッセージのSMIMEタイプのパラメーターは「包括された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-DATAで識別される必要があり、ID-DATAを使用するとMIMEラッパーが必要です。これは、膨大な量のオーバーヘッドにつながる可能性があり、避ける必要があります。S/MIMEバージョン2の互換性は懸念されるため、実装はカプセル化されたオブジェクトを現在の構造の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構造の周りでのみ使用する必要があります。この場合、アプリケーション/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の実装は、受信者コンピューターの合理的なリソース制限内でarbitrarily意的にネストされた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は、署名のアプリケーション/PKCS7-MIMEを使用してトリプルラップされたS/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.
ステップ1. X.400コンテンツ（「オリジナルコンテンツ」と呼ばれる）から始めます。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 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は、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.
ステップ5.上記のステップ2および3と同じロジックを使用して、ステップ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.
場合によっては、1つのセキュリティサービス（署名のみのメッセージにのみ適用されるCERTSのみなど）のみを反映するSMIMEタイプが作成されます。ただし、新しい層が包まれているため、このスマイム型を上向きに伝播する必要があります。したがって、CERTSのみのメッセージを暗号化するか、新しいSignedData構造に包まれた場合、SMIMEタイプのCERTSのみを次の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)
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は、証明書当局から証明書を取得する方法を指定するのではなく、すべての送信エージェントにすでに証明書があることを義務付けています。PKIXワーキンググループは、この執筆時点で、証明書登録に関する2つの別個の基準、CMP（RFC 2510）とCMC（RFC 2792）を作成しています。
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アドレスと一致することを確認する必要があります。受信エージェントは、この比較が失敗した場合、メッセージの明示的な代替処理を提供する必要があります。これは、受信者に証明書またはその他の証明書の詳細を示すメッセージを表示する場合があります。
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で使用されます。存在するX.400アドレスは、一般名のX400Address選択を使用してエンコードする必要があります。subjectaltnameタイプは一般名のシーケンスであるため、複数の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]のセクション5、[ESS]のセクション6、および[CMS]のセキュリティに関する考慮事項セクションで特定されています。
[CERT31] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[Cert31] Ramsdell、B.、ed。、「Secure/Multipurpose Internet Mail拡張機能（S/MIME）バージョン3.1証明書処理」、RFC 3850、2004年7月。
[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] Hoffman、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.、ed。、「Secure/Multipurpose Internet Mail Extensions（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.
[必須] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Hoffman、P。and C. Bonatti、「Secure/Multipurpose Internet Mail Extensions（S/MIME）オブジェクトのX.400」、RFC 3855、2004年7月。
[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.、ed。、「X.400とRFC-822/MIMEメッセージボディのマッピング」、RFC 2157、1998年1月。
[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.、ed。、「Mixer（Mime Internet X.400 Enhanced Relay）：X.400とRFC 822/MIMEの間のマッピング」、RFC 2156、1998年1月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April, 2001.
[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 USA
ポールホフマンインターネットメールコンソーシアム127セグレプレイスサンタクルス、カリフォルニア州95060 USA
EMail: phoffman@imc.org
Chris Bonatti IECA, Inc. 15309 Turkey Foot Road Darnestown, MD 20878-3640 USA
Chris Bonatti Ieca、Inc。15309 Turkey Foot Road Darnestown、MD 20878-3640 USA
EMail: bonattic@ieca.com
Anders Eggen Forsvarets Forskningsinstitutt Postboks 25 2027 Kjeller, Norway
Anders Eggen Forsvarets forskningsinstitt postboks 25 2027 Kjeller、ノルウェー
EMail: 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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。