idnits 2.17.00 (12 Aug 2021) /tmp/idnits27736/draft-ietf-dnsext-dnssec-records-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 486 has weird spacing: '...decimal integ...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2003) is 7024 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '12' is defined on line 977, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1521 (ref. '3') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 2671 (ref. '6') (Obsoleted by RFC 6891) == Outdated reference: draft-ietf-dnsext-delegation-signer has been published as RFC 3658 == Outdated reference: draft-ietf-dnsext-dnssec-intro has been published as RFC 4033 == Outdated reference: draft-ietf-dnsext-dnssec-protocol has been published as RFC 4035 == Outdated reference: draft-ietf-dnsext-unknown-rrs has been published as RFC 3597 == Outdated reference: draft-ietf-dnsext-dnssec-opt-in has been published as RFC 4956 ** Downref: Normative reference to an Experimental draft: draft-ietf-dnsext-dnssec-opt-in (ref. '13') -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '14') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3445 (ref. '16') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions R. Arends 3 Internet-Draft Telematica Instituut 4 Expires: August 26, 2003 R. Austein 5 ISC 6 M. Larson 7 VeriSign 8 D. Massey 9 USC/ISI 10 S. Rose 11 NIST 12 February 25, 2003 14 Resource Records for the DNS Security Extensions 15 draft-ietf-dnsext-dnssec-records-03 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at http:// 33 www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 26, 2003. 40 Copyright Notice 42 Copyright (C) The Internet Society (2003). All Rights Reserved. 44 Abstract 46 This document is part of a family of documents that describes the DNS 47 Security Extensions (DNSSEC). The DNS Security Extensions are a 48 collection of resource records and protocol modifications that 49 provide source authentication for the DNS. This document defines the 50 KEY, DS, SIG, and NXT resource records. The purpose and format of 51 each resource record is described in detail and an example of each 52 resource record is given. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1 Background and Related Documents . . . . . . . . . . . . . . 4 58 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.3 Editors Notes . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4 61 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4 62 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 63 2. The KEY Resource Record . . . . . . . . . . . . . . . . . . 6 64 2.1 KEY RDATA Wire Format . . . . . . . . . . . . . . . . . . . 6 65 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . . 6 66 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . . . . 7 67 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 7 68 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . . . . 7 69 2.1.5 Notes on KEY RDATA Design . . . . . . . . . . . . . . . . . 7 70 2.2 The KEY RR Presentation Format . . . . . . . . . . . . . . . 7 71 2.3 KEY RR Example . . . . . . . . . . . . . . . . . . . . . . . 7 72 3. The SIG Resource Record . . . . . . . . . . . . . . . . . . 9 73 3.1 SIG RDATA Wire Format . . . . . . . . . . . . . . . . . . . 9 74 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . . 10 75 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . . 10 76 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . . 10 77 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . . 11 78 3.1.5 Signature Expiration and Inception Fields . . . . . . . . . 11 79 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 11 80 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . . 11 81 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . . 12 82 3.2 The SIG RR Presentation Format . . . . . . . . . . . . . . . 12 83 3.3 SIG RR Example . . . . . . . . . . . . . . . . . . . . . . . 13 84 4. The NXT Resource Record . . . . . . . . . . . . . . . . . . 15 85 4.1 NXT RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15 86 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 15 87 4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . . 15 88 4.1.3 Inclusion of Wildcard Names in NXT RDATA . . . . . . . . . . 16 89 4.2 The NXT RR Presentation Format . . . . . . . . . . . . . . . 16 90 4.3 NXT RR Example . . . . . . . . . . . . . . . . . . . . . . . 16 91 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 18 92 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 18 93 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 18 94 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 19 95 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 19 96 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 19 97 5.2 The DS RR Presentation Format . . . . . . . . . . . . . . . 19 98 5.3 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 20 99 6. Canonical Form and Order of Resource Records . . . . . . . . 21 100 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 21 101 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . . 21 102 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . . 22 103 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 104 8. Security Considerations . . . . . . . . . . . . . . . . . . 24 105 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25 106 Normative References . . . . . . . . . . . . . . . . . . . . 26 107 Informative References . . . . . . . . . . . . . . . . . . . 27 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27 109 A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . 29 110 A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 29 111 A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . . . . 29 112 A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 30 113 B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 31 114 B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 32 115 Full Copyright Statement . . . . . . . . . . . . . . . . . . 33 117 1. Introduction 119 The DNS Security Extensions (DNSSEC) introduce four new DNS resource 120 record types: KEY, SIG, NXT, and DS. This document defines the 121 purpose of each resource record (RR), the RR's RDATA format, and its 122 ASCII representation. 124 1.1 Background and Related Documents 126 The reader is assumed to be familiar with the basic DNS concepts 127 described in RFC1034 [1] and RFC1035 [2]. 129 This document is part of a family of documents that define the DNS 130 security extensions. The DNS security extensions (DNSSEC) are a 131 collection of resource records and DNS protocol modifications that 132 add source authentication the Domain Name System (DNS). An 133 introduction to DNSSEC and definition of common terms can be found in 134 [10]. A description of DNS protocol modifications can be found in 135 [11]. This document defines the DNSSEC resource records. 137 1.2 Reserved Words 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [5]. 143 1.3 Editors Notes 145 1.3.1 Open Technical Issues 147 The NXT section (Section 4) may be updated in the next version if 148 DNSSEC-Opt-In [13] becomes part of DNSSEC. 150 The cryptographic algorithm types (Appendix A) requires input from 151 the working group. The DSA algorithm was moved to OPTIONAL. This 152 had strong consensus in workshops and various discussions and a 153 separate internet draft solely to move DSA from MANDATORY to OPTIONAL 154 seemed excessive. This draft solicits input on that proposed change. 156 1.3.2 Technical Changes or Corrections 158 Please report technical corrections to dnssec-editors@east.isi.edu. 159 To assist the editors, please indicate the text in error and point 160 out the RFC that defines the correct behavior. For a technical 161 change where no RFC that defines the correct behavior, or if there's 162 more than one applicable RFC and the definitions conflict, please 163 post the issue to namedroppers. 165 An example correction to dnssec-editors might be: Page X says 166 "DNSSEC RRs SHOULD be automatically returned in responses." This was 167 true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the 168 DNSSEC RR types MUST NOT be included in responses unless the resolver 169 indicated support for DNSSEC. 171 1.3.3 Typos and Minor Corrections 173 Please report any typos corrections to dnssec-editors@east.isi.edu. 174 To assist the editors, please provide enough context for us to find 175 the incorrect text quickly. 177 An example message to dnssec-editors might be: page X says "the 178 DNSSEC standard has been in development for over 1 years". It 179 should read "over 10 years". 181 2. The KEY Resource Record 183 DNSSEC uses public key cryptography to sign and authenticate DNS 184 resource record sets (RRsets). The public keys are stored in KEY 185 resource records and are used in the DNSSEC authentication process 186 described in [11]. In a typical example, a zone signs its 187 authoritative RRsets using a private key and stores the corresponding 188 public key in a KEY RR. A resolver can then use these signatures to 189 authenticate RRsets from the zone. 191 The KEY RR may also be used to store public keys associated with 192 other DNS operations such as TKEY [15]. In all cases, the KEY RR 193 plays a special role in secure DNS resolution and DNS message 194 processing. The KEY RR is not intended as a record for storing 195 arbitrary public keys. The KEY RR MUST NOT be used to store 196 certificates or public keys that do not directly relate to the DNS 197 infrastructure. Examples of certificates and public keys that MUST 198 NOT be stored in the KEY RR include X.509 certificates, IPSEC public 199 keys, and SSH public keys. 201 The Type value for the KEY RR type is 25. 203 The KEY RR is class independent. 205 There are no special TTL requirements on the KEY record. 207 2.1 KEY RDATA Wire Format 209 The RDATA for a KEY RR consists of a 2 octet Flags Field, a 1 octet 210 Protocol Field, a 1 octet Algorithm Field , and the Public Key Field. 212 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Flags | Protocol | Algorithm | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 / / 218 / Public Key / 219 / / 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 2.1.1 The Flags Field 224 Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, 225 then the KEY record holds a DNS zone key and the KEY's owner name 226 MUST be the name of a zone. If bit 7 has value 0, then the KEY 227 record holds some other type of DNS public key, such as a public key 228 used by TKEY. 230 Bits 0-6 and 8-15 are reserved and MUST have value 0 upon creation of 231 the KEY RR, and MUST be ignored upon reception. 233 Editors' Note: draft-ietf-dnsext-keyrr-key-signing-flag changes this 234 by allocating bit 15 as the KSK bit. 236 2.1.2 The Protocol Field 238 The Protocol Field MUST have value 3. 240 2.1.3 The Algorithm Field 242 The Algorithm field identifies the public key's cryptographic 243 algorithm and determines the format of the Public Key field. A list 244 of DNSSEC algorithm types can be found in Appendix A.1 246 2.1.4 The Public Key Field 248 The Public Key Field holds the public key material. 250 2.1.5 Notes on KEY RDATA Design 252 Although the Protocol Field always has value 3, it is retained for 253 backward compatibility with an earlier version of the KEY record. 255 2.2 The KEY RR Presentation Format 257 The presentation format of the RDATA portion is as follows: 259 The Flag field is represented as an unsigned decimal integer with a 260 value of either 0 or 256. 262 The Protocol Field is represented as an unsigned decimal integer with 263 a value of 3. 265 The Algorithm field is represented either as an unsigned decimal 266 integer or as an algorithm mnemonic as specified in Appendix A.1. 268 The Public Key field is represented as a Base64 encoding of the 269 Public Key. Whitespace is allowed within the Base64 text. For a 270 definition of Base64 encoding, see [3] Section 5.2. 272 2.3 KEY RR Example 274 The following KEY RR stores a DNS zone key for example.com. 276 example.com. 86400 IN KEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3Cbl 277 +BBZH4b/0PY1kxkmvHjcZc8nokfzj31 278 GajIQKY+5CptLr3buXA10hWqTkF7H6R 279 foRqXQeogmMHfpftf6zMv1LyBUgia7z 280 a6ZEzOJBOztyvhjL742iU/TpPSEDhm2 281 SNKLijfUppn1UaNvv4w== ) 283 The first four text fields specify the owner name, TTL, Class, and RR 284 type (KEY). Value 256 indicates that the Zone Key bit (bit 7) in the 285 Flags field has value 1. Value 3 is the fixed Protocol value. Value 286 5 indicates the public key algorithm. Appendix A.1 identifies 287 algorithm type 5 as RSA/SHA1 and indicates that the format of the 288 RSA/SHA1 public key field is defined in [8]. The remaining text is a 289 base 64 encoding of the public key. 291 3. The SIG Resource Record 293 DNSSEC uses public key cryptography to sign and authenticate DNS 294 resource record sets (RRsets). Signatures are stored in SIG resource 295 records and are used in the DNSSEC authentication process described 296 in [11]. In a typical example, a zone signs its authoritative RRsets 297 using a private key and stores the corresponding signatures in SIG 298 RRs. A resolver can then use these SIG RRs to authenticate RRsets 299 from the zone. 301 A SIG record contains the signature for an RRset with a particular 302 name, class, and type. The SIG RR specifies a validity interval for 303 the signature and uses the Algorithm, the Signer's Name, and the Key 304 Tag to identify the public key (KEY RR) that can be used to verify 305 the signature. 307 The SIG RR may cover a transaction instead of an RRset. In this 308 case, the "Type Covered" field value is 0, the SIG RR MUST NOT appear 309 in any zone, and its use and processing are outside the scope of this 310 document. Please see [7] for further details. 312 The Type value for the SIG RR type is 24. 314 The SIG RR MUST have the same class as the RRset it covers. 316 The SIG RR TTL value SHOULD match the TTL value of the RRset it 317 covers. 319 3.1 SIG RDATA Wire Format 321 The RDATA for a SIG RR consists of a 2 octet Type Covered field, a 1 322 octet Algorithm field, a 1 octet Labels field, a 4 octet Original TTL 323 field, a 4 octet Signature Expiration field, a 4 octet Signature 324 Inception field, a 2 octet Key tag, the Signer's Name field, and the 325 Signature field. 327 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Type Covered | Algorithm | Labels | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Original TTL | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Signature Expiration | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Signature Inception | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Key Tag | / 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / 340 / / 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 / / 343 / Signature / 344 / / 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 3.1.1 The Type Covered Field 349 The Type Covered field identifies the type of the RRset which is 350 covered by this SIG record. 352 If Type Covered field has a value of 0, the record is referred to as 353 a transaction signature; please see [7] for further details. 355 3.1.2 The Algorithm Number Field 357 The Algorithm Number field identifies the cryptographic algorithm 358 used to create the signature. A list of DNSSEC algorithm types can 359 be found in Appendix A.1 361 3.1.3 The Labels Field 363 The Labels field specifies the number of labels in the original SIG 364 RR owner name. It is included to handle signatures associated with 365 wildcard owner names. 367 To validate a signature, the validator requires the original owner 368 name that was used when the signature was created. If the original 369 owner name contains a wildcard label ("*"), the owner name may have 370 been expanded by the server during the response process, in which 371 case the validator will need to reconstruct the original owner name 372 in order to validate the signature. [11] describes how to use the 373 Labels field to reconstruct the original owner name. 375 The value of the Label field MUST NOT count either the null (root) 376 label that terminates the owner name or the wildcard label (if 377 present). The value of the Label field MUST be less than or equal to 378 the number of labels in the SIG owner name. For example, 379 "www.example.com." has a Label field value of 3, and "*.example.com." 380 has a Label field value of 2. Root (".") has a Label field value of 381 0. 383 Note that, although the wildcard label is not included in the count 384 stored in the Label field of the SIG RR, the wildcard label is part 385 of the RRset's owner name when generating or verifying the signature. 387 3.1.4 Original TTL Field 389 The Original TTL field specifies the TTL of the covered RRset as it 390 appears in the authoritative zone. 392 The Original TTL field is necessary because a caching resolver 393 decrements the TTL value of a cached RRset. In order to validate a 394 signature, a resolver requires the original TTL. [11] describes how 395 to use the Original TTL field value to reconstruct the original TTL. 397 The Original TTL value MUST be greater than or equal to the TTL value 398 of the SIG record itself. 400 3.1.5 Signature Expiration and Inception Fields 402 The Signature Expiration and Inception fields specify a validity 403 period for the signature. The SIG record MUST NOT be used for 404 authentication prior to the inception date and MUST NOT be used for 405 authentication after the expiration date. 407 Signature Expiration and Inception field values are in POSIX.1 time 408 format, a 32-bit unsigned number of seconds elapsed since 1 January 409 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The 410 longest interval which can be expressed by this format without 411 wrapping is approximately 136 years. A SIG RR can have an Expiration 412 field value which is numerically smaller than the Inception field 413 value if the expiration field value is near the 32-bit wrap-around 414 point or if the signature is long lived. Because of this, all 415 comparisons involving these fields MUST use "Serial number 416 arithmetic" as defined in [4]. As a direct consequence, the values 417 contained in these fields cannot refer to dates more than 68 years in 418 either the past or the future. 420 3.1.6 The Key Tag Field 422 The Key Tag field contains the key tag value of the KEY RR that 423 validates this signature. The process of calculating the Key Tag 424 value is given in Appendix B. 426 3.1.7 The Signer's Name Field 428 The Signer's Name field value identifies the owner name of the KEY RR 429 used to authenticate this signature. The Signer's Name field MUST 430 contain the name of the zone of the covered RRset, unless the Type 431 Covered field value is 0. A sender MUST NOT use DNS name compression 432 on the Signer's Name field when transmitting a SIG RR. A receiver 433 which receives a SIG RR containing a compressed Signer's Name field 434 SHOULD decompress the field value. 436 3.1.8 The Signature Field 438 The Signature field contains the cryptographic signature which covers 439 the SIG RDATA (excluding the Signature field) and the RRset specified 440 by the SIG owner name, SIG class, and SIG Type Covered field. 442 3.1.8.1 Signature Calculation 444 A signature covers the SIG RDATA (excluding the Signature Field) and 445 covers the RRset specified by the SIG owner name, SIG class, and SIG 446 Type Covered field. The RRset is in canonical form (see Section 6) 447 and the set RR(1),...RR(n) is signed as follows: 449 signature = sign(SIG_RDATA | RR(1) | RR(2)... ) where 451 "|" denotes concatenation; 453 SIG_RDATA is the wire format of the SIG RDATA fields with 454 the Signer's Name field in canonical form and 455 the Signature field excluded; 457 RR(i) = owner | class | type | TTL | RDATA length | RDATA; 459 "owner" is the fully qualified owner name of the RRset in 460 canonical form (for RRs with wildcard owner names, the 461 wildcard label is included in the owner name); 463 Each RR MUST have the same owner name as the SIG RR; 465 Each RR MUST have the same class as the SIG RR; 467 Each RR in the RRset MUST have the RR type listed in the 468 SIG RR's Type Covered field; 470 Each RR in the RRset MUST have the TTL listed in the SIG 471 Original TTL Field; 473 Any DNS names in the RDATA field of each RR MUST be in 474 canonical form; and 476 The RRset MUST be sorted in canonical order. 478 3.2 The SIG RR Presentation Format 480 The presentation format of the RDATA portion is as follows: 482 The Type Covered field value is represented either as an unsigned 483 decimal integer or as the mnemonic for the covered RR type. 485 The Algorithm field value is represented either as an unsigned 486 decimal integer or as an algorithm mnemonic as specified in Appendix 487 A.1. 489 The Labels field value is represented as an unsigned decimal integer. 491 The Original TTL field value is represented as an unsigned decimal 492 integer. 494 The Signature Inception Time and Expiration Time field values are 495 represented in the form YYYYMMDDHHmmSS in UTC, where: 497 YYYY is the year (0000-9999, but see Section 3.1.5); 499 MM is the month number (01-12); 501 DD is the day of the month (01-31); 503 HH is the hour in 24 hours notation (00-23); 505 mm is the minute (00-59); 507 SS is the second (00-59). 509 The Key Tag field is represented as an unsigned decimal integer. 511 The Signer's Name field value is represented as a fully qualified 512 domain name. 514 The Signature field is represented as a Base64 encoding of the 515 signature. Whitespace is allowed within the Base64 text. For a 516 definition of Base64 encoding see [3] Section 5.2. 518 3.3 SIG RR Example 520 The following a SIG RR stores the signature for the A RRset of 521 host.example.com: 523 host.example.com. 86400 IN SIG A 5 3 86400 20030322173103 ( 524 20030220173103 2642 example.com. 525 oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr 526 PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o 527 B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t 528 GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG 529 J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) 531 The first four fields specify the owner name, TTL, Class, and RR type 532 (SIG). The "A" represents the Type Covered field. The value 5 533 identifies the Algorithm used (RSA-SHA1) to create the signature. 534 The value 3 is the number of Labels in the original owner name. The 535 value 86400 in the SIG RDATA is the Original TTL for the covered A 536 RRset. 20030322173103 and 20030220173103 are the expiration and 537 inception dates, respectively. 2642 is the Key Tag, and example.com. 538 is the Signer's Name. The remaining text is a Base64 encoding of the 539 signature. 541 Note that combination of SIG RR owner name, class, and Type Covered 542 indicate that this SIG covers the "host.example.com" A RRset. The 543 Label value of 3 indicates that no wildcard expansion was used. The 544 Algorithm, Signer's Name, and Key Tag indicate this signature can be 545 authenticated using an example.com zone KEY RR whose algorithm is 5 546 and key tag is 2642. 548 4. The NXT Resource Record 550 The NXT resource record lists two separate things: the owner name of 551 the next authoritative RRset in the canonical ordering of the zone, 552 and the set of RR types present at the NXT RR's owner name. The 553 complete set of NXT RRs in a zone both indicate which authoritative 554 RRsets exist in a zone and also form a chain of authoritative owner 555 names in the zone. This information is used to provide authenticated 556 denial of existence for DNS data, as described in [11]. 558 The type value for the NXT RR is 30. 560 The NXT RR is class independent. 562 4.1 NXT RDATA Wire Format 564 The RDATA of the NXT RR is as shown below: 566 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 / Next Domain Name / 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 / Type Bit Map / 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 4.1.1 The Next Domain Name Field 576 The Next Domain Name field contains the owner name of the next 577 authoritative RRset in the canonical ordering of the zone; see 578 Section 6.1 for an explanation of canonical ordering. The value of 579 the Next Domain Name field in the last NXT record in the zone is the 580 name of the zone apex (the owner name name of the zone's SOA RR). 582 A sender MUST NOT use DNS name compression on the Next Domain Name 583 field when transmitting an NXT RR. A receiver which receives an NXT 584 RR containing a compressed Next Domain Name field SHOULD decompress 585 the field value. 587 Owner names of non-authoritative RRsets (such as glue records) MUST 588 NOT be listed in the Next Domain Name unless at least one 589 authoritative RRset exists at the same owner name. 591 4.1.2 The Type Bit Map Field 593 The Type Bit Map field identifies the RRset types which exist at the 594 NXT RR's owner name. 596 Each bit in the Type Bit Map field corresponds to an RR type. Bit 1 597 corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS), 598 and so forth. If a bit is set to 1, it indicates that an RRset of 599 that type is present for the NXT's owner name. If a bit is set to 0, 600 it indicates that no RRset of that type present for the NXT's owner 601 name. 603 Bit 1 MUST NOT indicate glue address records. 605 Bit 41 MUST have the value of 0, since the OPT pseudo-RR [6] can 606 never appear in zone data. 608 Trailing zero octets MUST be omitted. The length of the Type Bit Map 609 field varies, and is determined by the type code with the largest 610 numerical value among the set of RR types present at the NXT RR's 611 owner name. Trailing zero octets not specified MUST be interpreted 612 as zero octets. 614 The above Type Bit Map format MUST NOT be used when an RR type code 615 with numerical value greater than 127 is present. 617 Bit 0 in the Type Bit Map field indicates the Type Bit Map format. A 618 value of 0 in bit 0 denotes the format described above, therefore bit 619 0 MUST have a value of 0. The format and meaning of a Type Bit Map 620 with a value of 1 in bit 0 is undefined. 622 4.1.3 Inclusion of Wildcard Names in NXT RDATA 624 If a wildcard owner name appears in a zone, the wildcard label ("*") 625 is treated as a literal symbol and is treated the same as any other 626 owner name for purposes of generating NXT RRs. Wildcard owner names 627 appear in the Next Domain Name field without any wildcard expansion. 628 [11] describes the impact of wildcards on authenticated denial of 629 existence. 631 4.2 The NXT RR Presentation Format 633 The presentation format of the RDATA portion is as follows: 635 The Next Domain Name field is represented as a domain name. 637 The Type Bit Map field is represented either as a sequence of RR type 638 mnemonics or as a sequence of unsigned decimal integers denoting the 639 RR type codes. 641 4.3 NXT RR Example 643 The following NXT RR identifies the RRsets associated with 644 alfa.example.com. and identifies the next authoritative name after 645 alfa.example.com. 647 alfa.example.com. 86400 IN NXT host.example.com. A MX SIG NXT 649 The first four text fields specify the name, TTL, Class, and RR type 650 (NXT). The entry host.example.com. is the next authoritative name 651 after alfa.example.com. (in canonical order). The A, MX, SIG and 652 NXT mnemonics indicate there are A, MX, SIG and NXT RRsets associated 653 with the name alfa.example.com. 655 Note the NXT record can be used for authenticated denial of 656 existence. If the example NXT record were authenticated, it could be 657 used to prove that beta.example.com. does not exist, or could be 658 used to prove there is no AAAA record associated with 659 alfa.example.com. Authenticated denial of existence is discussed in 660 [11] 662 5. The DS Resource Record 664 The DS Resource Record refers to a KEY RR and is used in the DNS KEY 665 authentication process. A DS RR refers to a KEY RR by storing the 666 key tag, algorithm number, and a digest of KEY RR. Note that while 667 the digest should be sufficient to identify the key, storing the key 668 tag and key algorithm helps make the identification process more 669 efficient. By authenticating the DS record, a resolver can 670 authenticate the KEY RR to which the DS record points. The key 671 authentication process is described in [11]. 673 The DS RR and its corresponding KEY RR have the same owner name, but 674 they are stored in different locations. The DS RR appears only on 675 the upper (parental) side of a delegation, and is authoritative data 676 in the parent zone. For example, the DS RR for "example.com" is 677 stored in the "com" zone (the parent zone) rather than in the 678 "example.com" zone (the child zone). The corresponding KEY RR is 679 stored in the "example.com" zone (the child zone). This simplifies 680 DNS zone management and zone signing, but introduces special response 681 processing requirements for the DS RR; these are described in [11]. 683 The type number for the DS record is 43. 685 The DS resource record is class independent. 687 There are no special TTL requirements on the DS resource record. 689 5.1 DS RDATA Wire Format 691 The RDATA for a DS RR consists of 2 octet Key Tag field, a one octet 692 Algorithm field, a one octet Digest Type field, and a Digest field. 694 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Key Tag | Algorithm | Digest Type | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 / / 700 / Digest / 701 / / 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 5.1.1 The Key Tag Field 706 The Key Tag field lists the key tag of the KEY RR referred to by the 707 DS record. The KEY RR MUST be a zone key. The KEY RR Flags MUST 708 have Flags bit 7 set to value 1. 710 The Key Tag used by the DS RR is identical to the Key Tag used by the 711 SIG RR and Appendix B describes how to compute a Key Tag. 713 5.1.2 The Algorithm Field 715 The Algorithm field lists the algorithm number of the KEY RR referred 716 to by the DS record. 718 The algorithm number used by the DS RR is identical to the algorithm 719 number used by the SIG RR and KEY RR. Appendix A.1 lists the 720 algorithm number types. 722 5.1.3 The Digest Type Field 724 The DS RR refers to a KEY RR by including a digest of that KEY RR. 725 The Digest Type field identifies the algorithm used to construct the 726 digest and Appendix A.2 lists the possible digest algorithm types. 728 5.1.4 The Digest Field 730 The DS record refers to a KEY RR by including a digest of that KEY 731 RR. The Digest field holds the digest. 733 The digest is calculated by concatenating the canonical form of the 734 fully qualified owner name of the KEY RR (abbreviated below as "key 735 RR name") with the KEY RDATA, and then applying the digest algorithm. 737 digest = digest_algorithm( KEY RR name | KEY RDATA); 739 "|" denotes concatenation 741 KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key. 743 The size of the digest may vary depending on the digest algorithm and 744 KEY RR size. Currently, the defined digest algorithm is SHA-1, which 745 produces a 20 octet digest. 747 5.2 The DS RR Presentation Format 749 The presentation format of the RDATA portion is as follows: 751 The Key Tag field is represented as an unsigned decimal integer. 753 The Algorithm field is represented either as an unsigned decimal 754 integer or as an algorithm mnemonic specified in Appendix A.1. 756 The Digest Type field is represented as an unsigned decimal integer. 758 The Digest is represented as a sequence of case-insensitive 759 hexadecimal digits. Whitespace is allowed within the hexadecimal 760 text. 762 5.3 DS RR Example 764 The following example shows a KEY RR and its corresponding DS RR. 766 dskey.example.com. 86400 IN KEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz 767 fwJr1AYtsmx3TGkJaNXVbfi/ 768 2pHm822aJ5iI9BMzNXxeYCmZ 769 DRD99WYwYqUSdjMmmAphXdvx 770 egXd/M5+X7OrzKBaMbCVdFLU 771 Uh6DhweJBjEVv5f2wwjM9Xzc 772 nOf+EPbtG9DMBmADjFDc2w/r 773 ljwvFw== 774 ) ; key id = 60485 776 dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A 777 98631FAD1A292118 ) 779 The first four text fields specify the name, TTL, Class, and RR type 780 (DS). Value 60485 is the key tag for the corresponding 781 "dskey.example.com." KEY RR, and value 5 denotes the algorithm used 782 by this "dskey.example.com." KEY RR. The value 1 is the algorithm 783 used to construct the digest, and the rest of the RDATA text is the 784 digest in hexadecimal. 786 6. Canonical Form and Order of Resource Records 788 This section defines a canonical form for resource records, a 789 canonical ordering of DNS names, and a canonical ordering of resource 790 records within an RRset. A canonical name order is required to 791 construct the NXT name chain. A canonical RR form and ordering 792 within an RRset are required to construct and verify SIG RRs. 794 6.1 Canonical DNS Name Order 796 For purposes of DNS security, owner names are ordered by treating 797 individual labels as unsigned left-justified octet strings. The 798 absence of a octet sorts before a zero value octet, and upper case 799 US-ASCII letters are treated as if they were lower case US-ASCII 800 letters. 802 To compute the canonical ordering of a set of DNS names, start by 803 sorting the names according to their most significant (rightmost) 804 labels. For names in which the most significant label is identical, 805 continue sorting according to their next most significant label, and 806 so forth. 808 For example, the following names are sorted in canonical DNS name 809 order. The most significant label is "example". At this level, 810 "example" sorts first, followed by names ending in "a.example", then 811 names ending "z.example". The names within each level are sorted in 812 the same way. 814 example 815 a.example 816 yljkjljk.a.example 817 Z.a.example 818 zABC.a.EXAMPLE 819 z.example 820 \001.z.example 821 *.z.example 822 \200.z.example 824 6.2 Canonical RR Form 826 For purposes of DNS security, the canonical form of an RR is the wire 827 format of the RR where: 829 1. Every domain name in the RR is fully expanded (no DNS name 830 compression) and fully qualified; 832 2. All uppercase US-ASCII letters in the owner name of the RR are 833 replaced by the corresponding lowercase US-ASCII letters; 835 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, 836 HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, 837 SRV, DNAME, or A6, all uppercase US-ASCII letters in the DNS 838 names within the RDATA of the RR are replaced by the 839 corresponding lowercase US-ASCII letters; 841 4. If the owner name of the RR is a wildcard name, the owner name is 842 in its original unexpanded form, including the "*" label (no 843 wildcard substitution); and 845 5. The RR's TTL is set to its original value as it appears in the 846 authoritative zone containing the RR or the Original TTL field of 847 the covering SIG RR. 849 Editors' Note: the above definition sacrifices readability for an 850 attempt at precision. Please send better text! 852 6.3 Canonical RR Ordering Within An RRset 854 For purposes of DNS security, RRs with same owner name, same class, 855 and same type are sorted by sorting the canonical forms of the RRs 856 while treating the RDATA portion of the canonical form of each RR as 857 a left justified unsigned octet sequence. The absence of an octet 858 sorts before the zero octet. 860 7. IANA Considerations 862 This document introduces one new IANA consideration. RFC 2535 [14] 863 created an IANA registry for DNS Security Algorithm Numbers. This 864 document re-assigns DNS Security Algorithm Number 252 to be 865 "reserved". This value is no longer available for assignment by 866 IANA. 868 This document clarifies the use of existing DNS resource records. 869 For completeness, the IANA considerations from the previous documents 870 which defined these resource records are summarized below. No IANA 871 changes are made by this document other than the one change described 872 in the first paragraph of this section. 874 [14] updated the IANA registry for DNS Resource Record Types, and 875 assigned types 24,25, and 30 to the SIG, KEY, and NXT RRs, 876 respectively. [9] assigned DNS Resource Record Type 43 to DS. 878 [14] created an IANA registry for DNSSEC Resource Record Algorithm 879 Numbers. Values to 1-4, and 252-255 were assigned by [14]. Value 5 880 was assigned by [8]. Value 252 is re-assigned by this document, as 881 noted above. 883 [9] created an IANA registry for DNSSEC DS Digest Types, and assigned 884 value 0 to reserved and value 1 to SHA-1. 886 [14] created an IANA Registry for KEY Protocol Values, but [16] re- 887 assigned all assigned values other than 3 to reserved and closed this 888 IANA registry. The registry remains closed, and all KEY records are 889 required to have Protocol Octet value of 3. 891 The Flag bits in the KEY RR are not assigned by IANA, and there is no 892 IANA registry for these flags. All changes to the meaning of the KEY 893 RR Flag bits require a standards action. 895 The meaning of a value of 1 in bit zero of the Type Bit Map of an NXT 896 RR can only be assigned by a standards action. 898 8. Security Considerations 900 This document describes the format of four DNS resource records used 901 by the DNS security extensions, and presents an algorithm for 902 calculating a key tag for a public key. Other than the items 903 described below, the resource records themselves introduce no 904 security considerations. The use of these records is specified in a 905 separate document, and security considerations related to the use 906 these resource records are discussed in that document. 908 The DS record points to a KEY RR using a cryptographic digest, the 909 key algorithm type and a key tag. The DS record is intended to 910 identify an existing KEY RR, but it is theoretically possible for an 911 attacker to generate a KEY that matches all the DS fields. The 912 probability of constructing such a matching KEY depends on the type 913 of digest algorithm in use. The only currently defined digest 914 algorithm is SHA-1, and the working group believes that constructing 915 a public key which would match the algorithm, key tag, and SHA-1 916 digest given in a DS record would be a sufficiently difficult problem 917 that such an attack is not a serious threat at this time. 919 The key tag is used to help select KEY resource records efficiently, 920 but it does not uniquely identify a single KEY resource record. It 921 is possible for two distinct KEY RRs to have the same owner name, the 922 same algorithm type, and the same key tag. An implementation which 923 used only the key tag to select a KEY RR might select the wrong 924 public key in some circumstances. Implementations MUST NOT assume 925 the key tag is unique public key identifier; this is clearly stated 926 in Appendix B. 928 9. Acknowledgments 930 This document was created from the input and ideas of several members 931 of the DNS Extensions Working Group and working group mailing list. 932 The co-authors of this draft would like to express their thanks for 933 the comments and suggestions received during the revision of these 934 security extension specifications. 936 Normative References 938 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 939 13, RFC 1034, November 1987. 941 [2] Mockapetris, P., "Domain names - implementation and 942 specification", STD 13, RFC 1035, November 1987. 944 [3] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail 945 Extensions) Part One: Mechanisms for Specifying and Describing 946 the Format of Internet Message Bodies", RFC 1521, September 947 1993. 949 [4] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 950 August 1996. 952 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 953 Levels", BCP 14, RFC 2119, March 1997. 955 [6] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, 956 August 1999. 958 [7] Eastlake, D., "DNS Request and Transaction Signatures ( 959 SIG(0)s)", RFC 2931, September 2000. 961 [8] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 962 System (DNS)", RFC 3110, May 2001. 964 [9] Gudmundsson, O., "Delegation Signer Resource Record", draft- 965 ietf-dnsext-delegation-signer-12 (work in progress), December 966 2002. 968 [10] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, 969 "DNS Security Introduction and Requirements", draft-ietf- 970 dnsext-dnssec-intro-05 (work in progress), February 2003. 972 [11] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, 973 "Protocol Modifications for the DNS Security Extensions", 974 draft-ietf-dnsext-dnssec-protocol-00 (work in progress), 975 Februari 2003. 977 [12] Gustafsson, A., "Handling of Unknown DNS RR Types", draft-ietf- 978 dnsext-unknown-rrs-04 (work in progress), September 2002. 980 [13] Kosters, M., Blacka, D. and R. Arends, "DNSSEC Opt-in", draft- 981 ietf-dnsext-dnssec-opt-in-04 (work in progress), February 2003. 983 Informative References 985 [14] Eastlake, D., "Domain Name System Security Extensions", RFC 986 2535, March 1999. 988 [15] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 989 2930, September 2000. 991 [16] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource 992 Record (RR)", RFC 3445, December 2002. 994 Authors' Addresses 996 Roy Arends 997 Telematica Instituut 998 Drienerlolaan 5 999 7522 NB Enschede 1000 NL 1002 EMail: roy.arends@telin.nl 1004 Rob Austein 1005 Internet Software Consortium 1006 40 Gavin Circle 1007 Reading, MA 01867 1008 USA 1010 EMail: sra@isc.org 1012 Matt Larson 1013 VeriSign, Inc. 1014 21345 Ridgetop Circle 1015 Dulles, VA 20166-6503 1016 USA 1018 EMail: mlarson@verisign.com 1020 Dan Massey 1021 USC Information Sciences Institute 1022 3811 N. Fairfax Drive 1023 Arlington, VA 22203 1024 USA 1026 EMail: masseyd@isi.edu 1027 Scott Rose 1028 National Institute for Standards and Technology 1029 100 Bureau Drive 1030 Gaithersburg, MD 20899-8920 1031 USA 1033 EMail: scott.rose@nist.gov 1035 Appendix A. DNSSEC Algorithm and Digest Types 1037 The DNS security extensions are designed to be independent of the 1038 underlying cryptographic algorithms. The KEY, SIG, and DS resource 1039 records all use a DNSSEC Algorithm Number to identify the 1040 cryptographic algorithm in use by the resource record. The DS 1041 resource record also specifies a Digest Algorithm Number to identify 1042 the digest algorithm used to construct the DS record. The currently 1043 defined Algorithm and Digest Types are listed below. Additional 1044 Algorithm or Digest Types could be added as advances in cryptography 1045 warrant. 1047 A DNSSEC aware resolver or name server MUST implement all MANDATORY 1048 algorithms. 1050 A.1 DNSSEC Algorithm Types 1052 An "Algorithm Number" field in the KEY, SIG, and DS resource record 1053 types identifies the cryptographic algorithm used by the resource 1054 record. Algorithm specific formats are described in separate 1055 documents. The following table lists the currently defined algorithm 1056 types and provides references to their supporting documents: 1058 VALUE Algorithm RFC STATUS 1059 0 Reserved - - 1060 1 RSA/MD5 RFC 2537 NOT RECOMMENDED 1061 2 Diffie-Hellman RFC 2539 OPTIONAL 1062 3 DSA RFC 2536 OPTIONAL 1063 4 elliptic curve TBA OPTIONAL 1064 5 RSA/SHA1 RFC 3110 MANDATORY 1065 6-251 available for assignment - 1066 252 reserved - 1067 253 private see below OPTIONAL 1068 254 private see below OPTIONAL 1069 255 reserved - - 1071 A.1.1 Private Algorithm Types 1073 Algorithm number 253 is reserved for private use and will never be 1074 assigned to a specific algorithm. The public key area in the KEY RR 1075 and the signature area in the SIG RR begin with a wire encoded domain 1076 name. Only local domain name compression is permitted. The domain 1077 name indicates the private algorithm to use and the remainder of the 1078 public key area is determined by that algorithm. Entities should 1079 only use domain names they control to designate their private 1080 algorithms. 1082 Algorithm number 254 is reserved for private use and will never be 1083 assigned to a specific algorithm. The public key area in the KEY RR 1084 and the signature area in the SIG RR begin with an unsigned length 1085 byte followed by a BER encoded Object Identifier (ISO OID) of that 1086 length. The OID indicates the private algorithm in use and the 1087 remainder of the area is whatever is required by that algorithm. 1088 Entities should only use OIDs they control to designate their private 1089 algorithms. 1091 A.2 DNSSEC Digest Types 1093 A "Digest Type" field in the DS resource record types identifies the 1094 cryptographic digest algorithm used by the resource record. The 1095 following table lists the currently defined digest algorithm types. 1097 VALUE Algorithm STATUS 1098 0 Reserved - 1099 1 SHA-1 MANDATORY 1100 2-255 Unassigned - 1102 Appendix B. Key Tag Calculation 1104 The Key Tag field in the SIG and DS resource record types provides a 1105 mechanism for selecting a public key efficiently. In most cases, a 1106 combination of owner name, algorithm, and key tag can efficiently 1107 identify a KEY record. Both the SIG and DS resource records have 1108 corresponding KEY records. The Key Tag field in the SIG and DS 1109 records can be used to help select the corresponding KEY RR 1110 efficiently when more than one candidate KEY RR is available. 1112 However, it is essential to note that the key tag is not a unique 1113 identifier. It is theoretically possible for two distinct KEY RRs to 1114 have the same owner name, the same algorithm, and the same key tag. 1115 The key tag is used to limit the possible candidate keys, but it does 1116 not uniquely identify a KEY record. Implementations MUST NOT assume 1117 that the key tag uniquely identifies a KEY RR. 1119 The key tag is the same for all KEY algorithm types except algorithm 1120 1 (please see Appendix B.1 for the definition of the key tag for 1121 algorithm 1). For all algorithms other than algorithm 1, the key tag 1122 is defined to be the output which would be generated by running the 1123 ANSI C function shown below with the RDATA portion of the KEY RR as 1124 input. It is not necessary to use the following reference code 1125 verbatim, but the numerical value of the Key Tag MUST be identical to 1126 what the reference implementation would generate for the same input. 1128 Please note that the algorithm for calculating the Key Tag is almost 1129 but not completely identical to the familiar ones complement checksum 1130 used in many other Internet protocols. Key Tags MUST be calculated 1131 using the algorithm described below rather than the ones complement 1132 checksum. 1134 The following ANSI C reference implementation calculates the value of 1135 a Key Tag. This reference implementation applies to all algorithm 1136 types except algorithm 1 (see Appendix B.1). The input is the wire 1137 format of the RDATA portion of the KEY RR. The code is written for 1138 clarity, not efficiency. 1140 /* 1141 * Assumes that int is at least 16 bits. 1142 * First octet of the key tag is the most significant 8 bits of the 1143 * return value; 1144 * Second octet of the key tag is the least significant 8 bits of the 1145 * return value. 1146 */ 1148 unsigned int 1149 keytag ( 1150 unsigned char key[], /* the RDATA part of the KEY RR */ 1151 unsigned int keysize /* the RDLENGTH */ 1152 ) 1153 { 1154 unsigned long ac; /* assumed to be 32 bits or larger */ 1155 int i; /* loop index */ 1157 for ( ac = 0, i = 0; i < keysize; ++i ) 1158 ac += (i & 1) ? key[i] : key[i] << 8; 1159 ac += (ac >> 16) & 0xFFFF; 1160 return ac & 0xFFFF; 1161 } 1163 B.1 Key Tag for Algorithm 1 (RSA/MD5) 1165 The key tag for algorithm 1 (RSA/MD5) is defined differently than the 1166 key tag for all other algorithms, for historical reasons. For a KEY 1167 RR with algorithm 1, the key tag is defined to be the most 1168 significant 16 bits of the least significant 24 bits in the public 1169 key modulus (in other words, the 4th to last and 3rd to last octets 1170 of the public key modulus). 1172 Please note that Algorithm 1 is NOT RECOMMENDED. 1174 Full Copyright Statement 1176 Copyright (C) The Internet Society (2003). All Rights Reserved. 1178 This document and translations of it may be copied and furnished to 1179 others, and derivative works that comment on or otherwise explain it 1180 or assist in its implementation may be prepared, copied, published 1181 and distributed, in whole or in part, without restriction of any 1182 kind, provided that the above copyright notice and this paragraph are 1183 included on all such copies and derivative works. However, this 1184 document itself may not be modified in any way, such as by removing 1185 the copyright notice or references to the Internet Society or other 1186 Internet organizations, except as needed for the purpose of 1187 developing Internet standards in which case the procedures for 1188 copyrights defined in the Internet Standards process must be 1189 followed, or as required to translate it into languages other than 1190 English. 1192 The limited permissions granted above are perpetual and will not be 1193 revoked by the Internet Society or its successors or assigns. 1195 This document and the information contained herein is provided on an 1196 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1197 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1198 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1199 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1200 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1202 Acknowledgement 1204 Funding for the RFC Editor function is currently provided by the 1205 Internet Society.