RFC 8162 - Using Secure DNS to Associate Certificates with Domain Names for S/MIME 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8162
タイトル : RFC 8162 - セキュアDNSを使用して証明書をS / MIMEのドメイン名に関連付ける
翻訳編集 : 自動生成

[要約] RFC 8162は、S/MIMEのドメイン名に証明書を関連付けるためにセキュアDNSを使用する方法について説明しています。このRFCの目的は、セキュアな方法でドメイン名と証明書を関連付けるためのガイドラインを提供することです。

Internet Engineering Task Force (IETF)                        P. Hoffman
Request for Comments: 8162                                         ICANN
Category: Experimental                                       J. Schlyter
ISSN: 2070-1721                                                 Kirei AB
                                                                May 2017

Using Secure DNS to Associate Certificates with Domain Names for S/MIME

セキュアDNSを使用して証明書をS / MIMEのドメイン名に関連付ける

Abstract

概要

This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DNS-Based Authentication of Named Entities (DANE), RFC 6698, does for TLS.

このドキュメントでは、セキュアDNSを使用してS / MIMEユーザーの証明書を目的のドメイン名に関連付ける方法について説明します。これは、DNSに基づく名前付きエンティティの認証（DANE）、RFC 6698がTLSに対して行う方法と似ています。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。

This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.

このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション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/rfc8162.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8162で入手できます。

著作権表示

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
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Experiment Goal . . . . . . . . . . . . . . . . . . . . .   3
   2.  The SMIMEA Resource Record  . . . . . . . . . . . . . . . . .   4
   3.  Location of the SMIMEA Record . . . . . . . . . . . . . . . .   4
   4.  Email Address Variants and Internationalization
       Considerations  . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Mandatory-to-Implement Features . . . . . . . . . . . . . . .   6
   6.  Application Use of S/MIME Certificate Associations  . . . . .   6
   7.  Certificate Size and DNS  . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     9.1.  Response Size . . . . . . . . . . . . . . . . . . . . . .   8
     9.2.  Email Address Information Leak  . . . . . . . . . . . . .   8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     10.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1. Introduction

1. はじめに

S/MIME [RFC5751] messages often contain a certificate (some messages contain more than one certificate). These certificates assist in authenticating the sender of the message and can be used for encrypting messages that will be sent in reply. In order for the S/MIME receiver to authenticate that a message is from the sender identified in the message, the receiver's Mail User Agent (MUA) must validate that this certificate is associated with the purported sender. Currently, the MUA must trust a trust anchor upon which the sender's certificate is rooted and must successfully validate the certificate. There are other requirements on the MUA, such as associating the identity in the certificate with that of the message, that are out of scope for this document.

S / MIME [RFC5751]メッセージには証明書が含まれていることがよくあります（一部のメッセージには複数の証明書が含まれています）。これらの証明書は、メッセージの送信者の認証に役立ち、返信で送信されるメッセージの暗号化に使用できます。 S / MIME受信者がメッセージがメッセージで識別された送信者からのものであることを認証するには、受信者のメールユーザーエージェント（MUA）が、この証明書が意図された送信者に関連付けられていることを検証する必要があります。現在、MUAは送信者の証明書のルートとなるトラストアンカーを信頼し、証明書を正常に検証する必要があります。 MUAには、証明書のIDをメッセージのIDに関連付けるなど、このドキュメントの範囲外である他の要件があります。

Some people want to authenticate the association of the sender's certificate with the sender without trusting a configured trust anchor. Others to want mitigate the difficulty of finding certificates from outside the enterprise. Given that the DNS administrator for a domain name is authorized to give identifying information about the zone, it makes sense to allow that administrator to also make an authoritative binding between email messages purporting to come from the domain name and a certificate that might be used by someone authorized to send mail from those servers. The easiest way to do this is to use the DNS.

構成されているトラストアンカーを信頼せずに、送信者の証明書と送信者の関連付けを認証したいという人もいます。企業の外部から証明書を見つける困難さを軽減したい人もいます。ドメイン名のDNS管理者がゾーンに関する識別情報を提供することを許可されている場合、その管理者が、ドメイン名から送信されたと主張する電子メールメッセージと、それらのサーバーからのメール送信を許可された人。これを行う最も簡単な方法は、DNSを使用することです。

This document describes a mechanism for associating a user's certificate with the domain that is similar to that described in DANE itself [RFC6698], as updated by [RFC7218] and [RFC7671]; it is also similar to the mechanism given in [RFC7929] for OpenPGP. Most of the operational and security considerations for using the mechanism in this document are described in RFC 6698 and are not described here at all. Only the major differences between this mechanism and those used in RFC 6698 are described here. Thus, the reader must be familiar with RFC 6698 before reading this document.

このドキュメントは、[RFC7218]と[RFC7671]によって更新された、DANE自体[RFC6698]で説明されているものと同様のドメインにユーザーの証明書を関連付けるメカニズムについて説明しています。また、OpenPGPの[RFC7929]で提供されているメカニズムにも似ています。このドキュメントのメカニズムを使用するための操作上およびセキュリティ上の考慮事項のほとんどは、RFC 6698で説明されており、ここではまったく説明しません。ここでは、このメカニズムとRFC 6698で使用されているメカニズムの主な違いのみを説明します。したがって、読者はこのドキュメントを読む前にRFC 6698に精通している必要があります。

1.1. Terminology

1.1. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

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

This document also makes use of standard PKIX, DNSSEC, and S/MIME terminology. See PKIX [RFC5280], DNSSEC [RFC4033] [RFC4034] [RFC4035], and S/MIME [RFC5751] for these terms.

このドキュメントでは、標準のPKIX、DNSSEC、およびS / MIMEの用語も使用しています。これらの用語については、PKIX [RFC5280]、DNSSEC [RFC4033] [RFC4034] [RFC4035]、およびS / MIME [RFC5751]を参照してください。

1.2. Experiment Goal

1.2. 実験目標

This specification is one experiment in improving access to public keys for end-to-end email security. There are a range of ways in which this can reasonably be done for OpenPGP or S/MIME, for example, using the DNS, SMTP, or HTTP. Proposals for each of these have been made with various levels of support in terms of implementation and deployment. For each such experiment, specifications such as this will enable experiments to be carried out that may succeed or that may uncover technical or other impediments to large- or small-scale deployments. The IETF encourages those implementing and deploying such experiments to publicly document their experiences so that future specifications in this space can benefit.

この仕様は、エンドツーエンドの電子メールセキュリティのために公開鍵へのアクセスを改善するための1つの実験です。これをOpenPGPまたはS / MIMEで合理的に行うことができるさまざまな方法があります。たとえば、DNS、SMTP、またはHTTPを使用します。これらのそれぞれに対する提案は、実装と展開に関してさまざまなレベルのサポートで行われました。このような各実験について、このような仕様により、成功する可能性のある実験、または大規模または小規模の展開に対する技術的またはその他の障害を明らかにする可能性のある実験を実行できます。 IETFは、このような実験を実装および展開する人たちに、この分野の将来の仕様が恩恵を受けることができるように、彼らの経験を公に文書化することを奨励します。

This document defines an RRtype whose use is Experimental. The goal of the experiment is to see whether encrypted email usage will increase if an automated discovery method is available to Mail Transfer Agents (MTAs) and if MUAs help the end user with email encryption key management.

このドキュメントでは、実験的な用途を持つRRtypeを定義しています。実験の目的は、自動検出方法がMail Transfer Agents（MTA）で利用可能であり、MUAがエンドユーザーの電子メール暗号化キー管理を支援する場合に、暗号化された電子メールの使用が増加するかどうかを確認することです。

It is unclear if this RRtype will scale to some of the larger email service deployments. Concerns have been raised about the size of the SMIMEA record and the size of the resulting DNS zone files. This experiment hopefully will give the IETF some insight into whether or not this is a problem.

このRRtypeが一部の大規模な電子メールサービス展開に拡張されるかどうかは不明です。 SMIMEAレコードのサイズと結果のDNSゾーンファイルのサイズについて懸念が提起されました。この実験により、IETFがこれが問題であるかどうかについての洞察が得られると期待しています。

If the experiment is successful, it is expected that the findings of the experiment will result in an updated document for Standards Track approval.

実験が成功した場合、実験の結果により、Standards Track承認用のドキュメントが更新されることが期待されます。

2. The SMIMEA Resource Record

2. SMIMEAリソースレコード

The SMIMEA DNS resource record (RR) is used to associate an end entity certificate or public key with the associated email address, thus forming a "SMIMEA certificate association". The semantics of how the SMIMEA resource record is interpreted are given later in this document. Note that the information returned in the SMIMEA record might be for the end entity certificate, or it might be for the trust anchor or an intermediate certificate. This mechanism is similar to the one given in [RFC7929] for OpenPGP.

SMIMEA DNSリソースレコード（RR）は、エンドエンティティ証明書または公開キーを関連付けられた電子メールアドレスに関連付けるために使用され、「SMIMEA証明書関連付け」を形成します。 SMIMEAリソースレコードの解釈方法のセマンティクスについては、このドキュメントの後半で説明します。 SMIMEAレコードで返される情報は、エンドエンティティ証明書の場合もあれば、トラストアンカーまたは中間証明書の場合もあります。このメカニズムは、OpenPGPの[RFC7929]で提供されているメカニズムに似ています。

The type value for the SMIMEA RRtype is defined in Section 8. The SMIMEA resource record is class independent.

SMIMEA RRtypeのタイプ値は、セクション8で定義されています。SMIMEAリソースレコードは、クラスに依存しません。

The SMIMEA wire format and presentation format are the same as for the TLSA record as described in Section 2.1 of [RFC6698]. The certificate usage field, the selector field, and the matching type field have the same format; the semantics are also the same except where RFC 6698 talks about TLS as the target protocol for the certificate information.

SMIMEAワイヤ形式とプレゼンテーション形式は、[RFC6698]のセクション2.1で説明されているTLSAレコードと同じです。証明書の使用法フィールド、セレクターフィールド、および一致するタイプフィールドは同じ形式です。セマンティクスも同じですが、RFC 6698が証明書情報のターゲットプロトコルとしてTLSについて話している場合を除きます。

3. Location of the SMIMEA Record

3. SMIMEAレコードの場所

The DNS does not allow the use of all characters that are supported in the "local-part" of email addresses as defined in [RFC5322] and [RFC6530]. Therefore, email addresses are mapped into DNS using the following method:

DNSでは、[RFC5322]と[RFC6530]で定義されている電子メールアドレスの「ローカル部分」でサポートされているすべての文字の使用は許可されていません。したがって、電子メールアドレスは次の方法を使用してDNSにマッピングされます。

1. The "left-hand side" of the email address, called the "local-part" in both the mail message format definition [RFC5322] and in the specification for internationalized email [RFC6530]) is encoded in UTF-8 (or its subset ASCII). If the local-part is written in another charset, it MUST be converted to UTF-8.

1. メールメッセージ形式の定義[RFC5322]と国際化されたメールの仕様[RFC6530]の両方で「ローカル部分」と呼ばれるメールアドレスの「左側」は、UTF-8（またはそのサブセット）でエンコードされていますASCII）。ローカル部分が別の文字セットで記述されている場合は、UTF-8に変換する必要があります。

2. The local-part is first canonicalized using the following rules. If the local-part is unquoted, any comments and/or folding whitespace (CFWS) around dots (".") is removed. Any enclosing double quotes are removed. Any literal quoting is removed.

2. ローカル部分は、最初に次のルールを使用して正規化されます。ローカル部分が引用符で囲まれていない場合、コメントやドット（ "。"）の周りの折りたたみ空白（CFWS）は削除されます。囲んでいる二重引用符は削除されます。リテラル引用は削除されます。

3. If the local-part contains any non-ASCII characters, it SHOULD be normalized using the Unicode Normalization Form C from [UNICODE]. Recommended normalization rules can be found in Section 10.1 of [RFC6530].

3. ローカル部分に非ASCII文字が含まれている場合は、[UNICODE]のUnicode正規化形式Cを使用して正規化する必要があります。推奨される正規化ルールは、[RFC6530]のセクション10.1にあります。

4. The local-part is hashed using the SHA2-256 [RFC5754] algorithm, with the hash truncated to 28 octets and represented in its hexadecimal representation, to become the left-most label in the prepared domain name.

4. ローカル部分は、SHA2-256 [RFC5754]アルゴリズムを使用してハッシュされ、ハッシュは28オクテットに切り捨てられ、16進表記で表され、準備されたドメイン名の左端のラベルになります。

5. The string "_smimecert" becomes the second left-most label in the prepared domain name.

5. 文字列 "_smimecert"は、準備されたドメイン名の左から2番目のラベルになります。

6. The domain name (the "right-hand side" of the email address, called the "domain" in [RFC5322]) is appended to the result of step 5 to complete the prepared domain name.

6. ドメイン名（[RFC5322]では「ドメイン」と呼ばれる、電子メールアドレスの「右側」）がステップ5の結果に追加され、準備されたドメイン名が完成します。

For example, to request an SMIMEA resource record for a user whose email address is "hugh@example.com", an SMIMEA query would be placed for the following QNAME: "c93f1e400f26708f98cb19d936620da35eec8f72e57 f9eec01c1afd6._smimecert.example.com".

たとえば、メールアドレスが「hugh@example.com」であるユーザーのSMIMEAリソースレコードをリクエストするには、次のQNAMEに対してSMIMEAクエリを配置します：「c93f1e400f26708f98cb19d936620da35eec8f72e57 f9eec01c1afd6._smimecert.example.com」。

4. Email Address Variants and Internationalization Considerations

4. メールアドレスのバリエーションと国際化に関する考慮事項

Mail systems usually handle variant forms of local-parts. The most common variants are upper and lower case, often automatically corrected when a name is recognized as such. Other variants include systems that ignore "noise" characters such as dots, so that local-parts 'johnsmith' and 'John.Smith' would be equivalent. Many systems allow "extensions" such as 'john-ext' or 'mary+ext' where 'john' or 'mary' is treated as the effective local-part, and the 'ext' is passed to the recipient for further handling. This can complicate finding the SMIMEA record associated with the dynamically created email address.

メールシステムは通常、ローカルパーツのさまざまな形式を処理します。最も一般的なバリエーションは大文字と小文字で、多くの場合、名前がそのように認識されると自動的に修正されます。他のバリアントには、ドットなどの「ノイズ」文字を無視するシステムが含まれるため、ローカルパーツの「johnsmith」と「John.Smith」は同等になります。多くのシステムでは、「john-ext」や「mary + ext」などの「拡張子」を使用できます。「john」または「mary」は有効なローカル部分として扱われ、「ext」は受信者に渡されてさらに処理されます。これにより、動的に作成された電子メールアドレスに関連付けられたSMIMEAレコードの検索が複雑になる可能性があります。

[RFC5321] and its predecessors have always made it clear that only the recipient MTA is allowed to interpret the local-part of an address. Therefore, sending MUAs and MTAs supporting this specification MUST NOT perform any kind of mapping rules based on the email address. In order to improve the chances of finding SMIMEA resource records for a particular local-part, domains that allow variant forms (such as treating local-parts as case-insensitive) might publish SMIMEA resource records for all variants of local-parts, might publish variants on first use (for example, a webmail provider that also controls DNS for a domain can publish variants as used by owner of a particular local-part), or might just publish SMIMEA resource records for the most common variants.

[RFC5321]とその前身は常に、受信者のMTAだけがアドレスのローカル部分を解釈できることを明確にしてきました。したがって、この仕様をサポートするMUAおよびMTAを送信しても、電子メールアドレスに基づいて、あらゆる種類のマッピングルールを実行してはなりません（MUST NOT）。特定のローカルパーツのSMIMEAリソースレコードを見つける可能性を高めるために、バリアントフォーム（ローカルパーツを大文字と小文字を区別しないものとして扱うなど）を許可するドメインは、ローカルパーツのすべてのバリアントのSMIMEAリソースレコードを発行し、初めて使用するバリアント（たとえば、ドメインのDNSも制御するWebメールプロバイダーは、特定のローカルパーツの所有者が使用するバリアントを公開できます）、または最も一般的なバリアントのSMIMEAリソースレコードを公開するだけかもしれません。

Section 3 above defines how the local-part is used to determine the location in which one looks for an SMIMEA resource record. Given the variety of local-parts seen in email, designing a good experiment for this is difficult as a) some current implementations are known to lowercase at least US-ASCII local-parts, b) we know from (many) other situations that any strategy based on guessing and making multiple DNS queries is not going to achieve consensus for good reasons, and c) the underlying issues are just hard -- see Section 10.1 of [RFC6530] for discussion of just some of the issues that would need to be tackled to fully address this problem.

上記のセクション3では、ローカルパーツを使用して、SMIMEAリソースレコードを探す場所を決定する方法を定義しています。電子メールで見られるさまざまなローカルパーツを考えると、a）現在の実装では少なくともUS-ASCIIローカルパーツを小文字にすることがわかっているb）他の状況（多くの）から、複数のDNSクエリの推測と作成に基づく戦略では、十分な理由でコンセンサスが得られません。c）根本的な問題は非常に難しいです。[RFC6530]のセクション10.1を参照してください。この問題に完全に取り組むために取り組みました。

However, while this specification is not the place to try to address these issues with local-parts, doing so is also not required to determine the outcome of this experiment. If this experiment succeeds, then further work on email addresses with non-ASCII local-parts will be needed, and that would be better based on the findings from this experiment, rather than doing nothing or starting this experiment based on a speculative approach to what is a very complex topic.

ただし、この仕様はローカルパーツに関するこれらの問題に対処するための場所ではありませんが、この実験の結果を判断するためにそうする必要もありません。この実験が成功した場合は、ASCII以外のローカルパーツを含む電子メールアドレスでさらに作業が必要になります。これは、何もしないか、何を行うかの推測アプローチに基づいてこの実験を開始するのではなく、この実験の結果に基づいて行う方が良いでしょう。非常に複雑なトピックです。

5. Mandatory-to-Implement Features

5. 必須の機能

S/MIME MUAs conforming to this specification MUST be able to correctly interpret SMIMEA records with certificate usages 0, 1, 2, and 3. S/MIME MUAs conforming to this specification MUST be able to compare a certificate association with a certificate offered by another S/MIME MUA using selector types 0 and 1, and matching type 0 (no hash used) and matching type 1 (SHA-256), and SHOULD be able to make such comparisons with matching type 2 (SHA-512).

この仕様に準拠するS / MIME MUAは、SMIMEAレコードを証明書の使用法0、1、2、および3で正しく解釈できなければなりません。この仕様に準拠するS / MIME MUAは、証明書の関連付けを別の証明書が提供する証明書と比較できる必要がありますセレクタータイプ0および1、一致するタイプ0（ハッシュを使用しない）および一致するタイプ1（SHA-256）を使用するS / MIME MUA。一致するタイプ2（SHA-512）でこのような比較を行うことができる必要があります（SHOULD）。

S/MIME MUAs conforming to this specification MUST be able to interpret any S/MIME capabilities (defined in [RFC4262]) in any certificates that it receives through SMIMEA records.

この仕様に準拠するS / MIME MUAは、SMIMEAレコードを介して受信する証明書内のS / MIME機能（[RFC4262]で定義）を解釈できなければなりません（MUST）。

6. Application Use of S/MIME Certificate Associations

6. S / MIME証明書関連付けのアプリケーション使用

The SMIMEA record allows an application or service to obtain an S/MIME certificate or public key and use it for verifying a digital signature or encrypting a message to the public key. The DNS answer MUST pass DNSSEC validation; if DNSSEC validation reaches any state other than "Secure" (as specified in [RFC4035]), the DNSSEC validation MUST be treated as a failure.

SMIMEAレコードを使用すると、アプリケーションまたはサービスはS / MIME証明書または公開鍵を取得し、デジタル署名の検証や公開鍵へのメッセージの暗号化に使用できます。 DNS回答はDNSSEC検証に合格する必要があります。 DNSSEC検証が（[RFC4035]で指定されているように）「セキュア」以外の状態に達した場合、DNSSEC検証は失敗として扱われなければなりません（MUST）。

If no S/MIME certificates are known for an email address, an SMIMEA DNS lookup MAY be performed to seek the certificate or public key that corresponds to that email address. This can then be used to verify a received signed message or can be used to send out an encrypted email message. An application whose attempt fails to retrieve a DNSSEC-verified SMIMEA resource record from the DNS should remember that failed attempt and not retry it for some time. This will avoid sending out a DNS request for each email message the application is sending out; such DNS requests constitute a privacy leak.

電子メールアドレスのS / MIME証明書がわからない場合は、SMIMEA DNSルックアップを実行して、その電子メールアドレスに対応する証明書または公開キーを探すことができます。これは、受信した署名付きメッセージを検証するために使用するか、暗号化された電子メールメッセージを送信するために使用できます。 DNSSECで検証されたSMIMEAリソースレコードのDNSからの取得に失敗したアプリケーションは、失敗した試行を記憶し、しばらくの間再試行しないでください。これにより、アプリケーションが送信する電子メールメッセージごとにDNS要求を送信する必要がなくなります。このようなDNS要求はプライバシーリークを構成します。

7. Certificate Size and DNS

7. 証明書のサイズとDNS

Due to the expected size of the SMIMEA record, applications SHOULD use TCP -- not UDP -- to perform queries for the SMIMEA resource record.

SMIMEAレコードの予想サイズにより、アプリケーションは、SMIMEAリソースレコードのクエリを実行するために、UDPではなくTCPを使用する必要があります（SHOULD）。

Although the reliability of the transport of large DNS resource records has improved in the last years, it is still recommended to keep the DNS records as small as possible without sacrificing the security properties of the public key. The algorithm type and key size of certificates should not be modified to accommodate this section.

大規模なDNSリソースレコードの転送の信頼性はここ数年で向上していますが、公開キーのセキュリティプロパティを犠牲にすることなく、DNSレコードをできるだけ小さくすることをお勧めします。証明書のアルゴリズムタイプとキーサイズは、このセクションに対応するために変更しないでください。

8. IANA Considerations

8. IANAに関する考慮事項

This document uses a new DNS RRtype, SMIMEA, whose value (53) was allocated by IANA from the "Resource Record (RR) TYPEs" subregistry of the "Domain Name System (DNS) Parameters" registry.

このドキュメントでは、新しいDNS RRtype、SMIMEAを使用しています。その値（53）は、IANAによって「ドメインネームシステム（DNS）パラメータ」レジストリの「リソースレコード（RR）TYPEs」サブレジストリから割り当てられました。

9. Security Considerations

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

Client treatment of any information included in the trust anchor is a matter of local policy. This specification does not mandate that such information be inspected or validated by the domain name administrator.

トラストアンカーに含まれる情報のクライアントの扱いは、ローカルポリシーの問題です。この仕様では、そのような情報をドメイン名管理者が検査または検証することを義務付けていません。

DNSSEC does not protect the queries from pervasive monitoring as defined in [RFC7258]. Since DNS queries are currently mostly unencrypted, a query to look up a target SMIMEA record could reveal that a user using the (monitored) recursive DNS server is attempting to send encrypted email to a target.

DNSSECは、[RFC7258]で定義されているように、クエリを広範囲にわたる監視から保護しません。 DNSクエリは現在ほとんどが暗号化されていないため、ターゲットのSMIMEAレコードを検索するクエリで、（監視された）再帰DNSサーバーを使用しているユーザーが暗号化された電子メールをターゲットに送信しようとしていることがわかる場合があります。

Various components could be responsible for encrypting an email message to a target recipient. It could be done by the sender's MUA, an MUA plugin, or the sender's MTA. Each of these have their own characteristics. An MUA can ask the user to make a decision before continuing. The MUA can either accept or refuse a message. The MTA might deliver the message as is or encrypt the message before delivering. Each of these components should attempt to encrypt an unencrypted outgoing message whenever possible.

さまざまなコンポーネントが、対象の受信者への電子メールメッセージの暗号化を担当する可能性があります。これは、送信者のMUA、MUAプラグイン、または送信者のMTAによって実行できます。これらにはそれぞれ独自の特性があります。 MUAは続行する前にユーザーに決定を求めることができます。 MUAはメッセージを受け入れることも拒否することもできます。 MTAはメッセージをそのまま配信するか、配信前にメッセージを暗号化します。これらの各コンポーネントは、可能な限り、暗号化されていない送信メッセージを暗号化しようとする必要があります。

In theory, two different local-parts could hash to the same value. This document assumes that such a hash collision has a negligible chance of happening.

理論的には、2つの異なるローカル部分が同じ値にハッシュされる可能性があります。このドキュメントでは、このようなハッシュ衝突が発生する可能性はごくわずかであると想定しています。

If an obtained S/MIME certificate is revoked or expired, that certificate MUST NOT be used, even if that would result in sending a message in plaintext.

取得したS / MIME証明書が取り消されたり期限切れになったりした場合、メッセージがプレーンテキストで送信されることになっても、その証明書を使用してはなりません（MUST NOT）。

Anyone who can obtain a DNSSEC private key of a domain name via coercion, theft, or brute-force calculations can replace any SMIMEA record in that zone and all of the delegated child zones. Any future messages encrypted with the malicious SMIMEA key could then be read. Therefore, a certificate or key obtained from a DNSSEC-validated SMIMEA record can only be trusted as much as the DNS domain can be trusted.

強制、盗難、または総当たりの計算を介してドメイン名のDNSSEC秘密キーを取得できるユーザーは、そのゾーンとすべての委任された子ゾーンのSMIMEAレコードを置き換えることができます。その後、悪意のあるSMIMEAキーで暗号化されたメッセージを読み取ることができます。したがって、DNSSEC検証済みのSMIMEAレコードから取得した証明書またはキーは、DNSドメインが信頼できる場合にのみ信頼できます。

Organizations that are required to be able to read everyone's encrypted email should publish the escrow key as the SMIMEA record. Mail servers of such organizations MAY optionally re-encrypt the message to the individual's S/MIME key. This case can be considered a special case of the key-replacement attack described above.

暗号化された全員のメールを読むことができる必要がある組織は、エスクローキーをSMIMEAレコードとして公開する必要があります。そのような組織のメールサーバーは、オプションで、メッセージを個人のS / MIMEキーに再暗号化できます。このケースは、上記のキー置換攻撃の特別なケースと考えることができます。

9.1. Response Size

9.1. 応答サイズ

To prevent amplification attacks, an Authoritative DNS server MAY wish to prevent returning SMIMEA records over UDP unless the source IP address has been confirmed with DNS Cookies [RFC7873]. If a query is received via UDP without source IP address verification, the server MUST NOT return REFUSED but answer the query with an empty answer section and the truncation flag set ("TC=1").

増幅攻撃を防ぐために、権威DNSサーバーは、送信元IPアドレスがDNS Cookie [RFC7873]で確認されていない限り、UDMI経由でSMIMEAレコードを返さないようにする必要があります。送信元IPアドレスを検証せずにUDP経由でクエリを受信した場合、サーバーはREFUSEDを返してはならず、空の応答セクションと切り捨てフラグセット（ "TC = 1"）でクエリに応答する必要があります。

9.2. Email Address Information Leak

9.2. メールアドレス情報漏洩

The hashing of the local-part in this document is not a security feature. Publishing SMIMEA records will create a list of hashes of valid email addresses, which could simplify obtaining a list of valid email addresses for a particular domain. It is desirable to not ease the harvesting of email addresses where possible.

このドキュメントのローカル部分のハッシュはセキュリティ機能ではありません。 SMIMEAレコードを公開すると、有効なメールアドレスのハッシュのリストが作成されます。これにより、特定のドメインの有効なメールアドレスのリストを簡単に取得できます。可能な限りメールアドレスの収集を容易にしないことが望ましいです。

The domain name part of the email address is not used as part of the hash so that hashes can be used in multiple zones deployed using DNAME [RFC6672]. This makes it slightly easier and cheaper to brute-force the SHA2-256 hashes into common and short local-parts, as single rainbow tables [Rainbow] can be reused across domains. This can be somewhat countered by using NSEC3 [RFC5155].

電子メールアドレスのドメイン名部分はハッシュの一部として使用されないため、DNAME [RFC6672]を使用して展開された複数のゾーンでハッシュを使用できます。これにより、単一のレインボーテーブル[Rainbow]をドメイン間で再利用できるため、SHA2-256ハッシュを共通のローカルパーツと短いローカルパーツにブルートフォースするのが少し簡単かつ安価になります。これは、NSEC3 [RFC5155]を使用することにより、多少対抗できます。

DNS zones that are signed with DNSSEC using NSEC [RFC4033] for denial of existence are susceptible to zone walking, a mechanism that allows someone to enumerate all the SMIMEA hashes in a zone. This can be used in combination with previously hashed common or short local-parts (in rainbow tables) to deduce valid email addresses. DNSSEC-signed zones using NSEC3 for denial of existence instead of NSEC are significantly harder to brute-force after performing a zone walk.

存在拒否のためにNSEC [RFC4033]を使用してDNSSECで署名されたDNSゾーンは、ゾーンウォーキングの影響を受けます。これは、誰かがゾーン内のすべてのSMIMEAハッシュを列挙できるメカニズムです。これは、以前にハッシュされた共通または短いローカル部分（レインボーテーブル内）と組み合わせて使用して、有効な電子メールアドレスを推測できます。 NSECの代わりにNSEC3を使用して存在を拒否するDNSSEC署名ゾーンは、ゾーンウォークを実行した後、ブルートフォースを実行することが著しく困難になります。

10. References

10. 参考文献

10.1. Normative References

10.1. 引用文献

[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>。

[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 Securityの紹介と要件」、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>。

[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>。

[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <http://www.rfc-editor.org/info/rfc5751>.

[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、DOI 10.17487 / RFC5751、2010年1月、<http：//www.rfc- editor.org/info/rfc5751>。

[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 2010, <http://www.rfc-editor.org/info/rfc5754>.

[RFC5754] Turner、S。、「Using SHA2 Algorithms with Cryptographic Message Syntax」、RFC 5754、DOI 10.17487 / RFC5754、2010年1月、<http://www.rfc-editor.org/info/rfc5754>。

[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>。

[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, <http://www.rfc-editor.org/info/rfc7671>.

[RFC7671] Dukhovni、V。およびW. Hardaker、「DNSベースの名前付きエンティティの認証（DANE）プロトコル：更新と運用ガイダンス」、RFC 7671、DOI 10.17487 / RFC7671、2015年10月、<http：// www。 rfc-editor.org/info/rfc7671>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「あいまいな大文字と小文字のRFC 2119キーワード」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<http://www.rfc-editor.org/info/ rfc8174>。

10.2. Informative References

10.2. 参考引用

[Rainbow] Oechslin, P., "Making a Faster Cryptanalytic Time-Memory Trade-Off", DOI 10.1007/978-3-540-45146-4_36, 2003, <http://www.iacr.org/cryptodb/archive/2003/ CRYPTO/1615/1615.ps>.

[Rainbow] Oechslin、P。、「Make a Faster Cryptanalytic Time-Memory Trade-Off」、DOI 10.1007 / 978-3-540-45146-4_36、2003、<http://www.iacr.org/cryptodb/archive / 2003 / CRYPTO / 1615 / 1615.ps>。

[RFC4262] Santesson, S., "X.509 Certificate Extension for Secure/ Multipurpose Internet Mail Extensions (S/MIME) Capabilities", RFC 4262, DOI 10.17487/RFC4262, December 2005, <http://www.rfc-editor.org/info/rfc4262>.

[RFC4262] Santesson、S。、「X / 509 Certificate Extension for Secure / Multipurpose Internet Mail Extensions（S / MIME）Capabilities」、RFC 4262、DOI 10.17487 / RFC4262、2005年12月、<http：//www.rfc-editor .org / info / rfc4262>。

[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, <http://www.rfc-editor.org/info/rfc5155>.

[RFC5155] Laurie、B.、Sisson、G.、Arends、R。、およびD. Blacka、「DNS Security（DNSSEC）Hashed Authenticated Denial of Existence」、RFC 5155、DOI 10.17487 / RFC5155、2008年3月、<http： //www.rfc-editor.org/info/rfc5155>。

[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.

[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、DOI 10.17487 / RFC5321、2008年10月、<http://www.rfc-editor.org/info/rfc5321>。

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.

[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<http://www.rfc-editor.org/info/rfc5322>。

[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, February 2012, <http://www.rfc-editor.org/info/rfc6530>.

[RFC6530] Klensin、J。およびY. Ko、「国際化電子メールの概要とフレームワーク」、RFC 6530、DOI 10.17487 / RFC6530、2012年2月、<http://www.rfc-editor.org/info/rfc6530>。

[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, <http://www.rfc-editor.org/info/rfc6672>.

[RFC6672] Rose、S。およびW. Wijngaards、「DNAME Redirection in the DNS」、RFC 6672、DOI 10.17487 / RFC6672、2012年6月、<http://www.rfc-editor.org/info/rfc6672>。

[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 2014, <http://www.rfc-editor.org/info/rfc7218>.

[RFC7218] Gudmundsson、O。、「名前付きエンティティのDNSベースの認証（DANE）に関する会話を簡素化するための頭字語の追加」、RFC 7218、DOI 10.17487 / RFC7218、2014年4月、<http://www.rfc-editor.org / info / rfc7218>。

[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.

[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<http://www.rfc-editor.org/info/rfc7258 >。

[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, <http://www.rfc-editor.org/info/rfc7873>.

[RFC7873] Eastlake 3rd、D。およびM. Andrews、「ドメインネームシステム（DNS）Cookie」、RFC 7873、DOI 10.17487 / RFC7873、2016年5月、<http://www.rfc-editor.org/info/rfc7873 >。

[RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP", RFC 7929, DOI 10.17487/RFC7929, August 2016, <http://www.rfc-editor.org/info/rfc7929>.

[RFC7929] Wouters、P。、「OpenPGPのDNSベースの名前付きエンティティ（DANE）バインディングの認証」、RFC 7929、DOI 10.17487 / RFC7929、2016年8月、<http://www.rfc-editor.org/info/ rfc7929>。

[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.

[UNICODE] Unicodeコンソーシアム、「The Unicode Standard」、<http://www.unicode.org/versions/latest/>。

Acknowledgements

謝辞

A great deal of material in this document is copied from [RFC7929]. That material was created by Paul Wouters and other participants in the IETF DANE WG.

このドキュメントの多くの資料は、[RFC7929]からコピーされています。その資料は、Paul WoutersおよびIETF DANE WGの他の参加者によって作成されました。

Brian Dickson, Stephen Farrell, Miek Gieben, Martin Pels, and Jim Schaad contributed technical ideas and support to this document.

Brian Dickson、Stephen Farrell、Miek Gieben、Martin Pels、およびJim Schaadは、このドキュメントに技術的なアイデアとサポートを提供しました。

Authors' Addresses

著者のアドレス

Paul Hoffman ICANN

ポール・ホフマンICANN

   Email: paul.hoffman@icann.org

Jakob Schlyter Kirei AB

じゃこｂＳｃｈｌｙてｒきれいあＢ

   Email: jakob@kirei.se