< draft-ietf-dane-openpgpkey-01.txt		draft-ietf-dane-openpgpkey-02.txt >
	Network Working Group P. Wouters, Ed.		Network Working Group P. Wouters
	Internet-Draft Red Hat		Internet-Draft Red Hat
	Intended status: Standards Track October 27, 2014		Intended status: Standards Track March 09, 2015
	Expires: April 30, 2015		Expires: September 10, 2015
	Using DANE to Associate OpenPGP public keys with email addresses		Using DANE to Associate OpenPGP public keys with email addresses
	draft-ietf-dane-openpgpkey-01		draft-ietf-dane-openpgpkey-02
	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 standarized lookup mechanism to obtain OpenPGP public keys.		lacks a standardized lookup mechanism to obtain OpenPGP public keys.
	This document specifies a standarized method for securely publishing		This document specifies a method for securely publishing and locating
	and locating OpenPGP public keys in DNS using a new OPENPGPKEY DNS		OpenPGP public keys in DNS using a new OPENPGPKEY DNS Resource
	Resource Record.		Record.
	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 April 30, 2015.		This Internet-Draft will expire on September 10, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. The OPENPGPKEY Resource Record . . . . . . . . . . . . . . . 3		2. The OPENPGPKEY Resource Record . . . . . . . . . . . . . . . 3
	2.1. The OPENPGPKEY RDATA component . . . . . . . . . . . . . 3		2.1. The OPENPGPKEY RDATA component . . . . . . . . . . . . . 3
	2.2. The OPENPGPKEY RDATA wire format . . . . . . . . . . . . 3		2.2. The OPENPGPKEY RDATA wire format . . . . . . . . . . . . 3
	2.3. The OPENPGPKEY RDATA presentation format . . . . . . . . 3		2.3. The OPENPGPKEY RDATA presentation format . . . . . . . . 4
	3. Location of the OpenPGPKEY record . . . . . . . . . . . . . . 4		3. Location of the OPENPGPKEY record . . . . . . . . . . . . . . 4
	4. OpenPGP Key size and DNS . . . . . . . . . . . . . . . . . . 4		3.1. Email address variants . . . . . . . . . . . . . . . . . 4
			4. OpenPGP Key size and DNS . . . . . . . . . . . . . . . . . . 5
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 5		5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	5.1. Email address information leak . . . . . . . . . . . . . 5		5.1. Response size . . . . . . . . . . . . . . . . . . . . . . 5
	5.2. Forward security of OpenPGP versus DNSSEC . . . . . . . . 5		5.2. Email address information leak . . . . . . . . . . . . . 5
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5.3. Forward security of OpenPGP versus DNSSEC . . . . . . . . 6
	6.1. OPENPGPKEY RRtype . . . . . . . . . . . . . . . . . . . . 6		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		6.1. OPENPGPKEY RRtype . . . . . . . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	8.1. Normative References . . . . . . . . . . . . . . . . . . 6		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
			8.1. Normative References . . . . . . . . . . . . . . . . . . 7
	8.2. Informative References . . . . . . . . . . . . . . . . . 7		8.2. Informative References . . . . . . . . . . . . . . . . . 7
	Appendix A. Generating OPENPGPKEY records . . . . . . . . . . . 7		Appendix A. Generating OPENPGPKEY records . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	To encrypt a message to a target recipient using OpenPGP [RFC4880],		To encrypt a message to a target recipient using OpenPGP [RFC4880],
	possession of the recipient's OpenPGP public key is required. To		possession of the recipient's OpenPGP public key is required. To
	obtain that public key, two problems need to be solved by the		obtain that public key, the sender's email client or MTA needs to
	sender's email client, MUA or MTA. Where does one find the		know where to find the recipient's public key. Once obtained, it
	recipient's public key and how does one trust that the found key		needs to find some proof that the public key found actually belongs
	actually belongs to the intended recipient.		to the intended recipient.
	Obtaining a public key is not a straightforward process as there are		Obtaining a public key is not a straightforward process as there are
	no trusted standarized locations for publishing OpenPGP public keys		no trusted standardized locations for publishing OpenPGP public keys
	indexed by email address. Instead, OpenPGP clients rely on "well-		indexed by email address. Instead, OpenPGP clients rely on "well-
	known key servers" that are accessed using the web based HKP protocol		known key servers" that are accessed using the HTTP Keyserver
	or manually by users using a variety of differently formatted front-		Protocol ("HKP") or manually by users using a variety of differently
	end web pages.		formatted front-end web pages.
	Currently deployed key servers have no method of validating any		Currently deployed key servers have no method of validating any
	uploaded OpenPGP public key. The key servers simply store and		uploaded OpenPGP public key. The key servers simply store and
	publish. Anyone can add public keys with any identities and anyone		publish. Anyone can add public keys with any identities and anyone
	can add signatures to any other public key using forged malicious		can add signatures to any other public key using forged malicious
	identities. Furthermore, once uploaded, public keys cannot be		identities. Furthermore, once uploaded, public keys cannot be
	deleted. People who did not pre-sign a key revocation can never		deleted. People who did not pre-sign a key revocation can never
	remove their public key from these key servers once they lost their		remove their public key from these key servers once they lose their
	private key.		private key.
	The lack of association of email address and public key lookup is		The lack of a secure means to look up a public key for an email
	also preventing email clients, MTAs and MUAs from encrypting a		address also prevents email clients and MUAs from encrypting a
	received message to the target receipient forcing the software to		received email to the target recipient, forcing the software to send
	send the message unencryped. Currently deployed MTA's only support		the message unencrypted. Currently deployed MTAs only support
	encrypting the transport of the email, not the email contents itself.		encrypting the transport of the email, not the email contents itself.
	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 a new DNS RRtype.		public key with their email address, using a new DNS RRtype.
	The proposed new DNS Resource Record type is secured using DNSSEC.		The proposed new DNS Resource Record type is secured using DNSSEC.
	This trust model is not meant to replace the "web of trust" model.		This trust model is not meant to replace the Trust Signature model.
	However, it can be used to encrypt a message that would otherwise		However, it can be used to encrypt a message that would otherwise
	have to be sent out unencrypted, where it could be monitored by a		have to be sent out unencrypted, where it could be monitored by a
	third party in transit or located in plaintext on a storage or email		third party in transit or located in plaintext on a storage or email
	server.		server.
	1.1. Terminology		1.1. 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].
	skipping to change at page 3, line 48 ¶		skipping to change at page 3, line 48 ¶
	OPENPGPKEY RR is class independent. The OPENPGPKEY RR has no special		OPENPGPKEY RR is class independent. The OPENPGPKEY RR has no special
	TTL requirements.		TTL requirements.
	2.1. The OPENPGPKEY RDATA component		2.1. The OPENPGPKEY RDATA component
	The RDATA (or RHS) of an OPENPGPKEY Resource Record contains a single		The RDATA (or RHS) of an OPENPGPKEY Resource Record contains a single
	value consisting of a [RFC4880] formatted OpenPGP public keyring.		value consisting of a [RFC4880] formatted OpenPGP public keyring.
	2.2. The OPENPGPKEY RDATA wire format		2.2. The OPENPGPKEY RDATA wire format
	The RDATA Wire Format is the binary OpenPGP public keyring as		The RDATA Wire Format consists of a single OpenPGP public key as
	specified in [RFC4880] without any ascii armor or base64 encoding.		defined in Section 5.5.1.1 of [RFC4880]. Note that this 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,
	consists of the [RFC4880] formatted OpenPGP public keyring encoded in
	Base64 [RFC4648]
	3. Location of the OpenPGPKEY record		The RDATA Presentation Format, as visible in textual zone files,
			consists of a single OpenPGP public key as defined in
			Section 5.5.1.1. of [RFC4880] encoded in Base64 [RFC4648]
	Email addresses are mapped into DNS using the following method:		3. Location of the OPENPGPKEY record
	1. The user name (the "left-hand side" of the email address, called		The DNS does not allow the use of all characters that are supported
	the "local-part" in the mail message format definition [RFC2822]		in the "local-part" of email addresses as defined in [RFC2822] and
	and the "local part" in the specification for internationalized		[RFC6530]. Therefore, email addresses are mapped into DNS using the
	email [RFC6530]), is hashed using the SHA2-224 [RFC5754]		following method:
	algorithm to become the left-most label in the prepared domain
	name. This does not include the at symbol ("@") that separates
	the left and right sides of the email address.
	2. The DNS does not allow the use of all characters that are		o The user name (the "left-hand side" of the email address, called
	supported in "local-part" of email addresses as defined in		the "local-part" in the mail message format definition [RFC2822]
	[RFC2822] and [RFC6530] . The SHA2-224 hashing of the user name		and the "local part" in the specification for internationalized
	ensures that none of these characters would need to be placed		email [RFC6530]), is hashed using the SHA2-224 [RFC5754]
	directly in the DNS.		algorithm, with the hash being represented in its hexadecimal
			representation, to become the left-most label in the prepared
			domain name. This does not include the at symbol ("@") that
			separates the left and right sides of the email address.
	3. The string "_openpgpkey" becomes the second left-most label in		o The string "_openpgpkey" becomes the second left-most label in the
	the prepared domain name.		prepared domain name.
	4. 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		called the "domain" in RFC 2822) is appended to the result of step
	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: "8d5730bd8d76d417bf974c03f59eedb7a		be placed for the following QNAME: "8d5730bd8d76d417bf974c03f59eedb7a
	f98cb5c3dc73ea8ebbd54b7._openpgpkey.example.com" The corresponding RR		f98cb5c3dc73ea8ebbd54b7._openpgpkey.example.com". The corresponding
	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):
	8d[..]b7._openpgpkey.example.com. IN OPENPGPKEY <base64 public key>		8d[..]b7._openpgpkey.example.com. IN OPENPGPKEY <base64 public key>
			3.1. Email address variants
			Some email service providers and email software perform automatic
			mappings of email addresses based on special characters. This can
			complicate finding the OPENPGPKEY record associated with the
			dynamically created email address. Some well known examples are
			listed below
			o The LHS is case insensitive, Hugh@example.com and HUGH@example.com
			map to hugh@example.com. Some email clients also automatically
			uppercase the first letter of an email address when typing it in.
			o Everything after a "+" symbol is dynamc. hugh+string@example.com
			maps to hugh@example.com.
			o Dots are optional. hugh.daniel@example.com maps to
			hughdaniel@example.com.
			Software implementing DNS lookup for the OPENPGPKEY RRtype MAY
			perform similar translations rules while trying to find the
			OPENPGPKEY record.
	4. OpenPGP Key size and DNS		4. OpenPGP Key size and DNS
	Although the reliability of the transport of large DNS Resoruce		Due to the expected size of the OPENPGPKEY record, it is recommended
			to perform DNS queries for the OPENPGPKEY record using TCP, not UDP.
			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 accomodate 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.
	5. Security Considerations		5. Security Considerations
	OPENPGPKEY usage considerations are published in [OPENPGPKEY-USAGE]		OPENPGPKEY usage considerations are published in [OPENPGPKEY-USAGE].
	5.1. Email address information leak		5.1. Response size
	Email addresses are not secret. Using them causes its publication.		To prevent amplification attacks, an Authoritative DNS server MAY
			wish to prevent returning OPENPGPKEY records over UDP unless the
			source IP address has been verified with [DNS-COOKIES]. Such servers
			MUST NOT return REFUSED, but answer the query with an empty Answer
			Section and the truncation flag set ("TC=1).
			5.2. Email address information leak
			Email addresses are not secret. Using them causes their publication.
	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
	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-224 hashes into common and short user names, as		brute-force the SHA2-224 hashes into common and short user names, as
	single rainbow tables can be re-used accross 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 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.
	5.2. Forward security of OpenPGP versus DNSSEC		5.3. Forward security of OpenPGP versus DNSSEC
	DNSSEC key sizes are chosen based on the fact that these keys can be		DNSSEC key sizes are chosen based on the fact that these keys can be
	rolled with next to no requirement for security in the future. If		rolled with next to no requirement for security in the future. If
	one doubts the strength or security of the DNSSEC key for whatever		one doubts the strength or security of the DNSSEC key for whatever
	reason, one simply rolls to a new DNSSEC key with a stronger		reason, one simply rolls to a new DNSSEC key with a stronger
	algorithm or larger key size. On the other hand, OpenPGP key sizes		algorithm or larger key size. On the other hand, OpenPGP key sizes
	are chosen based on how many years (or decades) their encryption		are chosen based on how many years (or decades) their encryption
	should remain unbreakable by adversaries that own large scale		should remain unbreakable by adversaries that own large scale
	computational resources.		computational resources.
	This effectively means that anyone who can obtain a DNSSEC private		This effectively means that anyone who can obtain a DNSSEC private
	key of a domain name via coercion, theft or brute force calculations,		key of a domain name via coercion, theft or brute force calculations,
	can replace any OPENPGPKEY record in that zone and all of the		can replace any OPENPGPKEY record in that zone and all of the
	delegated child zones, irrespective of the key size of the OpenPGP		delegated child zones, irrespective of the key size of the OpenPGP
	keypair. Any future messages encrypted with the malicious OpenPGP		keypair. Any future messages encrypted with the malicious OpenPGP
	key could then be read.		key could then be read.
	Therefor, 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 are 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 of the "Web of Trust". See
	[OPENPGPKEY-USAGE] for more in-depth information on safe usage of		[OPENPGPKEY-USAGE] for more in-depth information on safe usage of
	OPENPGPKEY based OpenPGP keys.		OPENPGPKEY based OpenPGP keys.
	6. IANA Considerations		6. IANA Considerations
	6.1. OPENPGPKEY RRtype		6.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.
	7. Acknowledgements		7. Acknowledgements
	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. Edwin
			Taylor contributed language improvements for various iterations of
			this document.
	8. References		8. References
	8.1. Normative References		8.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, March 1997.
	[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
	skipping to change at page 7, line 16 ¶		skipping to change at page 7, line 52 ¶
	Encodings", RFC 4648, October 2006.		Encodings", RFC 4648, October 2006.
	[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, November 2007.		Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
	[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic		[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
	Message Syntax", RFC 5754, January 2010.		Message Syntax", RFC 5754, January 2010.
	8.2. Informative References		8.2. Informative References
			[DNS-COOKIES]
			Eastlake, Donald., "Domain Name System (DNS) Cookies",
			draft-ietf-dnsop-cookies (work in progress), February
			2015.
	[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-dane-openpgpkey-usage (work in progress),
	October 2014.		October 2014.
	[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS		[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
	Specification", RFC 2181, July 1997.		Specification", RFC 2181, July 1997.
	[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April		[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
	2001.		2001.
	skipping to change at page 8, line 20 ¶		skipping to change at page 9, line 15 ¶
	gpg --export --export-options export-minimal \		gpg --export --export-options export-minimal \
	hugh@example.com | wc -c		hugh@example.com | wc -c
	gpg --export --export-options export-minimal \		gpg --export --export-options export-minimal \
	hugh@example.com | hexdump -e \		hugh@example.com | hexdump -e \
	'"\t" /1 "%.2x"' -e '/32 "\n"'		'"\t" /1 "%.2x"' -e '/32 "\n"'
	These values can then be used to generate a generic record (line		These values can then be used to generate a generic record (line
	break has been added for formatting):		break has been added for formatting):
	<SHA2-224(hugh)>._openpgpkey.example.com. IN TYPE65280 \# \		<SHA2-224(hugh)>._openpgpkey.example.com. IN TYPE61 \# \
	<numOctets> <keydata in hex>		<numOctets> <keydata in hex>
	The openpgpkey command in the hash-slinger software can be used to		The openpgpkey command in the hash-slinger software can be used to
	generate complete OPENPGPKEY records		generate complete OPENPGPKEY records
	~> openpgpkey --output rfc hugh@example.com		~> openpgpkey --output rfc hugh@example.com
	8d[...]b7._openpgpkey.example.com. IN OPENPGPKEY mQCNAzIG[...]		8d[...]b7._openpgpkey.example.com. IN OPENPGPKEY mQCNAzIG[...]
	~> openpgpkey --output generic hugh@example.com		~> openpgpkey --output generic hugh@example.com
	8d[...]b7._openpgpkey.example.com. IN TYPE65280 \# 2313 99008d03[...]		8d[...]b7._openpgpkey.example.com. IN TYPE61 \# 2313 99008d03[...]
	Author's Address		Author's Address
	Paul Wouters (editor)		Paul Wouters
	Red Hat		Red Hat
	Email: pwouters@redhat.com		Email: pwouters@redhat.com
End of changes. 39 change blocks.
	76 lines changed or deleted		116 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/