< draft-ietf-dane-openpgpkey-05.txt		draft-ietf-dane-openpgpkey-06.txt >
	Network Working Group P. Wouters		Network Working Group P. Wouters
	Internet-Draft Red Hat		Internet-Draft Red Hat
	Intended status: Experimental August 28, 2015		Intended status: Experimental October 20, 2015
	Expires: February 29, 2016		Expires: April 22, 2016
	Using DANE to Associate OpenPGP public keys with email addresses		Using DANE to Associate OpenPGP public keys with email addresses
	draft-ietf-dane-openpgpkey-05		draft-ietf-dane-openpgpkey-06
	Abstract		Abstract
	OpenPGP is a message format for email (and file) encryption that		OpenPGP is a message format for email (and file) encryption that
	lacks a standardized lookup mechanism to securely obtain OpenPGP		lacks a standardized lookup mechanism to securely obtain OpenPGP
	public keys. This document specifies a method for publishing and		public keys. This document specifies a method for publishing and
	locating OpenPGP public keys in DNS for a specific email address		locating OpenPGP public keys in DNS for a specific email address
	using a new OPENPGPKEY DNS Resource Record. Security is provided via		using a new OPENPGPKEY DNS Resource Record. Security is provided via
	DNSSEC.		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 send unencrypted.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on February 29, 2016.		This Internet-Draft will expire on April 22, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Experiment goal . . . . . . . . . . . . . . . . . . . . . 3
	2. The OPENPGPKEY Resource Record . . . . . . . . . . . . . . . 3		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
			2. The OPENPGPKEY Resource Record . . . . . . . . . . . . . . . 4
	2.1. The OPENPGPKEY RDATA component . . . . . . . . . . . . . 4		2.1. The OPENPGPKEY RDATA component . . . . . . . . . . . . . 4
	2.1.1. The OPENPGPKEY RDATA content . . . . . . . . . . . . 4		2.1.1. The OPENPGPKEY RDATA content . . . . . . . . . . . . 5
	2.1.2. Reducing the Transferable Public Key size . . . . . . 5		2.1.2. Reducing the Transferable Public Key size . . . . . . 5
	2.2. The OPENPGPKEY RDATA wire format . . . . . . . . . . . . 5		2.2. The OPENPGPKEY RDATA wire format . . . . . . . . . . . . 6
	2.3. The OPENPGPKEY RDATA presentation format . . . . . . . . 5		2.3. The OPENPGPKEY RDATA presentation format . . . . . . . . 6
	3. Location of the OPENPGPKEY record . . . . . . . . . . . . . . 5		3. Location of the OPENPGPKEY record . . . . . . . . . . . . . . 6
	4. Email address variants . . . . . . . . . . . . . . . . . . . 6		4. Email address variants . . . . . . . . . . . . . . . . . . . 7
	5. Application use of OPENPGPKEY . . . . . . . . . . . . . . . . 7		5. Application use of OPENPGPKEY . . . . . . . . . . . . . . . . 7
	5.1. Obtaining an OpenPGP key for a specific email address . . 7		5.1. Obtaining an OpenPGP key for a specific email address . . 8
	5.2. Confirming the validity of an OpenPGP key . . . . . . . . 7		5.2. Confirming the validity of an OpenPGP key . . . . . . . . 8
	5.3. Verifying an unknown OpenPGP signature . . . . . . . . . 7		5.3. Public Key UIDs and query names . . . . . . . . . . . . . 8
	6. OpenPGP Key size and DNS . . . . . . . . . . . . . . . . . . 7		6. OpenPGP Key size and DNS . . . . . . . . . . . . . . . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 8		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	7.1. Response size . . . . . . . . . . . . . . . . . . . . . . 8		7.1. MTA behaviour . . . . . . . . . . . . . . . . . . . . . . 10
	7.2. Email address information leak . . . . . . . . . . . . . 8		7.2. MUA behaviour . . . . . . . . . . . . . . . . . . . . . . 11
	7.3. Storage of OPENPGPKEY data . . . . . . . . . . . . . . . 9		7.3. Email client behaviour . . . . . . . . . . . . . . . . . 11
	7.4. Forward security of OpenPGP versus DNSSEC . . . . . . . . 9		7.4. Response size . . . . . . . . . . . . . . . . . . . . . . 11
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7.5. Email address information leak . . . . . . . . . . . . . 11
	8.1. OPENPGPKEY RRtype . . . . . . . . . . . . . . . . . . . . 10		7.6. Storage of OPENPGPKEY data . . . . . . . . . . . . . . . 12
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		7.7. Security of OpenPGP versus DNSSEC . . . . . . . . . . . . 12
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		8. Implementation Status . . . . . . . . . . . . . . . . . . . . 12
	10.1. Normative References . . . . . . . . . . . . . . . . . . 10		8.1. The GNU Privacy Guard (GNUpg) . . . . . . . . . . . . . . 13
	10.2. Informative References . . . . . . . . . . . . . . . . . 11		8.2. hash-slinger . . . . . . . . . . . . . . . . . . . . . . 14
	Appendix A. Generating OPENPGPKEY records . . . . . . . . . . . 11		8.3. openpgpkey-milter . . . . . . . . . . . . . . . . . . . . 14
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
			9.1. OPENPGPKEY RRtype . . . . . . . . . . . . . . . . . . . . 15
			10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
			11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
			11.1. Normative References . . . . . . . . . . . . . . . . . . 15
			11.2. Informative References . . . . . . . . . . . . . . . . . 16
			Appendix A. Generating OPENPGPKEY records . . . . . . . . . . . 17
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	OpenPGP [RFC4880] public keys are used to encrypt or sign email		OpenPGP [RFC4880] public keys are used to encrypt or sign email
	messages and files. To encrypt an email message, or verify a		messages and files. To encrypt an email message, or verify a
	sender's OpenPGP signature, the email client or MTA needs to locate		sender's OpenPGP signature, the email client or MTA needs to locate
	the recipient's OpenPGP public key.		the recipient's OpenPGP public key.
	OpenPGP clients have relied on centralized "well-known" key servers		OpenPGP clients have relied on centralized "well-known" key servers
	that are accessed using either the HTTP Keyserver Protocol [HKP]		that are accessed using either the HTTP Keyserver Protocol [HKP]
	skipping to change at page 3, line 29 ¶		skipping to change at page 3, line 31 ¶
	Therefor, these keyservers are not well suited to support email		Therefor, these keyservers are not well suited to support email
	clients and MTA's to automatically encrypt email - especially in the		clients and MTA's to automatically encrypt email - especially in the
	absence of an interactive user.		absence of an interactive user.
	This document describes a mechanism to associate a user's OpenPGP		This document describes a mechanism to associate a user's OpenPGP
	public key with their email address, using the OPENPGPKEY DNS RRtype.		public key with their email address, using the OPENPGPKEY DNS RRtype.
	These records are published in the DNS zone of the user's email		These records are published in the DNS zone of the user's email
	address. If the user loses their private key, the OPENPGPKEY DNS		address. If the user loses their private key, the OPENPGPKEY DNS
	record can simply be updated or removed from the zone.		record can simply be updated or removed from the zone.
	The proposed new DNS Resource Record type is secured using DNSSEC.		The OPENPGPKEY data is secured using Secure DNS.
	This trust model is not meant to replace the Web Of Trust model.
	1.1. Terminology		The main goal of the OPENPGPKEY resource record is to stop passive
			attacks against plaintext emails. While it can also twart some
			active attacks (such as people uploading rogue keys to keyservers 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.
			1.1. Experiment goal
			This document defines an Experimental RRtype. The goal of the
			experiment is to see whether encrypted email usage will increase if
			an automated discovery method is available to MTA's and MUA's to help
			the enduser with email encryption key management.
			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 this is a problem or not.
			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 generality 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.
			1.2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	This document also makes use of standard DNSSEC and DANE terminology.		This document also makes use of standard DNSSEC and DANE terminology.
	See DNSSEC [RFC4033], [RFC4034], [RFC4035], and DANE [RFC6698] for		See DNSSEC [RFC4033], [RFC4034], [RFC4035], and DANE [RFC6698] for
	these terms.		these terms.
	2. The OPENPGPKEY Resource Record		2. The OPENPGPKEY Resource Record
	skipping to change at page 7, line 38 ¶		skipping to change at page 8, line 31 ¶
	old OpenPGP public key. Applications and users can perform an		old OpenPGP public key. Applications and users can perform an
	OPENPGPKEY lookup to confirm the locally stored OpenPGP public key is		OPENPGPKEY lookup to confirm the locally stored OpenPGP public key is
	still the correct key to use. If verifying a locally stored OpenPGP		still the correct key to use. If verifying a locally stored OpenPGP
	public key and the OpenPGP public key found through DNS is different		public key and the OpenPGP public key found through DNS is different
	from the locally stored OpenPGP public key, the verification MUST be		from the locally stored OpenPGP public key, the verification MUST be
	treated as a failure. An application that can interact with the user		treated as a failure. An application that can interact with the user
	MAY ask the user for guidance. For privacy reasons, an application		MAY ask the user for guidance. For privacy reasons, an application
	MUST NOT attempt to validate a locally stored OpenPGP key using an		MUST NOT attempt to validate a locally stored OpenPGP key using an
	OPENPGPKEY lookup at every use of that key.		OPENPGPKEY lookup at every use of that key.
	5.3. Verifying an unknown OpenPGP signature		5.3. Public Key UIDs and query names
	Storage media can be signed using an OpenPGP public key. Even if the		An OpenPGP public key can be associated with multiple email addresses
	OpenPGP public key is included on the storage media, it needs to be		by specifying multiple key uids. The OpenPGP public key obtained
	independently validated. OpenPGP public keys contain one or more IDs		from a OPENPGPKEY RR can be used as long as the query and resulting
	than can have the syntax of an email address. An application can		data form a proper email to uid identity association.
	perform a lookup for an OPENPGPKEY at the expected location for the
	specific email address to confirm the validity of the OpenPGP public		CNAME's (see [RFC2181]) and DNAME's (see [RFC6672]) can be followed
	key. Once the key has been validated, all files on the storage media		to obtain an OPENPGPKEY RR, as long as the original recipient's email
	that have been signed by this key can now be verified.		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".
			If one of the OpenPGP key uids contains only a single wildcard as the
			LHS 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 (eg hugh@*.com) or regular expressions in key uids
			are not allowed, and any OPENPGPKEY RR containing these should be
			ignored.
	6. OpenPGP Key size and DNS		6. OpenPGP Key size and DNS
	Due to the expected size of the OPENPGPKEY record, applications		Due to the expected size of the OPENPGPKEY record, applications
	SHOULD use TCP - not UDP - to perform queries for the OPENPGPKEY		SHOULD use TCP - not UDP - to perform queries for the OPENPGPKEY
	Resource Record.		Resource Record.
	Although the reliability of the transport of large DNS Resource		Although the reliability of the transport of large DNS Resource
	Records has improved in the last years, it is still recommended to		Records has improved in the last years, it is still recommended to
	keep the DNS records as small as possible without sacrificing the		keep the DNS records as small as possible without sacrificing the
	security properties of the public key. The algorithm type and key		security properties of the public key. The algorithm type and key
	size of OpenPGP keys should not be modified to accommodate this		size of OpenPGP keys should not be modified to accommodate this
	section.		section.
	OpenPGP supports various attributes that do not contribute to the		OpenPGP supports various attributes that do not contribute to the
	security of a key, such as an embedded image file. It is recommended		security of a key, such as an embedded image file. It is recommended
	that these properties are not exported to OpenPGP public keyrings		that these properties are not exported to OpenPGP public keyrings
	that are used to create OPENPGPKEY Resource Records. Some OpenPGP		that are used to create OPENPGPKEY Resource Records. Some OpenPGP
	software, for example GnuPG, have support for a "minimal key export"		software, for example GnuPG, have support for a "minimal key export"
	that is well suited to use as OPENPGPKEY RDATA. See Appendix A.		that is well suited to use as OPENPGPKEY RDATA. See Appendix A.
	7. Security Considerations		7. Security Considerations
	OPENPGPKEY usage considerations are published in [OPENPGPKEY-USAGE].		DNSSEC is not an alternative for the "web of trust" or for manual
			fingerprint verification by humans. It is a solution aimed to ease
			obtaining someone's public key, and without manual verification
			should be treated as "better then plaintext" only. While this twarts
			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 verification of their
			public key via other out-of-band methods before sending any
			confidential or sensitive information.
	7.1. Response size		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.
			Various components could be responsible for encrypting an email
			message to a target recipient. It could be done by the sender's
			email client or software plugin, the sender's Mail User Agent (MUA)
			or the sender's Mail Transfer Agent (MTA). Each of these have their
			own characteristics. An email client can direct the human 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 programs should attempt to
			encrypt an unencrypted received message whenever possible.
			Organisations that are required to be able to read everyone's
			encrypted email should publish the escrow key as the OPENPGPKEY
			record. Upon receipt, such mail servers MAY optionally re-encrypt
			the message to the individual's OpenPGP key.
			7.1. MTA behaviour
			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.
			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.
			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.
			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.
			If the DNS request for an OPENPGPKEY record returned an
			"indeterminate" or "bogus" answer, the MTA MUST NOT sent 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.
			If multiple non-revoked OPENPGPKEY resource records are found, the
			MTA SHOULD pick the most secure RR based on its local policy.
			7.2. MUA behaviour
			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 MUST NOT accept the message for delivery.
			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.
			If multiple non-revoked OPENPGPKEY resource records are found, the
			MUA SHOULD pick the most secure OpenPGP public key based on its local
			policy.
			7.3. Email client behaviour
			Email clients should adhere to the above listed MUA behaviour.
			Additionally, an email client MAY interact with the user to resolve
			any conflicts between locally stored keyrings and OPENPGPKEY RRdata.
			An email client that is encrypting a message SHOULD clearly indicate
			to the user the difference between encrypting to a locally stored and
			humanly verified public key and encrypting to an unverified (by the
			human sender) public key obtained via an OPENPGPKEY resource record.
			7.4. Response size
	To prevent amplification attacks, an Authoritative DNS server MAY		To prevent amplification attacks, an Authoritative DNS server MAY
	wish to prevent returning OPENPGPKEY records over UDP unless the		wish to prevent returning OPENPGPKEY records over UDP unless the
	source IP address has been verified with [DNS-COOKIES]. Such servers		source IP address has been verified with [EDNS-COOKIE]. Such servers
	MUST NOT return REFUSED, but answer the query with an empty Answer		MUST NOT return REFUSED, but answer the query with an empty Answer
	Section and the truncation flag set ("TC=1").		Section and the truncation flag set ("TC=1").
	7.2. Email address information leak		7.5. Email address information leak
	The hashing of the user name in this document is not a security		The hashing of the user name in this document is not a security
	feature. Publishing OPENPGPKEY records however, will create a list		feature. Publishing OPENPGPKEY records however, will create a list
	of hashes of valid email addresses, which could simplify obtaining a		of hashes of valid email addresses, which could simplify obtaining a
	list of valid email addresses for a particular domain. It is		list of valid email addresses for a particular domain. It is
	desirable to not ease the harvesting of email addresses where		desirable to not ease the harvesting of email addresses where
	possible.		possible.
	The domain name part of the email address is not used as part of the		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		hash so that hashes can be used in multiple zones deployed using
	skipping to change at page 9, line 10 ¶		skipping to change at page 12, line 20 ¶
	somewhat countered by using NSEC3.		somewhat countered by using NSEC3.
	DNS zones that are signed with DNSSEC using NSEC for denial of		DNS zones that are signed with DNSSEC using NSEC for denial of
	existence are susceptible to zone-walking, a mechanism that allows		existence are susceptible to zone-walking, a mechanism that allows
	someone to enumerate all the OPENPGPKEY hashes in a zone. This can		someone to enumerate all the OPENPGPKEY hashes in a zone. This can
	be used in combination with previously hashed common or short user		be used in combination with previously hashed common or short user
	names (in rainbow tables) to deduce valid email addresses. DNSSEC-		names (in rainbow tables) to deduce valid email addresses. DNSSEC-
	signed zones using NSEC3 for denial of existence instead of NSEC are		signed zones using NSEC3 for denial of existence instead of NSEC are
	significantly harder to brute-force after performing a zone-walk.		significantly harder to brute-force after performing a zone-walk.
	7.3. Storage of OPENPGPKEY data		7.6. Storage of OPENPGPKEY data
	Users may have a local key store with OpenPGP public keys. An		Users may have a local key store with OpenPGP public keys. An
	application supporting the use of OPENPGPKEY DNS records MUST NOT		application supporting the use of OPENPGPKEY DNS records MUST NOT
	modify the local key store without explicit confirmation of the user,		modify the local key store without explicit confirmation of the user,
	as the application is unaware of the user's personal policy for		as the application is unaware of the user's personal policy for
	adding, removing or updating their local key store. An application		adding, removing or updating their local key store. An application
	MAY warn the user if an OPENPGPKEY record does not match the OpenPGP		MAY warn the user if an OPENPGPKEY record does not match the OpenPGP
	public key in the local key store.		public key in the local key store.
	Applications that do not have users associated with, such as daemon		Applications that cannot interact with users, such as daemon
	processes, SHOULD store OpenPGP public keys obtained via OPENPGPKEY		processes, SHOULD store OpenPGP public keys obtained via OPENPGPKEY
	up to their DNS TTL value. This avoids repeated DNS lookups that		up to their DNS TTL value. This avoids repeated DNS lookups that
	third parties could monitor to determine when an email is being sent		third parties could monitor to determine when an email is being sent
	to a particular user. If TLS is in use between MTA's, only the DNS		to a particular user.
	lookup could happen unencrypted.
	7.4. Forward security of OpenPGP versus DNSSEC
	DNSSEC key sizes are chosen based on the fact that these keys can be		7.7. Security of OpenPGP versus DNSSEC
	rolled with next to no requirement for security in the future. If
	one doubts the strength or security of the DNSSEC key for whatever
	reason, one simply rolls to a new DNSSEC key with a stronger
	algorithm or larger key size. On the other hand, OpenPGP key sizes
	are chosen based on how many years (or decades) their encryption
	should remain unbreakable by adversaries that own large scale
	computational resources.
	This effectively means that anyone who can obtain a DNSSEC private		Anyone who can obtain a DNSSEC private key of a domain name via
	key of a domain name via coercion, theft or brute force calculations,		coercion, theft or brute force calculations, can replace any
	can replace any OPENPGPKEY record in that zone and all of the		OPENPGPKEY record in that zone and all of the delegated child zones.
	delegated child zones, irrespective of the key size of the OpenPGP		Any future messages encrypted with the malicious OpenPGP key could
	keypair. Any future messages encrypted with the malicious OpenPGP		then be read.
	key could then be read.
	Therefore, an OpenPGP key obtained via an OPENPGPKEY record can only		Therefore, an OpenPGP key obtained via an OPENPGPKEY record can only
	be trusted as much as the DNS domain can be trusted, and is no		be trusted as much as the DNS domain can be trusted, and is no
	substitute for in-person key verification of the "Web of Trust". See		substitute for in-person key verification or verification via the
	[OPENPGPKEY-USAGE] for more in-depth information on safe usage of		"Web of Trust".
	OPENPGPKEY based OpenPGP keys.
	8. IANA Considerations		8. Implementation Status
	8.1. OPENPGPKEY RRtype		[RFC Editor Note: Please remove this entire seciton prior to
			publication as an RFC.]
			This section records the status of known implementations of the
			protocol defined by this specification at the time of posting of this
			Internet-Draft, and is based on a proposal described in [RFC6982].
			The description of implementations in this section is intended to
			assist the IETF in its decision processes in progressing drafts to
			RFCs. Please note that the listing of any individual implementation
			here does not imply endorsement by the IETF. Furthermore, no effort
			has been spent to verify the information presented here that was
			supplied by IETF contributors. This is not intended as, and must not
			be construed to be, a catalog of available implementations or their
			features. Readers are advised to note that other implementations may
			exist. According to RFC 6982, "this will allow reviewers and working
			groups to assign due consideration to documents that have the benefit
			of running code, which may serve as evidence of valuable
			experimentation and feedback that have made the implemented protocols
			more mature. It is up to the individual working groups to use this
			information as they see fit."
			8.1. The GNU Privacy Guard (GNUpg)
			Implementation Name and Details: The GNUpg software, more commonly
			known as "gpg", is is available at https://gnupg.org/
			Brief Description: Support has been added to gnupg in their git
			repository. This code is expected to be part of the next official
			release.
			Level of Maturity: The implementation has just been added and has
			not seen widespread deployment.
			Coverage: The implementation follows the latest draft with the
			exception that it first performs a lowercase of the local-part
			before hashing. This is done because other parts in the code that
			perform a lookup of uid already performed a localcasing to ensure
			case insensitivity. The implementors are tracking the development
			of this draft in particular with respect to the lowercase issue.
			Licensing: All code is covered under the GNU Public License version
			3 or later.
			Implementation Experience: Currrent experience limited to small test
			networks only
			Contact Information: https://gnupg.org/
			Interoperability: No report.
			8.2. hash-slinger
			Implementation Name and Details: The hash-slinger software is a
			collection of tools to generate and verify application DNS records
			written by the author of this document. It is available at http:/
			/people.redhat.com/pwouters/
			Brief Description: Support has been added in the form of an
			"openpgpkey" command that can generate, fetch and verify
			OPENPGPKEY records.
			Level of Maturity: The implementation has been around for a few
			months but has not seen widespread deployment.
			Coverage: The implementation follows the latest draft with the
			exception that it first performs a lowercase of the local-part
			before hashing.
			Licensing: All code is covered under the GNU Public License version
			3 or later.
			Implementation Experience: Currrent experience limited to small test
			networks only
			Contact Information: pwouters@redhat.com
			Interoperability: No report.
			8.3. openpgpkey-milter
			Implementation Name and Details: The openpgpkey-milter is a Postfix
			and Sendmail Mail server plugin (milter) that automatically
			encrypts email before sending further to other SMTP servers. It
			is written by the author of this document. It is available at
			http://github.com/letoams/openpgpkey-milter/
			Brief Description: Before forwarding an unencrypted email, the
			plugin looks for the presence of an OPENPGPKEY record. When
			available, it will encrypt the email message and send out the
			encrypted email.
			Level of Maturity: The implementation has been around for a few
			months but has not seen widespread deployment.
			Coverage: The implementation follows the latest draft with the
			exception that it first performs a lowercase of the local-part
			before hashing.
			Licensing: All code is covered under the GNU Public License version
			3 or later.
			Implementation Experience: Currrent experience limited to small test
			networks only
			Contact Information: pwouters@redhat.com
			Interoperability: No report.
			9. IANA Considerations
			9.1. OPENPGPKEY RRtype
	This document uses a new DNS RR type, OPENPGPKEY, whose value 61 has		This document uses a new DNS RR type, OPENPGPKEY, whose value 61 has
	been allocated by IANA from the Resource Record (RR) TYPEs		been allocated by IANA from the Resource Record (RR) TYPEs
	subregistry of the Domain Name System (DNS) Parameters registry.		subregistry of the Domain Name System (DNS) Parameters registry.
	9. Acknowledgments		10. Acknowledgments
	This document is based on RFC-4255 and draft-ietf-dane-smime whose		This document is based on RFC-4255 and draft-ietf-dane-smime whose
	authors are Paul Hoffman, Jacob Schlyter and W. Griffin. Olafur		authors are Paul Hoffman, Jacob Schlyter and W. Griffin. Olafur
	Gudmundsson provided feedback and suggested various improvements.		Gudmundsson provided feedback and suggested various improvements.
	Willem Toorop contributed the gpg and hexdump command options.		Willem Toorop contributed the gpg and hexdump command options.
	Daniel Kahn Gillmor provided the text describing the OpenPGP packet		Daniel Kahn Gillmor provided the text describing the OpenPGP packet
	formats and filtering options. Edwin Taylor contributed language		formats and filtering options. Edwin Taylor contributed language
	improvements for various iterations of this document. Text regarding		improvements for various iterations of this document. Text regarding
	email mappings was taken from draft-levine-dns-mailbox whose author		email mappings was taken from draft-levine-dns-mailbox whose author
	is John Levine.		is John Levine.
	10. References		11. References
	10.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
			RFC2119, March 1997,
			<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>.
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements", RFC		Rose, "DNS Security Introduction and Requirements", RFC
	4033, March 2005.		4033, DOI 10.17487/RFC4033, March 2005,
			<http://www.rfc-editor.org/info/rfc4033>.
	[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Resource Records for the DNS Security Extensions",		Rose, "Resource Records for the DNS Security Extensions",
	RFC 4034, March 2005.		RFC 4034, DOI 10.17487/RFC4034, March 2005,
			<http://www.rfc-editor.org/info/rfc4034>.
	[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Protocol Modifications for the DNS Security		Rose, "Protocol Modifications for the DNS Security
	Extensions", RFC 4035, March 2005.		Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
			<http://www.rfc-editor.org/info/rfc4035>.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,		Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<http://www.rfc-editor.org/info/rfc4648>.		<http://www.rfc-editor.org/info/rfc4648>.
	[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.		[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
	Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/		Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/
	RFC4880, November 2007,		RFC4880, November 2007,
	<http://www.rfc-editor.org/info/rfc4880>.		<http://www.rfc-editor.org/info/rfc4880>.
	[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic		[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
	Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January		Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
	2010, <http://www.rfc-editor.org/info/rfc5754>.		2010, <http://www.rfc-editor.org/info/rfc5754>.
	10.2. Informative References		11.2. Informative References
	[DNS-COOKIES]		[EDNS-COOKIE]
	Eastlake, Donald., "Domain Name System (DNS) Cookies",		Eastlake, Donald., "Domain Name System (DNS) Cookies",
	draft-ietf-dnsop-cookies (work in progress), August 2015.		draft-ietf-dnsop-cookies (work in progress), August 2015.
	[HKP] Shaw, D., "The OpenPGP HTTP Keyserver Protocol (HKP)",		[HKP] Shaw, D., "The OpenPGP HTTP Keyserver Protocol (HKP)",
	draft-shaw-openpgp-hkp (work in progress), March 2013.		draft-shaw-openpgp-hkp (work in progress), March 2013.
	[OPENPGPKEY-USAGE]
	Wouters, P., "Usage considerations with the DNS OPENPGPKEY
	record", draft-ietf-dane-openpgpkey-usage (work in
	progress), October 2014.
	[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record		[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
	(RR) Types", RFC 3597, DOI 10.17487/RFC3597, September		(RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
	2003, <http://www.rfc-editor.org/info/rfc3597>.		2003, <http://www.rfc-editor.org/info/rfc3597>.
			[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>.
	[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,		[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
	DOI 10.17487/RFC5321, October 2008,		DOI 10.17487/RFC5321, October 2008,
	<http://www.rfc-editor.org/info/rfc5321>.		<http://www.rfc-editor.org/info/rfc5321>.
	[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI		[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI
	10.17487/RFC5322, October 2008,		10.17487/RFC5322, October 2008,
	<http://www.rfc-editor.org/info/rfc5322>.		<http://www.rfc-editor.org/info/rfc5322>.
	[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for		[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
	Internationalized Email", RFC 6530, DOI 10.17487/RFC6530,		Internationalized Email", RFC 6530, DOI 10.17487/RFC6530,
	February 2012, <http://www.rfc-editor.org/info/rfc6530>.		February 2012, <http://www.rfc-editor.org/info/rfc6530>.
	[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the		[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
	DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,		DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
	<http://www.rfc-editor.org/info/rfc6672>.		<http://www.rfc-editor.org/info/rfc6672>.
	[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication		[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
	of Named Entities (DANE) Transport Layer Security (TLS)		of Named Entities (DANE) Transport Layer Security (TLS)
	Protocol: TLSA", RFC 6698, August 2012.		Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
			2012, <http://www.rfc-editor.org/info/rfc6698>.
			[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
			Code: The Implementation Status Section", RFC 6982, DOI
			10.17487/RFC6982, July 2013,
			<http://www.rfc-editor.org/info/rfc6982>.
	Appendix A. Generating OPENPGPKEY records		Appendix A. Generating OPENPGPKEY records
	The commonly available GnuPG software can be used to generate a		The commonly available GnuPG software can be used to generate a
	minimum Transferable Public Key for the RRdata portion of an		minimum Transferable Public Key for the RRdata portion of an
	OPENPGPKEY record:		OPENPGPKEY record:
	gpg --export --export-options export-minimal,no-export-attributes \		gpg --export --export-options export-minimal,no-export-attributes \
	hugh@example.com | base64		hugh@example.com | base64
End of changes. 37 change blocks.
	85 lines changed or deleted		336 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/