< draft-ietf-dnsext-dnssec-records-00.txt		draft-ietf-dnsext-dnssec-records-01.txt >
	Network Working Group R. Arends
			DNS Extensions R. Arends
	Internet-Draft Nominum		Internet-Draft Nominum
	Expires: August 23, 2002 M. Larson		Expires: August 2, 2002 M. Larson
	VeriSign		VeriSign
	D. Massey		D. Massey
	USC/ISI		USC/ISI
	S. Rose		S. Rose
	NIST		NIST
	February 22, 2002		February 2002
	Resource Records for DNS Security Extensions		Resource Records for DNS Security Extensions
	draft-ietf-dnsext-dnssec-records-00		draft-ietf-dnsext-dnssec-records-01
	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.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 37 ¶
	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 http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		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.
	This Internet-Draft will expire on August 23, 2002.		This Internet-Draft will expire on August 2, 2002.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2002). All Rights Reserved.
	Abstract		Abstract
	The DNS Security Extensions (DNSSEC) introduce four resource records:		The DNS Security Extensions (DNSSEC) introduce four resource records:
	the KEY, DS, SIG, and NXT resource records. This document defines		the KEY, DS, SIG, and NXT resource records. This document defines
	the purpose and the RDATA format for each of these records. This		the purpose and the RDATA format for each of these records. This
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	2. The Key Resource Record . . . . . . . . . . . . . . . . . 5		2. The Key Resource Record . . . . . . . . . . . . . . . . . 5
	2.1 KEY RDATA Wire Format . . . . . . . . . . . . . . . . . . 5		2.1 KEY RDATA Wire Format . . . . . . . . . . . . . . . . . . 5
	2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 5		2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 5
	2.1.1.1 Explanation for Choice of Bit 7 . . . . . . . . . . . . . 6		2.1.1.1 Explanation for Choice of Bit 7 . . . . . . . . . . . . . 6
	2.1.2 The Protocol Octet Field . . . . . . . . . . . . . . . . . 6		2.1.2 The Protocol Octet Field . . . . . . . . . . . . . . . . . 6
	2.1.2.1 Explanation for a Fixed Value Protocol Octet Field . . . . 6		2.1.2.1 Explanation for a Fixed Value Protocol Octet Field . . . . 6
	2.1.3 The Algorithm and Public Key Fields . . . . . . . . . . . 6		2.1.3 The Algorithm and Public Key Fields . . . . . . . . . . . 6
	2.2 The KEY RR Presentation Format . . . . . . . . . . . . . . 7		2.2 The KEY RR Presentation Format . . . . . . . . . . . . . . 7
	2.3 KEY RR Examples . . . . . . . . . . . . . . . . . . . . . 7		2.3 KEY RR Examples . . . . . . . . . . . . . . . . . . . . . 7
	2.3.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 7		2.3.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.3.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 7		2.3.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 8
	3. The SIG Resource Record . . . . . . . . . . . . . . . . . 9		3. The SIG Resource Record . . . . . . . . . . . . . . . . . 9
	3.1 The SIG RDATA . . . . . . . . . . . . . . . . . . . . . . 9		3.1 The SIG RDATA . . . . . . . . . . . . . . . . . . . . . . 9
	3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . 10		3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . 10
	3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . 10		3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . 10
	3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . 10		3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . 10
	3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . 10		3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . 10
	3.1.5 Signature Expiration and Inception Fields . . . . . . . . 10		3.1.5 Signature Expiration and Inception Fields . . . . . . . . 10
	3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 10		3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 10
	3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . 11		3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . 11
	3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . 11		3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . 11
	3.2 The NXT RR Presentation Format (placeholder) . . . . . . . 11		3.2 The NXT RR Presentation Format (placeholder) . . . . . . . 11
	3.3 Calculating the signature . . . . . . . . . . . . . . . . 11		3.3 Calculating the signature . . . . . . . . . . . . . . . . 11
	4. The NXT Resource Record . . . . . . . . . . . . . . . . . 13		4. The NXT Resource Record . . . . . . . . . . . . . . . . . 13
	4.1 NXT RDATA Wire Format . . . . . . . . . . . . . . . . . . 13		4.1 NXT RDATA Wire Format . . . . . . . . . . . . . . . . . . 13
	4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . 13		4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . 13
	4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . 13		4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . 13
	4.2 The NXT RR Presentation Format . . . . . . . . . . . . . . 14		4.2 The NXT RR Presentation Format . . . . . . . . . . . . . . 14
	5. The DS Resource Record (placeholder) . . . . . . . . . . . 15		5. The DS Resource Record . . . . . . . . . . . . . . . . . . 15
	6. DNSSEC message bits . . . . . . . . . . . . . . . . . . . 16		5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15
	6.1 The AD and CD Header Bits . . . . . . . . . . . . . . . . 16		5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 15
	6.2 The DO Extended Flags Field Bit . . . . . . . . . . . . . 16		5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . 15
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . 18		5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . 16
	8. Security Considerations . . . . . . . . . . . . . . . . . 19		5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . 16
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 20		5.2 DS Record Example . . . . . . . . . . . . . . . . . . . . 16
	References . . . . . . . . . . . . . . . . . . . . . . . . 21		5.3 Resolver Example . . . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . 22		6. DNSSEC message bits . . . . . . . . . . . . . . . . . . . 18
			6.1 The AD and CD Header Bits . . . . . . . . . . . . . . . . 18
	A. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 23		6.2 The DO Extended Flags Field Bit . . . . . . . . . . . . . 18
	Full Copyright Statement . . . . . . . . . . . . . . . . . 24		7. IANA Considerations . . . . . . . . . . . . . . . . . . . 20
			8. Security Considerations . . . . . . . . . . . . . . . . . 21
			9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 22
			References . . . . . . . . . . . . . . . . . . . . . . . . 23
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . 24
			A. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 25
			Full Copyright Statement . . . . . . . . . . . . . . . . . 26
	1. Introduction		1. Introduction
	The reader to assumed to be familiar with common DNSSEC terminology		The reader to assumed to be familiar with common DNSSEC terminology
	as defined in [13] and familiar with the basic DNS concepts described		as defined in [13] and familiar with the basic DNS concepts described
	in RFC1034 [1] and RFC1035 [2].		in RFC1034 [1] and RFC1035 [2].
	The DNS Security Extensions (DNSSEC) introduce four resource records:		The DNS Security Extensions (DNSSEC) introduce four resource records:
	KEY, DS, SIG, and NXT resource records. This document defines the		KEY, DS, SIG, and NXT resource records. This document defines the
	purpose of each resource record, the RDATA format, the ASCII		purpose of each resource record, the RDATA format, the ASCII
	skipping to change at page 6, line 17 ¶		skipping to change at page 6, line 17 ¶
	2.1.1.1 Explanation for Choice of Bit 7		2.1.1.1 Explanation for Choice of Bit 7
	The choice of bit 7 as the zone key flag was made in order to provide		The choice of bit 7 as the zone key flag was made in order to provide
	backwards compatibility with an earlier version of the KEY record.		backwards compatibility with an earlier version of the KEY record.
	This earlier version was defined in [6] and [15] eliminated all flags		This earlier version was defined in [6] and [15] eliminated all flags
	except the bit 7 zone key flag.		except the bit 7 zone key flag.
	2.1.2 The Protocol Octet Field		2.1.2 The Protocol Octet Field
	The Protocol Octet value MUST be 3. Name servers and resolvers		The Protocol Octet value MUST be 3.
	SHOULD reject KEY records with a Protocol Octet value other than 3.
	2.1.2.1 Explanation for a Fixed Value Protocol Octet Field		2.1.2.1 Explanation for a Fixed Value Protocol Octet Field
	The Protocol Octet field is included for backwards compatibility with		The Protocol Octet field is included for backwards compatibility with
	an earlier version of the KEY record. This earlier version of the		an earlier version of the KEY record. This earlier version of the
	KEY record was defined in [6] and [15] restricted the possible		KEY record was defined in [6] and [15] restricted the possible
	Protocol Octet values to 3.		Protocol Octet values to 3.
	2.1.3 The Algorithm and Public Key Fields		2.1.3 The Algorithm and Public Key Fields
	skipping to change at page 6, line 40 ¶		skipping to change at page 6, line 39 ¶
	algorithm and determines the format of the Public Key Field.		algorithm and determines the format of the Public Key Field.
	Algorithm values are defined in separate documents. The following		Algorithm values are defined in separate documents. The following
	table shows the currently defined Algorithm formats:		table shows the currently defined Algorithm formats:
	VALUE Algorithm RFC STATUS		VALUE Algorithm RFC STATUS
	0 Reserved - -		0 Reserved - -
	1 RSA/MD5 RFC 2536 NOT RECOMMENDED		1 RSA/MD5 RFC 2536 NOT RECOMMENDED
	2 Diffie-Hellman RFC 2539 OPTIONAL		2 Diffie-Hellman RFC 2539 OPTIONAL
	3 DSA RFC 2536 MANDATORY		3 DSA RFC 2536 MANDATORY
	4 elliptic curve - reserved		4 elliptic curve Work in Progress
	5 RSA/SHA1 RFC 3110 MANDATORY		5 RSA/SHA1 RFC 3110 MANDATORY
	6-251 available for assignment -		6-251 available for assignment -
	252 reserved - indirect keys		252 reserved - indirect keys
	253 private - domain name		253 private - domain name
	254 private - OID		254 private - OID
	255 reserved - -		255 reserved - -
	EDITORS NOTE: indirect keys (252), private keys 253/254 and the		It is expected that a signed zone will contain at least one KEY
	implication of making a key MANDATORY need further clarification.		record with one of the MANDATORY algorithms. A DNS security aware
	This clarification will be in the next version of this document.		resolver MUST implement all MANDATORY and SHOULD implement all
			OPTIONAL algorithms. Currently RSA/MD5 is NOT RECOMMENDED for zone
			signing, but it may be found in older DNS implementations.
			Therefore, if may be useful for a security aware resolver to
			implement RSA/MD5 as well as RSA/SHA1.
			Algorithm number 252 is reserved for indirect key format where the
			actual key material is elsewhere (non-DNS). This format will be
			defined in a separate document.
			Algorithm numbers 253 and 254 are reserved for private use and will
			never be assigned a specific algorithm. For number 253, the public
			key area and the signature begin with a wire encoded domain name
			indicating the algorithm the key uses. Only local domain name
			compression is permitted. The remainder of the public key area is
			privately defined. For number 254, the public key area for the KEY
			RR and the signature begin with an unsigned length byte followed by a
			BER encoded Object Identifier (ISO OID) of that length. The OID
			indicates the private algorithm in use and the remainder of the area
			is whatever is required by that algorithm. Entities should only use
			domain names and OIDs they control to designate their private
			algorithms.
	2.2 The KEY RR Presentation Format		2.2 The KEY RR Presentation Format
	A KEY RR may appear as a single line. The presentation format of the		A KEY RR may appear as a single line. The presentation format of the
	RDATA portion is as follows:		RDATA portion is as follows:
	The Flag field is represented as an unsigned integer.		The Flag field is represented as an unsigned integer.
	The Protocol Octet field is represented as the unsigned integer 3.		The Protocol Octet field is represented as the unsigned integer 3.
	skipping to change at page 13, line 20 ¶		skipping to change at page 13, line 20 ¶
	The NXT RR lists the next canonical name in the zone and lists what		The NXT RR lists the next canonical name in the zone and lists what
	RR types are present for the current name of the NXT RR.		RR types are present for the current name of the NXT RR.
	The set of NXT RRs in a zone is a chain of all authoritative names in		The set of NXT RRs in a zone is a chain of all authoritative names in
	that zone.		that zone.
	Glue address records MUST NOT be covered by a NXT RR.		Glue address records MUST NOT be covered by a NXT RR.
	The type number for the NXT RR is 30.		The type number for the NXT RR is 30.
	The NXT RR is class independant.		The NXT RR is class independent.
	The NXT RR TTL SHOULD NOT exceed the zone minimum TTL.		The NXT RR TTL SHOULD NOT exceed the zone minimum TTL.
	4.1 NXT RDATA Wire Format		4.1 NXT RDATA Wire Format
	The RDATA of the NXT RR is as shown below:		The RDATA of the NXT RR is as shown below:
	1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 15, line 5 ¶		skipping to change at page 15, line 5 ¶
	4.2 The NXT RR Presentation Format		4.2 The NXT RR Presentation Format
	A NXT RR may appear as a single line. The presentation format of the		A NXT RR may appear as a single line. The presentation format of the
	RDATA portion is as follows:		RDATA portion is as follows:
	The "next domain name" field is represented as a domain name.		The "next domain name" field is represented as a domain name.
	The "type bit map" field is represented as a sequence of RR type		The "type bit map" field is represented as a sequence of RR type
	mnemonics or as an unsigned integer.		mnemonics or as an unsigned integer.
	5. The DS Resource Record (placeholder)		5. The DS Resource Record
	[This section will be finalised once DS has WG consensus and is		The DS record is a major change to DNS: it is the first resource
	proposed standard]		record that can appear only on the upper side of a delegation. Other
			keys MAY sign the child's apex KEY RRset. DS records MUST point to
			zone KEY records that are allowed to authenticate DNS data.
			The type number for the DS record is 43.
			The DS record is class independent.
			5.1 DS RDATA Wire Format
			This record contains these fields: key tag, algorithm, digest type,
			and the digest of a public key KEY record that is allowed and/or used
			to sign the child's apex KEY RRset.
			1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| key tag | algorithm | Digest type |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Digest |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| (20 bytes for SHA-1) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			5.1.1 The Key Tag Field
			The key tag value is the same key tag value in the SIG RRs generated
			using the KEY record this DS record points too. Having the key tag
			in the RDATA provides additional reliability in matching than just
			the KEY digest alone. See the key tag for details.
			5.1.2 The Algorithm Field
			The algorithm value has the same defined values as the KEY and SIG
			records. The value MUST be an algorithm number assigned in the range
			1..251 and the algorithm MUST be allowed to sign DNS data.
			5.1.3 The Digest Type Field
			The digest type is an identifier for the digest algorithm used. The
			following numbers have been assigned and the assignment of future
			numbers requires IETF standards action.
			VALUE Algorithm STATUS
			0 Reserved -
			1 RSA/SHA-1 MANDATORY
			2-255 Unassigned -
			5.1.4 The Digest Field
			The digest is calculated over the canonical name of the delegated
			domain name followed by the whole RDATA of the KEY record (all four
			fields). The size of the DS RDATA for type 1 (SHA-1) is 24 bytes,
			regardless of key size. Other digest algorithms may have a differing
			digest size, to be described in other documents.
			digest = hash( cannonical FQDN on KEY RR | KEY_RR_rdata)
			KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key
			5.2 DS Record Example
			The presentation format of the DS record consists of three numbers
			(key tag, algorithm and digest type) followed by the digest itself
			presented in hex:
			example. DS 12345 3 1 123456789abcdef67890123456789abcdef67890
			This is a example of a KEY record and corresponding DS record.
			dskey.example. KEY 256 3 1 (
			encoded public key
			) ; key id = 28668
			DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE
			5.3 Resolver Example
			To create a chain of trust, a resolver goes from trusted KEY to DS to
			KEY.
			Assume the key for domain "example." is trusted. Zone "example."
			contains at least the following records:
			example. SOA (soa stuff)
			example. NS ns.example.
			example. KEY (encoded public key)
			example. NXT NS SOA KEY SIG NXT
			example. SIG(SOA)
			example. SIG(NS)
			example. SIG(NXT)
			example. SIG(KEY)
			secure.example. NS ns1.secure.example.
			secure.example. DS tag=10243 alg=3 digest_type=1
			secure.example. NXT NS SIG NXT DS unsecure.example.
			secure.example. SIG(NXT)
			secure.example. SIG(DS)
			unsecure.example NS ns1.unsecure.example.
			unsecure.example. NXT NS SIG NXT .example.
			unsecure.example. SIG(NXT)
			In zone "secure.example." following records exist:
			secure.example. SOA (soa stuff)
			secure.example. NS ns1.secure.example.
			secure.example. KEY (tag=12345 alg=3)
			secure.example. SIG(KEY) (key-tag=12345 alg=3)
			secure.example. SIG(SOA) (key-tag=12345 alg=3)
			secure.example. SIG(NS) (key-tag=12345 alg=5)
			In this example the private key for "example." signs the DS record
			for "secure.example.", making that a secure delegation. The DS
			record states which key is expected to sign the RRsets at
			"secure.example.". Here "secure.example." signs its KEY RRset with
			the KEY identified in the DS RRset, thus the KEY RRset is validated
			and trusted.
			This example has only one DS record for the child, but parents MUST
			allow multiple DS records to facilitate key rollover. It is strongly
			recommended that the DS RRset be kept small: two or three DS records
			should be sufficient in all cases.
			The resolver determines the security status of "unsecure.example." by
			examining the parent zone's NXT record for this name. The absence of
			the DS bit indicates an unsecure delegation.
	6. DNSSEC message bits		6. DNSSEC message bits
	There are 3 new bits allocated for use with DNSSEC. The DO bit is		There are 3 new bits allocated for use with DNSSEC. The DO bit is
	used to indicate to a server that the resolver is able to accept		used to indicate to a server that the resolver is able to accept
	DNSSEC security RRs (KEY SIG NXT DS). The CD and AD bits are used to		DNSSEC security RRs (KEY SIG NXT DS). The CD and AD bits are used to
	indicate if non-authenticated data is accepted, and if data is		indicate if non-authenticated data is accepted, and if data is
	authenticated.		authenticated.
	6.1 The AD and CD Header Bits		6.1 The AD and CD Header Bits
	skipping to change at page 19, line 5 ¶		skipping to change at page 20, line 10 ¶
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	|DO| Z |		|DO| Z |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	The usage of the DO bit is defined in [14]		The usage of the DO bit is defined in [14]
	7. IANA Considerations		7. IANA Considerations
	This document clarifies the use of existing types and introduces no		This document clarifies the use of existing types and introduces no
	new IANA considerations.		new IANA considerations.
			The definitions of the flag bits in the KEY RR are set by working
			group consensus and there is no IANA registry for their definition.
			Changes to the meaning of the bits in the flags section of the KEY
			RDATA must be done through working group consensus.
			RFC 2535 created an IANA registry for DNSSEC Resource Record
			algorithm Octet values. Values to 1-5, and 255 were assigned and
			values 6-254 were made available for assignment by IANA. This
			document re-assigns DNS KEY Resource Record Protocol Octet values 1,
			2, 4, and 255 to ``reserved''. DNS Key Resource Record Protocol
			Octet Value 3 remains unchanged as ``DNSSEC''.
			New protocol values are no longer available for assignment by IANA
			and this document closes the IANA registry for DNS KEY Resource
			Record Protocol Octet Values. Assignment of any future KEY Resource
			Record Protocol Octet values requires a standards action. New
			numbers for algorithm values will continue to be assigned by IANA.
			IANA needs to open a new registry for the DS RR type digest
			algorithms. Defined types are: 0 is Reserved, 1 is SHA-1. Adding
			new reservations requires IETF standards action.
	8. Security Considerations		8. Security Considerations
	This document describes the format of resource records used by DNS		This document describes the format of resource records used by DNS
	security. The threats facing DNS are described in a seperate		security. The threats facing DNS are described in a separate
	document and these records are used to help counter those threats.		document and these records are used to help counter those threats.
	The records themselves introduce no new security considerations, but		The records themselves introduce no new security considerations, but
	the protocol use of these records is described in a second document.		the protocol use of these records is described in a second document.
	9. Acknowledgements		9. Acknowledgements
			This document was created from the input and ideas of several members
			of the DNS Extensions Working Group and working group mailing list.
			The co-authors of this draft would like to express their thanks for
			the comments and suggestions received during the re-writing of these
			security extension specifications.
	References		References
	[1] Mockapetris, P., "Domain names - concepts and facilities", STD		[1] Mockapetris, P., "Domain names - concepts and facilities", STD
	13, RFC 1034, November 1987.		13, RFC 1034, November 1987.
	[2] Mockapetris, P., "Domain names - implementation and		[2] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.		specification", STD 13, RFC 1035, November 1987.
	[3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,		[3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
	August 1996.		August 1996.
	skipping to change at page 23, line 13 ¶		skipping to change at page 25, line 13 ¶
	EMail: scott.rose@nist.gov		EMail: scott.rose@nist.gov
	Appendix A. Key Tag Calculation		Appendix A. Key Tag Calculation
	The key tag field in the SIG RR is just a means of more efficiently		The key tag field in the SIG RR is just a means of more efficiently
	selecting the correct KEY RR to use when there is more than one KEY		selecting the correct KEY RR to use when there is more than one KEY
	RR candidate available, for example, in verifying a signature. It is		RR candidate available, for example, in verifying a signature. It is
	possible for more than one candidate key to have the same tag, in		possible for more than one candidate key to have the same tag, in
	which case each must be tried until one works or all fail. The		which case each must be tried until one works or all fail. The
	following reference implementation of how to calculate the Key Tag,		following reference implementation of how to calculate the Key Tag,
	for all algorithms other than algorithm 1, is in ANSI C. It is coded		for all algorithms other than algorithm 1 (which is NOT RECOMMENDED),
	for clarity, not efficiency.		is in ANSI C. The input is the key material in base 64,not the
			entire RDATA of the KEY record that contains the public key. It is
			coded for clarity, not efficiency.
	/* assumes int is at least 16 bits		/* assumes int is at least 16 bits
	first byte of the key tag is the most significant byte of return		first byte of the key tag is the most significant byte of return
	value		value
	second byte of the key tag is the least significant byte of		second byte of the key tag is the least significant byte of
	return value		return value
	*/		*/
	int keytag (		int keytag (
End of changes. 17 change blocks.
	31 lines changed or deleted		217 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/