idnits 2.17.1 draft-kolkman-dnsext-dnssec-in-band-rollover-00.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 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 619. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 596. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 603. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 609. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 625), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** There are 24 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 434 has weird spacing: '...ication using...' == Line 478 has weird spacing: '...y issue resol...' == Line 486 has weird spacing: '...of) the resol...' == 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.) -- The document date (July 9, 2004) is 7223 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3757 (ref. '2') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-11) exists of draft-ietf-dnsext-dnssec-records-04 == Outdated reference: A later version (-13) exists of draft-ietf-dnsext-dnssec-intro-10 == Outdated reference: A later version (-08) exists of draft-ietf-dnsop-dnssec-operational-practices-01 -- Obsolete informational reference (is this intentional?): RFC 2459 (ref. '6') (Obsoleted by RFC 3280) Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Ihren 2 Internet-Draft Autonimica AB 3 Expires: January 7, 2005 O. Kolkman 4 RIPE NCC 5 B. Manning 6 EP.net 7 July 9, 2004 9 An In-Band Rollover Algorithm and a Out-Of-Band Priming Method for 10 DNS Trust Anchors. 11 draft-kolkman-dnsext-dnssec-in-band-rollover-00 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 7, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 The DNS Security Extensions (DNSSEC) works by validating so called 45 chains of authority. The start of these chains of authority are 46 usually public keys that are anchored in the DNS clients, the so 47 called trust anchors. 49 This memo describes a method how these client trust anchors can be 50 replaced using the DNS validation and querying mechanisms (in-band) 51 if the key pairs used for signing by zone owner are rolled. 53 This memo also describes a method to establish the validity of trust 54 anchors for initial configuration, or priming, using out of band 55 mechanisms. 57 Table of Contents 59 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Key Signing Keys, Zone Signing Keys and Secure Entry 61 Points. . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Introduction and Background . . . . . . . . . . . . . . . . . 4 63 3. M-N Trust Anchor Rollover. . . . . . . . . . . . . . . . . . . 5 64 3.1 The Rollover . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.2 The Algorithm. . . . . . . . . . . . . . . . . . . . . . . 6 66 3.3 Implementation notes . . . . . . . . . . . . . . . . . . . 7 67 3.4 Possible transactions. . . . . . . . . . . . . . . . . . . 7 68 3.4.1 Single DNSKEY replaced. . . . . . . . . . . . . . . . 7 69 3.4.2 Addition of a new DNSKEY (no removal) . . . . . . . . 8 70 3.4.3 Removal of old DNSKEY (no addition). . . . . . . . . . 8 71 3.4.4 Multiple DNSKEYs replaced. . . . . . . . . . . . . . . 8 72 3.4.5 Only some RRSIGs validate over an unchanged DNSKEY 73 set. . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.5 No need for resolver-side overlap of old and new keys. . . 8 75 4. Bootstrapping automatic rollovers. . . . . . . . . . . . . . . 8 76 4.1 Priming Keys. . . . . . . . . . . . . . . . . . . . . . . 9 77 4.1.1 Bootstrapping trust-anchors using a priming key. . . . 9 78 4.1.2 Distribution of priming keys. . . . . . . . . . . . . 9 79 5. M-N algorithm vs Priming . . . . . . . . . . . . . . . . . . . 10 80 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 10 81 6.1 M-N Algorithm Security Considerations . . . . . . . . . . 10 82 6.2 Priming Key Security Considerations . . . . . . . . . . . 11 83 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 11 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 86 8.2 Informative References . . . . . . . . . . . . . . . . . . . 11 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 88 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 89 B. Document History . . . . . . . . . . . . . . . . . . . . . . . 12 90 B.1 version 00 . . . . . . . . . . . . . . . . . . . . . . . . 13 91 Intellectual Property and Copyright Statements . . . . . . . . 14 93 1. Terminology 95 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 96 and "MAY" in this document are to be interpreted as described in 97 RFC2119 [1]. 99 The term "zone" refers to the unit of administrative control in the 100 Domain Name System. In this document "name server" denotes a DNS 101 name server that is authoritative (i.e. knows all there is to know) 102 for a DNS zone. A "zone owner" is the entity responsible for signing 103 and publishing a zone on a name server. The terms "authentication 104 chain", "bogus", "trust anchors" and "Island of Security" are defined 105 in [4]. Throughout this document we use the term "resolver" to mean 106 "Validating Stub Resolvers" as defined in [4]. 108 We use the term "security apex" as the zone for which a trust anchor 109 has been configured and which is therefore, by definition, at the 110 root of an island of security. The configuration of trust anchors is 111 a client side issue therefore a zone owner may not always know if 112 their zone has become a security apex. 114 A "stale anchor" is a trust anchor (a public key) that relates to a 115 key that is not used for signing. Since trust anchors indicate that 116 a zone is supposed to be secure a validator will mark the all data in 117 an island of security as bogus when all trust anchors become stale. 119 It is assumed that the reader is familiar with public key 120 cryptography concepts [REF: Schneier Applied Cryptography] and is 121 able to distinguish between the private and public parts of a key 122 based on the context in which we use the term "key", if there is a 123 possible ambiguity we will explicitly mention if a private or a 124 public part of a key is used. 126 The term "administrator" is used loosely throughout the text. In 127 some cases an administrator is meant to be a person, in other cases 128 the administrator may be a process that has been delegated certain 129 responsibilities. 131 1.1 Key Signing Keys, Zone Signing Keys and Secure Entry Points. 133 Although the DNSSEC protocol does not make a distinction between 134 different keys the operational practice is that a distinction is made 135 between zone signing keys and key signing keys. A key signing key is 136 used to exclusively sign the DNSKEY Resource Record (RR) set at the 137 apex of a zone and the zone signing keys sign all the data in the 138 zone (including the DNSKEY RR set at the apex). 140 Keys that are intended to be used as the start of the authentication 141 chain for a particular zone, either because they are pointed to by a 142 parental DS RR or because they are configured as a trust anchor, are 143 called Secure Entry Point (SEP) keys. In practice these SEP keys 144 will be key signing keys. 146 In order for the mechanism described herein to work the keys that are 147 intended to be used as secure entry points MUST have the SEP [2] flag 148 set. In the examples it is assumed that keys with the SEP flag set 149 are used as key signing keys and thus exclusively sign the DNSKEY RR 150 set published at the apex of the zone. 152 2. Introduction and Background 154 When DNSSEC signatures are validated the resolver constructs a chain 155 of authority from a pre-configured trust anchor to the DNSKEY 156 Resource Record (RR), which contains the public key that validates 157 the signature stored in a RRSIG RR. DNSSEC is designed so that the 158 administrator of a resolver can create multiple islands of security 159 by configuring multiple trust anchors. 161 It is expected that resolvers will have more than one trust-anchor 162 configured. Although there is no deployment experience it is not 163 unreasonable to expect resolvers to be configured with a number of 164 trust anchors that varies between order 1 and order 1000. Because 165 zone owners are expected to roll their keys, trust-anchors will have 166 to be maintained in order not to become stale. 168 Since there is no global key maintenance policy for zone owners and 169 there are no mechanisms in the DNS to signal the key maintenance 170 policy it may be very hard for resolvers administrators to keep their 171 set of trust anchors up to date. For instance, if there is only one 172 trust anchor configured and the key maintenance policy is clearly 173 published, through some out of band trusted channel, than a resolver 174 administrator can probably keep track of key rollovers and update the 175 trust anchor annually. With more than 100 different policies all 176 published through different channels this soon becomes an 177 unmanageable problem. 179 In Section 3 this memo sets out a lightweight, in-DNS, mechanism to 180 track key rollovers and modify the trust-anchor's accordingly. The 181 algorithm is stateless and does not need protocol extensions. 183 In Section 4 we describe a method [Editors note: for now only the 184 frame work and a set of requirements] to install trust anchors. This 185 method can be used at first configuration or when the trust anchors 186 became out of sync with the keys published by a zone owner. 188 The choice for which domains trust anchors are to be configured is a 189 local policy issue. So is the choice which trust anchors has 190 prevalence if there are multiple chains of trust to a given piece of 191 DNS data (e.g. when a domain and its sub-domain both have a trust 192 anchor configured). Both issues are out of the scope of this 193 document. 195 3. M-N Trust Anchor Rollover. 197 3.1 The Rollover 199 When a key pair is replaced all signatures (in DNSSEC these are the 200 RRSIG records) created with the old key will be replaced by new 201 signatures created by the new key. Access to the new public key is 202 needed to verify these signatures. 204 Since a zone signing keys are in "the middle" of a chain of authority 205 the can be verified using the signature made by a key signing key. 206 Rollover is therefore transparent to validators. But if a key 207 signing key is rolled a resolver can determine its authenticity by 208 either following the authorization chain from the parents DS RR, an 209 out-of-DNS authentication or by relying on other trust anchors known 210 for the zone in which the key is rolled. The M-N trust anchor 211 rollover mechanism, described below, is based on using existing trust 212 anchors to verify a subset of the available signatures. 214 Our example pseudo zone below contains a number of key signing keys 215 numbered 1 through Y and two zone signing keys A and B. During a key 216 rollover key 2 is replaced by key Y+1. The zone content changes 217 from: 219 example.com. DNSKEY key1 220 example.com. DNSKEY key2 221 example.com. DNSKEY key3 222 ... 223 example.com. DNSKEY keyN 225 example.com. DNSKEY keyA 226 example.com. DNSKEY keyB 228 example.com. RRSIG DNSKEY ... (key1) 229 example.com. RRSIG DNSKEY ... (key2) 230 example.com. RRSIG DNSKEY ... (key3) 231 ... 232 example.com. RRSIG DNSKEY ... (keyY) 233 example.com. RRSIG DNSKEY ... (keyA) 234 example.com. RRSIG DNSKEY ... (keyB) 236 to: 238 example.com. DNSKEY key1 239 example.com. DNSKEY key3 240 ... 241 example.com. DNSKEY keyY 242 example.com. DNSKEY keyY+1 244 example.com. RRSIG DNSKEY ... (key1) 245 example.com. RRSIG DNSKEY ... (key3) 246 ... 247 example.com. RRSIG DNSKEY ... (keyY) 248 example.com. RRSIG DNSKEY ... (keyY+1) 250 When the rollover becomes visible to the verifying stub resolver it 251 will be able to verify the RRSIGs associated with key1, key3 ... 252 keyY. There will be no RRSIG by key2 and the RRSIG by keyY+1 will 253 not be used for validation, since that key is previously unknown and 254 thereby not trusted. 256 Note that this example is simplified. Because of operational 257 considerations described in [5] having a period where the two key 258 signing keys are available is actually a good idea. 260 3.2 The Algorithm. 262 The M-N trust anchor rollover algorithm applies as follows. If for a 263 particular zone 264 o at least M public keys from the trust anchors directly verify the 265 related RRSIGs over the DNSKEY RRset. (the M criterion) 266 and if 267 o the number of element in the set difference between 'the set of 268 keys from the DNSKEY RRset with the SEP bit set' and 'the set of 269 keys configured as trust anchors' is smaller or equal than N. 270 (the N criterion) 271 then all the trust-anchors for the particular zone replaced by the 272 keys from the zones DNSKEY RR set that have the SEP flag set 274 The choices for the rollover acceptance policy parameters M and N are 275 left to the administrator of the resolver. To be certain that a 276 rollover is picked up by resolvers running this algorithm zone owners 277 should only roll 1 SEP key at a time. That way they comply to the 278 most strict rollover acceptance policy of N=1. The value of M is 279 limited by the amount of SEP keys a zone owner publishes. If the 280 policy of the zone owner is to use Y SEP keys than the value of M 281 should be M<=Y-N. 283 If the rollover acceptance policy is M=1 then the result for the 284 rollover in our example above should be that the local database of 285 trusted keys is updated by removing key "key2" and adding key 286 "keyN+1" to the key store. 288 3.3 Implementation notes 290 The DNSSEC protocol ordains that all DNSKEYs should be self-signed. 291 The implementation should check this. In order to be resilient 292 against failures the implementation should collect the DNSKEY RRsets 293 from (other) authoritative servers if verification of the self 294 signatures fails. 296 The algorithm SHOULD only be applied to algorithms, as represented in 297 the algorithm field in the DNSKEY/RRSIG [3], that the resolver is 298 aware of. In other words the SEP keys of unknown algorithms should 299 not be used when calculating the set difference for the N parameter 300 and the SEP keys of unknown algorithm should not be entered as trust 301 anchors. 303 If a the M criterion is not met then the set of trust-anchors is out 304 of sync with the SEP keys in the DNSKEY RRset and some or all of the 305 trust-anchors are stale. This condition should be flagged. The most 306 appropriate action is human audit possibly followed by re-priming 307 (Section 4) the keyset. 309 An implementation should regularly probe the the authoritative 310 nameservers for new keys. Since there is no mechanism to publish 311 rollover frequencies this document RECOMMENDS zone owners not to roll 312 their key signing keys more often than once per month and resolver 313 administrators to probe for key rolls (and apply the M-N algorithm) 314 not less often than once per month. If the rollover frequency is 315 higher than the probing frequency than trust anchors may become 316 stale. The exact relation between the frequencies depends on the 317 amount of SEP keys rolled by the zone owner and the value M 318 configured by the resolver administrator. 320 In all the cases below a transaction where M-N algorithm does not 321 validate should be considered bad (i.e. possibly spoofed or 322 otherwise corrupted data). The most appropriate action is human 323 audit. 325 3.4 Possible transactions. 327 3.4.1 Single DNSKEY replaced. 329 This is probably the most typical transaction on the zone owners 330 part. The result should be that if the M-N algorithm validates then 331 the key store is updated by removal of the old key and addition of 332 the new key. Note that if the DNSKEY RRset contains exactly M keys 333 replacement of keys is not possible. 335 3.4.2 Addition of a new DNSKEY (no removal) 337 If M-N algorithm validates then the new key is added to the key 338 store. Not more than N keys can be added at once. 340 3.4.3 Removal of old DNSKEY (no addition). 342 If the M-N algorithm validates then the old key is removed from the 343 key store. Note that it is not possible to reduce the keyset to a 344 size smaller than M. 346 3.4.4 Multiple DNSKEYs replaced. 348 Not more than N keys can be replace at one time. Since M keys need 349 to validate the total number of SEP keys in the DNSKEY RRset is M+N. 351 Since the value of N is set by the resolvers local policy zone owners 352 should assume N==1 in order to prevent a subset of the resolvers to 353 become stale because they did not pick up the change. 355 3.4.5 Only some RRSIGs validate over an unchanged DNSKEY set. 357 This is a case where the M criterion may not be met, see Section 3.3. 359 3.5 No need for resolver-side overlap of old and new keys. 361 It is worth pointing out that there is no need for the resolver to 362 keep state about old keys versus new keys. From the resolver point 363 of view there are only trusted and not trusted keys. The reason is 364 that the zone owner needs to do proper maintenance of RRSIGs 365 regardless of the resolver rollover mechanism and hence must ensure 366 that a key is not rolled out out the DNSKEY set until there cannot be 367 any RRSIGs created by this key still legally cached. 369 Hence the rollover mechanism is stateless: as soon as the resolver 370 (or in this case the rollover tracking utility) detects a change in 371 the DNSKEY set with a sufficient number of matching RRSIGs the 372 trusted key definition is immediately updated. 374 4. Bootstrapping automatic rollovers. 376 It is expected that with the ability to automatically roll trust 377 anchors at trust points will follow a diminished unwillingness to 378 roll these keys, since the risks associated with stale keys are 379 minimized. 381 The problem of "priming" the trust anchors, or bringing them into 382 sync (which could happen if a resolver is off line for a long period 383 in which a set of SEP keys in a zone 'evolve' away from its trust 384 anchor configuration) remains. 386 For (re)priming we can rely on out of band technology and we propose 387 the following framework. 389 4.1 Priming Keys. 391 If all the trust anchors roll somewhat frequently (on the order of 392 months or at most about a year) then it will not be possible to 393 design a device, or a software distribution that includes trust 394 anchors, that after being manufactured is put on a shelf for several 395 key rollover periods before being brought into use (since no trust 396 anchors that were known at the time of manufacture remain active). 398 To alleviate this we propose the concept of "priming keys". Priming 399 keys are ordinary DNSSEC Key Signing Keys with the characteristic 400 that 401 o The private part of a priming key signs the DNSKEY RRset at the 402 security apex, i.e. at least one RRSIG DNSKEY is created by a 403 priming key rather than by an "ordinary" trust anchor 404 o the public parts of priming keys are not included in the DNSKEY 405 RRset. Instead the public parts of priming keys are only 406 available out-of-band. 407 o The public parts of the priming keys have a validity period. 408 Within this period they can be used to obtain trust anchors. 409 o The priming key pairs are long lived (relative to the key rollover 410 period.) 412 4.1.1 Bootstrapping trust-anchors using a priming key. 414 To install the trust-anchor for a particular security apex an 415 administrator of a validating resolver will need to: 416 o query for the DNSKEY RR set of the zone at the security apex; 417 o verify the self signatures of all DNSKEYs in the RRset; 418 o verify the signature of the RRSIG made with a priming key -- 419 verification using one of the public priming keys that is valid at 420 that moment is sufficient; 421 o create the trust anchors by extracting the DNSKEY RRs with the SEP 422 flag set. 423 The SEP keys with algorithms unknown to the validating resolver 424 SHOULD be ignored during the creation of the trust anchors. 426 4.1.2 Distribution of priming keys. 428 The public parts of the priming keys SHOULD be distributed 429 exclusively through out-of-DNS mechanisms. The requirements for a 430 distribution mechanism are: 432 o it can carry the "validity" period for the priming keys; 433 o it can carry the self-signature of the priming keys; 434 o and it allows for verification using trust relations outside the 435 DNS. 436 A distribution mechanism would benefit from: 437 o the availability of revocation lists; 438 o the ability of carrying zone owners policy information such as 439 recommended values for "M" and "N" and a rollover frequency; 440 o and the technology on which is based is readily available. 442 [Editors Note: 444 X.509 technology is a logical candidate for the distribution of 445 priming keys. The exact details need further research. 447 What we probably need a convention on the use id-ce-keyUsage, the 448 id-ce-extKeyUsage (assignment of a KeyPurposeId) and other relevant 449 field [6]. Is there a possibility to store the keyroll policy 450 information? PKIX specialist are invited to give their input. 452 End of Editors note] 454 5. M-N algorithm vs Priming 456 There is overlap in the M-N algorithm and the Priming method. One 457 could exclusively use the Priming method for maintaining the trust 458 anchors. However the priming method probably relies on "non-DNS' 459 technology and may therefore not be available for all devices that 460 have a resolver. 462 6. Security Considerations. 464 6.1 M-N Algorithm Security Considerations 466 A clear issue for resolvers will be how to ensure that they track all 467 rollover events for the zones they have configure trust anchors for. 468 Because of temporary outages validating resolvers may have missed a 469 rollover of a KSK. The parameters that determine the robustness 470 against failures are: a long period between rollovers during which 471 the KSK set is stable and validating resolvers can actually notice 472 the change; the number of KSKs and the value of M. 474 With a large number of KSKs and a small value of M this operation 475 becomes more robust since losing one key, for whatever reason, will 476 not be crucial. Unfortunately the choice for the number of KSKs is a 477 local policy issue for the zone owner while the choice for the 478 parameter M is a local policy issue resolvers administrator. 480 Higher values of M increase the resilience against attacks somewhat; 481 more signatures need to verify before a rollover is approved. 483 The M-N algorithm does not provide a revocation mechanism. In the 484 case that the private keys of a zone owner are compromised the 485 culprit may use these private keys to roll the trust anchors of (a 486 subset of) the resolvers. 488 6.2 Priming Key Security Considerations 490 Since priming keys are not included in the DNSKEY RR set they are 491 less sensitive to packet size constraints and can be chosen 492 relatively large. The private parts are only needed to sign the 493 DNSKEY RR set during the validity period of the particular priming 494 key pair. Note that the private part of the priming key is used each 495 time when a DNSKEY RRset has to be resigned in practice there shall 496 little difference between the usage pattern of the private part of 497 key signing keys and priming keys. 499 7. IANA Considerations. 501 NONE. 503 8. References 505 8.1 Normative References 507 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 508 Levels", BCP 14, RFC 2119, March 1997. 510 [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY 511 (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", 512 RFC 3757, May 2004. 514 [3] Arends, R., "Resource Records for DNS Security Extensions", 515 draft-ietf-dnsext-dnssec-records-04 (work in progress), 516 September 2003. 518 8.2 Informative References 520 [4] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, 521 "DNS Security Introduction and Requirements", 522 draft-ietf-dnsext-dnssec-intro-10 (work in progress), May 2004. 524 [5] Kolkman, O., "DNSSEC Operational Practices", 525 draft-ietf-dnsop-dnssec-operational-practices-01 (work in 526 progress), May 2004. 528 [6] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509 529 Public Key Infrastructure Certificate and CRL Profile", RFC 530 2459, January 1999. 532 Authors' Addresses 534 Johan Ihren 535 Autonimica AB 536 Bellmansgaten 30 537 Stockholm SE-118 47 538 Sweden 540 EMail: johani@autonomica.se 542 Olaf M. Kolkman 543 RIPE NCC 544 Singel 256 545 Amsterdam 1016 AB 546 NL 548 Phone: +31 20 535 4444 549 EMail: olaf@ripe.net 550 URI: http://www.ripe.net/ 552 Bill Manning 553 EP.net 554 Marina del Rey, CA 90295 555 USA 557 Appendix A. Acknowledgments 559 The present design for in-band automatic rollovers of DNSSEC trust 560 anchors is the result of many conversations and it is no longer 561 possible to remember exactly who contributed what. 563 In addition we've also had appreciated help from (in no particular 564 order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt 565 Larson and Mark Kosters. 567 Appendix B. Document History 569 This appendix will be removed if and when the document is submitted 570 to the RFC editor. 572 The version you are reading is tagged as $Revision: 1.5 $. 574 Text between square brackets, other than references, are editorial 575 comments and will be removed. 577 B.1 version 00 579 Kolkman documented the ideas provided by Ihren and Manning. In the 580 process of documenting (and prototyping) Kolkman changed some of the 581 details of the M-N algorithms working. Ihren did not have a change 582 to review the draft before Kolkman posted; 584 Kolkman takes responsibilities for omissions, fuzzy definitions and 585 mistakes. 587 Intellectual Property Statement 589 The IETF takes no position regarding the validity or scope of any 590 Intellectual Property Rights or other rights that might be claimed to 591 pertain to the implementation or use of the technology described in 592 this document or the extent to which any license under such rights 593 might or might not be available; nor does it represent that it has 594 made any independent effort to identify any such rights. Information 595 on the procedures with respect to rights in RFC documents can be 596 found in BCP 78 and BCP 79. 598 Copies of IPR disclosures made to the IETF Secretariat and any 599 assurances of licenses to be made available, or the result of an 600 attempt made to obtain a general license or permission for the use of 601 such proprietary rights by implementers or users of this 602 specification can be obtained from the IETF on-line IPR repository at 603 http://www.ietf.org/ipr. 605 The IETF invites any interested party to bring to its attention any 606 copyrights, patents or patent applications, or other proprietary 607 rights that may cover technology that may be required to implement 608 this standard. Please address the information to the IETF at 609 ietf-ipr@ietf.org. 611 Disclaimer of Validity 613 This document and the information contained herein are provided on an 614 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 615 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 616 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 617 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 618 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 619 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 621 Copyright Statement 623 Copyright (C) The Internet Society (2004). This document is subject 624 to the rights, licenses and restrictions contained in BCP 78, and 625 except as set forth therein, the authors retain all their rights. 627 Acknowledgment 629 Funding for the RFC Editor function is currently provided by the 630 Internet Society.