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