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