< draft-ietf-dane-openpgpkey-04.txt		draft-ietf-dane-openpgpkey-05.txt >
	Network Working Group P. Wouters		Network Working Group P. Wouters
	Internet-Draft Red Hat		Internet-Draft Red Hat
	Intended status: Experimental August 27, 2015		Intended status: Experimental August 28, 2015
	Expires: February 28, 2016		Expires: February 29, 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-04		draft-ietf-dane-openpgpkey-05
	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.		DNSSEC.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 28, 2016.		This Internet-Draft will expire on February 29, 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
	skipping to change at page 2, line 43 ¶		skipping to change at page 2, line 43 ¶
	7.1. Response size . . . . . . . . . . . . . . . . . . . . . . 8		7.1. Response size . . . . . . . . . . . . . . . . . . . . . . 8
	7.2. Email address information leak . . . . . . . . . . . . . 8		7.2. Email address information leak . . . . . . . . . . . . . 8
	7.3. Storage of OPENPGPKEY data . . . . . . . . . . . . . . . 9		7.3. Storage of OPENPGPKEY data . . . . . . . . . . . . . . . 9
	7.4. Forward security of OpenPGP versus DNSSEC . . . . . . . . 9		7.4. Forward security of OpenPGP versus DNSSEC . . . . . . . . 9
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8.1. OPENPGPKEY RRtype . . . . . . . . . . . . . . . . . . . . 10		8.1. OPENPGPKEY RRtype . . . . . . . . . . . . . . . . . . . . 10
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10.1. Normative References . . . . . . . . . . . . . . . . . . 10		10.1. Normative References . . . . . . . . . . . . . . . . . . 10
	10.2. Informative References . . . . . . . . . . . . . . . . . 11		10.2. Informative References . . . . . . . . . . . . . . . . . 11
	Appendix A. Generating OPENPGPKEY records . . . . . . . . . . . 12		Appendix A. Generating OPENPGPKEY records . . . . . . . . . . . 11
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
	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 5, line 16 ¶		skipping to change at page 5, line 16 ¶
	When preparing a Transferable Public Key for a specific OPENPGPKEY		When preparing a Transferable Public Key for a specific OPENPGPKEY
	RDATA format with the goal of minimizing certificate size, a user		RDATA format with the goal of minimizing certificate size, a user
	would typically want to:		would typically want to:
	o Where one User ID from the certifications matches the looked-up		o Where one User ID from the certifications matches the looked-up
	address, strip away non-matching User IDs and any associated		address, strip away non-matching User IDs and any associated
	certifications (self-signatures or third-party certifications)		certifications (self-signatures or third-party certifications)
	o Strip away all User Attribute packets and associated		o Strip away all User Attribute packets and associated
	certifications Strip away all expired subkeys. The user may want		certifications.
	to keep revoked subkeys if these were revoked prior to their
	preferred expiration time to ensure that correspondents know about
	these earlier then expected revocations.
	o strip away all but the most recent self-sig for the remaining user		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 then
			expected revocations.
			o Strip away all but the most recent self-sig for the remaining user
	IDs and subkeys		IDs and subkeys
	o Optionally strip away any uninteresting or unimportant third-party		o Optionally strip away any uninteresting or unimportant third-party
	User ID certifications. This is a value judgment by the user that		User ID certifications. This is a value judgment by the user that
	is difficult to automate. At the very least, expired and		is difficult to automate. At the very least, expired and
	superseded third-party certifcations should be stripped out. The		superseded third-party certifcations should be stripped out. The
	user should attempt to keep the most recent and most well		user should attempt to keep the most recent and most well
	connected certifications in the Web Of Trust in their Transferable		connected certifications in the Web Of Trust in their Transferable
	Public Key.		Public Key.
	2.2. The OPENPGPKEY RDATA wire format		2.2. The OPENPGPKEY RDATA wire format
	The RDATA Wire Format consists of a single OpenPGP Transferable		The RDATA Wire Format consists of a single OpenPGP Transferable
	Public Key as defined in Section 11.1 of [RFC4880]. Note that this		Public Key as defined in Section 11.1 of [RFC4880]. Note that this
	format is without ASCII armor or base64 encoding.		format is without ASCII armor or base64 encoding.
	2.3. The OPENPGPKEY RDATA presentation format		2.3. The OPENPGPKEY RDATA presentation format
	The RDATA Presentation Format, as visible in textual zone files,		The RDATA Presentation Format, as visible in textual zone files,
	consists of a single OpenPGP Transferable Public Key as defined in		consists of a single OpenPGP Transferable Public Key as defined in
	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 [RFC2822] 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 user name (the "left-hand side" of the email address, called
	the "local-part" in the mail message format definition [RFC2822]		the "local-part" in the mail message format definition [RFC5322]
	and the local-part in the specification for internationalized		and the local-part in the specification for internationalized
	email [RFC6530]) should already be encoded in UTF-8 (or its subset		email [RFC6530]) should already be encoded in UTF-8 (or its subset
	ASCII). If it is written in another encoding it should be		ASCII). If it is written in another encoding it should be
	converted to UTF-8 and then hashed using the SHA2-256 [RFC5754]		converted to UTF-8 and then hashed using the SHA2-256 [RFC5754]
	algorithm, with the hash truncated to 28 octets and represented in		algorithm, with the hash truncated to 28 octets and represented in
	its hexadecimal representation, to become the left-most label in		its hexadecimal representation, to become the left-most label in
	the prepared domain name. Truncation comes from the right-most		the prepared domain name. Truncation comes from the right-most
	octets. This does not include the at symbol ("@") that separates		octets. This does not include the at symbol ("@") that separates
	the left and right sides of the email address.		the left and right sides of the email address.
	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,
	called the "domain" in RFC 2822) is appended to the result of step		called the "domain" in RFC 5322) is appended to the result of step
	2 to complete the prepared domain name.		2 to complete the prepared domain name.
	For example, to request an OPENPGPKEY resource record for a user		For example, to request an OPENPGPKEY resource record for a user
	whose email address is "hugh@example.com", an OPENPGPKEY query would		whose email address is "hugh@example.com", an OPENPGPKEY query would
	be placed for the following QNAME: "c93f1e400f26708f98cb19d936620da35		be placed for the following QNAME: "c93f1e400f26708f98cb19d936620da35
	eec8f72e57f9eec01c1afd6._openpgpkey.example.com". The corresponding		eec8f72e57f9eec01c1afd6._openpgpkey.example.com". The corresponding
	RR in the example.com zone might look like (key shortened for		RR in the example.com zone might look like (key shortened for
	formatting):		formatting):
	c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY <base64 public key>		c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY <base64 public key>
	skipping to change at page 11, line 20 ¶		skipping to change at page 11, line 20 ¶
	[DNS-COOKIES]		[DNS-COOKIES]
	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]		[OPENPGPKEY-USAGE]
	Wouters, P., "Usage considerations with the DNS OPENPGPKEY		Wouters, P., "Usage considerations with the DNS OPENPGPKEY
	record", draft-dane-openpgpkey-usage (work in progress),		record", draft-ietf-dane-openpgpkey-usage (work in
	October 2014.		progress), October 2014.
	[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>.
	[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, DOI
	10.17487/RFC2822, April 2001,
	<http://www.rfc-editor.org/info/rfc2822>.
	[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>.
	[RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress
	Extension", RFC 5233, DOI 10.17487/RFC5233, January 2008,
	<http://www.rfc-editor.org/info/rfc5233>.
	[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
			10.17487/RFC5322, October 2008,
			<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, August 2012.
	[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
	Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
	February 2014, <http://www.rfc-editor.org/info/rfc7129>.
	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. 14 change blocks.
	33 lines changed or deleted		23 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/