idnits 2.17.1 draft-ietf-dnsop-dnssec-dps-framework-03.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 (November 9, 2010) is 4916 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: May 13, 2011 .SE 6 T. Okubo 7 ICANN 8 November 9, 2010 10 DNSSEC Policy & Practice Statement Framework 11 draft-ietf-dnsop-dnssec-dps-framework-03 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 May 13, 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. DP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.2. DPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . 21 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 . . . . . . . 22 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 . . . . . . . 23 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], 145 [RFC4034], [RFC4035]) is a set of IETF specifications which addresses 146 these vulnerabilities by adding data origin authentication, data 147 integrity verification and authenticated denial of existence 148 capabilities to the Domain Name System, using public key 149 cryptography. In short, DNSSEC provides a way for software to 150 validate that Domain Name System (DNS) data has not been modified 151 during transit. 153 To provide means for the relying parties to evaluate the strength and 154 security of the DNSSEC chain of trust, an entity operating a DNSSEC 155 enabled zone may choose to publish a DNSSEC Practice Statement (DPS), 156 comprising statements of critical security controls and procedures 157 relevant for scrutinizing the trustworthiness of the system. The DPS 158 may also identify one or more DNSSEC Policies which are supported, 159 explaining how it meets the requirements of each Policy. 161 Even though this document is heavily inspired by the Internet X.509 162 Public Key Infrastructure Certificate Policy and Certification 163 Practices Framework [RFC3647], and large parts drawn from that 164 document, the properties and structure of the DNSSEC PKI is 165 fundamentally different from the X.509 PKI. 167 In the DNSSEC PKI there is no central control of assurance or trust 168 levels. Each zone manager may select their own way of managing keys 169 and operations, and there is no necessity to perform any coordination 170 of security practices between different zones in the DNS. The degree 171 to which a relying party can trust the binding embodied in the DNSSEC 172 chain of trust is dependent on the weakest link of that chain. This 173 implies that the security of zones is generally more critical higher 174 up in the DNS hierarchy. 176 Another significant difference is that the DPS is focused only on 177 stating the security posture of a zone, and not the entire domain 178 name system. Moreover, the DNS is of a almost ubiquitous nature and 179 completely open. There exists no agreements with the relying (third) 180 parties, which is all entities relying on signed responses from the 181 DNS. 183 1.2. Purpose 185 The purpose of this document is twofold. Firstly, the document aims 186 to explain the concept of a DNSSEC Policy (DP) and a DNSSEC Practice 187 Statement (DPS), and describe the relationship between a DP and a 188 DPS. Second, this document aims to present a framework to encourage 189 and assist writers of Policies and Practice Statements in creating 190 heterogenous and comparable documents. In particular, the framework 191 identifies the elements that should be considered in formulating a 192 DP/DPS. It does not, however, define a particular Policy or Practice 193 Statement, not does it seek to provide legal advice or 194 recommendations as to the contents. 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 Audit logs - Control evidence information generated by DNS and 220 DNSSEC-related systems, the surrounding facility or other manually 221 processed, non-electronic documentation to prove the integrity of 222 processes. Audit logs will be examined by the internal and/or 223 external auditors. 225 Activation data - Data values, other than keys, that are required to 226 operate the cryptographic modules which are usually used to protect 227 the keys from unauthorized use. 229 Chain of Trust - A hierarchical structure of trust consisting of DNS 230 keys, signatures, and delegation signer records that, when validated 231 in a series, can provide proof of authenticity of the last element in 232 the chain using the first element in the chain. Usually, the first 233 element is a trust anchor. 235 Compromise (Key Compromise) - Key Compromise is a situation where the 236 private component of the Key Signing Key or Zone Signing Key is lost, 237 stolen, exposed, modified or used in an unauthorized manner. More 238 strictly, even a suspicion that one of these has occurred will be 239 enough to be considered as key compromise. 241 DNS - The Domain Name System (DNS) is a hierarchical global naming 242 catalog for computers, services, or any resource connected to the 243 Internet. It associates various information with domain names 244 assigned to each of the participants. 246 DNS Zone - A portion of the global Domain Name System (DNS) namespace 247 for which administrative responsibility has been delegated. 249 DNSSEC Policy - A DNSSEC Policy sets forth the requirements and 250 standards to be implemented for a DNSSEC signed zone. A Practice 251 Statement may support a Policy by explaining how it meets the 252 requirements of the Policy. 254 DNSSEC Practice Statement - A DNSSEC Practices Statement is a 255 practices disclosure document which may be a supplemental document to 256 the DNSSEC Policy (if such exists) and states how the management of a 257 given zone implements procedures and controls at a high level. 259 Key Roll Over - A operational process of DNSSEC to change either the 260 Key Signing Key or the Zone Signing Key. 262 Policy Management Authority - A group formed by stake-holders from 263 each group within the organization operating DNSSEC, responsible for 264 managing the DP/DPS. 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 Relying Party - An entity that rely on the signed response from the 271 DNS. 273 Repository - A location on the Internet to store DP, DPS, Trust 274 Anchors and other related information that should be kept public. 276 Security Posture - A Security Posture is a barometer that indicates 277 how secure the entity is and how secure the entity should be which is 278 a result of an adequate threat modelling, vulnerability assessment 279 and risk assessment. 281 Separation of Duties - A security concept that limits the influence 282 of a single person by segregating the roles and responsibilities. 284 Trust Anchor - Public portion of the Key Signing Key which is the 285 authoritative entity used to cryptographically validate the chain of 286 trust to the signed resource record. 288 3. Concepts 290 This section describes the concept of a DNSSEC Policy and of a DNSSEC 291 Practices Statement. Other related concepts are described as well. 293 3.1. DP 295 The DP sets forth requirements that are appropriate for a determined 296 level of assurance. For example, a DP may encompass all topics of 297 this framework, each with a certain set of security requirements and 298 possibly grouped them into categories, such as medium impact and high 299 impact. The progression from medium to high levels would correspond 300 to increasing security requirements and corresponding increasing 301 levels of assurance. 303 A DPS may identify a supported DP, which may subsequently be used by 304 a relying party to evaluate the trustworthiness of any digital 305 signatures verified using the public key of that entity. 307 DPs also constitute a basis for an audit, accreditation, or another 308 assessment of an entity. Each entity can be assessed against one or 309 more DPs that it is recognized as implementing. 311 3.2. DPS 313 Most DNSSEC participants may not have the need to create a thorough 314 and detailed statement of practices. For example, the registrant may 315 itself be the sole relying party of its own zone and would already be 316 aware of the nature and trustworthiness of its services. In other 317 cases, a zone manager may provide registration services providing 318 only a very low level of assurances where the domain names being 319 secured may pose only marginal risks if compromised. Publishing a 320 DPS is most relevant for entities operating a zone which contains a 321 significant number of delegations to other entities. 323 A DPS should contain information which is relevant to the 324 stakeholders of the relevant zone(s). Since these generally include 325 the Internet community, it should not contain such information which 326 could be considered to be sensitive details of an entity's 327 operations. 329 3.3. Relationship between DNSSEC Policy and Practice Statement 331 A DNSSEC Policy and a DNSSEC Practice Statement address the same set 332 of topics that are of interest to the stakeholders in terms of the 333 degree to which a DNSSEC digital signature may be trusted. Their 334 primary difference is in the focus of their provisions. A Policy 335 sets forth the requirements and standards to be implemented for a 336 DNSSEC signed zone. In other words, the purpose of the Policy is to 337 establish what entities must do. A Practice Statement, by contrast, 338 states how a zone operator (and possibly other participants in the 339 management of a given zone) implements procedures and controls to 340 meet the requirements stated in the Policy. To summarise, the 341 purpose of the Practice Statement is to disclose how the participants 342 perform their functions and implement controls. 344 An additional difference between a Policy and a Practice Statement 345 relates the scope of coverage of the two kinds of documents. Since a 346 Policy is a statement of requirements, it is best used for 347 communicating minimum operating guidelines that must be met by 348 complying parties, but may as such also be used to facilitate 349 interoperation of a level of trust between zones. Thus, a Policy may 350 apply to multiple organizations or multiple zones. By contrast, a 351 Practice Statement would usually apply only to a single zone operator 352 or a single organization. 354 For example, a TLD Manager or regulatory authority may define 355 requirements in a Policy for operations of one or more zones. The 356 Policy will be a broad statement of the general requirements for 357 managing the zone. A zone operator may be required to write its own 358 Practice Statement to support the Policy by explaining how it meets 359 the requirements of the Policy. Or, a zone operator which is also 360 the manager of that zone and not governed by any external Policy may 361 still choose to disclose operational practices by publishing a DPS, 362 for the purpose of providing transparency and gain community trust in 363 the operations. 365 A Policy and a Practice Statement also differ in the level of detail 366 of the provisions in each. Although the level of detail may vary, a 367 Practice Statement will generally be more detailed than a Policy. A 368 Practice Statement provides a detailed description of procedures and 369 controls in place to meet the Policy requirements, while a Policy is 370 more general. 372 The main differences between a Policy and Practice Statement can 373 therefore be summarized as follows: 375 (a) Operation of a DNS zone with DNSSEC may be governed by a Policy, 376 to establish requirements that state what the entity operating 377 that zone must do. An entity can use a Practice Statement to 378 disclose how it meets the requirements of a Policy or how it has 379 implemented critical processes and controls. 380 (b) A Policy may facilitate interoperation of level of trust through 381 several parts or levels in the DNS hierarchy. By contrast, a 382 Practice Statement is a statement of a single zone operator or 383 organization. 384 (c) A Practice Statement is generally more detailed than a Policy 385 and specifies how the zone operator or organization implements 386 critical processes and controls, and how the entity meets any 387 requirements specified in the one or more Policies under which 388 it operates DNSSEC. 390 3.4. Set of Provisions 392 A set of provisions is a collection of Policy requirements or 393 Practice statements, which may employ the approach described in this 394 framework by covering the topics appearing in Section 5 below. They 395 are also described in detail in Section 4 below. 397 A Policy can be expressed as a single set of provisions. 399 A Practice Statement can also be expressed as a single set of 400 provisions with each component addressing the requirements of one or 401 more Policies. Alternatively, it could be a set of provisions that 402 do not reference any particular policy but instead describe a set of 403 self-imposed provisions to the relying parties. For example, a 404 Practice Statement could be expressed as a combination of the 405 following: 407 (a) a list of Policies supported by the DPS; 408 (b) for each Policy in (a), a set of provisions that contains 409 statements responding to that Policy by filling in details not 410 stipulated in that policy or expressly left to the discretion of 411 the implementor; such statements serve to show how this 412 particular Practice Statement implements the requirements of the 413 particular Policy; or 414 (c) a set of provisions that contains statements regarding the 415 practices of the DNSSEC operations, regardless of any Policy. 417 The statements provided in (b) may augment or refine the stipulations 418 of an applicable Policy, but generally must not conflict with any of 419 the stipulations of such Policy. In certain cases, however, a Policy 420 Authority may permit exceptions because certain compensating controls 421 of the entity are disclosed in its Practices Statement, that allow 422 the entity to provide assurances that are equivalent to the 423 assurances provided by entities that are in full compliance with the 424 Policy. 426 This framework outlines the contents of a set of provisions, in terms 427 of eight primary components, as follows: 429 1. Introduction 430 2. Publication and Repositories 431 3. Operational Requirements 432 4. Facility, Management, and Operational Controls 433 5. Technical Security Controls 434 6. Zone Signing 435 7. Compliance Audit 436 8. Legal Matters 438 This framework can be used by Policy Authorities to write DNSSEC 439 Policies and zone operators to write a DNSSEC Practice Statements. 440 Having a set of documents with the same structure facilitates 441 comparisons and mappings between them with the corresponding 442 documents of other zones. 444 4. Contents of a set of provisions 446 This section describes the contents of a set of provisions. Refer to 447 Section 5 for the complete outline. 449 Drafters of DPSs in conformance with this framework are permitted to 450 add additional levels of subcomponents below the subcomponents 451 described here for the purpose of meeting the needs of the drafter's 452 particular requirements. Drafters may also leave any components 453 without stipulation if so requires, but all components listed in 454 Section 5 should exist. 456 4.1. Introduction 458 This component identifies and introduces the set of provisions, and 459 indicates the types of entities and applications for which the 460 document (either the Policy or the Practice Statement) is targeted. 462 4.1.1. Overview 464 This subcomponent provides a general introduction to the document 465 being written. It can also be used to provide a description of 466 entities to which the Policy or Practice Statement applies. 468 4.1.2. Document Name and Identification 470 This subcomponent provides any applicable names or other identifiers 471 of the document. 473 4.1.3. Community and Applicability 475 This subcomponent addresses the stakeholders in DNSSEC along with the 476 expected roles and responsibilities. These include (but are not 477 limited to) an entity signing the zone, an entity that relies on the 478 signed zone, other entities that have operational dependency on the 479 signed zone and an entity that entrusted the zone signing. 481 4.1.4. Specification Administration 483 This subcomponent includes the name and contact details of the 484 organization that is responsible for managing the DP/DPS. 486 Moreover, if a formal or informal Policy Authority is responsible for 487 determining whether a DPS being suitable for the Policy this 488 subcomponent may include the name and contact information of the 489 entity in charge of making such a determination. Finally, in this 490 case, this subcomponent also includes the procedures by which this 491 determination is made. 493 4.2. Publication and Repositories 495 This component contains any applicable provisions regarding: 497 o The location and method to access the repository; 498 o An identification of the entity or entities that operate 499 repositories within the community, such as a zone operator or a 500 TLD Manager; 501 o The responsibility of an entity to publish information regarding 502 its practices, public keys, and the current status of such keys, 503 which may include the responsibilities of making the DPS publicly 504 available using various mechanisms and of identifying components 505 and subcomponents. It should also include an indication of the 506 elements of the documents that are not made publicly available 507 owing to their sensitive nature, e.g. security controls, clearance 508 procedures, or business information; 509 o When information must be published and the frequency of 510 publication; and 511 o Access control on published information objects. 513 4.3. Operational Requirements 515 This component describes the operational requirements when operating 516 a DNSSEC signed zone. 518 4.3.1. Meaning of domain names 520 This section describes the overall policy of child zone naming, if 521 any. 523 4.3.2. Activation of DNSSEC for child zone 525 This section describes the process of establishing the chain-of-trust 526 to the child zone by incorporating DS record(s) into the zone. 528 4.3.3. Identification and authentication of child zone manager 530 This section describes how the child zone manager has initially been 531 identified, and how any subsequent change request is authenticated as 532 originating from the manager or its authorized representative. 534 4.3.4. Registration of delegation signer (DS) resource records 536 This section describes how the delegation signer resource records are 537 incorporated into the parent zone. 539 4.3.5. Method to prove possession of private key 541 This section describes how, if, or under which circumstances the 542 child zone manager is required to provide proof of the possession of 543 the private component of any current or subsequent child zone Key 544 Signing Key that corresponds to a DS record they whish to incorporate 545 into the parent zone. 547 4.3.6. Removal of DS resource records 549 This section will explain how, when and under which circumstances the 550 DS records may be removed from the zone. 552 4.4. Facility, Management and Operational Controls 554 This component describes non-technical security controls (i.e., 555 physical, procedural, and personnel controls) in use by the entity to 556 securely perform the DNSSEC related functions such as physical 557 access, key management, disaster recovery, auditing and archiving. 559 These non-technical security controls are critical for trusting the 560 signatures since lack of security may compromise DNSSEC operations 561 resulting for example, in the creation of signatures with erroneous 562 information or compromising the Key Signing Key and/or Zone Signing 563 Key. 565 Within each subcomponent, separate consideration will, in general, 566 need to be given to each entity type. 568 4.4.1. Physical Controls 570 In this subcomponent, the physical controls on the facility housing 571 the entity systems are described. Topics addressed may include: 573 o Site location and construction, such as the construction 574 requirements for high-security areas and the use of locked rooms, 575 cages, safes, and cabinets; 576 o Physical access, i.e., mechanisms to control access from one area 577 of the facility to another or access into high-security zones, 578 such as locating DNSSEC operations in a secure computer room 579 monitored by guards, cameras or security alarms and requiring 580 movement from zone to zone to be accomplished using tokens and/or 581 PINs; 582 o Power and air conditioning; 583 o Water exposures; 584 o Fire prevention and protection; 585 o Media storage, for example, requiring the storage of backup media 586 in a separate location that is physically secure and protected 587 from fire, smoke, particle and water damage; 588 o Waste disposal; and 589 o Off-site backup. 591 4.4.2. Procedural Controls 593 In this subcomponent, requirements for recognizing trusted roles are 594 described, together with the responsibilities for each role. 595 Examples of trusted roles include system administrators, security 596 officers, and system auditors. 598 For each task identified, the number of individuals required to 599 perform the task (n of m rule, if applicable) should be stated for 600 each role. Identification and authentication requirements for each 601 role may also be defined. 603 This component also includes the separation of duties in terms of the 604 roles that cannot be performed by the same individuals. 606 4.4.3. Personnel Controls 608 This subcomponent addresses the following: 610 o Qualifications, experience, and clearances that personnel must 611 have as a condition of filling trusted roles or other important 612 roles. Examples include credentials, job experiences, and 613 official government clearances that candidates for these positions 614 must have before being hired; 615 o Background checks and clearance procedures that are required in 616 connection with the hiring of personnel filling trusted roles or 617 perhaps other important roles; such roles may require a check of 618 their criminal records, financial records, references, and 619 additional clearances that a participant undertakes after a 620 decision has been made to hire a particular person; 621 o Training requirements and training procedures for each role 622 following the hiring of personnel; 623 o Any retraining period and retraining procedures for each role 624 after completion of initial training; 625 o Frequency and sequence for job rotation among various roles; 626 o Sanctions against personnel for unauthorized actions, unauthorized 627 use of authority, and unauthorized use of the entity systems; 628 o Controls on personnel that are independent contractors rather than 629 employees of the entity; examples include: 631 * Bonding requirements on contract personnel; 632 * Contractual requirements including indemnification for damages 633 due to the actions of the contractor personnel; 634 * Auditing and monitoring of contractor personnel; and 635 * Other controls on contracting personnel. 637 o Documentation to be supplied to personnel during initial training, 638 retraining, or otherwise. 640 4.4.4. Audit Logging Procedures 642 This subcomponent is used to describe event logging and audit 643 systems, implemented for the purpose of maintaining an audit trail 644 and provide evidence of processes' integrity. Elements include the 645 following: 647 o Types of events recorded, such as attempts to access the system, 648 and requests made to the system; 649 o Frequency with which audit logs are processed or archived, for 650 example, weekly, following an alarm or anomalous event, or when 651 ever the audit log is n% full; 653 o Period for which audit logs are kept; 654 o Protection of audit logs: 656 * Who can view audit logs, for example only the audit 657 administrator; 658 * Protection against modification of audit logs, for instance a 659 requirement that no one may modify or delete the audit records 660 or that only an audit administrator may delete an audit file as 661 part of rotating the audit file; and 662 * Protection against deletion of audit logs. 664 o Audit log back up procedures; 665 o Whether the audit log collection function is internal or external 666 to the system; 667 o Whether the subject who caused an audit event to occur is notified 668 of the audit action; and 669 o Vulnerability assessments, for example, where audit data is run 670 through a tool that identifies potential attempts to breach the 671 security of the system. 673 4.4.5. Compromise and Disaster Recovery 675 This subcomponent describes requirements relating to notification and 676 recovery procedures in the event of compromise or disaster. Each of 677 the following may need to be addressed separately: 679 o Identification or listing of the applicable incident and 680 compromise reporting and handling procedures. 681 o The recovery procedures used if computing resources, software, 682 and/or data are corrupted or suspected to be corrupted. These 683 procedures describe how a secure environment is re-established, 684 whether the Key Signing Key or Zone Signing key requires a roll 685 over, how to assess the damage and carry out the root cause 686 analysis. 687 o The recovery procedures used if the Key Signing Key or Zone 688 Signing Key is compromised. These procedures describe how a 689 secure environment is re-established, how the keys are rolled 690 over, how a new Trust Anchor is provided to the users (if 691 applicable) and how new zone is published. 692 o The entity's capabilities to ensure business continuity following 693 a natural or other disaster. Such capabilities may include the 694 availability of a disaster recovery site at which operations may 695 be recovered. They may also include procedures for securing its 696 facility during the period of time following a natural or other 697 disaster and before a secure environment is re-established, either 698 at the original site or at a disaster recovery site. For example, 699 procedures to protect against theft of sensitive materials from an 700 earthquake-damaged site. 702 4.4.6. Entity termination 704 This subcomponent describes requirements relating to procedures for 705 entity termination, termination notification and transition of 706 responsibilities of a zone operator or other entity, where the 707 purpose may be to ensure that the transition process will be 708 transparent to the relying parties and will not affect the services. 710 4.5. Technical Security Controls 712 This component is used to define the security measures taken to 713 protect the cryptographic keys and activation data (e.g., PINs, 714 passwords, or manually-held key shares) relevant to the DNSSEC 715 operations. Secure key management is critical to ensure that all 716 secret and private keys and activation data are protected and used 717 only by authorized personnel. 719 Also describes here are other technical security controls used to 720 perform the functions of key generation, authentication, 721 registration, auditing, and archiving. Technical controls include 722 life-cycle security controls (including software development 723 environment security) and operational security controls. 725 If applicable, other technical security controls on repositories, 726 authoritative name servers or other participants may also be 727 documented here. 729 4.5.1. Key Pair Generation and Installation 731 Key pair generation and installation need to be considered, whereas 732 the following questions potentially need to be answered: 734 1. Who generates the zone's public, private key pairs? Furthermore, 735 how is the key generation performed? Is the key generation 736 performed by hardware or software? 737 2. How is the private key installed in all parts of the key 738 management system? 739 3. How are the zones's public keys provided securely to the parent 740 zone and potential relying parties? 741 4. Who generates the public key parameters, and is the quality of 742 the parameters checked during key generation? 744 5. For what purposes may the keys be used, and/or for what purposes 745 should usage of the key be restricted? 747 4.5.2. Private Key Protection and Cryptographic Module Engineering 748 Controls 750 Requirements for private key protection and cryptographic modules 751 need to be considered for key generation and creation of signatures. 752 The following questions potentially need to be answered: 754 1. What standards, if any, are required for the cryptographic 755 module used to generate the keys? A cryptographic module can be 756 composed of hardware, software, firmware, or any combination of 757 them. For example, are the zones signatures required to be 758 generated using modules compliant with the US FIPS 140-2 759 standard? If so, what is the required FIPS 140-2 level of the 760 module? Are there any other engineering or other controls 761 relating to a cryptographic module, such as the identification 762 of the cryptographic module boundary, input/output, roles and 763 services, finite state machine, physical security, software 764 security, operating system security, algorithm compliance, 765 electromagnetic compatibility, and self tests. 766 2. Is the private key under n out of m multi-person control? If 767 yes, provide n and m (two person control is a special case of n 768 out of m, where n = m = 2)? 769 3. Is the private key escrowed? If so, who is the escrow agent, 770 what form is the key escrowed in (examples include plaintext, 771 encrypted, split key), and what are the security controls on the 772 escrow system? 773 4. Is the private key backed up? If so, who is the backup agent, 774 what form is the key backed up in (examples include plaintext, 775 encrypted, split key), and what are the security controls on the 776 backup system? 777 5. Is the private key archived? If so, who is the archival agent, 778 what form is the key archived in (examples include plaintext, 779 encrypted, split key), and what are the security controls on the 780 archival system? 781 6. Under what circumstances, if any, can a private key be 782 transferred into or from a cryptographic module? Who is 783 permitted to perform such a transfer operation? In what form is 784 the private key during the transfer (i.e., plaintext, encrypted, 785 or split key)? 786 7. How is the private key stored in the module (i.e., plaintext, 787 encrypted, or split key)? 789 8. Who can activate (use) the private key? What actions must be 790 performed to activate the private key (e.g., login, power on, 791 supply PIN, insert token/key, automatic, etc.)? Once the key is 792 activated, is the key active for an indefinite period, active 793 for one time, or active for a defined time period? 794 9. Who can deactivate the private key and how? Examples of methods 795 of deactivating private keys include logging out, turning the 796 power off, removing the token/key, automatic deactivation, and 797 time expiration. 798 10. Who can destroy the private key and how? Examples of methods of 799 destroying private keys include token surrender, token 800 destruction, and zeroizing the key. 802 4.5.3. Other Aspects of Key Pair Management 804 Other aspects of key management need to be considered for the zone 805 operator and other participants. For each of these types of 806 entities, the following questions may need to be answered: 808 1. Is the public key archived? If so, who is the archival agent and 809 what are the security controls on the archival system? 810 2. What is the operational period of the keys. What are the usage 811 periods, or active lifetimes for the pairs? 813 4.5.4. Activation data 815 Activation data refers to data values other than whole private keys 816 that are required to operate private keys or cryptographic modules 817 containing private keys, such as a PIN, passphrase, or portions of a 818 private key used in a key-splitting scheme. Protection of activation 819 data prevents unauthorized use of the private key, and potentially 820 needs to be considered for the zone operator and other participants. 821 Such consideration potentially needs to address the entire life-cycle 822 of the activation data from generation through archival and 823 destruction. For each of the entity types, all of the questions 824 listed in 4.5.1 through 4.5.3 potentially need to be answered with 825 respect to activation data rather than with respect to keys. 827 4.5.5. Computer Security Controls 829 This subcomponent is used to describe computer security controls such 830 as: 832 1. use of the trusted computing base concept or equivalent; 833 2. discretionary access control, labels, mandatory access controls; 834 3. object re-use; 835 4. auditing; 836 5. identification and authentication; 837 6. trusted path; and 838 7. security testing. 840 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 889 signing, if any. 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 describes 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 are any requirements or guidelines for the selection of the 961 auditor. 963 4.7.4. Topics covered by audit 965 Topics covered by audit refers to the scope of the audit. Since the 966 DNSSEC Policy and Practices Statement is the document to be audited 967 against, it is ideal to set the scope to the scope of the DP/DPS. 968 However, the scope may be narrowed down or expanded as needed for 969 example in case there are not enough resources to conduct a full 970 audit, or some portion is under development and not ready for the 971 audit. 973 4.7.5. Actions taken as a result of deficiency 975 This subcomponent specifies the action taken in order to correct any 976 discrepancy. This could be the remediation process for the audit 977 findings or any other action to correct any discrepancy with the 978 DNSSEC Policy or Practices Statement. 980 4.7.6. Communication of results 982 This subcomponent specifies how the results of the audit are 983 communicated to the stakeholders. 985 4.8. Legal Matters 987 This component covers legal matters. Sections 8.1 and 8.2 of the 988 framework discuss the business issues of fees to be charged for 989 various services and the financial responsibility of participants to 990 maintain resources for ongoing operations. The remaining sections 991 are generally concerned with legal topics. 993 With respect to many of the legal subcomponents within this 994 component, a DPS drafter may choose to include in the document terms 995 and conditions that apply directly to registrants or relying parties. 996 For instance, a Registry Manager may set forth limitations of 997 liability that apply to registrants and relying parties. The 998 inclusion of terms and conditions is likely to be appropriate only 999 where the DPS is itself a contract or part of a contract. 1001 In most cases, however, the DPS is not a contract or part of a 1002 contract; instead, it is laid out so that its terms and conditions 1003 are applied to the parties by separate documents, which may include 1004 associated agreements, such as registrar or registrant agreements. 1005 In that event, a drafter may write a Policy so as to require that 1006 certain legal terms and conditions appear (or not appear) in such 1007 associated agreements. 1009 4.8.1. Fees 1011 This subcomponent contains any applicable provisions regarding fees 1012 charged for DNSSEC or services related to DNSSEC. 1014 4.8.2. Financial responsibility 1016 This subcomponent contains requirements or disclosures relating to 1017 the resources available to the zone operator, and to remain solvent 1018 if they are liable to pay a judgment or settlement in connection with 1019 a claim arising out of such operations. 1021 4.8.3. Confidentiality of business information 1023 This subcomponent contains provisions relating to the treatment of 1024 confidential business information. Specifically, this subcomponent 1025 addresses: 1027 o The scope of what is considered confidential information; 1028 o The types of information that are considered to be outside the 1029 scope of confidential information; and 1030 o The responsibilities of participants that receive confidential 1031 information to secure it from compromise, and refrain from using 1032 it or disclosing it to third parties. 1034 4.8.4. Privacy of personal information 1036 This subcomponent relates to the protection that participants, 1037 particularly a Registry Operator, may be required to afford to 1038 personally identifiable private information of registrants and other 1039 participants. Specifically, this subcomponent addresses the 1040 following, to the extent pertinent under applicable law: 1042 o The designation and disclosure of the applicable privacy plan that 1043 applies to a participant's activities, if required by applicable 1044 law or policy; 1045 o Information that is or is not considered private; 1046 o Any responsibility of participants that receive private 1047 information to secure it, and refrain from using it and from 1048 disclosing it to third parties; 1049 o Any requirements as to notices to, or consent from individuals 1050 regarding use or disclosure of private information; and 1051 o Any circumstances under which a participant is entitled or 1052 required to disclose private information pursuant to judicial, 1053 administrative process in a private or governmental proceeding, or 1054 in any legal proceeding. 1056 4.8.5. Limitations of liability 1058 This subcomponent can include limitations of liability in a DPS or 1059 limitations that appear or must appear in an agreement associated 1060 with the DPS, such as a registrar or registrant agreement. 1062 4.8.6. Term and termination 1064 This subcomponent can include the time period in which a DPS remains 1065 in force and the circumstances under which the document, portions of 1066 the document, or its applicability to a particular participant can be 1067 terminated. In addition or alternatively, the DP may include 1068 requirements that certain term and termination clauses appear in 1069 agreements, such as registrar or registrant agreements. In 1070 particular, such terms can include: 1072 o The term of a document or agreement, that is, when the document 1073 becomes effective and when it expires if it is not terminated 1074 earlier. 1075 o Termination provisions stating circumstances under which the 1076 document, certain portions of it, or its application to a 1077 particular participant ceases to remain in effect. 1078 o Any consequences of termination of the document. For example, 1079 certain provisions of an agreement may survive its termination and 1080 remain in force. Examples include acknowledgements of 1081 intellectual property rights and confidentiality provisions. 1082 Also, termination may trigger a responsibility of parties to 1083 return confidential information to the party that disclosed it. 1085 5. Outline of a set of provisions 1087 1. INTRODUCTION 1088 1.1. Overview 1089 1.2. Document name and identification 1090 1.3. Community and Applicability 1091 1.4. Specification Administration 1092 1.4.1. Specification administration organization 1093 1.4.2. Contact Information 1094 1.4.3. Specification change procedures 1095 2. PUBLICATION AND REPOSITORIES 1096 2.1. Repositories 1097 2.2. Publication of key signing keys 1098 2.3. Access controls on repositories 1099 3. OPERATIONAL REQUIREMENTS 1100 3.1. Meaning of domain names 1101 3.2. Activation of DNSSEC for child zone 1102 3.3. Identification and authentication of child zone manager 1103 3.4. Registration of delegation signer (DS) resource records 1104 3.5. Method to prove possession of private key 1105 3.6. Removal of DS record 1106 3.6.1. Who can request removal 1107 3.6.2. Procedure for removal request 1108 3.6.3. Emergency removal request 1109 4. FACILITY, MANAGEMENT AND OPERATIONAL CONTROLS 1110 4.1. Physical Controls 1111 4.1.1. Site location and construction 1112 4.1.2. Physical access 1113 4.1.3. Power and air conditioning 1114 4.1.4. Water exposures 1115 4.1.5. Fire prevention and protection 1116 4.1.6. Media storage 1117 4.1.7. Waste disposal 1118 4.1.8. Off-site backup 1119 4.2. Procedural Controls 1120 4.2.1. Trusted roles 1121 4.2.2. Number of persons required per task 1122 4.2.3. Identification and authentication for each role 1123 4.2.4. Tasks requiring separation of duties 1124 4.3. Personnel Controls 1125 4.3.1. Qualifications, experience, and clearance 1126 requirements 1127 4.3.2. Background check procedures 1128 4.3.3. Training requirements 1129 4.3.4. Retraining frequency and requirements 1130 4.3.5. Job rotation frequency and sequence 1131 4.3.6. Sanctions for unauthorized actions 1132 4.3.7. Contracting personnel requirements 1133 4.3.8. Documentation supplied to personnel 1134 4.4. Audit Logging Procedures 1135 4.4.1. Types of events recorded 1136 4.4.2. Frequency of processing log 1137 4.4.3. Retention period for audit log information 1138 4.4.4. Protection of audit log 1139 4.4.5. Audit log backup procedures 1140 4.4.6. Audit collection system 1141 4.4.7. Notification to event-causing subject 1142 4.4.8. Vulnerability assessments 1143 4.5. Compromise and Disaster Recovery 1144 4.5.1. Incident and compromise handling procedures 1145 4.5.2. Corrupted computing resources, software, and/or 1146 data 1147 4.5.3. Entity private key compromise procedures 1148 4.5.4. Business Continuity and IT Disaster Recovery 1149 Capabilities 1150 4.6. Entity termination 1151 5. TECHNICAL SECURITY CONTROLS 1152 5.1. Key Pair Generation and Installation 1153 5.1.1. Key pair generation 1154 5.1.2. Public key delivery 1155 5.1.3. Public key parameters generation and quality 1156 checking 1157 5.1.4. Key usage purposes 1158 5.2. Private key protection and Cryptographic Module 1159 Engineering Controls 1161 5.2.1. Cryptographic module standards and controls 1162 5.2.2. Private key (m-of-n) multi-person control 1163 5.2.3. Private key escrow 1164 5.2.4. Private key backup 1165 5.2.5. Private key storage on cryptographic module 1166 5.2.6. Private key archival 1167 5.2.7. Private key transfer into or from a cryptographic 1168 module 1169 5.2.8. Method of activating private key 1170 5.2.9. Method of deactivating private key 1171 5.2.10. Method of destroying private key 1172 5.3. Other Aspects of Key Pair Management 1173 5.3.1. Public key archival 1174 5.3.2. Key usage periods 1175 5.4. Activation data 1176 5.4.1. Activation data generation and installation 1177 5.4.2. Activation data protection 1178 5.4.3. Other aspects of activation data 1179 5.5. Computer Security Controls 1180 5.6. Network Security Controls 1181 5.7. Timestamping 1182 5.8. Life Cycle Technical Controls 1183 5.8.1. System development controls 1184 5.8.2. Security management controls 1185 5.8.3. Life cycle security controls 1186 6. ZONE SIGNING 1187 6.1. Key lengths and algorithms 1188 6.2. Authenticated denial of existence 1189 6.3. Signature format 1190 6.4. Zone signing key roll-over 1191 6.5. Key signing key roll-over 1192 6.6. Signature life-time and re-signing frequency 1193 6.7. Verification of zone signing key set 1194 6.8. Verification of resource records 1195 6.9. Resource records time-to-live 1196 7. COMPLIANCE AUDIT 1197 7.1. Frequency of entity compliance audit 1198 7.2. Identity/qualifications of auditor 1199 7.3. Auditor's relationship to audited party 1200 7.4. Topics covered by audit 1201 7.5. Actions taken as a result of deficiency 1202 7.6. Communication of results 1203 8. LEGAL MATTERS 1204 8.1. Fees 1205 8.2. Financial responsibility 1206 8.3. Confidentiality of business information 1207 8.3.1. Scope of confidential information 1208 8.3.2. Information not within the scope of confidential 1209 information 1210 8.3.3. Responsibility to protect confidential information 1211 8.4. Privacy of personal information 1212 8.4.1. Information treated as private 1213 8.4.2. Information not deemed private 1214 8.4.3. Responsibility to protect private information 1215 8.4.4. Disclosure Pursuant to Judicial or Administrative 1216 Process 1217 8.5. Limitations of liability 1218 8.6. Term and termination 1219 8.6.1. Term 1220 8.6.2. Termination 1221 8.6.3. Dispute resolution provisions 1222 8.6.4. Governing law 1224 6. Security Considerations 1226 The sensitivity of the information protected by DNSSEC on all levels 1227 in the DNS tree will vary significantly. In addition, there are no 1228 restrictions as to what types of information that can be protected 1229 using DNSSEC. Entities must evaluate their own environment and the 1230 chain of trust originating from their Trust Anchor, the associated 1231 threats and vulnerabilities, to determine the level of risk they are 1232 willing to accept. 1234 7. Acknowledgements 1236 The authors gratefully acknowledges, in no particular order, the 1237 contributions of the following persons: 1238 Richard Lamb 1239 Jakob Schlyter 1240 Stephen Morris 1242 8. References 1244 8.1. Normative References 1246 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1247 Rose, "DNS Security Introduction and Requirements", 1248 RFC 4033, March 2005. 1250 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1251 Rose, "Resource Records for the DNS Security Extensions", 1252 RFC 4034, March 2005. 1254 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1255 Rose, "Protocol Modifications for the DNS Security 1256 Extensions", RFC 4035, March 2005. 1258 8.2. Informative References 1260 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 1261 Wu, "Internet X.509 Public Key Infrastructure Certificate 1262 Policy and Certification Practices Framework", RFC 3647, 1263 November 2003. 1265 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1266 Security (DNSSEC) Hashed Authenticated Denial of 1267 Existence", RFC 5155, March 2008. 1269 Authors' Addresses 1271 Fredrik Ljunggren 1272 Kirei AB 1273 P.O. Box 53204 1274 Goteborg SE-400 16 1275 Sweden 1277 Email: fredrik@kirei.se 1279 Anne-Marie Eklund-Lowinder 1280 .SE (The Internet Infrastructure Foundation) 1281 P.O. Box 7399 1282 Stockholm SE-103 91 1283 Sweden 1285 Email: amel@iis.se 1287 Tomofumi Okubo 1288 Internet Corporation For Assigned Names and Numbers 1289 4676 Admiralty Way, Suite 330 1290 Marina del Ray, CA 90292 1291 USA 1293 Email: tomofumi.okubo@icann.org