RFC3183 日本語訳

3183 Domain Security Services using S/MIME. T. Dean, W. Ottaway. October 2001. (Format: TXT=57129 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                            T. Dean
Request for Comments: 3183                                    W. Ottaway
Category: Experimental                                           QinetiQ
                                                            October 2001

コメントを求めるワーキンググループT.ディーンの要求をネットワークでつないでください: 3183年のW.Ottawayカテゴリ: 実験的なQinetiQ2001年10月

                 Domain Security Services using S/MIME

S/MIMEを使用するドメインセキュリティー・サービス

Status of this Memo

この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.

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(安全な/マルチパーパスインターネットメールエクステンション)プロトコルが通信系のメッセージ転送エージェントや、番人やゲートウェイなどの多くの部品によってどう処理されて、生成されるか、そして、セキュリティー・サービスを提供できるのと説明します。これらのサービスは'ドメインSecurity Services'とまとめて呼ばれます。

Acknowledgements

承認

   Significant comments were made by Luis Barriga, Greg Colla, Trevor
   Freeman, Russ Housley, Dave Kemp, Jim Schaad and Michael Zolotarev.

重要なコメントはルイスBarriga、グレッグ・コーラ、トレバー・フリーマン、ラスHousley、デーヴ・ケンプ、ジムSchaad、およびマイケル・ゾロタリョフによってされました。

1. Introduction

1. 序論

   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

本書では説明されたメカニズムは多くの相互運用性問題を解決するように設計されています、そして、異なったセキュリティー領域であるときに起こる技術的な制限は2つのドメインがいつX.400シリーズやSMTP/MIMEなどの両立しないメッセージング技術を使用したがっているか、そして、または単一領域がいつしっかりと信頼されていないドメインに住んでいるメンバーのひとりとコミュニケートしたがっているかをしっかりと、例えば伝えたがっています。このドキュメントでカバーされたシナリオは、ドメインからドメインと、個人からドメインとドメインから個人です。

Dean & Ottaway                Experimental                      [Page 1]

RFC 3183         Domain Security Services using S/MIME      October 2001

2001年10月にS/MIMEを使用するディーンとOttawayの実験的な[1ページ]RFC3183ドメインセキュリティー・サービス

   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.

コミュニケーション。また、このドキュメントも外の世界でアクセスしやすくない内部のPKIsを持っている組織と企業に適切ですが、しっかりと共同利用することを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) 異種のメッセージアクセス法: ウェブブラウザを使用などなどのメッセージを再フォーマットするメカニズムを使用することでユーザはメールにアクセスしています。 Messageストアで再フォーマットされるメッセージで、終わりまでの終わりの暗号化と署名合法化は不可能になります。

   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.

また、地理的にリモートであり、暗号化されたそして/または、署名しているメッセージをそれらのベースと交換したがっている会社の個人会員はドメインサービスを利用できます。

Dean & Ottaway                Experimental                      [Page 2]

RFC 3183         Domain Security Services using S/MIME      October 2001

2001年10月にS/MIMEを使用するディーンとOttawayの実験的な[2ページ]RFC3183ドメインセキュリティー・サービス

   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.

ドメインがサービスを基礎づけたかどうかが、本来より良いか、デスクトップがソリューションを基礎づけたより悪いのは、未決問題です。何人かの専門家が、本当に終わりから終わりへのソリューションしか安全にすることができないと信じています、ドメイン境界でチェックする内容が多くの実システム許容の追加サービスのために実用的なセキュリティのかなりの増加を提供するとき、他のものは、利益がそのようなものでものを提供したと信じていますが、また、コミュニケーション経路の数ポイントでチェックする署名は多くの状況で付加的な利益です。このドキュメントの範囲の外にこの討論はあります。ここに提供されるものはインテグレーターが異なった事情の異なった需要を満たす異なった方法で合わせることができる1セットのツールです。

   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.

メッセージ転送エージェント(MTAs)、番人、ファイアウォール、およびプロトコル変換ゲートウェイはすべて、ドメインセキュリティー・サービスを提供します。デスクトップに基づいているソリューションなら、これらのコンポーネントはセキュリティー・サービスを打倒することを意図するさまざまな攻撃に対して弾力があるに違いありません。したがって、これらのコンポーネントのセキュリティに熟慮を与えるべきであり、確実にそれをそれらの位置するのと構成にするのは攻撃の可能性を最小とならせます。

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[2]で説明されるように本書では解釈されることであるべきですか?

2. Overview of Domain Security Services

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と呼ばれた定義された署名を定義しました。

Dean & Ottaway                Experimental                      [Page 3]

RFC 3183         Domain Security Services using S/MIME      October 2001

2001年10月にS/MIMEを使用するディーンとOttawayの実験的な[3ページ]RFC3183ドメインセキュリティー・サービス

   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つの例が組織的なネットワーク('イントラネット')です。

2.1 Domain Signature

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".

ドメイン署名はドメインの1セットのユーザを代表して生成されたS/MIME署名です。 2'イントラネット'がインターネットを使用することで接続されているか、またはイントラネットがインターネットの上のリモート・ユーザーに接されるとき例えばドメインの間、または、ある一定のドメインと個人のひとりの間に送られた情報を認証するのにドメイン署名を使用できます。 2つのドメインが内部的に両立しない署名体系を使うか、またはそれらのPKIsの間に証明リンクが全くないとき、それを使用できます。どちらの場合も、創始者のドメインからのメッセージは、受取人か受取人ドメインで処理できるアルゴリズム、キー、および証明書を使用することでオリジナルのメッセージと署名の上で署名されるのと(現在。)です。ドメイン署名は時々「組織的な署名」と呼ばれます。

2.2 Review Signature

2.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署名はそれに加えられます--レビュー署名。エージェントは、見直されたメッセージだけが発表されるのを保証するためにドメイン境界でレビュー署名をチェックできました。

2.3 Additional Attributes Signature

2.3 追加属性署名

   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]で定義された'同等なLabel'属性です。

Dean & Ottaway                Experimental                      [Page 4]

RFC 3183         Domain Security Services using S/MIME      October 2001

2001年10月にS/MIMEを使用するディーンとOttawayの実験的な[4ページ]RFC3183ドメインセキュリティー・サービス

2.4 Domain Encryption and Decryption

2.4 ドメイン暗号化と復号化

   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'イントラネット'がインターネットを使用することで接続されているとき、例えば、ドメインの間の情報を保護するのにドメイン暗号化を使用できます。雇用両立しない2つのドメインであるときに、また、エンドユーザがデスクトップにPKI/暗号化能力を持っていないと、それを使用できますか、または暗号化は内部的に計画されます。それらのドメインのアルゴリズムを使用することで暗号化された(または、再暗号化されます)創始者のドメインからの後者のケースメッセージか、キーと、受取人が解読することができる証明書か実体で。また、この体系は両方が信頼されていないネットワークを使用することで接続されているとき単一領域とメンバーのひとりの間の情報を保護するのに適用されます、例えば、インターネット。

3. Mapping of the Signature Services to the S/MIME Protocol

3. S/MIMEプロトコルに対する署名サービスのマッピング

   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]は最初に、署名されて、次に、暗号化されて、次に再び署名される3倍包装されたメッセージの概念を紹介します。また、このドキュメントは三重のラッピングのこの概念を使用します。また、さらに、このドキュメントは'署名カプセル化'の概念を使用します。 '署名カプセル化'は署名で包装される署名しているか未署名のメッセージを指示します、この署名が内容と最初の(内側)の署名の両方をカバーしていて、存在しているなら。

   Signature encapsulation MAY be performed on the inner and/or the
   outer signature of a triple-wrapped message.

署名カプセル化は3倍包装されたメッセージの内側の署名、そして/または、外側の署名に実行されるかもしれません。

   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:

定義された署名が以下の方法の1つでメッセージをカプセル化するかもしれない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

1) 未署名のメッセージで、空の署名層をそれに加えます(すなわち、メッセージは要素を全く含まないsignerInfosを持っているsignedDataで包装されます)。これは、DOMSEC能力を持っていないS/MIMEソフトウェアとの後方の互換性を可能にするためのものです。 signerInfosが署名者を全く含まないので

Dean & Ottaway                Experimental                      [Page 5]

RFC 3183         Domain Security Services using S/MIME      October 2001

2001年10月にS/MIMEを使用するディーンとOttawayの実験的な[5ページ]RFC3183ドメインセキュリティー・サービス

      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.

eContentTypeはCMS[5]で説明されるようにEncapsulatedContentInfoの中でイドデータであるに違いありません。しかしながら、eContent分野は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) 署名Encapsulationは包装に使用されて、DOMSECがあるオリジナルの署名しているメッセージが署名を定義したということです。これがそうであるので、DOMSECが署名を定義したのがメッセージとすべての以前に加えられた署名を含んでいます。また、DOMSECが署名を定義したことを決定するのが既にそこにある署名の後に加えられたのも、可能です。

3.1 Naming Conventions and Signature Types

3.1 コンベンションと署名タイプを命名すること。

   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.

これが、状態SHOULDが、ある状況で抑圧されると警告して、セキュリティが修理するドメインの場合で。これらの事情はSHOULDという署名者名が固く守るフォームを指定する命名規則によって定義されます。この命名規則への固守はこれが起こす非制御の命名と可能な仮面舞踏会攻撃の問題を避けます。

   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.

この規格に従う実装は署名世代と検証のために命名規則をサポートしなければなりません。この規格に従う実装は署名照合として署名タイプ属性を認識しなければなりません。この規格に従う実装は署名世代のために署名タイプ属性をサポートしなければなりません。

Dean & Ottaway                Experimental                      [Page 6]

RFC 3183         Domain Security Services using S/MIME      October 2001

2001年10月にS/MIMEを使用するディーンとOttawayの実験的な[6ページ]RFC3183ドメインセキュリティー・サービス

3.1.1 Naming Conventions

3.1.1 命名規則

   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)'コンポーネントとして現れるものとします。 1つの存在しているCNの部品しかないに違いありません。さらに、証明書がRFC822アドレスを含んでいるなら、この名前は'@'シンボルの左側にアドレスの終わりの実体の部品に載っているものとします。

   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.509証明書のX.500の顕著な対象の名の場合では、ドメイン部分は、分類名の国と、組織と、組織的なユニットと、州と、場所コンポーネントです。

   *  In the case of an RFC 2247 distinguished name, the domain part is
      the domain components of the distinguished name.

* RFC2247分類名の場合では、ドメイン部分は分類名のドメインコンポーネントです。

   *  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.

* 証明書がRFC822アドレスを含んでいるなら、ドメイン部分は、'@'シンボルの右側の上のRFC822アドレス構成要素になるように定義されます。

   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

例えば、分類名が'cnはジョン・ドウと等しいです、ou=マーケティング、o=頂上、c=私たち'であり、Eメールアドレスが John.Doe@marketing.acme.com であるAcme会社のジョン・ドウを代表して行動するドメイン署名権威は'cnがドメインに署名する権威と等しいです、o=頂上、c=私たち'の分類名と' domain-signing-authority@acme.com 'のRFC822アドレスを含む証明書を持っているかもしれません。ジョン・ドウがRFC2247を持っているなら

Dean & Ottaway                Experimental                      [Page 7]

RFC 3183         Domain Security Services using S/MIME      October 2001

2001年10月にS/MIMEを使用するディーンとOttawayの実験的な[7ページ]RFC3183ドメインセキュリティー・サービス

   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に私たちと等しいこと'が使用されているかもしれない'cn=ジョン・ドウ、dc=マーケティング、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.

最も重要なコンポーネント(すなわち、国、場所または組織を代表する'dc'エントリー)からRFC2247の対象の名を分析するとき、分析された'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=頂上、c=私たち'であり、Eメールアドレスが John.Doe@marketing.defence.acme.com であるAcme会社のジョン・ドウを代表して行動するドメイン署名権威は'cnがドメインに署名する権威と等しいです、ou=ディフェンス、o=頂上、c=私たち'の分類名と'ドメイン signing-authority@defence.acme.com 'のRFC822アドレスを含む証明書を持っているかもしれません。ジョン・ドウに'cnはジョン・ドウと等しいです、dc=マーケティング、dc=ディフェンス、dc=頂上、dc=私たち'のRFC2247の定義されたアドレスがあるなら、ドメイン署名権威には、'cnはドメインに署名する権威と等しいです、dc=ディフェンス、dc=頂上、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.

この命名規則は別のものを代表してドメイン署名当局のふりをする1つの組織からエージェントを防ぎます。本書では定義された他のタイプの署名において、そのようなどんな命名された配置規則も定義されません。

   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.

署名について確かめると、受信エージェントは、命名規則が固く守られたのを保証しなければなりません。コンベンションに違反するどんなメッセージにも旗を揚げさせなければなりません。

Dean & Ottaway                Experimental                      [Page 8]

RFC 3183         Domain Security Services using S/MIME      October 2001

2001年10月にS/MIMEを使用するディーンとOttawayの実験的な[8ページ]RFC3183ドメインセキュリティー・サービス

3.1.2 Signature Type Attribute

3.1.2 署名タイプ属性

   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

SignatureType:、:= オブジェクト識別子の系列

      id-sti  OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
                  rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 9 }

イド-sti OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(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属性が欠けていて、これ以上カプセル化されなかった署名があれば、受取人SHOULDは、署名がメッセージ創始者のものであると仮定します。

   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.

イド-sti-domainSigオブジェクト識別子:、:= イド-sti2--ドメイン署名。

      id-sti-addAttribSig OBJECT IDENTIFIER ::= { id-sti 3 }
      -- additional attributes signature.

イド-sti-addAttribSigオブジェクト識別子:、:= イド-sti3--追加属性署名。

      id-sti-reviewSig OBJECT IDENTIFIER ::= { id-sti 4 }
      -- review signature.

イド-sti-reviewSigオブジェクト識別子:、:= イド-sti4--署名を見直してください。

   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.

イド-sti-originatorSigオブジェクト識別子:、:= イド-sti1--創始者の署名。

   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が要約が空の署名であったかもしれないなら署名を定義したことに注意してください。

Dean & Ottaway                Experimental                      [Page 9]

RFC 3183         Domain Security Services using S/MIME      October 2001

2001年10月にS/MIMEを使用するディーンとOttawayの実験的な[9ページ]RFC3183ドメインセキュリティー・サービス

   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を表す署名している属性はattrValues[5]のAttributeValueとして異なったSignatureType値の複数のインスタンスを含むかもしれません、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.

1SignerInfoがsignerInfosにあれば(すなわち、異なったアルゴリズムはいつ使用されていますか)、すべてのSignerInfosのSignatureType属性は同じ内容を含まなければなりません。

   The following sections describe the conditions under which each of
   these types of signature may be generated, and how they are
   processed.

以下のセクションはそれぞれのこれらのタイプの署名が生成されるかもしれない状態と、彼らがどう処理されるかを説明します。

3.2 Domain Signature Generation and Verification

3.2 ドメイン署名世代と検証

   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つのメソッドの1つで達成されます。 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.

'ドメイン署名'が加えられて、メッセージがメールListエージェント(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.

創始者の信憑性が首尾よく確かめられないか、または署名が提示するすべてが有効であるというわけではないなら、'ドメイン署名'を生成してはいけません。

Dean & Ottaway                Experimental                     [Page 10]

RFC 3183         Domain Security Services using S/MIME      October 2001

2001年10月にS/MIMEを使用するディーンとOttawayの実験的な[10ページ]RFC3183ドメインセキュリティー・サービス

   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.

レセプション、'ドメイン署名'SHOULD、使用されて、メッセージの信憑性について確かめてください。命名規則とコンベンションを写像する名前の両方がこの規格で指定されるように使用されたのを保証するのをチェックをしなければなりません。

   A recipient can assume that successful verification of the domain
   signature also authenticates the message originator.

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 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.

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.

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.

The 'domain signature' is indicated by the presence of the value id- sti-domainSig in a 'signature type' signed attribute.

   There MAY be one or more 'domain signature' signatures in an S/MIME
   encoding.

There MAY be one or more 'domain signature' signatures in an S/MIME encoding.

3.3 Additional Attributes Signature Generation and Verification

3.3 Additional Attributes Signature Generation and Verification

   The 'additional attributes' signature type indicates that the
   SignerInfo contains additional attributes that are associated with
   the message.

The 'additional attributes' signature type indicates that the SignerInfo contains additional attributes that are associated with the message.

   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.

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.

   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.

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.

Dean & Ottaway                Experimental                     [Page 11]

RFC 3183         Domain Security Services using S/MIME      October 2001

Dean & Ottaway Experimental [Page 11] RFC 3183 Domain Security Services using S/MIME October 2001

   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:

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:

   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) Equivalent Label: label values in this attribute are to be treated as equivalent to the security label contained in an encapsulated SignerInfo, if present.

   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) 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.

   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.

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.

   There MAY be multiple 'additional attributes' signatures in an S/MIME
   encoding.

There MAY be multiple 'additional attributes' signatures in an S/MIME encoding.

3.4 Review Signature Generation and Verification

3.4 Review Signature Generation and Verification

   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.

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.

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.

   A review signature is indicated by the presence of the value id-sti-
   reviewSig in a 'signature type' signed attribute.

A review signature is indicated by the presence of the value id-sti- reviewSig in a 'signature type' signed attribute.

   There MAY be multiple review signatures in an S/MIME encoding.

There MAY be multiple review signatures in an S/MIME encoding.

Dean & Ottaway                Experimental                     [Page 12]

RFC 3183         Domain Security Services using S/MIME      October 2001

Dean & Ottaway Experimental [Page 12] RFC 3183 Domain Security Services using S/MIME October 2001

3.5 Originator Signature

3.5 Originator Signature

   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.

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.

4. Encryption and Decryption

4. Encryption and Decryption

   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.

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.

   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.

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.

 --------------------------------------------------------------------
|                        | Recipient Decryption |  Domain Decryption |
|------------------------|----------------------|--------------------|
| Originator Encryption  |       Case(a)        |       Case(b)      |
| Domain Encryption      |       Case(c)        |       Case(d)      |
 --------------------------------------------------------------------

-------------------------------------------------------------------- | | 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.

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 client implementation that conforms to this standard MUST support
   case (b) for transmission, case (c) for reception and case (a) for
   transmission and reception.

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.

Dean & Ottaway                Experimental                     [Page 13]

RFC 3183         Domain Security Services using S/MIME      October 2001

Dean & Ottaway Experimental [Page 13] RFC 3183 Domain Security Services using S/MIME October 2001

   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.

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.

   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.

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.

   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.

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.

   The mechanisms below are also applicable to individual roving users
   who wish to encrypt messages that are sent back to base.

The mechanisms below are also applicable to individual roving users who wish to encrypt messages that are sent back to base.

4.1 Domain Confidentiality Naming Conventions

4.1 Domain Confidentiality Naming Conventions

   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.

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.

   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:

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:

   *  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.

* 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.

   * In the case of an RFC 2247 distinguished name, the domain part is
      the domain components of the distinguished name.

* In the case of an RFC 2247 distinguished name, the domain part is the domain components of the distinguished name.

   * 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.

* 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.

Dean & Ottaway                Experimental                     [Page 14]

RFC 3183         Domain Security Services using S/MIME      October 2001

Dean & Ottaway Experimental [Page 14] RFC 3183 Domain Security Services using S/MIME October 2001

   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.

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.

   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.

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.

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.

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.

4.2 Key Management for DCA Encryption

4.2 Key Management for DCA Encryption

   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.

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.

   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:

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:

Dean & Ottaway                Experimental                     [Page 15]

RFC 3183         Domain Security Services using S/MIME      October 2001

Dean & Ottaway Experimental [Page 15] RFC 3183 Domain Security Services using S/MIME October 2001

   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. The directory may store the DCA certificate in the recipient's directory entry. When the user certificate attribute is requested, this certificate is returned.

   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. 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.

   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.

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].

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].

   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 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.

4.3 Key Management for DCA Decryption

4.3 Key Management for DCA Decryption

   DCA decryption uses a private-key belonging to the DCA and the
   necessary information conveyed in the DCA's recipientInfo field.

DCA decryption uses a private-key belonging to the DCA and the necessary information conveyed in the DCA's recipientInfo field.

   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.

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.

5. Applying a Domain Signature when Mail List Agents are Present.

5. Applying a Domain Signature when Mail List Agents are Present.

   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.

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.

   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.

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.

Dean & Ottaway                Experimental                     [Page 16]

RFC 3183         Domain Security Services using S/MIME      October 2001

Dean & Ottaway Experimental [Page 16] RFC 3183 Domain Security Services using S/MIME October 2001

   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.

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.

   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.

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.

   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: -

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: -

      -  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).

- 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).

   If a signedData layer containing a mlExpansionHistory attribute has
   been found then: -

If a signedData layer containing a mlExpansionHistory attribute has been found then: -

      1) Strip off the signedData layer (after remembering the included
         signedAttributes).

1) Strip off the signedData layer (after remembering the included signedAttributes).

      2) Search the rest of the message until an envelopedData layer or
         the original content is found.

2) Search the rest of the message until an envelopedData layer or the original content is found.

      3) a) If an envelopedData layer has been found then: -

3) a) If an envelopedData layer has been found then: -

            -  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.

- 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.

Dean & Ottaway                Experimental                     [Page 17]

RFC 3183         Domain Security Services using S/MIME      October 2001

Dean & Ottaway Experimental [Page 17] RFC 3183 Domain Security Services using S/MIME October 2001

               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.

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.

               An example when it may not be local policy to require
               S/MIME encryption is when there is a link crypto present.

An example when it may not be local policy to require S/MIME encryption is when there is a link crypto present.

      b) If an envelopedData layer has not been found then: -

b) If an envelopedData layer has not been found then: -

            -  Encapsulate the new message with a 'domain signature'.

- 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) Encapsulate the new message in a signedData layer, adding the signedAttributes from the signedData layer that contained the mlExpansionHistory attribute.

   If no signedData layer containing a mlExpansionHistory attribute has
   been found but an envelopedData has been found then: -

If no signedData layer containing a mlExpansionHistory attribute has been found but an envelopedData has been found then: -

      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) 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.

         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.

   If no signedData layer containing a mlExpansionHistory attribute has
   been found and no envelopedData has been found then: -

If no signedData layer containing a mlExpansionHistory attribute has been found and no envelopedData has been found then: -

      1) Encapsulate the message in a 'domain signature'.

1) Encapsulate the message in a 'domain signature'.

5.1 Examples of Rule Processing

5.1 Examples of Rule Processing

   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.

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.

Dean & Ottaway                Experimental                     [Page 18]

RFC 3183         Domain Security Services using S/MIME      October 2001

Dean & Ottaway Experimental [Page 18] RFC 3183 Domain Security Services using S/MIME October 2001

   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) 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))).

   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) 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))).

   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) 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.

   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) 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,

Dean & Ottaway                Experimental                     [Page 19]

RFC 3183         Domain Security Services using S/MIME      October 2001

Dean & Ottaway Experimental [Page 19] RFC 3183 Domain Security Services using S/MIME October 2001

      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, 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.

   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) 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.

   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(1E(S1(オリジナルのContent)))))は'ドメイン署名'を適用させることです。 signedDataオブジェクトのS3とS2は確かめられます。 mlExpansionHistory属性がS3で見つけられるので、S3は「外側」のsignedDataです。 S3の署名している属性はメッセージに適用される新しい外側のsignedDataでの後の包含のために覚えていられます。 signedDataオブジェクトS3は全部はぎ取られます。 1EであるenvelopedData層が見つけられるとき、signedDataオブジェクトS2は全部はぎ取られます。 encryptedContentは解読されます。 signedDataオブジェクトS1は確かめられます。解読された内容は新しいsignedData層、S4で包装されます。(S4は'ドメイン署名'を含みます)。ローカルの方針が暗号化されるべきメッセージを必要とするなら、S/MIMEを使用して、次に、この新しいメッセージにドメインを出る前の暗号化はenvelopedData層の中で包装されます、2Eです。次に、新しいsignedData層(S5)はenvelopedDataに巻きつけられます、2Eです、ドメイン(S5(2E(S4(S1(オリジナルのContent)))))から送られた以下のメッセージをもたらして。 S/MIMEを使用して、ローカルの方針が暗号化されるべきメッセージを必要としないなら、次に、メッセージにドメインを出る前の暗号化は、envelopedData層の中で包装されませんが、新しいsignedData層の中で包装されます、S5、ドメインから送られた以下のメッセージをもたらして(S5、(S4、(S1(オリジナルのContent)signedData S5はどちらの場合も、S3からの署名している属性を含みます。

Dean & Ottaway                Experimental                     [Page 20]

RFC 3183         Domain Security Services using S/MIME      October 2001

2001年10月にS/MIMEを使用するディーンとOttawayの実験的な[20ページ]RFC3183ドメインセキュリティー・サービス

   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(2E(S2(1E(S1(オリジナルのContent))))))は'ドメイン署名'を適用させることです。 signedDataオブジェクトS3は確かめられます。 envelopedData E2が見つけられるとき、signedDataオブジェクトS3は全部はぎ取られます。 encryptedContentは解読されます。 signedDataオブジェクトS2は確かめられます、そして、envelopedData E1は解読されます、そして、signedDataオブジェクトS1は確かめられます。 signedDataオブジェクトS2はS4の新しいsignedData層の中で包装されます。層は'ドメイン署名'を含みます。メッセージにはenvelopedDataの1Eのロワー・ダウンがあるので、新しいメッセージはenvelopedData層の中で包装されます、3Eです、ドメイン(3E(S4(S2(1E(S1(オリジナルのContent))))))から送られた以下のメッセージをもたらして。

6. Security Considerations

6. セキュリティ問題

   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 に関連づけさせることができて、その結果他のもののために意図するa 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.

メッセージがエンドユーザDCAによって解読されるような方法で暗号化されたDOMSECメッセージをエンドユーザに送るとき、メッセージがプレーンテキストにあるでしょう、そして、したがって、秘密性に感染することができました。

Dean & Ottaway                Experimental                     [Page 21]

RFC 3183         Domain Security Services using S/MIME      October 2001

2001年10月にS/MIMEを使用するディーンとOttawayの実験的な[21ページ]RFC3183ドメインセキュリティー・サービス

   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が正しくメッセージの署名について確かめても、メッセージはundetectablyに変更されるかもしれません、署名が全く受取人が確かめることができるメッセージにないとき。

7. DOMSEC ASN.1 Module

7. DOMSEC ASN.1モジュール

   DOMSECSyntax
    { iso(1) member-body(2) us(840) rsadsi(113549)
          pkcs(1) pkcs-9(9) smime(16) modules(0) domsec(10) }

DOMSECSyntaxiso(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.

-- このモジュールで定義されたタイプと値のためにエクスポートされるというEXPORTS Allはもう片方のASNで.1のモジュールを使用します。他のアプリケーションは使用されるかもしれません--それら自身の目的のためのそれら。

    SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER

SignatureType:、:= オブジェクト識別子の系列

    id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

イド-smime OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9)16をメンバーと同じくらい具体化させます。

    id-sti  OBJECT IDENTIFIER ::= { id-smime 9 }   -- signature type
    identifier

イド-sti OBJECT IDENTIFIER:、:= イド-smime9--署名タイプ識別子

    -- 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 }

イド-sti-originatorSigオブジェクト識別子:、:= イド-sti1、イド-sti-domainSig OBJECT IDENTIFIER:、:= イド-sti2、イド-sti-addAttribSig OBJECT IDENTIFIER:、:= イド-sti3、イド-sti-reviewSig OBJECT IDENTIFIER:、:= イド-sti4

    END -- of DOMSECSyntax

終わり--DOMSECSyntaxについて

Dean & Ottaway                Experimental                     [Page 22]

RFC 3183         Domain Security Services using S/MIME      October 2001

2001年10月にS/MIMEを使用するディーンとOttawayの実験的な[22ページ]RFC3183ドメインセキュリティー・サービス

8. References

8. 参照

   [1] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633,
       June 1999.

[1]Ramsdell、B.、「S/MIMEバージョン3メッセージ仕様」、RFC2633、1999年6月。

   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [3] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634,
       June 1999.

[3] ホフマン、P.、「S/MIMEのための警備の強化サービス」、RFC2634、1999年6月。

   [4] International Telecommunications Union, Recommendation X.208,
       "Open systems interconnection: specification of Abstract Syntax
       Notation (ASN.1)", CCITT Blue Book, 1989.

[4] 国際Telecommunications Union、Recommendation X.208、「開放型システム間相互接続:」「抽象的なSyntax Notation(ASN.1)の仕様」、CCITT Blue Book、1989。

   [5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.

[5]Housley、R.、「暗号のメッセージ構文」、RFC2630、1999年6月。

9. Authors' Addresses

9. 作者のアドレス

   Tim Dean
   QinetiQ
   St. Andrews Road
   Malvern
   Worcs
   WR14 3PS

ティムディーンQinetiQセント・アンドリューズ道路マルバーンWorcs WR14 3PS

   Phone: +44 (0) 1684 894239
   Fax:   +44 (0) 1684 896660
   EMail: tbdean@QinetiQ.com

以下に電話をしてください。 +44 (0)1684 894239Fax: +44 (0) 1684 896660はメールされます: tbdean@QinetiQ.com

   William Ottaway
   QinetiQ
   St. Andrews Road
   Malvern
   Worcs
   WR14 3PS

ウィリアムOttaway QinetiQセント・アンドリューズ道路マルバーンWorcs WR14 3PS

   Phone: +44 (0) 1684 894079
   Fax:   +44 (0) 1684 896660
   EMail: wjottaway@QinetiQ.com

以下に電話をしてください。 +44 (0)1684 894079Fax: +44 (0) 1684 896660はメールされます: wjottaway@QinetiQ.com

Dean & Ottaway                Experimental                     [Page 23]

RFC 3183         Domain Security Services using S/MIME      October 2001

2001年10月にS/MIMEを使用するディーンとOttawayの実験的な[23ページ]RFC3183ドメインセキュリティー・サービス

10.  Full Copyright Statement

10. 完全な著作権宣言文

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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機能のための基金は現在、インターネット協会によって提供されます。

Dean & Ottaway                Experimental                     [Page 24]

ディーンとOttaway実験的です。[24ページ]

一覧

RFC 1～100	RFC 1401～1500	RFC 2801～2900	RFC 4201～4300
RFC 101～200	RFC 1501～1600	RFC 2901～3000	RFC 4301～4400
RFC 201～300	RFC 1601～1700	RFC 3001～3100	RFC 4401～4500
RFC 301～400	RFC 1701～1800	RFC 3101～3200	RFC 4501～4600
RFC 401～500	RFC 1801～1900	RFC 3201～3300	RFC 4601～4700
RFC 501～600	RFC 1901～2000	RFC 3301～3400	RFC 4701～4800
RFC 601～700	RFC 2001～2100	RFC 3401～3500	RFC 4801～4900
RFC 701～800	RFC 2101～2200	RFC 3501～3600	RFC 4901～5000
RFC 801～900	RFC 2201～2300	RFC 3601～3700	RFC 5001～5100
RFC 901～1000	RFC 2301～2400	RFC 3701～3800	RFC 5101～5200
RFC 1001～1100	RFC 2401～2500	RFC 3801～3900	RFC 5201～5300
RFC 1101～1200	RFC 2501～2600	RFC 3901～4000	RFC 5301～5400
RFC 1201～1300	RFC 2601～2700	RFC 4001～4100	RFC 5401～5500
RFC 1301～1400	RFC 2701～2800	RFC 4101～4200

RFC3183 日本語訳

一覧

リンク

メニュー

コメント

お問い合わせ

プライバシーポリシー