< draft-ietf-dnsop-delegation-trust-maintainance-08.txt		draft-ietf-dnsop-delegation-trust-maintainance-09.txt >
	dnsop W. Kumari		dnsop W. Kumari
	Internet-Draft Google		Internet-Draft Google
	Intended status: Informational O. Gudmundsson		Intended status: Informational O. Gudmundsson
	Expires: October 17, 2014 Shinkuro Inc.		Expires: October 18, 2014 Shinkuro Inc.
	G. Barwood		G. Barwood
	April 15, 2014		April 16, 2014
	Automating DNSSEC Delegation Trust Maintenance		Automating DNSSEC Delegation Trust Maintenance
	draft-ietf-dnsop-delegation-trust-maintainance-08		draft-ietf-dnsop-delegation-trust-maintainance-09
	Abstract		Abstract
	This document describes a method to allow DNS operators to more		This document describes a method to allow DNS operators to more
	easily update DNSSEC Key Signing Keys using the DNS as communication		easily update DNSSEC Key Signing Keys using the DNS as communication
	channel. This document does not address the initial configuration of		channel. This document does not address the initial configuration of
	trust anchors for a domain. The technique described is aimed at		trust anchors for a domain. The technique described is aimed at
	delegations in which it is currently hard to move information from		delegations in which it is currently hard to move information from
	the child to parent.		the child to parent.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 17, 2014.		This Internet-Draft will expire on October 18, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 40 ¶		skipping to change at page 2, line 40 ¶
	6.2.1. Parent Calculates DS . . . . . . . . . . . . . . . . 11		6.2.1. Parent Calculates DS . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 12		9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	11.1. Normative References . . . . . . . . . . . . . . . . . . 14		11.1. Normative References . . . . . . . . . . . . . . . . . . 14
	11.2. Informative References . . . . . . . . . . . . . . . . . 15		11.2. Informative References . . . . . . . . . . . . . . . . . 15
	Appendix A. RRR background . . . . . . . . . . . . . . . . . . . 15		Appendix A. RRR background . . . . . . . . . . . . . . . . . . . 15
	Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 16		Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	When a DNS operator first signs their zone, they need to communicate		The first time a DNS operator signs a zone, they need to communicate
	their DS record(s) (or DNSKEY(s)) to their parent through some out-		the keying material to their parent through some out-of-band method
	of-band method to complete the chain of trust.		to complete the chain of trust. Depending on the desires of the
			parent, the child might send their DNSKEY record, a DS record, or
			both.
	Each time the child changes the key that is represented in the		Each time the child changes the key that is represented in the
	parent, the updated and/or deleted key information has to be		parent, the updated and/or deleted key information has to be
	communicated to the parent and published in the parent's zone. How		communicated to the parent and published in the parent's zone. How
	this information is sent to the parent depends on the relationship		this information is sent to the parent depends on the relationship
	the child has with the parent. In many cases this is a manual		the child has with the parent. In many cases this is a manual
	process, and not an easy one. For each key change, there may be up		process, and not an easy one. For each key change, there may be up
	to two interactions with the parent. Any manual process is		to two interactions with the parent. Any manual process is
	susceptible to mistakes and/or errors. In addition, due to the		susceptible to mistakes and/or errors. In addition, due to the
	annoyance factor of the process, operators may avoid changing keys or		annoyance factor of the process, operators may avoid changing keys or
	skipping to change at page 16, line 19 ¶		skipping to change at page 16, line 19 ¶
	In many RRR cases the Registrar and Registry communicate via		In many RRR cases the Registrar and Registry communicate via
	EPP[RFC5730] and use the EPP DNSSEC extension [RFC5910]. In a number		EPP[RFC5730] and use the EPP DNSSEC extension [RFC5910]. In a number
	of ccTLDs there are other mechanisms in use as well as EPP, but in		of ccTLDs there are other mechanisms in use as well as EPP, but in
	general there seems to be a movement towards EPP usage when DNSSEC is		general there seems to be a movement towards EPP usage when DNSSEC is
	enabled in the TLD.		enabled in the TLD.
	Appendix B. Changes / Author Notes.		Appendix B. Changes / Author Notes.
	[RFC Editor: Please remove this section before publication ]		[RFC Editor: Please remove this section before publication ]
			WG-08 to WG-09
			o New text from Paul Hoffman for the first paragraph of the intro.
			o ... with a modification from Jaap.
	WG-07 to WG-08		WG-07 to WG-08
	o Incorporated text from Antoin Verschuren at the end of Section 6.		o Incorporated text from Antoin Verschuren at the end of Section 6.
	o Comments from Paul Hoffman and Tim W		o Comments from Paul Hoffman and Tim W
	WG-06 to WG-07		WG-06 to WG-07
	o Incorporated nits / editorial comments from Tim Wicinski.		o Incorporated nits / editorial comments from Tim Wicinski.
End of changes. 7 change blocks.
	8 lines changed or deleted		16 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/