idnits 2.17.1 draft-ietf-dnsop-dnssec-dps-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 23, 2010) is 5141 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Ljunggren 3 Internet-Draft Kirei AB 4 Intended status: Informational A-M. Eklund-Lowinder 5 Expires: September 24, 2010 .SE 6 T. Okubo 7 VeriSign 8 March 23, 2010 10 DNSSEC Signing Policy & Practice Statement Framework 11 draft-ietf-dnsop-dnssec-dps-framework-01 13 Abstract 15 This document presents a framework to assist writers of DNSSEC 16 Signing Policy and Practice Statements such as Regulatory Authorities 17 and Registry Managers on both the TLD and secondary level, who is 18 operating a DNS zone with Security Extensions (DNSSEC) implemented. 20 In particular, the framework provides a comprehensive list of topics 21 that potentially (at the writer's discretion) needs to be covered in 22 a DNSSEC Signing Policy definition and Practice Statement. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on September 24, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. DPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.2. Relationship between DNSSEC Signing Policy and 71 Practice Statement . . . . . . . . . . . . . . . . . . . . 6 72 3.3. Set of provisions . . . . . . . . . . . . . . . . . . . . 7 73 4. Contents of a set of provisions . . . . . . . . . . . . . . . 9 74 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.1.2. Document Name and Identification . . . . . . . . . . . 9 77 4.1.3. Community and Applicability . . . . . . . . . . . . . 9 78 4.1.4. Specification Administration . . . . . . . . . . . . . 9 79 4.2. Publication and Repositories . . . . . . . . . . . . . . . 10 80 4.3. Operational Requirements . . . . . . . . . . . . . . . . . 10 81 4.3.1. Meaning of domain names . . . . . . . . . . . . . . . 10 82 4.3.2. Activation of DNSSEC for child zone . . . . . . . . . 10 83 4.3.3. Identification and authentication of child zone 84 manager . . . . . . . . . . . . . . . . . . . . . . . 11 85 4.3.4. Registration of delegation signer (DS) resource 86 records . . . . . . . . . . . . . . . . . . . . . . . 11 87 4.3.5. Method to prove possession of private key . . . . . . 11 88 4.3.6. Removal of DS resource records . . . . . . . . . . . . 11 89 4.4. Management, Operational, and Physical Controls . . . . . . 11 90 4.4.1. Physical Controls . . . . . . . . . . . . . . . . . . 11 91 4.4.2. Procedural Controls . . . . . . . . . . . . . . . . . 12 92 4.4.3. Personnel Controls . . . . . . . . . . . . . . . . . . 12 93 4.4.4. Audit Logging Procedures . . . . . . . . . . . . . . . 13 94 4.4.5. Compromise and Disaster Recovery . . . . . . . . . . . 14 95 4.4.6. Entity termination . . . . . . . . . . . . . . . . . . 14 96 4.5. Technical Security Controls . . . . . . . . . . . . . . . 15 97 4.5.1. Key Pair Generation and Installation . . . . . . . . . 15 98 4.5.2. Private key protection and Cryptographic Module 99 Engineering Controls . . . . . . . . . . . . . . . . . 15 100 4.5.3. Other Aspects of Key Pair Management . . . . . . . . . 17 101 4.5.4. Activation data . . . . . . . . . . . . . . . . . . . 17 102 4.5.5. Computer Security Controls . . . . . . . . . . . . . . 17 103 4.5.6. Network Security Controls . . . . . . . . . . . . . . 18 104 4.5.7. Timestamping . . . . . . . . . . . . . . . . . . . . . 18 105 4.5.8. Life Cycle Technical Controls . . . . . . . . . . . . 18 106 4.6. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 18 107 4.6.1. Key lengths and algorithms . . . . . . . . . . . . . . 19 108 4.6.2. Authenticated denial of existence . . . . . . . . . . 19 109 4.6.3. Signature format . . . . . . . . . . . . . . . . . . . 19 110 4.6.4. Zone signing key roll-over . . . . . . . . . . . . . . 19 111 4.6.5. Key signing key roll-over . . . . . . . . . . . . . . 19 112 4.6.6. Signature life-time and re-signing frequency . . . . . 19 113 4.6.7. Verification of zone signing key set . . . . . . . . . 19 114 4.6.8. Verification of resource records . . . . . . . . . . . 19 115 4.6.9. Resource records time-to-live . . . . . . . . . . . . 20 116 4.7. Compliance Audit . . . . . . . . . . . . . . . . . . . . . 20 117 4.7.1. Frequency of entity compliance audit . . . . . . . . . 20 118 4.7.2. Identity/qualifications of auditor . . . . . . . . . . 20 119 4.7.3. Auditor's relationship to audited party . . . . . . . 20 120 4.7.4. Topics covered by audit . . . . . . . . . . . . . . . 20 121 4.7.5. Actions taken as a result of deficiency . . . . . . . 20 122 4.7.6. Communication of results . . . . . . . . . . . . . . . 21 123 4.8. Legal Matters . . . . . . . . . . . . . . . . . . . . . . 21 124 4.8.1. Fees . . . . . . . . . . . . . . . . . . . . . . . . . 21 125 4.8.2. Financial responsibility . . . . . . . . . . . . . . . 21 126 4.8.3. Confidentiality of business information . . . . . . . 22 127 4.8.4. Privacy of personal information . . . . . . . . . . . 22 128 4.8.5. Limitations of liability . . . . . . . . . . . . . . . 23 129 4.8.6. Term and termination . . . . . . . . . . . . . . . . . 23 130 5. Outline of a set of provisions . . . . . . . . . . . . . . . . 23 131 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 132 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 133 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 134 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 135 8.2. Informative References . . . . . . . . . . . . . . . . . . 27 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 138 1. Introduction 140 1.1. Background 142 The Domain Name System Security Extensions (DNSSEC, RFC 4033 143 [RFC4033]) is a set of IETF specifications for securing the Domain 144 Name System. DNSSEC provides a way for software to validate the 145 authenticity of Domain Name System (DNS) data and that such data have 146 not been modified during Internet transit. 148 The DNS was not originally designed with strong security mechanisms 149 to provide integrity and authenticity of DNS data. Over the years, a 150 number of vulnerabilities had been discovered that threaten the 151 reliability and trustworthiness of the system. DNSSEC addresses 152 these vulnerabilities by adding data origin authentication, data 153 integrity verification and authenticated denial of existence 154 capabilities to DNS by incorporating public key cryptography into the 155 DNS hierarchy. 157 DNSSEC differs from the X.509 PKI in many ways. For instance, in 158 DNSSEC there is no central control of assurance or trust levels. 159 Each zone manager may have its own way of managing keys and 160 operations, and there is no necessity to perform any coordination 161 between different zones or levels in the DNS. The degree to which a 162 relying party can trust the binding embodied in the DNSSEC chain is 163 dependent on the weakest link in that chain. As an implication of 164 this nature, the security of domains becomes more critical the higher 165 up in the DNS hierarchy one gets. 167 To provide means for the relying parties to evaluate the trust and 168 strength of the chain, registries may choose to publish DNSSEC 169 Practice Statements (DPSs), comprising statements of critical 170 security controls and procedures relevant to the relying parties. 172 Even though this document is heavily inspired by RFC 3647 [RFC3647] 173 and large parts drawn from that document, one significant difference 174 is that the DPS framework is focused only on stating the security 175 posture of the registry, rather than for all participants in the 176 domain name system. The DNS is almost of a ubiquitous nature, and 177 there exists no agreements with the relying (third) parties, which is 178 basically everyone using the Internet. 180 1.2. Purpose 182 The purpose of this document is twofold. Firstly, the document aims 183 to explain the concept of a DPS and describe the relationship between 184 the DPS, the registry, the domain holders and the relying (third) 185 parties. Second, this document aims to present a framework to 186 encourage and assist writers of DPSs in creating heterogenous and 187 comparable policies and practices. In particular, the framework 188 identifies the elements that may need to be considered in formulating 189 a DPS. The purpose is not to define a particular Policy or Practice 190 Statement, per se. Moreover, this document does not aim to provide 191 legal advice or recommendations as to particular requirements or 192 practices that should be contained within a DPS. 194 1.3. Scope 196 The scope of this document is limited to discussion of the topics 197 that can be covered in a DPS and does not go into the specific 198 details that could possibly be included in each topic. In 199 particular, this document describes the types of information that 200 should be considered for inclusion in a DPS. 202 This DPS framework should be viewed and used as a tool that could act 203 as a checklist of factors that should be taken in to consideration 204 prior to deploying DNSSEC, and an outline to create a document that 205 states the actual DNSSEC operations. The framework is primarily 206 aimed at organizations providing registry services, but may be used 207 by high-value domain holders and serve as a check sheet for DNSSEC 208 readiness at a high level. 210 This document assumes that the reader is familiar with the general 211 concepts of DNS, DNSSEC and PKI. 213 2. Definitions 215 3. Concepts 217 This section describes the concept of a DNSSEC Signing Policy and 218 Practices Statement. Other related concepts are described as well. 220 3.1. DPS 222 Most DNSSEC participants may not have the need to create a thorough 223 and detailed statement of practices. For example, the registrant may 224 itself be the relying party of its own zone and would already be 225 aware of the nature and trustworthiness of its services. In other 226 cases, a Registry may provide registration services providing only a 227 very low level of assurances where the domain names being secured may 228 pose only marginal risks if compromised. In these cases, an 229 organization implementing DNS Security Extensions may only want to 230 use a registrant agreement. In such circumstances, that agreement 231 may serve as the only "statement of practices" used by one or more 232 registries within that Zone. Consequently, that agreement may also 233 be considered a DPS and can be entitled or subtitled as such. 235 A DPS should contain information which is relevant to the DNSSEC 236 participants. Since the participants generally include the Internet 237 community, it should not contain such information which could be 238 considered to be sensitive details of a registry's operations, but 239 rather reference such processes and procedures, which need not be 240 public information. 242 The DPS does not automatically constitute a contract and do not 243 automatically bind DNSSEC participants as a contract would. In most 244 cases there exists no contractual agreement between the registry and 245 the relying party. Where a document serves the dual purpose of being 246 a registrant agreement and a DPS, the document is intended to be part 247 of a contract and constitutes a legally binding document to the 248 extent that a registrant agreement would ordinarily be considered as 249 such. 251 Therefore, DPS's terms have a binding effect as contract terms only 252 if a separate document creates a contractual relationship between the 253 parties and where that document incorporates parts or all of the DPS 254 by reference. 256 3.2. Relationship between DNSSEC Signing Policy and Practice Statement 258 A DNSSEC Signing Policy and a DNSSEC Practice Statement address the 259 same set of topics that are of interest to the relying party in terms 260 of the degree to and purpose for which a signature should be trusted. 261 Their primary difference is in the focus of their provisions. A 262 Signing Policy sets forth the requirements and standards to be 263 implemented for a DNSSEC Signed Zone. In other words, the purpose of 264 the Signing Policy is to establish what participants must do. A 265 Practice statement, by contrast, states how a Registry and other 266 participants in a given Zone implement procedures and controls to 267 meet the requirements stated in the Policy. In other words, the 268 purpose of the Practice Statement is to disclose how the participants 269 perform their functions and implement controls. 271 An additional difference between a Signing Policy and a Practice 272 Statement relates the scope of coverage of the two kinds of 273 documents. Since a Signing Policy is a statement of requirements, it 274 best serves as the vehicle for communicating minimum operating 275 guidelines that must be met by complying parties. Thus, a Signing 276 Policy may apply to multiple Registries, multiple organizations, or 277 multiple zones. By contrast, a Practice Statement applies only to a 278 single Registry or single organization. 280 For example, a Regulatory Authority might define requirements in a 281 Signing Policy for DNSSEC operations for one or more Registries. The 282 Signing Policy will be a broad statement of the general requirements 283 for participants within the Registry's Zone. 285 A registry may be required to write its own Practice Statement to 286 support this Signing Policy by explaining how it meets the 287 requirements of the Signing Policy. Or, a Registry not governed by 288 any Signing Policy may choose to publish a Practice Statement to 289 provide transparency and gain community trust and acceptance. 291 An additional difference between a Signing Policy and a Practice 292 Statement concerns the level of detail of the provisions in each. 293 Although the level of detail may vary, a Practice Statement will 294 generally be more detailed than a Signing Policy. A Practice 295 Statement provides a detailed description of procedures and controls 296 in place to meet the Signing Policy requirements, while a Signing 297 Policy is more general. 299 The main differences between a Signing Policy and Practice Statement 300 can therefore be summarized as follows: 302 (a) Operation of a DNS Zone with DNSSEC may be governed by a Signing 303 Policy, to establish requirements that state what the parties 304 within the zone must do. A single Registry or organization can 305 use a Practice Statment to disclose how it meets the 306 requirements of a Signing Policy or how it implements its 307 practices and controls. 308 (b) A Signing Policy may facilitate interoperation of level of trust 309 through several parts or levels in the DNS hierarchy. By 310 contrast, a Practice Statement is a statement of a single 311 Registry or organization. 312 (c) A Practice Statement is generally more detailed than a Signing 313 Policy and specifies how the Registry meets the requirements 314 specified in the one or more Signing Policies under which it 315 operates DNSSEC. 317 3.3. Set of provisions 319 A set of provisions is a collection of Signing Policy and/or Practice 320 statements, spanning a range of standard topics for use in expressing 321 a Signing Policy or Practice Statement employing the approach 322 described in this framework by covering the topics appearing in 323 Section 5 below. They are also described in detail in Section 4 324 below. 326 A Signing Policy can be expressed as a single set of provisions. 328 A Practice Statement can be expressed as a single set of provisions 329 with each component addressing the requirements of one or more 330 Signing Policies, or, alternatively, as an organized collection of 331 sets of provisions. For example, a Practice Statement could be 332 expressed as a combination of the following: 334 (a) a list of Signing Policies supported by the DPS; 335 (b) for each Signing Policy in (a), a set of provisions that 336 contains statements responding to that Signing Policy by filling 337 in details not stipulated in that policy or expressly left to 338 the discretion of the Signing Policy (in its Practice 339 Statement); such statements serve to state how this particular 340 Practice Statement implements the requirements of the particular 341 Signing Policy; or 342 (c) a set of provisions that contains statements regarding the 343 practices of the DNSSEC operations, regardless of Signing 344 Policy. 346 The statements provided in (b) and (c) may augment or refine the 347 stipulations of an applicable Signing Policy, but generally must not 348 conflict with any of the stipulations of such Signing Policy. In 349 certain cases, however, a Policy Authority may permit exceptions to 350 the requirements in a Signing Policy, because certain compensating 351 controls of the registry are disclosed in its DPS that allow the 352 registry to provide assurances that are equivalent to the assurances 353 provided by registries that are in full compliance with the DPS. 355 This framework outlines the contents of a set of provisions, in terms 356 of eight primary components, as follows: 358 1. Introduction 359 2. Publication and Repositories 360 3. Operational Requirements 361 4. Facilities, Management, and Operational Controls 362 5. Technical Security Controls 363 6. Zone Signing 364 7. Compliance Audit 365 8. Legal Matters 367 Policy authorities can use this framework of eight primary components 368 to write a DNSSEC Signing Policy. Moreover, a Registry can use this 369 same framework to write a DNSSEC Practice Statement. 371 Therefore, a Registry can establish a set of basic documents (with a 372 Signing Policy, Practice statement, and Registrant agreement) all 373 having the same structure and ordering of topics, thereby 374 facilitating comparisons and mappings among these documents and among 375 the corresponding documents of other Zones. 377 This basic framework may also be useful for the establishing of 378 agreements with registrars or outsourcing of certain services. 380 Drafters of DPSs are permitted to add additional levels of 381 subcomponents below the subcomponents described in Section 4 for the 382 purpose of meeting the needs of the drafter's particular 383 requirements. 385 4. Contents of a set of provisions 387 4.1. Introduction 389 This component identifies and introduces the set of provisions, and 390 indicates the types of entities and applications for which the 391 document (either the Signing Policy or the Practice Statement being 392 written) is targeted. 394 4.1.1. Overview 396 This subcomponent provides a general introduction to the document 397 being written. This subcomponent can also be used to provide a 398 synopsis of the community to which the Signing Policy or Practice 399 Statement applies. 401 4.1.2. Document Name and Identification 403 This subcomponent provides any applicable names or other identifiers 404 of the document. 406 4.1.3. Community and Applicability 408 This subcomponent addresses the stakeholders in DNSSEC along with the 409 expected roles and responsibilities. This includes but are not 410 limited to an entity signing the zone, an entity that relies on the 411 signed zone, other entities that have operational dependency on the 412 signed zone and an entity that entrusted the zone signing. 414 4.1.4. Specification Administration 416 This subcomponent includes the name and mailing address of the 417 organization that is responsible for drafting, registering, 418 maintaining, and updating of the DPS. It also includes the name, 419 electronic mail address and telephone number of a contact person. As 420 an alternative to naming an actual person, the document may name a 421 title or role, an e-mail alias, and other generalized contact 422 information. In some cases, the organization may state that its 423 contact person, alone or in combination with others, is available to 424 answer questions about the document. 426 Moreover, when a formal or informal Policy Authority is responsible 427 for determining whether a Registry should be allowed to operate a 428 Zone, it may wish to approve the DPS of the Registry as being 429 suitable for the Policy Authority's Signing Policy. If so, this 430 subcomponent can include the name or title, electronic mail address 431 (or alias), telephone number and other generalized information of the 432 entity in charge of making such a determination. Finally, in this 433 case, this subcomponent also includes the procedures by which this 434 determination is made. 436 4.2. Publication and Repositories 438 This component contains any applicable provisions regarding: 440 o An identification of the entity or entities that operate 441 repositories within the community, such as a Registry; 442 o The responsibility of a registry to publish information regarding 443 its practices, public keys, and the current status of such keys, 444 which may include the responsibilities of making the DPS publicly 445 available using various mechanisms and of identifying components, 446 subcomponents, and elements of such documents that exist but are 447 not made publicly available, for instance, security controls, 448 clearance procedures, or business information due to their 449 sensitivity; 450 o When information must be published and the frequency of 451 publication; and 452 o Access control on published information objects. 454 4.3. Operational Requirements 456 This component describes the operational requirements when operating 457 DNSSEC. 459 4.3.1. Meaning of domain names 461 This section describes the meaning of names in child zones, if any. 463 4.3.2. Activation of DNSSEC for child zone 465 This section describes how the child zone would be tied into the 466 parent zone by incorporating DS record into the zone. 468 4.3.3. Identification and authentication of child zone manager 470 This section will specify the methodology of identifying and 471 authenticating the requester of the child zone to determine whether 472 the request is valid or not. 474 4.3.4. Registration of delegation signer (DS) resource records 476 This section describes how the delegation signer resource records are 477 incorporated into the parent zone. 479 4.3.5. Method to prove possession of private key 481 This section describes how the child zone manager proves the 482 possession of the Key Signing Key to the parent zone when requesting 483 a delegation signer resource record to be incorporated. 485 4.3.6. Removal of DS resource records 487 This section will explain how, when and under which circumstances the 488 DS record may be removed from the zone file. 490 4.4. Management, Operational, and Physical Controls 492 This component describes non-technical security controls (that is, 493 physical, procedural, and personnel controls) used by the Registry to 494 securely perform the DNSSEC related functions such as key management, 495 zone signing, key roll-over, zone distribution, auditing and 496 archiving. 498 These non-technical security controls are critical for trusting the 499 signatures since lack of security may compromise DNSSEC operations 500 resulting for example, in the creation of signatures with erroneous 501 information or compromising the Key Signing Key and/or Zone Signing 502 Key. 504 Within each subcomponent, separate consideration will, in general, 505 need to be given to each entity type. 507 4.4.1. Physical Controls 509 In this subcomponent, the physical controls on the facility housing 510 the entity systems are described. Topics addressed may include: 512 o Site location and construction, such as the construction 513 requirements for high-security areas and the use of locked rooms, 514 cages, safes, and cabinets; 516 o Physical access, i.e., mechanisms to control access from one area 517 of the facility to another or access into high-security zones, 518 such as locating Registry operations in a secure computer room 519 monitored by guards, cameras or security alarms and requiring 520 movement from zone to zone to be accomplished using a token, 521 biometric readers, and/or access control lists; 522 o Power and air conditioning; 523 o Water exposures; 524 o Fire prevention and protection; 525 o Media storage, for example, requiring the storage of backup media 526 in a separate location that is physically secure and protected 527 from fire, smoke, particle and water damage; 528 o Waste disposal; and 529 o Off-site backup. 531 4.4.2. Procedural Controls 533 In this subcomponent, requirements for recognizing trusted roles are 534 described, together with the responsibilities for each role. 535 Examples of trusted roles include system administrators, security 536 officers, and system auditors. 538 For each task identified, the number of individuals required to 539 perform the task (n out m rule if applicable) should be stated for 540 each role. Identification and authentication requirements for each 541 role may also be defined. 543 This component also includes the separation of duties in terms of the 544 roles that cannot be performed by the same individuals. 546 4.4.3. Personnel Controls 548 This subcomponent addresses the following: 550 o Qualifications, experience, and clearances that personnel must 551 have as a condition of filling trusted roles or other important 552 roles. Examples include credentials, job experiences, and 553 official government clearances that candidates for these positions 554 must have before being hired; 555 o Background checks and clearance procedures that are required in 556 connection with the hiring of personnel filling trusted roles or 557 perhaps other important roles; such roles may require a check of 558 their criminal records, financial records, references, and 559 additional clearances that a participant undertakes after a 560 decision has been made to hire a particular person; 562 o Training requirements and training procedures for each role 563 following the hiring of personnel; 564 o Any retraining period and retraining procedures for each role 565 after completion of initial training; 566 o Frequency and sequence for job rotation among various roles; 567 o Sanctions against personnel for unauthorized actions, unauthorized 568 use of authority, and unauthorized use of entity systems for the 569 purpose of imposing accountability on a participant's personnel; 570 o Controls on personnel that are independent contractors rather than 571 employees of the entity; examples include: 573 * Bonding requirements on contract personnel; 574 * Contractual requirements including indemnification for damages 575 due to the actions of the contractor personnel; 576 * Auditing and monitoring of contractor personnel; and 577 * Other controls on contracting personnel. 579 o Documentation to be supplied to personnel during initial training, 580 retraining, or otherwise. 582 4.4.4. Audit Logging Procedures 584 This subcomponent is used to describe event logging and audit 585 systems, implemented for the purpose of maintaining a secure 586 environment. Elements include the following: 588 o Types of events recorded, such as attempts to access the system, 589 and requests made to the system; 590 o Frequency with which audit logs are processed or archived, for 591 example, weekly, following an alarm or anomalous event, or when 592 ever the audit log is n% full; 593 o Period for which audit logs are kept; 594 o Protection of audit logs: 596 * Who can view audit logs, for example only the audit 597 administrator; 598 * Protection against modification of audit logs, for instance a 599 requirement that no one may modify or delete the audit records 600 or that only an audit administrator may delete an audit file as 601 part of rotating the audit file; and 602 * Protection against deletion of audit logs. 604 o Audit log back up procedures; 605 o Whether the audit log accumulation system is internal or external 606 to the entity; 608 o Whether the subject who caused an audit event to occur is notified 609 of the audit action; and 610 o Vulnerability assessments, for example, where audit data is run 611 through a tool that identifies potential attempts to breach the 612 security of the system. 614 4.4.5. Compromise and Disaster Recovery 616 This subcomponent describes requirements relating to notification and 617 recovery procedures in the event of compromise or disaster. Each of 618 the following may need to be addressed separately: 620 o Identification or listing of the applicable incident and 621 compromise reporting and handling procedures. 622 o The recovery procedures used if computing resources, software, 623 and/or data are corrupted or suspected to be corrupted. These 624 procedures describe how a secure environment is re-established, 625 whether the Key Signing Key or Zone Signing key requires a roll 626 over, how to assess the damage and carry out the root cause 627 analysis. 628 o The recovery procedures used if the Key Signing Key or Zone 629 Signing Key is compromised. These procedures describe how a 630 secure environment is re- established, how the keys are rolled 631 over, how the new Trust Anchor is provided to the users and how 632 new zone file is published. 633 o The entity's capabilities to ensure business continuity following 634 a natural or other disaster. Such capabilities may include the 635 availability of a disaster recovery site at which operations may 636 be recovered. They may also include procedures for securing its 637 facility during the period of time following a natural or other 638 disaster and before a secure environment is re-established, either 639 at the original site or at a disaster recovery site. For example, 640 procedures to protect against theft of sensitive materials from an 641 earthquake-damaged site. 643 4.4.6. Entity termination 645 This subcomponent describes requirements relating to procedures for 646 termination, termination notification and transition of 647 responsibilities of a Registry. The major purpose is to ensure that 648 the transition process will be transparent to the relying party and 649 will not affect the service. 651 4.5. Technical Security Controls 653 This component is used to define the security measures taken by the 654 Registry to protect its cryptographic keys and activation data (e.g., 655 PINs, passwords, or manually-held key shares). Secure key management 656 is critical to ensure that all secret and private keys and activation 657 data are protected and used only by authorized personnel. 659 This component also describes other technical security controls used 660 by the Registry to perform securely the functions of key generation, 661 authentication, registration, auditing, and archiving. Technical 662 controls include life-cycle security controls (including software 663 development environment security, trusted software development 664 methodology) and operational security controls. 666 This component can also be used to define other technical security 667 controls on repositories, authoritative name servers or other 668 participants where applicable. 670 4.5.1. Key Pair Generation and Installation 672 Key pair generation and installation need to be considered for the 673 Registry. The following questions potentially need to be answered: 675 1. Who generates the Registry's public, private key pair? 676 Furthermore, how is the key generation performed? Is the key 677 generation performed by hardware or software? 678 2. How is the private key installed in all parts of the key 679 management system? 680 3. How is the Registry's public key provided securely to potential 681 relying parties? 682 4. Who generates the public key parameters, and is the quality of 683 the parameters checked during key generation? 684 5. For what purposes may the key be used, or for what purposes 685 should usage of the key be restricted? 687 4.5.2. Private key protection and Cryptographic Module Engineering 688 Controls 690 Requirements for private key protection and cryptographic modules 691 need to be considered for key generation and creation of signatures. 692 The following questions potentially need to be answered: 694 1. What standards, if any, are required for the cryptographic 695 module used to generate the keys? A cryptographic module can be 696 composed of hardware, software, firmware, or any combination of 697 them. For example, are the zones signatures required to be 698 generated using modules compliant with the US FIPS 140-2? If 699 so, what is the required FIPS 140-2 level of the module? Are 700 there any other engineering or other controls relating to a 701 cryptographic module, such as the identification of the 702 cryptographic module boundary, input/output, roles and services, 703 finite state machine, physical security, software security, 704 operating system security, algorithm compliance, electromagnetic 705 compatibility, and self tests. 706 2. Is the private key under n out of m multi-person control? If 707 yes, provide n and m (two person control is a special case of n 708 out of m, where n = m = 2)? 709 3. Is the private key escrowed? If so, who is the escrow agent, 710 what form is the key escrowed in (examples include plaintext, 711 encrypted, split key), and what are the security controls on the 712 escrow system? 713 4. Is the private key backed up? If so, who is the backup agent, 714 what form is the key backed up in (examples include plaintext, 715 encrypted, split key), and what are the security controls on the 716 backup system? 717 5. Is the private key archived? If so, who is the archival agent, 718 what form is the key archived in (examples include plaintext, 719 encrypted, split key), and what are the security controls on the 720 archival system? 721 6. Under what circumstances, if any, can a private key be 722 transferred into or from a cryptographic module? Who is 723 permitted to perform such a transfer operation? In what form is 724 the private key during the transfer (i.e., plaintext, encrypted, 725 or split key)? 726 7. How is the private key stored in the module (i.e., plaintext, 727 encrypted, or split key)? 728 8. Who can activate (use) the private key? What actions must be 729 performed to activate the private key (e.g., login, power on, 730 supply PIN, insert token/key, automatic, etc.)? Once the key is 731 activated, is the key active for an indefinite period, active 732 for one time, or active for a defined time period? 733 9. Who can deactivate the private key and how? Examples of methods 734 of deactivating private keys include logging out, turning the 735 power off, removing the token/key, automatic deactivation, and 736 time expiration. 737 10. Who can destroy the private key and how? Examples of methods of 738 destroying private keys include token surrender, token 739 destruction, and overwriting the key. 741 11. Provide the capabilities of the cryptographic module in the 742 following areas: identification of the cryptographic module 743 boundary, input/output, roles and services, finite state 744 machine, physical security, software security, operating system 745 security, algorithm compliance, electromagnetic compatibility, 746 and self tests. Capability may be expressed through reference 747 to compliance with a standard such as U.S. FIPS 140-2, 748 associated level, and rating. 750 4.5.3. Other Aspects of Key Pair Management 752 Other aspects of key management need to be considered for the 753 Registry and other participants. For each of these types of 754 entities, the following questions potentially need to be answered: 756 1. Is the public key archived? If so, who is the archival agent and 757 what are the security controls on the archival system? 758 2. What is the operational period of the keys. What are the usage 759 periods, or active lifetimes for the pairs? 761 4.5.4. Activation data 763 Activation data refers to data values other than whole private keys 764 that are required to operate private keys or cryptographic modules 765 containing private keys, such as a PIN, passphrase, or portions of a 766 private key used in a key-splitting scheme. Protection of activation 767 data prevents unauthorized use of the private key, and potentially 768 needs to be considered for the Registry. Such consideration 769 potentially needs to address the entire life-cycle of the activation 770 data from generation through archival and destruction. For each of 771 the entity types, all of the questions listed in 4.5.1 through 4.5.3 772 potentially need to be answered with respect to activation data 773 rather than with respect to keys. 775 4.5.5. Computer Security Controls 777 This subcomponent is used to describe computer security controls such 778 as: use of the trusted computing base concept, discretionary access 779 control, labels, mandatory access controls, object re-use, audit, 780 identification and authentication, trusted path, security testing, 781 and penetration testing. Product assurance may also be addressed. 783 A computer security rating for computer systems may be required. The 784 rating could be based, for example, on the Trusted System Evaluation 785 Criteria (TCSEC), Canadian Trusted Products Evaluation Criteria, 786 European Information Technology Security Evaluation Criteria (ITSEC), 787 or the Common Criteria for Information Technology Security 788 Evaluation, ISO/IEC 15408:1999. This subcomponent may also address 789 requirements for product evaluation analysis, testing, profiling, 790 product certification, and/or product accreditation related activity 791 undertaken. 793 4.5.6. Network Security Controls 795 This subcomponent addresses network security related controls, 796 including firewalls. 798 4.5.7. Timestamping 800 This subcomponent addresses requirements or practices relating to the 801 use of timestamps on various data. It may also discuss whether or 802 not the time-stamping application must use a trusted time source. 804 4.5.8. Life Cycle Technical Controls 806 This subcomponent addresses system development controls and security 807 management controls. 809 System development controls include development environment security, 810 development personnel security, configuration management security 811 during product maintenance, software engineering practices, software 812 development methodology, modularity, layering, use of failsafe design 813 and implementation techniques (e.g., defensive programming) and 814 development facility security. 816 Security management controls include execution of tools and 817 procedures to ensure that the operational systems and networks adhere 818 to configured security. These tools and procedures include checking 819 the integrity of the security software, firmware, and hardware to 820 ensure their correct operation. 822 This subcomponent can also address life-cycle security ratings based, 823 for example, on the Trusted Software Development Methodology (TSDM) 824 level IV and V, independent life-cycle security controls audit, and 825 the Software Engineering Institute's Capability Maturity Model (SEI- 826 CMM). 828 4.6. Zone Signing 830 This component covers all aspects of zone signing including, the 831 cryptographic specification surrounding the Key Signing Key and Zone 832 Signing Key, methodology and signing scheme for key roll-over and the 833 actual zone signing. Child zones and other relying parties may 834 depend on the information in this section to understand the expected 835 data in the signed zone and determine their own behavior. In 836 addition, this section will be used to state the compliance to the 837 cryptographic and operational requirements pertaining to zone signing 838 if applicable. 840 4.6.1. Key lengths and algorithms 842 This subcomponent describes the key generation algorithm and the key 843 length used to create the Key Signing Key and the Zone Signing Key. 845 4.6.2. Authenticated denial of existence 847 Authenticated denial of existence refers to the usage of NSEC (RFC 848 4034 [RFC4034]), NSEC3 (RFC 5155 [RFC5155]) or any other record 849 defined in the future that is used to authenticate the denial of 850 existence of the resource record. 852 4.6.3. Signature format 854 This subcomponent is used to describe the signing method and 855 algorithms used for the zone signing. 857 4.6.4. Zone signing key roll-over 859 This subcomponent explains the Zone signing key roll-over scheme. 861 4.6.5. Key signing key roll-over 863 This subcomponent addresses the Key signing key roll-over scheme. 865 4.6.6. Signature life-time and re-signing frequency 867 This subcomponent identifies the life-cycle of the Resource Record 868 Signature (RRSIG) record. 870 4.6.7. Verification of zone signing key set 872 This subsection addresses the controls around the keyset signing 873 process performed by the Key Signing Key. The procedures surrounding 874 KSK management may be different from those of the ZSK, hence it may 875 be necessary to authenticate the data signed by the KSK. 877 4.6.8. Verification of resource records 879 This subsection addresses the controls around the verification of the 880 resource records in order to validate and authenticate the data to be 881 signed. 883 4.6.9. Resource records time-to-live 885 This subcomponent specifies the time-to-live (TTL) for each DNSSEC 886 related resource record such as DNSKEY, NSEC/NSEC3, DS and RRSIG. 888 4.7. Compliance Audit 890 The ideal and the only way to prove the statements in the DNSSEC 891 Signing Policy or Practices Statement is to conduct an audit. This 892 component describes the outline of how the audit is conducted at the 893 registry. 895 4.7.1. Frequency of entity compliance audit 897 This subcomponent describes the frequency of the compliance audit. 898 An audit could be considered as a health check of the service 899 therefore it is ideal to have an audit at least once a year to know 900 the current status. 902 4.7.2. Identity/qualifications of auditor 904 This subcomponent addresses what is the qualifications for the 905 auditor. For instance it may be an auditor from a specific 906 association or an auditor that has a certain certifications. 908 4.7.3. Auditor's relationship to audited party 910 This subcomponent is used to clarify the relationship between the 911 auditor and the entity being audited. This becomes important if 912 there is any requirements or guidlines for selection of the auditor. 914 4.7.4. Topics covered by audit 916 Topics covered by audit refers to the scope of the audit. Since the 917 DNSSEC Signing Policy and Practices Statement is the document to be 918 audited against, it is ideal to set the scope to the scope of the 919 DPS. However, the scope may be narrowed down or expanded as needed 920 for example in case there is not enough resources to conduct a full 921 audit, or some portion is under development and not ready for the 922 audit. 924 4.7.5. Actions taken as a result of deficiency 926 This subcomponent specifies the action taken in order to correct any 927 discrepancy. This could be the remediation process for the audit 928 findings or any other action to correct any descrepancy with the 929 DNSSEC Signing Policy or Practices Statement. 931 4.7.6. Communication of results 933 4.8. Legal Matters 935 This component covers legal matters. Sections 8.1 and 8.2 of the 936 framework discuss the business issues of fees to be charged for 937 various services and the financial responsibility of participants to 938 maintain resources for ongoing operations and for paying judgments or 939 settlements in response to claims asserted against them. The 940 remaining sections are generally concerned with legal topics. 942 With respect to many of the legal subcomponents within this 943 component, a DPS drafter may choose to include in the document terms 944 and conditions that apply directly to registrants or relying parties. 945 For instance, a Registry may set forth limitations of liability that 946 apply to registrants and relying parties. The inclusion of terms and 947 conditions is likely to be appropriate where the DPS is itself a 948 contract or part of a contract. 950 In other cases, however, the DPS is not a contract or part of a 951 contract; instead, it is configured so that its terms and conditions 952 are applied to the parties by separate documents, which may include 953 associated agreements, such as registrar or registrant agreements. 954 In that event, a DPS drafter may write a Polict so as to require that 955 certain legal terms and conditions appear (or not appear) in such 956 associated agreements. For example, a Signing Policy might include a 957 subcomponent stating that a certain limitation of liability term must 958 appear in a Registrys registrant agreements. Another example is a 959 Signing Policy that contains a subcomponent prohibiting the use of a 960 registrar or registrant agreement containing a limitation upon 961 Registry liability inconsistent with the provisions of the Signing 962 Policy. A DPS drafter may use legal subcomponents to disclose that 963 certain terms and conditions appear in associated agreements in use 964 by the Registry. A DPS might explain, for instance, that the 965 Registry writing it uses an associated registrar or registrant 966 agreement that applies a particular provision for limiting liability. 968 4.8.1. Fees 970 This subcomponent contains any applicable provisions regarding fees 971 charged by the Registry for DNSSEC or services related to DNSSEC. 973 4.8.2. Financial responsibility 975 This subcomponent contains requirements or disclosures relating to 976 the resources available to the Registry, and to remain solvent and 977 pay damages in the event they are liable to pay a judgment or 978 settlement in connection with a claim arising out of such operations. 980 Such provisions include: 982 o A statement that the participant maintains a certain amount of 983 insurance coverage for its liabilities to other participants; 984 o A statement that a participant has access to other resources to 985 support operations and pay damages for potential liability, which 986 may be couched in terms of a minimum level of assets necessary to 987 operate and cover contingencies that might occur, and a right 988 under an agreement to an indemnity under certain circumstances; 989 and 990 o A statement that a participant has a program that offers first- 991 party insurance or warranty protection to other participants in 992 connection with their use of the Registry services. 994 4.8.3. Confidentiality of business information 996 This subcomponent contains provisions relating to the treatment of 997 confidential business information. Specifically, this subcomponent 998 addresses: 1000 o The scope of what is considered confidential information; 1001 o The types of information that are considered to be outside the 1002 scope of confidential information; and 1003 o The responsibilities of participants that receive confidential 1004 information to secure it from compromise, and refrain from using 1005 it or disclosing it to third parties. 1007 4.8.4. Privacy of personal information 1009 This subcomponent relates to the protection that participants, 1010 particularly the Registry, may be required to afford to personally 1011 identifiable private information of registrants and other 1012 participants. Specifically, this subcomponent addresses the 1013 following, to the extent pertinent under applicable law: 1015 o The designation and disclosure of the applicable privacy plan that 1016 applies to a participant's activities, if required by applicable 1017 law or policy; 1018 o Information that is or is not considered private within the 1019 Registry; 1020 o Any responsibility of participants that receive private 1021 information to secure it, and refrain from using it and from 1022 disclosing it to third parties; 1023 o Any requirements as to notices to, or consent from individuals 1024 regarding use or disclosure of private information; and 1026 o Any circumstances under which a participant is entitled or 1027 required to disclose private information pursuant to judicial, 1028 administrative process in a private or governmental proceeding, or 1029 in any legal proceeding. 1031 4.8.5. Limitations of liability 1033 This subcomponent can include limitations of liability in a DPS or 1034 limitations that appear or must appear in an agreement associated 1035 with the DPS, such as a registrar or registrant agreement. These 1036 limitations may fall into one of two categories: limitations on the 1037 elements of damages recoverable and limitations on the amount of 1038 damages recoverable, also known as liability caps. Often, contracts 1039 contain clauses preventing the recovery of elements of damages such 1040 as incidental and consequential damages, and sometimes punitive 1041 damages. Frequently, contracts contain clauses that limit the 1042 possible recovery of one party or the other to an amount certain or 1043 to an amount corresponding to a benchmark, such as the amount a 1044 vendor was paid under the contract. 1046 4.8.6. Term and termination 1048 This subcomponent can include the time period in which a DPS remains 1049 in force and the circumstances under which the document, portions of 1050 the document, or its applicability to a particular participant can be 1051 terminated. In addition or alternatively, the DPS may include 1052 requirements that certain term and termination clauses appear in 1053 agreements, such as registrar or registrant agreements. In 1054 particular, such terms can include: 1056 o The term of a document or agreement, that is, when the document 1057 becomes effective and when it expires if it is not terminated 1058 earlier. 1059 o Termination provisions stating circumstances under which the 1060 document, certain portions of it, or its application to a 1061 particular participant ceases to remain in effect. 1062 o Any consequences of termination of the document. For example, 1063 certain provisions of an agreement may survive its termination and 1064 remain in force. Examples include acknowledgements of 1065 intellectual property rights and confidentiality provisions. 1066 Also, termination may trigger a responsibility of parties to 1067 return confidential information to the party that disclosed it. 1069 5. Outline of a set of provisions 1070 1. INTRODUCTION 1071 1.1. Overview 1072 1.2. Document name and identification 1073 1.3. Community and Applicability 1074 1.3.1. Registry 1075 1.3.2. Registrar 1076 1.3.3. Registrant 1077 1.3.4. Relying Party 1078 1.3.5 Auditor 1079 1.3.4. Applicability 1080 1.4. Specification Administration 1081 1.4.1. Specification administration organization 1082 1.4.2. Contact Information 1083 1.4.3. Specification change procedures 1084 2. PUBLICATION AND REPOSITORIES 1085 2.1. Repositories 1086 2.2. Publication of key signing keys 1087 2.3. Access controls on repositories 1088 3. OPERATIONAL REQUIREMENTS 1089 3.1. Meaning of domain names 1090 3.2. Activation of DNSSEC for child zone 1091 3.3. Identification and authentication of child zone manager 1092 3.4. Registration of delegation signer (DS) resource records 1093 3.5. Method to prove possession of private key 1094 3.6. Removal of DS record 1095 3.6.1. Who can request removal 1096 3.6.2. Procedure for removal request 1097 3.6.3. Emergency removal request 1098 4. FACILITY, MANAGEMENT AND OPERATIONAL CONTROLS 1099 4.1. Physical Controls 1100 4.1.1. Site location and construction 1101 4.1.2. Physical access 1102 4.1.3. Power and air conditioning 1103 4.1.4. Water exposures 1104 4.1.5. Fire prevention and protection 1105 4.1.6. Media storage 1106 4.1.7. Waste disposal 1107 4.1.8. Off-site backup 1108 4.2. Procedural Controls 1109 4.2.1. Trusted roles 1110 4.2.2. Number of persons required per task 1111 4.2.3. Identification and authentication for each role 1112 4.2.4. Tasks requiring separation of duties 1113 4.3. Personnel Controls 1114 4.3.1. Qualifications, experience, and clearance 1115 requirements 1116 4.3.2. Background check procedures 1117 4.3.3. Training requirements 1118 4.3.4. Retraining frequency and requirements 1119 4.3.5. Job rotation frequency and sequence 1120 4.3.6. Sanctions for unauthorized actions 1121 4.3.7. Contracting personnel requirements 1122 4.3.8. Documentation supplied to personnel 1123 4.4. Audit Logging Procedures 1124 4.4.1. Types of events recorded 1125 4.4.2. Frequency of processing log 1126 4.4.3. Retention period for audit log information 1127 4.4.4. Protection of audit log 1128 4.4.5. Audit log backup procedures 1129 4.4.6. Audit collection system 1130 4.4.7. Notification to event-causing subject 1131 4.4.8. Vulnerability assessments 1132 4.5. Compromise and Disaster Recovery 1133 4.5.1. Incident and compromise handling procedures 1134 4.5.2. Corrupted computing resources, software, and/or 1135 data 1136 4.5.3. Entity private key compromise procedures 1137 4.5.4. Business Continuity and IT Disaster Recovery 1138 Capabilities 1139 4.6. Entity termination 1140 5. TECHNICAL SECURITY CONTROLS 1141 5.1. Key Pair Generation and Installation 1142 5.1.1. Key pair generation 1143 5.1.2. Public key delivery 1144 5.1.3. Public key parameters generation and quality 1145 checking 1146 5.1.4. Key usage purposes 1147 5.2. Private key protection and Cryptographic Module 1148 Engineering Controls 1149 5.2.1. Cryptographic module standards and controls 1150 5.2.2. Private key (m-of-n) multi-person control 1151 5.2.3. Private key escrow 1152 5.2.4. Private key backup 1153 5.2.5. Private key storage on cryptographic module 1154 5.2.6. Private key archival 1155 5.2.7. Private key transfer into or from a cryptographic 1156 module 1157 5.2.8. Method of activating private key 1158 5.2.9. Method of deactivating private key 1159 5.2.10. Method of destroying private key 1160 5.3. Other Aspects of Key Pair Management 1161 5.3.1. Public key archival 1162 5.3.2. Key usage periods 1163 5.4. Activation data 1164 5.4.1. Activation data generation and installation 1165 5.4.2. Activation data protection 1166 5.4.3. Other aspects of activation data 1167 5.5. Computer Security Controls 1168 5.6. Network Security Controls 1169 5.7. Timestamping 1170 5.8. Life Cycle Technical Controls 1171 5.8.1. System development controls 1172 5.8.2. Security management controls 1173 5.8.3. Life cycle security controls 1174 6. ZONE SIGNING 1175 6.1. Key lengths and algorithms 1176 6.2. Authenticated denial of existence 1177 6.3. Signature format 1178 6.4. Zone signing key roll-over 1179 6.5. Key signing key roll-over 1180 6.6. Signature life-time and re-signing frequency 1181 6.7. Verification of zone signing key set 1182 6.8. Verification of resource records 1183 6.9. Resource records time-to-live 1184 7. COMPLIANCE AUDIT 1185 7.1. Frequency of entity compliance audit 1186 7.2. Identity/qualifications of auditor 1187 7.3. Auditor's relationship to audited party 1188 7.4. Topics covered by audit 1189 7.5. Actions taken as a result of deficiency 1190 7.6. Communication of results 1191 8. LEGAL MATTERS 1192 8.1. Fees 1193 8.2. Financial responsibility 1194 8.3. Confidentiality of business information 1195 8.3.1. Scope of confidential information 1196 8.3.2. Information not within the scope of confidential 1197 information 1198 8.3.3. Responsibility to protect confidential information 1199 8.4. Privacy of personal information 1200 8.4.1. Information treated as private 1201 8.4.2. Information not deemed private 1202 8.4.3. Responsibility to protect private information 1203 8.4.4. Disclosure Pursuant to Judicial or Administrative 1204 Process 1205 8.5. Limitations of liability 1206 8.6. Term and termination 1207 8.6.1. Term 1208 8.6.2. Termination 1209 8.6.3. Dispute resolution provisions 1210 8.6.4. Governing law 1212 6. Security Considerations 1214 The sensitivity of the information protected by DNSSEC on all levels 1215 in the DNS tree will vary significantly. There are also not any 1216 restrictions of what kinds of information that can be protected using 1217 DNSSEC. Entities must evaluate their own environment and the chain 1218 of trust originating from their Trust Anchor, the associated threats 1219 and vulnerabilities, to determine the level of risk they are willing 1220 to accept. 1222 7. Acknowledgements 1224 The authors gratefully acknowledges, in no particular order, the 1225 contributions of the following persons: 1226 Richard Lamb 1227 Jakob Schlyter 1229 8. References 1231 8.1. Normative References 1233 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1234 Rose, "DNS Security Introduction and Requirements", 1235 RFC 4033, March 2005. 1237 8.2. Informative References 1239 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 1240 Wu, "Internet X.509 Public Key Infrastructure Certificate 1241 Policy and Certification Practices Framework", RFC 3647, 1242 November 2003. 1244 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1245 Rose, "Resource Records for the DNS Security Extensions", 1246 RFC 4034, March 2005. 1248 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1249 Security (DNSSEC) Hashed Authenticated Denial of 1250 Existence", RFC 5155, March 2008. 1252 Authors' Addresses 1254 Fredrik Ljunggren 1255 Kirei AB 1256 P.O. Box 53204 1257 Goteborg SE-400 16 1258 Sweden 1260 Email: fredrik@kirei.se 1262 Anne-Marie Eklund-Lowinder 1263 .SE (The Internet Infrastructure Foundation) 1264 P.O. Box 7399 1265 Stockholm SE-103 91 1266 Sweden 1268 Email: amel@iis.se 1270 Tomofumi Okubo 1271 VeriSign Inc. 1272 21345 Ridgetop Circle 1273 Dulles, VA 20166-6503 1274 USA 1276 Email: tookubo@verisign.com