RFC3855 日本語訳
3855 Transporting Secure/Multipurpose Internet Mail Extensions(S/MIME) Objects in X.400. P. Hoffman, C. Bonatti. July 2004. (Format: TXT=25774 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Hoffman
Request for Comments: 3855 IMC
Category: Standards Track C. Bonatti
IECA
July 2004
コメントを求めるワーキンググループP.ホフマン要求をネットワークでつないでください: 3855年のIMCカテゴリ: 標準化過程C.Bonatti IECA2004年7月
Transporting Secure/Multipurpose Internet Mail
Extensions (S/MIME) Objects in X.400
X.400で安全な/マルチパーパスインターネットメールエクステンション(S/MIME)オブジェクトを輸送します。
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document describes 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メッセージ転送システムの上でCryptographic Message Syntax(CMS)を使用することで保護されたオブジェクトを運ぶためのプロトコルオプションとSecure/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1について説明します。
1. Introduction
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.
さまざまな電子メール・システムを通して合理的にCryptographic Message Syntax[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.
このドキュメントはネイティブのX.400環境におけるX.400メッセージに関するメッセージ内容としてCMSオブジェクトを使用するためのメカニズムを記述します。 これは、IPMSに対処すると予想するゲートウェイか他の機能が[MIXER]と[BODYMAP]で指定されたものなどのようにこれらのメッセージで何もできないことを意味します。 協力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オブジェクトのリレーを支えるゲートウェイサービスの定義はこのドキュメントの範囲を超えています。
Hoffman & Bonatti Standards Track [Page 1] RFC 3855 Transporting S/MIME Objects in X.400 July 2004
2004年7月にX.400でS/MIMEオブジェクトを輸送するホフマンとBonatti標準化過程[1ページ]RFC3855
1.1. Terminology
1.1. 用語
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14, RFC 2119 [MUSTSHOULD].
“MUST"(“SHALL")が、このドキュメントで“SHOULD"、「推薦された」、および「5月」が「必要であった」というキーワードはBCP14RFC2119[MUSTSHOULD]で説明されるように解釈されることです。
1.2. Definitions
1.2. 定義
For the purposes of this document, the following definitions apply.
このドキュメントの目的のために、以下の定義は申し込まれます。
ASN.1: Abstract Syntax Notation One, as defined in ISO/IEC 8824.
ASN.1: ISO/IEC8824で定義されるような抽象的なSyntax Notation One。
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/IEC8824による指定されるとしての分配された登録で割り当てられた整数値の系列から成るグローバルにユニークな識別子値。
Transfer Encoding: A reversible transformation made on data so 8-bit or binary data may be sent via a channel that only transmits 7-bit data.
コード化を移してください: 7ビットのデータを送るだけであるチャンネルであまりに8ビットであるデータでされた可逆的な変換かバイナリ・データを送るかもしれません。
1.3. Compatibility with Existing S/MIME Implementations
1.3. 既存のS/MIME実装との互換性
It is a goal of this document to, if possible, maintain backward compatibility with existing X.400 implementations that employ S/MIME v3.1 wrappers.
それはできれば、既存のX.400実装との互換性がその雇用S/MIME v3.1ラッパーであることを後方に支持するこのドキュメントの目標です。
2. S/MIME Packaging
2. S/MIMEパッケージ
2.1. The X.400 Message Structure
2.1. X.400メッセージ構造
This section reviews the X.400 message format. An X.400 message has two parts, the envelope and the content, as described in X.402 [X.400]:
このセクションはX.400メッセージ・フォーマットを見直します。 X.400メッセージには、2つの部品、封筒、および内容がX.402[X.400]で説明されるようにあります:
Envelope -- An information object whose composition varies from one
transmittal step to another and that variously identifies the
message's originator and potential recipients, documents its
previous conveyance and directs its subsequent conveyance by the
Message Transfer System (MTS), and characterizes its content.
封筒--構成が別のものと1譲渡ステップからそれに異なる情報オブジェクトは、Message Transfer System(MTS)で、さまざまにメッセージの創始者と潜在的受取人を特定して、前の運送を記録して、その後の運送を指示して、内容を特徴付けます。
Content -- The content is the piece of information that the
originating User Agent wants to be delivered to one or more
recipients. The MTS neither examines nor modifies the content,
except for conversion, during its conveyance of the message. MTS
conversion is not applicable to the scenario of this document
because such conversion is incompatible with CMS protection
mechanisms.
内容--内容は起因しているUserエージェントを1人以上の受取人に提供されたいという情報の断片です。 MTSはメッセージの運送の間の変換以外の内容を審査でない、また変更しません。 そのような変換がCMS保護メカニズムと両立しないので、MTS変換はこのドキュメントのシナリオに適切ではありません。
Hoffman & Bonatti Standards Track [Page 2] RFC 3855 Transporting S/MIME Objects in X.400 July 2004
2004年7月にX.400でS/MIMEオブジェクトを輸送するホフマンとBonatti標準化過程[2ページ]RFC3855
One piece of information borne by the envelope identifies the type of the content. The content type is an identifier (an ASN.1 OID or Integer) that denotes the syntax and semantics of the content overall. This identifier enables the MTS to determine the message's deliverability to particular users, and enables User Agents and Message Stores to interpret and process the content.
封筒によって持たれている1つの情報が内容のタイプを特定します。 content typeは全体的に見て内容の構文と意味論を指示する識別子(ASN.1OIDかInteger)です。 この識別子は、UserエージェントとMessageストアが内容を解釈して、処理するのをMTSがメッセージのデリベラビリティを特定のユーザに決定するのを可能にして、可能にします。
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.400content typeが1セットのヘッダ要素と身体の部分としてさらに内容の構造を洗練します。 この例はInterpersonal Messaging System(IPMS)です。 IPMSの満足している構造がゼロを伝えることができますか、または身体の部分によってそれぞれ特定されたより任意の身体の部分はタイプします。 ボディー部分タイプは、問題の身体の部分の構文と意味論を指示するASN.1OIDかIntegerです。
2.2. Carrying S/MIME as X.400 Content
2.2. X.400内容としてS/MIMEを運びます。
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オブジェクトが外側のMIMEラッパーでカバーされているなら、P1封筒の内容タイプ分野を以下のCMSの定義された値に設定しなければなりません:
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }
イドデータOBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(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オブジェクトが外側のMIMEラッパーでカバーされていないなら、以下のCMSによって定義された値にP1封筒のcontent type分野を設定しなければなりません:
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}
イドct contentInfo、オブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)content type(1)6をメンバーと同じくらい具体化させます。
2.2.1. Carrying Plaintext MIME objects as X.400 Content
2.2.1. X.400 ContentとしてPlaintext MIMEオブジェクトを運びます。
When transporting a plaintext MIME object in X.400, the preferred approach is to convey the object as X.400 message content. The
X.400で平文MIMEオブジェクトを輸送するとき、好ましい方法はX.400メッセージ内容としてオブジェクトを運ぶことです。 The
Hoffman & Bonatti Standards Track [Page 3] RFC 3855 Transporting S/MIME Objects in X.400 July 2004
2004年7月にX.400でS/MIMEオブジェクトを輸送するホフマンとBonatti標準化過程[3ページ]RFC3855
content-type field of the P1 envelope MUST be set to the following CMS-defined value:
以下のCMSによって定義された値にP1封筒のcontent type分野を設定しなければなりません:
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }
イドデータOBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs7(7)1をメンバーと同じくらい具体化させます。
2.3. Carrying S/MIME as IPMS Body Parts
2.3. IPMSボディ・パーツとしてS/MIMEを運びます。
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.
いくつかの状況で、内容の選んだ身体の部分の中でMIME CMSによってS/保護されたメッセージを伝えることができます。 一般に実装SHOULD NOTは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 -- }} }
満足している身体のパートExtendedContentType: content type EXTENDED-BODY-PART-TYPE:、:= PARAMETERS、イドは内容をepしています--content typeで連結される--のForwardedContentParameters IDENTIFIED BY、DATAはイドは内容をetしています--content typeで連結される--のIDENTIFIED BYを満足させます。
ForwardedContentParameters ::= SET {
delivery-time [0] MessageDeliveryTime OPTIONAL,
delivery-envelope [1] OtherMessageDeliveryFields OPTIONAL,
mts-identifier [2] MessageDeliveryIdentifier OPTIONAL }
ForwardedContentParameters:、:= セットします。納期[0]MessageDeliveryTime OPTIONAL、配送封筒[1]OtherMessageDeliveryFields OPTIONAL、mts-識別子[2]MessageDeliveryIdentifier OPTIONAL
id-ep-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) ep(11) 17}
イドep内容:、:= 共同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}
イドet内容:、:= 共同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.
実装は満足している身体の部分のContent分野に送られるCMSオブジェクトをコピーしなければなりません。 身体の部分の直接的な言及分野はイド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}
イドct contentInfo、オブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)content type(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 }.
例えば身体の部分のDATAの部品が特定されるどんなCMSオブジェクトも進める、2 6 1 4、17、1 2、840、113549、1 9、16、1 6
Hoffman & Bonatti Standards Track [Page 4] RFC 3855 Transporting S/MIME Objects in X.400 July 2004
2004年7月にX.400でS/MIMEオブジェクトを輸送するホフマンとBonatti標準化過程[4ページ]RFC3855
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値のイドet内容はX.400メッセージ封筒の元のコード化された情報タイプ分野に送付S/MIMEエージェントの裁量で含まれるかもしれません。
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).
この場合、推進内容(例えば、IPMSのための整数22)の値の関連にP1封筒のcontent type分野を設定しなければなりません。
2.4. Transfer Encoding
2.4. 転送コード化
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オブジェクトは、7ビットが輸送であるとダイナミックにサポートするためにMIMEで任意に包装されるかもしれません。 この外側のラッピングはX.400輸送、および一般にSHOULD NOTに必要ではありません。均質のX.400環境で、適用されます。 異種のメールシステムか他の要素がこの外側のMIMEラッパーを存在に要求するかもしれません。
2.5. Encoded Information Type Indication
2.5. コード化された情報タイプ指示
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アプリケーション/パントマイムcontent typeと任意の「smime-タイプ」パラメタは、含まれた内容の情報と共に適用された(署名されるか、またはおおわれます)セキュリティに関する詳細を伝えるのに使用されます。 これは、正しく機密保護している内容を処理する際にS/MIME実装を受けながら、支援されるかもしれません。 smime-タイプの加算値は[ESS]で定義されます。 X.400輸送環境で、MIMEタイプは利用可能ではありません。 同等物意味的であるのは、運ばれた使用です。したがって、Encoded情報Types(EITs)。 EITsはX.400メッセージ封筒の元のコード化された情報タイプ分野を運ばれます。 このメモは以下のsmime-タイプを定義します。
Hoffman & Bonatti Standards Track [Page 5] RFC 3855 Transporting S/MIME Objects in X.400 July 2004
2004年7月にX.400でS/MIMEオブジェクトを輸送するホフマンとBonatti標準化過程[5ページ]RFC3855
+-----------------------------------------------------+ | | | 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 | | | +-----------------------------------------------------+
+-----------------------------------------------------+ | | | smime-タイプEIT Value(OID)| | CMS保護タイプInner Content| | | +-----------------------------------------------------+ | | | おおわれたデータイド-eit-envelopedData| | EnvelopedDataデータ| | | | 署名しているデータイド-eit-signedData| | SignedDataデータ| | | | 本命だけイド-eit-certsOnly| | SignedDataは(ゼロ・レングス内容)を空にします。| | | | 署名している領収書イド-eit-signedReceipt| | SignedData領収書| | | | おおわれたx400イド-eit-envelopedx400| | EnvelopedData X.400内容| | | | 署名しているx400イド-eit-signedx400| | SignedData X.400内容| | | | 圧縮されたデータイド-eit-compressedData| | CompressedData RFC3274圧縮ラッパー| | | +-----------------------------------------------------+
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.
送付エージェントSHOULDは適切なS/MIME EIT OID値を含んでいます。 エージェントSHOULDを受けて、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.
新しいEIT値を割り当てるとき、将来のS/MIME EIT課題で一貫性を得ることができるように、以下のガイドラインは従われるべきです。 S/MIME EITsのために割り当てられた値は1〜1個のベースに関する割り当てられたsmime-タイプ値に対応するべきです。 したがって、.2セクション3.2[MSG]の制限は適用されます。 S/MIME EIT値はさらに保護された内容の構成に資格を与える意図する他のEIT値に共存するかもしれません。
Hoffman & Bonatti Standards Track [Page 6] RFC 3855 Transporting S/MIME Objects in X.400 July 2004
2004年7月にX.400でS/MIMEオブジェクトを輸送するホフマンとBonatti標準化過程[6ページ]RFC3855
2.5.1. Enveloped Data
2.5.1. おおわれたデータ
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は、[MSG]に従ってX.400の満足している分野が保護されたCMSによっておおわれたデータcontent typeであるMIMEの種類を含むのを示します。 セクション2.2に従って、結果として起こるおおわれたデータCMS内容は伝えられます。 この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) }
イド-eit-envelopedDataオブジェクト識別子:、:= iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-eit(10)イド-eit-envelopedData(1)
2.5.2. Signed Data
2.5.2. データであると署名されます。
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署名しているデータcontent typeによって保護されたMIMEの種類を含むのを示します。 セクション2.2によると、データCMS内容であると署名される結果になることは運ばれます。 この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) }
イド-eit-signedDataオブジェクト識別子:、:= iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-eit(10)イド-eit-signedData(2)
2.5.3. Certs Only
2.5.3. 本命専用
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:
本命だけメッセージは、登録要求に対応したなど証明書、そして/または、CRLsを輸送するのに使用されます。 これは[CERT31]で説明されます。 本命だけメッセージは署名しているデータでタイプのCMS内容のただ一つのインスタンスから成ります。 encapContentInfo eContent分野は欠けるに違いありません、そして、signerInfos分野は人影がないに違いありません。 セクション2.2に従って、結果として起こる本命だけCMS内容は伝えられます。 この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) }
イド-eit-certsOnlyオブジェクト識別子:、:= iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-eit(10)イド-eit-certsOnly(3)
2.5.4. Signed Receipt
2.5.4. 領収書であると署名されます。
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]に従ってCMS署名しているデータcontent typeによって保護されたReceipt内容を含むのを示します。 セクション2.2に従って、結果として起こるCMS署名しているデータ内容は伝えられます。 このEITは以下のOID値によって示されるべきです:
Hoffman & Bonatti Standards Track [Page 7] RFC 3855 Transporting S/MIME Objects in X.400 July 2004
2004年7月にX.400でS/MIMEオブジェクトを輸送するホフマンとBonatti標準化過程[7ページ]RFC3855
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) }
イド-eit-signedReceiptオブジェクト識別子:、:= iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-eit(10)イド-eit-signedReceipt(4)
2.5.5. Enveloped X.400
2.5.5. おおわれたX.400
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は、[X400WRAP]に従ってX.400の満足している分野が保護されたCMSによっておおわれたデータcontent typeであるX.400内容を含むのを示します。 セクション2.2に従って、結果として起こるおおわれたX.400 CMS内容は伝えられます。 この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) }
イド-eit-envelopedX400オブジェクト識別子:、:= iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-eit(10)イド-eit-envelopedX400(5)
2.5.6. Signed X.400
2.5.6. X.400であると署名されます。
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署名しているデータcontent typeによって保護されたX.400内容を含むのを示します。 セクション2.2によると、X.400 CMS内容であると署名される結果になることは運ばれます。 この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) }
イド-eit-signedX400オブジェクト識別子:、:= iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-eit(10)イド-eit-signedX400(6)
2.5.7. Compressed Data
2.5.7. 圧縮されたデータ
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の満足している分野がaを含むのを示します。[COMPRESS]に従って圧縮されたデータcontent typeによって圧縮された別のタイプ。 セクション2.2に従って、結果として起こるCMS内容は伝えられます。 この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) }
イド-eit-compressedDataオブジェクト識別子:、:= iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-eit(10)イド-eit-compressedData(7)
2.6. Interaction with X.400 Elements of Service
2.6. サービスのX.400Elementsとの相互作用
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サービスについて選択で払われるべきです。 内容の変換、Distribution Lists(DLs)の拡張、およびメッセージリダイレクションに影響するサービスはひどく"EnvelopedData"と"SignedData"CMS content typeによって提供されたサービスと対話できます。
Hoffman & Bonatti Standards Track [Page 8] RFC 3855 Transporting S/MIME Objects in X.400 July 2004
2004年7月にX.400でS/MIMEオブジェクトを輸送するホフマンとBonatti標準化過程[8ページ]RFC3855
2.6.1. MTS Conversion Services
2.6.1. MTS変換サービス
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.
そのような変換がCMS保護メカニズムと両立しないので、MTS変換はこのドキュメントのシナリオに適切ではありません。そういったタイプの人がX.420構造規則に従わないので、一般に、変換がサービスであると実装するX.400システムはCMS content typeの変換を試みるはずであることができません。 それにもかかわらず、X.400環境の中でCMSオブジェクトを輸送するときのConversion ProhibitionはSHOULDを調整します。選択されます。
2.6.2. Message Redirection Services
2.6.2. メッセージリダイレクションサービス
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"content typeのアプリケーションに間接的な影響力を持つことができます。 リダイレクションのいくつかの異なったフォームが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"content typeがメッセージ内容を保護するのに使用されるとき、RecipientInfoのインスタンスが、メッセージへの必要なアクセスを確実にするのにそれぞれの受取人と代替の受取人に必要です。 ただMTSが全体のメッセージを返すといけないので、創始者のためのRecipientInfoは良い習慣です。
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が使用されている場合、創始者は代替の受取人のアイデンティティを意識しています、そして、SHOULDは対応するRecipientInfo要素を含んでいます。 他の形式のリダイレクション、(包含、非セキュリティ意識する、自動推進) 代替の受取人は、意図している受取人のキー(推薦されない)に近づく手段を持たなければならないか、または他の手段で意図している受取人にメッセージをリレーしなければなりません。
2.6.3. DL Expansion
2.6.3. dl拡張
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
X.400 DLsはCMS"EnvelopedData"content typeのアプリケーションに間接的な影響力を持つことができます。 いつまで"EnvelopedData"content typeはメッセージ内容を保護するのに使用されて、RecipientInfoのインスタンスが、必要なアクセスを確実にするのに各受取人に必要ですか。
Hoffman & Bonatti Standards Track [Page 9] RFC 3855 Transporting S/MIME Objects in X.400 July 2004
2004年7月にX.400でS/MIMEオブジェクトを輸送するホフマンとBonatti標準化過程[9ページ]RFC3855
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.
メッセージ。 DLへのメッセージはDLに関連している独身のRecipientInfoだけを通常含んでいるでしょう。 [ESS]で説明されたメールLists(MLs)と異なって、しかしながら、X.400 DLsは一般に、セキュリティ意識していなくて、またDLメンバーのためにRecipientInfo要素を作り直しません。 [ESS]に従うセキュリティ意識しているMLがX.400 DLsに優先して使用されるのは、お勧めです。 輸送するとき、CMSはX.400環境、DL Expansion ProhibitedサービスSHOULDの中で反対します。選択されます。
3. Security Considerations
3. セキュリティ問題
This specification introduces no new security concerns to the CMS or S/MIME models. Security issues are identified in section 5 of [MSG], section 6 of [ESS] and the Security Considerations section of [CMS].
この仕様はCMSかS/MIMEモデルにどんな新しい安全上の配慮も取り入れません。 安全保障問題は[MSG]のセクション5、[ESS]のセクション6、および[CMS]のSecurity Considerations部で特定されます。
4. References
4. 参照
4.1. Normative References
4.1. 引用規格
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MUSTSHOULD] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[CERT31] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Certificate Handling",
RFC 3850, July 2004.
[CERT31] Ramsdell、B.、エド「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1証明書は扱う」RFC3850、2004年7月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[cm] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。
[COMPRESS] Gutmann, P., "Compressed Data Content Type for
Cryptographic Message Syntax (CMS)", RFC 3274, June
2002.
[圧縮します] ガットマン、P.、「暗号のメッセージ構文(cm)のための圧縮されたデータcontent type」、RFC3274、2002年6月。
[ESS] Hoffman, P., Ed., "Enhanced Security Services for
S/MIME", RFC 2634, June 1999.
[ESS]ホフマン、P.、エド、「S/MIMEのための警備の強化サービス」、RFC2634、6月1999日
[MSG] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[MSG] Ramsdell、B.、エド、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1は仕様を通信する」RFC3851、7月2004日
[X.400] ITU-T X.400 Series of Recommendations, Information
technology - Message Handling Systems (MHS). X.400:
System and Service Overview; X.402: Overall
Architecture; X.411: Message Transfer System: Abstract
Service Definition and Procedures; X.420: Interpersonal
Messaging System; 1996.
Recommendationsの[X.400]ITU-T X.400 Series、情報技術--メッセージHandling Systems(MHS)。 X.400: システムとサービス概要。 X.402: 総合的なアーキテクチャ。 X.411: メッセージ転送システム: 抽象的なサービス定義と手順。 X.420: 個人間のメッセージシステム。 1996.
Hoffman & Bonatti Standards Track [Page 10] RFC 3855 Transporting S/MIME Objects in X.400 July 2004
2004年7月にX.400でS/MIMEオブジェクトを輸送するホフマンとBonatti標準化過程[10ページ]RFC3855
4.2. Informative References
4.2. 有益な参照
[BODYMAP] Alvestrand, H., "Mapping between X.400 and RFC-822/MIME
Message Bodies", RFC 2157, January 1998.
H. [BODYMAP]Alvestrand、1998年1月、「X.400とRFC-822/MIMEメッセージの間でボディーを写像すること」でのRFC2157。
[MIXER] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
Mapping between X.400 and RFC 822/MIME", RFC 2156,
January 1998.
[ミキサー]Kille、S.、「ミキサー(パントマイムインターネットX.400はリレーを機能アップしました):」 「X.400とRFC822/の間でMIMEを写像します」、RFC2156、1998年1月。
[X400WRAP] Hoffman, P., Bonatti, C., and A. Eggen, "Securing X.400
Content with Secure/Multipurpose Internet Mail
Extensions (S/MIME), RFC 3854, July 2004.
「2004年7月に安全な/マルチパーパスインターネットメールエクステンション(S/MIME)、RFC3854と共にX.400が内容であると機密保護する」[X400WRAP]ホフマン、P.、Bonatti、C.、およびA.Eggen。
5. Authors' Addresses
5. 作者のアドレス
Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 USA
ポールホフマンインターネットメール共同体127セグレ・Placeカリフォルニア95060サンタクルス(米国)
EMail: phoffman@imc.org
メール: phoffman@imc.org
Chris Bonatti IECA, Inc. 15309 Turkey Foot Road Darnestown, MD 20878-3640 USA
フット・ロードDarnestown、クリスBonatti IECA Inc.15309トルコMD20878-3640米国
EMail: bonattic@ieca.com
メール: bonattic@ieca.com
Hoffman & Bonatti Standards Track [Page 11] RFC 3855 Transporting S/MIME Objects in X.400 July 2004
2004年7月にX.400でS/MIMEオブジェクトを輸送するホフマンとBonatti標準化過程[11ページ]RFC3855
6. Full Copyright Statement
6. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Hoffman & Bonatti Standards Track [Page 12]
ホフマンとBonatti標準化過程[12ページ]
一覧
スポンサーリンク
