[要約] RFC 3183は、S/MIMEを使用したドメインセキュリティサービスに関する標準化ドキュメントです。その目的は、電子メールのセキュリティを向上させ、ドメイン内の通信を保護することです。
Network Working Group T. Dean
Request for Comments: 3183 W. Ottaway
Category: Experimental QinetiQ
October 2001
Domain Security Services using S/MIME
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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（Secure/Multipurpose Internet Mail Extensions）プロトコルを、セキュリティサービスを提供するためのメッセージ転送エージェント、ガード、ゲートウェイなど、通信システムの多くのコンポーネントによって処理および生成される方法について説明します。これらのサービスは、集合的に「ドメインセキュリティサービス」と呼ばれます。
Acknowledgements
謝辞
Significant comments were made by Luis Barriga, Greg Colla, Trevor Freeman, Russ Housley, Dave Kemp, Jim Schaad and Michael Zolotarev.
Luis Barriga、Greg Colla、Trevor Freeman、Russ Housley、Dave Kemp、Jim Schaad、Michael 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.
このドキュメントで説明されているメカニズムは、さまざまなセキュリティドメインが安全に通信したい場合に発生する多くの相互運用性の問題と技術的な制限を解決するように設計されています。または、単一のドメインが、信頼されていないドメインに居住するメンバーの1人と安全に通信したい場合。このドキュメントでカバーされているシナリオは、ドメインからドメイン、個人からドメイン、ドメイン間通信です。このドキュメントは、外の世界からアクセスできない内部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シリーズプロトコルを使用する1つの組織では、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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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つのセキュリティドメイン間のインターフェイスは、「セキュリティ境界」と呼ばれます。セキュリティドメインの1つの例は、組織ネットワーク（「イントラネット」）です。
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つの「イントラネット」がインターネットを使用して接続されている場合、またはイントラネットがインターネット上のリモートユーザーに接続されている場合。2つのドメインが内部的に互換性のない署名スキームを使用する場合、またはPKI間に認証リンクがない場合に使用できます。どちらの場合も、オリジネーターのドメインからのメッセージは、受信者または受信者ドメインによって処理できるアルゴリズム、キー、および証明書を使用して、元のメッセージと署名（存在する場合）を介して署名されます。ドメインの署名は、「組織署名」と呼ばれることもあります。
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]は、最初に署名され、次に暗号化されてから再び署名されたトリプルラップされたメッセージの概念を紹介します。このドキュメントでは、このトリプルラップの概念も使用しています。さらに、このドキュメントでは、「署名カプセル化」の概念も使用しています。「署名カプセル化」とは、署名に包まれた署名または署名されていないメッセージを示します。この署名は、コンテンツと最初の（内側の）署名の両方をカバーします（存在する場合）。
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には署名者が含まれていないため、cms [5]で説明されているように、cmsulatedContentInfo内のecontentTypeはid-dataでなければなりません。ただし、econtentフィールドには、CMS [5]のセクション5.2で提案されているように、空のままにされる代わりに、署名されていないメッセージが含まれます。これは、以下の方法2）で定義されているように、DOMSEC定義された署名が追加されると、署名が署名されていないメッセージをカバーします。
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コンポーネントが1つだけ存在する必要があります。さらに、証明書に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:
ドメイン署名の場合、追加の命名ルールが定義されています：「名前マッピングルール」。名前のマッピングルールには、ドメイン署名機関の場合、その名前のドメイン部分は、それが表すメッセージオリジネーターのドメイン名と同じ、またはアセンダントでなければならないことが示されています。ドメイン部分は次のように定義されています。
* 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.500の著名な件名名X.509証明書の場合、ドメイン部分は、著名な名前の国、組織、組織単位、州、および地域のコンポーネントです。
* 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 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.
たとえば、ACME CorporationのJohn Doeに代わって行動するドメイン署名機関の著名な名前は「CN = John Doe、Ou = Marketing、O = Acme、C = US」であり、その電子メールアドレスはJohn.Doeです。@marketing.acme.com、「cn = domain-singe-authority、o = acme、c = us」の著名な名前を含む証明書を持つことができます。。John Doeには、「CN = John Doe、DC = Marketing、DC = ACME、DC = US」のRFC 2247の定義アドレスがある場合、 'cn = domain-singe-authority、dc = acme、dc = us'のアドレスドメイン署名機関を表すために使用されます。
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.
最も重要なコンポーネント（つまり、国、地域、または組織を表す「DC」エントリ）から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'.
たとえば、ACME CorporationのJohn Doeに代わって行動するドメイン署名機関。john.doe@marketing.defence.acme.comは、「cn = domain-singe-authority、ou = defense、o = acme、c = us」の著名な名前を含む証明書を持つことができます。domain-singe-authority@defence.acme.com '。John DoeにRFC 2247の定義されたアドレスが「CN = John Doe、DC = Marketing、DC = Defense、DC = ACME、DC = US」のアドレスを持っている場合、ドメイン署名機関は 'CN = domain-SINGIBER-の著名な名前を持つことができます。権限、DC =防御、DC = ACME、DC = US '。
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.
存在する場合、[5]で定義されているように、SignAtureType属性は署名された属性でなければなりません。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.
オリジネータータイプを除くすべての署名タイプは、他の署名をカプセル化する必要があります。注DomSec定義の署名は、セクション3で定義されている空の署名をカプセル化する可能性があります。
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「追加の属性」が存在しない限り、属性の属性として異なるSIGNATURETYPE値の複数のインスタンスが含まれる場合があります[5]。
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の命名規則を遵守する必要があります。メッセージの「ドメイン署名」は、メッセージがそのドメインからリリースされたという事実を認証します。署名する前に、「ドメイン署名」を生成するプロセスは、最初にメッセージオリジネーターの信ity性について自らを満たす必要があります。これは、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.
Originator Signatureが存在する場合、その証明書の名前を使用して、オリジネーターを識別する必要があります。この情報は、受信者に表示できます。
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) セキュリティラベル：ラベル値は、内側のメッセージコンテンツの集合的な感度と、カプセル化された署名dataおよび封筒コンテナの集合性を示します。元のデータのラベルは、存在する場合、オリジネーターの署名の値によって示されます。
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.
「Originator Signature」は、署名者がメッセージとその内容の発信者であることを示すために使用されます。このドキュメントには、完全性のみが含まれています。オリジネーターの署名は、署名タイプの属性がないこと、または「署名タイプ」署名属性にID-STI-ORIGINATORIGの値が存在することによって示されます。
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.
この標準に準拠するクライアントの実装は、送信の場合（b）ケース（c）受信の場合はケース、および送信および受信の場合はケース（c）をサポートする必要があります。
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.500の著名な名前のX.509証明書の場合、ドメイン部分は、著名な名前の国、組織、組織単位、州、および地域コンポーネントです。
* 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.
たとえば、ACME CorporationのJohn Doeに代わって行動するDCA。.acme.comは、「cn = domain-confidentiality-authority、o = acme、c = us」の著名な名前を含む証明書と、「domain-confidentiality-authority@acme.com」の電子メールアドレスを含めることができます。John DoeにRFC 2247の定義されたアドレスが「CN = John Doe、DC = Marketing、DC = Defense、DC = ACME、DC = US」のアドレスを持っている場合、ドメイン署名機関は 'CN = domain-SINGIBER-の著名な名前を持つことができます。権限、DC =防御、DC = ACME、DC = US '。この証明書に関連付けられたキーは、John Doeのメッセージを暗号化するために使用されます。
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の証明書を正しく見つけることができなければなりません。正しい証明書を見つけた後、暗号化プロセスが実行され、復号化に必要な追加情報がCMSで指定されているように、ReciontientINFOフィールドの受信者に伝えられます[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: 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.
受信者のドメインに対応するDCAまたは最終受信者に対応するレシピエントに対応するDCAに証明書を配置するための特定の方法は、このドキュメントに義務付けられていません。実装は、正しい証明書を見つけるためにローカル証明書ストアにアクセスすることを選択できます。あるいは、X.500またはLDAPディレクトリを次のいずれかの方法で使用できます。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またはENDレシピエントのレシピエンティンフォーが生成されます。
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 Decryptionは、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]で説明されています。2番目のケースでは、暗号化プロセスは4.2で説明されています。
5. Applying a Domain Signature when Mail List Agents are Present.
5. メールリストのエージェントが存在するときにドメイン署名を適用します。
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で定義されているように、「外側」の署名dataレイヤーのメッセージを検索し、この「外側」のsigneddataレイヤーをカプセル化するすべての署名されたdataレイヤーを取り除きます。この「外側」の署名data層が見つかる場所は、メッセージにmlexpansionhistory属性または封筒層が含まれているかどうかによって異なります。
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ドメインを残すメッセージがMLAによってすでに処理されている可能性があります。この場合、メッセージ内に「MlexPansionHistory」属性が存在します。
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.
メッセージに封筒層が含まれる可能性があります。これは、メッセージがドメインの「ドメイン機密保持権限」のドメイン内で暗号化された場合に当てはまります。セクション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: -
「ドメイン署名」が適用される方法は、メッセージ内に既に存在するものによって異なります。「ドメイン署名」を適用する前に、メッセージを「外側」の署名dataレイヤーの検索する必要があります。この検索は、次のいずれかが見つかったときに完了します。
- 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属性を含むまたは封筒のオブジェクトをカプセル化する「外側」の署名Dataレイヤー。-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) SignedDataレイヤーを除去します（含まれているSignedattributesを覚えた後）。
2) Search the rest of the message until an envelopedData layer or the original content is found.
2) 封筒レイヤーまたは元のコンテンツが見つかるまで、メッセージの残りの部分を検索します。
3) a) If an envelopedData layer has been found then: -
3) a）封筒層が見つかった場合： -
- 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.
- すべてのsignedDataレイヤーを封筒レイヤーに除去します。 - ローカルDCAのReciontientInfoを見つけ、含まれる情報を使用してメッセージキーを取得します。 - メッセージキーを使用して暗号化されたコンテンントを復号化します。 - 「ドメイン署名」を使用して復号化されたメッセージをカプセル化します - ローカルポリシーがドメインを離れる前にs/mime暗号化を使用してメッセージを暗号化する必要がある場合、レシピエントのレシピエントinfo構造を含む封筒レイヤーを含む「ドメイン署名」をカプセル化します。このDCAを説明する情報から構築されたOriginatorInfo値。
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暗号化を使用して暗号化する必要がないが、メッセージ内の低レベルに封筒がある場合、「ドメイン署名」は上記のように封筒にカプセル化する必要があります。
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) 封筒層が見つかっていない場合： -
- 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) SignedDataレイヤーの新しいメッセージをカプセル化し、MlexPansionHistory属性を含むSignedDataレイヤーからSigneDattributesを追加します。
If no signedData layer containing a mlExpansionHistory attribute has been found but an envelopedData has been found then: -
mlexpansionhistory属性を含む署名dataレイヤーが見つかっていないが、その後封筒が見つかった場合： -
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) すべてのsignedDataレイヤーを封筒レイヤーに除去します。2）ローカルDCAのReciontientInfoを見つけ、含まれる情報を使用してメッセージキーを取得します。3）メッセージキーを使用して暗号化されたコンテンントを復号化します。4）「ドメイン署名」を使用して復号化されたメッセージをカプセル化する5）ローカルポリシーがドメインを離れる前にメッセージを暗号化する必要がある場合、各受信者のReciontIentInfo構造を含むEnvelopedDataレイヤーとOriginatorInToの値を含む「ドメイン署名」をカプセル化しますこの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暗号化を使用して暗号化する必要がないが、メッセージ内の低レベルに封筒がある場合、「ドメイン署名」は上記のように封筒にカプセル化する必要があります。
If no signedData layer containing a mlExpansionHistory attribute has been found and no envelopedData has been found then: -
mlexpansionhistory属性を含む署名dataレイヤーが見つかっていない場合、その後封筒は見つかりませんでした： -
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オブジェクトがドメイン署名である場合、さらに署名されたオブジェクトを検証する必要はありません。
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は検証されています。元のコンテンツが見つかったため、上記で定義したように検索した後、「外側」の署名dataは見つかりません。「ドメイン署名」を含む新しい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))).
2) SignedDataレイヤーにはMLEXPANSIONHISTORY属性が含まれていないメッセージ（S3（S2（S1（ORIGINAL CONTERS））））は、「ドメイン署名」を適用するためです。SignedDataオブジェクトS1、S2、S3は検証されています。元のコンテンツが見つかっているため、オリジナルの「外側の」署名されたレイヤーは、エンベロッドパンディオンヒストの属性が見つかりません。新しい署名dataレイヤーs4は、「ドメイン署名」を含む新しいsigneddataレイヤーが作成されているため、次のメッセージが送信されました。ドメイン（S4（S3（S2（S1（ORIGINAL CONTER）））。
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) S1にはMlexPansionHistory属性が含まれていないメッセージ（E1（S1（ORIGINAL CONTERT）））（E = EnvelopedData）は、「ドメイン署名」を適用することです。EnvelopedData、E1が外層に見られるため、オリジナルの「外側の」サインダタ層はありません。暗号化されたコンテンントが復号化されます。SignedData、S1は検証されています。復号化されたコンテンツは、「ドメイン署名」を含む新しいSignedDataレイヤーS2に包まれています。ローカルポリシーでs/mime暗号化を使用してメッセージを暗号化する必要がある場合、ドメインを離れる前に、この新しいメッセージは封筒レイヤーe2に包まれているため、ドメインから送信される次のメッセージが表示されます（e2（s1（s1）（元のコンテンツ））））、その他のメッセージは、次のメッセージ（S2（S1（元のコンテンツ）））が送信される封筒層に包まれていません。
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, 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.
4) S2がMlexPansionHistory属性を含むメッセージ（s2（s1（s1（original content））））は、「ドメイン署名」を適用することです。SignedDataオブジェクトS2が検証されています。MlexPansionHistory属性はS2に含まれているため、S2は「外側」の署名Dataです。S2の署名された属性は、メッセージに適用される新しい外側の署名dataに後で含めるために記憶されています。S2が剥奪され、メッセージが復号化されます。SignedDataオブジェクトS1が検証されています。復号化されたメッセージは、「ドメインの署名」を含むSignedDataレイヤーS3に包まれています。ローカルポリシーでは、S/MIME暗号化を使用してメッセージを暗号化する必要がある場合、ドメインを離れる前に、この新しいメッセージはEnvelopedDataレイヤーE2に包まれています。次に、新しいSignedDataレイヤーS4が封筒のE2に巻き付けられ、ドメインから送信される次のメッセージが表示されます（S4（E2（S3（S1（ORIGINATION CONTENT）））））））。ローカルポリシーでは、s/mime暗号化を使用してドメインを離れる前にメッセージを暗号化する必要がない場合、メッセージは封筒層に包まれず、新しいsigneddataレイヤーs4に包まれ、次のメッセージが送信されます。out out domain（s4（s1（s1（original content）。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) signedDataレイヤーが含まれていないmlexpansionhistory属性が「ドメイン署名」を適用するためのメッセージ（S3（s2（s1（s1（oringer content）））））））。SignedDataオブジェクトS3およびS2が検証されています。EnvelopedData E1が見つかると、SignedDataオブジェクトS3とS2が剥奪されます。暗号化されたコンテンントが復号化されます。SignedDataオブジェクトS1が検証されています。復号化されたコンテンツは、「ドメイン署名」を含む新しいSignedDataレイヤーS4に包まれています。ローカルポリシーでs/mime暗号化を使用してメッセージを暗号化する必要がある場合、ドメインを離れる前に、この新しいメッセージは封筒レイヤーe2にラップされ、ドメインから送信される次のメッセージが表示されます（e2（s1（s1）（元のコンテンツ））））、その他のメッセージは、次のメッセージ（S4（S1（元のコンテンツ）））が送信される封筒層に包まれていません。
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が含まれるmlexpansionhistory属性を含むメッセージ（S3（s2（s1（s1（original content））））））は、「ドメイン署名」を適用することです。SignedDataオブジェクトS3およびS2が検証されています。MlexPansionHistory属性はS3に含まれているため、S3は「外側」の署名Dataです。S3の署名された属性は、メッセージに適用される新しい外側の署名dataに後で含めるために記憶されています。SignedDataオブジェクトS3が剥がれます。EnvelopedData層のE1が見つかると、SignedDataオブジェクトS2が剥がれます。暗号化されたコンテンントが復号化されます。SignedDataオブジェクトS1が検証されています。復号化されたコンテンツは、「ドメイン署名」を含む新しいSignedDataレイヤーS4に包まれています。ローカルポリシーでは、S/MIME暗号化を使用してメッセージを暗号化する必要がある場合、ドメインを離れる前に、この新しいメッセージはEnvelopedDataレイヤーE2に包まれています。次に、新しいSignedDataレイヤーS5をEnvelopedData E2に巻き付けて、ドメインから送信された次のメッセージ（S5（E2（S4（S1（ORIGININCE CONTENT））））））になります。ローカルポリシーでは、s/mime暗号化を使用してドメインを離れる前にメッセージを暗号化する必要がない場合、メッセージは封筒層に包まれず、新しいsigneddataレイヤーs5に包まれています。out out domain（s5（s4（s1（original content）。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にはMlexPansionHistory属性が含まれていないメッセージ（s3（s2（s1（s1（s1 content）））））））は、「ドメイン署名」を適用することです。SignedDataオブジェクトS3が検証されています。EnvelopedData E2が見つかると、SignedDataオブジェクトS3が剥奪されます。暗号化されたコンテンントが復号化されます。SignedDataオブジェクトS2が検証され、EnvelopedData E1が復号化され、SignedDataオブジェクトS1が検証されます。SignedDataオブジェクトS2は、「ドメイン署名」を含む新しいSignedDataレイヤーS4に包まれています。メッセージには封筒E1が下にあるため、新しいメッセージは封筒レイヤーE3に包まれているため、次のメッセージがドメインから送信されます（E3（S4（S2（S1（ORIGINAL CONTER））））））。
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をサポートしていなくても、これらの名前に注意を払う必要があります。そのため、これらの名前で発行された証明書は正当なエンティティにのみ発行されます。これが当てはまらない場合、個人はdomain-confidentiality-authority@acme.comに関連付けられた証明書を取得でき、その結果、他の人向けのDomsecクライアントがメッセージを読み取ることができる可能性があります。
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) }
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.
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
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[3] Hoffman、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] International Telecommunications Union、推奨X.208、「オープンシステムの相互接続：抽象的構文表記の仕様（ASN.1）」、Ccitt Blue Book、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
Tim Dean Qinetiq St. Andrews Road Malvern Worcs WR14 3PS
Phone: +44 (0) 1684 894239
Fax: +44 (0) 1684 896660
EMail: tbdean@QinetiQ.com
William Ottaway QinetiQ St. Andrews Road Malvern Worcs WR14 3PS
ウィリアムオタウェイQinetiqセントアンドリュースロードマルバーンワークWR14 3PS
Phone: +44 (0) 1684 894079
Fax: +44 (0) 1684 896660
EMail: wjottaway@QinetiQ.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。