[要約] RFC 3855は、X.400でS/MIMEオブジェクトを転送するための仕様です。その目的は、セキュアな電子メールの送信と受信を可能にすることです。
Network Working Group P. Hoffman
Request for Comments: 3855 IMC
Category: Standards Track C. Bonatti
IECA
July 2004
Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400
x.400で安全/多目的インターネットメール拡張（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）The Internet Society（2004）。
Abstract
概要
This document describes protocol options for conveying objects that have been protected using the Cryptographic Message Syntax (CMS) and Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1 over an X.400 message transfer system.
このドキュメントでは、X.400メッセージ転送システムを介して、暗号化メッセージの構文（CMS）およびセキュア/マルチパスインターネットメールエクステンション（S/MIME）バージョン3.1を使用して保護されているオブジェクトを伝えるためのプロトコルオプションについて説明します。
The techniques described in the Cryptographic Message Syntax [CMS] specification and message specifications can reasonably be transported via a variety of electronic mail systems. This specification defines the options and values necessary to enable interoperable transport of S/MIME messages over an X.400 system.
暗号化メッセージの構文[CMS]仕様とメッセージ仕様に記載されている手法は、さまざまな電子メールシステムを介して合理的に輸送できます。この仕様では、X.400システムでS/MIMEメッセージの相互運用可能な輸送を有効にするために必要なオプションと値を定義します。
This document describes a mechanism for using CMS objects as the message content of X.400 messages in a native X.400 environment. This means that gateways or other functions that expect to deal with IPMS, such as those specified in [MIXER] and [BODYMAP], cannot do anything with these messages. Note that cooperating S/MIME agents must support common forms of message content in order to achieve interoperability.
このドキュメントでは、CMSオブジェクトをネイティブX.400環境でX.400メッセージのメッセージコンテンツとして使用するメカニズムについて説明しています。これは、[ミキサー]や[ボディマップ]で指定されているものなど、IPMを処理することを期待するゲートウェイまたはその他の機能が、これらのメッセージで何もできないことを意味します。協力するS/MIMEエージェントは、相互運用性を実現するために、メッセージコンテンツの一般的な形式をサポートする必要があることに注意してください。
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。
Object Identifier (OID): A globally unique identifier value consisting of a sequence of integer values assigned through distributed registration as specified by ISO/IEC 8824.
オブジェクト識別子（OID）：ISO/IEC 8824で指定された分散登録を通じて割り当てられた一連の整数値で構成されるグローバルな一意の識別子値。
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ビットまたはバイナリデータを送信するチャネルを介して送信することができます。
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実装との逆方向の互換性を維持することです。
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は特定のユーザーへのメッセージの配信可能性を決定し、ユーザーエージェントやメッセージストアがコンテンツを解釈および処理できるようにします。
Some X.400 content types further refine the structure of content as a set of heading elements and body parts. An example of this is the Interpersonal Messaging System (IPMS). The IPMS content structure is able to convey zero or more arbitrary body parts each identified by the body part type. The body part type is an ASN.1 OID or Integer that denotes the syntax and semantics of the body part in question.
一部のX.400コンテンツタイプは、一連の見出し要素と体の部分としてコンテンツの構造をさらに洗練します。この例は、対人メッセージングシステム（IPMS）です。IPMSコンテンツ構造は、ボディパーツタイプでそれぞれ識別されるゼロ以上の任意の身体部分を伝えることができます。ボディパーツタイプは、問題の身体部分の構文とセマンティクスを示すasn.1 oidまたは整数です。
When transporting a CMS-protected message in X.400, the preferred approach (except as discussed in section 2.3 below) is to convey the object as X.400 message content. This section describes how S/MIME CMS objects are conveyed as the content part of X.400 messages. This mechanism is suitable for transport of CMS-protected messages regardless of the mail content that has been encapsulated.
X.400でCMSで保護されたメッセージを輸送する場合、好みのアプローチ（以下のセクション2.3で説明する場合を除く）は、オブジェクトをX.400メッセージコンテンツとして伝えることです。このセクションでは、S/MIME CMSオブジェクトがX.400メッセージのコンテンツ部分として伝達される方法について説明します。このメカニズムは、カプセル化されたメールコンテンツに関係なく、CMS保護されたメッセージの輸送に適しています。
Implementations MUST include the CMS object in the content field of the X.400 message.
実装には、X.400メッセージのコンテンツフィールドにCMSオブジェクトを含める必要があります。
If the CMS object is covered by an outer MIME wrapper, the content-type field of the P1 envelope MUST be set to the following CMS-defined value:
CMSオブジェクトがアウターマイムラッパーでカバーされている場合、P1エンベロープのコンテンツタイプのフィールドを次のCMS定義値に設定する必要があります。
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }
If the CMS object is not covered by an outer MIME wrapper, the content-type field of the P1 envelope MUST be set to the following CMS-defined value:
CMSオブジェクトがアウターマイムラッパーでカバーされていない場合、P1エンベロープのコンテンツタイプのフィールドを次のCMS定義値に設定する必要があります。
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
content-types(1) 6}
When transporting a plaintext MIME object in X.400, the preferred approach is to convey the object as X.400 message content. The content-type field of the P1 envelope MUST be set to the following CMS-defined value:
X.400でPlantext Mimeオブジェクトを輸送する場合、好みのアプローチはオブジェクトをX.400メッセージコンテンツとして伝えることです。P1エンベロープのコンテンツ型フィールドは、次のCMS定義値に設定する必要があります。
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }
Under some circumstances S/MIME CMS-protected messages can be conveyed within select body parts of the content. Implementations generally SHOULD NOT embed CMS objects within X.400 body parts, but should instead convey them as content as described in section 2.2. Nevertheless, one notable exception is necessary for the case of forwarding.
状況によっては、S/MIME CMSで保護されたメッセージをコンテンツの一部のボディ部分内で伝えることができます。一般に、実装はx.400ボディ部分内にCMSオブジェクトを埋め込むべきではありませんが、代わりにセクション2.2で説明されているようにコンテンツとしてそれらを伝える必要があります。それにもかかわらず、転送の場合には1つの注目すべき例外が必要です。
In instances when CMS objects are forwarded as part of a message forwarding function, use of a body part is necessary. When forwarding a CMS object in an IPMS or IPMS-compatible body part, implementations MUST use the content-body-part as formally defined by [X.400], as shown below for reference.
CMSオブジェクトがメッセージ転送機能の一部として転送される場合、身体部分の使用が必要です。IPMSまたはIPMS互換のボディパーツにCMSオブジェクトを転送する場合、実装は、参照のために以下に示すように、[x.400]で正式に定義されているようにコンテンツボディパートを使用する必要があります。
content-body-part {ExtendedContentType:content-type}
EXTENDED-BODY-PART-TYPE ::= {
PARAMETERS {ForwardedContentParameters IDENTIFIED BY
{id-ep-content -- concatenated with content-type -- }},
DATA {Content IDENTIFIED BY
{id-et-content -- concatenated with content-type -- }} }
ForwardedContentParameters ::= SET {
delivery-time [0] MessageDeliveryTime OPTIONAL,
delivery-envelope [1] OtherMessageDeliveryFields OPTIONAL,
mts-identifier [2] MessageDeliveryIdentifier OPTIONAL }
id-ep-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) ep(11) 17}
id-et-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) et(4) 17}
The implementation MUST copy the CMS object to be forwarded into the Content field of the content-body-part. The direct-reference field of the body part MUST include the OID formed by the concatenation of the id-et-content value and the following CMS-defined value.
実装は、CMSオブジェクトをコピーして、コンテンツボディパートのコンテンツフィールドに転送する必要があります。身体部分の直接的な参照フィールドには、ID-ETコンテンツ値の連結と次のCMS定義値によって形成されたOIDを含める必要があります。
id-ct-contentInfo OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) content-types(1) 6}
For example, to forward any CMS object the DATA component of the body part would be identified by { 2 6 1 4 17 1 2 840 113549 1 9 16 1 6 }.
たとえば、任意のCMSオブジェクトを転送するには、{2 6 1 4 17 1 2 840 113549 1 9 16 1 6}によって身体部分のデータコンポーネントが識別されます。
The ForwardedContentParameters are optional and MAY be supported at the discretion of the implementor. The OID value id-et-content MAY also be included in the original-encoded-information-types field of the X.400 message envelope at the discretion of the sending S/MIME agent.
ForwardedContentParametersはオプションであり、実装者の裁量でサポートされる場合があります。OID値ID-ET-Contentは、送信S/MIMEエージェントの裁量でX.400メッセージエンベロープの元のエンコードインフォメーションタイプフィールドに含めることもできます。
In this instance, the content-type field of the P1 envelope MUST be set to the value associate with the forwarding content (e.g., integer 22 for IPMS).
この例では、P1エンベロープのコンテンツタイプのフィールドを、転送コンテンツ（例：IPMSの整数22）に関連する値に設定する必要があります。
According to various S/MIME specifications for message wrapping, CMS objects MAY optionally be wrapped in MIME to dynamically support 7- bit transport. This outer wrapping is not required for X.400 transport, and generally SHOULD NOT be applied in a homogeneous X.400 environment. Heterogeneous mail systems or other factors MAY require the presence of this outer MIME wrapper
メッセージラッピング用のさまざまなS/MIME仕様によると、CMSオブジェクトはオプションでMIMEでラップして、7ビットトランスポートを動的にサポートする場合があります。この外側のラッピングはX.400輸送には必要ありません。通常、均一なX.400環境には適用されないでください。不均一なメールシステムまたは他の要因がこの外側のマイムラッパーの存在を必要とする場合があります
In [MSG], the application/pkcs7-mime content type and optional "smime-type" parameter are used to convey details about the security applied (signed or enveloped) along with information about the contained content. This may aid receiving S/MIME implementations in correctly processing the secured content. Additional values of smime-type are defined in [ESS]. In an X.400 transport environment, MIME typing is not available. Therefore the equivalent semantic is conveyed using the Encoded Information Types (EITs). The EITs are conveyed in the original-encoded-information-types field of the X.400 message envelope. This memo defines the following smime-types.
[MSG]では、アプリケーション/PKCS7-MIMEコンテンツのタイプとオプションの「SMIMEタイプ」パラメーターを使用して、含まれているコンテンツに関する情報とともに、適用されたセキュリティ（署名または封筒）に関する詳細を伝えます。これにより、セキュリティで保護されたコンテンツを正しく処理する際にS/MIMEの実装を受信することができます。SMIMEタイプの追加値は[ess]で定義されています。X.400輸送環境では、MIMEタイピングは利用できません。したがって、同等のセマンティックは、エンコードされた情報タイプ（EIT）を使用して伝達されます。eitsは、x.400メッセージエンベロープの元のエンコードインフォーメーションタイプフィールドで伝えられます。このメモは、次のスマイムタイプを定義します。
+-----------------------------------------------------+
| |
| smime-type EIT Value (OID) |
| CMS protection type Inner Content |
| |
+-----------------------------------------------------+
| |
| enveloped-data id-eit-envelopedData |
| EnvelopedData Data |
| |
| signed-data id-eit-signedData |
| SignedData Data |
| |
| certs-only id-eit-certsOnly |
| SignedData empty (zero-length content) |
| |
| signed-receipt id-eit-signedReceipt |
| SignedData Receipt |
| |
| enveloped-x400 id-eit-envelopedx400 |
| EnvelopedData X.400 content |
| |
| signed-x400 id-eit-signedx400 |
| SignedData X.400 content |
| |
| compressed-data id-eit-compressedData |
| CompressedData RFC 3274 compression wrapper |
| |
+-----------------------------------------------------+
Sending agents SHOULD include the appropriate S/MIME EIT OID value. Receiving agents SHOULD recognize S/MIME OID values in the EITs field, and process the message appropriately according to local procedures.
送信エージェントには、適切なS/MIME EIT OID値を含める必要があります。受信エージェントは、EITSフィールドでS/MIME OID値を認識し、ローカル手順に従ってメッセージを適切に処理する必要があります。
In order that consistency can be obtained in future S/MIME EIT assignments, the following guidelines should be followed when assigning new EIT values. Values assigned for S/MIME EITs should correspond to assigned smime-type values on a one-to-one basis. The restrictions of section 3.2.2 of [MSG] therefore apply. S/MIME EIT values may coexist with other EIT values intended to further qualify the makeup of the protected content.
将来のS/MIME EITの割り当てでその一貫性を取得できるために、新しいEIT値を割り当てるときは、次のガイドラインに従う必要があります。S/MIME EITに割り当てられた値は、1対1のベースで割り当てられたSMIMEタイプの値に対応する必要があります。したがって、[MSG]のセクション3.2.2の制限が適用されます。S/MIME EIT値は、保護されたコンテンツの構成をさらに適格にすることを目的とした他のEIT値と共存する場合があります。
The enveloped data EIT indicates that the X.400 content field contains a MIME type that has been protected by the CMS enveloped-data content type in accordance with [MSG]. The resulting enveloped data CMS content is conveyed in accordance with section 2.2. This EIT should be indicated by the following OID value:
包括されたデータEITは、X.400コンテンツフィールドに[MSG]に従ってCMSエンベロープデータコンテンツタイプによって保護されているMIMEタイプが含まれていることを示しています。結果の包括的なデータCMSコンテンツは、セクション2.2に従って伝えられます。このEITは、次のOID値で示す必要があります。
id-eit-envelopedData OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedData(1) }
The signed data EIT indicates that the X.400 content field contains a MIME type that has been protected by the CMS signed-data content type in accordance with [MSG]. The resulting signed data CMS content is conveyed in accordance with section 2.2. This EIT should be indicated by the following OID value:
署名されたデータEITは、X.400コンテンツフィールドに[MSG]に従ってCMS署名DATAコンテンツタイプによって保護されているMIMEタイプが含まれていることを示しています。結果の署名されたデータCMSコンテンツは、セクション2.2に従って伝えられます。このEITは、次のOID値で示す必要があります。
id-eit-signedData OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-signedData(2) }
The certs-only message is used to transport certificates and/or CRLs, such as in response to a registration request. This is described in [CERT31]. The certs-only message consists of a single instance of CMS content of type signed-data. The encapContentInfo eContent field MUST be absent and signerInfos field MUST be empty. The resulting certs-only CMS content is conveyed in accordance with section 2.2. This EIT should be indicated by the following OID value:
CERTSのみのメッセージは、登録要求に応じて、証明書および/またはCRLの輸送に使用されます。これは[CERT31]で説明されています。CERTSのみのメッセージは、SIGNED-DATAのタイプのCMSコンテンツの単一インスタンスで構成されています。EncapContentInfo econtentフィールドは欠席し、Signerinfosフィールドが空でなければなりません。結果の証明書のみのCMSコンテンツは、セクション2.2に従って伝えられます。このEITは、次のOID値で示す必要があります。
id-eit-certsOnly OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-certsOnly(3) }
The signed receipt EIT indicates that the X.400 content field contains a Receipt content that has been protected by the CMS signed-data content type in accordance with [ESS]. The resulting CMS signed-data content is conveyed in accordance with section 2.2. This EIT should be indicated by the following OID value:
署名された領収書EITは、X.400コンテンツフィールドに[ESS]に従って署名されたDATAコンテンツタイプによって保護されている領収書コンテンツが含まれていることを示しています。結果のCMS署名されたDATAコンテンツは、セクション2.2に従って伝えられます。このEITは、次のOID値で示す必要があります。
id-eit-signedReceipt OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-signedReceipt(4) }
The enveloped X.400 EIT indicates that the X.400 content field contains X.400 content that has been protected by the CMS enveloped-data content type in accordance with [X400WRAP]. The resulting enveloped X.400 CMS content is conveyed in accordance with section 2.2. This EIT should be indicated by the following OID value:
封筒に囲まれたX.400 EITは、X.400コンテンツフィールドに[X400Wrap]に従ってCMSエンベロープデータコンテンツタイプによって保護されているX.400コンテンツが含まれていることを示しています。結果として包まれたX.400 CMSコンテンツは、セクション2.2に従って伝達されます。このEITは、次のOID値で示す必要があります。
id-eit-envelopedX400 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedX400(5) }
The signed X.400 EIT indicates that the X.400 content field contains X.400 content that has been protected by the CMS signed-data content type in accordance with [X400WRAP]. The resulting signed X.400 CMS content is conveyed in accordance with section 2.2. This EIT should be indicated by the following OID value:
署名されたX.400 EITは、X.400コンテンツフィールドに[X400Wrap]に従ってCMS署名されたDATAコンテンツタイプによって保護されているX.400コンテンツが含まれていることを示しています。結果として署名されたX.400 CMSコンテンツは、セクション2.2に従って伝達されます。このEITは、次のOID値で示す必要があります。
id-eit-signedX400 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-signedX400(6) }
The compressed data EIT indicates that the X.400 content field contains a another type that has been compressed by the compressed-data content type in accordance with [COMPRESS]. The resulting CMS content is conveyed in accordance with section 2.2. This EIT should be indicated by the following OID value:
圧縮データEITは、X.400コンテンツフィールドに、[圧縮]に従って圧縮されたDATAコンテンツタイプによって圧縮された別のタイプが含まれていることを示しています。結果のCMSコンテンツは、セクション2.2に従って伝達されます。このEITは、次のOID値で示す必要があります。
id-eit-compressedData OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-compressedData(7) }
Care should be taken in the selection of X.400 services to be used in conjunction with CMS objects. Services affecting conversion of the content, expansion of Distribution Lists (DLs), and message redirection can interact badly with services provided by the "EnvelopedData" and "SignedData" CMS content types.
CMSオブジェクトと組み合わせて使用するX.400サービスの選択に注意する必要があります。コンテンツの変換に影響を与えるサービス、配布リスト（DLS）の拡張、およびメッセージリダイレクトは、「EnvelopedData」および「SignedData」CMSコンテンツタイプによって提供されるサービスとひどく相互作用できます。
MTS conversion is not applicable to the scenario of this document because such conversion is incompatible with CMS protection mechanisms. X.400 systems that implement conversion services should generally be unable to attempt conversion of CMS content types because those types do not conform to X.420 structure rules. Nevertheless, when transporting CMS objects within an X.400 environment, the Conversion Prohibition service SHOULD be selected.
MTS変換は、このような変換はCMS保護メカニズムと互換性がないため、このドキュメントのシナリオには適用されません。これらのタイプはX.420構造ルールに準拠していないため、コンバージョンサービスを実装するX.400システムは、一般にCMSコンテンツタイプの変換を試みることができないはずです。それにもかかわらず、X.400環境内でCMSオブジェクトを輸送する場合、変換禁止サービスを選択する必要があります。
X.400 message redirection services can have an indirect impact on the application of the CMS "EnvelopedData" content type. Several different forms of redirection are possible in X.400, including:
X.400メッセージリダイレクトサービスは、CMSの「EnvelopedData」コンテンツタイプの適用に間接的な影響を与える可能性があります。X.400では、以下を含むいくつかの異なる形式のリダイレクトが可能です。
- Originator Requested Alternate Recipient (ORAR) - Alternate Recipient Assignment - Redirection of Incoming Messages
- オリジネーターは代替受信者（ORAR）を要求しました - 代替受信者の割り当て - 着信メッセージのリダイレクト
In addition, any auto-forwarding services that are not security-aware may share the same problem. An auto-forwarding implementation that removes the EnvelopedData and reapplies it for the forwarded recipient is not affected by this problem. The normal case is that the private key is not available when the human user is not present, thus decryption is not possible. However, if the private key is present, forwarding can be used instead.
さらに、セキュリティ対応ではない自動配りサービスは、同じ問題を共有する場合があります。EnvelopedDataを削除し、転送された受信者のためにそれを再適用する自動配りの実装は、この問題の影響を受けません。通常のケースは、人間のユーザーが存在しないときに秘密鍵が利用できないため、復号化は不可能です。ただし、秘密鍵が存在する場合、代わりに転送を使用できます。
When the "EnvelopedData" content type is used to protect message contents, an instance of RecipientInfo is needed for each recipient and alternate recipient in order to ensure the desired access to the message. A RecipientInfo for the originator is a good practice just in case the MTS returns the whole message.
「EnvelopedData」コンテンツタイプを使用してメッセージコンテンツを保護する場合、メッセージへの目的のアクセスを確保するために、各受信者と代替受信者にレシピエンティインフーのインスタンスが必要です。OriginatorのReciontientInfoは、MTSがメッセージ全体を返した場合に備えて、良い習慣です。
In the event that ORAR is used, the originator is aware of the identity of the alternate recipient and SHOULD include a corresponding RecipientInfo element. For other forms of redirection (including non-security-aware auto-forwarding) the alternate recipient must either have access to the intended recipient's keys (not recommended) or must relay the message to the intended recipient by other means.
ORARが使用された場合、発信者は代替レシピエントの身元を認識しており、対応するRecipientINFO要素を含める必要があります。他の形式のリダイレクト（セキュリティを認識していない自動配りを含む）の場合、代替レシピエントは、意図した受信者のキーにアクセスする（推奨されない）か、他の手段で対象受信者にメッセージを中継する必要があります。
X.400 DLs can have an indirect impact on the application of the CMS "EnvelopedData" content type. When the "EnvelopedData" content type is used to protect message contents, an instance of RecipientInfo is needed for each recipient in order to ensure the desired access to the message. Messages to a DL would typically include only a single RecipientInfo associated with the DL. Unlike Mail Lists (MLs) described in [ESS], however, X.400 DLs are not generally security-aware and do not regenerate RecipientInfo elements for the DL members. It is recommended that a security-aware ML conforming to [ESS] be used in preference to X.400 DLs. When transporting CMS objects within an X.400 environment, the DL Expansion Prohibited service SHOULD be selected.
X.400 DLSは、CMS「EnvelopedData」コンテンツタイプの適用に間接的な影響を与える可能性があります。「EnvelopedData」コンテンツタイプを使用してメッセージコンテンツを保護する場合、メッセージへの目的のアクセスを確保するために、各受信者にReciontientINFOのインスタンスが必要です。DLへのメッセージには、通常、DLに関連付けられた単一のRecipientInfoのみが含まれます。ただし、[ESS]で説明されているメールリスト（MLS）とは異なり、X.400 DLSは一般にセキュリティ認識ではなく、DLメンバーのRecipientInfo要素を再生しません。[ess]に準拠するセキュリティ認識MLをX.400 DLSよりも優先して使用することをお勧めします。X.400環境内でCMSオブジェクトを輸送する場合、DL拡張を禁止するサービスを選択する必要があります。
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]のセキュリティに関する考慮事項セクションで特定されています。
[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月。
[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月。
[COMPRESS] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[Compress] Gutmann、P。、「暗号化メッセージ構文（CMS）の圧縮データコンテンツタイプ」、RFC 3274、2002年6月。
[ESS] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS] Hoffman、P.、ed。、「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月。
[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., "Mapping between X.400 and RFC-822/MIME Message Bodies", RFC 2157, January 1998.
[Bodymap] Alvestrand、H。、「X.400とRFC-822/MIMEメッセージボディの間のマッピング」、RFC 2157、1998年1月。
[MIXER] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[ミキサー]キル、S。、「ミキサー（MIMEインターネットX.400強化リレー）：X.400とRFC 822/MIMEの間のマッピング」、RFC 2156、1998年1月。
[X400WRAP] Hoffman, P., Bonatti, C., and A. Eggen, "Securing X.400 Content with Secure/Multipurpose Internet Mail Extensions (S/MIME), RFC 3854, July 2004.
[X400Wrap] Hoffman、P.、Bonatti、C。、およびA. Eggen、「セキュア/多目的インターネットメールエクステンション（S/MIME）、RFC 3854、2004年7月のX.400コンテンツの保護。
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
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エディター機能の資金は現在、インターネット協会によって提供されています。