Network Working Group T. Dean
Request for Comments: 3183 W. Ottaway
Category: Experimental QinetiQ
October 2001
Domain Security Services using S/MIME
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document describes how the S/MIME (Secure/Multipurpose Internet Mail Extensions) protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'.
この文書では、S / MIME（/多目的インターネットメール拡張セキュア）プロトコルを処理し、セキュリティサービスを提供するためにそのようなメッセージ転送エージェント、ガードやゲートウェイなどの通信システムの構成要素の数で生成することができる方法について説明します。これらのサービスを総称して「ドメインセキュリティサービス」と呼ばれています。
Acknowledgements
謝辞
Significant comments were made by Luis Barriga, Greg Colla, Trevor Freeman, Russ Housley, Dave Kemp, Jim Schaad and Michael Zolotarev.
重要なコメントはルイスBarriga、グレッグ・コラ、トレバー・フリーマン、ラスHousley、デイブ・ケンプ、ジムSchaadとマイケルZolotarevによって作られました。
The S/MIME [1] series of standards define a data encapsulation format for the provision of a number of security services including data integrity, confidentiality, and authentication. S/MIME is designed for use by messaging clients to deliver security services to distributed messaging applications.
標準のS / MIME [1]シリーズは、データの整合性、機密性、および認証を含むセキュリティ・サービスの数を提供するためのデータのカプセル化形式を定義します。 S / MIMEは、分散メッセージングアプリケーションにセキュリティサービスを提供するメッセージングクライアントが使用するために設計されています。
The mechanisms described in this document are designed to solve a number of interoperability problems and technical limitations that arise when different security domains wish to communicate securely, for example when two domains use incompatible messaging technologies such as the X.400 series and SMTP/MIME, or when a single domain wishes to communicate securely with one of its members residing on an untrusted domain. The scenarios covered by this document are domain-to-domain, individual-to-domain and domain-to-individual communications. This document is also applicable to organizations and enterprises that have internal PKIs which are not accessible by the outside world, but wish to interoperate securely using the S/MIME protocol.
本書で説明されたメカニズムは、相互運用性の問題とは異なるセキュリティドメインは、2つのドメインは、X.400シリーズ、SMTP / MIMEなどの互換性のないメッセージングテクノロジを使用する場合、例えば、安全に通信することを望む場合に生じる技術的な制限の数を解決するように設計されています場合や、単一のドメインが信頼されていないドメイン上に存在するそのメンバーのいずれかと安全に通信することを望みます。この文書でカバーシナリオはドメイン間、個々のツードメインおよびドメイン・ツー・個別通信をしています。この文書はまた、外の世界からはアクセスできません内部のPKIを持っていますが、S / MIMEプロトコルを使用して安全に相互運用したい組織や企業に適用されます。
There are many circumstances when it is not desirable or practical to provide end-to-end (desktop-to-desktop) security services, particularly between different security domains. An organization that is considering providing end-to-end security services will typically have to deal with some if not all of the following issues:
特に、異なるセキュリティドメイン間で、エンドツーエンド（デスクトップ・ツー・デスクトップ）セキュリティサービスを提供することが望ましいか、実用的でない場合、多くの状況があります。エンドツーエンドのセキュリティサービスを提供して検討している組織は、典型的には、いくつかの場合ではない次の問題のすべてに対処する必要があります。
1) Heterogeneous message access methods: Users are accessing mail using mechanisms which re-format messages, such as using Web browsers. Message reformatting in the Message Store makes end-to-end encryption and signature validation impossible.
1）異種メッセージのアクセス方法：ユーザーは、Webブラウザを使用するなど、メッセージフォーマットに再メカニズムを使用してメールにアクセスしています。メッセージストアに再フォーマットのメッセージは、エンドツーエンドの暗号化と署名の検証が不可能になります。
2) Message screening and audit: Server-based mechanisms such as searching for prohibited words or other content, virus scanning, and audit, are incompatible with end-to-end encryption.
2）メッセージスクリーニングおよび監査：そのような禁止された単語またはその他のコンテンツ、ウイルススキャン、および監査の検索などのサーバーベースのメカニズムは、エンド・ツー・エンドの暗号化と互換性がありません。
3) PKI deployment issues: There may not be any certificate paths between two organizations. Or an organization may be sensitive about aspects of its PKI and unwilling to expose them to outside access. Also, full PKI deployment for all employees, may be expensive, not necessary or impractical for large organizations. For any of these reasons, direct end-to-end signature validation and encryption are impossible.
3）PKI展開に関する問題：2つの組織間の任意の証明書パスがない可能性があります。または組織は、そのPKIの側面に関する機密や外部からのアクセスにそれらを公開したがらないかもしれません。また、全従業員のための完全なPKIの展開は、大規模な組織のために必要であるか、または非現実的で、高価ではないかもしれません。これらのいずれかの理由で、直接エンド・ツー・エンドの署名検証と暗号化は不可能です。
4) Heterogeneous message formats: One organization using X.400 series protocols wishes to communicate with another using SMTP. Message reformatting at gateways makes end-to-end encryption and signature validation impossible.
4）異種メッセージフォーマットX.400シリーズのプロトコルを使用して一つの組織は、別の使用SMTPと通信することを望みます。ゲートウェイで再フォーマットのメッセージは、エンドツーエンドの暗号化と署名の検証が不可能になります。
This document describes an approach to solving these problems by providing message security services at the level of a domain or an organization. This document specifies how these 'domain security services' can be provided using the S/MIME protocol. Domain security services may replace or complement mechanisms at the desktop. For example, a domain may decide to provide desktop-to-desktop signatures but domain-to-domain encryption services. Or it may allow desktop-to-desktop services for intra-domain use, but enforce domain-based services for communication with other domains.
この文書では、ドメインまたは組織のレベルでのメッセージのセキュリティサービスを提供することにより、これらの問題を解決するためのアプローチを説明しています。この文書では、これらのドメインのセキュリティサービスは、 'S / MIMEプロトコルを使用して提供することができる方法を指定します。ドメインセキュリティサービスは、交換またはデスクトップでのメカニズムを補完することがあります。例えば、ドメインは、デスクトップからデスクトップへの署名が、ドメイン間の暗号化サービスを提供するように決定することができます。それとも、ドメイン内での使用のためのデスクトップからデスクトップへのサービスを許可しますが、他のドメインとの通信のために、ドメインベースのサービスを強制することがあります。
Domain services can also be used by individual members of a corporation who are geographically remote and who wish to exchange encrypted and/or signed messages with their base.
ドメインサービスは、地理的に離れており、誰がそのベースと、暗号化および/または署名されたメッセージを交換したい企業の個々のメンバーでも使用することができます。
Whether or not a domain based service is inherently better or worse than desktop based solutions is an open question. Some experts believe that only end-to-end solutions can be truly made secure, while others believe that the benefits offered by such things as content checking at domain boundaries offers considerable increase in practical security for many real systems. The additional service of allowing signature checking at several points on a communications path is also an extra benefit in many situations. This debate is outside the scope of this document. What is offered here is a set of tools that integrators can tailor in different ways to meet different needs in different circumstances.
ドメインベースのサービスは、デスクトップベースのソリューションよりも本質的に良いか悪いかであるかどうかは未解決の問題です。他の人がドメイン境界でチェックするコンテンツのようなものによって提供される利点は、多くの実際のシステムのための実用的なセキュリティの大幅な増加を提供すると信じていながら、一部の専門家は、唯一のエンド・ツー・エンドのソリューションは、本当に確実なものとすることができると信じています。通信経路上の複数の点で検査署名を可能にする付加的なサービスは、多くの状況では、余分な利点です。この議論は、この文書の範囲外です。何ここで提供されていることインテグレータが異なる状況では異なるニーズを満たすためにさまざまな方法でカスタマイズできるツールのセットです。
Message transfer agents (MTAs), guards, firewalls and protocol translation gateways all provide domain security services. As with desktop based solutions, these components must be resilient against a wide variety of attacks intended to subvert the security services. Therefore, careful consideration should be given to security of these components, to make sure that their siting and configuration minimises the possibility of attack.
メッセージ転送エージェント（MTA）、警備員、ファイアウォールやプロトコル変換ゲートウェイは、すべてのドメインのセキュリティサービスを提供しています。デスクトップベースのソリューションと同様に、これらのコンポーネントは、セキュリティサービスを覆すことを意図した攻撃の多種多様性に対する弾力性でなければなりません。そのため、慎重な検討は、その立地や構成が攻撃の可能性を最小限に抑えることを確認するために、これらのコンポーネントのセキュリティに与えられるべきです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[2]で説明されるように解釈されます。
This section gives an informal overview of the security services that are provided by S/MIME between different security domains. These services are provided by a combination of mechanisms in the sender's and recipient's domains.
このセクションでは、異なるセキュリティドメイン間でS / MIMEによって提供されているセキュリティ・サービスの非公式の概要を説明します。これらのサービスは、送信者と受信者のドメインのメカニズムの組み合わせによって提供されています。
Later sections describe definitively how these services map onto elements of the S/MIME protocol.
その後のセクションでは、これらのサービスは、S / MIMEプロトコルの要素にマップ決定的方法について説明します。
The following security mechanisms are specified in this document:
次のセキュリティメカニズムは、この文書で指定されています。
1. Domain signature 2. Review signature 3. Additional attributes signature 4. Domain encryption and decryption
1.ドメイン署名2.レビューの署名3.追加の属性署名4.ドメインの暗号化と復号化
The signature types defined in this document are referred to as DOMSEC defined signatures.
この文書で定義された署名タイプがDOMSEC定義シグネチャと呼ばれます。
The term 'security domain' as used in this document is defined as a collection of hardware and personnel operating under a single security authority and performing a common business function. Members of a security domain will of necessity share a high degree of mutual trust, due to their shared aims and objectives.
この文書で使用される用語「セキュリティドメインは、」ハードウェアおよび単一のセキュリティ権限の下で動作し、一般的なビジネス機能を実行する人材の集合体として定義されます。その共有の目標と目的のために必要シェアのセキュリティドメインの意志のメンバー相互の信頼度の高いです、。
A security domain is typically protected from direct outside attack by physical measures and from indirect (electronic) attack by a combination of firewalls and guards at network boundaries. The interface between two security domains is termed a 'security boundary'. One example of a security domain is an organizational network ('Intranet').
セキュリティドメインは、一般的に物理的手段により、ネットワークの境界でファイアウォールや警備員の組み合わせによって間接的（電子的）攻撃からの直接外の攻撃から保護されています。 2つのセキュリティドメイン間の界面は、「セキュリティの境界」と呼ばれています。セキュリティドメインの一例は、組織のネットワーク（「イントラネット」）です。
A domain signature is an S/MIME signature generated on behalf of a set of users in a domain. A domain signature can be used to authenticate information sent between domains or between a certain domain and one of its individuals, for example, when two 'Intranets' are connected using the Internet, or when an Intranet is connected to a remote user over the Internet. It can be used when two domains employ incompatible signature schemes internally or when there are no certification links between their PKIs. In both cases messages from the originator's domain are signed over the original message and signature (if present) using an algorithm, key, and certificate which can be processed by the recipient(s) or the recipient(s) domain. A domain signature is sometimes referred to as an "organizational signature".
ドメイン署名は、ドメイン内のユーザーのセットの代わりに生成されたS / MIME署名です。 2つの「イントラネット」はインターネットを使用して接続されている場合、またはイントラネット、インターネットを介してリモートユーザに接続されている場合、ドメイン署名は、例えば、ドメイン間、または特定のドメインとその個体の間で送信される情報を認証するために使用することができます。自分のPKIの間には認定のリンクが存在しないときに、2つのドメインが内部的に互換性のない署名方式を採用する場合、またはそれを使用することができます。両方の場合において、発信者のドメインからのメッセージは、受信者または受信者のドメインで処理することができ、元のメッセージと署名（存在する場合）アルゴリズム、鍵を使用して、証明書の上に署名されています。ドメイン署名は時々「組織署名」と呼ばれます。
A third party may review messages before they are forwarded to the final recipient(s) who may be in the same or a different security domain. Organizational policy and good security practice often require that messages be reviewed before they are released to external recipients. Having reviewed a message, an S/MIME signature is added to it - a review signature. An agent could check the review signature at the domain boundary, to ensure that only reviewed messages are released.
これらは、同一または異なるセキュリティドメインであってもよく、最終的な受信者に転送される前に第三者がメッセージを検討することができます。組織のポリシーと優れたセキュリティプラクティスは、多くの場合、彼らは外部の受信者にリリースされる前に、メッセージが見直されている必要があります。レビューの署名 - メッセージ、S / MIME署名がそれに追加さを検討しました。エージェントは、唯一の見直しメッセージが解放されることを保証するために、ドメイン境界でレビュー署名をチェックすることができます。
A third party can add additional attributes to a signed message. An S/MIME signature is used for this purpose - an additional attributes signature. An example of an additional attribute is the 'Equivalent Label' attribute defined in ESS [3].
第三者が署名されたメッセージに属性を追加することができます。追加属性の署名 - S / MIME署名は、この目的のために使用されています。追加の属性の例は、ESS [3]で定義された「等価ラベル」属性です。
Domain encryption is S/MIME encryption performed on behalf of a collection of users in a domain. Domain encryption can be used to protect information between domains, for example, when two 'Intranets' are connected using the Internet. It can also be used when end users do not have PKI/encryption capabilities at the desktop, or when two domains employ incompatible encryption schemes internally. In the latter case messages from the originator's domain are encrypted (or re-encrypted) using an algorithm, key, and certificate which can be decrypted by the recipient(s) or an entity in their domain. This scheme also applies to protecting information between a single domain and one of its members when both are connected using an untrusted network, e.g., the Internet.
ドメインの暗号化は、ドメイン内のユーザーのコレクションに代わって行ってS / MIME暗号化です。ドメインの暗号化には、2つの「イントラネット」がインターネットを使用して接続されている場合、例えば、ドメイン間で情報を保護するために使用することができます。エンドユーザーがデスクトップでPKI /暗号化機能を持っていない場合にも使用することができ、または2つのドメインが内部的に互換性のない暗号化方式を採用したとき。後者の場合、発信者のドメインからのメッセージは、受信者（複数可）またはそれらのドメイン内のエンティティによって復号することができるアルゴリズム、鍵、及び証明書を使用して暗号化された（または再暗号化）。この方式は、単一のドメインとの両方が信頼できないネットワーク、例えば、インターネットを使用して接続され、そのメンバーのうちの1つとの間の情報の保護に適用されます。
This section describes the S/MIME protocol elements that are used to provide the security services described above. ESS [3] introduces the concept of triple-wrapped messages that are first signed, then encrypted, then signed again. This document also uses this concept of triple-wrapping. In addition, this document also uses the concept of 'signature encapsulation'. 'Signature encapsulation' denotes a signed or unsigned message that is wrapped in a signature, this signature covering both the content and the first (inner) signature, if present.
このセクションでは、上述したセキュリティサービスを提供するために使用されるS / MIMEプロトコル要素を記載しています。 ESSは、[3]第1の暗号化、その後、署名されているトリプル包まれたメッセージの概念を導入し、再度署名しました。また、このドキュメントでは、トリプルラッピングのこの概念を使用しています。また、この文書はまた、「署名のカプセル化」の概念を使用しています。存在する場合に「署名カプセル化」、署名に包まれている符号付きまたは符号なしのメッセージ、コンテンツと最初の（内側の）署名の両方をカバーするこの署名を表します。
Signature encapsulation MAY be performed on the inner and/or the outer signature of a triple-wrapped message.
署名のカプセル化は、内側および/または三重ラップメッセージの外側の署名を行ってもよいです。
For example, the originator signs a message which is then encapsulated with an 'additional attributes' signature. This is then encrypted. A reviewer then signs this encrypted data, which is then encapsulated by a domain signature.
例えば、発信者は、次いで、「追加属性」署名でカプセル化されたメッセージに署名します。これは、その後、暗号化されています。レビューは、次いで、ドメイン署名によってカプセル化され、この暗号化されたデータを、署名します。
There is a possibility that some policies will require signatures to be added in a specific order. By only allowing signatures to be added by encapsulation it is possible to determine the order in which the signatures have been added.
いくつかのポリシーは、特定の順序で追加される署名を必要とする可能性があります。唯一の署名がカプセル化によって追加されることを可能にすることによって、署名が追加された順序を決定することが可能です。
A DOMSEC defined signature MAY encapsulate a message in one of the following ways:
DOMSEC定義されたシグネチャは、次のいずれかの方法でメッセージをカプセル化することができます。
1) An unsigned message has an empty signature layer added to it (i.e., the message is wrapped in a signedData that has a signerInfos which contains no elements). This is to enable backward compatibility with S/MIME software that does not have a DOMSEC capability. Since the signerInfos will contain no signers the eContentType, within the EncapsulatedContentInfo, MUST be id-data as described in CMS [5]. However, the eContent field will contain the unsigned message instead of being left empty as suggested in section 5.2 in CMS [5]. This is so that when the DOMSEC defined signature is added, as defined in method 2) below, the signature will cover the unsigned message.
1）未署名のメッセージは、（すなわち、メッセージ）要素が含まれていないsignerInfosを有したsignedDataに包まれているに加え、空の署名層を有します。これはDOMSEC機能を持っていないS / MIMEソフトウェアとの下位互換性を有効にすることです。 signerInfos無署名者のeContentTypeを含まないのでCMSに記載されているように、EncapsulatedContentInfo内、[5]のIDデータでなければなりません。しかし、e-コンテンツフィールドは符号なしのメッセージを含むことになる代わりにCMS [5]のセクション5.2で提案されているように空のままにされます。 DOMSEC定義された署名が追加された場合、方法で定義され2）以下、署名が未署名のメッセージをカバーするようにするためです。
2) Signature Encapsulation is used to wrap the original signed message with a DOMSEC defined signature. This is so that the DOMSEC defined signature covers the message and all the previously added signatures. Also, it is possible to determine that the DOMSEC defined signature was added after the signatures that are already there.
2）署名封入はDOMSEC定義された署名付きオリジナルの署名されたメッセージをラップするために使用されます。 DOMSEC定義された署名は、メッセージおよびすべての以前に追加された署名を覆うようにするためです。また、DOMSEC定義された署名が既に存在する署名後に追加されたと判断することができます。
An entity receiving an S/MIME signed message would normally expect the signature to be that of the originator of the message. However, the message security services defined in this document require the recipient to be able to accept messages signed by other entities and/or the originator. When other entities sign the message the name in the certificate will not match the message sender's name. An S/MIME compliant implementation would normally flag a warning if there were a mismatch between the name in the certificate and the message sender's name. (This check prevents a number of types of masquerade attack.)
S / MIME署名されたメッセージを受信するエンティティは、通常、署名は、メッセージの発信者のものであることが期待されます。しかし、この文書で定義されたメッセージのセキュリティサービスは、他のエンティティおよび/または発信者によって署名されたメッセージを受け入れることができるように、受信者が必要です。他のエンティティは、メッセージに署名するときに証明書の名前は、メッセージの送信者の名前と一致しません。 S / MIME準拠した実装では、証明書の名前とメッセージの送信者名の間に不一致があった場合に警告をフラグ正常でしょう。 （このチェックはマスカレード攻撃の種類の数を防ぐことができます。）
In the case of domain security services, this warning condition SHOULD be suppressed under certain circumstances. These circumstances are defined by a naming convention that specifies the form that the signers name SHOULD adhere to. Adherence to this naming convention avoids the problems of uncontrolled naming and the possible masquerade attacks that this would produce.
ドメインセキュリティサービスの場合には、この警告条件は、特定の状況下では抑制されるべきです。これらの状況は、署名者の名前がに従う必要があるフォームを指定する命名規則によって定義されています。この命名規則の遵守は、これが生じるであろうことを制御できない命名の問題と可能ななりすまし攻撃を回避することができます。
As an assistance to implementation, a signed attribute is defined to be included in the S/MIME signature - the 'signature type' attribute. On receiving a message containing this attribute, the naming convention checks are invoked.
「署名タイプ」属性 - インプリメンテーションへの支援として、署名された属性は、S / MIME署名に含まれるように定義されます。この属性を含むメッセージを受信すると、命名規則のチェックが呼び出されます。
Implementations conforming to this standard MUST support the naming convention for signature generation and verification. Implementations conforming to this standard MUST recognize the signature type attribute for signature verification. Implementations conforming to this standard MUST support the signature type attribute for signature generation.
この規格に準拠した実装では、署名生成と検証のための命名規則をサポートしなければなりません。この規格に準拠した実装が署名検証のための署名タイプ属性を認識しなければなりません。この規格に準拠した実装が署名生成のための署名タイプ属性をサポートしなければなりません。
The following naming conventions are specified for agents generating signatures specified in this document:
以下の命名規則は、この文書で指定された署名を生成する物質に指定されています。
* For a domain signature, an agent generating this signature MUST be named 'domain-signing-authority'
*ドメインの署名については、この署名を生成するエージェントは、「ドメイン署名-権威」という名前にする必要があります
* For a review signature, an agent generating this signature MUST be named 'review-authority'.
*レビューの署名については、この署名を生成する物質は、「レビュー・権限」という名前でなければなりません。
* For an additional attributes signature, an agent generating this signature MUST be named 'attribute-authority'.
*追加属性の署名については、この署名を生成する物質は、「属性の権限」という名前でなければなりません。
This name shall appear as the 'common name (CN)' component of the subject field in the X.509 certificate. There MUST be only one CN component present. Additionally, if the certificate contains an RFC 822 address, this name shall appear in the end entity component of the address - on the left-hand side of the '@' symbol.
この名前は、X.509証明書のサブジェクトフィールドの「共通名（CN）」成分として表示されなければなりません。一つだけのCN構成要素の存在があるに違いありません。 「@」記号の左側にある - 証明書がRFC 822アドレスが含まれている場合はさらに、この名前は、アドレスのエンドエンティティコンポーネントに出頭しなければなりません。
In the case of a domain signature, an additional naming rule is defined: the 'name mapping rule'. The name mapping rule states that for a domain signing authority, the domain part of its name MUST be the same as, or an ascendant of, the domain name of the message originator(s) that it is representing. The domain part is defined as follows:
ドメイン署名の場合には、追加の命名規則が定義される：「名前マッピング規則を」。名前マッピング規則は、ドメイン署名認証のために、その名前のドメイン部分と同じ、またはそれが表現されていることをメッセージ発信元（S）のドメイン名の昇順である必要があること。次のようにドメイン部分が定義されています。
* In the case of an X.500 distinguished subject name of an X.509 certificate, the domain part is the country, organization, organizational unit, state, and locality components of the distinguished name.
* X.509証明書のX.500識別サブジェクト名の場合は、ドメイン部分は、国、組織、組織単位、状態、および識別名の局所性コンポーネントです。
* In the case of an RFC 2247 distinguished name, the domain part is the domain components of the distinguished name.
* RFC 2247識別名の場合には、ドメイン部分は、識別名のドメインコンポーネントです。
* If the certificate contains an RFC 822 address, the domain part is defined to be the RFC 822 address component on the right-hand side of the '@' symbol.
証明書は、RFC 822のアドレスが含まれている場合*、ドメイン部が「@」記号の右側のRFC 822アドレス成分であると定義されます。
For example, a domain signing authority acting on behalf of John Doe of the Acme corporation, whose distinguished name is 'cn=John Doe, ou=marketing,o=acme,c=us' and whose e-mail address is John.Doe@marketing.acme.com, could have a certificate containing a distinguished name of 'cn=domain-signing-authority,o=acme,c=us' and an RFC 822 address of 'domain-signing-authority@acme.com'. If John Doe has an RFC 2247
例えば、識別名ですアクメ社のジョン・ドウの代わりに行動するドメイン署名権限とその電子メールアドレスのJohn.Doeである「CN =ジョン・ドウは、= ACME、C =私たちにO、=マーケティングをOU」 @ marketing.acme.com、「= ACME、C = O、私たちCN =ドメイン署名-権威」の識別名と「domain-signing-authority@acme.com」のRFC 822アドレスを含む証明書を持つことができます。ジョン・ドウは、RFC 2247を持っている場合
defined address of 'cn=John Doe,dc=marketing,dc=acme,dc=us' then an address of 'cn=domain-signing-authority,dc=acme,dc=us' could be used to represent the domain signing authority.
アドレス定義され、その後のアドレス「CN =ジョン・ドウ、DC =マーケティング、DCはアクメを=、DCたちを=」「CN =ドメイン署名-権限を、DCはアクメを=、DCたちを=」ドメインの署名を表すために使用することができ権限。
When the X.500 distinguished subject name has consecutive organizational units and/or localities it is important to understand the ordering of these values in order to determine if the domain part of the domain signature is an ascendant. In this case, when parsing the distinguished subject name from the most significant component (i.e., country, locality or organization) the parsed organizational unit or locality is deemed to be the ascendant of consecutive (unparsed) organizational units or localities.
X.500識別サブジェクト名は、連続した組織単位および/または地域を持っている場合には、ドメインの署名のドメイン部分が優勢であるかどうかを判断するために、これらの値の順序を理解することが重要です。最も重要な成分（すなわち、国、地域、または組織）から識別対象名を解析する際、この場合には、解析された組織単位または地域は、連続（未解析）、組織単位または地域の先祖であるとみなされます。
When parsing an RFC 2247 subject name from the most significant component (i.e., the 'dc' entry that represents the country, locality or organization) the parsed 'dc' entry is deemed to be the ascendant of consecutive (unparsed) 'dc' entries.
最も重要な構成要素からRFC 2247サブジェクト名を解析するとき（すなわち、国、地域や組織を表す「DC」エントリ）解析された「DC」エントリは、連続した（解析対象外）「直流」エントリの優勢であると思われます。
For example, a domain signing authority acting on behalf of John Doe of the Acme corporation, whose distinguished name is 'cn=John Doe, ou=marketing,ou=defence,o=acme,c=us' and whose e-mail address is John.Doe@marketing.defence.acme.com, could have a certificate containing a distinguished name of 'cn=domain-signing-authority,ou=defence,o=acme,c=us' and an RFC 822 address of 'domain-signing-authority@defence.acme.com'. If John Doe has an RFC 2247 defined address of 'cn=John Doe,dc=marketing,dc=defense,dc=acme,dc=us' then the domain signing authority could have a distinguished name of 'cn=domain-signing-authority,dc=defence,dc=acme,dc=us'.
たとえば、識別名ですアクメ社のジョン・ドウ、のために行動する、ドメイン署名機関「CN =ジョン・ドウ、OU =マーケティング、OU =防衛、O = ACME、C = US」とその電子メールアドレスJohn.Doe@marketing.defence.acme.comは、 '= ACME、C = US oをCN =ドメイン署名-権威、OU =防衛' の識別名を含む証明書と 'のRFC 822アドレスを持つことができますdomain-signing-authority@defence.acme.com」。ジョン・ドウは、「CN =ジョン・ドウ、DC =マーケティング、DC =防衛、DC = ACME、DCが私たちを=」のRFC 2247定義されたアドレスを持っている場合は、ドメインの署名権限は「CN =ドメインsigning-の識別名を持つことができます当局は、dcは=防衛は、DC = ACMEは、DCは、私たち=。
Any message received where the domain part of the domain signing agent's name does not match, or is not an ascendant of, the originator's domain name MUST be flagged.
任意のメッセージは、ドメインの署名エージェントの名のドメイン部分が一致しない場合受信、または発信者のドメイン名がフラグを立てなければならない、の優勢ではありません。
This naming rule prevents agents from one organization masquerading as domain signing authorities on behalf of another. For the other types of signature defined in this document, no such named mapping rule is defined.
この命名規則は、ある組織が別のドメインに代わって署名当局になりすましてからエージェントを防ぐことができます。この文書で定義された署名の他のタイプのために、そのような名前のマッピング規則が定義されていません。
Implementations conforming to this standard MUST support this name mapping convention as a minimum. Implementations MAY choose to supplement this convention with other locally defined conventions. However, these MUST be agreed between sender and recipient domains prior to secure exchange of messages.
この規格に準拠した実装は、最低でもこの名前マッピング規則をサポートしなければなりません。実装は、他のローカルに定義された規則にこの条約を補足するために選ぶかもしれません。しかし、これらは、メッセージの交換を確保する前に、送信者と受信者のドメインの間で合意されなければなりません。
On verifying the signature, a receiving agent MUST ensure that the naming convention has been adhered to. Any message that violates the convention MUST be flagged.
署名を検証することで、受信エージェントは、命名規則に付着されていることを確認しなければなりません。規則に違反したメッセージにフラグを付けなければなりません。
An S/MIME signed attribute is used to indicate the type of signature. This should be used in conjunction with the naming conventions specified in the previous section. When an S/MIME signed message containing the signature type attribute is received it triggers the software to verify that the correct naming convention has been used.
S / MIME署名された属性は、署名の種類を示すために使用されます。これは、前のセクションで指定された命名規則と組み合わせて使用する必要があります。署名タイプ属性を含むS / MIME署名されたメッセージを受信したとき、正しい命名規則が使用されていることを確認するためのソフトウェアをトリガします。
The ASN.1 [4] notation of this attribute is: -
この属性のASN.1 [4]の表記であります： -
SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER
id-sti OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 9 }
-- signature type identifier
- 署名タイプ識別子
If present, the SignatureType attribute MUST be a signed attribute, as defined in [5]. If the SignatureType attribute is absent and there are no further encapsulated signatures the recipient SHOULD assume that the signature is that of the message originator.
存在する場合、SignatureType属性が[5]で定義されるように、署名された属性である必要があります。 SignatureType属性が存在しない、それ以上のカプセル化された署名が存在する場合、受信者は、署名は、メッセージ発信のであると仮定すべきです。
All of the signatures defined here are generated and processed as described in [5]. They are distinguished by the presence of the following values in the SignatureType signed attribute:
[5]記載のように、ここで定義されたシグネチャの全てが生成され、処理されます。彼らはSignatureType署名している属性に次の値の存在によって区別されています。
id-sti-domainSig OBJECT IDENTIFIER ::= { id-sti 2 }
-- domain signature.
id-sti-addAttribSig OBJECT IDENTIFIER ::= { id-sti 3 }
-- additional attributes signature.
id-sti-reviewSig OBJECT IDENTIFIER ::= { id-sti 4 }
-- review signature.
For completeness, an attribute type is also specified for an originator signature. However, this signature type is optional. It is defined as follows:
完全を期すため、属性タイプは、発信元の署名のために指定されています。しかし、この署名タイプはオプションです。これは次のように定義されます。
id-sti-originatorSig OBJECT IDENTIFIER ::= { id-sti 1 }
-- originator's signature.
All signature types, except the originator type, MUST encapsulate other signatures. Note a DOMSEC defined signature could be encapsulating an empty signature as defined in section 3.
すべての署名タイプは、発信元タイプを除いて、他の署名をカプセル化しなければなりません。セクション3で定義されるようDOMSEC定義シグネチャが空署名をカプセル化することができる留意されたいです。
A SignerInfo MUST NOT include multiple instances of SignatureType. A signed attribute representing a SignatureType MAY include multiple instances of different SignatureType values as an AttributeValue of attrValues [5], as long as the SignatureType 'additional attributes' is not present.
SignerInfoはSignatureTypeの複数のインスタンスを含んではいけません。 SignatureTypeを表す符号付き属性であればSignatureType「追加属性」が存在しないように、[5] attrValuesのAttributeValueのような異なるSignatureType値の複数のインスタンスを含むかもしれません。
If there is more than one SignerInfo in a signerInfos (i.e., when different algorithms are used) then the SignatureType attribute in all the SignerInfos MUST contain the same content.
signerInfosにおける複数のSignerInfoがある場合（異なるアルゴリズムが使用される場合、すなわち、）すべてSignerInfosでSignatureType属性は、同じ内容を含まなければなりません。
The following sections describe the conditions under which each of these types of signature may be generated, and how they are processed.
以下のセクションでは、署名のこれらのタイプの各々を生成することができる条件を説明し、それらがどのように処理されます。
A 'domain signature' is a proxy signature generated on a user's behalf in the user's domain. The signature MUST adhere to the naming conventions in 3.1.1, including the name mapping convention. A 'domain signature' on a message authenticates the fact that the message has been released from that domain. Before signing, a process generating a 'domain signature' MUST first satisfy itself of the authenticity of the message originator. This is achieved by one of two methods. Either the 'originator's signature' is checked, if S/MIME signatures are used inside a domain. Or if not, some mechanism external to S/MIME is used, such as the physical address of the originating client or an authenticated IP link.
「ドメインの署名は、」ユーザーのドメイン内のユーザーに代わって生成されたプロキシ署名です。署名は、名前のマッピング規則を含め、3.1.1で命名規則に準拠する必要があります。メッセージの「ドメインの署名は」メッセージがそのドメインから解放されたことを認証します。署名する前に、「ドメイン署名」を生成するプロセスは、最初のメッセージの発信者の真正性自体を満たさなければなりません。これは、2つの方法のいずれかによって達成されます。 S / MIME署名は、ドメイン内で使用されている場合はどちらの「発信者の署名が」、チェックされています。かない場合、S / MIMEの外部のいくつかのメカニズムは、このような元のクライアントの物理アドレスまたは認証されたIPリンクとして、使用されています。
If the originator's authenticity is successfully verified by one of the above methods and all other signatures present are valid, including those that have been encrypted, a 'domain signature' can be added to a message.
発信者の信憑性が正常に上記のいずれかの方法で確認され、存在するすべての他の署名が暗号化されたものを含め、有効なされている場合は、「ドメインの署名は、」メッセージに追加することができます。
If a 'domain signature' is added and the message is received by a Mail List Agent (MLA) there is a possibility that the 'domain signature' will be removed. To stop the 'domain signature' from being removed the steps in section 5 MUST be followed.
「ドメイン署名が」メールリストエージェント（MLA）によって追加され、メッセージが受信された場合のドメインシグネチャー 'は除去される可能性があります。停止するセクション5の手順に除去されるから「ドメインシグネチャー」は従わなければなりません。
An entity generating a domain signature MUST do so using a certificate containing a subject name that follows the naming convention specified in 3.1.1.
ドメインの署名を生成するエンティティは、3.1.1で指定された命名規則を次のサブジェクト名を含む証明書を使用して行う必要があります。
If the originator's authenticity is not successfully verified or all the signatures present are not valid, a 'domain signature' MUST NOT be generated.
発信者の信憑性は正常に検証されていないか、存在するすべての署名が有効でない場合は、「ドメイン署名」が生成されてはなりません。
On reception, the 'domain signature' SHOULD be used to verify the authenticity of a message. A check MUST be made to ensure that both the naming convention and the name mapping convention have been used as specified in this standard.
受信時に、「ドメインシグネチャー」はメッセージの信憑性を検証するために使用されるべきです。チェックは、この規格に指定されている命名規則と名前のマッピング規則の両方が使用されていることを確認するためになされなければなりません。
A recipient can assume that successful verification of the domain signature also authenticates the message originator.
受信者は、ドメイン署名の成功した検証は、メッセージ発信元を認証すると仮定することができます。
If there is an originator signature present, the name in that certificate SHOULD be used to identify the originator. This information can then be displayed to the recipient.
発信者の署名が存在する場合、その証明書の名前は、発信元を識別するために使用されるべきです。この情報は、受信者に表示することができます。
If there is no originator signature present, the only assumption that can be made is the domain the message originated from.
全く発信署名が存在しない場合、行うことができる唯一の仮定は、メッセージが由来するドメインです。
A domain signer can be assumed to have verified any signatures that it encapsulates. Therefore, it is not necessary to verify these signatures before treating the message as authentic. However, this standard does not preclude a recipient from attempting to verify any other signatures that are present.
ドメイン署名者は、それがカプセル化する任意の署名を検証していると仮定することができます。したがって、本物のようにメッセージを処理する前に、これらの署名を検証する必要はありません。しかし、この標準は存在している他の署名を検証しようとしてから受信者を排除するものではありません。
The 'domain signature' is indicated by the presence of the value id-sti-domainSig in a 'signature type' signed attribute.
「ドメイン署名は」属性を締結「署名タイプ」における値Id-STI-domainSigの存在によって示されます。
There MAY be one or more 'domain signature' signatures in an S/MIME encoding.
S / MIMEエンコード中の1つまたは複数のドメインシグネチャー '署名があってもよいです。
The 'additional attributes' signature type indicates that the SignerInfo contains additional attributes that are associated with the message.
「追加属性」署名タイプのSignerInfoは、メッセージに関連付けられた追加の属性を含むことを示します。
All attributes in the applicable SignerInfo MUST be treated as additional attributes. Successful verification of an 'additional attributes' signature means only that the attributes are authentically bound to the message. A recipient MUST NOT assume that its successful verification also authenticates the message originator.
該当のSignerInfoのすべての属性は追加属性として扱わなければなりません。 「追加の属性の署名の検証に成功は、属性が本物のメッセージにバインドされているだけということを意味します。受信者は、その成功の検証はまた、メッセージの発信元を認証すると仮定してはいけません。
An entity generating an 'additional attributes' signature MUST do so using a certificate containing a subject name that follows the naming convention specified in 3.1.1. On reception, a check MUST be made to ensure that the naming convention has been used.
「追加の属性の署名を生成するエンティティは、3.1.1で指定された命名規則を次のサブジェクト名を含む証明書を使用して行う必要があります。レセプションでは、チェックが命名規則が使用されていることを確認するためになされなければなりません。
A signer MAY include any of the attributes listed in [3] or in this document when generating an 'additional attributes' signature. The following attributes have a special meaning, when present in an 'additional attributes' signature:
署名者は、「追加属性」署名を生成する際に、[3]または本文書に記載されている属性のいずれかを含むことができます。とき「追加属性」の署名に存在する以下の属性は、特別な意味を持っています：
1) Equivalent Label: label values in this attribute are to be treated as equivalent to the security label contained in an encapsulated SignerInfo, if present.
1）等価レーベル：この属性のラベル値が存在する場合、カプセル化のSignerInfoに含まれるセキュリティ・ラベルと同等に扱われるべきです。
2) Security Label: the label value indicates the aggregate sensitivity of the inner message content plus any encapsulated signedData and envelopedData containers. The label on the original data is indicated by the value in the originator's signature, if present.
2）セキュリティラベル：ラベル値内側メッセージコンテンツの集合感度および任意のカプセル化されたsignedDataとEnvelopedDataの容器を示しています。存在する場合、元のデータのラベルは、発信者の署名の値で示されています。
An 'additional attributes' signature is indicated by the presence of the value id-sti-addAttribSig in a 'signature type' signed attribute. Other Object Identifiers MUST NOT be included in the sequence of OIDs if this value is present.
「追加属性」署名は、属性に署名した「署名タイプ」の値ID-STI-addAttribSigの存在によって示されます。この値が存在する場合、他のオブジェクト識別子は、OIDのシーケンスに含まれてはなりません。
There MAY be multiple 'additional attributes' signatures in an S/MIME encoding.
S / MIMEエンコードで複数の「追加属性」の署名があるかもしれません。
The review signature indicates that the signer has reviewed the message. Successful verification of a review signature means only that the signer has approved the message for onward transmission to the recipient(s). When the recipient is in another domain, a device on a domain boundary such as a Mail Guard or firewall may be configured to check review signatures. A recipient MUST NOT assume that its successful verification also authenticates the message originator.
レビュー署名は、署名者がメッセージを検討していることを示しています。レビュー署名の検証が成功は、署名者は、受信者への以降の送信のためのメッセージを承認した唯一のことを意味します。受信者が別のドメインにある場合には、そのようなメールガードやファイアウォールなどのドメイン境界上のデバイスはレビューの署名をチェックするように構成することができます。受信者は、その成功の検証はまた、メッセージの発信元を認証すると仮定してはいけません。
An entity generating a signed review signature MUST do so using a certificate containing a subject name that follows the naming convention specified in 3.1.1. On reception, a check MUST be made to ensure that the naming convention has been used.
署名審査署名を生成するエンティティは、3.1.1で指定された命名規則を次のサブジェクト名を含む証明書を使用して行う必要があります。レセプションでは、チェックが命名規則が使用されていることを確認するためになされなければなりません。
A review signature is indicated by the presence of the value id-sti-reviewSig in a 'signature type' signed attribute.
レビュー署名は属性に署名した「署名タイプ」における値Id-STI-reviewSigの存在によって示されます。
There MAY be multiple review signatures in an S/MIME encoding.
S / MIMEエンコードで複数のレビュー署名があるかもしれません。
The 'originator signature' is used to indicate that the signer is the originator of the message and its contents. It is included in this document for completeness only. An originator signature is indicated either by the absence of the signature type attribute, or by the presence of the value id-sti-originatorSig in a 'signature type' signed attribute.
「発信署名」は、署名者は、メッセージとその内容の発信であることを示すために使用されます。これは、唯一の完全を期すために、この文書に含まれています。発信者の署名が署名タイプ属性が存在しないことによって、または属性に署名した「署名タイプ」の値ID-STI-originatorSigの存在のいずれかによって示されます。
Message encryption may be performed by a third party on behalf of a set of originators in a domain. This is referred to as domain encryption. Message decryption may be performed by a third party on behalf of a set of recipients in a domain. This is referred to as domain decryption. The third party that performs these processes is referred to in this section as a "Domain Confidentiality Authority" (DCA). Both of these processes are described in this section.
メッセージの暗号化は、ドメイン内のオリジネーターのセットに代わって第三者によって行われてもよいです。これは、ドメインの暗号化と呼ばれています。メッセージの復号は、ドメイン内の受信者のセットに代わって第三者によって行われてもよいです。これは、ドメイン復号化と呼ばれています。これらの処理を行う第三者は、「ドメイン機密権限」（DCA）として、このセクションで言及されています。これらのプロセスの両方は、このセクションに記載されています。
Messages may be encrypted for decryption by the final recipient and/or by a DCA in the recipient's domain. The message may also be encrypted for decryption by a DCA in the originator's domain (e.g., for content analysis, audit, key word scanning, etc.). The choice of which of these is actually performed is a system specific issue that depends on system security policy. It is therefore outside the scope of this document. These processes of encryption and decryption processes are shown in the following table.
メッセージは受信者のドメインに最終受信者および/またはDCAによる解読のために暗号化することができます。メッセージは、発信者のドメイン内のDCAによって復号のために暗号化されてもよい（例えば、コンテンツ解析、監査、キーワードスキャン、等）。実際に実行されるこれらのうち選択は、システムのセキュリティポリシーに依存してシステム固有の問題です。これは、この文書の範囲外のことです。暗号化と復号化プロセスのこれらのプロセスは、次の表に示します。
--------------------------------------------------------------------
| | Recipient Decryption | Domain Decryption |
|------------------------|----------------------|--------------------|
| Originator Encryption | Case(a) | Case(b) |
| Domain Encryption | Case(c) | Case(d) |
--------------------------------------------------------------------
Case (a), encryption of messages by the originator for decryption by the final recipient(s), is described in CMS [5]. In cases (c) and (d), encryption is performed not by the originator but by the DCA in the originator's domain. In cases (b) and (d), decryption is performed not by the recipient(s) but by the DCA in the recipient's domain.
ケース（a）に示すように、最終的な受信者によって復号化するための発信者によってメッセージの暗号化、CMSに記載されている[5]。例（c）及び（d）では、暗号化はない発信者ではなく、発信元のドメイン内のDCAによって行われます。ケース（b）及び（d）において、復号化は受信者のドメインにない受信者ではなく、DCAによって行われます。
A client implementation that conforms to this standard MUST support case (b) for transmission, case (c) for reception and case (a) for transmission and reception.
この規格に準拠したクライアントの実装では、送信および受信用の送信、受信ケースとケース用（C）（A）の場合と（B）をサポートしなければなりません。
A DCA implementation that conforms to this standard MUST support cases (c) and (d), for transmission, and cases (b) and (d) for reception. In cases (c) and (d) the 'domain signature' SHOULD be applied before the encryption. In cases (b) and (d) the message SHOULD be decrypted before the originators 'domain signature' is obtained and verified.
この規格に準拠したDCAの実装では、受信用ケース（c）及び（d）に示すように、送信のために、及びケース（b）および（d）をサポートしなければなりません。ケースでは（c）および（d）「ドメインシグネチャー」は暗号化の前に適用されるべきです。発信元のドメインシグネチャーを '取得し、検証される前に、ケース（b）及び（d）にメッセージが解読されるべきです。
The process of encryption and decryption is documented in CMS [5]. The only additional requirement introduced by domain encryption and decryption is for greater flexibility in the management of keys, as described in the following subsections. As with signatures, a naming convention and name mapping convention are used to locate the correct public key.
暗号化と復号化のプロセスは、CMS [5]に記載されています。以下のサブセクションで説明するように、ドメインの暗号化と復号化によって導入された唯一の追加要件は、鍵の管理の柔軟性のためです。署名と同じように、命名規則と名前のマッピング規則は、正しい公開鍵を見つけるために使用されています。
The mechanisms described below are applicable both to key agreement and key transport systems, as documented in CMS [5]. The phrase 'encryption key' is used as a collective term to cover the key management keys used by both techniques.
CMS [5]に記載されているように、以下に説明されたメカニズムは、キー合意及び主要な輸送システムの両方に適用可能です。フレーズ「暗号化キーは、」両方の技術が使用する鍵管理キーをカバーする総称として使用されています。
The mechanisms below are also applicable to individual roving users who wish to encrypt messages that are sent back to base.
以下のメカニズムは、ベースに戻って送信されたメッセージを暗号化したい個々のロービングユーザーに適用されます。
A DCA MUST be named 'domain-confidentiality-authority'. This name MUST appear in the 'common name(CN)' component of the subject field in the X.509 certificate. Additionally, if the certificate contains an RFC 822 address, this name MUST appear in the end entity part of the address, i.e., on the left-hand side of the '@' symbol.
DCAは、「ドメイン・機密性・権威」という名前でなければなりません。この名前は、X.509証明書のサブジェクトフィールドの「共通名（CN）」成分に現れなければなりません。証明書は、RFC 822のアドレスが含まれている場合に加えて、この名前は、「@」記号の左側に、即ち、アドレスの終わりの実体部分に現れなければなりません。
Along with this naming convention, an additional naming rule is defined: the 'name mapping rule'. The name mapping rule states that for a DCA, the domain part of its name MUST be the same as, or an ascendant of (as defined in section 3.1.1), the domain name of the set of entities that it represents. The domain part is defined as follows:
この命名規則に加えて、追加の命名規則が定義されている：「名前のマッピングルール」を。名前マッピング規則はDCAのために、その名前のドメイン部分は、それが表すエンティティのセットのドメイン名と同じ、または（セクション3.1.1で定義されている）の先祖である必要があること。次のようにドメイン部分が定義されています。
* In the case of an X.500 distinguished name of an X.509 certificate, the domain part is the country, organization, organizational unit, state, and locality components of the distinguished name.
* X.509証明書のX.500識別名の場合は、ドメイン部分は、国、組織、組織単位、状態、および識別名の局所性コンポーネントです。
* In the case of an RFC 2247 distinguished name, the domain part is the domain components of the distinguished name.
* RFC 2247識別名の場合には、ドメイン部分は、識別名のドメインコンポーネントです。
* If the certificate contains an RFC 822 address, the domain part is defined to be the RFC 822 address part on the right-hand side of the '@' symbol.
証明書は、RFC 822アドレスが含まれている場合は*、ドメイン部分を「@」記号の右側にRFC 822アドレス部分であると定義されます。
For example, a DCA acting on behalf of John Doe of the Acme corporation, whose distinguished name is 'cn=John Doe,ou=marketing, o=acme,c=us' and whose e-mail address is John.Doe@marketing.acme.com, could have a certificate containing a distinguished name of 'cn=domain-confidentiality-authority,o=acme,c=us' and an e-mail address of 'domain-confidentiality-authority@acme.com'. If John Doe has an RFC 2247 defined address of 'cn=John Doe,dc=marketing, dc=defense,dc=acme,dc=us' then the domain signing authority could have a distinguished name of 'cn=domain-signing-authority,dc=defence,dc=acme,dc=us'. The key associated with this certificate would be used for encrypting messages for John Doe.
例えば、その識別名であるアクメ社のジョン・ドウの代わりに動作DCA、「CN =ジョン・ドウ、OU =マーケティングは、O = ACME、C = US」とその電子メールアドレスがJohn.Doe@marketingされます.acme.comは、「CN =ドメイン・機密性・権威、O = ACME、C =私たちを」と「domain-confidentiality-authority@acme.com」の電子メールアドレスの識別名を含む証明書を持つことができます。ジョン・ドウは、「CN =ジョン・ドウ、DC =マーケティング、DC =防衛、DC = ACME、DCが私たちを=」のRFC 2247定義されたアドレスを持っている場合は、ドメインの署名権限は「CN =ドメインsigning-の識別名を持つことができます当局は、dcは=防衛は、DC = ACMEは、DCは、私たち=。この証明書に関連付けられたキーは、ジョン・ドウのメッセージを暗号化するために使用されるであろう。
Any message received where the domain part of the domain encrypting agents name does not match, or is not an ascendant of, the domain name of the entities it represents MUST be flagged.
すべてのメッセージは、エージェント名を暗号化するドメインのドメイン部分が一致しない場合、受信し、またはそれが表すエンティティのドメイン名の優勢は、フラグを設定する必要がありません。
This naming rule prevents messages being encrypted for the wrong domain decryption agent.
この命名規則は、間違ったドメイン復号化エージェントのために暗号化されたメッセージを防ぎます。
Implementations conforming to this standard MUST support this name mapping convention as a minimum. Implementations may choose to supplement this convention with other locally defined conventions. However, these MUST be agreed between sender and recipient domains prior to sending any messages.
この規格に準拠した実装は、最低でもこの名前マッピング規則をサポートしなければなりません。実装は、他のローカルに定義された規則にこの条約を補完することもできます。しかし、これらはすべてのメッセージを送信する前に、送信者と受信者のドメインの間で合意されなければなりません。
At the sender's domain, DCA encryption is achieved using the recipient DCA's certificate or the end recipient's certificate. For this, the encrypting process must be able to correctly locate the certificate for the corresponding DCA in the recipient's domain or the one corresponding to the end recipient. Having located the correct certificate, the encryption process is then performed and additional information required for decryption is conveyed to the recipient in the recipientInfo field as specified in CMS [5]. A DCA encryption agent MUST be named according to the naming convention specified in section 4.1. This is so that the corresponding certificate can be found.
送信者のドメインでは、DCAの暗号化は、受信者DCAの証明書または最終受信者の証明書を使用して達成されます。このため、暗号化処理が正常に受信者のドメイン内の対応するDCAのための証明書または最終受信者に対応するものを見つけることができなければなりません。正しい証明書を配置したが、暗号化処理は、次に実行され、復号化に必要な追加情報が搬送されるのRecipientInfoフィールドの受信者にCMSに指定されている[5]。 DCA暗号化エージェントは、セクション4.1で指定された命名規則に従って名前を付ける必要があります。対応する証明書を見つけることができるようにするためです。
No specific method for locating the certificate to the corresponding DCA in the recipient's domain or the one corresponding to the end recipient is mandated in this document. An implementation may choose to access a local certificate store to locate the correct certificate. Alternatively, a X.500 or LDAP directory may be used in one of the following ways:
受信者のドメインまたはエンド受信者に対応するもので、対応するDCAへの証明書を検索するための具体的な方法は、本文書に義務付けられていません。実装が正しい証明書を見つけるために、ローカル証明書ストアにアクセスすることもできます。また、X.500またはLDAPディレクトリには、次のいずれかの方法で使用することができます。
1. The directory may store the DCA certificate in the recipient's directory entry. When the user certificate attribute is requested, this certificate is returned.
1.ディレクトリは、受信者のディレクトリエントリにDCA証明書を格納することができます。ユーザー証明書の属性が要求されると、この証明書が返されます。
2. The encrypting agent maps the recipient's name to the DCA name in the manner specified in 4.1. The user certificate attribute associated with this directory entry is then obtained.
2.暗号化エージェントは4.1で指定された方法でDCA名に受信者の名前をマップします。このディレクトリエントリに関連付けられているユーザ証明書の属性が、その後得られます。
This document does not mandate either of these processes. Whichever one is used, the name mapping conventions must be adhered to, in order to maintain confidentiality.
この文書では、これらのプロセスのいずれかを強制しません。どちらのものが使用され、名前のマッピング規則は、機密性を維持するために、に付着しなければなりません。
Having located the correct certificate, the encryption process is then performed. A recipientInfo for the DCA or end recipient is then generated, as described in CMS [5].
正しい証明書を設置したので、暗号化処理が実行されます。 CMS [5]に記載のようにDCAまたはエンド受信者のためのRecipientInfoは次いで、生成されます。
DCA encryption may be performed for decryption by the end recipient and/or by a DCA. End recipient decryption is described in CMS [5]. DCA decryption is described in section 4.3.
DCAの暗号化は、エンド受信者及び/又はDCAによって復号化を行ってもよいです。エンド受信者の復号化は、CMSに記述されている[5]。 DCAの解読は、セクション4.3に記載されています。
DCA decryption uses a private-key belonging to the DCA and the necessary information conveyed in the DCA's recipientInfo field.
DCAの解読は、DCAとDCAののRecipientInfoフィールドに伝え、必要な情報に属する秘密鍵を使用しています。
It should be noted that domain decryption can be performed on messages encrypted by the originator and/or by a DCA in the originator's domain. In the first case, the encryption process is described in CMS [5]; in the second case, the encryption process is described in 4.2.
ドメイン復号化が発信者のドメイン内で発信者によっておよび/またはDCAにより暗号化されたメッセージに対して実行できることに留意すべきです。最初のケースでは、暗号化処理は、CMS [5]に記載されています。第二の場合には、暗号化処理は、4.2に記載されています。
It is possible that a message leaving a DOMSEC domain may encounter a Mail List Agent (MLA) before it reaches the final recipient. There is a possibility that this would result in the 'domain signature' being stripped off the message. We do not want a MLA to remove the 'domain signature'. Therefore, the 'domain signature' must be applied to the message in such a way that will prevent a MLA from removing it.
最終的な受信者に到達する前にDOMSECドメインを残したメッセージがメールリストエージェント（MLA）が遭遇する可能性があります。これはメッセージ剥ぎ取られているのドメイン署名 "につながる可能性があります。私たちは、MLAは、「ドメインの署名」を削除する必要はありません。したがって、「ドメインシグネチャー」は、それを除去することからMLAを防止するように、メッセージに適用されなければなりません。
A MLA will search a message for the "outer" signedData layer, as defined in ESS [3] section 4.2, and strip off all signedData layers that encapsulate this "outer" signedData layer. Where this "outer" signedData layer is found will depend on whether the message contains a mlExpansionHistory attribute or an envelopedData layer.
MLAは、ESS [3]のセクション4.2で定義されるように、「外側」たsignedData層のためのメッセージを検索し、この「外側」たsignedData層をカプセル化する全てたsignedData層を取り除くであろう。この「外側」たsignedData層が発見された場合は、メッセージがmlExpansionHistory属性またはEnvelopedDataの層が含まれているかどうかに依存します。
There is a possibility that a message leaving a DOMSEC domain has already been processed by a MLA, in which case a 'mlExpansionHistory' attribute will be present within the message.
DOMSECドメインを残したメッセージは、すでに「mlExpansionHistory」属性は、メッセージ内に存在することになる。その場合にはMLA、によって処理された可能性があります。
There is a possibility that the message will contain an envelopedData layer. This will be the case when the message has been encrypted within the domain for the domain's "Domain Confidentiality Authority", see section 4.0, and, possibly, the final recipient.
メッセージはEnvelopedDataの層が含まれている可能性があります。これは、セクション4.0、そして、おそらく、最終的に受信者を参照してください、メッセージはドメインの「ドメインの機密機関」のドメイン内で暗号化されている場合になります。
How the 'domain signature' is applied will depend on what is already present within the message. Before the 'domain signature' can be applied the message MUST be searched for the "outer" signedData layer, this search is complete when one of the following is found: -
どのように「ドメイン署名が」適用されたメッセージの中にすでに存在しているかに依存します。 「ドメインの署名が」「外側」たsignedData層で検索しなければならないメッセージを適用する前に、次のいずれかが発見された場合、この検索が完了しています： -
- The "outer" signedData layer that includes an mlExpansionHistory attribute or encapsulates an envelopedData object. - An envelopedData layer. - The original content (that is, a layer that is neither envelopedData nor signedData).
- mlExpansionHistory属性を含むか、EnvelopedDataのオブジェクトをカプセル化する「外側」たsignedData層。 - EnvelopedDataの層。 - 元のコンテンツ（すなわち、EnvelopedDataのたりたsignedDataでもない層です）。
If a signedData layer containing a mlExpansionHistory attribute has been found then: -
mlExpansionHistory属性を含むたsignedData層が、その後発見された場合 -
1) Strip off the signedData layer (after remembering the included signedAttributes).
1））が含まsignedAttributesのを思い出した後（たsignedData層を取り除きます。
2) Search the rest of the message until an envelopedData layer or the original content is found.
2）EnvelopedDataの層まで、メッセージの残りの部分を検索するか、元のコンテンツが発見されました。
3) a) If an envelopedData layer has been found then: -
3）a）はEnvelopedDataの層が、その後発見された場合 -
- Strip off all the signedData layers down to the
envelopedData layer.
- Locate the RecipientInfo for the local DCA and use the
information it contains to obtain the message key.
- Decrypt the encryptedContent using the message key.
- Encapsulate the decrypted message with a 'domain
signature'
- If local policy requires the message to be encrypted
using S/MIME encryption before leaving the domain then
encapsulate the 'domain signature' with an envelopedData
layer containing RecipientInfo structures for each of the
recipients and an originatorInfo value built from
information describing this DCA.
If local policy does not require the message to be encrypted using S/MIME encryption but there is an envelopedData at a lower level within the message then the 'domain signature' MUST be encapsulated by an envelopedData as described above.
ローカルポリシーがS / MIME暗号化を使用して暗号化されるメッセージを必要としないが、EnvelopedDataのメッセージ内の低いレベルで存在する場合、上述のように「ドメインシグネチャー」はEnvelopedDataのによってカプセル化されなければなりません。
An example when it may not be local policy to require S/MIME encryption is when there is a link crypto present.
リンク暗号存在があるとき、S / MIME暗号化を要求するために、ローカルポリシーではないかもしれない例があります。
b) If an envelopedData layer has not been found then: -
b）はEnvelopedDataの層が、その後発見されていない場合： -
- Encapsulate the new message with a 'domain signature'.
- 「ドメイン署名」で新しいメッセージのカプセル化。
4) Encapsulate the new message in a signedData layer, adding the signedAttributes from the signedData layer that contained the mlExpansionHistory attribute.
4）mlExpansionHistory属性を含んでいたsignedData層からsignedAttributesのを追加、たsignedData層で新しいメッセージをカプセル化します。
If no signedData layer containing a mlExpansionHistory attribute has been found but an envelopedData has been found then: -
mlExpansionHistory属性を含む一切たsignedData層が発見されていないが、EnvelopedDataのは、発見された場合 -
1) Strip off all the signedData layers down to the envelopedData layer. 2) Locate the RecipientInfo for the local DCA and use the information it contains to obtain the message key. 3) Decrypt the encryptedContent using the message key. 4) Encapsulate the decrypted message with a 'domain signature' 5) If local policy requires the message to be encrypted before leaving the domain then encapsulate the 'domain signature' with an envelopedData layer containing RecipientInfo structures for each of the recipients and an originatorInfo value built from information describing this DCA.
1）EnvelopedDataの層まで全てたsignedData層を取り除きます。 2）局所DCAのためのRecipientInfoを見つけ、それはメッセージ鍵を取得するために含まれている情報を使用します。 3）メッセージ鍵を用いて暗号化コンテンツを復号化。 4）ローカルポリシーがドメインを離れる前に暗号化されるメッセージを必要とする場合5）を受信者のそれぞれについてのRecipientInfo構造を含むEnvelopedDataの層とoriginatorInfo値と「ドメイン署名を」カプセル化「ドメインシグネチャー」と復号化されたメッセージをカプセル化このDCAを記述した情報から構築されました。
If local policy does not require the message to be encrypted using S/MIME encryption but there is an envelopedData at a lower level within the message then the 'domain signature' MUST be encapsulated by an envelopedData as described above.
ローカルポリシーがS / MIME暗号化を使用して暗号化されるメッセージを必要としないが、EnvelopedDataのメッセージ内の低いレベルで存在する場合、上述のように「ドメインシグネチャー」はEnvelopedDataのによってカプセル化されなければなりません。
If no signedData layer containing a mlExpansionHistory attribute has been found and no envelopedData has been found then: -
mlExpansionHistory属性を含む一切たsignedData層が発見されていないと何もEnvelopedDataのは、見つかっていない場合： -
1) Encapsulate the message in a 'domain signature'.
1）「ドメインシグネチャー」にメッセージをカプセル化。
The following examples help explain the above rules. All of the signedData objects are valid and none of them are a domain signature. If a signedData object was a domain signature then it would not be necessary to validate any further signedData objects.
次の例では、上記の規則を説明するのに役立ちます。たsignedDataオブジェクトのすべてが有効であり、それらのどれも、ドメイン署名されません。 SignedDataオブジェクトがドメインシグネチャーであった場合、さらなるたsignedDataオブジェクトを検証する必要はありません。
1) A message (S1 (Original Content)) (where S = signedData) in which the signedData does not include an mlExpansionHistory attribute is to have a 'domain signature' applied. The signedData, S1, is verified. No "outer" signedData is found, after searching for one as defined above, since the original content is found, nor is an envelopedData or a mlExpansionHistory attribute found. A new signedData layer, S2, is created that contains a 'domain signature', resulting in the following message sent out of the domain (S2 (S1 (Original Content))).
1）たsignedDataがmlExpansionHistory属性を含まない、メッセージ（S1（オリジナルコンテンツ））（S =たsignedData）が「ドメインシグネチャー」が適用されていることです。たsignedData、S1は、検証されます。元のコンテンツが見つからず、またEnvelopedDataの又は見出さmlExpansionHistory属性であるので、「外側」たsignedDataは、上記で定義したいずれかの検索の後、見出されていない全く。新しいたsignedData層、S2は、ドメイン（S2（S1（オリジナルコンテンツ）））から送信された次のメッセージをもたらす、「ドメイン署名」を含むが作成されます。
2) A message (S3 (S2 (S1 (Original Content))) in which none of the signedData layers includes an mlExpansionHistory attribute is to have a 'domain signature' applied. The signedData objects S1, S2 and S3 are verified. There is not an original, "outer" signedData layer since the original content is found, nor is an envelopedData or a mlExpansionHistory attribute found. A new signedData layer, S4, is created that contains a 'domain signature', resulting in the following message sent out of the domain (S4 (S3 (S2 (S1 (Original Content))).
たsignedData層のいずれもmlExpansionHistory属性が含まれていないれた2）メッセージが（S3（S2（S1（オリジナルコンテンツ）））「ドメイン署名」適用を有することである。たsignedDataはS1、S2及びS3が検証されるオブジェクト。ありますない元、元のコンテンツが見つからず、またEnvelopedDataの又は見出さmlExpansionHistory属性。送り出された次のメッセージをもたらす、「ドメイン署名」を含む新しいたsignedData層、S4、作成されているので、「外側」たsignedData層ドメインの（S4（S3（S2（S1（オリジナルコンテンツ）））。
3) A message (E1 (S1 (Original Content))) (where E = envelopedData) in which S1 does not include a mlExpansionHistory attribute is to have a 'domain signature' applied. There is not an original, received "outer" signedData layer since the envelopedData, E1, is found at the outer layer. The encryptedContent is decrypted. The signedData, S1, is verified. The decrypted content is wrapped in a new signedData layer, S2, which contains a 'domain signature'. If local policy requires the message to be encrypted, using S/MIME encryption, before it leaves the domain then this new message is wrapped in an envelopedData layer, E2, resulting in the following message sent out of the domain (E2 (S2 (S1 (Original Content)))), else the message is not wrapped in an envelopedData layer resulting in the following message (S2 (S1 (Original Content))) being sent.
3）メッセージ（E1（S1（オリジナルコンテンツ）））（S1がmlExpansionHistory属性を含まないでE = EnvelopedDataの）が「ドメイン署名」適用を有することです。 EnvelopedDataの、E1は、外側の層で発見されているので、原稿が存在しない、「外側」たsignedData層を受けました。暗号化コンテンツを復号化されます。たsignedData、S1は、検証されます。復号化されたコンテンツは、「ドメインの署名」を含む新しいたsignedData層、S2、に包まれています。ローカルポリシーはドメインの外に送信され、次のメッセージが得られ、それがドメインを離れる前に、この新しいメッセージがEnvelopedDataの層、E2に包まれて、S / MIME暗号化を使用して、暗号化するメッセージを必要とする場合（E2（S2（S1 （オリジナルコンテンツ））））、他のメッセージは、次のメッセージ（S2（S1（オリジナルコンテンツ）））送信され、その結果EnvelopedDataの層に包まれていません。
4) A message (S2 (E1 (S1 (Original Content)))) in which S2 includes a mlExpansionHistory attribute is to have a 'domain signature' applied. The signedData object S2 is verified. The mlExpansionHistory attribute is found in S2, so S2 is the "outer" signedData. The signed attributes in S2 are remembered for later inclusion in the new outer signedData that is applied to the message. S2 is stripped off and the message is decrypted. The signedData object S1 is verified. The decrypted message is wrapped in a signedData layer, S3, which contains a 'domain signature'. If local policy requires the message to be encrypted, using S/MIME encryption, before it leaves the domain then this new message is wrapped in an envelopedData layer, E2. A new signedData layer, S4, is then wrapped around the envelopedData,
4）S2がmlExpansionHistory属性を含む、メッセージは（S2（E1（S1（オリジナルコンテンツ））））「ドメイン署名」適用を有することです。 SignedDataオブジェクトS2が検証されます。 mlExpansionHistory属性は、S2で発見されたので、S2は「外側」signedDataです。 S2で署名された属性がメッセージに適用される新たな外側たsignedDataの後の包含のために記憶されています。 S2が剥離され、メッセージが解読されます。 SignedDataオブジェクトS1が検証されます。復号化されたメッセージは、「ドメインシグネチャー」が含まれたsignedData層、S3、に包まれています。ローカルポリシーは、メッセージを必要とする場合、それは、この新しいメッセージがEnvelopedDataの層、E2に包まれているドメインを離れる前に、S / MIME暗号化を使用して、暗号化します。新たsignedData層は、S4、その後、EnvelopedDataの周りに巻かれます
E2, resulting in the following message sent out of the domain (S4 (E2 (S3 (S1 (Original Content))))). If local policy does not require the message to be encrypted, using S/MIME encryption, before it leaves the domain then the message is not wrapped in an envelopedData layer but is wrapped in a new signedData layer, S4, resulting in the following message sent out of the domain (S4 (S3 (S1 (Original Content). The signedData S4, in both cases, contains the signed attributes from S2.
E2、ドメインの外に送信され、次のメッセージが得られ（S4（E2（S3（S1（オリジナルコンテンツ）））））。ローカルポリシーは、ドメインを離れる前に、メッセージがEnvelopedDataの層に包まれていませんが、新しいたsignedData層、S4に包まれて、送られた次のようなメッセージが得られ、S / MIME暗号化を使用して、暗号化するメッセージを必要としない場合ドメイン（S4（S3（S1（オリジナルコンテンツ）のうちたsignedData S4は、両方の場合において、S2から署名された属性を含みます。
5) A message (S3 (S2 (E1 (S1 (Original Content))))) in which none of the signedData layers include a mlExpansionHistory attribute is to have a 'domain signature' applied. The signedData objects S3 and S2 are verified. When the envelopedData E1 is found the signedData objects S3 and S2 are stripped off. The encryptedContent is decrypted. The signedData object S1 is verified. The decrypted content is wrapped in a new signedData layer, S4, which contains a 'domain signature'. If local policy requires the message to be encrypted, using S/MIME encryption, before it leaves the domain then this new message is wrapped in an envelopedData layer, E2, resulting in the following message sent out of the domain (E2 (S4 (S1 (Original Content)))), else the message is not wrapped in an envelopedData layer resulting in the following message (S4 (S1 (Original Content))) being sent.
5）メッセージ（S3（S2（E1（S1（オリジナルコンテンツ）））））ではたsignedData層のいずれもmlExpansionHistory属性が「ドメイン署名」適用を有することである含んでいません。たsignedDataはS3とS2が確認されているオブジェクト。 EnvelopedDataのE1が発見された場合たsignedDataオブジェクトS3とS2が剥離されます。暗号化コンテンツを復号化されます。 SignedDataオブジェクトS1が検証されます。復号化されたコンテンツは、「ドメインの署名」を含む新しいたsignedData層、S4、に包まれています。ローカルポリシーはドメインの外に送信され、次のメッセージが得られ、それがドメインを離れる前に、この新しいメッセージがEnvelopedDataの層、E2に包まれて、S / MIME暗号化を使用して、暗号化するメッセージを必要とする場合（E2（S4（S1 （オリジナルコンテンツ））））、他のメッセージは、次のメッセージ（S4（S1（オリジナルコンテンツ）））送信され、その結果EnvelopedDataの層に包まれていません。
6) A message (S3 (S2 (E1 (S1 (Original Content))))) in which S3 includes a mlExpansionHistory attribute is to have a 'domain signature' applied. The signedData objects S3 and S2 are verified. The mlExpansionHistory attribute is found in S3, so S3 is the "outer" signedData. The signed attributes in S3 are remembered for later inclusion in the new outer signedData that is applied to the message. The signedData object S3 is stripped off. When the envelopedData layer, E1, is found the signedData object S2 is stripped off. The encryptedContent is decrypted. The signedData object S1 is verified. The decrypted content is wrapped in a new signedData layer, S4, which contains a 'domain signature'. If local policy requires the message to be encrypted, using S/MIME encryption, before it leaves the domain then this new message is wrapped in an envelopedData layer, E2. A new signedData layer, S5, is then wrapped around the envelopedData, E2, resulting in the following message sent out of the domain (S5 (E2 (S4 (S1 (Original Content))))). If local policy does not require the message to be encrypted, using S/MIME encryption, before it leaves the domain then the message is not wrapped in an envelopedData layer but is wrapped in a new signedData layer, S5, resulting in the following message sent out of the domain (S5 (S4 (S1 (Original Content). The signedData S5, in both cases, contains the signed attributes from S3.
6）メッセージ（S3（S2（E1（S1（オリジナルコンテンツ）））））S3がmlExpansionHistory属性が 'ドメイン署名' 適用を有することである含んでいます。たsignedDataはS3とS2が確認されているオブジェクト。 mlExpansionHistory属性はS3に発見されたので、S3は「外側」signedDataです。 S3で署名された属性がメッセージに適用される新たな外側たsignedDataの後の包含のために記憶されています。 SignedDataオブジェクトS3が剥ぎ取られます。 EnvelopedDataの層E1は、SignedDataオブジェクトが発見された場合S2を剥離します。暗号化コンテンツを復号化されます。 SignedDataオブジェクトS1が検証されます。復号化されたコンテンツは、「ドメインの署名」を含む新しいたsignedData層、S4、に包まれています。ローカルポリシーは、メッセージを必要とする場合、それは、この新しいメッセージがEnvelopedDataの層、E2に包まれているドメインを離れる前に、S / MIME暗号化を使用して、暗号化します。新しいたsignedData層、S5、その後ドメインから送信された次のメッセージをもたらす、EnvelopedDataの、E2の周りに巻かれる（S5（E2（S4（S1（オリジナルコンテンツ）））））。ローカルポリシーは、ドメインを離れる前に、メッセージがEnvelopedDataの層に包まれていませんが、新しいたsignedData層、S5に包まれて、送られた次のようなメッセージが得られ、S / MIME暗号化を使用して、暗号化するメッセージを必要としない場合ドメイン（S5（S4（S1（オリジナルコンテンツ）のうちたsignedData S5は、両方の場合に、S3から署名された属性を含みます。
7) A message (S3 (E2 (S2 (E1 (S1 (Original Content)))))) in which S3 does not include a mlExpansionHistory attribute is to have a 'domain signature' applied. The signedData object S3 is verified. When the envelopedData E2 is found the signedData object S3 is stripped off. The encryptedContent is decrypted. The signedData object S2 is verified, the envelopedData E1 is decrypted and the signedData object S1 is verified. The signedData object S2 is wrapped in a new signedData layer S4, which contains a 'domain signature'. Since there is an envelopedData E1 lower down in the message, the new message is wrapped in an envelopedData layer, E3, resulting in the following message sent out of the domain (E3 (S4 (S2 (E1 (S1 (Original Content)))))).
7）メッセージ（S3（E2（S2（E1（S1（オリジナルコンテンツ））））））ここでS3はmlExpansionHistory属性が 'ドメイン署名' 適用を有することである含んでいません。 SignedDataオブジェクトS3が検証されます。 EnvelopedDataのE2はSignedDataオブジェクトを発見された場合はS3が剥ぎ取られます。暗号化コンテンツを復号化されます。 S2が検証されるSignedDataオブジェクトは、EnvelopedDataのE1が解読されたsignedDataオブジェクトS1が検証されます。 SignedDataオブジェクトS2は「ドメイン署名」を含む新しいたsignedData層S4、に包まれています。 EnvelopedDataのE1メッセージにダウン低下があるため、新たなメッセージがドメインから送信された次のメッセージをもたらす、EnvelopedDataの層、E3に包まれる（E3（S4（S2（E1（S1（オリジナルコンテンツ））） ）））。
This specification relies on the existence of several well known names, such as domain-confidentiality-authority. Organizations must take care with these names, even if they do not support DOMSEC, so that certificates issued in these names are only issued to legitimate entities. If this is not true then an individual could get a certificate associated with domain-confidentiality-authority@acme.com and as a result might be able to read messages the a DOMSEC client intended for others.
この仕様は、ドメイン・機密性・権威としていくつかのよく知られた名前の存在に依存しています。組織は、これらの名前で発行された証明書が正当なエンティティに発行されるように、彼らは、DOMSECをサポートしていない場合でも、これらの名前に注意しなければなりません。これが真でない場合、個々のメッセージ他人のために意図DOMSECクライアントを読むことができるかもしれない結果domain-confidentiality-authority@acme.comにとして関連付けられた証明書を得ることができます。
Implementations MUST protect all private keys. Compromise of the signer's private key permits masquerade.
実装は、すべての秘密鍵を保護しなければなりません。署名者の秘密鍵の許可の妥協を装います。
Similarly, compromise of the content-encryption key may result in disclosure of the encrypted content.
同様に、コンテンツ暗号化キーの妥協は暗号化されたコンテンツの開示をもたらすことができます。
Compromise of key material is regarded as an even more serious issue for domain security services than for an S/MIME client. This is because compromise of the private key may in turn compromise the security of a whole domain. Therefore, great care should be used when considering its protection.
キーマテリアルの妥協がS / MIMEクライアント用よりも、ドメインセキュリティサービスのためのさらに深刻な問題とみなされています。秘密鍵の妥協が順番にドメイン全体のセキュリティを危険にさらす可能性があるためです。その保護を考慮した場合そのため、細心の注意を使用する必要があります。
Domain encryption alone is not secure and should be used in conjunction with a domain signature to avoid a masquerade attack, where an attacker that has obtained a DCA certificate can fake a message to that domain pretending to be another domain.
ドメインの暗号化だけでは確保されていないとDCAの証明書を取得した攻撃者は、そのドメインに偽のメッセージが別のドメインになりすましてできマスカレード攻撃を避けるために、ドメインのシグネチャと組み合わせて使用する必要があります。
When an encrypted DOMSEC message is sent to an end user in such a way that the message is decrypted by the end users DCA the message will be in plain text and therefore confidentiality could be compromised.
暗号化されたDOMSECメッセージは、メッセージがエンドユーザによって復号化されるように、エンドユーザに送信されるとDCAメッセージは、プレーンテキストになり、したがって、機密性が損なわれる可能性があります。
If the recipient's DCA is compromised then the recipient can not guarantee the integrity of the message. Furthermore, even if the recipient's DCA correctly verifies a message's signatures, then a message could be undetectably modified, when there are no signatures on a message that the recipient can verify.
受信者のDCAが侵害された場合、受信者は、メッセージの整合性を保証することはできません。受信者が確認することができますメッセージには署名がない場合さらに、受信者のDCAが正しくメッセージの署名を検証していても、そのメッセージは検出できない、変更することができます。
DOMSECSyntax { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) domsec(10) }
DOMSECSyntax {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）モジュール（0）domsec（10）}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS All -- The types and values defined in this module are exported for -- use in the other ASN.1 modules. Other applications may use -- them for their own purposes.
- すべてのエクスポート - 他のASN.1モジュールで使用 - このモジュールで定義されたタイプと値はのためにエクスポートされます。他のアプリケーションが使用することができます - それらを独自の目的のために。
SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
id-sti OBJECT IDENTIFIER ::= { id-smime 9 } -- signature type
identifier
-- Signature Type Identifiers
- シグニチャタイプ識別子
id-sti-originatorSig OBJECT IDENTIFIER ::= { id-sti 1 }
id-sti-domainSig OBJECT IDENTIFIER ::= { id-sti 2 }
id-sti-addAttribSig OBJECT IDENTIFIER ::= { id-sti 3 }
id-sti-reviewSig OBJECT IDENTIFIER ::= { id-sti 4 }
END -- of DOMSECSyntax
END - DOMSECSyntaxの
[1] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[1] Ramsdell、B.、 "S / MIMEバージョン3メッセージ仕様"、RFC 2633、1999年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[3]ホフマン、P.、 "S / MIMEのためのセキュリティサービスの強化"、RFC 2634、1999年6月を。
[4] International Telecommunications Union, Recommendation X.208, "Open systems interconnection: specification of Abstract Syntax Notation (ASN.1)", CCITT Blue Book, 1989.
[4]国際電気通信連合、勧告X.208、 "オープン・システム間相互接続：抽象構文記法（ASN.1）の仕様"、CCITTブルーブック、1989。
[5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[5] Housley氏、R.、 "暗号メッセージ構文"、RFC 2630、1999年6月。
Tim Dean QinetiQ St. Andrews Road Malvern Worcs WR14 3PS
ティム・ディーンキネティック社セントアンドリュース道路マルバーンWorcs WR14 3PS
Phone: +44 (0) 1684 894239 Fax: +44 (0) 1684 896660 EMail: tbdean@QinetiQ.com
電話：+44（0）1684 894239ファックス：+44（0）1684 896660 Eメール：tbdean@QinetiQ.com
William Ottaway QinetiQ St. Andrews Road Malvern Worcs WR14 3PS
ウィリアムOttawayキネティック社セントアンドリュース道路マルバーンWorcs WR14 3PS
Phone: +44 (0) 1684 894079 Fax: +44 (0) 1684 896660 EMail: wjottaway@QinetiQ.com
電話：+44（0）1684 894079ファックス：+44（0）1684 896660 Eメール：wjottaway@QinetiQ.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。