[要約] RFC 7671は、DNSベースの認証に関するプロトコルであるDANEの更新と運用ガイダンスを提供しています。その目的は、DANEの実装と運用に関する情報を提供し、セキュリティと信頼性を向上させることです。
Internet Engineering Task Force (IETF) V. Dukhovni
Request for Comments: 7671 Two Sigma
Updates: 6698 W. Hardaker
Category: Standards Track Parsons
ISSN: 2070-1721 October 2015
The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance
名前付きエンティティのDNSベースの認証（DANE）プロトコル：更新と運用ガイダンス
Abstract
概要
This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience. It also contains guidance for implementers, operators, and protocol developers who want to use DANE records.
このドキュメントでは、その後の実装経験に基づいて、DNSベースの名前付きエンティティの認証（DANE）TLSA仕様（RFC 6698）を明確にし、更新します。また、DANEレコードを使用する実装者、オペレーター、およびプロトコル開発者向けのガイダンスも含まれています。
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/rfc7671.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7671で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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 ....................................................3
1.1. Terminology ................................................4
2. DANE TLSA Record Overview .......................................5
2.1. Example TLSA Record ........................................6
3. DANE TLS Requirements ...........................................6
4. DANE Certificate Usage Selection Guidelines .....................7
4.1. Opportunistic Security and PKIX Usages .....................7
4.2. Interaction with Certificate Transparency ..................8
4.3. Switching from/to PKIX-TA/EE to/from DANE-TA/EE ............9
5. Certificate-Usage-Specific DANE Updates and Guidelines ..........9
5.1. Certificate Usage DANE-EE(3) ...............................9
5.2. Certificate Usage DANE-TA(2) ..............................11
5.3. Certificate Usage PKIX-EE(1) ..............................15
5.4. Certificate Usage PKIX-TA(0) ..............................15
6. Service Provider and TLSA Publisher Synchronization ............16
7. TLSA Base Domain and CNAMEs ....................................18
8. TLSA Publisher Requirements ....................................19
8.1. Key Rollover with Fixed TLSA Parameters ...................20
8.2. Switching to DANE-TA(2) from DANE-EE(3) ...................21
8.3. Switching to New TLSA Parameters ..........................22
8.4. TLSA Publisher Requirements: Summary ......................23
9. Digest Algorithm Agility .......................................23
10. General DANE Guidelines .......................................25
10.1. DANE DNS Record Size Guidelines ..........................25
10.2. Certificate Name Check Conventions .......................26
10.3. Design Considerations for Protocols Using DANE ...........27
11. Note on DNSSEC Security .......................................28
12. Summary of Updates to RFC 6698 ................................29
13. Operational Considerations ....................................29
14. Security Considerations .......................................30
15. References ....................................................30
15.1. Normative References .....................................30
15.2. Informative References ...................................32
Acknowledgements ..................................................33
Authors' Addresses ................................................33
The DNS-Based Authentication of Named Entities (DANE) specification [RFC6698] introduces the DNS "TLSA" resource record (RR) type ("TLSA" is not an acronym). TLSA records associate a certificate or a public key of an end-entity or a trusted issuing authority with the corresponding Transport Layer Security (TLS) [RFC5246] or Datagram Transport Layer Security (DTLS) [RFC6347] transport endpoint. DANE relies on the DNS Security Extensions (DNSSEC) [RFC4033]. DANE TLSA records validated by DNSSEC can be used to augment or replace the use of trusted public Certification Authorities (CAs).
名前付きエンティティのDNSベース認証（DANE）仕様[RFC6698]では、DNSの「TLSA」リソースレコード（RR）タイプが導入されています（「TLSA」は頭字語ではありません）。 TLSAレコードは、エンドエンティティまたは信頼できる発行機関の証明書または公開キーを、対応するトランスポート層セキュリティ（TLS）[RFC5246]またはデータグラムトランスポート層セキュリティ（DTLS）[RFC6347]トランスポートエンドポイントに関連付けます。 DANEはDNS Security Extensions（DNSSEC）[RFC4033]に依存しています。 DNSSECによって検証されたDANE TLSAレコードを使用して、信頼された公的認証局（CA）の使用を増強または置き換えることができます。
The TLS and DTLS protocols provide secured TCP and UDP communication, respectively, over IP. In the context of this document, channel security is assumed to be provided by TLS or DTLS. By convention, "TLS" will be used throughout this document; unless otherwise specified, the text applies equally well to DTLS over UDP. Used without authentication, TLS provides protection only against eavesdropping through its use of encryption. With authentication, TLS also protects the transport against man-in-the-middle (MITM) attacks.
TLSおよびDTLSプロトコルは、IPを介したセキュアなTCPおよびUDP通信をそれぞれ提供します。このドキュメントのコンテキストでは、チャネルセキュリティはTLSまたはDTLSによって提供されると想定されています。慣例により、このドキュメント全体で「TLS」が使用されます。特に明記しない限り、テキストはUDP上のDTLSにも同様に適用されます。認証なしで使用されるTLSは、暗号化の使用による盗聴に対してのみ保護を提供します。認証により、TLSは中間者（MITM）攻撃からトランスポートを保護します。
[RFC6698] defines three TLSA record fields: the first with four possible values, the second with two, and the third with three. These yield 24 distinct combinations of TLSA record types. This document recommends a smaller set of best-practice combinations of these fields to simplify protocol design, implementation, and deployment.
[RFC6698]は、3つのTLSAレコードフィールドを定義しています。1つは4つの可能な値、2つ目は2つの値、3つ目は3つの値です。これらにより、TLSAレコードタイプの24の異なる組み合わせが生成されます。このドキュメントでは、プロトコルの設計、実装、および展開を簡素化するために、これらのフィールドのベストプラクティスの組み合わせの少数のセットを推奨しています。
This document explains and recommends DANE-specific strategies to simplify "virtual hosting", where a single Service Provider transport endpoint simultaneously supports multiple hosted Customer Domains.
このドキュメントでは、「仮想ホスティング」を簡素化するためのDANE固有の戦略について説明し、推奨しています。この場合、単一のサービスプロバイダーのトランスポートエンドポイントが、ホストされている複数のカスタマードメインを同時にサポートします。
Other related documents that build on [RFC6698] are [RFC7673] and [RFC7672].
[RFC6698]に基づいて構築されている他の関連ドキュメントは、[RFC7673]と[RFC7672]です。
Section 12 summarizes the normative updates this document makes to [RFC6698].
セクション12は、このドキュメントが[RFC6698]に対して行う規範的な更新を要約しています。
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 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
The following terms are used throughout this document:
このドキュメントでは、次の用語が使用されています。
Web PKI: The Public Key Infrastructure (PKI) model employed by browsers to authenticate web servers. This employs a set of trusted public CAs to vouch for the authenticity of public keys associated with a particular party (the subject).
Web PKI：ブラウザがWebサーバーを認証するために使用する公開キー基盤（PKI）モデル。これは、特定のパーティ（サブジェクト）に関連付けられた公開鍵の信頼性を保証するために、信頼された公開CAのセットを採用しています。
Service Provider: A company or organization that offers to host a service on behalf of the owner of a Customer Domain. The original domain name associated with the service often remains under the control of the customer. Connecting applications may be directed to the Service Provider via a redirection RR. Example redirection records include MX, SRV, and CNAME. The Service Provider frequently provides services for many customers and needs to ensure that the TLS credentials presented to connecting applications authenticate it as a valid server for the requested domain.
サービスプロバイダー：カスタマードメインの所有者に代わってサービスをホストすることを申し出る会社または組織。多くの場合、サービスに関連付けられている元のドメイン名は、顧客の管理下にあります。接続アプリケーションは、リダイレクトRRを介してサービスプロバイダーに送信される場合があります。リダイレクトレコードの例には、MX、SRV、およびCNAMEが含まれます。サービスプロバイダーは多くの顧客にサービスを提供することが多く、接続するアプリケーションに提示されるTLS資格情報が、要求されたドメインの有効なサーバーとして認証されることを確認する必要があります。
Customer Domain: As described above, a TLS client may be interacting with a service that is hosted by a third party. This document refers to the domain name used to locate the service (prior to any redirection) as the "Customer Domain".
顧客ドメイン：上記のように、TLSクライアントはサードパーティによってホストされているサービスと対話している可能性があります。このドキュメントでは、サービスの検索に使用されるドメイン名（リダイレクト前）を「顧客ドメイン」と呼びます。
TLSA Publisher: The entity responsible for publishing a TLSA record within a DNS zone. This zone will be assumed DNSSEC-signed and validatable to a trust anchor (TA), unless otherwise specified. If the Customer Domain is not outsourcing its DNS service, the TLSA Publisher will be the customer itself. Otherwise, the TLSA Publisher may be the operator of the outsourced DNS service.
TLSAパブリッシャー：DNSゾーン内でのTLSAレコードの公開を担当するエンティティ。このゾーンは、特に指定のない限り、DNSSECで署名され、トラストアンカー（TA）に対して検証可能であると見なされます。お客様ドメインがDNSサービスをアウトソーシングしていない場合、TLSAパブリッシャーはお客様自身になります。それ以外の場合は、TLSAパブリッシャーが外部委託DNSサービスのオペレーターである可能性があります。
Public key: The term "public key" is shorthand for the subjectPublicKeyInfo component of a PKIX [RFC5280] certificate.
公開鍵：「公開鍵」という用語は、PKIX [RFC5280]証明書のsubjectPublicKeyInfoコンポーネントの短縮形です。
SNI: The Server Name Indication (SNI) TLS protocol extension allows a TLS client to request a connection to a particular service name of a TLS server ([RFC6066], Section 3). Without this TLS extension, a TLS server has no choice but to offer a certificate with a default list of server names, making it difficult to host multiple Customer Domains at the same IP-address-based TLS service endpoint (i.e., provide "secure virtual hosting").
SNI：サーバー名表示（SNI）TLSプロトコル拡張により、TLSクライアントはTLSサーバーの特定のサービス名への接続をリクエストできます（[RFC6066]、セクション3）。このTLS拡張がないと、TLSサーバーはデフォルトのサーバー名のリストで証明書を提供するしかなく、同じIPアドレスベースのTLSサービスエンドポイントで複数のカスタマードメインをホストすることが困難になります（つまり、「安全な仮想ホスティング」）。
TLSA parameters: In [RFC6698], the TLSA record is defined to consist of four fields. The first three of these are numeric parameters that specify the meaning of the data in the fourth and final field. This document refers to the first three fields as "TLSA parameters", or sometimes just "parameters" when obvious from context.
TLSAパラメータ：[RFC6698]では、TLSAレコードは4つのフィールドで構成されるように定義されています。これらの最初の3つは、4番目の最後のフィールドのデータの意味を指定する数値パラメーターです。このドキュメントでは、最初の3つのフィールドを「TLSAパラメータ」、または文脈から明らかな場合は単に「パラメータ」と呼ぶことがあります。
TLSA base domain: Per Section 3 of [RFC6698], TLSA records are stored at a DNS domain name that is a combination of a port and protocol prefix and a "base domain". In [RFC6698], the "base domain" is the fully qualified domain name of the TLS server. This document modifies the TLSA record lookup strategy to prefer the fully CNAME-expanded name of the TLS server, provided that expansion is "secure" (DNSSEC validated) at each stage of the expansion, and TLSA records are published for this fully expanded name. Thus, the "TLSA base domain" is either the fully CNAME-expanded TLS server name or otherwise the initial fully qualified TLS server name, whichever is used in combination with a port and protocol prefix to obtain the TLSA RRset.
TLSAベースドメイン：[RFC6698]のセクション3に従い、TLSAレコードは、ポートとプロトコルのプレフィックスと「ベースドメイン」を組み合わせたDNSドメイン名で保存されます。 [RFC6698]では、「ベースドメイン」はTLSサーバーの完全修飾ドメイン名です。このドキュメントでは、展開の各段階で展開が「安全」（DNSSEC検証済み）であり、この完全に展開された名前に対してTLSAレコードが公開されている場合、TLSサーバーの完全なCNAME展開名を優先するようにTLSAレコード検索戦略を変更します。したがって、「TLSAベースドメイン」は、完全にCNAMEで拡張されたTLSサーバー名か、そうでなければ初期の完全修飾TLSサーバー名のいずれかであり、ポートとプロトコルプレフィックスと組み合わせてTLSA RRsetを取得するために使用されます。
DANE TLSA [RFC6698] specifies a protocol for publishing TLS server certificate associations via DNSSEC [RFC4033] [RFC4034] [RFC4035]. DANE TLSA records consist of four fields. The record type is determined by the values of the first three fields, which this document refers to as the "TLSA parameters" to distinguish them from the fourth and last field. The numeric values of these parameters were given symbolic names in [RFC7218]. The four fields are as follows:
DANE TLSA [RFC6698]は、DNSSEC [RFC4033] [RFC4034] [RFC4035]を介してTLSサーバー証明書の関連付けを公開するためのプロトコルを指定します。 DANE TLSAレコードは、4つのフィールドで構成されています。レコードタイプは、最初の3つのフィールドの値によって決まります。このドキュメントでは、これらのフィールドを「TLSAパラメータ」と呼び、4番目と最後のフィールドと区別します。これらのパラメータの数値は、[RFC7218]でシンボリック名を与えられました。 4つのフィールドは次のとおりです。
The Certificate Usage field: Section 2.1.1 of [RFC6698] specifies four values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-EE(3). There is an additional private-use value: PrivCert(255), which, given its private scope, shall not be considered further in this document. All other values are reserved for use by future specifications.
[Certificate Usage]フィールド：[RFC6698]のセクション2.1.1は、PKIX-TA（0）、PKIX-EE（1）、DANE-TA（2）、DANE-EE（3）の4つの値を指定します。追加の私的使用値があります。PrivCert（255）は、そのプライベートスコープを考えると、このドキュメントではこれ以上考慮されません。他のすべての値は、将来の仕様で使用するために予約されています。
The Selector field: Section 2.1.2 of [RFC6698] specifies two values: Cert(0) and SPKI(1). There is an additional private-use value: PrivSel(255). All other values are reserved for use by future specifications.
[セレクタ]フィールド：[RFC6698]のセクション2.1.2は、Cert（0）とSPKI（1）の2つの値を指定します。追加の私用値があります：PrivSel（255）。他のすべての値は、将来の仕様で使用するために予約されています。
The Matching Type field: Section 2.1.3 of [RFC6698] specifies three values: Full(0), SHA2-256(1), and SHA2-512(2). There is an additional private-use value: PrivMatch(255). All other values are reserved for use by future specifications.
[マッチングタイプ]フィールド：[RFC6698]のセクション2.1.3は、Full（0）、SHA2-256（1）、SHA2-512（2）の3つの値を指定します。追加の私用値があります：PrivMatch（255）。他のすべての値は、将来の仕様で使用するために予約されています。
The Certificate Association Data field: See Section 2.1.4 of [RFC6698]. This field stores the full value or digest of the certificate or subject public key as determined by the matching type and selector, respectively.
Certificate Association Dataフィールド：[RFC6698]のセクション2.1.4を参照してください。このフィールドには、証明書またはサブジェクトの公開鍵の完全な値またはダイジェストが、それぞれ一致するタイプとセレクターによって決定されたとおりに格納されます。
In the Matching Type field, of the two digest algorithms -- SHA2-256(1) and SHA2-512(2) -- as of the time of this writing, only SHA2-256(1) is mandatory to implement. Clients SHOULD implement SHA2-512(2), but servers SHOULD NOT exclusively publish SHA2-512(2) digests. The digest algorithm agility protocol defined in Section 9 SHOULD be used by clients to decide how to process TLSA RRsets that employ multiple digest algorithms. Server operators MUST publish TLSA RRsets that are compatible (see Section 8) with digest algorithm agility (Section 9).
[マッチングタイプ]フィールドでは、2つのダイジェストアルゴリズム（SHA2-256（1）およびSHA2-512（2））のうち、この記事の執筆時点では、SHA2-256（1）のみを実装する必要があります。クライアントはSHA2-512（2）を実装する必要がありますが、サーバーはSHA2-512（2）ダイジェストのみを公開するべきではありません（SHOULD NOT）。セクション9で定義されているダイジェストアルゴリズムの俊敏性プロトコルは、クライアントが複数のダイジェストアルゴリズムを使用するTLSA RRsetの処理方法を決定するために使用する必要があります（SHOULD）。サーバーオペレーターは、ダイジェストアルゴリズムの俊敏性（セクション9）と互換性のある（セクション8を参照）TLSA RRsetを公開する必要があります。
In the example TLSA record below, the TLSA certificate usage is DANE-TA(2), the selector is Cert(0), and the matching type is SHA2-256(1). The last field is the Certificate Association Data field, which in this case contains the SHA2-256 digest of the server certificate.
以下のTLSAレコードの例では、TLSA証明書の使用法はDANE-TA（2）、セレクターはCert（0）、一致するタイプはSHA2-256（1）です。最後のフィールドは、Certificate Association Dataフィールドです。この場合、サーバー証明書のSHA2-256ダイジェストが含まれています。
_25._tcp.mail.example.com. IN TLSA 2 0 1 ( E8B54E0B4BAA815B06D3462D65FBC7C0 CF556ECCF9F5303EBFBB77D022F834C0 )
_25._tcp.mail.example.com。 IN TLSA 2 0 1（E8B54E0B4BAA815B06D3462D65FBC7C0 CF556ECCF9F5303EBFBB77D022F834C0）
[RFC6698] does not discuss what versions of TLS are required when using DANE records. This document specifies that TLS clients that support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support TLS 1.2 or later.
[RFC6698]は、DANEレコードを使用するときに必要なTLSのバージョンについては説明していません。このドキュメントでは、DANE / TLSAをサポートするTLSクライアントが少なくともTLS 1.0をサポートする必要があり、TLS 1.2以降をサポートする必要があることを明記しています。
TLS clients using DANE MUST support the SNI extension of TLS [RFC6066]. Servers MAY support SNI and respond with a matching certificate chain but MAY also ignore SNI and respond with a default certificate chain. When a server supports SNI but is not configured with a certificate chain that exactly matches the client's SNI extension, the server SHOULD respond with another certificate chain (a default or closest match). This is because clients might support more than one server name but can only put a single name in the SNI extension.
DANEを使用するTLSクライアントは、TLSのSNI拡張をサポートする必要があります[RFC6066]。サーバーはSNIをサポートし、一致する証明書チェーンで応答してもよいが、SNIを無視してデフォルトの証明書チェーンで応答してもよい（MAY）。サーバーがSNIをサポートしているが、クライアントのSNI拡張と完全に一致する証明書チェーンが構成されていない場合、サーバーは別の証明書チェーン（デフォルトまたは最も近い一致）で応答する必要があります（SHOULD）。これは、クライアントが複数のサーバー名をサポートする可能性があるが、SNI拡張に単一の名前しか配置できないためです。
As mentioned in Section 2, the TLSA Certificate Usage field takes one of four possible values. With PKIX-TA(0) and PKIX-EE(1), the validation of peer certificate chains requires additional preconfigured CA TAs that are mutually trusted by the operators of the TLS server and client. With DANE-TA(2) and DANE-EE(3), no preconfigured CA TAs are required and the published DANE TLSA records are sufficient to verify the peer's certificate chain.
セクション2で述べたように、TLSA証明書の使用状況フィールドは、4つの可能な値のいずれかを取ります。 PKIX-TA（0）およびPKIX-EE（1）を使用する場合、ピア証明書チェーンの検証には、TLSサーバーおよびクライアントのオペレーターによって相互に信頼される追加の事前設定されたCA TAが必要です。 DANE-TA（2）とDANE-EE（3）では、事前設定されたCA TAは不要であり、公開されたDANE TLSAレコードはピアの証明書チェーンを検証するのに十分です。
Standards for application protocols that employ DANE TLSA can specify more specific guidance than [RFC6698] or this document. Such application-specific standards need to carefully consider which set of DANE certificate usages to support. Simultaneous support for all four usages is NOT RECOMMENDED for DANE clients. When all four usages are supported, an attacker capable of compromising the integrity of DNSSEC needs only to replace the server's TLSA RRset with one that lists suitable DANE-EE(3) or DANE-TA(2) records, effectively bypassing any added verification via public CAs. In other words, when all four usages are supported, PKIX-TA(0) and PKIX-EE(1) offer only illusory incremental security over DANE-TA(2) and DANE-EE(3).
DANE TLSAを使用するアプリケーションプロトコルの標準では、[RFC6698]またはこのドキュメントよりも具体的なガイダンスを指定できます。このようなアプリケーション固有の標準では、サポートするDANE証明書の使用のセットを慎重に検討する必要があります。 DANEクライアントでは、4つの使用法すべてを同時にサポートすることはお勧めしません。 4つすべての使用法がサポートされている場合、DNSSECの整合性を危うくする可能性のある攻撃者は、サーバーのTLSA RRsetを適切なDANE-EE（3）またはDANE-TA（2）レコードをリストするものに置き換えるだけで、追加の検証を効果的にバイパスできます。パブリックCA。つまり、4つの使用法すべてがサポートされている場合、PKIX-TA（0）とPKIX-EE（1）は、DANE-TA（2）とDANE-EE（3）に比べて架空の増分セキュリティしか提供しません。
Designs in which clients support just the DANE-TA(2) and DANE-EE(3) certificate usages are RECOMMENDED. With DANE-TA(2) and DANE-EE(3), clients don't need to track a large changing list of X.509 TAs in order to successfully authenticate servers whose certificates are issued by a CA that is brand new or not widely trusted.
クライアントがDANE-TA（2）およびDANE-EE（3）の証明書の使用のみをサポートする設計が推奨されます。 DANE-TA（2）およびDANE-EE（3）を使用すると、クライアントは、証明書が新しいかどうかに関係なくCAによって発行されたサーバーを正常に認証するために、X.509 TAの大きな変更リストを追跡する必要がありません広く信頼されています。
The DNSSEC TLSA records for servers MAY include both sets of usages if the server needs to support a mixture of clients, some supporting one pair of usages and some the other.
サーバーのDNSSEC TLSAレコードには、サーバーがクライアントの混合をサポートする必要がある場合、両方の使用法のセットが含まれる場合があります。
When the client's protocol design is based on "Opportunistic Security" (OS) [RFC7435] and the use of authentication is based on the presence of server TLSA records, it is especially important to avoid the PKIX-EE(1) and PKIX-TA(0) certificate usages.
クライアントのプロトコル設計が "Opportunistic Security"（OS）[RFC7435]に基づいており、認証の使用がサーバーのTLSAレコードの存在に基づいている場合、PKIX-EE（1）およびPKIX-TAを避けることが特に重要です。 （0）証明書の使用法。
When authenticated TLS is used opportunistically based on the presence of DANE TLSA records and no secure TLSA records are present, unauthenticated TLS is used if possible, and if TLS is not possible, perhaps even cleartext. However, if usable secure TLSA records are published, then authentication MUST succeed. Also, outside the browser space, there is no preordained canon of trusted CAs, and in any case there is no security advantage in using PKIX-TA(0) or PKIX-EE(1) when the DANE-TA(2) and DANE-EE(3) usages are also supported (as an attacker who can compromise DNS can replace the former with the latter).
DANE TLSAレコードの存在に基づいて認証済みTLSが日和見的に使用され、セキュアなTLSAレコードが存在しない場合、可能であれば非認証TLSが使用され、TLSが不可能な場合はおそらくクリアテキストも使用されます。ただし、使用可能な安全なTLSAレコードが公開されている場合、認証は成功する必要があります。また、ブラウザスペースの外では、信頼できるCAの規定された基準はなく、DANE-TA（2）とDANEの場合にPKIX-TA（0）またはPKIX-EE（1）を使用してもセキュリティ上の利点はありません。 -EE（3）の使用法もサポートされています（DNSを侵害できる攻撃者は前者を後者に置き換えることができるため）。
Authentication via the PKIX-TA(0) and PKIX-EE(1) certificate usages is more brittle; the client and server need to happen to agree on a mutually trusted CA, but with OS the client is just trying to protect the communication channel at the request of the server and would otherwise be willing to use cleartext or unauthenticated TLS. The use of fragile mechanisms (like public CA authentication for some unspecified set of trusted CAs) is not sufficiently reliable for an OS client to honor the server's request for authentication. OS needs to be non-intrusive and to require few, if any, workarounds for valid but mismatched peers.
PKIX-TA（0）およびPKIX-EE（1）証明書の使用による認証は、より脆弱です。クライアントとサーバーは、相互に信頼されたCAに同意する必要がありますが、OSの場合、クライアントはサーバーの要求で通信チャネルを保護しようとするだけであり、それ以外の場合はクリアテキストまたは非認証TLSを使用します。脆弱なメカニズムの使用（特定されていない信頼されたCAのセットに対するパブリックCA認証など）は、OSクライアントがサーバーの認証要求を受け入れるのに十分な信頼性がありません。 OSは非侵入型である必要があり、有効であるが不一致のピアに対する回避策があったとしても少数しか必要としません。
Because the PKIX-TA(0) and PKIX-EE(1) usages offer no more security and are more prone to failure, they are a poor fit for OS and SHOULD NOT be used in that context.
PKIX-TA（0）およびPKIX-EE（1）を使用すると、セキュリティが強化されず、障害が発生しやすくなるため、OSには適しておらず、そのような状況では使用しないでください。
Certificate Transparency (CT) [RFC6962] defines an experimental approach that could be used to mitigate the risk of rogue or compromised public CAs issuing unauthorized certificates. This section clarifies the interaction of the experimental CT and DANE. This section may need to be revised in light of any future Standards Track version of CT.
証明書の透明性（CT）[RFC6962]は、不正な証明書や侵害されたパブリックCAが不正な証明書を発行するリスクを軽減するために使用できる実験的なアプローチを定義しています。このセクションでは、実験的なCTとDANEの相互作用を明らかにします。このセクションは、CTの将来のStandards Trackバージョンに照らして改訂する必要があるかもしれません。
When a server is authenticated via a DANE TLSA RR with TLSA certificate usage DANE-EE(3), the domain owner has directly specified the certificate associated with the given service without reference to any public CA. Therefore, when a TLS client authenticates the TLS server via a TLSA record with usage DANE-EE(3), CT checks SHOULD NOT be performed. Publication of the server certificate or public key (digest) in a TLSA record in a DNSSEC-signed zone by the domain owner assures the TLS client that the certificate is not an unauthorized certificate issued by a rogue CA without the domain owner's consent.
サーバーがDANE TLSA RRを介してTLSA証明書の使用DANE-EE（3）で認証されている場合、ドメイン所有者は、パブリックCAを参照せずに、特定のサービスに関連付けられた証明書を直接指定しています。したがって、TLSクライアントが使用法DANE-EE（3）のTLSAレコードを介してTLSサーバーを認証する場合、CTチェックは実行されるべきではありません（SHOULD NOT）。ドメイン所有者がDNSSEC署名ゾーンのTLSAレコードにサーバー証明書または公開鍵（ダイジェスト）を公開すると、TLSクライアントは、証明書がドメイン所有者の同意なしに不正なCAによって発行された不正な証明書ではないことを保証します。
When a server is authenticated via a DANE TLSA record with TLSA usage DANE-TA(2) and the server certificate does not chain to a known public root CA, CT cannot apply (CT logs only accept chains that start with a known public root). Since TLSA certificate usage DANE-TA(2) is generally intended to support non-public TAs, TLS clients SHOULD NOT perform CT checks with usage DANE-TA(2).
サーバーがTLSA使用DANE-TA（2）のDANE TLSAレコードを介して認証され、サーバー証明書が既知のパブリックルートCAにチェーンしない場合、CTは適用できません（CTログは、既知のパブリックルートで始まるチェーンのみを受け入れます） 。 TLSA証明書の使用法DANE-TA（2）は一般に非公開TAをサポートすることを目的としているため、TLSクライアントは使用法DANE-TA（2）でCTチェックを実行すべきではありません（SHOULD NOT）。
With certificate usages PKIX-TA(0) and PKIX-EE(1), CT applies just as it would without DANE. TLSA records of this type only constrain which CAs are acceptable in PKIX validation. All checks used in the absence of DANE still apply when validating certificate chains with DANE PKIX-TA(0) and PKIX-EE(1) constraints.
証明書の使用法がPKIX-TA（0）およびPKIX-EE（1）の場合、CTはDANEがない場合と同様に適用されます。このタイプのTLSAレコードは、PKIX検証で受け入れ可能なCAのみを制約します。 DANEがない場合に使用されるすべてのチェックは、DANE PKIX-TA（0）およびPKIX-EE（1）制約を使用して証明書チェーンを検証する場合にも適用されます。
The choice of preferred certificate usages may need to change as an application protocol evolves. When transitioning between PKIX-TA/ PKIX-EE and DANE-TA/DANE-EE, clients begin to enable support for the new certificate usage values. If the new preferred certificate usages are PKIX-TA/EE, this requires installing and managing the appropriate set of CA TAs. During this time, servers will publish both types of TLSA records. At some later time, when the vast majority of servers have published the new preferred TLSA records, clients can stop supporting the legacy certificate usages. Similarly, servers can stop publishing legacy TLSA records once the vast majority of clients support the new certificate usages.
推奨される証明書の使用法の選択は、アプリケーションプロトコルの進化に応じて変更する必要がある場合があります。 PKIX-TA / PKIX-EEとDANE-TA / DANE-EEの間で移行すると、クライアントは新しい証明書の使用値のサポートを有効にし始めます。新しい優先証明書の使用法がPKIX-TA / EEの場合は、適切なCA TAセットをインストールして管理する必要があります。この間、サーバーは両方のタイプのTLSAレコードを公開します。しばらくすると、サーバーの大部分が新しい優先TLSAレコードを公開したときに、クライアントはレガシー証明書の使用法のサポートを停止できます。同様に、クライアントの大多数が新しい証明書の使用をサポートすると、サーバーはレガシーTLSAレコードの公開を停止できます。
The four certificate usage values from the TLSA record -- DANE-EE(3), DANE-TA(2), PKIX-EE(1), and PKIX-TA(0) -- are discussed below.
TLSAレコードからの4つの証明書の使用法の値（DANE-EE（3）、DANE-TA（2）、PKIX-EE（1）、およびPKIX-TA（0））については、以下で説明します。
In this section, the meaning of DANE-EE(3) is updated from [RFC6698] to specify that peer identity matching and validity period enforcement are based solely on the TLSA RRset properties. This document also extends [RFC6698] to cover the use of DANE authentication of raw public keys [RFC7250] via TLSA records with certificate usage DANE-EE(3) and selector SPKI(1).
このセクションでは、DANE-EE（3）の意味が[RFC6698]から更新され、ピアIDの一致と有効期間の強制がTLSA RRsetプロパティのみに基づくことを指定しています。このドキュメントはまた、[RFC6698]を拡張して、証明書の使用法DANE-EE（3）およびセレクターSPKI（1）を使用したTLSAレコードを介した生の公開鍵[RFC7250]のDANE認証の使用をカバーします。
Authentication via certificate usage DANE-EE(3) TLSA records involves simply checking that the server's leaf certificate matches the TLSA record. In particular, the binding of the server public key to its name is based entirely on the TLSA record association. The server MUST be considered authenticated even if none of the names in the certificate match the client's reference identity for the server. This simplifies the operation of servers that host multiple Customer Domains, as a single certificate can be associated with multiple domains without having to match each of the corresponding reference identifiers.
証明書の使用による認証DANE-EE（3）TLSAレコードは、サーバーのリーフ証明書がTLSAレコードと一致することを確認するだけです。特に、サーバーの公開鍵とその名前のバインドは、完全にTLSAレコードの関連付けに基づいています。証明書の名前がサーバーのクライアントの参照IDと一致しない場合でも、サーバーは認証済みであると見なされなければなりません（MUST）。これにより、単一の証明書を対応する各参照識別子と一致させる必要なく複数のドメインに関連付けることができるため、複数の顧客ドメインをホストするサーバーの操作が簡素化されます。
; Multiple Customer Domains hosted by an example.net
; Service Provider:
;
www.example.com. IN CNAME ex-com.example.net.
www.example.org. IN CNAME ex-org.example.net.
;
; In the provider's DNS zone, a single certificate and TLSA
; record support multiple Customer Domains, greatly simplifying
; "virtual hosting".
;
ex-com.example.net. IN A 192.0.2.1
ex-org.example.net. IN A 192.0.2.1
_443._tcp.ex-com.example.net. IN CNAME tlsa._dane.example.net.
_443._tcp.ex-org.example.net. IN CNAME tlsa._dane.example.net.
tlsa._dane.example.net. IN TLSA 3 1 1 e3b0c44298fc1c14...
Also, with DANE-EE(3), the expiration date of the server certificate MUST be ignored. The validity period of the TLSA record key binding is determined by the validity period of the TLSA record DNSSEC signatures. Validity is reaffirmed on an ongoing basis by continuing to publish the TLSA record and signing the zone in which the record is contained, rather than via dates "set in stone" in the certificate. The expiration becomes a reminder to the administrator that it is likely time to rotate the key, but missing the date no longer causes an outage. When keys are rotated (for whatever reason), it is important to follow the procedures outlined in Section 8.
また、DANE-EE（3）では、サーバー証明書の有効期限を無視する必要があります。 TLSAレコードのキーバインディングの有効期間は、TLSAレコードのDNSSEC署名の有効期間によって決まります。有効性は、TLSAレコードの公開を継続し、証明書に「確定した」日付ではなく、そのレコードが含まれているゾーンに署名することにより、継続的に再確認されます。有効期限は、キーをローテーションする時期である可能性が高いことを管理者に思い出させるものになりますが、日付を指定しなくても停止することはありません。 （何らかの理由で）キーがローテーションされる場合は、セクション8で説明されている手順に従うことが重要です。
If a server uses just DANE-EE(3) TLSA records and all its clients are DANE clients, the server need not employ SNI (i.e., it may ignore the client's SNI message) even when the server is known via multiple domain names that would otherwise require separate certificates. It is instead sufficient for the TLSA RRsets for all the domain names in question to match the server's default certificate. For application protocols where the server name is obtained indirectly via SRV records, MX records, or similar records, it is simplest to publish a single hostname as the target server name for all the hosted domains.
サーバーがDANE-EE（3）TLSAレコードのみを使用し、そのすべてのクライアントがDANEクライアントである場合、サーバーが複数のドメイン名を介して認識されている場合でも、サーバーはSNIを使用する必要はありません（つまり、クライアントのSNIメッセージを無視できます）。それ以外の場合は、個別の証明書が必要です。代わりに、問題のすべてのドメイン名のTLSA RRsetがサーバーのデフォルトの証明書と一致することで十分です。サーバー名がSRVレコード、MXレコード、または同様のレコードを介して間接的に取得されるアプリケーションプロトコルの場合、単一のホスト名をすべてのホストドメインのターゲットサーバー名として公開するのが最も簡単です。
In organizations where it is practical to make coordinated changes in DNS TLSA records before server key rotation, it is generally best to publish end-entity DANE-EE(3) certificate associations in preference to other choices of certificate usage. DANE-EE(3) TLSA records support multiple server names without SNI, don't suddenly stop working when leaf or intermediate certificates expire, and don't fail when a server operator neglects to include all the required issuer certificates in the server certificate chain.
サーバーキーのローテーションの前にDNS TLSAレコードを調整して変更することが実際的である組織では、証明書の使用法の他の選択肢よりも、エンドエンティティDANE-EE（3）証明書の関連付けを公開するのが一般的に最善です。 DANE-EE（3）TLSAレコードはSNIなしで複数のサーバー名をサポートし、リーフまたは中間証明書が期限切れになったときに突然動作を停止せず、サーバーオペレーターが必要なすべての発行者証明書をサーバー証明書チェーンに含めることを怠ったときに失敗しない。
More specifically, it is RECOMMENDED that at most sites TLSA records published for DANE servers be "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Selector SPKI(1) is chosen because it is compatible with raw public keys [RFC7250] and the resulting TLSA record need not change across certificate renewals with the same key. Matching type SHA2-256(1) is chosen because all DANE implementations are required to support SHA2-256. This TLSA record type easily supports hosting arrangements with a single certificate matching all hosted domains. It is also the easiest to implement correctly in the client.
より具体的には、ほとんどのサイトでDANEサーバー用に公開されたTLSAレコードは「DANE-EE（3）SPKI（1）SHA2-256（1）」レコードであることが推奨されます。セレクターSPKI（1）が選択された理由は、生の公開鍵[RFC7250]と互換性があり、結果として得られるTLSAレコードが、同じ鍵を持つ証明書の更新全体で変更される必要がないためです。 SHA2-256をサポートするにはすべてのDANE実装が必要であるため、マッチングタイプSHA2-256（1）が選択されています。このTLSAレコードタイプは、ホストされているすべてのドメインに一致する単一の証明書を使用して、ホストの配置を簡単にサポートします。また、クライアントに正しく実装するのが最も簡単です。
Clients that support raw public keys can use DANE TLSA records with certificate usage DANE-EE(3) and selector SPKI(1) to authenticate servers that negotiate the use of raw public keys. Provided the server adheres to the requirements of Section 8, the fact that raw public keys are not compatible with any other TLSA record types will not get in the way of successful authentication. Clients that employ DANE to authenticate the peer server SHOULD NOT negotiate the use of raw public keys unless the server's TLSA RRset includes "DANE-EE(3) SPKI(1)" TLSA records.
生の公開鍵をサポートするクライアントは、証明書の使用法DANE-EE（3）およびセレクターSPKI（1）でDANE TLSAレコードを使用して、生の公開鍵の使用をネゴシエートするサーバーを認証できます。サーバーがセクション8の要件に準拠している場合、生の公開鍵が他のTLSAレコードタイプと互換性がないという事実は、認証の成功を妨げません。 DANEを使用してピアサーバーを認証するクライアントは、サーバーのTLSA RRsetに「DANE-EE（3）SPKI（1）」TLSAレコードが含まれていない限り、生の公開鍵の使用をネゴシエートしないでください。
While it is, in principle, also possible to authenticate raw public keys via "DANE-EE(3) Cert(0) Full(0)" records by extracting the public key from the certificate in DNS, extracting just the public key from a "3 0 0" TLSA record requires extra logic on clients that not all implementations are expected to provide. Servers that wish to support [RFC7250] raw public keys need to publish TLSA records with a certificate usage of DANE-EE(3) and a selector of SPKI(1).
原則として、DNSの証明書から公開鍵を抽出し、証明書から公開鍵のみを抽出することにより、「DANE-EE（3）Cert（0）Full（0）」レコードを介して生の公開鍵を認証することも可能です。 "3 0 0" TLSAレコードは、すべての実装が提供するとは限らない追加のロジックをクライアントに要求します。 [RFC7250]の未加工の公開鍵をサポートするサーバーは、DANE-EE（3）の証明書の使用法とSPKI（1）のセレクターを使用してTLSAレコードを公開する必要があります。
While DANE-EE(3) TLSA records are expected to be by far the most prevalent, as explained in Section 5.2, DANE-TA(2) records are a valid alternative for sites with many DANE services. Note, however, that virtual hosting is more complex with DANE-TA(2). Also, with DANE-TA(2), server operators MUST ensure that the server is configured with a sufficiently complete certificate chain and need to remember to replace certificates prior to their expiration dates.
DANE-EE（3）TLSAレコードは、セクション5.2で説明されているように、圧倒的に最も普及していると予想されますが、DANE-TA（2）レコードは、多くのDANEサービスを持つサイトの有効な代替手段です。ただし、仮想ホスティングはDANE-TA（2）の方が複雑であることに注意してください。また、DANE-TA（2）を使用する場合、サーバーオペレーターはサーバーが十分に完全な証明書チェーンで構成されていること、および有効期限の前に証明書を置き換えることを忘れないようにする必要があります。
This section updates [RFC6698] by specifying a new operational requirement for servers publishing TLSA records with a usage of DANE-TA(2): such servers MUST include the TA certificate in their TLS server certificate message unless all such TLSA records are "2 0 0" records that publish the server certificate in full.
このセクションは、DANE-TA（2）を使用してTLSAレコードを公開するサーバーの新しい運用要件を指定することによって[RFC6698]を更新します。そのようなすべてのTLSAレコードが「2 0」でない限り、そのようなサーバーはTLSサーバー証明書メッセージにTA証明書を含める必要がありますサーバー証明書を完全に公開する0レコード。
Some domains may prefer to avoid the operational complexity of publishing unique TLSA RRs for each TLS service. If the domain employs a common issuing CA to create certificates for multiple TLS services, it may be simpler to publish the issuing authority as a TA for the certificate chains of all relevant services. The TLSA query domain (TLSA base domain with port and protocol prefix labels) for each service issued by the same TA may then be set to a CNAME alias that points to a common TLSA RRset that matches the TA. For example:
一部のドメインは、TLSサービスごとに一意のTLSA RRを公開するという運用上の複雑さを回避することを好む場合があります。ドメインが共通の発行CAを使用して複数のTLSサービスの証明書を作成する場合、すべての関連サービスの証明書チェーンのTAとして発行機関を公開する方が簡単な場合があります。同じTAによって発行された各サービスのTLSAクエリドメイン（ポートとプロトコルのプレフィックスラベルが付いたTLSAベースドメイン）は、TAに一致する共通のTLSA RRsetを指すCNAMEエイリアスに設定できます。例えば：
; Two servers, each with its own certificate, that share
; a common issuer (TA).
;
www1.example.com. IN A 192.0.2.1
www2.example.com. IN A 192.0.2.2
_443._tcp.www1.example.com. IN CNAME tlsa._dane.example.com.
_443._tcp.www2.example.com. IN CNAME tlsa._dane.example.com.
tlsa._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14...
The above configuration simplifies server key rotation, because while the servers continue to receive new certificates from a CA matched by the shared (target of the CNAMEs) TLSA record, server certificates can be updated without making any DNS changes. As the list of active issuing CAs changes, the shared TLSA record will be updated (much less frequently) by the administrators who manage the CAs. Those administrators still need to perform TLSA record updates with care, as described in Section 8.
上記の構成により、サーバーは引き続き共有された（CNAMEのターゲット）TLSAレコードと一致するCAから新しい証明書を受け取りますが、DNSを変更せずにサーバー証明書を更新できるため、サーバーキーのローテーションが簡略化されます。アクティブな発行CAのリストが変更されると、CAを管理する管理者によって共有TLSAレコードが更新されます（はるかに少ない頻度）。これらの管理者は、セクション8で説明されているように、TLSAレコードの更新を慎重に実行する必要があります。
With usage DANE-TA(2), the server certificates will need to have names that match one of the client's reference identifiers (see [RFC6125]). When hosting multiple unrelated Customer Domains (that can't all appear in a single certificate), such a server SHOULD employ SNI to select the appropriate certificate to present to the client.
DANE-TA（2）を使用する場合、サーバー証明書には、クライアントの参照識別子の1つと一致する名前が必要です（[RFC6125]を参照）。複数の無関係な顧客ドメイン（すべてが単一の証明書に含まれるわけではない）をホストする場合、そのようなサーバーはSNIを使用して、クライアントに提示する適切な証明書を選択する必要があります（SHOULD）。
TLSA records with a matching type of Full(0) are NOT RECOMMENDED. While these potentially obviate the need to transmit the TA certificate in the TLS server certificate message, client implementations may not be able to augment the server certificate chain with the data obtained from DNS, especially when the TLSA record supplies a bare key (selector SPKI(1)). Since the server will need to transmit the TA certificate in any case, server operators SHOULD publish TLSA records with a matching type other than Full(0) and avoid potential DNS interoperability issues with large TLSA records containing full certificates or keys (see Section 10.1.1).
一致するタイプがFull（0）のTLSAレコードは推奨されません。これらにより、TLSサーバー証明書メッセージでTA証明書を送信する必要がなくなる可能性がありますが、クライアント実装では、特にTLSAレコードがベアキー（セレクターSPKI（ 1））。サーバーはいずれにせよTA証明書を送信する必要があるため、サーバーオペレーターはFull（0）以外の一致するタイプでTLSAレコードを公開し、完全な証明書またはキーを含む大きなTLSAレコードでの潜在的なDNS相互運用性の問題を回避する必要があります（セクション10.1を参照）。 1）。
TLSA Publishers employing DANE-TA(2) records SHOULD publish records with a selector of Cert(0). Such TLSA records are associated with the whole TA certificate, not just with the TA public key. In particular, when authenticating the peer certificate chain via such a TLSA record, the client SHOULD apply any relevant constraints from the TA certificate, such as, for example, path length constraints.
DANE-TA（2）レコードを使用するTLSAパブリッシャーは、Cert（0）のセレクターを使用してレコードをパブリッシュする必要があります（SHOULD）。このようなTLSAレコードは、TA公開鍵だけでなく、TA証明書全体に関連付けられています。特に、そのようなTLSAレコードを介してピア証明書チェーンを認証する場合、クライアントは、パスの長さの制約など、TA証明書からの関連する制約を適用する必要があります（SHOULD）。
While a selector of SPKI(1) may also be employed, the resulting TLSA record will not specify the full TA certificate content, and elements of the TA certificate other than the public key become mutable. This may, for example, enable a subsidiary CA to issue a chain that violates the TA's path length or name constraints.
SPKI（1）のセレクターも使用できますが、結果のTLSAレコードは完全なTA証明書の内容を指定せず、公開鍵以外のTA証明書の要素は変更可能になります。これにより、たとえば、下位CAがTAのパス長または名前の制約に違反するチェーンを発行できるようになります。
With DANE-TA(2), a complication arises when the TA certificate is omitted from the server's certificate chain, perhaps on the basis of Section 7.4.2 of [RFC5246]:
DANE-TA（2）を使用すると、おそらく[RFC5246]のセクション7.4.2に基づいて、TA証明書がサーバーの証明書チェーンから省略されると、問題が発生します。
The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.
送信者の証明書はリストの最初に来る必要があります。次の各証明書は、その前の証明書を直接証明する必要があります。証明書の検証ではルートキーを個別に配布する必要があるため、ルートの証明機関を指定する自己署名証明書は、リモートエンドがそれを検証するためにすでに所有している必要があるという前提の下で、チェーンから省略される場合があります。
With TLSA certificate usage DANE-TA(2), there is no expectation that the client is preconfigured with the TA certificate. In fact, client implementations are free to ignore all locally configured TAs when processing usage DANE-TA(2) TLSA records and may rely exclusively on the certificates provided in the server's certificate chain. But, with a digest in the TLSA record, the TLSA record contains neither the full TA certificate nor the full public key. If the TLS server's certificate chain does not contain the TA certificate, DANE clients will be unable to authenticate the server.
TLSA証明書の使用法DANE-TA（2）では、クライアントがTA証明書で事前構成されていることは想定されていません。実際、クライアントの実装は、使用法DANE-TA（2）TLSAレコードを処理するときにローカルに構成されたすべてのTAを自由に無視でき、サーバーの証明書チェーンで提供される証明書のみに依存する場合があります。ただし、TLSAレコードにダイジェストがあるため、TLSAレコードには完全なTA証明書も完全な公開鍵も含まれていません。 TLSサーバーの証明書チェーンにTA証明書が含まれていない場合、DANEクライアントはサーバーを認証できません。
TLSA Publishers that publish TLSA certificate usage DANE-TA(2) associations with a selector of SPKI(1) or with a digest-based matching type (not Full(0)) MUST ensure that the corresponding server is configured to also include the TA certificate in its TLS handshake certificate chain, even if that certificate is a self-signed root CA and would have been optional in the context of the existing public CA PKI.
TLSA証明書の使用法DANE-TA（2）アソシエーションを発行するTLSAパブリッシャーは、SPKI（1）のセレクターまたはダイジェストベースのマッチングタイプ（Full（0）ではない）を使用して、対応するサーバーがTAも含むように構成されていることを確認する必要があります。その証明書が自己署名ルートCAであり、既存のパブリックCA PKIのコンテキストではオプションであったとしても、TLSハンドシェイク証明書チェーン内の証明書。
Only when the server TLSA record includes a "DANE-TA(2) Cert(0) Full(0)" TLSA record containing a full TA certificate is the TA certificate optional in the server's TLS certificate message. This is also the only type of DANE-TA(2) record for which the client MUST be able to verify the server's certificate chain even if the TA certificate appears only in DNS and is absent from the TLS handshake server certificate message.
サーバーのTLSAレコードに「DANE-TA（2）Cert（0）Full（0）」が含まれる場合のみ、完全なTA証明書を含むTLSAレコードは、サーバーのTLS証明書メッセージでオプションのTA証明書になります。これは、TA証明書がDNSにのみ表示され、TLSハンドシェイクサーバー証明書メッセージに存在しない場合でも、クライアントがサーバーの証明書チェーンを検証できる唯一のタイプのDANE-TA（2）レコードでもあります。
TLSA records with TLSA certificate usage DANE-TA(2), selector SPKI(1), and a matching type of Full(0) publish the full public key of a TA via DNS. In Section 6.1.1 of [RFC5280], the definition of a TA consists of the following four parts:
TLSA証明書の使用法DANE-TA（2）、セレクターSPKI（1）、および一致するタイプFull（0）のTLSAレコードは、DNSを介してTAの完全な公開鍵を公開します。 [RFC5280]のセクション6.1.1では、TAの定義は次の4つの部分で構成されています。
1. the trusted issuer name,
1. 信頼できる発行者名、
2. the trusted public key algorithm,
2. 信頼できる公開鍵アルゴリズム、
3. the trusted public key, and
3. 信頼できる公開鍵、および
4. optionally, the trusted public key parameters associated with the public key.
4. 必要に応じて、公開鍵に関連付けられた信頼できる公開鍵パラメータ。
Items 2-4 are precisely the contents of the subjectPublicKeyInfo published in the TLSA record. The issuer name is not included in the subjectPublicKeyInfo.
項目2〜4は、正確にはTLSAレコードで公開されたsubjectPublicKeyInfoの内容です。発行者名は、subjectPublicKeyInfoに含まれていません。
With TLSA certificate usage DANE-TA(2), the client may not have the associated TA certificate and cannot generally verify whether or not a particular certificate chain is "issued by" the TA described in the TLSA record.
TLSA証明書の使用法DANE-TA（2）を使用すると、クライアントは関連付けられたTA証明書を持っていない可能性があり、通常、特定の証明書チェーンがTLSAレコードに記述されているTAによって「発行」されているかどうかを確認できません。
When the server certificate chain includes a CA certificate whose public key matches the TLSA record, the client can match that CA as the intended issuer. Otherwise, the client can only check that the topmost certificate in the server's chain is "signed by" the TA's public key in the TLSA record. Such a check may be difficult to implement and cannot be expected to be supported by all clients.
サーバー証明書チェーンに、公開鍵がTLSAレコードと一致するCA証明書が含まれている場合、クライアントはそのCAを目的の発行者として一致させることができます。それ以外の場合、クライアントは、サーバーのチェーン内の最上位の証明書がTLSAレコード内のTAの公開鍵に「署名されている」ことのみを確認できます。このようなチェックは実装が困難な場合があり、すべてのクライアントがサポートすることは期待できません。
Thus, servers cannot rely on "DANE-TA(2) SPKI(1) Full(0)" TLSA records to be sufficient to authenticate chains issued by the associated public key in the absence of a corresponding certificate in the server's TLS certificate message. Servers employing "2 1 0" TLSA records MUST include the corresponding TA certificate in their certificate chain.
したがって、サーバーは、「DANE-TA（2）SPKI（1）Full（0）」TLSAレコードに依存して、サーバーのTLS証明書メッセージに対応する証明書がない場合に、関連する公開鍵によって発行されたチェーンを認証するのに十分であるとは限りません。 "2 1 0" TLSAレコードを使用するサーバーは、対応するTA証明書を証明書チェーンに含める必要があります。
If none of the server's certificate chain elements match a public key specified in a TLSA record, and at least one "DANE-TA(2) SPKI(1) Full(0)" TLSA record is available, it is RECOMMENDED that clients check to see whether or not the topmost certificate in the chain is signed by the provided public key and has not expired, and in that case consider the server authenticated, provided the rest of the chain passes validation, including leaf certificate name checks.
サーバーの証明書チェーン要素のいずれもがTLSAレコードで指定された公開鍵と一致せず、少なくとも1つの「DANE-TA（2）SPKI（1）Full（0）」TLSAレコードが使用可能な場合、クライアントがチェックすることをお勧めしますチェーンの最上位の証明書が提供された公開鍵で署名されており、有効期限が切れていないかどうかを確認します。その場合、リーフ証明書名のチェックを含むチェーンの残りの部分が検証に合格した場合、サーバーが認証されていると見なします。
This certificate usage is similar to DANE-EE(3); but, in addition, PKIX verification is required. Therefore, name checks, certificate expiration, CT, etc. apply as they would without DANE.
この証明書の使用法はDANE-EE（3）に似ています。ただし、さらに、PKIX検証が必要です。したがって、名前のチェック、証明書の有効期限、CTなどは、DANEがない場合と同様に適用されます。
This section updates [RFC6698] by specifying new client implementation requirements. Clients that trust intermediate certificates MUST be prepared to construct longer PKIX chains than would be required for PKIX alone.
このセクションは、新しいクライアント実装要件を指定することによって[RFC6698]を更新します。中間証明書を信頼するクライアントは、PKIXのみに必要とされるよりも長いPKIXチェーンを構築する準備をしなければなりません。
TLSA certificate usage PKIX-TA(0) allows a domain to publish constraints on the set of PKIX CAs trusted to issue certificates for its TLS servers. A PKIX-TA(0) TLSA record matches PKIX-verified trust chains that contain an issuer certificate (root or intermediate) that matches its Certificate Association Data field (typically a certificate or digest).
TLSA証明書の使用PKIX-TA（0）を使用すると、ドメインは、TLSサーバーの証明書を発行することが信頼されているPKIX CAのセットに制約を公開できます。 PKIX-TA（0）TLSAレコードは、証明書関連付けデータフィールド（通常は証明書またはダイジェスト）と一致する発行者証明書（ルートまたは中間）を含むPKIX検証済み信頼チェーンと一致します。
PKIX-TA(0) requires more complex coordination (than with DANE-TA(2) or DANE-EE(3)) between the Customer Domain and the Service Provider in hosting arrangements. Thus, this certificate usage is NOT RECOMMENDED when the Service Provider is not also the TLSA Publisher (at the TLSA base domain obtained via CNAMEs, SRV records, or MX records).
PKIX-TA（0）は、ホスティング契約におけるカスタマードメインとサービスプロバイダーの間で（DANE-TA（2）またはDANE-EE（3）よりも）より複雑な調整を必要とします。したがって、サービスプロバイダーがTLSAパブリッシャーではない場合（CNAME、SRVレコード、またはMXレコードを介して取得されたTLSAベースドメインで）、この証明書の使用は推奨されません。
TLSA Publishers who publish TLSA records for a particular public root CA will expect that clients will only accept chains anchored at that root. It is possible, however, that the client's trusted certificate store includes some intermediate CAs, either with or without the corresponding root CA. When a client constructs a trust chain leading from a trusted intermediate CA to the server leaf certificate, such a "truncated" chain might not contain the trusted root published in the server's TLSA record.
特定のパブリックルートCAのTLSAレコードを発行するTLSAパブリッシャーは、クライアントがそのルートにアンカーされたチェーンのみを受け入れることを期待します。ただし、クライアントの信頼できる証明書ストアに、対応するルートCAの有無にかかわらず、いくつかの中間CAが含まれている可能性があります。クライアントが信頼された中間CAからサーバーリーフ証明書に至る信頼チェーンを構築する場合、そのような「切り捨てられた」チェーンには、サーバーのTLSAレコードで公開された信頼されたルートが含まれない場合があります。
If the omitted root is also trusted, the client may erroneously reject the server chain if it fails to determine that the shorter chain it constructed extends to a longer trusted chain that matches the TLSA record. Thus, when matching a usage PKIX-TA(0) TLSA record, so long as no matching certificate has yet been found, a client MUST continue extending the chain even after any locally trusted certificate is found. If no TLSA records have matched any of the elements of the chain and the trusted certificate found is not self-issued, the client MUST attempt to build a longer chain in case a certificate closer to the root matches the server's TLSA record.
省略されたルートも信頼されている場合、クライアントが構築した短いチェーンがTLSAレコードに一致する長い信頼チェーンに拡張されていると判断できない場合、クライアントはサーバーチェーンを誤って拒否する可能性があります。したがって、使用法のPKIX-TA（0）TLSAレコードを照合する場合、一致する証明書がまだ見つからない限り、ローカルで信頼された証明書が見つかった後でも、クライアントはチェーンを拡張し続ける必要があります。 TLSAレコードがチェーンのどの要素にも一致せず、見つかった信頼できる証明書が自己発行されていない場合、クライアントは、ルートに近い証明書がサーバーのTLSAレコードと一致する場合に備えて、より長いチェーンの構築を試行する必要があります。
Whenever possible, the TLSA Publisher and the Service Provider should be the same entity. Otherwise, they need to coordinate changes to ensure that TLSA records published by the TLSA Publisher don't fall out of sync with the server certificate used by the Service Provider. Such coordination is difficult, and service outages will result when coordination fails.
可能な限り、TLSAパブリッシャーとサービスプロバイダーは同じエンティティである必要があります。それ以外の場合は、TLSAパブリッシャーによって発行されたTLSAレコードが、サービスプロバイダーによって使用されるサーバー証明書と同期しないように変更を調整する必要があります。このような調整は困難であり、調整が失敗するとサービスが停止します。
Publishing the TLSA record in the Service Provider's zone avoids the complexity of bilateral coordination of server certificate configuration and TLSA record management. Even when the TLSA RRset has to be published in the Customer Domain's DNS zone (perhaps the client application does not "chase" CNAMEs to the TLSA base domain), it is possible to employ CNAME records to delegate the content of the TLSA RRset to a domain operated by the Service Provider.
サービスプロバイダーのゾーンでTLSAレコードを公開すると、サーバー証明書の構成とTLSAレコード管理の双方向の調整の複雑さが回避されます。 TLSA RRsetを顧客ドメインのDNSゾーンで公開する必要がある場合（おそらく、クライアントアプリケーションがCNAMEをTLSAベースドメインに「追跡」しない）でも、CNAMEレコードを使用してTLSA RRsetのコンテンツをaに委任することが可能です。サービスプロバイダーが運営するドメイン。
Only certificate usages DANE-EE(3) and DANE-TA(2) work well with TLSA CNAMEs across organizational boundaries. With PKIX-TA(0) or PKIX-EE(1), the Service Provider would need to obtain certificates in the name of the Customer Domain from a suitable public CA (securely impersonate the customer), or the customer would need to provision the relevant private keys and certificates at the Service Provider's systems.
証明書の使用法DANE-EE（3）およびDANE-TA（2）のみが、組織の境界を越えてTLSA CNAMEで適切に機能します。 PKIX-TA（0）またはPKIX-EE（1）を使用する場合、サービスプロバイダーは、適切なパブリックCAから顧客ドメインの名前で証明書を取得する必要があります（安全に顧客になりすます）。サービスプロバイダーのシステムでの関連する秘密鍵と証明書。
Certificate Usage DANE-EE(3): In this case, the Service Provider can publish a single TLSA RRset that matches the server certificate or public key digest. The same RRset works for all Customer Domains because name checks do not apply with DANE-EE(3) TLSA records (see Section 5.1). A Customer Domain can create a CNAME record pointing to the TLSA RRset published by the Service Provider.
証明書の使用DANE-EE（3）：この場合、サービスプロバイダーは、サーバー証明書または公開鍵ダイジェストと一致する単一のTLSA RRsetを公開できます。名前チェックはDANE-EE（3）TLSAレコードでは適用されないため、同じRRsetがすべてのカスタマードメインで機能します（セクション5.1を参照）。カスタマードメインは、サービスプロバイダーによって公開されたTLSA RRsetを指すCNAMEレコードを作成できます。
Certificate Usage DANE-TA(2): When the Service Provider operates a private CA, the Service Provider is free to issue a certificate bearing any customer's domain name. Without DANE, such a certificate would not pass trust verification, but with DANE, the customer's TLSA RRset that is aliased to the provider's TLSA RRset can delegate authority to the provider's CA for the corresponding service. The Service Provider can generate appropriate certificates for each customer and use the SNI information provided by clients to select the right certificate chain to present to each client.
証明書の使用DANE-TA（2）：サービスプロバイダーがプライベートCAを運用している場合、サービスプロバイダーは顧客のドメイン名が記載された証明書を自由に発行できます。 DANEがない場合、このような証明書は信頼検証に合格しませんが、DANEを使用すると、プロバイダーのTLSA RRsetにエイリアスされた顧客のTLSA RRsetは、対応するサービスのプロバイダーのCAに権限を委任できます。サービスプロバイダーは、顧客ごとに適切な証明書を生成し、クライアントから提供されたSNI情報を使用して、各クライアントに提示する適切な証明書チェーンを選択できます。
Below are example DNS records (assumed "secure" and shown without the associated DNSSEC information, such as record signatures) that illustrate both of the above models in the case of an HTTPS service whose clients all support DANE TLS. These examples work even with clients that don't "chase" CNAMEs when constructing the TLSA base domain (see Section 7 below).
以下は、すべてのクライアントがDANE TLSをサポートするHTTPSサービスの場合の上記の両方のモデルを示すDNSレコードの例（「セキュア」と想定され、レコード署名などの関連するDNSSEC情報なしで示されています）です。これらの例は、TLSAベースドメインの構築時にCNAMEを「追跡」しないクライアントでも機能します（以下のセクション7を参照）。
; The hosted web service is redirected via a CNAME alias.
; The associated TLSA RRset is also redirected via a CNAME alias.
;
; Certificate usage DANE-EE(3) makes it possible to deploy
; a single provider certificate for all Customer Domains.
;
www1.example.com. IN CNAME w1.example.net.
_443._tcp.www1.example.com. IN CNAME _443._tcp.w1.example.net.
_443._tcp.w1.example.net. IN TLSA 3 1 1 (
8A9A70596E869BED72C69D97A8895DFA
D86F300A343FECEFF19E89C27C896BC9 )
;
; A CA at the provider can also issue certificates for each Customer
; Domain and employ the DANE-TA(2) certificate usage to
; designate the provider's CA as a TA.
;
www2.example.com. IN CNAME w2.example.net.
_443._tcp.www2.example.com. IN CNAME _443._tcp.w2.example.net.
_443._tcp.w2.example.net. IN TLSA 2 0 1 (
C164B2C3F36D068D42A6138E446152F5
68615F28C69BD96A73E354CAC88ED00C )
With protocols that support explicit transport redirection via DNS MX records, SRV records, or other similar records, the TLSA base domain is based on the redirected transport endpoint rather than the origin domain. With SMTP, for example, when an email service is hosted by a Service Provider, the Customer Domain's MX hostnames will point at the Service Provider's SMTP hosts. When the Customer Domain's DNS zone is signed, the MX hostnames can be securely used as the base domains for TLSA records that are published and managed by the Service Provider. For example (without the required DNSSEC information, such as record signatures):
DNS MXレコード、SRVレコード、またはその他の同様のレコードを介した明示的な転送リダイレクトをサポートするプロトコルでは、TLSA基本ドメインは、発信元ドメインではなく、リダイレクトされた転送エンドポイントに基づいています。たとえば、SMTPを使用すると、メールサービスがサービスプロバイダーによってホストされている場合、カスタマードメインのMXホスト名はサービスプロバイダーのSMTPホストを指します。顧客ドメインのDNSゾーンが署名されている場合、MXホスト名は、サービスプロバイダーによって公開および管理されるTLSAレコードの基本ドメインとして安全に使用できます。例（レコード署名などの必要なDNSSEC情報なし）：
; Hosted SMTP service. ; example.com. IN MX 0 mx1.example.net. example.com. IN MX 0 mx2.example.net. _25._tcp.mx1.example.net. IN TLSA 3 1 1 ( 8A9A70596E869BED72C69D97A8895DFA D86F300A343FECEFF19E89C27C896BC9 ) _25._tcp.mx2.example.net. IN TLSA 3 1 1 ( C164B2C3F36D068D42A6138E446152F5 68615F28C69BD96A73E354CAC88ED00C )
;ホステッドSMTPサービス。 ; example.com。 IN MX 0 mx1.example.net。 example.com。 IN MX 0 mx2.example.net。 _25._tcp.mx1.example.net。 IN TLSA 3 1 1（8A9A70596E869BED72C69D97A8895DFA D86F300A343FECEFF19E89C27C896BC9）_25._tcp.mx2.example.net。 IN TLSA 3 1 1（C164B2C3F36D068D42A6138E446152F5 68615F28C69BD96A73E354CAC88ED00C）
If redirection to the Service Provider's domain (via MX records, SRV records, or any similar mechanism) is not possible and aliasing of the TLSA record is not an option, then more complex coordination between the Customer Domain and Service Provider will be required. Either the Customer Domain periodically provides private keys and a corresponding certificate chain to the provider (after making appropriate changes in its TLSA records), or the Service Provider periodically generates the keys and certificates and needs to wait for matching TLSA records to be published by its Customer Domains before deploying newly generated keys and certificate chains. Section 7 below describes an approach that employs CNAME "chasing" to avoid the difficulties of coordinating key management across organizational boundaries.
（MXレコード、SRVレコード、または同様のメカニズムを介して）サービスプロバイダーのドメインにリダイレクトできず、TLSAレコードのエイリアスが選択できない場合は、カスタマードメインとサービスプロバイダー間のより複雑な調整が必要になります。カスタマードメインが定期的にプライベートキーと対応する証明書チェーンをプロバイダーに提供する（TLSAレコードに適切な変更を加えた後）、またはサービスプロバイダーが定期的にキーと証明書を生成し、一致するTLSAレコードが発行されるのを待つ必要がある新しく生成されたキーと証明書チェーンを展開する前の顧客ドメイン。以下のセクション7では、CNAMEの「追跡」を使用して、組織の境界を越えてキー管理を調整する困難を回避するアプローチについて説明します。
For further information about combining DANE and SRV, please see [RFC7673].
DANEとSRVの組み合わせの詳細については、[RFC7673]を参照してください。
When the application protocol does not support service location indirection via MX, SRV, or similar DNS records, the service may be redirected via a CNAME. A CNAME is a more blunt instrument for this purpose because, unlike an MX or SRV record, it remaps the entire origin domain to the target domain for all protocols.
アプリケーションプロトコルがMX、SRV、または同様のDNSレコードを介したサービスロケーションの間接化をサポートしていない場合、サービスはCNAMEを介してリダイレクトされる可能性があります。 CNAMEは、MXまたはSRVレコードとは異なり、すべてのプロトコルのオリジンドメイン全体をターゲットドメインに再マップするため、この目的のためのより率直な手段です。
The complexity of coordinating key management is largely eliminated when DANE TLSA records are found in the Service Provider's domain, as discussed in Section 6. Therefore, DANE TLS clients connecting to a server whose domain name is a CNAME alias SHOULD follow the CNAME "hop by hop" to its ultimate target host (noting at each step whether or not the CNAME is DNSSEC validated). If at each stage of CNAME expansion the DNSSEC validation status is "secure", the final target name SHOULD be the preferred base domain for TLSA lookups.
セクション6で説明したように、DANE TLSAレコードがサービスプロバイダーのドメインで検出されると、キー管理の調整の複雑さが大幅に解消されます。最終的なターゲットホストにホップします（CNAMEがDNSSECで検証されているかどうかにかかわらず、各ステップで注意）。 CNAME展開の各段階でDNSSEC検証ステータスが「セキュア」である場合、最終的なターゲット名はTLSAルックアップの優先ベースドメインである必要があります（SHOULD）。
Implementations failing to find a TLSA record using a base name of the final target of a CNAME expansion SHOULD issue a TLSA query using the original destination name. That is, the preferred TLSA base domain SHOULD be derived from the fully expanded name and, failing that, SHOULD be the initial domain name.
CNAME展開の最終ターゲットのベース名を使用してTLSAレコードを見つけることができない実装は、元の宛先名を使用してTLSAクエリを発行する必要があります（SHOULD）。つまり、優先TLSA基本ドメインは完全に拡張された名前から派生する必要があり（SHOULD）、失敗した場合は初期ドメイン名である必要があります（SHOULD）。
When the TLSA base domain is the result of "secure" CNAME expansion, the resulting domain name MUST be used as the HostName in the client's SNI extension and MUST be the primary reference identifier for peer certificate matching with certificate usages other than DANE-EE(3).
TLSAベースドメインが「安全な」CNAME拡張の結果である場合、結果のドメイン名はクライアントのSNI拡張のHostNameとして使用する必要があり、DANE-EE（以外の証明書の使用法と一致するピア証明書のプライマリ参照識別子である必要があります。 3）。
Protocol-specific TLSA specifications may provide additional guidance or restrictions when following CNAME expansions.
プロトコル固有のTLSA仕様は、CNAMEの拡張に従うときに追加のガイダンスまたは制限を提供する場合があります。
Though CNAMEs are illegal on the right-hand side of most indirection records, such as MX and SRV records, they are supported by some implementations. For example, if the MX or SRV host is a CNAME alias, some implementations may "chase" the CNAME. If they do, they SHOULD use the target hostname as the preferred TLSA base domain as described above (and, if the TLSA records are found there, also use the CNAME-expanded domain in SNI and certificate name checks).
MXやSRVレコードなど、ほとんどの間接レコードの右側ではCNAMEは違法ですが、一部の実装ではサポートされています。たとえば、MXまたはSRVホストがCNAMEエイリアスの場合、実装によってはCNAMEを「追跡」する場合があります。その場合、前述のようにターゲットホスト名を優先TLSAベースドメインとして使用する必要があります（また、そこにTLSAレコードが見つかった場合は、SNIおよび証明書名のチェックでCNAME拡張ドメインも使用します）。
This section updates [RFC6698] by specifying that the TLSA Publisher MUST ensure that each combination of certificate usage, selector, and matching type in the server's TLSA RRset includes at least one record that matches the server's current certificate chain. TLSA records that match recently retired or yet-to-be-deployed certificate chains will be present during key rollover. Such past or future records MUST NOT at any time be the only records published for any given combination of usage, selector, and matching type. The TLSA record update process described below ensures that this requirement is met.
このセクションは、[RFC6698]を更新して、TLSAパブリッシャーが、サーバーのTLSA RRsetの証明書の使用法、セレクター、およびマッチングタイプの各組み合わせに、サーバーの現在の証明書チェーンと一致するレコードが少なくとも1つ含まれていることを確認する必要があることを指定する必要があることを指定します。最近廃止された、またはまだ展開されていない証明書チェーンに一致するTLSAレコードは、キーのロールオーバー中に存在します。このような過去または将来のレコードは、使用法、セレクター、およびマッチングタイプの特定の組み合わせに対して公開された唯一のレコードであってはなりません。以下で説明するTLSAレコードの更新プロセスにより、この要件が確実に満たされます。
While a server is to be considered authenticated when its certificate chain is matched by any of the published TLSA records, not all clients support all combinations of TLSA record parameters. Some clients may not support some digest algorithms; others may either not support or exclusively support the PKIX certificate usages. Some clients may prefer to negotiate [RFC7250] raw public keys, which are only compatible with TLSA records whose certificate usage is DANE-EE(3) with selector SPKI(1). The only other TLSA record type that is potentially compatible with raw public keys is "DANE-EE(3) Cert(0) Full(0)", but support for raw public keys with that TLSA record type is not expected to be broadly implemented.
サーバーは、証明書チェーンが公開されたTLSAレコードのいずれかと一致する場合に認証済みと見なされますが、すべてのクライアントがTLSAレコードパラメーターのすべての組み合わせをサポートするわけではありません。クライアントによっては、一部のダイジェストアルゴリズムをサポートしていない場合があります。他のユーザーは、PKIX証明書の使用をサポートしないか、排他的にサポートする場合があります。一部のクライアントは、証明書の使用法がDANE-EE（3）とセレクターSPKI（1）を持つTLSAレコードとのみ互換性がある[RFC7250]の未加工の公開鍵をネゴシエートすることを好む場合があります。未加工の公開鍵と互換性がある可能性がある他の唯一のTLSAレコードタイプは「DANE-EE（3）Cert（0）Full（0）」ですが、そのTLSAレコードタイプでの未加工公開キーのサポートは広く実装されるとは予想されません。
A consequence of the above uncertainty as to which TLSA parameters are supported by any given client is that servers need to ensure that each and every parameter combination that appears in the TLSA RRset is, on its own, sufficient to match the server's current certificate chain. In particular, when deploying new keys or new parameter combinations, some care is required to not generate parameter combinations that only match past or future certificate chains (or raw public keys). The rest of this section explains how to update the TLSA RRset in a manner that ensures that the above requirement is met.
特定のクライアントでサポートされるTLSAパラメータに関する上記の不確実性の結果として、サーバーは、TLSA RRsetに表示されるすべてのパラメーターの組み合わせが、それ自体でサーバーの現在の証明書チェーンと一致するのに十分であることを確認する必要があります。特に、新しいキーまたは新しいパラメーターの組み合わせを展開する場合、過去または将来の証明書チェーン（または未加工の公開キー）のみに一致するパラメーターの組み合わせを生成しないように注意する必要があります。このセクションの残りの部分では、上記の要件が確実に満たされるようにTLSA RRsetを更新する方法について説明します。
The simplest case is key rollover while retaining the same set of published parameter combinations. In this case, TLSA records matching the existing server certificate chain (or raw public keys) are first augmented with corresponding records matching the future keys, at least two Times to Live (TTLs) or longer before the new chain is deployed. This allows the obsolete RRset to age out of client caches before the new chain is used in TLS handshakes. Once sufficient time has elapsed and all clients performing DNS lookups are retrieving the updated TLSA records, the server administrator may deploy the new certificate chain, verify that it works, and then remove any obsolete records matching the chain that is no longer active:
最も単純なケースは、公開されたパラメーターの組み合わせの同じセットを保持しながらキーをロールオーバーすることです。この場合、既存のサーバー証明書チェーン（または生の公開鍵）と一致するTLSAレコードは、新しいチェーンがデプロイされる前に、将来の鍵と一致する対応するレコード（少なくとも2回の存続可能時間（TTL））で最初に拡張されます。これにより、新しいチェーンがTLSハンドシェイクで使用される前に、廃止されたRRsetがクライアントキャッシュを期限切れにすることができます。十分な時間が経過し、DNSルックアップを実行するすべてのクライアントが更新されたTLSAレコードを取得すると、サーバー管理者は新しい証明書チェーンをデプロイし、それが機能することを確認して、アクティブでなくなったチェーンに一致する古いレコードを削除できます。
; Initial TLSA RRset. ; _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
;初期TLSA RRset。 ; _443._tcp.www.example.org。 TLSA 3 1 1 01d09d19c2139a46 ...
; Transitional TLSA RRset published at least two TTLs before
; the actual key change.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
; Final TLSA RRset after the key change. ; _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
;キー変更後の最終的なTLSA RRset。 ; _443._tcp.www.example.org。 TLSA 3 1 1 7aa7a5359173d05b ...
The next case to consider is adding or switching to a new combination of TLSA parameters. In this case, publish the new parameter combinations for the server's existing certificate chain first, and only then deploy new keys if desired:
次に検討すべきケースは、TLSAパラメータの新しい組み合わせの追加または切り替えです。この場合、最初にサーバーの既存の証明書チェーンの新しいパラメーターの組み合わせを公開し、次に必要な場合にのみ新しいキーを展開します。
; Initial TLSA RRset. ; _443._tcp.www.example.org. IN TLSA 1 1 1 01d09d19c2139a46...
;初期TLSA RRset。 ; _443._tcp.www.example.org。 TLSA 1 1 1 01d09d19c2139a46 ...
; New TLSA RRset, same key re-published as DANE-EE(3). ; _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
;新しいTLSA RRset、DANE-EE（3）と同じキーが再公開されました。 ; _443._tcp.www.example.org。 TLSA 3 1 1 01d09d19c2139a46 ...
This section explains how to migrate to a new certificate chain and TLSA record with usage DANE-TA(2) from a self-signed server certificate and a "DANE-EE(3) SPKI(1) SHA2-256(1)" TLSA record. This example assumes that a new private key is generated in conjunction with transitioning to a new certificate issued by the desired TA.
このセクションでは、自己署名サーバー証明書と「DANE-EE（3）SPKI（1）SHA2-256（1）」TLSAから使用法DANE-TA（2）を使用して、新しい証明書チェーンとTLSAレコードに移行する方法について説明します記録。この例では、目的のTAによって発行された新しい証明書への移行に関連して、新しい秘密キーが生成されることを前提としています。
The original "3 1 1" TLSA record supports [RFC7250] raw public keys, and clients may choose to negotiate their use. The use of raw public keys rules out the possibility of certificate chain verification. Therefore, the transitional TLSA record for the planned DANE-TA(2) certificate chain is a "3 1 1" record that works even when raw public keys are used. The TLSA RRset is updated to use DANE-TA(2) only after the new chain is deployed and the "3 1 1" record matching the original key is dropped.
元の「3 1 1」TLSAレコードは[RFC7250]の未加工の公開鍵をサポートし、クライアントはその使用について交渉することを選択できます。生の公開鍵を使用すると、証明書チェーン検証の可能性が排除されます。したがって、計画されたDANE-TA（2）証明書チェーンの移行TLSAレコードは、生の公開鍵が使用されている場合でも機能する「3 1 1」レコードです。 TLSA RRsetは、新しいチェーンがデプロイされ、元のキーと一致する「3 1 1」レコードがドロップされた後にのみDANE-TA（2）を使用するように更新されます。
This process follows the requirement that each combination of parameters present in the RRset is always sufficient to validate the server. It avoids publishing a transitional TLSA RRset in which "3 1 1" matches only the current key and "2 0 1" matches only the future certificate chain, because these might not work reliably during the initial deployment of the new keys.
このプロセスは、RRsetに存在するパラメーターの各組み合わせが常にサーバーを検証するのに十分であるという要件に従います。 「3 1 1」が現在のキーのみと一致し、「2 0 1」が将来の証明書チェーンのみと一致する過渡的なTLSA RRsetの公開は回避されます。
; Initial TLSA RRset. ; _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
;初期TLSA RRset。 ; _443._tcp.www.example.org。 TLSA 3 1 1 01d09d19c2139a46 ...
; Transitional TLSA RRset, published at least two TTLs before the
; actual key change. The new keys are issued by a DANE-TA(2) CA
; but are initially specified via a DANE-EE(3) association.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
; The final TLSA RRset after the key change. Now that the old
; self-signed EE key is out of the picture, publish the issuing
; TA of the new chain.
;
_443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d...
When employing a new digest algorithm in the TLSA RRset, for compatibility with digest algorithm agility as specified in Section 9 below, administrators SHOULD publish the new digest algorithm with each combination of certificate usage and selector for each associated key or chain used with any other digest algorithm. When removing an algorithm, remove it entirely. Each digest algorithm employed SHOULD match the same set of chains (or raw public keys).
TLSA RRsetで新しいダイジェストアルゴリズムを採用する場合、以下のセクション9で指定されているダイジェストアルゴリズムの俊敏性との互換性のために、管理者は、他のダイジェストで使用される各関連キーまたはチェーンの証明書の使用法とセレクターの各組み合わせで新しいダイジェストアルゴリズムを公開する必要があります（SHOULD）。アルゴリズム。アルゴリズムを削除するときは、完全に削除してください。使用される各ダイジェストアルゴリズムは、同じチェーンのセット（または生の公開鍵）に一致する必要があります（SHOULD）。
; Initial TLSA RRset with "DANE-EE(3) SHA2-256(1)" associations
; for two keys.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
; New TLSA RRset, also with SHA2-512(2) associations
; for each key.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 2 d9947c35089310bc...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
_443._tcp.www.example.org. IN TLSA 3 1 2 89a7486a4b6ae714...
In summary, server operators updating TLSA records should make one change at a time. The individual safe changes are as follows:
要約すると、TLSAレコードを更新するサーバーオペレーターは、一度に1つの変更を行う必要があります。個々の安全な変更は次のとおりです。
o Pre-publish new certificate associations that employ the same TLSA parameters (usage, selector, and matching type) as existing TLSA records, but match certificate chains that will be deployed in the near future.
o 既存のTLSAレコードと同じTLSAパラメーター（使用法、セレクター、およびマッチングタイプ）を使用する新しい証明書の関連付けを事前公開しますが、近い将来に展開される証明書チェーンに一致します。
o Wait for stale TLSA RRsets to expire from DNS caches before configuring servers to use the new certificate chain.
o 新しい証明書チェーンを使用するようにサーバーを構成する前に、古いTLSA RRsetがDNSキャッシュから期限切れになるのを待ちます。
o Remove TLSA records matching any certificate chains that are no longer deployed.
o 展開されなくなった証明書チェーンに一致するTLSAレコードを削除します。
o Publish TLSA RRsets in which all parameter combinations (certificate usage, selector, and matching type) present in the RRset match the same set of current and planned certificate chains.
o RRsetに存在するすべてのパラメーターの組み合わせ（証明書の使用法、セレクター、およびマッチングタイプ）が現在および計画中の証明書チェーンの同じセットと一致するTLSA RRsetを公開します。
The above steps are intended to ensure that at all times, and for each combination of usage, selector, and matching type, at least one TLSA record corresponds to the server's current certificate chain. Each combination of certificate usage, selector, and matching type in a server's TLSA RRset SHOULD NOT at any time (including unexpired RRsets in client caches) match only some combination of future or past certificate chains. As a result, no matter what combinations of usage, selector, and matching type may be supported by a given client, they will be sufficient to authenticate the server.
上記の手順は、常に、使用法、セレクター、およびマッチングタイプの各組み合わせについて、少なくとも1つのTLSAレコードがサーバーの現在の証明書チェーンに対応することを保証することを目的としています。サーバーのTLSA RRset内の証明書の使用法、セレクター、および一致するタイプの各組み合わせ（クライアントキャッシュ内の有効期限が切れていないRRsetを含む）は、将来または過去の証明書チェーンの一部の組み合わせとのみ一致します（SHOULD NOT）。その結果、特定のクライアントがサポートする使用法、セレクター、およびマッチングタイプの組み合わせに関係なく、それらはサーバーを認証するのに十分です。
While [RFC6698] specifies multiple digest algorithms, it does not specify a protocol by which the client and TLSA record publisher can agree on the strongest shared algorithm. Such a protocol would allow the client and server to avoid exposure to deprecated weaker algorithms that are published for compatibility with less capable clients but that SHOULD be avoided when possible. Such a protocol is specified below.
[RFC6698]は複数のダイジェストアルゴリズムを指定していますが、クライアントとTLSAレコードパブリッシャーが最も強力な共有アルゴリズムに同意できるプロトコルを指定していません。このようなプロトコルにより、クライアントとサーバーは、能力の低いクライアントとの互換性のために公開されている非推奨の弱いアルゴリズムにさらされることを回避できますが、可能な場合は回避する必要があります。このようなプロトコルは、以下に指定されています。
This section defines a protocol for avoiding deprecated digest algorithms when these are published in a peer's TLSA RRset alongside stronger digest algorithms. Note that this protocol never avoids RRs with a DANE matching type of Full(0), as these do not employ a digest algorithm that might someday be weakened by cryptanalysis.
このセクションでは、ピアのTLSA RRsetで強力なダイジェストアルゴリズムとともに公開された非推奨のダイジェストアルゴリズムを回避するためのプロトコルを定義します。これらは暗号解読によって弱まる可能性のあるダイジェストアルゴリズムを採用していないため、このプロトコルはDANEマッチングタイプがFull（0）のRRを決して回避しないことに注意してください。
Client implementations SHOULD implement a default order of digest algorithms by strength. This order SHOULD be configurable by the administrator or user of the client software. If possible, a configurable mapping from numeric DANE TLSA matching types to underlying digest algorithms provided by the cryptographic library SHOULD be implemented to allow new matching types to be used with software that predates their introduction. Configurable ordering of digest algorithms SHOULD be extensible to any new digest algorithms.
クライアントの実装は、強度によるダイジェストアルゴリズムのデフォルトの順序を実装する必要があります（SHOULD）。この順序は、クライアントソフトウェアの管理者またはユーザーが構成できる必要があります（SHOULD）。可能であれば、数値DANE TLSAマッチングタイプから暗号化ライブラリによって提供される基礎となるダイジェストアルゴリズムへの構成可能なマッピングを実装して、新しいマッチングタイプを導入前のソフトウェアで使用できるようにする必要があります。ダイジェストアルゴリズムの構成可能な順序付けは、新しいダイジェストアルゴリズムに拡張可能であるべきです（SHOULD）。
To make digest algorithm agility possible, all published DANE TLSA RRsets MUST conform to the requirements of Section 8. Clients SHOULD use digest algorithm agility when processing the peer's DANE TLSA records. Algorithm agility is to be applied after first discarding any unusable or malformed records (unsupported digest algorithm, or incorrect digest length). For each usage and selector, the client SHOULD process only any usable records with a matching type of Full(0) and the usable records whose digest algorithm is considered by the client to be the strongest among usable records with the given usage and selector.
ダイジェストアルゴリズムの俊敏性を可能にするために、公開されたすべてのDANE TLSA RRsetはセクション8の要件に準拠する必要があります。クライアントは、ピアのDANE TLSAレコードを処理するときにダイジェストアルゴリズムの敏捷性を使用する必要があります。アルゴリズムの俊敏性は、使用不可または不正な形式のレコード（サポートされていないダイジェストアルゴリズム、または不適切なダイジェスト長）を最初に破棄した後に適用されます。クライアントは、使用法とセレクターごとに、一致するタイプがFull（0）の使用可能なレコードと、指定された使用法とセレクターで使用可能なレコードの中でクライアントがダイジェストアルゴリズムを最強と見なす使用可能なレコードのみを処理する必要があります（SHOULD）。
Example: a client implements digest algorithm agility and prefers SHA2-512(2) over SHA2-256(1), while the server publishes an RRset that employs both digest algorithms as well as a Full(0) record.
例：クライアントはダイジェストアルゴリズムの俊敏性を実装し、SHA2-256（1）よりもSHA2-512（2）を優先しますが、サーバーはダイジェストアルゴリズムとFull（0）レコードの両方を使用するRRsetを公開します。
_25._tcp.mail.example.com. IN TLSA 3 1 1 ( 3FE246A848798236DD2AB78D39F0651D 6B6E7CA8E2984012EB0A2E1AC8A87B72 ) _25._tcp.mail.example.com. IN TLSA 3 1 2 ( D4F5AF015B46C5057B841C7E7BAB759C BF029526D29520C5BE6A32C67475439E 54AB3A945D80C743347C9BD4DADC9D8D 57FAB78EAA835362F3CA07CCC19A3214 ) _25._tcp.mail.example.com. IN TLSA 3 1 0 ( 3059301306072A8648CE3D020106082A 8648CE3D0301070342000471CB1F504F 9E4B33971376C005445DACD33CD79A28 81C3DED1981F18E7AAA76609DD0E4EF2 8265C82703030AD60C5DBA6FB8A9397A C0FCF06D424C885D484887 )
_25._tcp.mail.example.com。 IN TLSA 3 1 1（3FE246A848798236DD2AB78D39F0651D 6B6E7CA8E2984012EB0A2E1AC8A87B72）_25._tcp.mail.example.com。 IN TLSA 3 1 2（D4F5AF015B46C5057B841C7E7BAB759C BF029526D29520C5BE6A32C67475439E 54AB3A945D80C743347C9BD4DADC9D8D 57FAB78EAA835362F3CA07CCC19A3214）_25._tcp IN TLSA 3 1 0（3059301306072A8648CE3D020106082A 8648CE3D0301070342000471CB1F504F 9E4B33971376C005445DACD33CD79A28 81C3DED1981F18E7AAA76609DD0E4EF2 8265C82703030AD60C5DBA6FB8F5A9396887C88D5F8A9396887C88D8A9396887C88A88
In this case, the client SHOULD accept a server public key that matches either the "3 1 0" record or the "3 1 2" record, but it SHOULD NOT accept keys that match only the weaker "3 1 1" record.
この場合、クライアントは「3 1 0」レコードまたは「3 1 2」レコードのいずれかに一致するサーバー公開鍵を受け入れる必要がありますが、弱い「3 1 1」レコードのみに一致する鍵は受け入れてはなりません（SHOULD NOT）。
These guidelines provide guidance for using or designing protocols for DANE.
これらのガイドラインは、DANEのプロトコルの使用または設計に関するガイダンスを提供します。
Selecting a combination of TLSA parameters to use requires careful thought. One important consideration to take into account is the size of the resulting TLSA record after its parameters are selected.
使用するTLSAパラメータの組み合わせを選択するには、慎重な検討が必要です。考慮すべき重要な考慮事項の1つは、パラメーターが選択された後のTLSAレコードのサイズです。
Deployments SHOULD avoid TLSA record sizes that cause UDP fragmentation.
デプロイメントは、UDPフラグメンテーションを引き起こすTLSAレコードサイズを回避する必要があります（SHOULD）。
Although DNS over TCP would provide the ability to more easily transfer larger DNS records between clients and servers, it is not universally deployed and is still prohibited by some firewalls. Clients that request DNS records via UDP typically only use TCP upon receipt of a truncated response in the DNS response message sent over UDP. Setting the Truncation (TC) bit (Section 4.1.1 of [RFC1035]) alone will be insufficient if the response containing the TC bit is itself fragmented.
DNS over TCPは、クライアントとサーバー間でより大きなDNSレコードをより簡単に転送する機能を提供しますが、普遍的に展開されているわけではなく、一部のファイアウォールによって依然として禁止されています。 UDP経由でDNSレコードを要求するクライアントは、通常、UDP経由で送信されたDNS応答メッセージで切り捨てられた応答を受信した場合にのみTCPを使用します。切り捨て（TC）ビット（[RFC1035]のセクション4.1.1）を設定するだけでは、TCビットを含む応答自体が断片化されている場合は不十分です。
Server operators SHOULD NOT publish TLSA records using both a TLSA selector of Cert(0) and a TLSA matching type of Full(0), as even a single certificate is generally too large to be reliably delivered via DNS over UDP. Furthermore, two TLSA records containing full certificates will need to be published simultaneously during a certificate rollover, as discussed in Section 8.1.
サーバーオペレーターは、Cert（0）のTLSAセレクターとFull（0）のTLSAマッチングタイプの両方を使用してTLSAレコードを公開するべきではありません。さらに、セクション8.1で説明するように、証明書のロールオーバー中に、完全な証明書を含む2つのTLSAレコードを同時に公開する必要があります。
While TLSA records using a TLSA selector of SPKI(1) and a TLSA matching type of Full(0) (which publish the bare public keys, i.e., without the overhead of encapsulating the keys in an X.509 certificate) are generally more compact, these are also best avoided when significantly larger than their digests. Rather, servers SHOULD publish digest-based TLSA matching types in their TLSA records, in which case the complete corresponding certificate MUST be transmitted to the client in-band during the TLS handshake. The certificate (or raw public key) can be easily verified using the digest value.
一方、SPKI（1）のTLSAセレクターとFull（0）のTLSAマッチングタイプを使用するTLSAレコードは、ベアパブリックキーを公開します（つまり、X.509証明書にキーをカプセル化するオーバーヘッドがない）。 、これらはダイジェストよりも大幅に大きい場合にも回避することをお勧めします。むしろ、サーバーはTLSAレコードでダイジェストベースのTLSAマッチングタイプを公開する必要があります。その場合、対応する完全な証明書をTLSハンドシェイク中にインバンドでクライアントに送信する必要があります。証明書（または生の公開鍵）は、ダイジェスト値を使用して簡単に検証できます。
In summary, the use of a TLSA matching type of Full(0) is NOT RECOMMENDED, and a digest-based matching type, such as SHA2-256(1), SHOULD be used instead.
要約すると、Full（0）のTLSAマッチングタイプの使用は推奨されておらず、代わりにSHA2-256（1）などのダイジェストベースのマッチングタイプを使用する必要があります（SHOULD）。
Certificates presented by a TLS server will generally contain a subjectAltName (SAN) extension or a Common Name (CN) element within the subject Distinguished Name (DN). The TLS server's DNS domain name is normally published within these elements, ideally within the SAN extension. (The use of the CN field for this purpose is deprecated.)
TLSサーバーによって提示される証明書には、通常、サブジェクトの識別名（DN）内にsubjectAltName（SAN）拡張または共通名（CN）要素が含まれます。 TLSサーバーのDNSドメイン名は通常、これらの要素内、理想的にはSAN拡張内で公開されます。 （この目的でのCNフィールドの使用は非推奨です。）
When a server hosts multiple domains at the same transport endpoint, the server's ability to respond with the right certificate chain is predicated on correct SNI information from the client. DANE clients MUST send the SNI extension with a HostName value of the base domain of the TLSA RRset.
サーバーが同じトランスポートエンドポイントで複数のドメインをホストする場合、正しい証明書チェーンで応答するサーバーの機能は、クライアントからの正しいSNI情報に基づいています。 DANEクライアントは、TLSA RRsetのベースドメインのHostName値を含むSNI拡張を送信する必要があります。
With the exception of TLSA certificate usage DANE-EE(3), where name checks are not applicable (see Section 5.1), DANE clients MUST verify that the client has reached the correct server by checking that the server name is listed in the server certificate's SAN or CN (when still supported). The primary server name used for this comparison MUST be the TLSA base domain; however, additional acceptable names may be specified by protocol-specific DANE standards. For example, with SMTP, both the destination domain name and the MX hostname are acceptable names to be found in the server certificate (see [RFC7672]).
TLSA証明書の使用法DANE-EE（3）を除いて、名前のチェックは適用されません（セクション5.1を参照）。DANEクライアントは、サーバー名がサーバー証明書のリストに含まれていることを確認して、クライアントが正しいサーバーに到達したことを確認する必要があります。 SANまたはCN（まだサポートされている場合）。この比較に使用されるプライマリサーバー名は、TLSAベースドメインである必要があります。ただし、プロトコル固有のDANE標準によって、追加の受け入れ可能な名前が指定される場合があります。たとえば、SMTPでは、宛先ドメイン名とMXホスト名の両方がサーバー証明書に含まれる受け入れ可能な名前です（[RFC7672]を参照）。
It is the responsibility of the service operator, in coordination with the TLSA Publisher, to ensure that at least one of the TLSA records published for the service will match the server's certificate chain (either the default chain or the certificate that was selected based on the SNI information provided by the client).
サービスに対して発行されたTLSAレコードの少なくとも1つがサーバーの証明書チェーン（デフォルトチェーンまたは証明書に基づいて選択された証明書のいずれか）と一致することを保証するのは、TLSAパブリッシャーと連携したサービスオペレーターの責任です。クライアントから提供されたSNI情報）。
Given the DNSSEC-validated DNS records below:
以下のDNSSEC検証済みDNSレコードがあるとします。
example.com. IN MX 0 mail.example.com. mail.example.com. IN A 192.0.2.1 _25._tcp.mail.example.com. IN TLSA 2 0 1 ( E8B54E0B4BAA815B06D3462D65FBC7C0 CF556ECCF9F5303EBFBB77D022F834C0 )
example.com。 IN MX 0 mail.example.com。 mail.example.com。 IN A 192.0.2.1 _25._tcp.mail.example.com。 IN TLSA 2 0 1（E8B54E0B4BAA815B06D3462D65FBC7C0 CF556ECCF9F5303EBFBB77D022F834C0）
The TLSA base domain is "mail.example.com" and is required to be the HostName in the client's SNI extension. The server certificate chain is required to be signed by a TA with the above certificate SHA2-256 digest. Finally, one of the DNS names in the server certificate is required to be either "mail.example.com" or "example.com" (this additional name is a concession to compatibility with prior practice; see [RFC7672] for details).
TLSA基本ドメインは「mail.example.com」であり、クライアントのSNI拡張のHostNameである必要があります。サーバー証明書チェーンは、上記の証明書SHA2-256ダイジェストでTAによって署名される必要があります。最後に、サーバー証明書のDNS名の1つは、「mail.example.com」または「example.com」である必要があります（この追加の名前は、以前のプラクティスとの互換性のために譲歩です。詳細については、[RFC7672]を参照してください）。
[RFC6125] specifies the semantics of wildcards in server certificates for various application protocols. DANE does not change how wildcards are treated by any given application.
[RFC6125]は、さまざまなアプリケーションプロトコルのサーバー証明書でワイルドカードのセマンティクスを指定します。 DANEは、特定のアプリケーションによるワイルドカードの処理方法を変更しません。
When a TLS client goes to the trouble of authenticating a certificate chain presented by a TLS server, it will typically not continue to use that server in the event of authentication failure, or else authentication serves no purpose. Some clients may, at times, operate in an "audit" mode, where authentication failure is reported to the user or in logs as a potential problem, but the connection proceeds despite the failure. Nevertheless, servers publishing TLSA records MUST be configured to allow correctly configured clients to successfully authenticate their TLS certificate chains.
TLSクライアントがTLSサーバーから提示された証明書チェーンを認証する際に問題が発生した場合、通常、認証に失敗した場合、そのサーバーは使用されず、認証が機能しません。一部のクライアントは、「監査」モードで動作する場合があります。このモードでは、認証の失敗が潜在的な問題としてユーザーまたはログに報告されますが、失敗しても接続は続行されます。それでも、TLSAレコードを公開するサーバーは、正しく構成されたクライアントがTLS証明書チェーンを正常に認証できるように構成する必要があります。
A service with DNSSEC-validated TLSA records implicitly promises TLS support. When all the TLSA records for a service are found "unusable" due to unsupported parameter combinations or malformed certificate association data, DANE clients cannot authenticate the service certificate chain. When authenticated TLS is mandatory, the client MUST NOT connect to the associated server.
DNSSECで検証されたTLSAレコードを持つサービスは、TLSサポートを暗黙的に約束します。サポートされていないパラメーターの組み合わせまたは不正な証明書関連付けデータが原因で、サービスのすべてのTLSAレコードが「使用不可」であることが判明した場合、DANEクライアントはサービス証明書チェーンを認証できません。認証されたTLSが必須の場合、クライアントは関連するサーバーに接続してはなりません（MUST NOT）。
If, on the other hand, the use of TLS and DANE is "opportunistic" [RFC7435], then when all TLSA records are unusable, the client SHOULD connect to the server via an unauthenticated TLS connection, and if TLS encryption cannot be established, the client MUST NOT connect to the server.
一方、TLSとDANEの使用が「便宜的」[RFC7435]である場合、すべてのTLSAレコードが使用できない場合、クライアントは非認証TLS接続を介してサーバーに接続する必要があり（SHOULD）、TLS暗号化を確立できない場合は、クライアントはサーバーに接続してはいけません。
Standards for opportunistic DANE TLS specific to a particular application protocol may modify the above requirements. The key consideration is whether or not mandating the use of (unauthenticated) TLS even with unusable TLSA records is asking for more security than one can realistically expect. If expecting TLS support when unusable TLSA records are published is realistic for the application in question, then the application MUST avoid cleartext. If not realistic, then mandating TLS would cause clients (even in the absence of active attacks) to run into problems with various peers that do not interoperate "securely enough". That would create strong incentives to just disable Opportunistic Security and stick with cleartext.
特定のアプリケーションプロトコルに固有の日和見DANE TLSの標準は、上記の要件を変更する場合があります。重要な考慮事項は、使用不可のTLSAレコードが存在する場合でも（認証されていない）TLSの使用を義務付けることが、実際に期待できるよりも高いセキュリティを求めているかどうかです。使用できないTLSAレコードが発行されたときにTLSサポートを期待することが問題のアプリケーションにとって現実的である場合、アプリケーションはクリアテキストを避けなければなりません（MUST）。現実的でない場合、TLSを強制すると、クライアントは（アクティブな攻撃がない場合でも）「十分に安全」に相互運用できないさまざまなピアで問題が発生します。これは、日和見セキュリティを無効にし、平文を守るという強い動機を生み出します。
Clearly, the security of the DANE TLSA PKI rests on the security of the underlying DNSSEC infrastructure. While this document is not a guide to DNSSEC security, a few comments may be helpful to TLSA implementers.
明らかに、DANE TLSA PKIのセキュリティは、基盤となるDNSSECインフラストラクチャのセキュリティに依存しています。このドキュメントはDNSSECセキュリティのガイドではありませんが、いくつかのコメントはTLSA実装者に役立つ場合があります。
With the existing public CA Web PKI, name constraints are rarely used, and a public root CA can issue certificates for any domain of its choice. With DNSSEC, under the Registry/Registrar/Registrant model, the situation is different: only the registrar of record can update a domain's DS record [RFC4034] in the registry parent zone (in some cases, however, the registry is the sole registrar). With many Generic Top-Level Domains (gTLDs) for which multiple registrars compete to provide domains in a single registry, it is important to make sure that rogue registrars cannot easily initiate an unauthorized domain transfer and thus take over DNSSEC for the domain. DNS operators are advised to set a registrar lock on their domains to offer some protection against this possibility.
既存のパブリックCA Web PKIでは、名前の制約はほとんど使用されず、パブリックルートCAは任意のドメインの証明書を発行できます。 DNSSECでは、Registry / Registrar / Registrantモデルでは状況が異なります。レコードのレジストラのみがレジストリの親ゾーンでドメインのDSレコード[RFC4034]を更新できます（ただし、場合によっては、レジストリが唯一のレジストラです） 。複数のレジストラが単一のレジストリでドメインを提供するために競合する多くの汎用トップレベルドメイン（gTLD）では、不正なレジストラが不正なドメイン転送を簡単に開始できず、ドメインのDNSSECを引き継ぐことができないようにすることが重要です。 DNSオペレーターは、ドメインにレジストラーロックを設定して、この可能性に対する何らかの保護を提供することをお勧めします。
When the registrar is also the DNS operator for the domain, one needs to consider whether or not the registrar will allow orderly migration of the domain to another registrar or DNS operator in a way that will maintain DNSSEC integrity. TLSA Publishers are advised to seek out a DNS hosting registrar that makes it possible to transfer domains to another hosting provider without disabling DNSSEC.
レジストラがドメインのDNSオペレーターでもある場合は、レジストラがDNSSECの整合性を維持する方法で、ドメインを別のレジストラまたはDNSオペレーターに秩序だって移行できるかどうかを検討する必要があります。 TLSAパブリッシャーは、DNSSECを無効にすることなく別のホスティングプロバイダーにドメインを転送できるようにするDNSホスティングレジストラーを探すことをお勧めします。
DNSSEC-signed RRsets cannot be securely revoked before they expire. Operators need to plan accordingly and not generate signatures of excessively long duration. For domains publishing high-value keys, a signature lifetime (length of the "signature validity period" as described in Section 8.1 of [RFC4033]) of a few days is reasonable, and the zone can be re-signed daily. For domains with less critical data, a reasonable signature lifetime is a couple of weeks to a month, and the zone can be re-signed weekly.
DNSSEC署名付きRRsetは、期限が切れる前に安全に取り消すことはできません。オペレーターはそれに応じて計画を立て、過度に長い期間の署名を生成しないようにする必要があります。価値の高いキーを公開しているドメインの場合、署名の有効期間（[RFC4033]のセクション8.1で説明されている「署名の有効期間」の長さ）は数日で妥当であり、ゾーンに毎日再署名できます。重要度の低いデータのドメインの場合、署名の有効期間は数週間から1か月であり、ゾーンは毎週再署名できます。
Short signature lifetimes require tighter synchronization of primary and secondary nameservers, to make sure that secondary servers never serve records with expired signatures. They also limit the maximum time for which a primary server that signs the zone can be down. Therefore, short signature lifetimes are more appropriate for sites with dedicated operations staff, who can restore service quickly in case of a problem.
署名の有効期間が短い場合は、プライマリサーバーとセカンダリネームサーバーのより厳密な同期が必要です。これにより、セカンダリサーバーが署名の期限切れのレコードを処理しないようにします。また、ゾーンに署名するプライマリサーバーが停止できる最大時間も制限されます。したがって、問題が発生した場合にサービスを迅速に復元できる専門の運用スタッフがいるサイトには、署名の有効期間が短い方が適切です。
Monitoring is important. If a DNS zone is not re-signed in a timely manner, a major outage is likely, as the entire domain and all its sub-domains become "bogus".
モニタリングは重要です。 DNSゾーンがタイムリーに再署名されない場合、ドメイン全体とそのすべてのサブドメインが「偽」になるため、大規模な停止が発生する可能性があります。
o Section 3 updates [RFC6698] to specify a requirement for clients to support at least TLS 1.0 and to support SNI.
o セクション3は、クライアントが少なくともTLS 1.0をサポートし、SNIをサポートするための要件を指定するために[RFC6698]を更新します。
o Section 4 explains that application support for all four certificate usages is NOT RECOMMENDED. The recommended design is to support just DANE-EE(3) and DANE-TA(2).
o セクション4では、4つすべての証明書の使用に対するアプリケーションサポートは推奨されないことを説明しています。推奨される設計は、DANE-EE（3）とDANE-TA（2）のみをサポートすることです。
o Section 5.1 updates [RFC6698] to specify that peer identity matching and validity period enforcement are based solely on the TLSA RRset properties. It also specifies DANE authentication of raw public keys [RFC7250] via TLSA records with certificate usage DANE-EE(3) and selector SPKI(1).
o セクション5.1は[RFC6698]を更新して、ピアIDの一致と有効期間の強制がTLSA RRsetプロパティのみに基づくことを指定しています。また、証明書の使用法DANE-EE（3）とセレクターSPKI（1）を使用したTLSAレコードを介した生の公開鍵[RFC7250]のDANE認証も指定しています。
o Section 5.2 updates [RFC6698] to require that servers publishing digest TLSA records with a usage of DANE-TA(2) MUST include the TA certificate in their TLS server certificate message. This extends to the case of "2 1 0" TLSA records that publish a full public key.
o セクション5.2は、DANE-TA（2）を使用してダイジェストTLSAレコードを公開するサーバーがTLSサーバー証明書メッセージにTA証明書を含める必要があることを要求するように[RFC6698]を更新します。これは、完全な公開鍵を公開する "2 1 0" TLSAレコードの場合にまで及びます。
o Section 5.4 observes that with usage PKIX-TA(0), clients may need to process extended trust chains beyond the first trusted issuer when that issuer is not self-signed.
o セクション5.4では、使用法PKIX-TA（0）を使用すると、クライアントは、最初の信頼された発行者を超えた拡張信頼チェーンを、その発行者が自己署名されていない場合に処理する必要がある場合があります。
o Section 7 recommends that DANE application protocols specify that, when possible, securely CNAME-expanded names be used to derive the TLSA base domain.
o セクション7では、DANEアプリケーションプロトコルで、可能な場合は安全にCNAMEで拡張された名前を使用してTLSAベースドメインを導出することを指定することを推奨しています。
o Section 8 specifies a strategy for managing TLSA records that interoperates with DANE clients regardless of what subset of the possible TLSA record types (combinations of TLSA parameters) is supported by the client.
o セクション8では、クライアントがサポートする可能性のあるTLSAレコードタイプのサブセット（TLSAパラメータの組み合わせ）に関係なく、DANEクライアントと相互運用するTLSAレコードを管理するための戦略を規定しています。
o Section 9 specifies a digest algorithm agility protocol.
o セクション9は、ダイジェストアルゴリズムの俊敏性プロトコルを指定します。
o Section 10.1 recommends against the use of Full(0) TLSA records, as digest records are generally much more compact.
o ダイジェストレコードは一般的にはるかにコンパクトであるため、セクション10.1ではFull（0）TLSAレコードの使用を推奨していません。
The DNS TTL of TLSA records needs to be chosen with care. When an unplanned change in the server's certificate chain and TLSA RRset is required, such as when keys are compromised or lost, clients that cache stale TLSA records will fail to validate the certificate chain of the updated server. Publish TLSA RRsets with TTLs that are short enough to limit unplanned service disruption to an acceptable duration.
TLSAレコードのDNS TTLは慎重に選択する必要があります。サーバーの証明書チェーンとTLSA RRsetの計画外の変更が必要な場合（キーが危険にさらされたり失われたりした場合など）、古いTLSAレコードをキャッシュするクライアントは、更新されたサーバーの証明書チェーンを検証できません。計画外のサービス中断を許容可能な期間に制限するのに十分短いTTLを使用してTLSA RRsetを公開します。
The signature lifetime (length of the signature validity period) for TLSA records SHOULD NOT be too long. Signed DNSSEC records can be replayed by an MITM attacker, provided the signatures have not yet expired. Shorter signature validity periods allow for faster invalidation of compromised keys. Zone refresh and expiration times for secondary nameservers often imply a lower bound on the signature validity period (Section 11). See Section 4.4.1 of [RFC6781].
TLSAレコードの署名の有効期間（署名の有効期間の長さ）は、長すぎてはなりません（SHOULD NOT）。署名の有効期限が切れていなければ、署名付きDNSSECレコードはMITM攻撃者が再生できます。署名の有効期間が短いほど、侵害されたキーの無効化が速くなります。セカンダリネームサーバーのゾーンの更新と有効期限は、多くの場合、署名の有効期間の下限を意味します（セクション11）。 [RFC6781]のセクション4.4.1を参照してください。
Application protocols that cannot use the existing public CA Web PKI may choose to not implement certain TLSA record types defined in [RFC6698]. If such records are published despite not being supported by the application protocol, they are treated as "unusable". When TLS is opportunistic, the client MAY proceed to use the server with mandatory unauthenticated TLS. This is stronger than opportunistic TLS without DANE, since in that case the client may also proceed with a cleartext connection. When TLS is not opportunistic, the client MUST NOT connect to the server.
既存のパブリックCA Web PKIを使用できないアプリケーションプロトコルは、[RFC6698]で定義されている特定のTLSAレコードタイプを実装しないことを選択する場合があります。アプリケーションプロトコルでサポートされていないにもかかわらず、そのようなレコードが公開された場合、それらは「使用不可」として扱われます。 TLSが便宜的である場合、クライアントは、認証されていない必須のTLSを備えたサーバーを引き続き使用できます（MAY）。これはDANEのない便宜的なTLSよりも強力です。その場合、クライアントもクリアテキスト接続を続行する可能性があるためです。 TLSが便宜的でない場合、クライアントはサーバーに接続してはなりません（MUST NOT）。
Thus, when TLSA records are used with opportunistic protocols where PKIX-TA(0) and PKIX-EE(1) do not apply, the recommended protocol design is for servers to not publish such TLSA records, and for opportunistic TLS clients to use them to only enforce the use of (albeit unauthenticated) TLS but otherwise treat them as unusable. Of course, when PKIX-TA(0) and PKIX-EE(1) are supported by the application protocol, clients MUST implement these certificate usages as described in [RFC6698] and this document.
したがって、PKIX-TA（0）およびPKIX-EE（1）が適用されない日和見プロトコルでTLSAレコードが使用される場合、推奨されるプロトコル設計は、サーバーがそのようなTLSAレコードを公開しないようにし、日和見TLSクライアントがそれらを使用するようにすることです。 （認証されていなくても）TLSの使用を強制するだけで、それ以外の場合は使用不可として扱います。もちろん、PKIX-TA（0）およびPKIX-EE（1）がアプリケーションプロトコルでサポートされている場合、クライアントは、[RFC6698]およびこのドキュメントで説明されているように、これらの証明書の使用法を実装する必要があります。
[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セキュリティの概要と要件」、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>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[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>。
[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>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<http://www.rfc-editor.org/info/rfc6347>。
[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>。
[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>。
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, <http://www.rfc-editor.org/info/rfc7250>.
[RFC7250] Wouters、P.、Ed。、Tschofenig、H.、Ed。、Gilmore、J.、Weiler、S.、and T. Kivinen、 "Using Raw Public Keys in Transport Layer Security（TLS）and Datagram Transport Layerセキュリティ（DTLS）」、RFC 7250、DOI 10.17487 / RFC7250、2014年6月、<http://www.rfc-editor.org/info/rfc7250>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, <http://www.rfc-editor.org/info/rfc6781>.
[RFC6781] Kolkman、O.、Mekking、W.、and R. Gieben、 "DNSSEC Operational Practices、Version 2"、RFC 6781、DOI 10.17487 / RFC6781、December 2012、<http://www.rfc-editor.org / info / rfc6781>。
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <http://www.rfc-editor.org/info/rfc6962>.
[RFC6962]ローリーB.、ラングレーA.、およびE.キャスパー、「証明書の透明性」、RFC 6962、DOI 10.17487 / RFC6962、2013年6月、<http://www.rfc-editor.org/info/rfc6962 >。
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435] Dukhovni、V。、「日和見セキュリティ：ほとんどの場合はある程度の保護」、RFC 7435、DOI 10.17487 / RFC7435、2014年12月、<http://www.rfc-editor.org/info/rfc7435>。
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10.17487/RFC7672, October 2015, <http://www.rfc-editor.org/info/rfc7672>.
[RFC7672] Dukhovni、V。およびW. Hardaker、「名前付きエンティティの便宜的DNSベース認証（DANE）トランスポート層セキュリティ（TLS）によるSMTPセキュリティ」、RFC 7672、DOI 10.17487 / RFC7672、2015年10月、<http：/ /www.rfc-editor.org/info/rfc7672>。
[RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 2015, <http://www.rfc-editor.org/info/rfc7673>.
[RFC7673] Finch、T.、Miller、M。、およびP. Saint-Andre、「DNSベースの名前付きエンティティの認証（DANE）TLSAレコードとSRVレコードの使用」、RFC 7673、DOI 10.17487 / RFC7673、2015年10月、 <http://www.rfc-editor.org/info/rfc7673>。
Acknowledgements
謝辞
The authors would like to thank Phil Pennock for his comments and advice on this document.
著者は、このドキュメントに関する彼のコメントとアドバイスをしてくれたPhil Pennockに感謝します。
Acknowledgements from Viktor: Thanks to Tony Finch, who finally prodded me into participating in DANE working group discussions. Thanks to Paul Hoffman, who motivated me to produce this document and provided feedback on early draft versions of it. Thanks also to Samuel Dukhovni for editorial assistance.
Viktorからの謝辞：最後に私をDANEワーキンググループディスカッションに参加させたTony Finchに感謝します。このドキュメントを作成する動機を与え、初期のドラフトバージョンに関するフィードバックを提供してくれたPaul Hoffmanに感謝します。編集の支援をしてくれたSamuel Dukhovniにも感謝します。
Authors' Addresses
著者のアドレス
Viktor Dukhovni Two Sigma
ビクタースピリチュアルツーシグマ
Email: ietf-dane@dukhovni.org
Wes Hardaker Parsons P.O. Box 382 Davis, CA 95617 United States
うぇｓ はｒだけｒ ぱｒそんｓ Ｐ。お。 ぼｘ ３８２ だゔぃｓ、 か ９５６１７ うにてｄ Ｓたてｓ
Email: ietf@hardakers.net