< draft-ietf-dnsext-signing-auth-01.txt		draft-ietf-dnsext-signing-auth-02.txt >
			DNSEXT Working Group Brian Wellington (Nominum)
			INTERNET-DRAFT October 2000
	DNSIND Working Group Brian Wellington (Nominum)		<draft-ietf-dnsext-signing-auth-02.txt>
	INTERNET-DRAFT May 2000
	<draft-ietf-dnsext-signing-auth-01.txt>
	Updates: RFC 2535		Updates: RFC 2535
	Domain Name System Security (DNSSEC) Signing Authority		Domain Name System Security (DNSSEC) Signing Authority
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 32 ¶
	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.''
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	Comments should be sent to the authors or the DNSIND WG mailing list		Comments should be sent to the authors or the DNSEXT WG mailing list
	namedroppers@internic.net.		namedroppers@ops.ietf.org.
	This draft expires on November 12, 2000.		This draft expires on April 2, 2000.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2000). All rights reserved.		Copyright (C) The Internet Society (2000). All rights reserved.
	Abstract		Abstract
	This document proposes a revised model of Domain Name System Security		This document proposes a revised model of Domain Name System Security
	(DNSSEC) Signing Authority. The revised model is designed to clarify		(DNSSEC) Signing Authority. The revised model is designed to clarify
	earlier documents and add additional restrictions to simplify the		earlier documents and add additional restrictions to simplify the
	secure resolution process. Specifically, this affects the		secure resolution process. Specifically, this affects the
	authorization of keys to sign sets of records.		authorization of keys to sign sets of records.
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC 2119 [RFC2119].
	1 - Introduction		1 - Introduction
	This document defines additional restrictions on DNSSEC signatures (SIG)		This document defines additional restrictions on DNSSEC signatures (SIG)
	records relating to their authority to sign associated data. The intent		records relating to their authority to sign associated data. The intent
	is to establish a standard policy followed by a secure resolver; this		is to establish a standard policy followed by a secure resolver; this
	policy can be augmented by local rules. This builds upon [RFC2535],		policy can be augmented by local rules. This builds upon [RFC2535],
	updating section 2.3.6 of that document.		updating section 2.3.6 of that document.
	The most significant change is that in a secure zone, zone data is		The most significant change is that in a secure zone, zone data is
	required to be signed by the zone key.		required to be signed by the zone key.
	skipping to change at page 2, line 39 ¶		skipping to change at page 2, line 43 ¶
	``immaterial'' or ``extra-DNSSEC'', as they are not relevant to DNSSEC		``immaterial'' or ``extra-DNSSEC'', as they are not relevant to DNSSEC
	validation. Immaterial SIGs may have application defined roles. SIG		validation. Immaterial SIGs may have application defined roles. SIG
	records may exist which are not bound to any RRset; these are also		records may exist which are not bound to any RRset; these are also
	considered immaterial. The validation process determines which SIGs are		considered immaterial. The validation process determines which SIGs are
	material; once a SIG is shown to be immaterial, no other validation is		material; once a SIG is shown to be immaterial, no other validation is
	necessary.		necessary.
	SIGs may also be used for transaction security. In this case, a SIG		SIGs may also be used for transaction security. In this case, a SIG
	record with a type covered field of 0 is attached to a message, and is		record with a type covered field of 0 is attached to a message, and is
	used to protect message integrity. This is referred to as a SIG(0)		used to protect message integrity. This is referred to as a SIG(0)
	[RFC2535].		[RFC2535, RFC2931].
	The following sections define requirements for all of the fields of a		The following sections define requirements for all of the fields of a
	SIG record. These requirements MUST be met in order for a DNSSEC		SIG record. These requirements MUST be met in order for a DNSSEC
	capable resolver to process this signature. If any of these		capable resolver to process this signature. If any of these
	requirements are not met, the SIG cannot be further processed.		requirements are not met, the SIG cannot be further processed.
	Additionally, once a KEY has been identified as having generated this		Additionally, once a KEY has been identified as having generated this
	SIG, there are requirements that it MUST meet.		SIG, there are requirements that it MUST meet.
	2.1 - Type Covered		2.1 - Type Covered
	skipping to change at page 3, line 41 ¶		skipping to change at page 3, line 41 ¶
	2.6 - Key Tag		2.6 - Key Tag
	There are no restrictions on the Key Tag field, although it is possible		There are no restrictions on the Key Tag field, although it is possible
	that future algorithms will impose contraints.		that future algorithms will impose contraints.
	2.7 - Signer's Name		2.7 - Signer's Name
	The signer's name field of a data SIG MUST contain the name of the zone		The signer's name field of a data SIG MUST contain the name of the zone
	to which the data and signature belong. The combination of signer's		to which the data and signature belong. The combination of signer's
	name, key tag, and algorithm MUST identify a zone key if the SIG is to		name, key tag, and algorithm MUST identify a zone key if the SIG is to
	be considered material. This document defines a standard policy for		be considered material. The only exception that the signer's name field
	DNSSEC validation; local policy may override the standard policy.		in a SIG KEY at a zone apex SHOULD contain the parent zone's name,
			unless the KEY set is self-signed. This document defines a standard
			policy for DNSSEC validation; local policy may override the standard
			policy.
	There are no restrictions on the signer field of a SIG(0) record. The		There are no restrictions on the signer field of a SIG(0) record. The
	combination of signer's name, key tag, and algorithm MUST identify a key		combination of signer's name, key tag, and algorithm MUST identify a key
	if this SIG(0) is to be processed.		if this SIG(0) is to be processed.
	2.8 - Signature		2.8 - Signature
	There are no restrictions on the signature field. The signature will be		There are no restrictions on the signature field. The signature will be
	verified at some point, but does not need to be examined prior to		verified at some point, but does not need to be examined prior to
	verification unless a future algorithm imposes constraints.		verification unless a future algorithm imposes constraints.
	skipping to change at page 5, line 4 ¶		skipping to change at page 5, line 9 ¶
	ignore all keys that are not zone keys unless local policy dictates		ignore all keys that are not zone keys unless local policy dictates
	otherwise.		otherwise.
	The primary reason that RFC 2535 allows host and user keys to generate		The primary reason that RFC 2535 allows host and user keys to generate
	material DNSSEC signatures is to allow dynamic update without online		material DNSSEC signatures is to allow dynamic update without online
	zone keys; that is, avoid storing private keys in an online server. The		zone keys; that is, avoid storing private keys in an online server. The
	desire to avoid online signing keys cannot be achieved, though, because		desire to avoid online signing keys cannot be achieved, though, because
	they are necessary to sign NXT and SOA sets [SSU]. These online zone		they are necessary to sign NXT and SOA sets [SSU]. These online zone
	keys can sign any incoming data. Removing the goal of having no online		keys can sign any incoming data. Removing the goal of having no online
	keys removes the reason to allow host and user keys to generate material		keys removes the reason to allow host and user keys to generate material
	signatures. in the DNS.		signatures.
	Limiting material signatures to zone keys simplifies the validation		Limiting material signatures to zone keys simplifies the validation
	process. The length of the verification chain is bounded by the name's		process. The length of the verification chain is bounded by the name's
	label depth. The authority of a key is clearly defined; a resolver does		label depth. The authority of a key is clearly defined; a resolver does
	not need to make a potentially complicated decision to determine whether		not need to make a potentially complicated decision to determine whether
	a key can sign data. amount of work to determine if all such keys have		a key can sign data. amount of work to determine if all such keys have
	the proper authority.		the proper authority.
	Finally, there is no additional flexibility granted by allowing		Finally, there is no additional flexibility granted by allowing
	host/user key generated material signatures. As long as users and hosts		host/user key generated material signatures. As long as users and hosts
	skipping to change at page 6, line 32 ¶		skipping to change at page 6, line 38 ¶
	Ed Lewis		Ed Lewis
	6 - References		6 - References
	[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,''		[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,''
	RFC 1034, ISI, November 1987.		RFC 1034, ISI, November 1987.
	[RFC1035] P. Mockapetris, ``Domain Names - Implementation and		[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
	Specification,'' RFC 1035, ISI, November 1987.		Specification,'' RFC 1035, ISI, November 1987.
			[RFC2119] S. Bradner, ``Key words for use in RFCs to Indicate
			Requirement Levels,'' BCP 14, RFC 2119, Harvard, March 1997.
	[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic		[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
	Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore		Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore
	& Cisco & DEC, April 1997.		& Cisco & DEC, April 1997.
	[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC		[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC
	2065, IBM, March 1999.		2535, IBM, March 1999.
			[RFC2931] D. Eastlake, ``DNS Request and Transaction Signatures (
			SIG(0)s ),'' RFC 2931, Motorola, September 2000.
	[SSU] B. Wellington, ``Simple Secure Domain Name System (DNS)		[SSU] B. Wellington, ``Simple Secure Domain Name System (DNS)
	Dynamic Update,'' draft-ietf-dnsext-simple-secure-		Dynamic Update,'' draft-ietf-dnsext-simple-secure-
	update-01.txt, Nominum, May 2000.		update-02.txt, Nominum, October 2000.
	7 - Author's Address		7 - Author's Address
	Brian Wellington		Brian Wellington
	Nominum, Inc.		Nominum, Inc.
	950 Charter Street		950 Charter Street
	Redwood City, CA 94063		Redwood City, CA 94063
	+1 650 779 6022		+1 650 779 6022
	<Brian.Wellington@nominum.com>		<Brian.Wellington@nominum.com>
End of changes. 11 change blocks.
	13 lines changed or deleted		25 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/