< draft-ietf-dane-openpgpkey-09.txt		draft-ietf-dane-openpgpkey-10.txt >
	Network Working Group P. Wouters		Network Working Group P. Wouters
	Internet-Draft Red Hat		Internet-Draft Red Hat
	Intended status: Experimental April 13, 2016		Intended status: Experimental April 19, 2016
	Expires: October 15, 2016		Expires: October 21, 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-09		draft-ietf-dane-openpgpkey-10
	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. DNS-Based Authentication of Named Entities ("DANE") is		public keys. DNS-Based Authentication of Named Entities ("DANE") is
	a method for publishing public keys in DNS. This document specifies		a method for publishing public keys in DNS. This document specifies
	a DANE method for publishing and locating OpenPGP public keys in DNS		a DANE method for publishing and locating OpenPGP public keys in DNS
	for a specific email address using a new OPENPGPKEY DNS Resource		for a specific email address using a new OPENPGPKEY DNS Resource
	Record. Security is provided via Secure DNS, however the OPENPGPKEY		Record. Security is provided via Secure DNS, however the OPENPGPKEY
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 October 15, 2016.		This Internet-Draft will expire on October 21, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	skipping to change at page 2, line 27 ¶		skipping to change at page 2, line 27 ¶
	2.1. The OPENPGPKEY RDATA component . . . . . . . . . . . . . 5		2.1. The OPENPGPKEY RDATA component . . . . . . . . . . . . . 5
	2.1.1. The OPENPGPKEY RDATA content . . . . . . . . . . . . 5		2.1.1. The OPENPGPKEY RDATA content . . . . . . . . . . . . 5
	2.1.2. Reducing the Transferable Public Key size . . . . . . 6		2.1.2. Reducing the Transferable Public Key size . . . . . . 6
	2.2. The OPENPGPKEY RDATA wire format . . . . . . . . . . . . 6		2.2. The OPENPGPKEY RDATA wire format . . . . . . . . . . . . 6
	2.3. The OPENPGPKEY RDATA presentation format . . . . . . . . 6		2.3. The OPENPGPKEY RDATA presentation format . . . . . . . . 6
	3. Location of the OPENPGPKEY record . . . . . . . . . . . . . . 6		3. Location of the OPENPGPKEY record . . . . . . . . . . . . . . 6
	4. Email address variants and internationalization		4. Email address variants and internationalization
	considerations . . . . . . . . . . . . . . . . . . . . . . . 7		considerations . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Application use of OPENPGPKEY . . . . . . . . . . . . . . . . 8		5. Application use of OPENPGPKEY . . . . . . . . . . . . . . . . 8
	5.1. Obtaining an OpenPGP key for a specific email address . . 8		5.1. Obtaining an OpenPGP key for a specific email address . . 8
	5.2. Confirming that an OpenPGP key is current . . . . . . . . 8		5.2. Confirming that an OpenPGP key is current . . . . . . . . 9
	5.3. Public Key UIDs and query names . . . . . . . . . . . . . 9		5.3. Public Key UIDs and query names . . . . . . . . . . . . . 9
	6. OpenPGP Key size and DNS . . . . . . . . . . . . . . . . . . 9		6. OpenPGP Key size and DNS . . . . . . . . . . . . . . . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7.1. MTA behaviour . . . . . . . . . . . . . . . . . . . . . . 10		7.1. MTA behaviour . . . . . . . . . . . . . . . . . . . . . . 11
	7.2. MUA behaviour . . . . . . . . . . . . . . . . . . . . . . 11		7.2. MUA behaviour . . . . . . . . . . . . . . . . . . . . . . 11
	7.3. Response size . . . . . . . . . . . . . . . . . . . . . . 12		7.3. Response size . . . . . . . . . . . . . . . . . . . . . . 12
	7.4. Email address information leak . . . . . . . . . . . . . 12		7.4. Email address information leak . . . . . . . . . . . . . 12
	7.5. Storage of OPENPGPKEY data . . . . . . . . . . . . . . . 12		7.5. Storage of OPENPGPKEY data . . . . . . . . . . . . . . . 12
	7.6. Security of OpenPGP versus DNSSEC . . . . . . . . . . . . 13		7.6. Security of OpenPGP versus DNSSEC . . . . . . . . . . . . 13
	8. Implementation Status . . . . . . . . . . . . . . . . . . . . 13		8. Implementation Status . . . . . . . . . . . . . . . . . . . . 13
	8.1. The GNU Privacy Guard (GNUpg) . . . . . . . . . . . . . . 13		8.1. The GNU Privacy Guard (GNUpg) . . . . . . . . . . . . . . 13
	8.2. hash-slinger . . . . . . . . . . . . . . . . . . . . . . 14		8.2. hash-slinger . . . . . . . . . . . . . . . . . . . . . . 14
	8.3. openpgpkey-milter . . . . . . . . . . . . . . . . . . . . 14		8.3. openpgpkey-milter . . . . . . . . . . . . . . . . . . . . 15
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	9.1. OPENPGPKEY RRtype . . . . . . . . . . . . . . . . . . . . 15		9.1. OPENPGPKEY RRtype . . . . . . . . . . . . . . . . . . . . 15
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	11.1. Normative References . . . . . . . . . . . . . . . . . . 16		11.1. Normative References . . . . . . . . . . . . . . . . . . 16
	11.2. Informative References . . . . . . . . . . . . . . . . . 16		11.2. Informative References . . . . . . . . . . . . . . . . . 17
	Appendix A. Generating OPENPGPKEY records . . . . . . . . . . . 17		Appendix A. Generating OPENPGPKEY records . . . . . . . . . . . 18
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
	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 (MUA) or the email		sender's OpenPGP signature, the email client (MUA) or the email
	server (MTA) needs to locate the recipient's OpenPGP public key.		server (MTA) needs to locate 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 the HTTP Keyserver Protocol [HKP].		that are accessed using the HTTP Keyserver Protocol [HKP].
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 5 ¶
	Section 11.1 of [RFC4880] encoded in base64 as defined in Section 4		Section 11.1 of [RFC4880] encoded in base64 as defined in Section 4
	of [RFC4648].		of [RFC4648].
	3. Location of the OPENPGPKEY record		3. Location of the OPENPGPKEY record
	The DNS does not allow the use of all characters that are supported		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		in the "local-part" of email addresses as defined in [RFC5322] and
	[RFC6530]. Therefore, email addresses are mapped into DNS using the		[RFC6530]. Therefore, email addresses are mapped into DNS using the
	following method:		following method:
	o The user name (the "left-hand side" of the email address, called		o The "left-hand side" of the email address, called the "local-part"
	the "local-part" in the mail message format definition [RFC5322]		in both the mail message format definition [RFC5322] and in the
	and the local-part in the specification for internationalized		specification for internationalized email [RFC6530]) is encoded in
	email [RFC6530]) is encoded in UTF-8 (or its subset ASCII). If		UTF-8 (or its subset ASCII). If the local-part is written in
	the local-part is written in another encoding it MUST be converted		another charset it MUST be converted to UTF-8.
	to UTF-8.
			o The local-part is first canonicalized using the following rules.
			If the local-part is unquoted, any whitespace (CFWS) around dots
			(".") is removed. Any enclosing double quotes are removed. Any
			literal quoting is removed.
			o If the local-part contains any non-ASCII characters, it SHOULD be
			normalized using the Unicode Normalization Form C from
			[Unicode52]. Recommended normalization rules can be found in
			Section 10.1 of [RFC6530].
	o The local-part is hashed using the SHA2-256 [RFC5754] algorithm,		o The local-part is hashed using the SHA2-256 [RFC5754] algorithm,
	with the hash truncated to 28 octets and represented in its		with the hash truncated to 28 octets and represented in its
	hexadecimal representation, to become the left-most label in the		hexadecimal representation, to become the left-most label in the
	prepared domain name.		prepared domain name.
	o The string "_openpgpkey" becomes the second left-most label in the		o The string "_openpgpkey" becomes the second left-most label in the
	prepared domain name.		prepared domain name.
	o The domain name (the "right-hand side" of the email address,		o The domain name (the "right-hand side" of the email address,
	skipping to change at page 12, line 25 ¶		skipping to change at page 12, line 34 ¶
	The hashing of the local-part in this document is not a security		The hashing of the local-part 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
	DNAME [RFC6672]. This does makes it slightly easier and cheaper to		DNAME [RFC6672]. This does makes it slightly easier and cheaper to
	brute-force the SHA2-256 hashes into common and short user names, as		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		single rainbow tables can be re-used across domains. This can be
	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 local-
	names (in rainbow tables) to deduce valid email addresses. DNSSEC-		parts (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.5. Storage of OPENPGPKEY data		7.5. 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
	skipping to change at page 17, line 44 ¶		skipping to change at page 18, line 10 ¶
	[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, DOI 10.17487/RFC6698, August		Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
	2012, <http://www.rfc-editor.org/info/rfc6698>.		2012, <http://www.rfc-editor.org/info/rfc6698>.
	[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running		[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
	Code: The Implementation Status Section", RFC 6982, DOI		Code: The Implementation Status Section", RFC 6982, DOI
	10.17487/RFC6982, July 2013,		10.17487/RFC6982, July 2013,
	<http://www.rfc-editor.org/info/rfc6982>.		<http://www.rfc-editor.org/info/rfc6982>.
			[Unicode52]
			The Unicode Consortium, "The Unicode Standard, Version
			5.2.0, defined by: "The Unicode Standard, Version 5.2.0",
			(Mountain View, CA: The Unicode Consortium, 2009. ISBN
			978-1-936213-00-9).", October 2009.
	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
	The --armor or -a option of the gpg command should NOT be used, as it		The --armor or -a option of the gpg command should NOT be used, as it
End of changes. 11 change blocks.
	18 lines changed or deleted		33 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/