idnits 2.17.1 draft-moreau-dnsext-takrem-dns-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 37. -- Found old boilerplate from RFC 3978, Section 5.5 on line 732. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 701. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 707. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 498 -- Looks like a reference, but probably isn't: '1' on line 533 -- Looks like a reference, but probably isn't: '2' on line 498 == Missing Reference: 'RC2459' is mentioned on line 552, but not defined ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Thierry Moreau 2 Document: draft-moreau-dnsext-takrem-dns-02.txt CONNOTECH 3 Category: Informational April, 2006 4 Expires: October, 2006 6 The Trust Anchor Key Renewal Method 7 Applied to DNS Security (TAKREM-DNSSEC) 9 Status of this Memo 11 Internet-Drafts are working documents of the Internet Engineering 12 Task Force (IETF), its areas, and its working groups. Note that 13 other groups may also distribute working documents as 14 Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet-Drafts 19 as reference material or to cite them other than as "work in 20 progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/1id-abstracts.html 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Copyright Notice 30 Copyright (C) The Internet Society (2006). 32 IPR Disclosure Acknowledgment 34 By submitting this Internet-Draft, each author represents that any 35 applicable patent or other IPR claims of which he or she is aware 36 have been or will be disclosed, and any of which he or she becomes 37 aware will be disclosed, in accordance with Section 6 of BCP 79. 39 Abstract 41 This document provides an authentication scheme based on the 42 generic SDDA-RR mechanism (SEP DNSKEY Direct Authenticator DNS 43 Resource Record). The result is an automated key rollover mechanism 44 for trust anchor keys. This represents additional security protocol 45 elements to the DNS Security Extensions (DNSSEC) in the area of key 46 management support functions for the DNS root zone and islands of 47 trust. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Document Organization . . . . . . . . . . . . . . . . . . . 4 54 2. Initial Procedures for the Use of TAKREM in the DNSSEC . . . . . . 4 55 2.1 Initial Generation of Trust Anchor Keys . . . . . . . . . . 4 56 2.2 Initial Trust Anchor Key Distribution . . . . . . . . . . . 5 58 3. Trust Anchor Key Rollover Overview . . . . . . . . . . . . . . . . 5 59 3.1 Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Detailed Zone Management Processing for Trust Anchor Key Rollover 7 62 4.1 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.2 Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 7 65 5. Resolver Procedures for Trust Anchor Key Rollover . . . . . . . . 8 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 9 71 Appendix A - Synopsis of the TAKREM Security Procedure . . . . . . . 10 73 Appendix B - Hash Function Input Stream Details . . . . . . . . . . . 12 75 Normative References . . . . . . . . . . . . . . . . . . . . . . . . 14 77 Informative References . . . . . . . . . . . . . . . . . . . . . . . 14 79 Document Revision History . . . . . . . . . . . . . . . . . . . . . . 14 80 From revision -01 to revision -02 . . . . . . . . . . . . . . . 15 81 From revision -00 to revision -01 . . . . . . . . . . . . . . . 15 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 Intellectual Property . . . . . . . . . . . . . . . . . . . . . 16 87 Derivative Works Limitation . . . . . . . . . . . . . . . . . . 16 88 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . 16 89 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 The DNS security protocol ([RFC4033], [RFC4034], and [RFC4035]) is 94 intended to provide DNS data assurance using a "chain of trust" 95 where the links are public key cryptography digital signatures, and 96 with a "trust anchor" is tied to one end of the chain. A trust 97 anchor is a public signature key associated with an "island of 98 trust" or the DNS root. Trust anchor key rollover relates to the 99 need to change the KSK (Key Singing Key) of a DNSSEC-aware DNS zone 100 when the parent zone is DNSSEC-oblivious or absent (i.e. 101 respectively an island of trust or the DNS root). The present 102 document addresses trust anchor key distribution issues, and 103 provides an automated rollover mechanism for trust anchor keys. 105 The technological capability specified herein rests on four 106 foundations: 107 o the DNS security protocol itself ([RFC4033], [RFC4034], and 108 [RFC4035]), 109 o the operational guidelines for the DNS security protocol 110 ([RFC2541bis]), 111 o the SEP DNSKEY Direct Authenticator resource record (SDDA-RR) 112 specification ([SDDA-RR]), and 113 o additional security principles and formal specifications 114 related to cryptographic mechanisms, including references 115 [ASN1-DER], [RFC2459], and [ISO10118-4]. 116 The present document makes contributions in two directions: 117 o a mix of formal protocol interoperability provisions and less 118 formal operational guidelines, where the security foundation 119 rests on proper performance of both, in contrast to the 120 limited scope on-the-wire protocol compliance, and 121 o formal provisions for cryptographic processing, allowing the 122 security-related computations to succeed in encoding trust 123 information (by DNS zone managers) and validating compliant 124 encoded trust information (in DNS resolvers). 125 Strictly speaking, the present document contains no protocol 126 provision impacting interoperability for DNS protocol entities not 127 involved in the present automated trust anchor key rollover scheme. 128 See also the reference [SDDA-RR], in which interoperability issues 129 are addressed, e.g. between different trust anchor key management 130 schemes based on the SDDA resource record. 132 Otherwise, it would be a double-sided sword to use the [RFC2119] 133 terminology to specify compliance in the present document. Doing so 134 might allow an implementation to claim "compliance to a security 135 standard for trust anchor key" while in fact the confidence in a 136 trust anchor key will systematically depend on operational 137 procedures. Moreover, trust anchor key rollover procedures are 138 spread across the nameserver and resolver dichotomy, and the 139 respective security principles should be analyzed in isolation. 140 Accordingly, the present document writing style avoids specifying 141 what actually allows a resolver to accept a trust anchor key, which 142 is nonetheless the stated goal of an automated trust anchor key 143 rollover scheme. 145 1.1 Document Organization 147 The normative appendix A specifies the TAKREM security procedure, 148 which is the security foundation for the present document. The 149 adaptation to the DNSSEC trust anchor rollover operation is covered 150 in the main part of the document. 152 The TAKREM procedure requires adaptations to the generation of an 153 initial trust anchor key, which is covered in section 2 in the case 154 of DNSSEC. These key generation provisions define some trust anchor 155 key initialization (TAK-i) data to be configured in DNS resolvers 156 as a preliminary, out-of-band procedure. 158 The rollover operation itself is first described in section 3. 160 The TAKREM procedure implies the publication of a "TAKREM rollover 161 message," which turns into inserting specialized DNS resource 162 records as explained in section 4. 164 The rollover operation is completed with the relying party 165 validation of the TAKREM rollover message, which turns into DNS 166 resolver provisions in section 5. 168 Unambiguous input format specification is critical to 169 interoperability of cryptographic integrity mechanisms. The 170 normative appendix B specifies the required unambiguous input 171 format for the TAKREM procedure. The type of specifications in 172 appendix B occurs in section 5.3.2. in [RFC4035], in this case for 173 unambiguous input to a digital signature algorithm in the DNSSEC 174 protocol itself. 176 2. Initial Procedures for the Use of TAKREM in the DNSSEC 178 2.1 Initial Generation of Trust Anchor Keys 180 The secure generation of signature key pairs by zone managers is an 181 implicit procedural requirement for support of the DNSSEC 182 specifications. While the original DNSSEC requires a single 183 signature key pair to be generated (appendix A notation 184 ""), the present document assumes that a different 185 procedure is being followed. Specifically, the TAKREM procedure 186 requires the initial generation of a series of future signature key 187 pairs (appendix A notation "" for "0"). Bar code printouts in tamper-evident 200 sealed envelopes appears as a suitable storage media for storage of 201 individual key pairs in separate components. The term "dead 202 storage" applies to this storage type because the cryptographic key 203 material is remote from any live digital computing device. 205 2.2 Initial Trust Anchor Key Distribution 207 With the original DNSSEC, the signature public key (appendix A 208 notation "R[0]") is initially distributed with the domain name as 209 the initial trust anchor key, and the signature private key 210 (appendix A notation "r[0]") is put into production (e.g. to sign 211 ZSK DNSKEY resource records). 213 Initial trust anchor distribution mechanisms are outside of the 214 DNSSEC specifications. The TAKREM proposal does not change this. 215 However, the initial trust anchor configuration data (appendix A 216 notation "R[0]") is replaced by an integer reference number "f" and 217 the series of cryptographic hash code values. The integer reference 218 number "f" is a 32-bit value. For a given domain name, the integer 219 value range from "f+1" to "f+n" should not be re-used by another 220 initial trust anchor configuration. 222 In summary, in a resolver the initial trust anchor configuration is 223 received as TAK-i data comprising, for each domain name subject to 224 the present automated rollover scheme: 225 1) the domain name, 226 2) a series of cryptographic hash code values (appendix A 227 notation "D[1], D[2], ..., D[n]"), and 228 3) a 32-bit integer reference value "f". 229 No special attention is paid to the hash code values and the 230 reference at this initial configuration time: they are simply kept 231 for later reference. At a later time, the resolver is able to 232 support the automated trust anchor key rollover procedure specified 233 in the following document section. 235 3. Trust Anchor Key Rollover Overview 237 For trust anchor key rollover, the present document specifies that 238 the new signature key pair (appendix A notation "" for 239 some "i" in the range "0") and sets 260 a) the new signature private key (appendix A notation 261 "r[i]") in the protected computing environment used for 262 generating zone digital signatures, 263 b) the new signature public key (appendix A notation "R[i]") 264 in a DNSKEY resource record, and 265 c) the key tag for the new signature public key and the 266 other TAKREM rollover message elements (appendix A 267 notation ""), plus the value "f+i", 268 where "f" is the 32-bit reference described in the above 269 subsection 2.2, in an SDDA resource record. 270 The zone manager includes the new DNSKEY record and the SDDA 271 record targeting it in the zone data at the same zone version 272 update. Obituary SDDA RRs may be added to signal or confirm 273 the expiry of a DNSKEY RR that is no longer present in the 274 DNSKEY RRset, or should never be present (obituary SDDA RRs 275 are defined in section 2.2.5 of [SDDA-RR]). Furthermore, the 276 zone signing operation must include an RRSIG record targeting 277 the SDDA RRset and using the new signature key. There are 278 mandatory provisions in section 2.4 of [SDDA-RR] for the 279 simultaneous publication of such DNSKEY, SDDA, and RRSIG 280 records. The simultaneous publication of these records in a 281 zone data completes the zone manager duties specific to a 282 trust anchor key rollover operation according to the present 283 authentication scheme. 285 o The second phase is the new KSK usage in DNS zone signing 286 according to DNSSEC specifications. If the new DNSKEY record 287 is to be authenticated also by a parental DS record, this 288 second phase may be delayed until this DS record has been 289 included in the parental zone. 291 o The third phase is run by resolvers having received the TAK-i 292 data configuration for this domain name. This is specified in 293 section 5. 295 3.1 Usage Scenarios 297 The manager of an island of trust or the DNS root can use the 298 present authentication scheme for trust anchor rollover, provided 299 the TAK-i data distribution was done according to the above 300 subsection 2.2. 302 A normal secure child zone may also use the present rollover 303 scheme, e.g. if it is suspected that some DNS resolver would not 304 have a trust anchor for validating the parent zone signatures. 306 In any case, only the DNS resolvers having been configured with the 307 TAK-i data for a domain name can authenticate its trust anchor 308 using the present authentication scheme. 310 4. Detailed Zone Management Processing for Trust Anchor Key Rollover 312 4.1 Procedures 314 This section specifies how a zone manager creates at once the SDDA 315 record and the targeted DNSKEY record for a trust anchor key 316 rollover. The DNSKEY record must have both the "Zone Key" and 317 "Secure Entry Point" flags set to 1. The lifetime of an SDDA record 318 should be the same as the one in the targeted DNSKEY. 320 The intended cryptoperiod for the DNSKEY signature public key 321 should be reflected in the SDDA record field pair for 322 Authentication Expiration and Authentication Inception. 323 Specifically, after the earliest SDDA expiration time ever 324 published for a given target DNSKEY signature public key, the zone 325 manager must not reuse the same signature public key value again. 326 Likewise, before the latest inception time ever published for a 327 given target DNSKEY signature public key, the zone manager must not 328 use the signature public key. 330 The DNS publication of the DNSKEY and SDDA records create or 331 augment corresponding RRsets. The RRSIG signatures for these DNSKEY 332 and SDDA RRsets are specified respectively in section 2.2 of 333 [RFC4035], and in section 2.4 of [SDDA-RR]. 335 4.2 Data Formats 337 This section specifies the TAKREM application of SDDA RR wire 338 format and formation, using the notation from appendix A. The 339 generic provisions of [SDDA-RR] apply to the SDDA record formation 340 and the targeting to the appropriate DNSKEY record. 342 The SDDA RR Authentication Mechanism Type field ([SDDA-RR] section 343 2.2.3) must contain 1 for the present document to apply. 345 The SDDA RR Authentication Context Type field ([SDDA-RR] section 346 2.2.4) should be 2 or 0. 347 o When this field value is 2, the 32-bits opaque value in the 348 Authentication Context Data field must hold the value "f+i". 349 From the value "f+i", a resolver can efficiently identify a 350 most probable candidate digest "D[i]" for TAKREM hash code 351 validation. 352 o When the Authentication Context Type field is 0, the SDDA RR 353 Authentication Context Data field is absent. 354 o Other Authentication Context Type values may be used provided 355 a prior arrangement allowing relying parties to identify the 356 relevant initial trust anchor configuration. 358 The SDDA RR must contain one set of Algorithm-Related fields 359 ([SDDA-RR] section 2.2.10). For the Authentication Algorithm Type 360 field ([SDDA-RR] section 2.2.10.1) within this set, the currently 361 allocated values are 362 o 1: MASH-1 as defined in [ISO10118-4], and 363 o 2: MASH-2 as defined in [ISO10118-4], 364 encoded as a single octet binary field value. 366 Two MASH parameters, respectively "N[i]", a large composite number 367 of unknown factorization, and "p[i]", a large prime number, 368 populate the Authentication Algorithm Common Parameters field 369 ([SDDA-RR] section 2.2.10.2) in the SDDA RR wire format. Each of 370 "N[i]" and "p[i]" is encoded as a variable length unsigned integer 371 prefixed by a length indication: the unsigned integer length in 372 octets is represented as one octet if it is in the range of 1 to 373 255 and by a zero octet followed by a two octet length if it is 374 longer than 255 bytes. Leading zero bytes should be omitted from 375 the unsigned integer representation. 377 The SDDA RR Authentication Mechanism Data field ([SDDA-RR] section 378 2.2.11) comprises a length indication as in the preceding paragraph 379 holding the length (octet count) of the TAKREM rollover message 380 salt field "s[i]", followed by an octet stream of this length, 381 encoding this salt field in binary form. The encoded salt may 382 contain leading zeroes. 384 5. Resolver Procedures for Trust Anchor Key Rollover 386 The present authentication scheme uses the generic DNS rollover 387 procedures specified in section 3 of reference [SDDA-RR]. The 388 present document section provides the required details for a 389 complete DNS resolver procedure specifications. 391 A resolver may process an SDDA record by first matching the DNSKEY 392 record pointed by the SDDA record, then reconstructing a TAKREM 393 digest from the DNSKEY and SDDA record, and finally checking the 394 presence of an identical digest value "D[i]" among the TAK-i data 395 that the resolver may have accepted as part of trusted 396 configuration. 398 As can be inferred from other portions of this document, a resolver 399 should validate the authenticity of a DNS resource record pair SDDA 400 plus linked DNSKEY with the SDDA having an Authentication Mechanism 401 Type set to 1 as if they provide a TAKREM rollover message. This 402 validation is based on a number of data elements: 403 o the DNSKEY RR linked to the SDDA RR, providing the public key 404 component "R[i]" of the TAKREM MASH input stream (in the case 405 of an obituary SDDA RR, the DNSKEY value is taken from the DNS 406 resolver state information), 407 o the field contents from the SDDA RR Authentication Mechanism 408 Data field, providing the salt component "s[i]" of the TAKREM 409 MASH input stream, and 410 o the two large integer values from the SDDA RR Authentication 411 Algorithm Common Parameters field, providing the MASH 412 parameters "N[i]" and "p[i]", thus revealing the specific MASH 413 function used in the computation of the hash code outputs in 414 the TAK-i data configuration, 415 from which a TAKREM MASH input stream must be reconstructed 416 according to appendix B, using values "s[i]", "R[i]", "N[i]", 417 "p[i]". Then the resolver computes a TAKREM rollover message hash 418 code according to the integer value from the Authentication 419 Algorithm Type field (either 1 or 2), providing the selection among 420 the MASH-1 and MASH-2 variants. Finally, the computed message hash 421 code is checked for equality with any of the trusted digests "D[i]" 422 from the initial TAK-i data configurations associated with the 423 relevant domain name. If the SDDA RR Authentication Context Type 424 field holds the value 2, the SDDA RR Authentication Context Data 425 field provides a 32-bit reference value "f+i" that provides a hint 426 for selecting a candidate digest "D[i]". If no matching trusted 427 digests "D[i]" can be found, the resolver should abstain from 428 granting a trust anchor status to the DNSKEY record (or an obituary 429 SDDA RR should be considered bogus). 431 6. Security Considerations 433 The TAKREM security effectiveness rests more on end-to-end 434 cryptographic properties than on particulars of DNS protocol 435 operations. 437 The malicious parties will typically attempt to circumvent the 438 cryptographic computations, notably by exploiting mishaps in manual 439 procedures (e.g. attempting to read a signature private key file) 440 or in implementation weaknesses (e.g. inadequate integrity 441 protection of resolver configuration). 443 7. IANA Considerations 445 The present document provides a specification for the 446 authentication scheme identified by the value "1" in the SDDA 447 record Authentication Mechanism Type field. The SDDA record 448 Authentication Mechanism Type name space is created in the 449 reference [SDDA-RR], where the assigned value "1" registration is 450 originally requested. 452 There are no additional IANA considerations. 454 Appendix A - Synopsis of the TAKREM Security Procedure 456 In this appendix, the TAKREM security procedure is described 457 without reference to the DNS protocols. This appendix is normative. 459 The purpose of any key management scheme is to preserve the 460 cryptographic properties of algorithms. For TAKREM, this is further 461 covered in reference [CONNOTECH]. 463 We use the notation "R[i]" for the public trust anchor key "R[i]", 464 with the private key counterpart "r[i]". 466 The zone owner establishes key pairs "", "", 467 "", ..., "", allocating the pair 468 "" as the initial trust anchor key pair, and reserving 469 each key pairs "" for the cryptoperiod starting with the 470 "i"'th trust anchor renewal, for "1<=i<=n". 472 Actually, the initial key pair "" is not essential; the 473 DNS resolver may bootstrap with the validation of the key pair 474 "" using the normal TAKREM rollover validation 475 procedure. The initial key pair "" is mentioned to 476 relate the TAKREM description to the prior procedure of manual 477 trust anchor key configuration. 479 A separate MASH (Modular Arithmetic Secure Hash) instance "H[i]" is 480 created for each "R[i]". MASH is defined in International standard 481 document ISO/IEC 10118-4:1998 ([ISO10118-4]). 483 That is, the zone owner selects a large composite modulus number 484 "N[i]" used in the MASH round function and a prime number "p[i]" 485 used in the MASH final reduction function. 487 Then, the zone owner selects a random salt field "s[i]". 489 A hash computation gives a root key digest "D[i]" : 490 "D[i]=H[i](s[i]|R[i]|N[i]|P[i])" . 491 The digest "D[i]" is like an advanced notice of future trust anchor 492 key "R[i]". 494 The data tuple "" is set aside in dead 495 storage. 497 The trust anchor key initial distribution is 498 "R[0], D[1], D[2], ..., D[n]" . 500 Security rationale: with data tuple "" 501 totally concealed until the usage period for key pair 502 "", an adversary is left with the digest "D[i]" from 503 which it is deemed impossible to mount a brute force attack. 505 A trust anchor key rollover is triggered by a rollover message 506 carrying the following information: 507 "i," . 509 Upon receipt of this message, the DNS resolver becomes in a 510 position to validate the trust anchor key digest "D[i]". 512 Appendix B - Hash Function Input Stream Details 514 This appendix is normative. 516 The TAKREM rollover message processing requires the unambiguous 517 definition of a cryptographic hash function input stream in a 518 format not necessarily typical of the DNS RR formatting rules. The 519 input format is based on the ASN.1 distinguished encoring rules 520 [ASN1-DER]. The input format is based on the X.509 public key 521 encoding standard. In addition to providing an unambiguous 522 canonical encoding, this approach supports the inclusion of new 523 digital signature algorithms in the initial TAK-i data 524 configuration. 526 The TAKREM MASH input stream to be (re)constructed is the ASN.1 DER 527 encoding for a value of the ASN.1 type defined as: 529 SEQUENCE { 530 OCTET STRING SIZE(20..MAX), 531 -- salt field "s[i]", SDDA RR 532 -- Authentication Mechanism Data field 533 [1] IMPLICIT SEQUENCE { -- SubjectPublicKeyInfo "R[i]" 534 -- in RFC2459 535 SEQUENCE { -- AlgorithmIdentifier in RFC2459 536 algorithm OBJECT IDENTIFIER, 537 parameters ANY DEFINED BY algorithm OPTIONAL 538 } 539 subjectPublicKey BIT STRING 540 -- public key encoded as a "subjectPublicKey" 541 -- per RFC 2459, or per encoding rules for the 542 -- subject public key algorithm 543 } 544 INTEGER, -- the MASH parameter "N[i]" 545 INTEGER -- the MASH parameter "p[i]" 546 } 548 In (re)constructing the MASH input stream, the ASN.1 encoding shall 549 omit the optional fields that are "witness values" that allow 550 verification of either number-theoretic properties intrinsic to the 551 public key value, or the unbiased selection of random public key 552 parameters (e.g. in [RC2459] for the Diffie-Hellman cryptosystem). 553 Such fields may occur in the "parameters" ASN.1 field above, and/or 554 in the "subjectPublicKey" ASN.1 field above 556 Other optional fields should be provided in the ASN.1 encoding of a 557 public key. Some optional fields are required for the complete 558 knowledge of a public key value and must be retained (e.g. the 559 three DSA common parameters are required even if they are encoded 560 in an optional field of an ASN.1 sequence). In the case of RSA 561 public keys, the X.509 mandates a NULL field in the 562 AlgorithmIdentifier ASN.1 structure, which must be retained 563 according to the present specification. 565 In doing the above encoding conversion from the DNS encoding to 566 ASN.1 encoding inspired from the X.509 specifications, the public 567 key information is stripped of some usage control data. That is, a 568 given type of public key might be allowable with a number of 569 digital signature algorithms. The TAKREM mechanism specified in the 570 body of this document protects the public key value with the type 571 of public key, but not with a specific digital signature algorithm. 572 Specifically, this allows RSA public keys to be used in the future 573 with hash algorithms different from SHA-1, but also omit to protect 574 against the use of weaker algorithms once stronger algorithms are 575 deployed. 577 The current digital signature algorithms allowed for DNS zone 578 signing are limited to RSA and DSA, plus the unspecified private 579 algorithms. For RSA (resp. DSA), the ASN.1 encoding specification 580 is in section 7.3.1 (resp. 7.3.3) in [RFC2459]. For private 581 algorithms, a similar public key encoding specification should be 582 relied upon. 584 Normative References 586 [ASN1-DER] International Standard ISO/IEC 8825-1, ITU-T 587 Recommendation X.690, "Information technology ASN.1 588 encoding rules: Specification of Basic Encoding Rules 589 (BER), Canonical Encoding Rules (CER) and Distinguished 590 Encoding Rules (DER)", July 2002 592 [ISO10118-4] International standard document ISO/IEC 10118-4:1998, 593 "Information technology - Security techniques - 594 Hash-functions - Part 4: Hash-functions using modular 595 arithmetic" 597 [RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public 598 Key Infrastructure Certificate and CRL Profile", RFC 2459, 599 January 1999 601 [RFC4033] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, "DNS 602 Security Introduction and Requirements", RFC 4033, March 2005 604 [RFC4034] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, 605 "Resource Records for the DNS Security Extensions", RFC 4034, 606 March 2005 608 [RFC4035] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, 609 "Protocol Modifications for the DNS Security Extensions", 610 RFC 4035, March 2005 612 [SDDA-RR] T. Moreau, "The SEP DNSKEY Direct Authenticator DNS Resource 613 Record (SDDA-RR)", work-in-progress, Internet Draft 614 draft-moreau-dnsext-sdda-rr-02.txt, April 2006 616 Informative References 618 [CONNOTECH] Thierry Moreau, "A Note About Trust Anchor Key 619 Distribution", CONNOTECH Experts-conseils inc., Document 620 Number C003444, 2005/07/05, 621 http://www.connotech.com/takrem.pdf 623 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement 624 Levels", RFC2119, March 1997 626 [RFC2541bis] O. Kolkman, R. Gieben, "DNSSEC Operational Practices", 627 [[Internet-Draft 628 draft-ietf-dnsop-dnssec-operational-practices-08.txt, 629 March 6, 2006, approved for RFC publication obsoleting 630 RFC2541]] 632 Document Revision History 634 [[This document section to be removed upon RFC publication.]] 636 >From revision -01 to revision -02 638 Major document editing with some technical changes and corrections, 639 including: 641 a) Document made informational instead of standard track, made 642 explicit the non-use of RFC2119 keywords, and indicated the 643 explicit avoidance of a basis for compliance statements (in 644 revised introduction text). 646 b) Moved some provisions about resolver process to the [SDDA-RR] 647 document. 649 c) Removed text that provided some design rationales. 651 d) Removed the initial public key "R[0]" in the TAK-i 652 configuration, avoiding a design bug, i.e. the lack of 653 expiration time and obituary capability for public key "R[0]" 654 (left public key "R[0]" in the text it as a tutorial 655 convenience). 657 e) Fixed a design bug with the introduction of the obituary SDDA, 658 luckily with no impact on services provided by the TAKREM for 659 DNSSEC scheme. 661 f) The IANA considerations were stipulated as emty. 663 >From revision -00 to revision -01 665 a) Changed the encoding for "N[i]", "p[i]", "s[i]" in section 666 4.2, making it alike the RSA public key exponent encoding in 667 DNSKEY RR. 669 b) Alignments with the technical changes in the revision -01 of 670 [SDDA-RR]. 672 c) Minor editorial clarifications and corrections. 674 Author's Address 676 Thierry Moreau 677 CONNOTECH Experts-conseils inc. 678 9130 Place de Montgolfier 679 Montreal, Qc, Canada 680 Tel.: +1-514-385-5691 681 e-mail: thierry.moreau@connotech.com 683 IPR Notices 685 Intellectual Property 687 The IETF takes no position regarding the validity or scope of any 688 Intellectual Property Rights or other rights that might be claimed 689 to pertain to the implementation or use of the technology described 690 in this document or the extent to which any license under such 691 rights might or might not be available; nor does it represent that 692 it has made any independent effort to identify any such rights. 693 Information on the ISOC's procedures with respect to rights in ISOC 694 Documents can be found in BCP 78 and BCP 79. 696 Copies of IPR disclosures made to the IETF Secretariat and any 697 assurances of licenses to be made available, or the result of an 698 attempt made to obtain a general license or permission for the use 699 of such proprietary rights by implementers or users of this 700 specification can be obtained from the IETF on-line IPR repository 701 at http://www.ietf.org/ipr. 703 The IETF invites any interested party to bring to its attention any 704 copyrights, patents or patent applications, or other proprietary 705 rights that may cover technology that may be required to implement 706 this standard. Please address the information to the IETF at 707 ietf-ipr@ietf.org. 709 Derivative Works Limitation 711 This document may not be modified, and derivative works of it may 712 not be created, except to publish it as an RFC and to translate it 713 into languages other than English. 715 Copyright Notice 717 Copyright (C) The Internet Society (2006). 719 This document is subject to the rights, licenses and restrictions 720 contained in BCP 78, and except as set forth therein, the authors 721 retain all their rights. 723 Disclaimer 725 This document and the information contained herein are provided on 726 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 727 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 728 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 729 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 730 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 731 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 732 PARTICULAR PURPOSE.