idnits 2.17.1 draft-ietf-dnsop-dnssec-dps-framework-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (July 31, 2010) is 5018 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 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: February 1, 2011 .SE 6 T. Okubo 7 ICANN 8 July 31, 2010 10 DNSSEC Policy & Practice Statement Framework 11 draft-ietf-dnsop-dnssec-dps-framework-02 13 Abstract 15 This document presents a framework to assist writers of DNSSEC Policy 16 and Practice Statements such as Domain Managers and Zone Operators on 17 both the top-level and secondary level, who is managing and operating 18 a DNS zone with Security Extensions (DNSSEC) implemented. 20 In particular, the framework provides a comprehensive list of topics 21 that should be considered for inclusion into a DNSSEC Policy 22 definition and Practice Statement. 24 Status of this Memo 26 This Internet-Draft is submitted 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). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on February 1, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.1. DPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.2. DP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.3. Relationship between DNSSEC Policy and Practice 67 Statement . . . . . . . . . . . . . . . . . . . . . . . . 8 68 3.4. Set of provisions . . . . . . . . . . . . . . . . . . . . 9 69 4. Contents of a set of provisions . . . . . . . . . . . . . . . 10 70 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.1.2. Document Name and Identification . . . . . . . . . . . 11 73 4.1.3. Community and Applicability . . . . . . . . . . . . . 11 74 4.1.4. Specification Administration . . . . . . . . . . . . . 11 75 4.2. Publication and Repositories . . . . . . . . . . . . . . . 11 76 4.3. Operational Requirements . . . . . . . . . . . . . . . . . 12 77 4.3.1. Meaning of domain names . . . . . . . . . . . . . . . 12 78 4.3.2. Activation of DNSSEC for child zone . . . . . . . . . 12 79 4.3.3. Identification and authentication of child zone 80 manager . . . . . . . . . . . . . . . . . . . . . . . 12 81 4.3.4. Registration of delegation signer (DS) resource 82 records . . . . . . . . . . . . . . . . . . . . . . . 12 83 4.3.5. Method to prove possession of private key . . . . . . 12 84 4.3.6. Removal of DS resource records . . . . . . . . . . . . 12 85 4.4. Facility, Management and Operational Controls . . . . . . 13 86 4.4.1. Physical Controls . . . . . . . . . . . . . . . . . . 13 87 4.4.2. Procedural Controls . . . . . . . . . . . . . . . . . 13 88 4.4.3. Personnel Controls . . . . . . . . . . . . . . . . . . 14 89 4.4.4. Audit Logging Procedures . . . . . . . . . . . . . . . 14 90 4.4.5. Compromise and Disaster Recovery . . . . . . . . . . . 15 91 4.4.6. Entity termination . . . . . . . . . . . . . . . . . . 16 92 4.5. Technical Security Controls . . . . . . . . . . . . . . . 16 93 4.5.1. Key Pair Generation and Installation . . . . . . . . . 16 94 4.5.2. Private key protection and Cryptographic Module 95 Engineering Controls . . . . . . . . . . . . . . . . . 17 97 4.5.3. Other Aspects of Key Pair Management . . . . . . . . . 18 98 4.5.4. Activation data . . . . . . . . . . . . . . . . . . . 18 99 4.5.5. Computer Security Controls . . . . . . . . . . . . . . 18 100 4.5.6. Network Security Controls . . . . . . . . . . . . . . 19 101 4.5.7. Timestamping . . . . . . . . . . . . . . . . . . . . . 19 102 4.5.8. Life Cycle Technical Controls . . . . . . . . . . . . 19 103 4.6. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 19 104 4.6.1. Key lengths and algorithms . . . . . . . . . . . . . . 20 105 4.6.2. Authenticated denial of existence . . . . . . . . . . 20 106 4.6.3. Signature format . . . . . . . . . . . . . . . . . . . 20 107 4.6.4. Zone signing key roll-over . . . . . . . . . . . . . . 20 108 4.6.5. Key signing key roll-over . . . . . . . . . . . . . . 20 109 4.6.6. Signature life-time and re-signing frequency . . . . . 20 110 4.6.7. Verification of zone signing key set . . . . . . . . . 20 111 4.6.8. Verification of resource records . . . . . . . . . . . 20 112 4.6.9. Resource records time-to-live . . . . . . . . . . . . 21 113 4.7. Compliance Audit . . . . . . . . . . . . . . . . . . . . . 21 114 4.7.1. Frequency of entity compliance audit . . . . . . . . . 21 115 4.7.2. Identity/qualifications of auditor . . . . . . . . . . 21 116 4.7.3. Auditor's relationship to audited party . . . . . . . 21 117 4.7.4. Topics covered by audit . . . . . . . . . . . . . . . 21 118 4.7.5. Actions taken as a result of deficiency . . . . . . . 21 119 4.7.6. Communication of results . . . . . . . . . . . . . . . 22 120 4.8. Legal Matters . . . . . . . . . . . . . . . . . . . . . . 22 121 4.8.1. Fees . . . . . . . . . . . . . . . . . . . . . . . . . 22 122 4.8.2. Financial responsibility . . . . . . . . . . . . . . . 22 123 4.8.3. Confidentiality of business information . . . . . . . 22 124 4.8.4. Privacy of personal information . . . . . . . . . . . 23 125 4.8.5. Limitations of liability . . . . . . . . . . . . . . . 23 126 4.8.6. Term and termination . . . . . . . . . . . . . . . . . 23 127 5. Outline of a set of provisions . . . . . . . . . . . . . . . . 24 128 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 129 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 130 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 131 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 132 8.2. Informative References . . . . . . . . . . . . . . . . . . 28 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 135 1. Introduction 137 1.1. Background 139 The DNS was not originally designed with strong security mechanisms 140 to provide integrity and authenticity of DNS data. Over the years, a 141 number of vulnerabilities have been discovered that threaten the 142 reliability and trustworthiness of the system. 144 The Domain Name System Security Extensions (DNSSEC, [RFC4033]) is a 145 set of IETF specifications which addresses these vulnerabilities by 146 adding data origin authentication, data integrity verification and 147 authenticated denial of existence capabilities to the Domain Name 148 System, using public key cryptography. In short, DNSSEC provides a 149 way for software to validate that Domain Name System (DNS) data has 150 not been modified during transit. 152 To provide means for the relying parties to evaluate the strength and 153 security of the DNSSEC chain of trust, an entity operating a DNSSEC 154 enabled zone may choose to publish a DNSSEC Practice Statement (DPS), 155 comprising statements of critical security controls and procedures 156 relevant for scrutinizing the trustworthiness of the system. The DPS 157 may also identify one or more DNSSEC Policies which are supported, 158 explaining how it meets the requirements of each Policy. 160 Even though this document is heavily inspired by the Internet X.509 161 Public Key Infrastructure Certificate Policy and Certification 162 Practices Framework [RFC3647], and large parts drawn from that 163 document, the properties and structure of the DNSSEC PKI is 164 fundamentally different from the X.509 PKI. 166 In the DNSSEC PKI there is no central control of assurance or trust 167 levels. Each zone manager may select their own way of managing keys 168 and operations, and there is no necessity to perform any coordination 169 of security practices between different zones in the DNS. The degree 170 to which a relying party can trust the binding embodied in the DNSSEC 171 chain of trust is dependent on the weakest link of that chain. This 172 implies that the security of zones is generally more critical higher 173 up in the DNS hierarchy. 175 Another significant difference is that the DPS is focused only on 176 stating the security posture of a zone, rather than for all 177 participants in the domain name system. The DNS is of a almost 178 ubiquitous nature, and there exists no agreements with the relying 179 (third) parties, which is all entities relying on signed responses 180 from the DNS. 182 1.2. Purpose 184 The purpose of this document is twofold. Firstly, the document aims 185 to explain the concept of a DPS and describe the relationship between 186 a DNSSEC Policy (DP) and a DNSSEC Practice Statement (DPS). Second, 187 this document aims to present a framework to encourage and assist 188 writers of Policies and Practice Statements in creating heterogenous 189 and comparable documents. In particular, the framework identifies 190 the elements that should be considered in formulating a DP/DPS. The 191 purpose is not to define a particular Policy or Practice Statement, 192 per se. Moreover, this document does not aim to provide legal advice 193 or recommendations as to particular requirements or practices that 194 should be contained within a DP/DPS. 196 1.3. Scope 198 The scope of this document is limited to discussion of the topics 199 that can be covered in a DP/DPS and does not go into the specific 200 details that could possibly be included in each one. In particular, 201 this document describes the types of information that should be 202 considered for inclusion in a DP/DPS. 204 The DNSSEC Policy and Practice Statement framework should be viewed 205 and used as a checklist of factors that should be taken in to 206 consideration prior to deploying DNSSEC, and an outline to create a 207 operational practices disclosure document. It is primarily aimed at 208 TLD managers and organizations providing registry services, but may 209 be used by high-value domain holders and serve as a check sheet for 210 DNSSEC readiness at a high level. 212 This document assumes that the reader is familiar with the general 213 concepts of DNS, DNSSEC and PKI. 215 2. Definitions 217 This document makes use of the following defined terms: 219 Chain of Trust - Chain of Trust is a hierarchical structure of trust 220 that consists the Key Signing Keys, Zone Signing Keys and the 221 Delegation Signer Records. 223 DNS - The Domain Name System (DNS) is a hierarchical global naming 224 catalog for computers, services, or any resource connected to the 225 Internet. It associates various information with domain names 226 assigned to each of the participants. 228 DNS Zone - A portion of the global Domain Name System (DNS) namespace 229 for which administrative responsibility has been delegated. 231 DNSSEC Policy - A DNSSEC Policy sets forth the requirements and 232 standards to be implemented for a DNSSEC signed zone. A Practice 233 Statement may support a Policy by explaining how it meets the 234 requirements of the Policy. 236 DNSSEC Practices Statement - A DNSSEC Practices Statement is a 237 practices disclosure document which may be a supplemental document to 238 the DNSSEC Policy (if such exists) and states how the management of a 239 given zone implements procedures and controls at a high level. 241 Relying Party - All entities that relies on the signed response from 242 the DNS. 244 Security Posture - A Security Posture is a barometer that indicates 245 how secure the entity is and how secure the entity should be which is 246 a result of an adequate threat modelling, vulnerability assessment 247 and risk assessment. 249 Trust Anchor - Public portion of the Key Signing Key which is the 250 authoritative entity used to cryptographically validate the chain of 251 trust to the signed resource record. 253 Key Roll Over - A operational process of DNSSEC to change either the 254 Key Signing Key or the Zone Signing Key. 256 Repository - Repository is a location on the internet to store DP, 257 DPS, Trust Anchors and other related information that should be kept 258 public. 260 Compromise (Key Compromise) - Key Compromise is a situation where the 261 private component of the Key Signing Key or Zone Signing Key are 262 lost, stolen or exposed, modified or under unauthorized usage. More 263 strictly, even a suspicion will be enough to be considered as key 264 compromise. 266 Public Key Infrastructure - A concept that uses asymmetric 267 cryptography, which may provide integrity, authentication, 268 confidentiality and non-repudiation to a system. 270 Activation data - Data values, other than keys, that are required to 271 operate the cryptographic modules which are usually used to protect 272 the keys from unauthorized use. 274 Separation of Duties - A security concept that limits the influence 275 of a single person by segregating the roles and responsibilities. 277 Audit logs - Control evidence information generated by the DNS and 278 DNSSEC related systems, the surrounding facility or other manually 279 processed, non-electronic documentation to prove the integrity of 280 processes. Audit logs will be examined by the internal and/or 281 external auditors. 283 Policy Management Authority - A group formed by stake-holders from 284 each group within the organization operating DNSSEC. The group is 285 responsible for approving changes to the DPS. In addition, any other 286 matters that could possibly affect the DNSSEC operations are to be 287 discussed in this group. 289 3. Concepts 291 This section describes the concept of a DNSSEC Policy and of a DNSSEC 292 Practices Statement. Other related concepts are described as well. 294 3.1. DPS 296 Most DNSSEC participants may not have the need to create a thorough 297 and detailed statement of practices. For example, the registrant may 298 itself be the sole relying party of its own zone and would already be 299 aware of the nature and trustworthiness of its services. In other 300 cases, a zone manager may provide registration services providing 301 only a very low level of assurances where the domain names being 302 secured may pose only marginal risks if compromised. Publishing a 303 DPS is most relevant for entities operating a zone which contains a 304 significant number of delegations to other entities. 306 A DPS should contain information which is relevant to the 307 stakeholders of the relevant zone(s). Since these generally include 308 the Internet community, it should not contain such information which 309 could be considered to be sensitive details of an entity's 310 operations. 312 3.2. DP 314 The DP sets forth requirements that are appropriate for a determined 315 level of assurance. For example, a DP may encompass all topics of 316 this framework, each with a certain set of security requirements and 317 possibly grouped them into categories, such as medium impact and high 318 impact. The progression from medium to high levels would correspond 319 to increasing security requirements and corresponding increasing 320 levels of assurance. 322 A DPS may identify a supported DP, which may subsequently be used by 323 a relying party to evaluate the trustworthiness of any digital 324 signatures verified using the public key of that entity. 326 DPs also constitute a basis for an audit, accreditation, or another 327 assessment of an entity. Each entity can be assessed against one or 328 more DPs that it is recognized as implementing. 330 3.3. Relationship between DNSSEC Policy and Practice Statement 332 A DNSSEC Policy and a DNSSEC Practice Statement address the same set 333 of topics that are of interest to the stakeholders in terms of the 334 degree to which a DNSSEC digital signature may be trusted. Their 335 primary difference is in the focus of their provisions. A Policy 336 sets forth the requirements and standards to be implemented for a 337 DNSSEC signed zone. In other words, the purpose of the Policy is to 338 establish what entities must do. A Practice Statement, by contrast, 339 states how a zone operator and possibly other participants in the 340 management of a given zone implements procedures and controls to meet 341 the requirements stated in the Policy. In other words, the purpose 342 of the Practice Statement is to disclose how the participants perform 343 their functions and implement controls. 345 An additional difference between a Policy and a Practice Statement 346 relates the scope of coverage of the two kinds of documents. Since a 347 Policy is a statement of requirements, it best used for communicating 348 minimum operating guidelines that must be met by complying parties, 349 but may as such also be used to facilitate interoperation of level of 350 trust between zones. Thus, a Policy may apply to multiple 351 organizations or multiple zones. By contrast, a Practice Statement 352 would usually apply only to a single zone operator or a single 353 organization. 355 For example, a TLD Manager or regulatory authority may define 356 requirements in a Policy for operations of one or more zones. The 357 Policy will be a broad statement of the general requirements for 358 managing the zone. 360 A zone operator may be required to write its own Practice Statement 361 to support the Policy by explaining how it meets the requirements of 362 the Policy. Or, a zone operator which is also the manager of that 363 zone and not governed by any external Policy may still choose to 364 disclose operational practices by publishing a DPS, for the purpose 365 of providing transparency and gain community trust in the operations. 367 An additional difference between a Policy and a Practice Statement 368 concerns the level of detail of the provisions in each. Although the 369 level of detail may vary, a Practice Statement will generally be more 370 detailed than a Policy. A Practice Statement provides a detailed 371 description of procedures and controls in place to meet the Policy 372 requirements, while a Policy is more general. 374 The main differences between a Policy and Practice Statement can 375 therefore be summarized as follows: 377 (a) Operation of a DNS zone with DNSSEC may be governed by a Policy, 378 to establish requirements that state what the entity operating 379 that zone must do. An entity can use a Practice Statement to 380 disclose how it meets the requirements of a Policy or how it has 381 implemented critical processes and controls. 382 (b) A Policy may facilitate interoperation of level of trust through 383 several parts or levels in the DNS hierarchy. By contrast, a 384 Practice Statement is a statement of a single zone operator or 385 organization. 386 (c) A Practice Statement is generally more detailed than a Policy 387 and specifies how the zone operator or organization implements 388 critical processes and controls, and how the entity meets any 389 requirements specified in the one or more Policies under which 390 it operates DNSSEC. 392 3.4. Set of provisions 394 A set of provisions is a collection of Policy requirements or 395 Practice statements, which may employ the approach described in this 396 framework by covering the topics appearing in Section 5 below. They 397 are also described in detail in Section 4 below. 399 A Policy can be expressed as a single set of provisions. 401 A Practice Statement can be expressed as a single set of provisions 402 with each component addressing the requirements of one or more 403 Policies, or, alternatively, as not referencing any particular policy 404 but used solely as to disclose any self-imposed provisions to the 405 relying parties. For example, a Practice Statement could be 406 expressed as a combination of the following: 408 (a) a list of Policies supported by the DPS; 409 (b) for each Policy in (a), a set of provisions that contains 410 statements responding to that Policy by filling in details not 411 stipulated in that policy or expressly left to the discretion of 412 the implementor; such statements serve to state how this 413 particular Practice Statement implements the requirements of the 414 particular Policy; or 415 (c) a set of provisions that contains statements regarding the 416 practices of the DNSSEC operations, regardless of any Policy. 418 The statements provided in (b) may augment or refine the stipulations 419 of an applicable Policy, but generally must not conflict with any of 420 the stipulations of such Policy. In certain cases, however, a Policy 421 Authority may permit exceptions to the requirements in a Policy, 422 because certain compensating controls of the entity are disclosed in 423 its Practices Statement, that allow the entity to provide assurances 424 that are equivalent to the assurances provided by entities that are 425 in full compliance with the Policy. 427 This framework outlines the contents of a set of provisions, in terms 428 of eight primary components, as follows: 430 1. Introduction 431 2. Publication and Repositories 432 3. Operational Requirements 433 4. Facility, Management, and Operational Controls 434 5. Technical Security Controls 435 6. Zone Signing 436 7. Compliance Audit 437 8. Legal Matters 439 Policy authorities can use this framework of eight primary components 440 to write a DNSSEC Policy. Moreover, a zone operator can use this 441 same framework to write a DNSSEC Practice Statement. 443 Therefore, an entity can establish a set of basic documents with the 444 same structure and ordering of topics, thereby facilitating 445 comparisons and mappings among these documents and among the 446 corresponding documents of other zones. 448 Drafters of DPSs in conformance with this framework are permitted to 449 add additional levels of subcomponents below the subcomponents 450 described in Section 4 for the purpose of meeting the needs of the 451 drafter's particular requirements. 453 4. Contents of a set of provisions 455 4.1. Introduction 457 This component identifies and introduces the set of provisions, and 458 indicates the types of entities and applications for which the 459 document (either the Policy or the Practice Statement being written) 460 is targeted. 462 4.1.1. Overview 464 This subcomponent provides a general introduction to the document 465 being written. This subcomponent can also be used to provide a 466 synopsis of the participants to which the Policy or Practice 467 Statement applies. 469 4.1.2. Document Name and Identification 471 This subcomponent provides any applicable names or other identifiers 472 of the document. 474 4.1.3. Community and Applicability 476 This subcomponent addresses the stakeholders in DNSSEC along with the 477 expected roles and responsibilities. This includes but are not 478 limited to an entity signing the zone, an entity that relies on the 479 signed zone, other entities that have operational dependency on the 480 signed zone and an entity that entrusted the zone signing. 482 4.1.4. Specification Administration 484 This subcomponent includes the name and mailing address of the 485 organization that is responsible for drafting, registering, 486 maintaining, and updating of the DP/DPS. It also includes the name, 487 electronic mail address and telephone number of a contact person. As 488 an alternative to naming an actual person, the document may name a 489 title or role, an e-mail alias, and other generalized contact 490 information. In some cases, the organization may state that its 491 contact person, alone or in combination with others, is available to 492 answer questions about the document. 494 Moreover, when a formal or informal Policy Authority is responsible 495 for determining whether a zone operator should be allowed to operate 496 a Zone, it may wish to approve the DPS of the zone operator as being 497 suitable for the Policy. If so, this subcomponent can include the 498 name or title, electronic mail address (or alias), telephone number 499 and other generalized information of the entity in charge of making 500 such a determination. Finally, in this case, this subcomponent also 501 includes the procedures by which this determination is made. 503 4.2. Publication and Repositories 505 This component contains any applicable provisions regarding: 507 o An identification of the entity or entities that operate 508 repositories within the community, such as a zone operator or a 509 TLD Manager; 510 o The responsibility of an entity to publish information regarding 511 its practices, public keys, and the current status of such keys, 512 which may include the responsibilities of making the DPS publicly 513 available using various mechanisms and of identifying components, 514 subcomponents, and elements of such documents that exist but are 515 not made publicly available, for instance, security controls, 516 clearance procedures, or business information due to their 517 sensitivity; 518 o When information must be published and the frequency of 519 publication; and 520 o Access control on published information objects. 522 4.3. Operational Requirements 524 This component describes the operational requirements when operating 525 a DNSSEC signed zone. 527 4.3.1. Meaning of domain names 529 This section describes the overall policy of child zone naming, if 530 any. 532 4.3.2. Activation of DNSSEC for child zone 534 This section describes the process of establishing the chain-of-trust 535 to the child zone by incorporating DS record(s) into the zone. 537 4.3.3. Identification and authentication of child zone manager 539 This section describes how the child zone manager has initially been 540 identified, and how any subsequent change request is authenticated as 541 to originate from the manager or its authorized representative. 543 4.3.4. Registration of delegation signer (DS) resource records 545 This section describes how the delegation signer resource records are 546 incorporated into the parent zone. 548 4.3.5. Method to prove possession of private key 550 This section describes how, if, or under which circumstances the 551 child zone manager is required to provide proof of the possession of 552 the private component of any current or subsequent child zone Key 553 Signing Key. 555 4.3.6. Removal of DS resource records 557 This section will explain how, when and under which circumstances the 558 DS record may be removed from the zone. 560 4.4. Facility, Management and Operational Controls 562 This component describes non-technical security controls (that is, 563 physical, procedural, and personnel controls) in use by the entity to 564 securely perform the DNSSEC related functions such as physical 565 access, key management, disaster recovery, auditing and archiving. 567 These non-technical security controls are critical for trusting the 568 signatures since lack of security may compromise DNSSEC operations 569 resulting for example, in the creation of signatures with erroneous 570 information or compromising the Key Signing Key and/or Zone Signing 571 Key. 573 Within each subcomponent, separate consideration will, in general, 574 need to be given to each entity type. 576 4.4.1. Physical Controls 578 In this subcomponent, the physical controls on the facility housing 579 the entity systems are described. Topics addressed may include: 581 o Site location and construction, such as the construction 582 requirements for high-security areas and the use of locked rooms, 583 cages, safes, and cabinets; 584 o Physical access, i.e., mechanisms to control access from one area 585 of the facility to another or access into high-security zones, 586 such as locating DNSSEC operations in a secure computer room 587 monitored by guards, cameras or security alarms and requiring 588 movement from zone to zone to be accomplished using tokens and/or 589 PINs; 590 o Power and air conditioning; 591 o Water exposures; 592 o Fire prevention and protection; 593 o Media storage, for example, requiring the storage of backup media 594 in a separate location that is physically secure and protected 595 from fire, smoke, particle and water damage; 596 o Waste disposal; and 597 o Off-site backup. 599 4.4.2. Procedural Controls 601 In this subcomponent, requirements for recognizing trusted roles are 602 described, together with the responsibilities for each role. 603 Examples of trusted roles include system administrators, security 604 officers, and system auditors. 606 For each task identified, the number of individuals required to 607 perform the task (n of m rule, if applicable) should be stated for 608 each role. Identification and authentication requirements for each 609 role may also be defined. 611 This component also includes the separation of duties in terms of the 612 roles that cannot be performed by the same individuals. 614 4.4.3. Personnel Controls 616 This subcomponent addresses the following: 618 o Qualifications, experience, and clearances that personnel must 619 have as a condition of filling trusted roles or other important 620 roles. Examples include credentials, job experiences, and 621 official government clearances that candidates for these positions 622 must have before being hired; 623 o Background checks and clearance procedures that are required in 624 connection with the hiring of personnel filling trusted roles or 625 perhaps other important roles; such roles may require a check of 626 their criminal records, financial records, references, and 627 additional clearances that a participant undertakes after a 628 decision has been made to hire a particular person; 629 o Training requirements and training procedures for each role 630 following the hiring of personnel; 631 o Any retraining period and retraining procedures for each role 632 after completion of initial training; 633 o Frequency and sequence for job rotation among various roles; 634 o Sanctions against personnel for unauthorized actions, unauthorized 635 use of authority, and unauthorized use of the entity systems; 636 o Controls on personnel that are independent contractors rather than 637 employees of the entity; examples include: 639 * Bonding requirements on contract personnel; 640 * Contractual requirements including indemnification for damages 641 due to the actions of the contractor personnel; 642 * Auditing and monitoring of contractor personnel; and 643 * Other controls on contracting personnel. 645 o Documentation to be supplied to personnel during initial training, 646 retraining, or otherwise. 648 4.4.4. Audit Logging Procedures 650 This subcomponent is used to describe event logging and audit 651 systems, implemented for the purpose of maintaining an audit trail 652 and provide evidence of processes' integrity. Elements include the 653 following: 655 o Types of events recorded, such as attempts to access the system, 656 and requests made to the system; 657 o Frequency with which audit logs are processed or archived, for 658 example, weekly, following an alarm or anomalous event, or when 659 ever the audit log is n% full; 660 o Period for which audit logs are kept; 661 o Protection of audit logs: 663 * Who can view audit logs, for example only the audit 664 administrator; 665 * Protection against modification of audit logs, for instance a 666 requirement that no one may modify or delete the audit records 667 or that only an audit administrator may delete an audit file as 668 part of rotating the audit file; and 669 * Protection against deletion of audit logs. 671 o Audit log back up procedures; 672 o Whether the audit log accumulation function is internal or 673 external to the system; 674 o Whether the subject who caused an audit event to occur is notified 675 of the audit action; and 676 o Vulnerability assessments, for example, where audit data is run 677 through a tool that identifies potential attempts to breach the 678 security of the system. 680 4.4.5. Compromise and Disaster Recovery 682 This subcomponent describes requirements relating to notification and 683 recovery procedures in the event of compromise or disaster. Each of 684 the following may need to be addressed separately: 686 o Identification or listing of the applicable incident and 687 compromise reporting and handling procedures. 688 o The recovery procedures used if computing resources, software, 689 and/or data are corrupted or suspected to be corrupted. These 690 procedures describe how a secure environment is re-established, 691 whether the Key Signing Key or Zone Signing key requires a roll 692 over, how to assess the damage and carry out the root cause 693 analysis. 694 o The recovery procedures used if the Key Signing Key or Zone 695 Signing Key is compromised. These procedures describe how a 696 secure environment is re-established, how the keys are rolled 697 over, how a new Trust Anchor is provided to the users (if 698 applicable) and how new zone is published. 699 o The entity's capabilities to ensure business continuity following 700 a natural or other disaster. Such capabilities may include the 701 availability of a disaster recovery site at which operations may 702 be recovered. They may also include procedures for securing its 703 facility during the period of time following a natural or other 704 disaster and before a secure environment is re-established, either 705 at the original site or at a disaster recovery site. For example, 706 procedures to protect against theft of sensitive materials from an 707 earthquake-damaged site. 709 4.4.6. Entity termination 711 This subcomponent describes requirements relating to procedures for 712 entity termination, termination notification and transition of 713 responsibilities of a zone operator or other entity, where the 714 purpose may be to ensure that the transition process will be 715 transparent to the relying parties and will not affect the services. 717 4.5. Technical Security Controls 719 This component is used to define the security measures taken to 720 protect the cryptographic keys and activation data (e.g., PINs, 721 passwords, or manually-held key shares) relevant to the DNSSEC 722 operations. Secure key management is critical to ensure that all 723 secret and private keys and activation data are protected and used 724 only by authorized personnel. 726 This component also describes other technical security controls used 727 to securely perform the functions of key generation, authentication, 728 registration, auditing, and archiving. Technical controls include 729 life-cycle security controls (including software development 730 environment security) and operational security controls. 732 This component can also be used to define other technical security 733 controls on repositories, authoritative name servers or other 734 participants where applicable. 736 4.5.1. Key Pair Generation and Installation 738 Key pair generation and installation need to be considered, whereas 739 the following questions potentially need to be answered: 741 1. Who generates the zone's public, private key pairs? Furthermore, 742 how is the key generation performed? Is the key generation 743 performed by hardware or software? 744 2. How is the private key installed in all parts of the key 745 management system? 747 3. How is the zones's public keys provided securely to parent zone 748 and potential relying parties? 749 4. Who generates the public key parameters, and is the quality of 750 the parameters checked during key generation? 751 5. For what purposes may the keys be used, or for what purposes 752 should usage of the key be restricted? 754 4.5.2. Private key protection and Cryptographic Module Engineering 755 Controls 757 Requirements for private key protection and cryptographic modules 758 need to be considered for key generation and creation of signatures. 759 The following questions potentially need to be answered: 761 1. What standards, if any, are required for the cryptographic 762 module used to generate the keys? A cryptographic module can be 763 composed of hardware, software, firmware, or any combination of 764 them. For example, are the zones signatures required to be 765 generated using modules compliant with the US FIPS 140-2? If 766 so, what is the required FIPS 140-2 level of the module? Are 767 there any other engineering or other controls relating to a 768 cryptographic module, such as the identification of the 769 cryptographic module boundary, input/output, roles and services, 770 finite state machine, physical security, software security, 771 operating system security, algorithm compliance, electromagnetic 772 compatibility, and self tests. 773 2. Is the private key under n out of m multi-person control? If 774 yes, provide n and m (two person control is a special case of n 775 out of m, where n = m = 2)? 776 3. Is the private key escrowed? If so, who is the escrow agent, 777 what form is the key escrowed in (examples include plaintext, 778 encrypted, split key), and what are the security controls on the 779 escrow system? 780 4. Is the private key backed up? If so, who is the backup agent, 781 what form is the key backed up in (examples include plaintext, 782 encrypted, split key), and what are the security controls on the 783 backup system? 784 5. Is the private key archived? If so, who is the archival agent, 785 what form is the key archived in (examples include plaintext, 786 encrypted, split key), and what are the security controls on the 787 archival system? 788 6. Under what circumstances, if any, can a private key be 789 transferred into or from a cryptographic module? Who is 790 permitted to perform such a transfer operation? In what form is 791 the private key during the transfer (i.e., plaintext, encrypted, 792 or split key)? 794 7. How is the private key stored in the module (i.e., plaintext, 795 encrypted, or split key)? 796 8. Who can activate (use) the private key? What actions must be 797 performed to activate the private key (e.g., login, power on, 798 supply PIN, insert token/key, automatic, etc.)? Once the key is 799 activated, is the key active for an indefinite period, active 800 for one time, or active for a defined time period? 801 9. Who can deactivate the private key and how? Examples of methods 802 of deactivating private keys include logging out, turning the 803 power off, removing the token/key, automatic deactivation, and 804 time expiration. 805 10. Who can destroy the private key and how? Examples of methods of 806 destroying private keys include token surrender, token 807 destruction, and zeroizing the key. 809 4.5.3. Other Aspects of Key Pair Management 811 Other aspects of key management need to be considered for the zone 812 operator and other participants. For each of these types of 813 entities, the following questions potentially need to be answered: 815 1. Is the public key archived? If so, who is the archival agent and 816 what are the security controls on the archival system? 817 2. What is the operational period of the keys. What are the usage 818 periods, or active lifetimes for the pairs? 820 4.5.4. Activation data 822 Activation data refers to data values other than whole private keys 823 that are required to operate private keys or cryptographic modules 824 containing private keys, such as a PIN, passphrase, or portions of a 825 private key used in a key-splitting scheme. Protection of activation 826 data prevents unauthorized use of the private key, and potentially 827 needs to be considered for the zone operator and other participants. 828 Such consideration potentially needs to address the entire life-cycle 829 of the activation data from generation through archival and 830 destruction. For each of the entity types, all of the questions 831 listed in 4.5.1 through 4.5.3 potentially need to be answered with 832 respect to activation data rather than with respect to keys. 834 4.5.5. Computer Security Controls 836 This subcomponent is used to describe computer security controls such 837 as: use of the trusted computing base concept or equivalent, 838 discretionary access control, labels, mandatory access controls, 839 object re-use, audit, identification and authentication, trusted 840 path, and security testing. Product assurance may also be addressed. 842 A computer security rating for computer systems may be specified. 843 The rating could be based, for example, on a protection profile (PP) 844 of the Common Criteria for Information Technology Security 845 Evaluation, ISO/IEC 15408:1999. This subcomponent may also address 846 requirements for product evaluation analysis, testing, profiling, 847 product certification, and/or product accreditation related activity 848 undertaken. 850 4.5.6. Network Security Controls 852 This subcomponent addresses network security related controls, 853 including firewalls, routers and remote access. 855 4.5.7. Timestamping 857 This subcomponent addresses requirements or practices relating to the 858 use of timestamps on various data. It may also discuss whether or 859 not the time-stamping application must use a trusted time source. 861 4.5.8. Life Cycle Technical Controls 863 This subcomponent addresses system development controls and security 864 management controls. 866 System development controls include development environment security, 867 development personnel security, configuration management security 868 during product maintenance, software engineering practices, software 869 development methodology, modularity, layering, use of failsafe design 870 and implementation techniques (e.g., defensive programming) and 871 development facility security. 873 Security management controls include execution of tools and 874 procedures to ensure that the operational systems and networks adhere 875 to configured security. These tools and procedures include checking 876 the integrity of the security software, firmware, and hardware to 877 ensure their correct operation. 879 4.6. Zone Signing 881 This component covers all aspects of zone signing, including the 882 cryptographic specification surrounding the Key Signing Key and Zone 883 Signing Key, signing scheme and methodology for key roll-over and the 884 actual zone signing. Child zones and other relying parties may 885 depend on the information in this section to understand the expected 886 data in the signed zone and determine their own behavior. In 887 addition, this section will be used to state the compliance to the 888 cryptographic and operational requirements pertaining to zone signing 889 if applicable. 891 4.6.1. Key lengths and algorithms 893 This subcomponent describes the key generation algorithm and the key 894 length used to create the Key Signing Key and the Zone Signing Key. 896 4.6.2. Authenticated denial of existence 898 Authenticated denial of existence refers to the usage of NSEC (RFC 899 4034 [RFC4034]), NSEC3 (RFC 5155 [RFC5155]) or any other record 900 defined in the future that is used to authenticate the denial of 901 existence of the resource record. 903 4.6.3. Signature format 905 This subcomponent is used to describe the signing method and 906 algorithms used for the zone signing. 908 4.6.4. Zone signing key roll-over 910 This subcomponent explains the Zone signing key roll-over scheme. 912 4.6.5. Key signing key roll-over 914 This subcomponent addresses the Key signing key roll-over scheme. 916 4.6.6. Signature life-time and re-signing frequency 918 This subcomponent identifies the life-cycle of the Resource Record 919 Signature (RRSIG) record. 921 4.6.7. Verification of zone signing key set 923 This subsection addresses the controls around the keyset signing 924 process performed by the Key Signing Key. The procedures surrounding 925 KSK management may be different from those of the ZSK, hence it may 926 be necessary to authenticate the data signed by the KSK. 928 4.6.8. Verification of resource records 930 This subsection addresses the controls around the verification of the 931 resource records in order to validate and authenticate the data to be 932 signed. 934 4.6.9. Resource records time-to-live 936 This subcomponent specifies the time-to-live (TTL) for each DNSSEC 937 related resource record such as DNSKEY, NSEC/NSEC3, DS and RRSIG. 939 4.7. Compliance Audit 941 The ideal and the only way to prove the compliance with a Policy or 942 the statements in the Practices Statement is to conduct an audit. 943 This component describes the outline of how the audit is conducted at 944 the zone operator and possibly at other involved entities. 946 4.7.1. Frequency of entity compliance audit 948 This subcomponent describes the frequency of the compliance audit. 950 4.7.2. Identity/qualifications of auditor 952 This subcomponent addresses what is the qualifications for the 953 auditor. For instance it may be an auditor from a specific 954 association or an auditor that has a certain certifications. 956 4.7.3. Auditor's relationship to audited party 958 This subcomponent is used to clarify the relationship between the 959 auditor and the entity being audited. This becomes important if 960 there is any requirements or guidelines for selection of the auditor. 962 4.7.4. Topics covered by audit 964 Topics covered by audit refers to the scope of the audit. Since the 965 DNSSEC Policy and Practices Statement is the document to be audited 966 against, it is ideal to set the scope to the scope of the DP/DPS. 967 However, the scope may be narrowed down or expanded as needed for 968 example in case there is not enough resources to conduct a full 969 audit, or some portion is under development and not ready for the 970 audit. 972 4.7.5. Actions taken as a result of deficiency 974 This subcomponent specifies the action taken in order to correct any 975 discrepancy. This could be the remediation process for the audit 976 findings or any other action to correct any descrepancy with the 977 DNSSEC Policy or Practices Statement. 979 4.7.6. Communication of results 981 This subcomponent specifies how the results of the audit are 982 communicated to the stakeholders. 984 4.8. Legal Matters 986 This component covers legal matters. Sections 8.1 and 8.2 of the 987 framework discuss the business issues of fees to be charged for 988 various services and the financial responsibility of participants to 989 maintain resources for ongoing operations. The remaining sections 990 are generally concerned with legal topics. 992 With respect to many of the legal subcomponents within this 993 component, a DPS drafter may choose to include in the document terms 994 and conditions that apply directly to registrants or relying parties. 995 For instance, a Registry Manager may set forth limitations of 996 liability that apply to registrants and relying parties. The 997 inclusion of terms and conditions is likely to be appropriate only 998 where the DPS is itself a contract or part of a contract. 1000 In most cases, however, the DPS is not a contract or part of a 1001 contract; instead, it is laid out so that its terms and conditions 1002 are applied to the parties by separate documents, which may include 1003 associated agreements, such as registrar or registrant agreements. 1004 In that event, a drafter may write a Policy so as to require that 1005 certain legal terms and conditions appear (or not appear) in such 1006 associated agreements. 1008 4.8.1. Fees 1010 This subcomponent contains any applicable provisions regarding fees 1011 charged for DNSSEC or services related to DNSSEC. 1013 4.8.2. Financial responsibility 1015 This subcomponent contains requirements or disclosures relating to 1016 the resources available to the zone operator, and to remain solvent 1017 if they are liable to pay a judgment or settlement in connection with 1018 a claim arising out of such operations. 1020 4.8.3. Confidentiality of business information 1022 This subcomponent contains provisions relating to the treatment of 1023 confidential business information. Specifically, this subcomponent 1024 addresses: 1026 o The scope of what is considered confidential information; 1027 o The types of information that are considered to be outside the 1028 scope of confidential information; and 1029 o The responsibilities of participants that receive confidential 1030 information to secure it from compromise, and refrain from using 1031 it or disclosing it to third parties. 1033 4.8.4. Privacy of personal information 1035 This subcomponent relates to the protection that participants, 1036 particularly a Registry Operator, may be required to afford to 1037 personally identifiable private information of registrants and other 1038 participants. Specifically, this subcomponent addresses the 1039 following, to the extent pertinent under applicable law: 1041 o The designation and disclosure of the applicable privacy plan that 1042 applies to a participant's activities, if required by applicable 1043 law or policy; 1044 o Information that is or is not considered private; 1045 o Any responsibility of participants that receive private 1046 information to secure it, and refrain from using it and from 1047 disclosing it to third parties; 1048 o Any requirements as to notices to, or consent from individuals 1049 regarding use or disclosure of private information; and 1050 o Any circumstances under which a participant is entitled or 1051 required to disclose private information pursuant to judicial, 1052 administrative process in a private or governmental proceeding, or 1053 in any legal proceeding. 1055 4.8.5. Limitations of liability 1057 This subcomponent can include limitations of liability in a DPS or 1058 limitations that appear or must appear in an agreement associated 1059 with the DPS, such as a registrar or registrant agreement. 1061 4.8.6. Term and termination 1063 This subcomponent can include the time period in which a DPS remains 1064 in force and the circumstances under which the document, portions of 1065 the document, or its applicability to a particular participant can be 1066 terminated. In addition or alternatively, the DP may include 1067 requirements that certain term and termination clauses appear in 1068 agreements, such as registrar or registrant agreements. In 1069 particular, such terms can include: 1071 o The term of a document or agreement, that is, when the document 1072 becomes effective and when it expires if it is not terminated 1073 earlier. 1074 o Termination provisions stating circumstances under which the 1075 document, certain portions of it, or its application to a 1076 particular participant ceases to remain in effect. 1077 o Any consequences of termination of the document. For example, 1078 certain provisions of an agreement may survive its termination and 1079 remain in force. Examples include acknowledgements of 1080 intellectual property rights and confidentiality provisions. 1081 Also, termination may trigger a responsibility of parties to 1082 return confidential information to the party that disclosed it. 1084 5. Outline of a set of provisions 1086 1. INTRODUCTION 1087 1.1. Overview 1088 1.2. Document name and identification 1089 1.3. Community and Applicability 1090 1.3.1. Registry 1091 1.3.2. Registrar 1092 1.3.3. Registrant 1093 1.3.4. Relying Party 1094 1.3.5 Auditor 1095 1.3.4. Applicability 1096 1.4. Specification Administration 1097 1.4.1. Specification administration organization 1098 1.4.2. Contact Information 1099 1.4.3. Specification change procedures 1100 2. PUBLICATION AND REPOSITORIES 1101 2.1. Repositories 1102 2.2. Publication of key signing keys 1103 2.3. Access controls on repositories 1104 3. OPERATIONAL REQUIREMENTS 1105 3.1. Meaning of domain names 1106 3.2. Activation of DNSSEC for child zone 1107 3.3. Identification and authentication of child zone manager 1108 3.4. Registration of delegation signer (DS) resource records 1109 3.5. Method to prove possession of private key 1110 3.6. Removal of DS record 1111 3.6.1. Who can request removal 1112 3.6.2. Procedure for removal request 1113 3.6.3. Emergency removal request 1114 4. FACILITY, MANAGEMENT AND OPERATIONAL CONTROLS 1115 4.1. Physical Controls 1116 4.1.1. Site location and construction 1117 4.1.2. Physical access 1118 4.1.3. Power and air conditioning 1119 4.1.4. Water exposures 1120 4.1.5. Fire prevention and protection 1121 4.1.6. Media storage 1122 4.1.7. Waste disposal 1123 4.1.8. Off-site backup 1124 4.2. Procedural Controls 1125 4.2.1. Trusted roles 1126 4.2.2. Number of persons required per task 1127 4.2.3. Identification and authentication for each role 1128 4.2.4. Tasks requiring separation of duties 1129 4.3. Personnel Controls 1130 4.3.1. Qualifications, experience, and clearance 1131 requirements 1132 4.3.2. Background check procedures 1133 4.3.3. Training requirements 1134 4.3.4. Retraining frequency and requirements 1135 4.3.5. Job rotation frequency and sequence 1136 4.3.6. Sanctions for unauthorized actions 1137 4.3.7. Contracting personnel requirements 1138 4.3.8. Documentation supplied to personnel 1139 4.4. Audit Logging Procedures 1140 4.4.1. Types of events recorded 1141 4.4.2. Frequency of processing log 1142 4.4.3. Retention period for audit log information 1143 4.4.4. Protection of audit log 1144 4.4.5. Audit log backup procedures 1145 4.4.6. Audit collection system 1146 4.4.7. Notification to event-causing subject 1147 4.4.8. Vulnerability assessments 1148 4.5. Compromise and Disaster Recovery 1149 4.5.1. Incident and compromise handling procedures 1150 4.5.2. Corrupted computing resources, software, and/or 1151 data 1152 4.5.3. Entity private key compromise procedures 1153 4.5.4. Business Continuity and IT Disaster Recovery 1154 Capabilities 1155 4.6. Entity termination 1156 5. TECHNICAL SECURITY CONTROLS 1157 5.1. Key Pair Generation and Installation 1158 5.1.1. Key pair generation 1159 5.1.2. Public key delivery 1160 5.1.3. Public key parameters generation and quality 1161 checking 1162 5.1.4. Key usage purposes 1163 5.2. Private key protection and Cryptographic Module 1164 Engineering Controls 1165 5.2.1. Cryptographic module standards and controls 1166 5.2.2. Private key (m-of-n) multi-person control 1167 5.2.3. Private key escrow 1168 5.2.4. Private key backup 1169 5.2.5. Private key storage on cryptographic module 1170 5.2.6. Private key archival 1171 5.2.7. Private key transfer into or from a cryptographic 1172 module 1173 5.2.8. Method of activating private key 1174 5.2.9. Method of deactivating private key 1175 5.2.10. Method of destroying private key 1176 5.3. Other Aspects of Key Pair Management 1177 5.3.1. Public key archival 1178 5.3.2. Key usage periods 1179 5.4. Activation data 1180 5.4.1. Activation data generation and installation 1181 5.4.2. Activation data protection 1182 5.4.3. Other aspects of activation data 1183 5.5. Computer Security Controls 1184 5.6. Network Security Controls 1185 5.7. Timestamping 1186 5.8. Life Cycle Technical Controls 1187 5.8.1. System development controls 1188 5.8.2. Security management controls 1189 5.8.3. Life cycle security controls 1190 6. ZONE SIGNING 1191 6.1. Key lengths and algorithms 1192 6.2. Authenticated denial of existence 1193 6.3. Signature format 1194 6.4. Zone signing key roll-over 1195 6.5. Key signing key roll-over 1196 6.6. Signature life-time and re-signing frequency 1197 6.7. Verification of zone signing key set 1198 6.8. Verification of resource records 1199 6.9. Resource records time-to-live 1200 7. COMPLIANCE AUDIT 1201 7.1. Frequency of entity compliance audit 1202 7.2. Identity/qualifications of auditor 1203 7.3. Auditor's relationship to audited party 1204 7.4. Topics covered by audit 1205 7.5. Actions taken as a result of deficiency 1206 7.6. Communication of results 1207 8. LEGAL MATTERS 1208 8.1. Fees 1209 8.2. Financial responsibility 1210 8.3. Confidentiality of business information 1211 8.3.1. Scope of confidential information 1212 8.3.2. Information not within the scope of confidential 1213 information 1214 8.3.3. Responsibility to protect confidential information 1215 8.4. Privacy of personal information 1216 8.4.1. Information treated as private 1217 8.4.2. Information not deemed private 1218 8.4.3. Responsibility to protect private information 1219 8.4.4. Disclosure Pursuant to Judicial or Administrative 1220 Process 1221 8.5. Limitations of liability 1222 8.6. Term and termination 1223 8.6.1. Term 1224 8.6.2. Termination 1225 8.6.3. Dispute resolution provisions 1226 8.6.4. Governing law 1228 6. Security Considerations 1230 The sensitivity of the information protected by DNSSEC on all levels 1231 in the DNS tree will vary significantly. There are also not any 1232 restrictions of what kinds of information that can be protected using 1233 DNSSEC. Entities must evaluate their own environment and the chain 1234 of trust originating from their Trust Anchor, the associated threats 1235 and vulnerabilities, to determine the level of risk they are willing 1236 to accept. 1238 7. Acknowledgements 1240 The authors gratefully acknowledges, in no particular order, the 1241 contributions of the following persons: 1242 Richard Lamb 1243 Jakob Schlyter 1245 8. References 1247 8.1. Normative References 1249 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1250 Rose, "DNS Security Introduction and Requirements", 1251 RFC 4033, March 2005. 1253 8.2. Informative References 1255 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 1256 Wu, "Internet X.509 Public Key Infrastructure Certificate 1257 Policy and Certification Practices Framework", RFC 3647, 1258 November 2003. 1260 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1261 Rose, "Resource Records for the DNS Security Extensions", 1262 RFC 4034, March 2005. 1264 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1265 Security (DNSSEC) Hashed Authenticated Denial of 1266 Existence", RFC 5155, March 2008. 1268 Authors' Addresses 1270 Fredrik Ljunggren 1271 Kirei AB 1272 P.O. Box 53204 1273 Goteborg SE-400 16 1274 Sweden 1276 Email: fredrik@kirei.se 1278 Anne-Marie Eklund-Lowinder 1279 .SE (The Internet Infrastructure Foundation) 1280 P.O. Box 7399 1281 Stockholm SE-103 91 1282 Sweden 1284 Email: amel@iis.se 1286 Tomofumi Okubo 1287 Internet Corporation For Assigned Names and Numbers 1288 4676 Admiralty Way, Suite 330 1289 Marina del Ray, CA 90292 1290 USA 1292 Email: tomofumi.okubo@icann.org