[要約] RFC 7929は、OpenPGPのDANEバインディングのためのDNSベースの認証を提供するための仕様です。その目的は、OpenPGPキーの認証を強化し、信頼性とセキュリティを向上させることです。
Internet Engineering Task Force (IETF) P. Wouters
Request for Comments: 7929 Red Hat
Category: Experimental August 2016
ISSN: 2070-1721
DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP
OpenPGPのDNSベースの名前付きエンティティの認証（DANE）バインディング
Abstract
概要
OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. DNS-Based Authentication of Named Entities (DANE) is a method for publishing public keys in DNS. This document specifies a DANE method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS resource record. Security is provided via Secure DNS, however the OPENPGPKEY record is not a replacement for verification of authenticity via the "web of trust" or manual verification. The OPENPGPKEY record can be used to encrypt an email that would otherwise have to be sent unencrypted.
OpenPGPは電子メール（およびファイル）暗号化のメッセージ形式であり、OpenPGP公開鍵を安全に取得するための標準化された検索メカニズムがありません。名前付きエンティティのDNSベースの認証（DANE）は、DNSで公開キーを公開する方法です。このドキュメントでは、新しいOPENPGPKEY DNSリソースレコードを使用して、特定の電子メールアドレスのDNSでOpenPGP公開鍵を公開および検索するためのDANEメソッドを指定します。セキュリティはセキュアDNSを介して提供されますが、OPENPGPKEYレコードは「信頼の網」による認証の検証や手動による検証の代わりにはなりません。 OPENPGPKEYレコードを使用して、暗号化しないで送信する必要がある電子メールを暗号化できます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7929.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7929で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Experiment Goal . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. The OPENPGPKEY Resource Record . . . . . . . . . . . . . . . 5
2.1. The OPENPGPKEY RDATA Component . . . . . . . . . . . . . 6
2.1.1. The OPENPGPKEY RDATA Content . . . . . . . . . . . . 6
2.1.2. Reducing the Transferable Public Key Size . . . . . . 7
2.2. The OPENPGPKEY RDATA Wire Format . . . . . . . . . . . . 7
2.3. The OPENPGPKEY RDATA Presentation Format . . . . . . . . 7
3. Location of the OPENPGPKEY Record . . . . . . . . . . . . . . 8
4. Email Address Variants and Internationalization
Considerations . . . . . . . . . . . . . . . . . . . . . . . 9
5. Application Use of OPENPGPKEY . . . . . . . . . . . . . . . . 10
5.1. Obtaining an OpenPGP Key for a Specific Email Address . . 10
5.2. Confirming that an OpenPGP Key is Current . . . . . . . . 10
5.3. Public Key UIDs and Query Names . . . . . . . . . . . . . 10
6. OpenPGP Key Size and DNS . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7.1. MTA Behavior . . . . . . . . . . . . . . . . . . . . . . 12
7.2. MUA Behavior . . . . . . . . . . . . . . . . . . . . . . 13
7.3. Response Size . . . . . . . . . . . . . . . . . . . . . . 14
7.4. Email Address Information Leak . . . . . . . . . . . . . 14
7.5. Storage of OPENPGPKEY Data . . . . . . . . . . . . . . . 14
7.6. Security of OpenPGP versus DNSSEC . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. OPENPGPKEY RRtype . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Generating OPENPGPKEY Records . . . . . . . . . . . 18
Appendix B. OPENPGPKEY IANA Template . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
OpenPGP [RFC4880] public keys are used to encrypt or sign email messages and files. To encrypt an email message, or verify a sender's OpenPGP signature, the email client Mail User Agent (MUA) or the email server Mail Transfer Agent (MTA) needs to locate the recipient's OpenPGP public key.
OpenPGP [RFC4880]公開鍵は、電子メールメッセージとファイルの暗号化または署名に使用されます。電子メールメッセージを暗号化するか、送信者のOpenPGP署名を検証するには、電子メールクライアントのメールユーザーエージェント（MUA）または電子メールサーバーのメール転送エージェント（MTA）が受信者のOpenPGP公開鍵を見つける必要があります。
OpenPGP clients have relied on centralized "well-known" key servers that are accessed using the HTTP Keyserver Protocol [HKP]. Alternatively, users need to manually browse a variety of different front-end websites. These key servers do not require a confirmation of the email address used in the User ID (UID) of the uploaded OpenPGP public key. Attackers can -- and have -- uploaded rogue public keys with other people's email addresses to these key servers.
OpenPGPクライアントは、HTTPキーサーバープロトコル[HKP]を使用してアクセスされる、集中化された「既知の」キーサーバーに依存しています。または、ユーザーは手動でさまざまなフロントエンドWebサイトを閲覧する必要があります。これらの鍵サーバーは、アップロードされたOpenPGP公開鍵のユーザーID（UID）で使用されている電子メールアドレスの確認を必要としません。攻撃者は、不正な公開鍵を他の人の電子メールアドレスとともにこれらの鍵サーバーにアップロードすることができます。
Once uploaded, public keys cannot be deleted. People who did not pre-sign a key revocation can never remove their OpenPGP public key from these key servers once they have lost access to their private key. This results in receiving encrypted email that cannot be decrypted.
アップロードした公開鍵は削除できません。鍵の失効に事前署名しなかった人々は、秘密鍵にアクセスできなくなると、OpenPGP公開鍵をこれらの鍵サーバーから削除できません。これにより、復号化できない暗号化された電子メールが受信されます。
Therefore, these key servers are not well suited to support MUAs and MTAs to automatically encrypt email -- especially in the absence of an interactive user.
したがって、これらのキーサーバーは、特にインタラクティブなユーザーがいない場合、MUAおよびMTAをサポートして電子メールを自動的に暗号化するのにはあまり適していません。
This document describes a mechanism to associate a user's OpenPGP public key with their email address, using the OPENPGPKEY DNS RRtype. These records are published in the DNS zone of the user's email address. If the user loses their private key, the OPENPGPKEY DNS record can simply be updated or removed from the zone.
このドキュメントでは、OPENPGPKEY DNS RRtypeを使用して、ユーザーのOpenPGP公開鍵を電子メールアドレスに関連付けるメカニズムについて説明します。これらのレコードは、ユーザーのメールアドレスのDNSゾーンに公開されます。ユーザーが秘密キーを紛失した場合、OPENPGPKEY DNSレコードをゾーンから更新または削除するだけです。
The OPENPGPKEY data is secured using Secure DNS [RFC4035].
OPENPGPKEYデータは、Secure DNS [RFC4035]を使用して保護されます。
The main goal of the OPENPGPKEY resource record is to stop passive attacks against plaintext emails. While it can also thwart some active attacks (such as people uploading rogue keys to key servers in the hopes that others will encrypt to these rogue keys), this resource record is not a replacement for verifying OpenPGP public keys via the "web of trust" signatures, or manually via a fingerprint verification.
OPENPGPKEYリソースレコードの主な目的は、プレーンテキストの電子メールに対する受動的な攻撃を阻止することです。また、一部のアクティブな攻撃（他のユーザーがこれらの不正なキーを暗号化することを期待して不正なキーをキーサーバーにアップロードするユーザーなど）を阻止することもできますが、このリソースレコードは、「信頼のWeb」によるOpenPGP公開キーの検証の代わりにはなりません署名、または指紋認証を介して手動で。
This specification is one experiment in improving access to public keys for end-to-end email security. There are a range of ways in which this can reasonably be done for OpenPGP or S/MIME, for example, using the DNS, or SMTP, or HTTP. Proposals for each of these have been made with various levels of support in terms of implementation and deployment. For each such experiment, specifications such as this will enable experiments to be carried out that may succeed or that may uncover technical or other impediments to large- or small-scale deployments. The IETF encourages those implementing and deploying such experiments to publicly document their experiences so that future specifications in this space can benefit.
この仕様は、エンドツーエンドの電子メールセキュリティのために公開鍵へのアクセスを改善するための1つの実験です。これをOpenPGPまたはS / MIMEに対して合理的に行うことができるさまざまな方法があります。たとえば、DNS、SMTP、またはHTTPを使用します。これらのそれぞれの提案は、実装と展開に関してさまざまなレベルのサポートで行われています。このような各実験について、このような仕様により、成功する可能性のある実験、または大規模または小規模の展開に対する技術的またはその他の障害を明らかにできる実験を実行できます。 IETFは、このような実験を実装および展開する人たちに、この分野の将来の仕様が恩恵を受けることができるように、彼らの経験を公に文書化することを奨励します。
This document defines an RRtype whose use is Experimental. The goal of the experiment is to see whether encrypted email usage will increase if an automated discovery method is available to MTAs and MUAs to help the end user with email encryption key management.
このドキュメントでは、実験的な用途を持つRRtypeを定義しています。この実験の目的は、MTAおよびMUAが自動検出方法を使用してエンドユーザーが電子メールの暗号化キーを管理できるようにする場合に、暗号化された電子メールの使用量が増えるかどうかを確認することです。
It is unclear if this RRtype will scale to some of the larger email service deployments. Concerns have been raised about the size of the OPENPGPKEY record and the size of the resulting DNS zone files. This experiment hopefully will give the working group some insight into whether or not this is a problem.
このRRtypeが一部の大規模な電子メールサービス展開に拡張されるかどうかは不明です。 OPENPGPKEYレコードのサイズと結果のDNSゾーンファイルのサイズに関する懸念が提起されました。この実験がうまくいけば、ワーキンググループにこれが問題であるかどうかについての洞察を与えるでしょう。
If the experiment is successful, it is expected that the findings of the experiment will result in an updated document for standards track approval.
実験が成功した場合、実験の結果により、標準化トラック承認のための更新されたドキュメントが得られることが期待されます。
The OPENPGPKEY RRtype somewhat resembles the generic CERT record defined in [RFC4398]. However, the CERT record uses sub-typing with many different types of keys and certificates. It is suspected that its general application of very different protocols (PKIX versus OpenPGP) has been the cause for lack of implementation and deployment. Furthermore, the CERT record uses sub-typing, which is now considered to be a bad idea for DNS.
OPENPGPKEY RRtypeは、[RFC4398]で定義されている一般的なCERTレコードに似ています。ただし、CERTレコードは、さまざまな種類のキーと証明書を使用したサブタイプを使用します。非常に異なるプロトコル（PKIXとOpenPGP）の一般的なアプリケーションが、実装と展開の欠如の原因であると考えられています。さらに、CERTレコードはサブタイピングを使用しますが、これは現在DNSの悪いアイデアと見なされています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This document also makes use of standard DNSSEC and DANE terminology. See DNSSEC [RFC4033], [RFC4034], [RFC4035], and DANE [RFC6698] for these terms.
このドキュメントでは、標準のDNSSECとDANEの用語も使用しています。これらの用語については、DNSSEC [RFC4033]、[RFC4034]、[RFC4035]、およびDANE [RFC6698]を参照してください。
The OPENPGPKEY DNS resource record (RR) is used to associate an end entity OpenPGP Transferable Public Key (see Section 11.1 of [RFC4880]) with an email address, thus forming an "OpenPGP public key association". A user that wishes to specify more than one OpenPGP key, for example, because they are transitioning to a newer stronger key, can do so by adding multiple OPENPGPKEY records. A single OPENPGPKEY DNS record MUST only contain one OpenPGP key.
OPENPGPKEY DNSリソースレコード（RR）を使用して、エンドエンティティのOpenPGP転送可能公開鍵（[RFC4880]のセクション11.1を参照）をメールアドレスに関連付け、「OpenPGP公開鍵の関連付け」を形成します。たとえば、より強力な新しいキーに移行しているために、複数のOpenPGPキーを指定したいユーザーは、複数のOPENPGPKEYレコードを追加することでそれを行うことができます。 1つのOPENPGPKEY DNSレコードには、1つのOpenPGPキーのみを含める必要があります。
The type value allocated for the OPENPGPKEY RR type is 61. The OPENPGPKEY RR is class independent.
OPENPGPKEY RRタイプに割り当てられるタイプ値は61です。OPENPGPKEYRRはクラスに依存しません。
The RDATA portion of an OPENPGPKEY resource record contains a single value consisting of a Transferable Public Key formatted as specified in [RFC4880].
OPENPGPKEYリソースレコードのRDATA部分には、[RFC4880]で指定されている形式の転送可能な公開鍵で構成される単一の値が含まれています。
An OpenPGP Transferable Public Key can be arbitrarily large. DNS records are limited in size. When creating OPENPGPKEY DNS records, the OpenPGP Transferable Public Key should be filtered to only contain appropriate and useful data. At a minimum, an OPENPGPKEY Transferable Public Key for the user hugh@example.com should contain:
OpenPGPの転送可能な公開鍵は、任意に大きくできます。 DNSレコードのサイズには制限があります。 OPENPGPKEY DNSレコードを作成するときは、OpenPGPの転送可能な公開鍵をフィルタリングして、適切で有用なデータのみを含める必要があります。少なくとも、ユーザーhugh@example.comのOPENPGPKEY転送可能な公開鍵には、以下が含まれている必要があります。
o The primary key X o One User ID Y, which SHOULD match 'hugh@example.com' o Self-signature from X, binding X to Y
o 主キーX o「hugh@example.com」と一致する1つのユーザーID Y o Xからの自己署名、XをYにバインド
If the primary key is not encryption-capable, at least one relevant subkey should be included, resulting in an OPENPGPKEY Transferable Public Key containing:
主キーが暗号化に対応していない場合は、少なくとも1つの関連するサブキーを含める必要があります。その結果、OPENPGPKEY転送可能公開キーには次のものが含まれます。
o The primary key X o One User ID Y, which SHOULD match 'hugh@example.com' o Self-signature from X, binding X to Y o Encryption-capable subkey Z o Self-signature from X, binding Z to X o (Other subkeys, if relevant)
o 主キーX o「hugh@example.com」と一致する1つのユーザーID Y o Xからの自己署名、XをYにバインドo暗号化対応サブキーZ o Xからの自己署名、ZをX oにバインド（その他のサブキー（該当する場合）
The user can also elect to add a few third-party certifications, which they believe would be helpful for validation in the traditional "web of trust". The resulting OPENPGPKEY Transferable Public Key would then look like:
ユーザーは、従来の「信頼の網」での検証に役立つと思われるいくつかのサードパーティの証明書を追加することもできます。結果のOPENPGPKEY転送可能公開鍵は次のようになります。
o The primary key X o One User ID Y, which SHOULD match 'hugh@example.com' o Self-signature from X, binding X to Y o Third-party certification from V, binding Y to X o (Other third-party certifications, if relevant) o Encryption-capable subkey Z o Self-signature from X, binding Z to X o (Other subkeys, if relevant)
o 主キーX o「hugh@example.com」と一致する1つのユーザーID Y o Xからの自己署名、XからYへのバインドo Vからのサードパーティ証明書、YからXへのバインドo（その他のサードパーティ証明書、該当する場合）o暗号化対応サブキーZ o Xからの自己署名、ZをXにバインドo（該当する場合、他のサブキー）
When preparing a Transferable Public Key for a specific OPENPGPKEY RDATA format with the goal of minimizing certificate size, a user would typically want to:
証明書のサイズを最小限に抑えることを目的として、特定のOPENPGPKEY RDATA形式の転送可能な公開鍵を準備する場合、ユーザーは通常、次のことを望みます。
o Where one User ID from the certifications matches the looked-up address, strip away non-matching User IDs and any associated certifications (self-signatures or third-party certifications).
o 証明書の1つのユーザーIDが検索されたアドレスと一致する場合、一致しないユーザーIDと関連する証明書（自己署名またはサードパーティの証明書）を取り除きます。
o Strip away all User Attribute packets and associated certifications.
o すべてのユーザー属性パケットと関連する証明書を取り除きます。
o Strip away all expired subkeys. The user may want to keep revoked subkeys if these were revoked prior to their preferred expiration time to ensure that correspondents know about these earlier than expected revocations.
o 期限切れのサブキーをすべて削除します。サブキーが適切な失効時間よりも前に取り消された場合、ユーザーは取り消されたサブキーを保持して、通信相手がこれらのサブキーを予想よりも早く取り消すことを確実にすることができます。
o Strip away all but the most recent self-signature for the remaining User IDs and subkeys.
o 残りのユーザーIDとサブキーの最新の自己署名を除くすべてを取り除きます。
o Optionally strip away any uninteresting or unimportant third-party User ID certifications. This is a value judgment by the user that is difficult to automate. At the very least, expired and superseded third-party certifications should be stripped out. The user should attempt to keep the most recent and most well-connected certifications in the "web of trust" in their Transferable Public Key.
o 必要に応じて、興味のない、または重要でないサードパーティのユーザーID証明書を削除します。これは、自動化が難しいユーザーによる価値判断です。少なくとも、期限切れで置き換えられたサードパーティの証明書は削除する必要があります。ユーザーは、転送可能な公開鍵の「信頼の網」にある最新の最も関連性の高い証明書を保持しようとする必要があります。
The RDATA Wire Format consists of a single OpenPGP Transferable Public Key as defined in Section 11.1 of [RFC4880]. Note that this format is without ASCII armor or base64 encoding.
RDATAワイヤー形式は、[RFC4880]のセクション11.1で定義されている単一のOpenPGP転送可能公開鍵で構成されています。この形式には、ASCII鎧やbase64エンコードが含まれていないことに注意してください。
The RDATA Presentation Format, as visible in master files [RFC1035], consists of a single OpenPGP Transferable Public Key as defined in Section 11.1 of [RFC4880] encoded in base64 as defined in Section 4 of [RFC4648].
マスターファイル[RFC1035]に表示されるRDATAプレゼンテーションフォーマットは、[RFC4880]のセクション11.1で定義されている単一のOpenPGP転送可能公開鍵で構成され、[RFC4648]のセクション4で定義されているbase64でエンコードされています。
The DNS does not allow the use of all characters that are supported in the "local-part" of email addresses as defined in [RFC5322] and [RFC6530]. Therefore, email addresses are mapped into DNS using the following method:
DNSでは、[RFC5322]と[RFC6530]で定義されている電子メールアドレスの「ローカル部分」でサポートされているすべての文字の使用が許可されていません。したがって、メールアドレスは次の方法でDNSにマッピングされます。
1. The "left-hand side" of the email address, called the "local-part" in both the mail message format definition [RFC5322] and in the specification for internationalized email [RFC6530]) is encoded in UTF-8 (or its subset ASCII). If the local-part is written in another charset, it MUST be converted to UTF-8.
1. メールメッセージ形式の定義[RFC5322]と国際化されたメールの仕様[RFC6530]の両方で「ローカル部分」と呼ばれるメールアドレスの「左側」は、UTF-8（またはそのサブセット）でエンコードされていますASCII）。ローカル部分が別の文字セットで記述されている場合は、UTF-8に変換する必要があります。
2. The local-part is first canonicalized using the following rules. If the local-part is unquoted, any comments and/or folding whitespace (CFWS) around dots (".") is removed. Any enclosing double quotes are removed. Any literal quoting is removed.
2. ローカル部分は、最初に次のルールを使用して正規化されます。ローカル部分が引用符で囲まれていない場合、コメントやドット（ "。"）の周りの折りたたみ空白（CFWS）は削除されます。囲んでいる二重引用符は削除されます。リテラル引用は削除されます。
3. If the local-part contains any non-ASCII characters, it SHOULD be normalized using the Unicode Normalization Form C from [Unicode90]. Recommended normalization rules can be found in Section 10.1 of [RFC6530].
3. ローカル部分に非ASCII文字が含まれている場合は、[Unicode90]のUnicode正規化フォームCを使用して正規化する必要があります。推奨される正規化ルールは、[RFC6530]のセクション10.1にあります。
4. The local-part is hashed using the SHA2-256 [RFC5754] algorithm, with the hash truncated to 28 octets and represented in its hexadecimal representation, to become the left-most label in the prepared domain name.
4. ローカル部分は、SHA2-256 [RFC5754]アルゴリズムを使用してハッシュされ、ハッシュは28オクテットに切り捨てられ、16進表記で表され、準備されたドメイン名の左端のラベルになります。
5. The string "_openpgpkey" becomes the second left-most label in the prepared domain name.
5. 文字列 "_openpgpkey"は、準備されたドメイン名の左から2番目のラベルになります。
6. The domain name (the "right-hand side" of the email address, called the "domain" in [RFC5322]) is appended to the result of step 2 to complete the prepared domain name.
6. ドメイン名（[RFC5322]では「ドメイン」と呼ばれる、電子メールアドレスの「右側」）がステップ2の結果に追加され、準備されたドメイン名が完成します。
For example, to request an OPENPGPKEY resource record for a user whose email address is "hugh@example.com", an OPENPGPKEY query would be placed for the following QNAME: "c93f1e400f26708f98cb19d936620da35 eec8f72e57f9eec01c1afd6._openpgpkey.example.com". The corresponding RR in the example.com zone might look like (key shortened for formatting):
たとえば、メールアドレスが「hugh@example.com」であるユーザーのOPENPGPKEYリソースレコードをリクエストするには、次のQNAMEに対してOPENPGPKEYクエリを配置します：「c93f1e400f26708f98cb19d936620da35 eec8f72e57f9eec01c1afd6._openpgpkey.example.com」。 example.comゾーン内の対応するRRは次のようになります（フォーマットするためにキーを短縮）：
c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY <base64 public key>
c9 [..] d6._openpgpkey.example.com。 IN OPENPGPKEY <base64公開鍵>
Mail systems usually handle variant forms of local-parts. The most common variants are upper- and lowercase, often automatically corrected when a name is recognized as such. Other variants include systems that ignore "noise" characters such as dots, so that local-parts 'johnsmith' and 'John.Smith' would be equivalent. Many systems allow "extensions" such as 'john-ext' or 'mary+ext' where 'john' or 'mary' is treated as the effective local-part, and 'ext' is passed to the recipient for further handling. This can complicate finding the OPENPGPKEY record associated with the dynamically created email address.
メールシステムは通常、ローカルパーツのさまざまな形式を処理します。最も一般的なバリエーションは大文字と小文字で、多くの場合、名前がそのように認識されると自動的に修正されます。他のバリアントには、ドットなどの「ノイズ」文字を無視するシステムが含まれるため、ローカルパーツの「johnsmith」と「John.Smith」は同等になります。多くのシステムでは、「john-ext」や「mary + ext」などの「拡張子」を使用できます。「john」または「mary」は有効なローカル部分として扱われ、「ext」はさらに処理するために受信者に渡されます。これにより、動的に作成された電子メールアドレスに関連付けられたOPENPGPKEYレコードの検索が複雑になる可能性があります。
[RFC5321] and its predecessors have always made it clear that only the recipient MTA is allowed to interpret the local-part of an address. Therefore, sending MUAs and MTAs supporting OPENPGPKEY MUST NOT perform any kind of mapping rules based on the email address. In order to improve chances of finding OPENPGP RRs for a particular local-part, domains that allow variant forms (such as treating local-parts as case-insensitive) might publish OPENPGP RRs for all variants of local-parts, might publish variants on first use (for example, a webmail provider that also controls DNS for a domain can publish variants as used by owner of a particular local-part) or just publish OPENPGP RRs for the most common variants.
[RFC5321]とその前身は常に、受信者のMTAだけがアドレスのローカル部分を解釈できることを明確にしてきました。したがって、OPENPGPKEYをサポートするMUAおよびMTAを送信しても、電子メールアドレスに基づいて、いかなる種類のマッピングルールも実行してはなりません。特定のローカルパーツのOPENPGP RRを見つける可能性を高めるために、バリアントフォーム（ローカルパーツを大文字と小文字を区別しないものとして扱うなど）を許可するドメインは、ローカルパーツのすべてのバリアントのOPENPGP RRを公開し、最初にバリアントを公開します。使用（たとえば、ドメインのDNSも制御するWebメールプロバイダーは、特定のローカルパーツの所有者が使用するバリアントを公開できます）または最も一般的なバリアントのOPENPGP RRを公開するだけです。
Section 3 above defines how the local-part is used to determine the location where one looks for an OPENPGPKEY record. Given the variety of local-parts seen in email, designing a good experiment for this is difficult, as: a) some current implementations are known to lowercase at least US-ASCII local-parts, b) we know from (many) other situations that any strategy based on guessing and making multiple DNS queries is not going to achieve consensus for good reasons, and c) the underlying issues are just hard -- see Section 10.1 of [RFC6530] for discussion of just some of the issues that would need to be tackled to fully address this problem.
上記のセクション3では、OPENPGPKEYレコードを探す場所を決定するためにローカルパーツを使用する方法を定義しています。電子メールで見られるローカルパーツの多様性を考えると、これを適切に実験することは困難です。たとえば、a）現在の実装では少なくともUS-ASCIIローカルパーツを小文字にすることがわかっている、b）他の（多くの）状況からわかっている複数のDNSクエリの推測と作成に基づく戦略は、十分な理由でコンセンサスを達成できないこと、およびc）根本的な問題は非常に難しい-必要になる問題の一部のみの説明については、[RFC6530]のセクション10.1を参照この問題に完全に取り組むために取り組むべきです。
However, while this specification is not the place to try to address these issues with local-parts, doing so is also not required to determine the outcome of this experiment. If this experiment succeeds, then further work on email addresses with non-ASCII local-parts will be needed and, based on the findings from this experiment, that would be better than doing nothing or starting this experiment based on a speculative approach to what is a very complex topic.
ただし、この仕様はローカルパーツに関するこれらの問題に対処するための場所ではありませんが、この実験の結果を判断するためにそうする必要もありません。この実験が成功した場合は、ASCII以外のローカルパーツを含む電子メールアドレスでさらに作業が必要になります。この実験の結果に基づいて、何もしないか、何を行うかについての推測的なアプローチに基づいてこの実験を開始するよりも良いでしょう。非常に複雑なトピックです。
The OPENPGPKEY record allows an application or service to obtain an OpenPGP public key and use it for verifying a digital signature or encrypting a message to the public key. The DNS answer MUST pass DNSSEC validation; if DNSSEC validation reaches any state other than "Secure" (as specified in [RFC4035]), the DNSSEC validation MUST be treated as a failure.
OPENPGPKEYレコードを使用すると、アプリケーションまたはサービスはOpenPGP公開鍵を取得し、それを使用してデジタル署名を検証したり、公開鍵へのメッセージを暗号化したりできます。 DNS回答はDNSSEC検証に合格する必要があります。 DNSSEC検証が（[RFC4035]で指定されているように）「セキュア」以外の状態に達した場合、DNSSEC検証は失敗として扱われなければなりません（MUST）。
If no OpenPGP public keys are known for an email address, an OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key that corresponds to that email address. This public key can then be used to verify a received signed message or can be used to send out an encrypted email message. An application whose attempt fails to retrieve a DNSSEC-verified OPENPGPKEY RR from the DNS should remember that failure for some time to avoid sending out a DNS request for each email message the application is sending out; such DNS requests constitute a privacy leak.
電子メールアドレスのOpenPGP公開鍵がわからない場合は、OPENPGPKEY DNSルックアップを実行して、その電子メールアドレスに対応するOpenPGP公開鍵を探すことができます。次に、この公開鍵を使用して、受信した署名付きメッセージを検証したり、暗号化された電子メールメッセージを送信したりできます。 DNSSECで検証されたOPENPGPKEY RRをDNSから取得しようとして失敗したアプリケーションは、アプリケーションが送信する各電子メールメッセージに対するDNS要求の送信を回避するために、しばらくの間失敗を覚えておく必要があります。このようなDNS要求はプライバシーリークを構成します。
Locally stored OpenPGP public keys are not automatically refreshed. If the owner of that key creates a new OpenPGP public key, that owner is unable to securely notify all users and applications that have its old OpenPGP public key. Applications and users can perform an OPENPGPKEY lookup to confirm that the locally stored OpenPGP public key is still the correct key to use. If the locally stored OpenPGP public key is different from the DNSSEC-validated OpenPGP public key currently published in DNS, the confirmation MUST be treated as a failure unless the locally stored OpenPGP key signed the newly published OpenPGP public key found in DNS. An application that can interact with the user MAY ask the user for guidance; otherwise, the application will have to apply local policy. For privacy reasons, an application MUST NOT attempt to look up an OpenPGP key from DNSSEC at every use of that key.
ローカルに保存されたOpenPGP公開鍵は自動的に更新されません。その鍵の所有者が新しいOpenPGP公開鍵を作成した場合、その所有者は古いOpenPGP公開鍵を持つすべてのユーザーとアプリケーションに安全に通知することができません。アプリケーションとユーザーはOPENPGPKEYルックアップを実行して、ローカルに保存されたOpenPGP公開鍵がまだ使用する正しい鍵であることを確認できます。ローカルに保存されたOpenPGP公開鍵が、現在DNSで公開されているDNSSEC検証済みのOpenPGP公開鍵と異なる場合、ローカルで保存されたOpenPGP鍵がDNSで見つかった新しく公開されたOpenPGP公開鍵に署名しない限り、確認は失敗として扱われる必要があります。ユーザーと対話できるアプリケーションは、ユーザーにガイダンスを求めることができます。それ以外の場合、アプリケーションはローカルポリシーを適用する必要があります。プライバシー上の理由から、アプリケーションは、そのキーを使用するたびにDNSSECからOpenPGPキーを検索してはなりません。
An OpenPGP public key can be associated with multiple email addresses by specifying multiple key UIDs. The OpenPGP public key obtained from an OPENPGPKEY RR can be used as long as the query and resulting data form a proper email to the UID identity association.
OpenPGP公開鍵は、複数の鍵UIDを指定することにより、複数の電子メールアドレスに関連付けることができます。 OPENPGPKEY RRから取得したOpenPGP公開鍵は、クエリと結果のデータがUID識別関連付けへの適切な電子メールを形成する限り使用できます。
CNAMEs (see [RFC2181]) and DNAMEs (see [RFC6672]) can be followed to obtain an OPENPGPKEY RR, as long as the original recipient's email address appears as one of the OpenPGP public key UIDs. For example, if the OPENPGPKEY RR query for hugh@example.com (8d57[...]b7._openpgpkey.example.com) yields a CNAME to 8d57[...]b7._openpgpkey.example.net, and an OPENPGPKEY RR for 8d57[...]b7._openpgpkey.example.net exists, then this OpenPGP public key can be used, provided one of the key UIDs contains "hugh@example.com". This public key cannot be used if it would only contain the key UID "hugh@example.net".
CNAME（[RFC2181]を参照）およびDNAME（[RFC6672]を参照）をフォローしてOPENPGPKEY RRを取得できます。ただし、元の受信者の電子メールアドレスがOpenPGP公開鍵UIDの1つとして表示されている場合に限ります。たとえば、hugh @ example.com（8d57 [...] b7._openpgpkey.example.com）のOPENPGPKEY RRクエリがCNAMEを8d57 [...] b7._openpgpkey.example.netに生成し、OPENPGPKEYが8d57 [...] b7._openpgpkey.example.netのRRが存在する場合、キーUIDの1つに「hugh@example.com」が含まれていれば、このOpenPGP公開鍵を使用できます。この公開鍵は、鍵UID "hugh@example.net"のみを含む場合は使用できません。
If one of the OpenPGP key UIDs contains only a single wildcard as the left-hand side of the email address, such as "*@example.com", the OpenPGP public key may be used for any email address within that domain. Wildcards at other locations (e.g., "hugh@*.com") or regular expressions in key UIDs are not allowed, and any OPENPGPKEY RR containing these MUST be ignored.
OpenPGPキーのUIDの1つに「*@example.com」のように、メールアドレスの左側にワイルドカードが1つだけ含まれている場合、OpenPGP公開鍵はそのドメイン内のすべてのメールアドレスに使用できます。他の場所のワイルドカード（例： "hugh@*.com"）またはキーUIDの正規表現は許可されていません。これらを含むOPENPGPKEY RRは無視する必要があります。
Due to the expected size of the OPENPGPKEY record, applications SHOULD use TCP -- not UDP -- to perform queries for the OPENPGPKEY resource record.
OPENPGPKEYレコードの予想されるサイズのため、アプリケーションは、OPENPGPKEYリソースレコードのクエリを実行するために、UDPではなくTCPを使用する必要があります（SHOULD）。
Although the reliability of the transport of large DNS resource records has improved in the last years, it is still recommended to keep the DNS records as small as possible without sacrificing the security properties of the public key. The algorithm type and key size of OpenPGP keys should not be modified to accommodate this section.
大規模なDNSリソースレコードの転送の信頼性はここ数年で向上しましたが、公開キーのセキュリティプロパティを犠牲にすることなく、DNSレコードをできるだけ小さくすることをお勧めします。 OpenPGP鍵のアルゴリズムタイプと鍵サイズは、このセクションに対応するために変更しないでください。
OpenPGP supports various attributes that do not contribute to the security of a key, such as an embedded image file. It is recommended that these properties not be exported to OpenPGP public keyrings that are used to create OPENPGPKEY resource records. Some OpenPGP software (for example, GnuPG) supports a "minimal key export" that is well suited to use as OPENPGPKEY RDATA. See Appendix A.
OpenPGPは、埋め込み画像ファイルなど、キーのセキュリティに寄与しないさまざまな属性をサポートしています。これらのプロパティは、OPENPGPKEYリソースレコードの作成に使用されるOpenPGP公開鍵リングにエクスポートしないことをお勧めします。一部のOpenPGPソフトウェア（たとえば、GnuPG）は、OPENPGPKEY RDATAとしての使用に適した「最小キーエクスポート」をサポートしています。付録Aを参照してください。
DNSSEC is not an alternative for the "web of trust" or for manual fingerprint verification by users. DANE for OpenPGP, as specified in this document, is a solution aimed to ease obtaining someone's public key. Without manual verification of the OpenPGP key obtained via DANE, this retrieved key should only be used for encryption if the only other alternative is sending the message in plaintext. While this thwarts all passive attacks that simply capture and log all plaintext email content, it is not a security measure against active attacks. A user who publishes an OPENPGPKEY record in DNS still expects senders to perform their due diligence by additional (non-DNSSEC) verification of their public key via other out-of-band methods before sending any confidential or sensitive information.
DNSSECは、「信頼の網」やユーザーによる手動の指紋認証の代替手段ではありません。このドキュメントで指定されているDANE for OpenPGPは、誰かの公開鍵の取得を容易にすることを目的としたソリューションです。 DANEを介して取得したOpenPGP鍵を手動で検証しない場合、この取得した鍵は、他の唯一の選択肢がメッセージを平文で送信する場合にのみ暗号化に使用する必要があります。これは、すべてのプレーンテキストの電子メールコンテンツを単にキャプチャしてログに記録するすべての受動的攻撃を阻止しますが、能動的攻撃に対するセキュリティ対策ではありません。 DNSでOPENPGPKEYレコードを公開するユーザーは、機密情報や機密情報を送信する前に、送信者が他の帯域外の方法で公開鍵を（DNSSEC以外で）検証することにより、デューデリジェンスを実行することを期待しています。
In other words, the OPENPGPKEY record MUST NOT be used to send sensitive information without additional verification or confirmation that the OpenPGP key actually belongs to the target recipient.
言い換えると、OPENPGPKEYレコードは、OpenPGPキーが実際にターゲット受信者に属していることの追加の検証または確認なしに機密情報を送信するために使用してはなりません（MUST NOT）。
DNSSEC does not protect the queries from Pervasive Monitoring as defined in [RFC7258]. Since DNS queries are currently mostly unencrypted, a query to look up a target OPENPGPKEY record could reveal that a user using the (monitored) recursive DNS server is attempting to send encrypted email to a target. This information is normally protected by the MUAs and MTAs by using Transport Layer Security (TLS) encryption using STARTTLS. The DNS itself can mitigate some privacy concerns, but the user needs to select a trusted DNS server that supports these privacy-enhancing features. Recursive DNS servers can support DNS Query Name Minimalisation [RFC7816], which limits leaking the QNAME to only the recursive DNS server and the nameservers of the actual zone being queried for. Recursive DNS servers can also support TLS [RFC7858] to ensure that the path between the end user and the recursive DNS server is encrypted.
DNSSECは、[RFC7258]で定義されているPervasive Monitoringからのクエリを保護しません。 DNSクエリは現在ほとんど暗号化されていないため、ターゲットのOPENPGPKEYレコードを検索するクエリで、（監視された）再帰DNSサーバーを使用しているユーザーが暗号化された電子メールをターゲットに送信しようとしていることがわかる場合があります。この情報は通常、STARTTLSを使用するトランスポート層セキュリティ（TLS）暗号化を使用することにより、MUAおよびMTAによって保護されます。 DNS自体はプライバシーの懸念を軽減できますが、ユーザーはこれらのプライバシー強化機能をサポートする信頼できるDNSサーバーを選択する必要があります。再帰DNSサーバーは、DNSクエリ名の最小化[RFC7816]をサポートできます。これにより、QNAMEのリークを、再帰DNSサーバーと、照会される実際のゾーンのネームサーバーのみに制限します。再帰DNSサーバーはTLS [RFC7858]もサポートして、エンドユーザーと再帰DNSサーバー間のパスが確実に暗号化されるようにします。
Various components could be responsible for encrypting an email message to a target recipient. It could be done by the sender's MUA or a MUA plug-in or the sender's MTA. Each of these have their own characteristics. A MUA can ask the user to make a decision before continuing. The MUA can either accept or refuse a message. The MTA must deliver the message as-is, or encrypt the message before delivering. Each of these components should attempt to encrypt an unencrypted outgoing message whenever possible.
さまざまなコンポーネントが、対象の受信者への電子メールメッセージの暗号化を担当する可能性があります。これは、送信者のMUA、MUAプラグイン、または送信者のMTAによって実行できます。これらにはそれぞれ独自の特性があります。 MUAは続行する前にユーザーに決定を求めることができます。 MUAはメッセージを受け入れることも拒否することもできます。 MTAはメッセージをそのまま配信するか、配信前にメッセージを暗号化する必要があります。これらの各コンポーネントは、可能な限り、暗号化されていない送信メッセージを暗号化しようとする必要があります。
In theory, two different local-parts could hash to the same value. This document assumes that such a hash collision has a negligible chance of happening.
理論的には、2つの異なるローカル部分が同じ値にハッシュされる可能性があります。このドキュメントでは、このようなハッシュ衝突が発生する可能性はごくわずかであると想定しています。
Organizations that are required to be able to read everyone's encrypted email should publish the escrow key as the OPENPGPKEY record. Mail servers of such organizations MAY optionally re-encrypt the message to the individual's OpenPGP key.
暗号化された全員のメールを読むことができる必要がある組織は、エスクローキーをOPENPGPKEYレコードとして公開する必要があります。そのような組織のメールサーバーは、オプションで、メッセージを個人のOpenPGPキーに再暗号化できます。
An MTA could be operating in a stand-alone mode, without access to the sender's OpenPGP public keyring, or in a way where it can access the user's OpenPGP public keyring. Regardless, the MTA MUST NOT modify the user's OpenPGP keyring.
MTAは、送信者のOpenPGP公開鍵リングにアクセスせずに、またはユーザーのOpenPGP公開鍵リングにアクセスできる方法で、スタンドアロンモードで動作している可能性があります。いずれにしても、MTAはユーザーのOpenPGP鍵リングを変更してはなりません（MUST NOT）。
An MTA sending an email MUST NOT add the public key obtained from an OPENPGPKEY resource record to a permanent public keyring for future use beyond the TTL.
電子メールを送信するMTAは、OPENPGPKEYリソースレコードから取得した公開鍵を永続的な公開鍵リングに追加して、TTLを超えて将来使用できないようにする必要があります。
If the obtained public key is revoked, the MTA MUST NOT use the key for encryption, even if that would result in sending the message in plaintext.
取得した公開鍵が取り消された場合、メッセージがプレーンテキストで送信されることになっても、MTAはその鍵を暗号化に使用してはなりません（MUST NOT）。
If a message is already encrypted, the MTA SHOULD NOT re-encrypt the message, even if different encryption schemes or different encryption keys would be used.
メッセージがすでに暗号化されている場合、たとえ別の暗号化スキームまたは別の暗号化キーが使用される場合でも、MTAはメッセージを再暗号化すべきではありません（SHOULD NOT）。
If the DNS request for an OPENPGPKEY record returned an Indeterminate or Bogus answer as specified in [RFC4035], the MTA MUST NOT send the message and queue the plaintext message for encrypted delivery at a later time. If the problem persists, the email should be returned via the regular bounce methods.
[RFC4035]で指定されているように、OPENPGPKEYレコードのDNS要求が不確定または偽の応答を返した場合、MTAはメッセージを送信して、後で暗号化された配信のためにプレーンテキストメッセージをキューに入れてはなりません（MUST NOT）。問題が解決しない場合は、通常のバウンス方式でメールを返送してください。
If multiple non-revoked OPENPGPKEY resource records are found, the MTA SHOULD pick the most secure RR based on its local policy.
取り消されていない複数のOPENPGPKEYリソースレコードが見つかった場合、MTAはローカルポリシーに基づいて最も安全なRRを選択する必要があります（SHOULD）。
If the public key for a recipient obtained from the locally stored sender's public keyring differs from the recipient's OPENPGPKEY RR, the MUA SHOULD halt processing the message and interact with the user to resolve the conflict before continuing to process the message.
ローカルに保存された送信者の公開鍵リングから取得した受信者の公開鍵が受信者のOPENPGPKEY RRと異なる場合、MUAはメッセージの処理を停止し、ユーザーと対話して、メッセージの処理を続行する前に競合を解決する必要があります。
If the public key for a recipient obtained from the locally stored sender's public keyring contains contradicting properties for the same key obtained from an OPENPGPKEY RR, the MUA SHOULD NOT accept the message for delivery.
ローカルに保存された送信者の公開鍵リングから取得した受信者の公開鍵にOPENPGPKEY RRから取得した同じ鍵の矛盾するプロパティが含まれている場合、MUAは配信用のメッセージを受け入れてはなりません（SHOULD NOT）。
If multiple non-revoked OPENPGPKEY resource records are found, the MUA SHOULD pick the most secure OpenPGP public key based on its local policy.
取り消されていない複数のOPENPGPKEYリソースレコードが見つかった場合、MUAはローカルポリシーに基づいて最も安全なOpenPGP公開鍵を選択する必要があります（SHOULD）。
The MUA MAY interact with the user to resolve any conflicts between locally stored keyrings and OPENPGPKEY RRdata.
MUAは、ユーザーと対話して、ローカルに格納されたキーリングとOPENPGPKEY RRdataの間の競合を解決できます（MAY）。
A MUA that is encrypting a message SHOULD clearly indicate to the user the difference between encrypting to a locally stored and previously user-verified public key and encrypting to a public key obtained via an OPENPGPKEY resource record that was not manually verified by the user in the past.
メッセージを暗号化しているMUAは、ローカルに保存され、以前にユーザーが検証した公開鍵への暗号化と、ユーザーが手動で検証していないOPENPGPKEYリソースレコードを介して取得した公開鍵への暗号化の違いをユーザーに明確に示す必要があります（SHOULD）。過去。
To prevent amplification attacks, an Authoritative DNS server MAY wish to prevent returning OPENPGPKEY records over UDP unless the source IP address has been confirmed with [RFC7873]. Such servers MUST NOT return REFUSED, but answer the query with an empty answer section and the truncation flag set ("TC=1").
増幅攻撃を防ぐために、権威DNSサーバーは、送信元IPアドレスが[RFC7873]で確認されていない限り、UDPを介してOPENPGPKEYレコードを返さないようにすることができます。このようなサーバーはREFUSEDを返してはなりませんが、空の応答セクションと切り捨てフラグセット（ "TC = 1"）でクエリに応答します。
The hashing of the local-part in this document is not a security feature. Publishing OPENPGPKEY records will create a list of hashes of valid email addresses, which could simplify obtaining a list of valid email addresses for a particular domain. It is desirable to not ease the harvesting of email addresses where possible.
このドキュメントのローカル部分のハッシュはセキュリティ機能ではありません。 OPENPGPKEYレコードを発行すると、有効なメールアドレスのハッシュのリストが作成されます。これにより、特定のドメインの有効なメールアドレスのリストを簡単に取得できます。可能な限りメールアドレスの収集を容易にしないことが望ましいです。
The domain name part of the email address is not used as part of the hash so that hashes can be used in multiple zones deployed using DNAME [RFC6672]. This does makes it slightly easier and cheaper to brute-force the SHA2-256 hashes into common and short local-parts, as single rainbow tables can be re-used across domains. This can be somewhat countered by using NextSECure version 3 (NSEC3).
電子メールアドレスのドメイン名部分はハッシュの一部として使用されないため、DNAME [RFC6672]を使用して展開された複数のゾーンでハッシュを使用できます。これにより、単一のレインボーテーブルをドメイン間で再利用できるため、SHA2-256ハッシュを共通のローカルパーツと短いローカルパーツにブルートフォースするのが少し簡単かつ安価になります。これは、NextSECureバージョン3（NSEC3）を使用することにより、多少対抗できます。
DNS zones that are signed with DNSSEC using NSEC for denial of existence are susceptible to zone walking, a mechanism that allows someone to enumerate all the OPENPGPKEY hashes in a zone. This can be used in combination with previously hashed common or short local-parts (in rainbow tables) to deduce valid email addresses. DNSSEC-signed zones using NSEC3 for denial of existence instead of NSEC are significantly harder to brute-force after performing a zone walk.
存在拒否のためにNSECを使用してDNSSECで署名されたDNSゾーンは、ゾーンウォーキングの影響を受けます。これは、誰かがゾーン内のすべてのOPENPGPKEYハッシュを列挙できるメカニズムです。これは、以前にハッシュされた共通または短いローカル部分（レインボーテーブル内）と組み合わせて使用して、有効な電子メールアドレスを推測できます。 NSECの代わりにNSEC3を使用して存在を拒否するDNSSEC署名ゾーンは、ゾーンウォークを実行した後、ブルートフォースを実行することが著しく困難になります。
Users may have a local key store with OpenPGP public keys. An application supporting the use of OPENPGPKEY DNS records MUST NOT modify the local key store without explicit confirmation of the user, as the application is unaware of the user's personal policy for adding, removing, or updating their local key store. An application MAY warn the user if an OPENPGPKEY record does not match the OpenPGP public key in the local key store.
ユーザーは、OpenPGP公開鍵を持つローカル鍵ストアを持っている場合があります。 OPENPGPKEY DNSレコードの使用をサポートするアプリケーションは、ローカルキーストアの追加、削除、または更新に関するユーザーの個人的なポリシーをアプリケーションが認識していないため、ユーザーの明示的な確認なしにローカルキーストアを変更してはなりません。 OPENPGPKEYレコードがローカルキーストア内のOpenPGP公開鍵と一致しない場合、アプリケーションはユーザーに警告する場合があります。
Applications that cannot interact with users, such as daemon processes, SHOULD store OpenPGP public keys obtained via OPENPGPKEY up to their DNS TTL value. This avoids repeated DNS lookups that third parties could monitor to determine when an email is being sent to a particular user.
デーモンプロセスなど、ユーザーと対話できないアプリケーションは、OPENPGPKEYを介して取得したOpenPGP公開鍵をDNS TTL値まで保存する必要があります（SHOULD）。これにより、特定のユーザーに電子メールが送信されていることをサードパーティが監視するためにDNSルックアップを繰り返すことを回避できます。
Anyone who can obtain a DNSSEC private key of a domain name via coercion, theft, or brute-force calculations, can replace any OPENPGPKEY record in that zone and all of the delegated child zones. Any future messages encrypted with the malicious OpenPGP key could then be read.
強制、盗難、または総当たりの計算を介してドメイン名のDNSSEC秘密キーを取得できるユーザーは、そのゾーンとすべての委任された子ゾーンのOPENPGPKEYレコードを置き換えることができます。その後、悪意のあるOpenPGPキーで暗号化されたメッセージを読み取ることができます。
Therefore, an OpenPGP key obtained via a DNSSEC-validated OPENPGPKEY record can only be trusted as much as the DNS domain can be trusted, and is no substitute for in-person OpenPGP key verification or additional OpenPGP verification via "web of trust" signatures present on the OpenPGP in question.
したがって、DNSSECで検証されたOPENPGPKEYレコードを介して取得したOpenPGP鍵は、DNSドメインが信頼できる場合にのみ信頼でき、対面するOpenPGP鍵検証または「信頼できるWeb」署名による追加のOpenPGP検証の代わりにはなりません。問題のOpenPGPで。
This document uses a new DNS RR type, OPENPGPKEY, whose value 61 has been allocated by IANA from the "Resource Record (RR) TYPEs" subregistry of the "Domain Name System (DNS) Parameters" registry.
このドキュメントでは、新しいDNS RRタイプOPENPGPKEYを使用しています。その値61は、IANAによって「ドメインネームシステム（DNS）パラメータ」レジストリの「リソースレコード（RR）TYPEs」サブレジストリから割り当てられています。
The IANA template for OPENPGPKEY is listed in Appendix B. It was submitted to IANA for review on July 23, 2014 and approved on August 12, 2014.
OPENPGPKEYのIANAテンプレートは付録Bにリストされています。2014年7月23日にレビューのためにIANAに提出され、2014年8月12日に承認されました。
[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>。
[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>。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <http://www.rfc-editor.org/info/rfc2181>.
[RFC2181] Elz、R。およびR. Bush、「Clarifications to the DNS Specification」、RFC 2181、DOI 10.17487 / RFC2181、1997年7月、<http://www.rfc-editor.org/info/rfc2181>。
[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>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<http://www.rfc-editor.org/info/rfc4648>。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, <http://www.rfc-editor.org/info/rfc4880>.
[RFC4880] Callas、J.、Donnerhacke、L.、Finney、H.、Shaw、D。、およびR. Thayer、「OpenPGP Message Format」、RFC 4880、DOI 10.17487 / RFC4880、2007年11月、<http：// www.rfc-editor.org/info/rfc4880>。
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 2010, <http://www.rfc-editor.org/info/rfc5754>.
[RFC5754] Turner、S。、「Using SHA2 Algorithms with Cryptographic Message Syntax」、RFC 5754、DOI 10.17487 / RFC5754、2010年1月、<http://www.rfc-editor.org/info/rfc5754>。
[HKP] Shaw, D., "The OpenPGP HTTP Keyserver Protocol (HKP)", Work in Progress, draft-shaw-openpgp-hkp-00, March 2003.
[HKP] Shaw、D。、「OpenPGP HTTP Keyserver Protocol（HKP）」、作業中、draft-shaw-openpgp-hkp-00、2003年3月。
[MAILBOX] Levine, J., "Encoding mailbox local-parts in the DNS", Work in Progress, draft-levine-dns-mailbox-01, September 2015.
[メールボックス]レバイン、J。、「DNSのメールボックスローカルパーツのエンコード」、作業中、draft-levine-dns-mailbox-01、2015年9月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 2003, <http://www.rfc-editor.org/info/rfc3597>.
[RFC3597] Gustafsson、A。、「Handling of Unknown DNS Resource Record（RR）Types」、RFC 3597、DOI 10.17487 / RFC3597、2003年9月、<http://www.rfc-editor.org/info/rfc3597>。
[RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, DOI 10.17487/RFC4255, January 2006, <http://www.rfc-editor.org/info/rfc4255>.
[RFC4255] Schlyter、J。およびW. Griffin、「DNSを使用したセキュアシェル（SSH）のキーフィンガープリントの安全な公開」、RFC 4255、DOI 10.17487 / RFC4255、2006年1月/ info / rfc4255>。
[RFC4398] Josefsson, S., "Storing Certificates in the Domain Name System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006, <http://www.rfc-editor.org/info/rfc4398>.
[RFC4398] Josefsson、S.、「証明書のドメインネームシステム（DNS）への保存」、RFC 4398、DOI 10.17487 / RFC4398、2006年3月、<http://www.rfc-editor.org/info/rfc4398>。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、DOI 10.17487 / RFC5321、2008年10月、<http://www.rfc-editor.org/info/rfc5321>。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<http://www.rfc-editor.org/info/rfc5322>。
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, February 2012, <http://www.rfc-editor.org/info/rfc6530>.
[RFC6530] Klensin、J。およびY. Ko、「国際化電子メールの概要とフレームワーク」、RFC 6530、DOI 10.17487 / RFC6530、2012年2月、<http://www.rfc-editor.org/info/rfc6530>。
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, <http://www.rfc-editor.org/info/rfc6672>.
[RFC6672] Rose、S。およびW. Wijngaards、「DNAME Redirection in the DNS」、RFC 6672、DOI 10.17487 / RFC6672、2012年6月、<http://www.rfc-editor.org/info/rfc6672>。
[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>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<http://www.rfc-editor.org/info/rfc7258 >。
[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, <http://www.rfc-editor.org/info/rfc7816>.
[RFC7816] Bortzmeyer、S。、「プライバシーを改善するためのDNSクエリ名の最小化」、RFC 7816、DOI 10.17487 / RFC7816、2016年3月、<http://www.rfc-editor.org/info/rfc7816>。
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <http://www.rfc-editor.org/info/rfc7858>.
[RFC7858] Hu、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D。、およびP. Hoffman、「DNS over Transport Layer Security（TLS）の仕様」、RFC 7858、DOI 10.17487 / RFC7858、2016年5月、<http://www.rfc-editor.org/info/rfc7858>。
[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, <http://www.rfc-editor.org/info/rfc7873>.
[RFC7873] Eastlake 3rd、D。およびM. Andrews、「ドメインネームシステム（DNS）Cookie」、RFC 7873、DOI 10.17487 / RFC7873、2016年5月、<http://www.rfc-editor.org/info/rfc7873 >。
[SMIME] Hoffman, P. and J. Schlyter, "Using Secure DNS to Associate Certificates with Domain Names For S/MIME", Work in Progress, draft-ietf-dane-smime-12, July 2016.
[SMIME] Hoffman、P。およびJ. Schlyter、「Secure DNSを使用した証明書とS / MIMEのドメイン名の関連付け」、Work in Progress、draft-ietf-dane-smime-12、2016年7月。
[Unicode90] The Unicode Consortium, "The Unicode Standard, Version 9.0.0", (Mountain View, CA: The Unicode Consortium, 2016. ISBN 978-1-936213-13-9), <http://www.unicode.org/versions/Unicode9.0.0/>.
[Unicode90] Unicode Consortium、「The Unicode Standard、Version 9.0.0」、（Mountain View、CA：The Unicode Consortium、2016。ISBN978-1-936213-13-9）、<http：//www.unicode .org / versions / Unicode9.0.0 />。
The commonly available GnuPG software can be used to generate a minimum Transferable Public Key for the RRdata portion of an OPENPGPKEY record:
一般的に入手可能なGnuPGソフトウェアを使用して、OPENPGPKEYレコードのRRdata部分の最小の転送可能な公開鍵を生成できます。
gpg --export --export-options export-minimal,no-export-attributes \ hugh@example.com | base64
gpg --export --export-options export-minimal、no-export-attributes \ hugh@example.com | base64
The --armor or -a option of the gpg command should not be used, as it adds additional markers around the armored key.
装甲キーの周囲にマーカーを追加するため、gpgコマンドの--armorまたは-aオプションは使用しないでください。
When DNS software reading or signing of the zone file does not yet support the OPENPGPKEY RRtype, the Generic Record Syntax of [RFC3597] can be used to generate the RDATA. One needs to calculate the number of octets and the actual data in hexadecimal:
DNSソフトウェアによるゾーンファイルの読み取りまたは署名がOPENPGPKEY RRtypeをまだサポートしていない場合、[RFC3597]のGeneric Record Syntaxを使用してRDATAを生成できます。オクテットの数と実際のデータを16進数で計算する必要があります。
gpg --export --export-options export-minimal,no-export-attributes \
hugh@example.com | wc -c
gpg --export --export-options export-minimal,no-export-attributes \
hugh@example.com | hexdump -e \
'"\t" /1 "%.2x"' -e '/32 "\n"'
These values can then be used to generate a generic record (line break has been added for formatting):
これらの値を使用して、汎用レコードを生成できます（フォーマットのために改行が追加されています）。
<SHA2-256-trunc(hugh)>._openpgpkey.example.com. IN TYPE61 \# \
<numOctets> <keydata in hex>
The openpgpkey command in the hash-slinger software can be used to generate complete OPENPGPKEY records
ハッシュスリンガーソフトウェアのopenpgpkeyコマンドを使用して、完全なOPENPGPKEYレコードを生成できます。
~> openpgpkey --output rfc hugh@example.com
c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY mQCNAzIG[...]
~> openpgpkey --output generic hugh@example.com
c9[..]d6._openpgpkey.example.com. IN TYPE61 \# 2313 99008d03[...]
This is a copy of the original registration template submitted to IANA; the text (including the references) has not been updated.
これは、IANAに送信された元の登録テンプレートのコピーです。テキスト（参照を含む）は更新されていません。
A. Submission Date: 23-07-2014
A.提出日：2014年7月23日
B.1 Submission Type: [x] New RRTYPE [ ] Modification to RRTYPE B.2 Kind of RR: [x] Data RR [ ] Meta-RR
B.1送信タイプ：[x]新しいRRTYPE [] RRTYPEへの変更B.2 RRの種類：[x]データRR []メタRR
C. Contact Information for submitter (will be publicly posted):
Name: Paul Wouters Email Address: pwouters@redhat.com
International telephone number: +1-647-896-3464
Other contact handles: paul@nohats.ca
D. Motivation for the new RRTYPE application.
D.新しいRRTYPEアプリケーションの動機。
Publishing RFC-4880 OpenPGP formatted keys in DNS with DNSSEC protection to faciliate automatic encryption of emails in defense against pervasive monitoring.
RFC-4880 OpenPGP形式の鍵をDNSSEC保護を使用してDNSで公開し、広範囲にわたる監視を防御する電子メールの自動暗号化を促進します。
E. Description of the proposed RR type.
E.提案されたRRタイプの説明。
http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00#section-2
F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory?
F.既存のRRTYPEのうち、そのニーズを満たすのに最も近いものはどれですか。なぜ不十分なのですか。
The CERT RRtype is the closest match. It unfortunately depends on subtyping, and its use in general is no longer recommended. It also has no human usable presentation format. Some usage types of CERT require external URI's which complicates the security model. This was discussed in the dane working group.
CERT RRtypeは最も近い一致です。残念ながら、これはサブタイプに依存しているため、一般的に使用することはお勧めしません。また、人間が使用できる表示形式もありません。 CERTの一部の使用タイプでは、セキュリティモデルを複雑にする外部URIが必要です。これはデーン作業部会で議論されました。
G. What mnemonic is requested for the new RRTYPE (optional)?
G.新しいRRTYPE（オプション）にはどのニーモニックが必要ですか？
OPENPGPKEY
OPENPGPKEY
H. Does the requested RRTYPE make use of any existing IANA registry or require the creation of a new IANA subregistry in DNS Parameters? If so, please indicate which registry is to be used or created. If a new subregistry is needed, specify the allocation policy for it and its initial contents. Also include what the modification procedures will be.
H.要求されたRRTYPEは、既存のIANAレジストリを使用しますか、それともDNSパラメータで新しいIANAサブレジストリを作成する必要がありますか？その場合は、使用または作成するレジストリを指定してください。新しいサブレジストリが必要な場合は、そのサブレジストリとその初期コンテンツの割り当てポリシーを指定します。また、変更手順を説明します。
The RDATA part uses the key format specified in RFC-4880, which
itself use
https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtm
This RRcode just uses the formats specified in those registries for its RRdata part.
このRRcodeは、それらのレジストリーで指定されたRRdata部分のフォーマットを使用するだけです。
I. Does the proposal require/expect any changes in DNS servers/resolvers that prevent the new type from being processed as an unknown RRTYPE (see [RFC3597])?
I.提案は、新しいタイプが不明なRRTYPEとして処理されるのを防ぐDNSサーバー/リゾルバーの変更を必要としていますか/期待していますか（[RFC3597]を参照）？
No.
の。
J. Comments:
J.コメント：
Currently, three software implementations of draft-ietf-dane-openpgpkey are using a private number.
現在、draft-ietf-dane-openpgpkeyの3つのソフトウェア実装は、プライベート番号を使用しています。
Acknowledgments
謝辞
This document is based on [RFC4255] and [SMIME] whose authors are Paul Hoffman, Jakob Schlyter, and W. Griffin. Olafur Gudmundsson provided feedback and suggested various improvements. Willem Toorop contributed the gpg and hexdump command options. Daniel Kahn Gillmor provided the text describing the OpenPGP packet formats and filtering options. Edwin Taylor contributed language improvements for various iterations of this document. Text regarding email mappings was taken from [MAILBOX] whose author is John Levine.
この文書は、作者がPaul Hoffman、Jakob Schlyter、およびW. Griffinである[RFC4255]および[SMIME]に基づいています。 Olafur Gudmundssonはフィードバックを提供し、さまざまな改善を提案しました。 Willem Tooropがgpgおよびhexdumpコマンドオプションを提供しました。 Daniel Kahn Gillmorが、OpenPGPパケット形式とフィルタリングオプションを説明するテキストを提供しました。 Edwin Taylorは、このドキュメントのさまざまなイテレーションで言語の改善に貢献しました。電子メールのマッピングに関するテキストは、著者がJohn Levineである[MAILBOX]から取得されました。
Author's Address
著者のアドレス
Paul Wouters Red Hat
ポール・ウーターズレッドハット
Email: pwouters@redhat.com