RFC 7817 - Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7817
タイトル : RFC 7817 - 電子メール関連プロトコルの更新されたトランスポート層セキュリティ（TLS）サーバーIDチェック手順
翻訳編集 : 自動生成

[要約] 要約：RFC 7817は、電子メール関連プロトコルにおけるTransport Layer Security（TLS）サーバーの識別チェック手順を更新するものである。目的：このRFCの目的は、電子メール関連プロトコルにおけるTLSサーバーの識別チェック手順を改善し、セキュリティを向上させることである。

Internet Engineering Task Force (IETF)                       A. Melnikov
Request for Comments: 7817                                     Isode Ltd
Updates: 2595, 3207, 3501, 5804                               March 2016
Category: Standards Track
ISSN: 2070-1721

Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols

電子メール関連プロトコルの更新されたトランスポート層セキュリティ（TLS）サーバーIDチェック手順

Abstract

概要

This document describes the Transport Layer Security (TLS) server identity verification procedure for SMTP Submission, IMAP, POP, and ManageSieve clients. It replaces Section 2.4 (Server Identity Check) of RFC 2595 and updates Section 4.1 (Processing After the STARTTLS Command) of RFC 3207, Section 11.1 (STARTTLS Security Considerations) of RFC 3501, and Section 2.2.1 (Server Identity Check) of RFC 5804.

このドキュメントでは、SMTP送信、IMAP、POP、およびManageSieveクライアントのトランスポート層セキュリティ（TLS）サーバーID検証手順について説明します。これは、RFC 2595のセクション2.4（サーバーIDチェック）に置き換わり、RFC 3207のセクション4.1（STARTTLSコマンド後の処理）、RFC 3501のセクション11.1（STARTTLSセキュリティに関する考慮事項）、およびRFCのセクション2.2.1（サーバーIDチェック）を更新します。 5804。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7817.

このドキュメントの現在の状態、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7817で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
   3.  Email Server Certificate Verification Rules . . . . . . . . .   3
   4.  Compliance Checklist for Certification Authorities  . . . . .   5
     4.1.  Notes on Handling of Delegated Email Services by
           Certification Authorities . . . . . . . . . . . . . . . .   5
   5.  Compliance Checklist for Mail Service Providers and
       Certificate Signing Request Generation Tools  . . . . . . . .   6
     5.1.  Notes on Hosting Multiple Domains . . . . . . . . . . . .   7
   6.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Operational Considerations  . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  Changes to RFCs 2595, 3207, 3501, and 5804 . . . . .  12
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

1. Introduction

1. はじめに

Use of TLS by SMTP Submission, IMAP, POP, and ManageSieve clients is described in [RFC3207], [RFC3501], [RFC2595], and [RFC5804], respectively. Each of the documents describes slightly different rules for server certificate identity verification (or doesn't define any rules at all). In reality, email client and server developers implement many of these protocols at the same time, so it would be good to define modern and consistent rules for verifying email server identities using TLS.

SMTP送信、IMAP、POP、およびManageSieveクライアントによるTLSの使用については、それぞれ[RFC3207]、[RFC3501]、[RFC2595]、および[RFC5804]で説明されています。各ドキュメントには、サーバー証明書のID検証に関するわずかに異なるルールが記載されています（またはルールがまったく定義されていません）。実際には、メールクライアントとサーバーの開発者はこれらのプロトコルの多くを同時に実装しているため、TLSを使用してメールサーバーのIDを検証するための最新の一貫したルールを定義することをお勧めします。

This document describes the updated TLS server identity verification procedure for SMTP Submission [RFC6409] [RFC3207], IMAP [RFC3501], POP [RFC1939], and ManageSieve [RFC5804] clients. Section 3 of this document replaces Section 2.4 of [RFC2595].

このドキュメントでは、SMTP送信[RFC6409] [RFC3207]、IMAP [RFC3501]、POP [RFC1939]、およびManageSieve [RFC5804]クライアントの更新されたTLSサーバーID検証手順について説明します。このドキュメントのセクション3は、[RFC2595]のセクション2.4に代わるものです。

Note that this document doesn't apply to use of TLS in MTA-to-MTA SMTP.

このドキュメントは、MTA-to-MTA SMTPでのTLSの使用には適用されないことに注意してください。

This document provides a consistent TLS server identity verification procedure across multiple email-related protocols. This should make it easier for Certification Authorities (CAs) and ISPs to deploy TLS for email use and would enable email client developers to write more secure code.

このドキュメントでは、電子メール関連の複数のプロトコルにまたがる一貫したTLSサーバーID検証手順について説明します。これにより、証明機関（CA）とISPが電子メール用にTLSを展開しやすくなり、電子メールクライアント開発者がより安全なコードを記述できるようになります。

2. Conventions Used in This Document

2. このドキュメントで使用される規則

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

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

The following terms or concepts are used through the document:

このドキュメントでは、次の用語または概念が使用されています。

reference identifier: One of the domain names that the email client (an SMTP, IMAP, POP3, or ManageSieve client) associates with the target email server. For some identifier types, the identifier also includes an application service type. Reference identifiers are used for performing name checks on server certificates. (This term is formally defined in [RFC6125].)

参照識別子：電子メールクライアント（SMTP、IMAP、POP3、またはManageSieveクライアント）がターゲットの電子メールサーバーに関連付けるドメイン名の1つ。一部の識別子の種類では、識別子にアプリケーションサービスの種類も含まれます。参照識別子は、サーバー証明書の名前チェックを実行するために使用されます。（この用語は[RFC6125]で正式に定義されています。）

CN-ID, DNS-ID, SRV-ID, and URI-ID are identifier types (see [RFC6125] for details). For convenience, their short definitions from [RFC6125] are listed below:

CN-ID、DNS-ID、SRV-ID、およびURI-IDは識別子タイプです（詳細は[RFC6125]を参照）。便宜上、[RFC6125]の短い定義を以下に示します。

CN-ID: A Relative Distinguished Name (RDN) in the certificate subject field that contains one and only one attribute-type-and-value pair of type Common Name (CN), where the value matches the overall form of a domain name (informally, dot-separated, letter-digit-hyphen labels).

CN-ID：証明書のサブジェクトフィールド内の相対識別名（RDN）。これには、共通名（CN）タイプの属性と値のペアが1つだけ含まれ、値はドメイン名の全体的な形式（非公式に、ドットで区切られた、文字と数字のハイフンのラベル）。

DNS-ID: A subjectAltName entry of type dNSName

DNS-ID：タイプdNSNameのsubjectAltNameエントリ

SRV-ID: A subjectAltName entry of type otherName whose name form is SRVName

SRV-ID：名前の形式がSRVNameであるタイプotherNameのsubjectAltNameエントリ

URI-ID: A subjectAltName entry of type uniformResourceIdentifier whose value includes both (i) a "scheme" and (ii) a "host" component (or its equivalent) that matches the "reg-name" rule (where the quoted terms represent the associated [RFC5234] productions from [RFC3986]).

URI-ID：値が（i）「スキーム」と（ii）「reg-name」ルールに一致する「ホスト」コンポーネント（またはその同等物）の両方を含む、ユニフォームリソースタイプのsubjectAltNameエントリ（引用された用語が表す場合） [RFC3986]からの関連[RFC5234]プロダクション）。

3. Email Server Certificate Verification Rules

3. メールサーバー証明書検証ルール

During a TLS negotiation, an email client (i.e., an SMTP, IMAP, POP3, or ManageSieve client) MUST check its understanding of the server identity (client's reference identifiers) against the server's identity as presented in the server Certificate message in order to prevent man-in-the-middle attacks. This check is only performed after the server certificate passes certification path validation as described in Section 6 of [RFC5280]. Matching is performed according to the rules specified in Section 6 of [RFC6125], including the relative order of matching of different identifier types, "certificate pinning", and the procedure on failure to match. The following inputs are used by the verification procedure used in [RFC6125]:

TLSネゴシエーションの間、電子メールクライアント（つまり、SMTP、IMAP、POP3、またはManageSieveクライアント）は、サーバー証明書メッセージで提示されるサーバーのIDに対してサーバーID（クライアントの参照識別子）の理解をチェックして、防止する必要があります。中間者攻撃。このチェックは、[RFC5280]のセクション6で説明されているように、サーバー証明書が証明書パス検証に合格した後にのみ実行されます。照合は、[RFC6125]のセクション6で指定されたルールに従って実行されます。これには、さまざまな識別子タイプの照合の相対的な順序、「証明書のピン留め」、照合に失敗した場合の手順が含まれます。次の入力は、[RFC6125]で使用される検証手順で使用されます。

1. For DNS-ID and CN-ID identifier types, the client MUST use one or more of the following as "reference identifiers": (a) the domain portion of the user's email address, (b) the hostname it used to open the connection (without CNAME canonicalization). The client MAY also use (c) a value securely derived from (a) or (b), such as using "secure" DNSSEC [RFC4033] [RFC4034] [RFC4035] validated lookup.

1. DNS-IDおよびCN-ID識別子タイプの場合、クライアントは「参照識別子」として次の1つ以上を使用する必要があります：（a）ユーザーのメールアドレスのドメイン部分、（b）接続を開くために使用したホスト名（CNAMEの正規化なし）。クライアントは、（c）（安全な）DNSSEC [RFC4033] [RFC4034] [RFC4035]検証済みルックアップの使用など、（a）または（b）から安全に導出された値も使用できます（MAY）。

2. When using email service discovery procedure specified in [RFC6186], the client MUST also use the domain portion of the user's email address as another "reference identifier" to compare against an SRV-ID identifier in the server certificate.

2. [RFC6186]で指定されている電子メールサービス検出手順を使用する場合、クライアントはユーザーの電子メールアドレスのドメイン部分を別の「参照識別子」として使用して、サーバー証明書のSRV-ID識別子と比較する必要があります。

The rules and guidelines defined in [RFC6125] apply to an email server certificate with the following supplemental rules:

[RFC6125]で定義されているルールとガイドラインは、次の補足ルールを備えた電子メールサーバー証明書に適用されます。

1. Support for the DNS-ID identifier type (subjectAltName of dNSName type [RFC5280]) is REQUIRED in email client software implementations.

1. DNS-ID識別子タイプ（dNSNameタイプの[subjectAltName] [RFC5280]）のサポートは、電子メールクライアントソフトウェアの実装で必須です。

2. Support for the SRV-ID identifier type (subjectAltName of SRVName type [RFC4985]) is REQUIRED for email client software implementations that support [RFC6186]. A list of SRV-ID types for email services is specified in [RFC6186]. For the ManageSieve protocol, the service name "sieve" is used.

2. SRV-ID識別子タイプ（SRVNameタイプのsubjectAltNameタイプ[RFC4985]）のサポートは、[RFC6186]をサポートする電子メールクライアントソフトウェアの実装に必須です。電子メールサービスのSRV-IDタイプのリストは、[RFC6186]で指定されています。 ManageSieveプロトコルの場合、サービス名「sieve」が使用されます。

3. A URI-ID identifier type (subjectAltName of uniformResourceIdentifier type [RFC5280]) MUST NOT be used by clients for server verification, as URI-IDs were not historically used for email.

3. URI-IDはこれまで電子メールに使用されていなかったため、URI-ID識別子タイプ（uniformResourceIdentifierタイプの[subjectAltName]の[RFC5280]）をサーバー検証に使用しないでください。

4. For backward compatibility with deployed software, a CN-ID identifier type (CN attribute from the subject name, see [RFC6125]) MAY be used for server identity verification.

4. 配備されたソフトウェアとの下位互換性のために、CN-ID識別子タイプ（サブジェクト名からのCN属性。[RFC6125]を参照）をサーバーID検証に使用できます。

5. Email protocols allow use of certain wildcards in identifiers presented by email servers. The "*" wildcard character MAY be used as the left-most name component of a DNS-ID or CN-ID in the certificate. For example, a DNS-ID of "*.example.com" would match "a.example.com", "foo.example.com", etc., but would not match "example.com". Note that the wildcard character MUST NOT be used as a fragment of the left-most name component (e.g., "*oo.example.com", "f*o.example.com", or "foo*.example.com").

5. 電子メールプロトコルでは、電子メールサーバーが提示する識別子に特定のワイルドカードを使用できます。「*」ワイルドカード文字は、証明書のDNS-IDまたはCN-IDの左端の名前コンポーネントとして使用できます。たとえば、「*。example.com」のDNS-IDは「a.example.com」、「foo.example.com」などと一致しますが、「example.com」とは一致しません。ワイルドカード文字は、左端の名前コンポーネントのフラグメントとして使用してはならないことに注意してください（例：「* oo.example.com」、「f * o.example.com」、または「foo * .example.com」））。

4. Compliance Checklist for Certification Authorities

4. 証明機関のコンプライアンスチェックリスト

1. CAs MUST support issuance of server certificates with a DNS-ID identifier type (subjectAltName of dNSName type [RFC5280]). (Note that some DNS-IDs may refer to domain portions of email addresses, so they might not have corresponding A/AAAA DNS records.)

1. CAは、DNS-ID識別子タイプ（dNSNameタイプの[subjectAltName] [RFC5280]）を使用したサーバー証明書の発行をサポートする必要があります。（一部のDNS-IDはメールアドレスのドメイン部分を参照する場合があるため、対応するA / AAAA DNSレコードがない場合があることに注意してください。）

2. CAs MUST support issuance of server certificates with an SRV-ID identifier type (subjectAltName of SRVName type [RFC4985]) for each type of email service. See Section 4.1 for more discussion on what this means for CAs.

2. CAは、電子メールサービスのタイプごとに、SRV-ID識別子タイプ（SRVNameタイプ[RFC4985]のsubjectAltName）を使用したサーバー証明書の発行をサポートする必要があります。これがCAにとって何を意味するかについての詳細は、セクション4.1を参照してください。

3. For backward compatibility with a deployed client base, CAs MUST support issuance of server certificates with a CN-ID identifier type (CN attribute from the subject name, see [RFC6125]).

3. 展開されたクライアントベースとの下位互換性のために、CAはCN-ID識別子タイプ（サブジェクト名のCN属性、[RFC6125]を参照）を使用したサーバー証明書の発行をサポートする必要があります。

4. CAs MAY allow "*" (wildcard) as the left-most name component of a DNS-ID or CN-ID in server certificates it issues.

4. CAは、発行するサーバー証明書のDNS-IDまたはCN-IDの左端の名前コンポーネントとして「*」（ワイルドカード）を許可する場合があります。

4.1. Notes on Handling of Delegated Email Services by Certification Authorities

4.1. 証明機関による委任された電子メールサービスの処理に関する注意

[RFC6186] provides an easy way for organizations to autoconfigure email clients. It also allows for delegation of email services to an email hosting provider. When connecting to such delegated hosting service, an email client that attempts to verify TLS server identity needs to know that if it connects to "imap.hosting.example.net", such server is authorized to provide email access for an email such as alice@example.org. In absence of SRV-IDs, users of compliant email clients would be forced to manually confirm exceptions because the TLS server certificate verification procedures specified in this document would result in failure to match the TLS server certificate against the expected domain(s). One way to provide such authorization is for the TLS certificate for "imap.hosting.example.net" to include SRV-ID(s) (or a DNS-ID) for the "example.org" domain. Note that another way is for DNS Service Record (SRV) lookups to be protected by DNSSEC, but this solution depends on ubiquitous use of DNSSEC and availability of DNSSEC-aware APIs and thus is not discussed in this document. A future update to this document might rectify this.

[RFC6186]は、組織が電子メールクライアントを自動設定する簡単な方法を提供します。また、メールサービスをメールホスティングプロバイダーに委任することもできます。このような委任されたホスティングサービスに接続する場合、TLSサーバーのIDを検証しようとする電子メールクライアントは、「imap.hosting.example.net」に接続する場合、そのサーバーがaliceなどの電子メールに電子メールアクセスを提供することを許可されていることを認識する必要があります。 @ example.org。 SRV-IDがない場合、このドキュメントで指定されているTLSサーバー証明書の検証手順により、TLSサーバー証明書と予想されるドメインとの照合が失敗するため、準拠している電子メールクライアントのユーザーは例外を手動で確認する必要があります。そのような認証を提供する1つの方法は、「imap.hosting.example.net」のTLS証明書に「example.org」ドメインのSRV-ID（またはDNS-ID）を含めることです。別の方法はDNSサービスレコード（SRV）ルックアップをDNSSECで保護することですが、このソリューションはDNSSECのユビキタスな使用とDNSSEC対応APIの可用性に依存するため、このドキュメントでは説明しません。このドキュメントの将来の更新により、これが修正される可能性があります。

A CA that receives a Certificate Signing Request containing multiple unrelated DNS-IDs and/or SRV-IDs (e.g., a DNS-ID of "example.org" and a DNS-ID of "example.com") needs to verify that the entity that supplied such Certificate Signing Request is authorized to provide email service for all requested domains.

複数の無関係なDNS-IDやSRV-ID（たとえば、「example.org」のDNS-IDと「example.com」のDNS-ID）を含む証明書署名要求を受け取ったCAは、そのような証明書署名要求を提供したエンティティは、要求されたすべてのドメインに電子メールサービスを提供する権限があります。

The ability to issue certificates that contain an SRV-ID (or a DNS-ID for the domain part of email addresses) implies the ability to verify that entities requesting them are authorized to run email service for these SRV-IDs/DNS-IDs. In particular, CAs that can't verify such authorization (whether for a particular domain or in general) MUST NOT include such email SRV-IDs/DNS-IDs in certificates they issue. This document doesn't specify exact mechanism(s) that can be used to achieve this. However, a few special case recommendations are listed below.

SRV-ID（または電子メールアドレスのドメイン部分のDNS-ID）を含む証明書を発行する機能は、それらを要求するエンティティがこれらのSRV-ID / DNS-IDの電子メールサービスを実行することを承認されていることを確認する機能を意味します。特に、そのような認証を確認できないCA（特定のドメインの場合も一般的な場合も）は、発行する証明書にそのような電子メールSRV-ID / DNS-IDを含めてはなりません（MUST NOT）。このドキュメントでは、これを達成するために使用できる正確なメカニズムを指定していません。ただし、いくつかの特別なケースの推奨事項を以下に示します。

A CA willing to sign a certificate containing a particular DNS-ID SHOULD also support signing a certificate containing one or more of the email SRV-IDs for the same domain because the SRV-ID effectively provides more restricted access to an email service for the domain (as opposed to unrestricted use of any services for the same domain, as specified by the DNS-ID).

特定のDNS-IDを含む証明書に署名するCAは、同じドメインの1つ以上の電子メールSRV-IDを含む証明書への署名もサポートする必要があります（SRV-IDは、ドメインの電子メールサービスへのアクセスをより制限するため）（DNS-IDで指定された同じドメインでのサービスの無制限の使用とは対照的に）。

A CA that also provides DNS service for a domain can use DNS information to validate SRV-IDs/DNS-IDs for the domain.

ドメインにDNSサービスも提供するCAは、DNS情報を使用して、ドメインのSRV-ID / DNS-IDを検証できます。

A CA that is also a Mail Service Provider for a hosted domain can use that knowledge to validate SRV-IDs/DNS-IDs for the domain.

ホストされたドメインのメールサービスプロバイダーでもあるCAは、その知識を使用してドメインのSRV-ID / DNS-IDを検証できます。

5. Compliance Checklist for Mail Service Providers and Certificate Signing Request Generation Tools

5. メールサービスプロバイダーと証明書署名要求生成ツールのコンプライアンスチェックリスト

Mail Service Providers and Certificate Signing Request generation tools:

メールサービスプロバイダーと証明書署名要求生成ツール：

1. MUST include the DNS-ID identifier type in Certificate Signing Requests for the host name(s) where the email server(s) are running. They SHOULD include the DNS-ID identifier type in Certificate Signing Requests for the domain portion of served email addresses.

1. 電子メールサーバーが実行されているホスト名の証明書署名要求にDNS-ID識別子タイプを含める必要があります。それらは、提供される電子メールアドレスのドメイン部分の証明書署名要求にDNS-ID識別子タイプを含める必要があります（SHOULD）。

2. MUST include the SRV-ID identifier type for each type of email service in Certificate Signing Requests if the email services provided are discoverable using DNS SRV as specified in [RFC6186].

2. [RFC6186]で指定されているDNS SRVを使用して、提供される電子メールサービスが検出可能な場合は、証明書署名要求に電子メールサービスの各タイプのSRV-ID識別子タイプを含める必要があります。

3. SHOULD include the CN-ID identifier type for the host name where the email server(s) is running in Certificate Signing Requests for backward compatibility with deployed email clients. (Note, a certificate can only include a single CN-ID, so if a mail service is running on multiple hosts, either each host has to use different certificate with its own CN-ID, a single certificate with multiple DNS-IDs, or a single certificate with wildcard in a CN-ID can be used).

3. デプロイされた電子メールクライアントとの下位互換性のために、証明書署名要求で電子メールサーバーが実行されているホスト名のCN-ID識別子タイプを含める必要があります。（証明書には単一のCN-IDのみを含めることができるため、メールサービスが複数のホストで実行されている場合、各ホストは独自のCN-IDを持つ異なる証明書、複数のDNS-IDを持つ単一の証明書、またはCN-IDにワイルドカードを含む単一の証明書を使用できます）。

4. MAY include "*" (wildcard) as the left-most name component of a DNS-ID or CN-ID in Certificate Signing Requests.

4. 証明書署名要求のDNS-IDまたはCN-IDの左端の名前コンポーネントとして「*」（ワイルドカード）を含めることができます。

5.1. Notes on Hosting Multiple Domains

5.1. 複数ドメインのホスティングに関する注意

A server that hosts multiple domains needs to do one of the following (or some combination thereof):

複数のドメインをホストするサーバーは、次のいずれか（またはそのいくつかの組み合わせ）を実行する必要があります。

1. Use DNS SRV records to redirect each hosted email service to a fixed domain, deploy TLS certificate(s) for that single domain, and instruct users to configure their clients with appropriate pinning (unless the SRV records can always be obtained via DNSSEC). Some email clients come with preloaded lists of pinned certificates for some popular domains; this can avoid the need for manual confirmation.

1. DNS SRVレコードを使用して、ホストされている各メールサービスを固定ドメインにリダイレクトし、その単一ドメインにTLS証明書を展開し、適切なピン接続を使用してクライアントを構成するようユーザーに指示します（SRVレコードは常にDNSSEC経由で取得できる場合を除く）。一部の電子メールクライアントには、いくつかの一般的なドメイン用の固定された証明書のプリロードリストが付属しています。これにより、手動で確認する必要がなくなります。

2. Use a single TLS certificate that includes a complete list of all the domains it is serving.

2. 提供するすべてのドメインの完全なリストを含む単一のTLS証明書を使用します。

3. Serve each domain on its own IP/port, using separate TLS certificates on each IP/port.

3. 各IP /ポートで個別のTLS証明書を使用して、独自のIP /ポートで各ドメインを提供します。

4. Use the Server Name Indication (SNI) TLS extension [RFC6066] to select the right certificate to return during TLS negotiation. Each domain has its own TLS certificate in this case.

4. サーバー名表示（SNI）TLS拡張[RFC6066]を使用して、TLSネゴシエーション中に返す正しい証明書を選択します。この場合、各ドメインには独自のTLS証明書があります。

Each of these deployment choices have their scaling disadvantages when the list of domains changes. Use of DNS SRV without an SRV-ID requires manual confirmation from users. While preloading pinned certificates avoids the need for manual confirmation, this information can get stale quickly or would require support for a new mechanism for distributing preloaded pinned certificates. A single certificate (the second choice) requires that when a domain is added, then a new Certificate Signing Request that includes a complete list of all the domains needs to be issued and passed to a CA in order to generate a new certificate. A separate IP/port can avoid regenerating the certificate but requires more transport layer resources. Use of TLS SNI requires each email client to use it.

ドメインのリストが変更されると、これらの展開の選択肢にはそれぞれスケーリングの欠点があります。 SRV-IDなしでDNS SRVを使用するには、ユーザーの手動による確認が必要です。ピン留めされた証明書を事前にロードすると手動で確認する必要がなくなりますが、この情報はすぐに古くなるか、事前にロードされたピン留めされた証明書を配布するための新しいメカニズムのサポートが必要になります。単一の証明書（2番目の選択肢）では、ドメインを追加するときに、新しい証明書を生成するために、すべてのドメインの完全なリストを含む新しい証明書署名要求を発行してCAに渡す必要があります。個別のIP /ポートを使用すると、証明書の再生成を回避できますが、より多くのトランスポート層リソースが必要になります。 TLS SNIを使用するには、各電子メールクライアントがそれを使用する必要があります。

Several Mail Service Providers host hundreds and even thousands of domains. This document, as well as its predecessors, RFCs 2595, 3207, 3501, and 5804, don't address scaling issues caused by use of TLS in multi-tenanted environments. Further work is needed to address this issue, possibly using DNSSEC or something like PKIX over Secure HTTP (POSH) [RFC7711].

いくつかのメールサービスプロバイダーが数百、さらには数千のドメインをホストしています。このドキュメントは、その前身であるRFC 2595、3207、3501、および5804と同様に、マルチテナント環境でのTLSの使用によって引き起こされるスケーリングの問題に対処していません。この問題に対処するには、DNSSECまたはPKIX over Secure HTTP（POSH）[RFC7711]などを使用する可能性があります。

6. Examples

6. 例

Consider an IMAP-accessible email server that supports both IMAP and IMAP-over-TLS (IMAPS) at the host "mail.example.net" servicing email addresses of the form "user@example.net". A certificate for this service needs to include DNS-IDs of "example.net" (because it is the domain portion of emails) and "mail.example.net" (this is what a user of this server enters manually if not using [RFC6186]). It might also include a CN-ID of "mail.example.net" for backward compatibility with deployed infrastructure.

ホスト "mail.example.net"でIMAPとIMAP-over-TLS（IMAPS）の両方をサポートし、 "user@example.net"の形式の電子メールアドレスにサービスを提供する、IMAPでアクセス可能な電子メールサーバーを検討してください。このサービスの証明書には、「example.net」（メールのドメイン部分であるため）と「mail.example.net」（このサーバーのユーザーが[ RFC6186]）。展開されたインフラストラクチャとの下位互換性のために、「mail.example.net」のCN-IDが含まれる場合もあります。

Consider the IMAP-accessible email server from the previous paragraph that is additionally discoverable via DNS SRV lookups in domain "example.net" (using DNS SRV records "_imap._tcp.example.net" and "_imaps._tcp.example.net"). In addition to the DNS-ID/CN-ID identity types specified above, a certificate for this service also needs to include SRV-IDs of "_imap.example.net" (when STARTTLS is used on the IMAP port) and "_imaps.example.net" (when TLS is used on IMAPS port). See [RFC6186] for more details. (Note that unlike DNS SRV there is no "_tcp" component in SRV-IDs).

ドメイン「example.net」のDNS SRVルックアップを介してさらに検出可能な、前の段落からのIMAPアクセス可能な電子メールサーバーを検討してください（DNS SRVレコード「_imap._tcp.example.net」と「_imaps._tcp.example.net」を使用））。上記で指定されたDNS-ID / CN-ID IDタイプに加えて、このサービスの証明書には、「_ imap.example.net」（STARTTLSがIMAPポートで使用されている場合）および「_imaps」のSRV-IDを含める必要もあります。 example.net "（IMAPSポートでTLSが使用されている場合）。詳細については、[RFC6186]を参照してください。（DNS SRVとは異なり、SRV-IDには "_tcp"コンポーネントがないことに注意してください）。

Consider the IMAP-accessible email server from the first paragraph that is running on a host also known as "mycompany.example.com". In addition to the DNS-ID identity types specified above, a certificate for this service also needs to include a DNS-ID of "mycompany.example.com" (this is what a user of this server enters manually if not using [RFC6186]). It might also include a CN-ID of "mycompany.example.com" instead of the CN-ID "mail.example.net" for backward compatibility with deployed infrastructure. (This is so, because a certificate can only include a single CN-ID)

「mycompany.example.com」としても知られているホストで実行されている最初の段落からIMAPでアクセス可能な電子メールサーバーを検討してください。上記で指定したDNS-ID IDタイプに加えて、このサービスの証明書には、「mycompany.example.com」のDNS-IDも含める必要があります（これは、このサーバーのユーザーが[RFC6186]を使用しない場合に手動で入力するものです））。展開されたインフラストラクチャとの下位互換性のために、CN-ID「mail.example.net」の代わりに「mycompany.example.com」のCN-IDが含まれる場合もあります。（これは、証明書に単一のCN-IDのみを含めることができるためです）

Consider an SMTP Submission server at the host "submit.example.net" servicing email addresses of the form "user@example.net" and discoverable via DNS SRV lookups in domain "example.net" (using DNS SRV record "_submission._tcp.example.net"). A certificate for this service needs to include SRV-IDs of "_submission.example.net" (see [RFC6186]) along with DNS-IDs of "example.net" and "submit.example.net". It might also include a CN-ID of "submit.example.net" for backward compatibility with deployed infrastructure.

ホスト「submit.example.net」のSMTP送信サーバーが「user@example.net」の形式の電子メールアドレスにサービスを提供し、ドメイン「example.net」のDNS SRVルックアップを介して検出できるとします（DNS SRVレコード「_submission._tcpを使用して」 .example.net」）。このサービスの証明書には、「_ submission.example.net」（[RFC6186]を参照）のSRV-IDと、「example.net」および「submit.example.net」のDNS-IDを含める必要があります。展開されたインフラストラクチャとの下位互換性のために、「submit.example.net」のCN-IDが含まれる場合もあります。

Consider a host "mail.example.net" servicing email addresses of the form "user@example.net" and discoverable via DNS SRV lookups in domain "example.net", which runs SMTP Submission, IMAPS and POP3S (POP3-over-TLS), and ManageSieve services. Each of the servers can use their own certificate specific to their service (see examples above). Alternatively, they can all share a single certificate that would include SRV-IDs of "_submission.example.net",

SMTP送信、IMAPSおよびPOP3S（POP3-over- TLS）、およびManageSieveサービス。各サーバーは、サービスに固有の独自の証明書を使用できます（上記の例を参照）。または、「_ submission.example.net」のSRV-IDを含む単一の証明書をすべて共有できます。

"_imaps.example.net", "_pop3s.example.net", and "_sieve.example.net" along with DNS-IDs of "example.net" and "mail.example.net". It might also include a CN-ID of "mail.example.net" for backward compatibility with deployed infrastructure.

「_imaps.example.net」、「_ pop3s.example.net」、「_ sieve.example.net」、および「example.net」と「mail.example.net」のDNS-ID。展開されたインフラストラクチャとの下位互換性のために、「mail.example.net」のCN-IDが含まれる場合もあります。

7. Operational Considerations

7. 運用上の考慮事項

Section 5 covers operational considerations (in particular, use of DNS SRV for autoconfiguration) related to generating TLS certificates for email servers so that they can be successfully verified by email clients. Additionally, Section 5.1 talks about operational considerations related to hosting multiple domains.

セクション5では、電子メールクライアントが正常に検証できるように電子メールサーバーのTLS証明書の生成に関連する運用上の考慮事項（特に、自動構成のためのDNS SRVの使用）について説明します。さらに、セクション5.1では、複数のドメインのホスティングに関連する運用上の考慮事項について説明しています。

8. Security Considerations

8. セキュリティに関する考慮事項

The goal of this document is to improve interoperability and thus security of email clients wishing to access email servers over TLS-protected email protocols by specifying a consistent set of rules that email service providers, email client writers, and CAs can use when creating server certificates.

このドキュメントの目的は、相互運用性を向上させ、TLSで保護された電子メールプロトコルを介して電子メールサーバーにアクセスする電子メールクライアントのセキュリティを向上させることです。これにより、電子メールサービスプロバイダー、電子メールクライアントの作成者、およびCAがサーバー証明書の作成時に使用できる一貫したルールセットを指定できます。。

The TLS server identity check for email relies on use of trustworthy DNS hostnames when constructing "reference identifiers" that are checked against an email server certificate. Such trustworthy names are either entered manually (for example, if they are advertised on a Mail Service Provider's website), explicitly confirmed by the user (e.g., if they are a target of a DNS SRV lookup), or derived using a secure third party service (e.g., DNSSEC-protected SRV records that are verified by the client or trusted local resolver). Future work in this area might benefit from integration with DNS-Based Authentication of Named Entities (DANE) [RFC6698], but it is not covered by this document.

電子メールのTLSサーバーIDチェックは、電子メールサーバー証明書に対してチェックされる「参照識別子」を構築するときに、信頼できるDNSホスト名の使用に依存します。このような信頼できる名前は、手動で入力するか（メールサービスプロバイダーのWebサイトでアドバタイズする場合など）、ユーザーが明示的に確認する（DNS SRVルックアップのターゲットである場合など）、または安全なサードパーティを使用して導出するサービス（たとえば、クライアントまたは信頼できるローカルリゾルバによって検証されるDNSSECで保護されたSRVレコード）。この領域での今後の作業は、DNSベースの名前付きエンティティの認証（DANE）[RFC6698]との統合から恩恵を受ける可能性がありますが、このドキュメントでは扱いません。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, <http://www.rfc-editor.org/info/rfc1939>.

[RFC1939]マイヤーズ、J。およびM.ローズ、「Post Office Protocol-Version 3」、STD 53、RFC 1939、DOI 10.17487 / RFC1939、1996年5月、<http://www.rfc-editor.org/info/ rfc1939>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, <http://www.rfc-editor.org/info/rfc3207>.

[RFC3207] Hoffman、P。、「Secure SMTP over Transport Layer SecurityのSMTPサービス拡張」、RFC 3207、DOI 10.17487 / RFC3207、2002年2月、<http://www.rfc-editor.org/info/rfc3207>。

[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <http://www.rfc-editor.org/info/rfc3501>.

[RFC3501] Crispin、M。、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 3501、DOI 10.17487 / RFC3501、2003年3月、<http://www.rfc-editor.org/info/rfc3501>。

[RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name", RFC 4985, DOI 10.17487/RFC4985, August 2007, <http://www.rfc-editor.org/info/rfc4985>.

[RFC4985] Santesson、S。、「Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name」、RFC 4985、DOI 10.17487 / RFC4985、2007年8月、<http://www.rfc-editor.org/ info / rfc4985>。

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.

[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。

[RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804, July 2010, <http://www.rfc-editor.org/info/rfc5804>.

[RFC5804] Melnikov、A.、Ed。およびT.マーティン、「A Sieveスクリプトをリモート管理するためのプロトコル」、RFC 5804、DOI 10.17487 / RFC5804、2010年7月、<http://www.rfc-editor.org/info/rfc5804>。

[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>.

[RFC6066] Eastlake 3rd、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、DOI 10.17487 / RFC6066、2011年1月、<http://www.rfc-editor.org/info/rfc6066> 。

[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.

[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<http://www.rfc-editor.org/info/rfc6125>。

[RFC6186] Daboo, C., "Use of SRV Records for Locating Email Submission/Access Services", RFC 6186, DOI 10.17487/RFC6186, March 2011, <http://www.rfc-editor.org/info/rfc6186>.

[RFC6186] Daboo、C。、「電子メールの送信/アクセスサービスを見つけるためのSRVレコードの使用」、RFC 6186、DOI 10.17487 / RFC6186、2011年3月、<http://www.rfc-editor.org/info/rfc6186> 。

[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, <http://www.rfc-editor.org/info/rfc6409>.

[RFC6409] Gellens、R。およびJ. Klensin、「メールのメッセージ送信」、STD 72、RFC 6409、DOI 10.17487 / RFC6409、2011年11月、<http://www.rfc-editor.org/info/rfc6409> 。

9.2. Informative References

9.2. 参考引用

[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, DOI 10.17487/RFC2595, June 1999, <http://www.rfc-editor.org/info/rfc2595>.

[RFC2595]ニューマン、C。、「TLSとIMAP、POP3およびACAPの使用」、RFC 2595、DOI 10.17487 / RFC2595、1999年6月、<http://www.rfc-editor.org/info/rfc2595>。

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.

[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.

[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<http： //www.rfc-editor.org/info/rfc4033>。

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.

[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、< http://www.rfc-editor.org/info/rfc4034>。

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>.

[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、DOI 10.17487 / RFC4035、2005年3月、< http://www.rfc-editor.org/info/rfc4035>。

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.

[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。

[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>.

[RFC6698] Hoffman、P。およびJ. Schlyter、「DNSベースの名前付きエンティティ（DANE）トランスポート層セキュリティ（TLS）プロトコルの認証：TLSA」、RFC 6698、DOI 10.17487 / RFC6698、2012年8月、<http：/ /www.rfc-editor.org/info/rfc6698>。

[RFC7711] Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP (POSH)", RFC 7711, DOI 10.17487/RFC7711, November 2015, <http://www.rfc-editor.org/info/rfc7711>.

[RFC7711] Miller、M。およびP. Saint-Andre、「PKIX over Secure HTTP（POSH）」、RFC 7711、DOI 10.17487 / RFC7711、2015年11月、<http://www.rfc-editor.org/info/ rfc7711>。

Appendix A. Changes to RFCs 2595, 3207, 3501, and 5804

付録A. RFC 2595、3207、3501、および5804の変更

This section lists detailed changes this document applies to RFCs 2595, 3207, 3501, and 5804.

このセクションでは、このドキュメントがRFC 2595、3207、3501、および5804に適用される詳細な変更を示します。

The entire Section 2.4 of RFC 2595 is replaced with the following text:

RFC 2595のセクション2.4全体が次のテキストに置き換えられます。

During the TLS negotiation, the client checks its understanding of the server identity against the provided server's identity as specified in Section 3 of [RFC7817].

TLSネゴシエーション中に、クライアントは、[RFC7817]のセクション3で指定されているように、提供されたサーバーのIDに対してサーバーIDの理解をチェックします。

The 3rd paragraph (and its subparagraphs) in Section 11.1 of RFC 3501 is replaced with the following text:

RFC 3501のセクション11.1の3番目の段落（およびそのサブ段落）は、次のテキストに置き換えられます。

During the TLS negotiation, the IMAP client checks its understanding of the server identity against the provided server's identity as specified in Section 3 of [RFC7817].

TLSネゴシエーション中に、IMAPクライアントは、[RFC7817]のセクション3で指定されているように、提供されたサーバーのIDに対してサーバーIDの理解をチェックします。

The 3rd paragraph (and its subparagraphs) in Section 4.1 of RFC 3207 is replaced with the following text:

RFC 3207のセクション4.1の3番目の段落（およびそのサブ段落）は、次のテキストに置き換えられます。

During the TLS negotiation, the Submission client checks its understanding of the server identity against the provided server's identity as specified in Section 3 of [RFC7817].

TLSネゴシエーション中に、送信クライアントは、[RFC7817]のセクション3で指定されているように、提供されたサーバーのIDに対してサーバーIDの理解をチェックします。

Sections 2.2.1 and 2.2.1.1 of RFC 5804 are replaced with the following text:

RFC 5804のセクション2.2.1および2.2.1.1は、次のテキストに置き換えられます。

During the TLS negotiation, the ManageSieve client checks its understanding of the server identity against the server's identity as specified in Section 3 of [RFC7817]. When the reference identity is an IP address, the iPAddress subjectAltName SHOULD be used by the client for comparison. The comparison is performed as described in Section 2.2.1.2 of RFC 5804.

TLSネゴシエーション中、ManageSieveクライアントは、[RFC7817]のセクション3で指定されているように、サーバーのIDに対する理解をサーバーのIDと照合します。参照IDがIPアドレスの場合、クライアントは比較のためにiPAddress subjectAltNameを使用する必要があります（SHOULD）。比較は、RFC 5804のセクション2.2.1.2の説明に従って実行されます。

Acknowledgements

謝辞

Thank you to Chris Newman, Viktor Dukhovni, Sean Turner, Russ Housley, Alessandro Vesely, Harald Alvestrand, and John Levine for comments on this document.

このドキュメントに関するコメントを提供してくれたChris Newman、Viktor Dukhovni、Sean Turner、Russ Housley、Alessandro Vesely、Harald Alvestrand、およびJohn Levineに感謝します。

The editor of this document copied lots of text from RFCs 2595 and 6125, so the hard work of editors of these documents is appreciated.

このドキュメントの編集者はRFC 2595および6125から多くのテキストをコピーしたので、これらのドキュメントの編集者のハードワークは高く評価されています。

Author's Address

著者のアドレス

Alexey Melnikov Isode Ltd 14 Castle Mews Hampton, Middlesex TW12 2NP United Kingdom

Alexey Melnikov Isode Ltd 14 Castle Mewsハンプトン、ミドルセックスTW12 2NPイギリス

   EMail: Alexey.Melnikov@isode.com