DNSSEC Practice Statement for the Root Zone KSK Operator

	Root Zone KSK Operator DPS	March 2024
RZ KSK PMA	Informational	[Page]

Abstract

This document is the DNSSEC Practice Statement (DPS) for the Root Zone Key Signing Key (KSK) Operator. It states the practices and provisions that are used to provide Root Zone Key Signing and Key Distribution services. These include, but are not limited to: issuing, managing, changing and distributing DNS keys.¶

1. Introduction

This document is the DNSSEC Practice Statement (DPS) for Public Technical Identifiers (PTI) performing the Root Zone (RZ) Key Signing Key (KSK) Operator role described within. It states the practices and provisions that PTI employs in providing Root Zone Key Signing and Key Distribution services.¶

1.1. Overview

The Domain Name System Security Extensions (DNSSEC) is a set of the Internet Engineering Task Force (IETF) specifications for adding origin authentication and data integrity to the Domain Name System (DNS). DNSSEC provides a way for software to validate that DNS data has not been modified during Internet transit. This is done by incorporating public key cryptography into the DNS hierarchy to form a chain of trust originating at the Root Zone.¶

The DNS was not originally designed with strong security mechanisms to provide integrity and authenticity of DNS data. Over the years, a number of vulnerabilities have been discovered that threaten the reliability and trustworthiness of the system. DNSSEC addresses these vulnerabilities by adding data origin authentication, data integrity verification and authenticated denial of existence capabilities to the DNS.¶

This DPS is specifically applicable to the RZ KSK Operator. PTI performs this role by virtue of the Internet Assigned Numbers Authority (IANA) Naming Functions agreement with the Internet Corporation for Assigned Names and Numbers (ICANN). More generally, this document provides the governing practices and provisions related to the management, security, and technical specifications of DNSSEC operation at the Root. This document is under the control and management of PTI with guidance and direction from ICANN. Information in this document and subsequent documents will be made public as required.¶

The DPS is only one of a set of documents relevant to PTI's management of the RZ's KSK. Other documents supplement the DPS by providing more detailed requirements. In some instances, the DPS refers to these ancillary documents for specific, detailed practices implementing certain policies where including the specifics are not relevant to the purpose of the DPS.¶

1.2. Document Name and Identification

Document title:: DNSSEC Practice Statement for the Root Zone KSK Operator¶
Version:: 7th Edition (2024-03-15)¶

1.3. Community and Applicability

1.3.1. Root Zone Manager

PTI performs the management of the DNS Root Zone. This role includes accepting change requests to the contents of the Root Zone from the Top Level Domain (TLD) Operators and validating those requests. After validation occurs, implementation is performed by the Root Zone Maintainer.¶

PTI is an affiliate of ICANN, and performs these functions under an "IANA Naming Functions" contract from ICANN using the facilities, property, and staff of ICANN under a service agreement.¶

1.3.2. Root Zone Maintainer

Verisign is acting as the Root Zone Maintainer. They have historically performed this role under an agreement with the U.S. Government and have entered into an agreement to perform this function under contract from ICANN. The Root Zone Maintainer performs the function of receiving validated change requests to the Root Zone from the Root Zone Manager, implementing the changes, generating a new Root Zone File and distributing it to the Root Server Operators.¶

1.3.3. Root Server Operators

The Root Server Operators consist of 12 different professional engineering entities responsible for providing the Root Zone to the public via the 13 Root Zone Authoritative Name Servers.¶

The Root Server Operators are not involved in the making of any policies or modification of data.¶

1.3.4. Root Zone Key Signing Key Operator

PTI performs the RZ KSK Operator function of generating the RZ KSK and signing the Root key set, including the Root Zone Zone Signing Key (RZ ZSK), using the KSK. The RZ KSK Operator is also responsible for securely generating and storing the private keys and distributing the public portion of the KSK (the Trust Anchor) to the relying parties.¶

The RZ KSK Operator is responsible for:¶

(1): Generating and protecting the private component of the RZ KSK¶
(2): Securely importing public key components from the RZ ZSK Operator¶
(3): Authenticating and validating the public RZ ZSK key set¶
(4): Securely signing the RZ ZSK key set¶
(5): Securely transmitting the signed RZ ZSK key set to the RZ ZSK Operator¶
(6): Securely exporting the RZ KSK public key components¶
(7): Issuing an emergency key rollover within a reasonable time if any private key component associated with the zone is lost or suspected to be compromised¶

1.3.5. Root Zone Zone Signing Key Operator

The RZ ZSK Operator is Verisign performing the function of generating the RZ ZSK and signing the Root Zone File using the ZSK.¶

The RZ ZSK Operator is also responsible for securely generating and storing the private keys and distributing the public portion of the ZSK to the RZ KSK Operator for signing.¶

The RZ ZSK Operator is responsible for:¶

(1): Generating and protecting the private component of the RZ ZSK¶
(2): Securely exporting and transmitting the public RZ ZSK component to the RZ KSK Operator¶
(3): Securely importing the signed RZ ZSK key set from the RZ KSK Operator¶
(4): Signing the Root Zone's Resource Records (RRs) (optionally omitting the DNSKEY RR)¶
(5): Issuing an emergency key rollover within a reasonable time if any private key component associated with the zone is lost or suspected to be compromised¶

1.3.6. Child Zone Manager

The child zone (TLD) manager is a trustee for the delegated domain, and as such responsible for providing registry services and operating subordinate DNS servers. If a child zone is signed using DNSSEC, the child zone manager is also responsible for:¶

(1): Generating the keys associated with its zone using a trustworthy method¶
(2): Registering and maintaining the shorthand representations of its KSK (Delegation Signer, or DS, RR) in the parent zone to establish the chain of trust¶
(3): Taking reasonable precautions to prevent any loss, disclosure or unauthorized use of the keys associated with its zone¶
(4): Issuing an emergency key rollover within a reasonable time if any private key associated with its zone is lost or suspected to be compromised¶

1.3.7. Relying Party

A relying party is the entity that relies on DNSSEC, such as security-aware validating resolvers and other applications that perform validation of DNSSEC signatures.¶

The relying party must properly authenticate, configure and update the Trust Anchors as appropriate. The automated method described in [RFC5011] may be used.¶

Relying parties must be informed of any critical changes in the Root Zone operation as notified by the RZ KSK Operator in accordance with section 2.1.¶

1.3.8. Applicability

This DPS is only applicable to the Root Zone, and more specifically the RZ KSK Operator. Each link in the chain of trust may have entirely different requirements that can affect the end entity, and is not governed by this DPS.¶

Entities must evaluate their own environments and its associated threats and vulnerabilities to determine the level of risk they are willing to accept.¶

1.4. Specification Administration

This DPS is periodically reviewed and updated, as appropriate by the RZ KSK Operator Policy Management Authority (PMA). The PMA is comprised of representatives of PTI and ICANN and is responsible for the management of the DPS. The PMA should be considered as the point of contact for all matters related to the DPS.¶

1.4.1. Specification Administration Organization

Public Technical Identifiers
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094
United States of America
¶

1.4.2. Contact Information

RZ KSK Operator Policy Management Authority
Public Technical Identifiers
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094
United States of America
+1 (424) 254-5300 (voice)
root-ksk-pma@iana.org
¶

1.4.3. Specification Change Procedures

Amendments to this DPS are made by the RZ KSK Operator PMA. Amendments will either be in the form of a document containing an amended form of the DPS or an update. Amended versions or updates will be linked to the Practices Updates and Notices section of the RZ KSK Operator's Repository (See section 2.1). Updates supersede any designated or conflicting provisions of the referenced version of the DPS.¶

The PMA reserves the right to amend the DPS without notification for amendments that are not material, including without limitation corrections of typographical errors, changes to URLs, and changes to contact information. The PMA's decision to designate amendments as material or non-material is within the PMA's sole discretion. Amendments to the DPS, and proposals to amend the DPS will appear in the RZ KSK Operator's Repository, which is located at <https://www.iana.org/dnssec>. The PMA solicits proposed amendments to the DPS from the community. If the PMA considers such an amendment desirable, the PMA will provide public notice of such amendment in accordance with this section. Should the PMA determine that material amendments to the DPS are necessary immediately to stop or prevent a breach of the security of any portion of it, the PMA is entitled to make such amendments. Updates to the DPS are published in the RZ KSK Operator's Repository, and such amendments are effective immediately upon publication.¶

4. Facility, Management, and Operational Controls

4.1. Physical Controls

The RZ KSK Operator has implemented physical security controls, which support the security requirements of this DPS. Compliance with these policies is included in the independent audit requirements described in section 7.¶

4.1.1. Site Location and Construction

The RZ KSK operations are conducted within physically protected environments known as Key Management Facilities (KMFs) that deter, prevent, and detect any unauthorized use of, access to, or disclosure of sensitive information and systems, whether covert or overt. The RZ KSK Operator maintains disaster recovery capabilities for its DNSSEC operations by maintaining more than one KMF with comparable physical security.¶

4.1.2. Physical Access

The RZ KSK Operator's signer systems are protected by a minimum of four tiers of physical security, with access to lower tiers required before gaining access to higher tiers. Progressively more restrictive physical access controls to each tier are applied. Unauthorized access becomes increasingly difficult as one reaches higher tiers.¶

Sensitive DNSSEC operational activity and any activity related to the life cycle of the RZ KSK occur within these restrictive physical tiers.¶

Physical access is automatically logged and video recorded. All tiers enforce individual access control through the use of two-factor authentication. Unescorted personnel, including visitors or employees without specific authorization, are not allowed into such secured areas. The physical security system includes additional controls for tiers used for key management activity which serves to protect storage of Hardware Security Modules (HSMs) and keying material.¶

Areas used to create and store cryptographic material enforce dual access control, each through the use of two-factor authentication. HSMs are protected through the use of tamper-evident bags, locked safes, cabinets, or containers. Access to HSMs and keying material is restricted in accordance with the RZ KSK Operator's segregation of duty requirements. The opening and closing of cabinets or containers in these tiers is logged for auditing purposes.¶

4.1.3. Power and Air Conditioning

The RZ KSK Operator's secure facilities are equipped with primary and backup power systems to ensure continuous, uninterrupted access to electric power and backup heating/ventilation/air conditioning systems to control temperature and relative humidity.¶

4.1.4. Water Exposures

The RZ KSK Operator has taken reasonable precautions to minimize the impact of water exposure to the signer systems.¶

4.1.5. Fire Prevention and Protection

The RZ KSK Operator has taken reasonable precautions to prevent and extinguish fires and/or other damaging exposure from flame or smoke. The RZ KSK Operator's fire prevention and protection measures have been designed to comply with local fire safety regulations.¶

4.1.6. Media Storage

All media containing production software and data, audit, archive, or backup information are stored within the RZ KSK Operator's facilities or in a secure off-site storage facility with appropriate physical and logical access controls designed to limit access to authorized personnel and protect such media from accidental damage (e.g., water, fire, and electromagnetic radiation).¶

4.1.7. Waste Disposal

Sensitive documents and materials are shredded before disposal. Media used to collect or transmit sensitive information is rendered unreadable before disposal. Cryptographic devices are physically destroyed or zeroized in accordance with the manufacturers' guidance prior to disposal. Other waste is disposed of in accordance with the RZ KSK Operator's normal waste disposal requirements.¶

4.1.8. Off-Site Backup

The RZ KSK Operator performs routine backups of critical system data, audit log data, and other sensitive information. Off-site backup media is stored in a physically secure manner using a bonded third party storage facility.¶

4.2. Procedural Controls

4.2.1. Trusted Roles

The RZ KSK Operator considers the categories of personnel identified in this section as Trusted Persons having a Trusted Role. A Trusted Person may only possess one Trusted Role. Persons seeking to become Trusted Persons by obtaining a Trusted Role must successfully complete the screening requirements set out in this DPS.¶

Trusted Persons include all employees, contractors, and consultants of either PTI or ICANN that have access to or control operations that may materially affect:¶

Generation and protection of the private component of the RZ KSK¶
Secure export or import of any public components¶
Zone File data¶

Trusted roles include, but are not limited to:¶

System Administrators¶
Crypto Officers¶
Recovery Key Share Holders¶
Safe Security Controllers¶
Internal Witnesses¶
Ceremony Administrators¶

4.2.2. Number of Persons Required per Task

The RZ KSK Operator has established, maintains, and enforces rigorous control procedures to ensure the segregation of duties based on roles and to ensure that multiple Trusted Persons are required to perform sensitive tasks.¶

The most sensitive tasks, such as access to and management of cryptographic key material, are enforced by rigorous control procedures to ensure the segregation of duties based on roles. These procedures also ensure that multiple Trusted Persons are required to perform any sensitive tasks.¶

Access to and management of cryptographic hardware is based on the principle of successive barriers in three tiers, requiring at least seven trusted persons from four different roles. These barriers are as follows:¶

Tier 5:: Physical access to safe room requires one person from the Key Ceremony Administrator role in combination with one person from the Internal Witness roles.¶
Tier 6:: Physical access to HSMs and activation material requires one out of two of the Safe Security Controller #1s, and one out of the two Safe Security Controller #2s in addition to the Trusted Persons required at Tier 5 and 7.¶
Tier 7:: Activation of an HSM requires three out of seven Crypto Officers to extract activation material from above safe deposit boxes using their physical key. Safe deposit box operation that involves opening of any one of the deposit box requires three out of seven Crypto Officers to be present.¶

Restoration of the contents of an HSM requires several trusted persons from multiple roles, as follows:¶

Storage Master Key (SMK):: Reconstruction of the SMK used for encryption of the application keys requires five out of seven Recovery Key Share Holders.¶
Domain Key:: Reconstruction of the domain key used for secure key transfer between HSMs and partitions, requires five out of seven Recovery Key Share Holders or Crypto Officers.¶
Encrypted Application Keys:: Physical access to the encrypted application keys requires one person from the Ceremony Administrators role, one person from the Internal Witness role, and one of two Safe Security Controller #1s.¶

These combinations of people are designed so that the binomial probability to find a group collaborating in any of these constellations is less than one in a million, assuming a dishonesty rate of 5% among Trusted Persons¶

Other internal control procedures are designed to ensure that at a minimum of two Trusted Persons are required to perform any sensitive task.¶

4.2.3. Identification and Authentication for Each Role

For all personnel seeking to become Trusted Persons, verification of identity is performed through the personal (physical) presence of such personnel before Trusted Persons performing security functions and a check of well-recognized forms of identification (e.g., passports and driver's licenses). Identity is further confirmed through the background checking procedures described in section 4.3 of this DPS. The RZ KSK Operator ensures that personnel have achieved Trusted Status and approval has been given before these personnel are:¶

Issued access devices and granted access to the required facilities¶
Issued electronic credentials to access and perform specific functions on the RZ KSK Operator's IT systems¶

4.2.4. Tasks Requiring Separation of Duties

Tasks requiring separation of duties include (but are not limited to) the generation, use, and destruction of Root Zone DNSSEC key material.¶

Personnel holding a role in the multi-party access to the RZ KSK do not hold a role in the multi-party access to the RZ ZSK, or vice versa. Audit personnel also may not participate in the multi-person control for the RZ KSK or RZ ZSK.¶

4.3. Personnel Controls

4.3.1. Qualifications, Experience, and Clearance Requirements

The RZ KSK Operator requires that personnel seeking to become Trusted Persons present proof of the requisite background, qualifications, and experience needed to perform their prospective job responsibilities competently and satisfactorily.¶

Background checks are repeated at least every 5 years for personnel holding Trusted Roles.¶

4.3.2. Background check procedures

All personnel with access to any cryptographic components used with the Root Zone Signing process are required to pass a background check extending back at least three years.¶

Prior to commencement of engagement in a Trusted Role, the RZ KSK Operator conducts background checks that include the following:¶

Confirmation of previous employment¶
Check of professional references¶
Confirmation of the highest or most relevant educational degree obtained¶
Check of credit/financial records to the extent allowed by national laws for the individual's country of residence¶

The factors revealed in a background check that may be considered grounds for rejecting candidates for Trusted Roles, or for taking action against an existing Trusted Person generally include, but are not limited to:¶

Misrepresentations made by the candidate or Trusted Person¶
Highly unfavorable or unreliable professional references¶
Indications of a lack of financial responsibility¶

Reports containing such information are evaluated by human resources and security personnel, who determine the appropriate course of action in light of the type, magnitude, and frequency of the behavior uncovered by the background check.¶

Such actions may include measures up to and including the cancellation of offers of employment made to candidates for Trusted Roles or the termination of existing Trusted Persons. The use of information revealed in a background check to take such actions is subject to the applicable federal, state, and local laws.¶

4.3.3. Training Requirements

The RZ KSK Operator provides its personnel with training when hired, as well as the requisite on-the-job training needed for them to perform their job responsibilities competently and satisfactorily. The RZ KSK Operator periodically reviews and enhances its training programs as necessary.¶

The RZ KSK Operator's training programs are tailored to the individuals' responsibilities and include the following as relevant:¶

Basic DNS/DNSSEC concepts¶
Job responsibilities¶
Use and operation of deployed hardware and software¶
Security and operational policies and procedures¶
Incident and compromise reporting and handling¶
Disaster recovery and business continuity procedures¶

4.3.4. Retraining Frequency and Requirements

The RZ KSK Operator provides refresher training and updates to their personnel to the extent and frequency required to ensure that such personnel maintain the required level of proficiency to perform their job responsibilities competently and satisfactorily.¶

4.3.5. Job Rotation Frequency and Sequence

The responsibility to execute the tasks of respective Trusted Roles will be distributed evenly over the set of the appointed personnel.¶

Recovery Key Share Holders and Crypto Officers will be serving limited terms. Refer to Trusted Community Representatives - Proposed Approach to Root Key Management [TCRS] for the original proposal for TCR participation.¶

Other positions are rotated and replaced as needed.¶

4.3.6. Sanctions for Unauthorized Actions

Appropriate disciplinary actions are taken for unauthorized actions with respect to this DPS and/or other violations of the RZ KSK Operator's security policies and procedures. Disciplinary actions may include measures up to and including termination and are commensurate with the frequency and severity of the unauthorized actions.¶

4.3.7. Contracting Personnel Requirements

In limited circumstances, independent contractors or consultants may be used to fill Trusted Roles. Any such contractor or consultant is held to the same functional and security criteria that apply to any PTI and ICANN employees in a comparable role. Independent contractors and consultants who have not completed or passed the background check procedures specified in DPS section 4.3 are permitted access to the RZ KSK Operator's secure facilities only to the extent they are escorted and directly supervised by Trusted Persons at all times.¶

4.3.8. Documentation Supplied to Personnel

PTI and ICANN provide their employees the requisite training and other documentation needed to perform their job responsibilities competently and satisfactorily.¶

4.4. Audit Logging Procedures

4.4.1. Types of Events Recorded

Specific auditing events related to KSK key life cycle management events, including:¶

Key generation, backup, storage, recovery, archival, and destruction¶
Exporting of public key components¶

KSK signing and management events, including:¶

Key activation¶
Receipt and validation of public key material (i.e., from the ZSK holder)¶
Successful or unsuccessful signing requests¶

Security-related events, including:¶

Assignment and revocation of credentials¶
Successful and unsuccessful system access attempts¶
Key and security system actions performed by trusted personnel¶
Security sensitive files or records read, written, or deleted¶
Security profile changes¶
System crashes, hardware failures and other anomalies¶
Facility visitor entry/exit¶
System changes and maintenance/system updates¶
Incident response handling¶

Log entries include the following elements:¶

Date and time of the entry¶
Identity of the entity making the journal entry¶
Type of entry¶

Other events as appropriate.¶

4.4.2. Frequency of Audit Log Processing

Audit logs are examined after each key ceremony for significant security and operational events. In addition, the RZ KSK Operator reviews its audit logs for suspicious or unusual activity in response to alerts generated based on irregularities and incidents within the DNSSEC related systems. Audit log processing consists of a review of the audit logs and documentation for all significant events in an audit log summary. Audit log reviews include a verification that the log has not been tampered with and an investigation of any alerts or irregularities in the logs. Actions taken based on audit log reviews are also documented.¶

4.4.3. Retention Period for Audit Log Information

All audit data collected in terms of section 4.4.1 is retained on-site for at least one year after creation and then archived for at least 10 years.¶

The media holding the audit data and the applications required to process the information are maintained to ensure that the archived data can be accessed for the time period set forth in this DPS.¶

4.4.4. Protection of Audit Log

Audit logs are kept offline and protected with an audit log handling procedure that includes mechanisms to protect the log files from unauthorized viewing, modification, deletion, or other tampering.¶

Only authorized Trusted Persons are able to obtain direct access to the audit information.¶

4.4.5. Audit Log Backup Procedures

The RZ KSK Operator backs up electronic archives of its audit information in an off-site secure facility after each key ceremony. Copies of paper-based records are also stored off-site and are maintained in the same manner.¶

4.4.6. Audit Collection System

Automated audit data is generated and recorded at the application and operating system level. Manually generated audit data is recorded by the Ceremony Administrator on paper.¶

After each completed Key Ceremony, the audit log information is collected by the Ceremony Administrator at the generating host and copied onto at least two portable media. Electronic copies of paper-based documents are also made.¶

The Ceremony Administrator is responsible for storing one copy of the audit log information at the off-site secure facility, and one copy with the signer system.¶

4.4.7. Notification to Event-Causing Subject

No notice is required to be given to the individual, organization, device, or application causing a log event.¶

4.4.8. Vulnerability Assessments

Events in the audit process are logged, in part, to monitor system vulnerabilities. Vulnerability assessments are performed manually as part of the audit log review process after each key ceremony.¶

The RZ KSK Operator also maintains contacts with relevant parties within the community to share the latest security-related information which may affect the signed Root Zone. Continuous vulnerability assessments are made based on this information.¶

4.5. Incident Handling and Disaster Recovery

4.5.1. Incident Handling Procedures

If the RZ KSK Operator detects an event that has led to, or could have led to a security compromise of any of the security mechanisms, it will perform an investigation in order to determine the nature of the incident. If the incident is suspected to have compromised the private component of an active KSK, the Emergency KSK rollover procedure will be enacted as described in section 4.5.3.¶

Otherwise, the scope, severity, and damage of the incident will be assessed and a plan to remedy the effect will be developed and implemented. The plan will also include measures to prevent the event from reoccurring.¶

The incident handling procedures include reporting of all events to RZ KSK Operations Security (RKOS), which in turn reports to the RZ KSK PMA.¶

4.5.2. Corrupted Computing Resources, Software, and/or Data

In the event of the corruption of computing resources, software, and/or data, this occurrence will be reported to RKOS and will cause the RZ KSK Operator's incident handling procedures to be enacted. Such procedures require appropriate escalation, incident investigation, and incident response. If necessary, the RZ KSK Operator's key compromise or disaster recovery procedures will be enacted as described in section 4.5.4 and 4.5.3.¶

4.5.3. Entity Private Key Compromise Procedures

4.5.3.1. Key Signing Key Compromise

The RZ KSK Operator has established and maintains Emergency KSK rollover procedures to ensure readiness for key compromise situations.¶

Upon the suspected or known compromise of a RZ KSK, RKOS will assess the situation, develop an appropriate action plan, and implement the action plan with approval from the PMA and PTI executive management.¶

As part of the KSK emergency rollover procedures, the RZ KSK Operator maintains the capability of being able to generate and publish an interim Trust Anchor within 48 hours. In favorable circumstances, this interim Trust Anchor may be used to facilitate an orderly [RFC5011] automatic KSK rollover to a new and sanctioned Trust Anchor generated at a new scheduled key ceremony, held within reasonable time.¶

The RZ KSK Operator will inform the community of any emergency as soon as possible using the channels stipulated in section 2.1.¶

4.5.3.2. Key Signing Key Loss

If the private component of a Trust Anchor is permanently lost, the latest point in time where this loss is detected will inevitably be at the key ceremony when it is supposed to be used. At this point in time, the Root Zone Maintainer/ZSK Operator has signatures for at least 33 days (see section 6.6) of independent operations.¶

If possible, a new KSK will be generated at this key ceremony or another ceremony scheduled within 48 hours. If the RZ KSK Operator is unable to accommodate the key ceremony, an interim KSK must be generated by the RZ KSK Operator and published as a Trust Anchor within the stipulated 48 hours.¶

The community is then given a minimum of 30 days notice to add the new Trust Anchors to the validating resolvers before the DNSKEY RRset has to be re-signed with the new Trust Anchor. Failure to update a validating resolver will render that resolver inoperable.¶

The RZ KSK Operator will inform the community of any emergency as soon as possible using the channels stipulated in section 2.1.¶

The old Trust Anchor will remain untouched in the key set for one 10 day time slot (see section 6.6). In the next consecutive time slot the old Trust Anchor will be marked as revoked, and after this time slot the lost key is permanently removed.¶

4.5.3.3. Zone Signing Key Compromise

The RZ KSK Operator will support Root Zone Zone Signing Key emergency rollover in the case of RZ ZSK compromise while following the RZ ZSK Operator's procedural directions. Refer to the RZ ZSK Operator's DPS for details.¶

4.5.4. Business Continuity and IT Disaster Recovery Capabilities

The RZ KSK Operator has implemented at least two fully-functional, geographically and logically dispersed KMFs, which at any point in time hold the data required for production, and are evenly utilized. All KMFs implement the same physical security protections and operational controls as specified in section 4.1.2.¶

The RZ KSK Operator has developed, implemented, and tested a business continuity and IT disaster recovery plan to mitigate the effects of natural, man-made, or technological disasters or other disasters that requires temporary or permanent cessation of operations from any of the RZ KSK Operator's facilities. The business continuity and IT disaster recovery plans are in place to address the restoration of information systems services and key business functions. These plans address:¶

Roles and responsibilities in the event of a disaster¶
Fallback procedures for restoring business-critical processes within acceptable times¶
Resumption procedures for restoring normal operations¶
The criteria for activating the plan¶

The RZ KSK Operator maintains the capability to restore or recover essential operations within 48 hours following a disaster with support for at minimum the following functions:¶

Communication with the public¶
Ability to import Key Signing Requests (KSRs) and export Signed Key Responses (SKRs)¶
Generation of KSKs¶
Processing and signing of KSR contents¶
Publishing the Trust Anchor¶

The RZ KSK Operator maintains redundant hardware and backups of its infrastructure system software at all KMFs. In addition, private keys are backed up and maintained in accordance with DPS section 5.2.4, and in such a way that critical keying material is distributed to all KMFs before put into production.¶

The RZ KSK Operator's business continuity and IT disaster recovery plans have been designed to provide full recovery within one week at the alternative KMF following any incident or disaster occurring at any of the RZ KSK Operator's KMFs.¶

When possible, operational status is restored as soon as possible following any incident or disaster.¶

These plans are regularly tested, validated, and updated to be operational in the event of any incident or disaster. Results of such tests are reviewed and kept for audit and planning purposes.¶

4.5.4.1. Variances

In the event of a declaration of a disaster recovery or business continuity response, the adverse event may necessitate variances to the procedural controls and technical security controls. These variances shall be limited in scope to those necessary for the successful conduct of key signing operations, and according to protocols that best ensures a proper record of the chain-of-custody and limiting sensitive operations to trusted persons. The RZ KSK Operator shall ensure such variances are consented by the RZ KSK Operator's management, are documented and communicated.¶

4.6. Entity Termination

The RZ KSK Operator has implemented a DNSSEC termination plan in the event that the roles and responsibilities of the RZ KSK Operator must transition to other entities. The Root Zone Manager will coordinate with the Root Zone ZSK Operator in order to execute the transition in a secure and transparent manner.¶

The DNSSEC termination plan also includes procedures in the event of the termination of the Root Zone Maintainer and/or RZ ZSK Operator.¶

5. Technical Security Controls

5.1. Key Pair Generation and Installation

5.1.1. Key Pair Generation

RZ KSK key pair generation is performed by multiple pre-selected, trained, and trusted individuals using Trustworthy Systems and processes that provide for the security and required cryptographic strength for the generated keys.¶

KSK key pairs are generated in pre-planned key generation ceremonies in accordance with the requirements of the KSK Key Management Procedure. The activities performed in each key generation ceremony are recorded, dated, and signed by the Ceremony Administrator. These records are kept for audit and tracking purposes as required in section 4.4.3.¶

5.1.2. Public Key Delivery

The public component of a Trust Anchor will be distributed in a secure fashion to preclude substitution attacks.¶

Acceptable methods for delivery and validation of Trust Anchors include, but are not limited to:¶

In-band as zone data in DNSKEY RRset, with proof traceable to the previous Trust Anchor as described in [RFC5011]¶
Publication of the Trust Anchor in the repository, protected and authenticated via TLS/SSL, while also providing S/MIME [RFC5751] and other signatures traceable to the RZ KSK Operator and optionally other parties¶
Proof distributed out-of-band directly to the witnesses participating at the key ceremony, whereas distribution to their respective communities at the witness' own discretion¶

5.1.3. Public Key Parameters Generation and Quality Checking

For the current key size, primality testing of RSA parameters (p and q) will be performed to ensure with a probability less than 2^-100 that the numbers are not composite.¶

Quality checking will also include validating the size of the public exponent to be both resource efficient and secure.¶

5.1.4. Key Usage Purposes

Any RZ KSK private key will only be used for signing the Root Zone's DNSKEY RRset or self-signing using the same padding scheme in order to prove possession of the private key.¶

Any RRSIG record generated as a result of a KSK signing operation will not have a validity period longer than 21 days, and will never expire more than 180 days in the future.¶

Disaster recovery procedures may override the standard RRSIG expiration period if reasonable concerns exist regarding the ability to conduct subsequent key signing operations during their allotted window. Additional RRSIG records may be generated further in advance of the standard validity period, which would remain in the possession of the RZ KSK Operator until the time in which all RRSIG records in the set would not expire more than 180 days in the future. The RZ KSK Operator will withhold RRSIG records generated for future validity periods using methods which reasonably safeguard the confidentiality, integrity, and availability of the RRSIG records utilizing a KMF and an offsite storage facility until they are transmitted to the RZ ZSK Operator. This scenario requires consent between the RZ KSK and RZ ZSK Operators and approval from their respective executive management.¶

5.2. Private Key Protection and Cryptographic Module Engineering Controls

All cryptographic functions involving the private component of the KSK are performed within the HSM; that is, the private component will not be exported from the HSM except in encrypted form for purposes of key backup.¶

5.2.1. Cryptographic Module Standards and Controls

For RZ KSK generation and RZ KSK private component operations and storage, the RZ KSK Operator shall use HSMs that are validated to meet relevant industry security requirements. HSMs shall meet either FIPS 140-2 or FIPS 140-3, at level 3 or higher. In the event there are no suitable HSMs that have been certified to these requirements, HSMs that are pending certification may be used as a temporary measure.¶

5.2.2. Private Key (M-of-N) Multi-Person Control

The RZ KSK Operator has implemented technical and procedural mechanisms that require the participation of multiple trusted individuals to perform sensitive cryptographic operations. The RZ KSK Operator splits activation data needed to make use of the RZ KSK private key onto separate credentials controlled by trusted individuals (Crypto Officers) selected from members of the Internet community not already part of Root Zone management operations. Specifically, organizationally separate parties, not affiliated with PTI, ICANN, or Verisign.¶

A threshold number of credentials (m) out of the total number of credentials created and distributed for a particular hardware security module (n) is required to activate a RZ KSK private key stored on the module. The threshold number of credentials needed to sign using the RZ KSK is three out of seven. The credentials are protected in accordance with section 5.4.2.¶

5.2.3. Private Key Escrow

Private components of RZ KSKs are not escrowed.¶

5.2.4. Private Key Backup

Encrypted copies of the RZ KSK private key(s) are backed up onto portable media held by the RZ KSK Operator and sent by courier to the other facilities. The key used to encrypt the private key(s) is backed up using a five out of seven threshold scheme with credentials distributed to trusted individuals (Recovery Key Share Holders) selected from members of the Internet community not already part of Root Zone management operations (specifically, organizationally separate parties, not affiliated with PTI, ICANN, or Verisign). The Recovery Key Share Holders keep the credentials in tamper-evident bags, stored in geographically dispersed locations under their control.¶

5.2.5. Private Key Storage on Cryptographic Module

Private keys held on hardware cryptographic modules are stored in encrypted form.¶

5.2.6. Private Key Archival

The private half of the RZ KSK key pair is not archived after rollover. This eliminates the possibility of its misuse in RZ KSK rollover or revocation after its suppression.¶

5.2.7. Private Key Transfer Into or From a Cryptographic Module

The RZ KSK Operator generates RZ KSK key pairs on the HSMs in which the keys will be used. In addition, the RZ KSK Operator makes copies of these key pairs for routine recovery and disaster recovery purposes. When key pairs are backed up to another HSM, these key pairs are transported between modules in encrypted form.¶

5.2.8. Method of Activating Private Key

The RZ KSK private key will be activated using three out of seven Crypto Officer controlled credentials that must be inserted into the HSM, one at a time, while entering the Crypto Officers' PIN.¶

5.2.9. Method of Deactivating Private Key

The RZ KSK private key may be deactivated by three out of seven Crypto Officer controlled credentials being inserted into the HSM, one at a time, while entering the Crypto Officers' common PIN. The credentials that were not used to activate the RZ KSK private key in the ceremony will be preferentially used for deactivation.¶

Alternatively, the RZ KSK private keys may be deactivated upon system shutdown.¶

5.2.10. Method of Destroying Private Key

When required, the RZ KSK Operator destroys RZ KSK private keys in a manner that reasonably ensures that there are no residual remains of the keys that could lead to the reconstruction of the keys. The RZ KSK Operator utilizes the zeroization function of its HSMs and other appropriate means to ensure the complete destruction of RZ KSK private keys. When performed, private key destruction activities are logged as part of a key ceremony.¶

5.3. Other Aspects of Key Pair Management

5.3.1. Public Key Archival

RZ KSK public keys are backed up and archived.¶

5.3.2. Key Usage Periods

The Operational Period of an RZ KSK ends upon its supersession. The superseded RZ KSK will never be reused to sign an RR while in retention.¶

5.4. Activation Data

5.4.1. Activation Data Generation and Installation

Activation data used to protect access to HSMs containing RZ KSK private keys is generated in accordance with the requirements of DPS section 5.1 and the KSK Key Management Procedure. The creation and distribution of these credentials and/or access to them is logged.¶

5.4.2. Activation Data Protection

Crypto Officers safeguard the credentials needed to access activation data.¶

When required, activation data will be decommissioned using methods that protect against the loss, theft, modification, unauthorized disclosure, or unauthorized use of the private keys protected by this activation data.¶

5.4.3. Other Aspects of Activation Data

Each Crypto Officer holds a physical key to one safe deposit box located inside a safe within the RZ KSK Operator's safe room. This safe deposit box contains the Crypto Officer's credentials stored in a tamper-evident bag with an individual ID. It is the Crypto Officer's responsibility to safeguard and securely store their physical key between key ceremonies.¶

5.5. Computer Security Controls

The RZ KSK Operator ensures that the systems maintaining key software and data files are Trustworthy Systems secure from unauthorized access. In addition, the RZ KSK Operator limits access to production servers to those individuals with a valid business reason for such access. General application users do not have accounts on production servers.¶

5.6. Network Security Controls

No part of the signer system making use of the HSM is connected to any communications network. Communication of ZSK KSRs from the Root Zone Maintainer/ZSK Operator is done using a TLS client-side authenticated web server connected to the RZ KSK Operator's production network. Transfer of a KSR from the web server to the signer system is performed manually using removable media (refer to section 6.7 for further details on verification of the KSR).¶

The RZ KSK Operator's production network is logically separated from other components. This separation prevents network access except through defined application processes. The RZ KSK Operator uses firewalls to protect the production network from internal and external intrusion and limit the nature and source of network activities that may access production systems related to key signing activities.¶

5.7. Timestamping

Time will be derived through a manual procedure before each key ceremony. The ceremony administrator will manually set the signer system clock and the wall clock to current UTC time drawn from a reliable time source.¶

Time derived from the procedure will be used for timestamping of¶

Electronic and paper based audit log records¶
DNSSEC signatures expiration and inception times¶

Asserted times are required to be accurate within three minutes.¶

5.8. Life Cycle Technical Controls

5.8.1. System Development Controls

The RZ KSK Operator's Software Development Life Cycle (SDLC) procedures for the RZ KSK key generation and signer software implements relevant parts of NIST SP 800-160 Volume 1 (Implementation Process) for incorporating security and trustworthiness into the SDLC.¶

In addition, all critical parts of the signer modules developed by the RZ KSK Operator will be subject to external code review. The code review is required to certify that:¶

There is a documented architectural design describing the security domains and functions maintained by the signer¶
The architectural design demonstrates that the signer system prevents bypass of the security-enforcing functionality¶
There is a functional specification completely representing the signer system and all operations associated with it¶
There is a modular design description and a one-to-one correspondence with the modular decomposition of the implementation¶
The implementation representation completely and accurately implements the security-enforcing functions¶

The RZ KSK Operator developed software, when first loaded, provides a method to verify that the software on the system originated from the RZ KSK Operator, has not been modified prior to installation, and is the version intended for use.¶

5.8.2. Security Management Controls

The RZ KSK Operator has mechanisms in place to control and monitor the configuration of its systems. The RZ KSK Operator creates a hash of all software packages and software updates. This hash is used to verify the integrity of such software manually. Upon installation and periodically thereafter, the RZ KSK Operator validates the integrity of its systems.¶

5.8.3. Life Cycle Security Controls

The signer system is designed to require a minimum of maintenance. Updates critical to the security and operations of the signer system will be applied after formal testing and approval. The origin of all software and firmware will be securely authenticated by available means.¶

Critical hardware components of the signer system will be procured directly from the manufacturer and transported in tamper-evident bags to their destination in the secure facility. Any hardware will be decommissioned well before reaching the end of its specified life expectancy.¶

6. Zone Signing

The RZ KSK Operator provides the the RZ ZSK Operator with signed and valid DNSSEC RRset for the RZ KSK Operator's current keys and the KSKs.¶

The Root Zone Maintainer includes this key set into the Root Zone File, adds the Next Secure (NSEC) RRs, and creates signatures for all relevant records. The Root Zone is then distributed to the Root Server Operators.¶

The daily Root Zone signing will be conducted semi-automatically by the Root Zone Maintainer's system.¶

6.1. Key Lengths and Algorithms

Key pairs are required to be of sufficient length to prevent others from determining the key pair's private key using crypto-analysis during the period of expected utilization of such key pairs.¶

The current RZ KSK key pair(s) is an RSA key pair, with a modulus size of 2048 bits.¶

6.2. Authenticated Denial of Existence

Authenticated denial of existence will be provided through the use of NSEC RRs as specified in [RFC4034].¶

6.3. Signature Format

The cryptographic hash function used in conjunction with the signing algorithm is required to be sufficiently resistant to preimage attacks during the time in which the signature is valid.¶

The RZ KSK signatures will be generated by encrypting SHA-256 hashes using RSA [RFC5702].¶

6.4. Zone Signing Key Rollover

ZSK rollover is carried out quarterly automatically by the Root Zone ZSK Operator's system as described in the RZ ZSK Operator's DPS.¶

6.5. Key Signing Key Rollover

Each RZ KSK will be scheduled to be rolled over through a key ceremony as required, or after 5 years of operation.¶

RZ KSK rollover is scheduled to facilitate automatic updates of resolvers' Trust Anchors as described in [RFC5011].¶

After an RZ KSK has been removed from the key set, it will be retained after its operational period until the next scheduled key ceremony, when the private component will be destroyed in accordance with section 5.2.10.¶

6.6. Signature Lifetime and Re-Signing Frequency

The signing practice of the Root Zone is divided into quarterly continuous time cycles of approximately 90 days. Time cycles begin on the following dates each year:¶

January 1st¶
April 1st¶
July 1st¶
October 1st¶

For each of these time cycles there is a key ceremony scheduled during the previous calendar quarter, but no later than 33 days before the time cycle commences. At this key ceremony, all of the necessary RZ KSK operations are performed to enable the Root Zone Maintainer to operate and publish the zone independently throughout the period.¶

To facilitate automatic updates of resolvers' Trust Anchors as described in [RFC5011] while minimizing the number of keys in the key set, each of the ~90 day time cycles is divided into 10 day slots (9 slots).¶

The time cycle will never last less than 90 days. If the time cycle is more than 90 days, the last slot in the cycle will be expanded to fill the period.¶

For each of these slots there is a pre-generated DNSKEY key set that is signed at the key ceremony with 21 days validity time to allow for signature overlap. The Root Zone Maintainer is responsible for selecting the current key set and publishing it with the corresponding valid signature.¶


             | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |

RRSIG 1      |---->|
RRSIG 2          |---->|
RRSIG 3              |---->|
RRSIG 4                  |---->|
RRSIG 5                      |---->|
RRSIG 6                          |---->|
RRSIG 7                              |---->|
RRSIG 8                                  |---->|
RRSIG 9                                      |---->|

Figure 1: DNSKEY RRSIG's validity period within the cycle

The Root Zone Maintainer may use slots at the edges of every time cycle for pre-publishing and post-publishing of RZ ZSK rollovers.¶


             | 1 | 2 - 8 | 9 || 1 | 2 - 8 | 9 || 1 | 2 - 8 | 9 |

ZSK n-1   ===|-->|
ZSK n     ---|===============||-->|
ZSK n+1                  |---||===============||-->|
ZSK n+2                                   |---||===============|-->
ZSK n+3                                                    |---|==>

KSK n     ===================||===|-----------||---|+++++++|
KSK n+1          |-----------||---|===========||===============|==>


                                    (-) pre-publish or post-publish
                                    (+) signing with revoke bit set
                                    (=) used for signing

Figure 2: Idealized 270 day cycle of ZSK rollovers with critical phases of a KSK rollover

In the event of an RZ KSK rollover and RZ ZSK rollovers in the same cycle, time slots are used for pre-publishing, post-publishing, adding, and deleting Trust Anchors in the following order:¶

RZ KSK Pre-Publication:
Slot 1:: publish ZSK (n) + ZSK (n-1) + KSK (n), sign DNSKEY RRset with KSK (n)¶
Slot 2-8:: publish ZSK (n) + KSK (n) + KSK (n+1), sign DNSKEY RRset with KSK (n)¶
Slot 9:: publish ZSK (n) + ZSK (n+1) + KSK (n) + KSK (n+1), sign DNSKEY RRset with KSK (n)¶
RZ KSK Rollover:
Slot 1:: publish ZSK (n) + ZSK (n+1) + KSK (n) + KSK (n+1), sign DNSKEY RRset with KSK (n)¶
Slot 2-8:: publish ZSK (n+1) + KSK (n) + KSK (n+1), sign DNSKEY RRset with KSK (n+1)¶
Slot 9:: publish ZSK (n+1) + ZSK (n+2) + KSK (n) + KSK (n+1), sign DNSKEY RRset with KSK (n+1)¶
RZ KSK Revocation:
Slot 1:: publish ZSK (n+1) + ZSK (n+2) + KSK (n) + KSK (n+1), sign DNSKEY RRset with KSK (n+1)¶
Slot 2-8:: publish ZSK (n+2) + KSK (n+1) + revoke KSK (n), sign DNSKEY RRset with revoke KSK (n) + KSK (n+1)¶
Slot 9:: publish ZSK (n+2) + ZSK (n+3) + KSK (n+1), sign DNSKEY RRset with KSK (n+1)¶

At each publication, the Root Zone Maintainer selects and includes the current key set and corresponding signature(s), and then signs all other authoritative records within the Root Zone using the current RZ ZSK. In this way, all phases of the KSK rollover can be postponed or reverted up until the revocation phase.¶

Each key set within the KSR is self-signed with the active key to provide proof of possession of the corresponding private key. The signer system will automatically validate this signature and perform checking of available parameters before accepting the KSR for signing.¶

The RZ KSK Operator will verify the authenticity of the KSR document by performing an out-of-band verification (verbally over the phone, by fax, or any other available method) of the hash of the KSR, before entering the KSR into the signer system. The resulting SKR is transferred back using the same TLS client-side authenticated connection used to receive the KSR from the Root Zone Maintainer.¶

6.8. Verification of Resource Records

Signature verification will be performed on the signer system that holds both the signed and the unsigned key set prior to the compilation of the SKR. Integrity of the signatures in the SKR is verified by the RZ ZSK Operator using the published Root Zone Trust Anchor.¶

6.9. Resource Records Time-To-Live

Table 1: Resource Records Time-To-Live
RRTYPE	TTL
DNSKEY	48 hours
NSEC	same as SOA minimum (24 hours)
DS	24 hours
RRSIG	same as the covered RR (varies)

Appendix A. Table of Acronyms and Definitions

A.1. Acronyms

Table 2: Acronyms
Term	Definition
AICPA	American Institute of Certified Public Accountants
DNS	Domain Name System
DNSKEY	Domain Name System Key
DNSSEC	Domain Name System Security Extensions
DPS	DNSSEC Practice Statement
DS	Delegation Signer
FIPS	Federal Information Processing Standards
HSM	Hardware Security Module
HTTPS	Hypertext Transfer Protocol Secure
IANA	Internet Assigned Numbers Authority
ICANN	Internet Corporation for Assigned Names and Numbers
IETF	Internet Engineering Task Force
KMF	Key Management Facility
KSK	Key Signing Key
KSR	Key Signing Request
NIST	National Institute of Standardization of Technology
NSEC	Next Secure
PIN	Personal Identification Number
PMA	Policy Management Authority
PTI	Public Technical Identifiers
RFC	Request for Comments
RKOS	Root Zone KSK Operations Security
RR	Resource Record
RRset	Resource Record Set
RRSIG	Resource Record Signature
RZ	Root Zone
S/MIME	Secure/Multipurpose Internet Mail Extensions
SDLC	Software Development Life Cycle
SHA	Secure Hash Algorithm
SKR	Signed Key Responses
SMK	Storage Master Key
SOA	Start of Authority
SOC	Service Organization Control
SP	NIST Special Publication
SSL	Secure Sockets Layer
TLD	Top Level Domain
TLS	Transport Layer Security
TTL	Time To Live
US	United States
UTC	Coordinated Universal Time
ZSK	Zone Signing Key

A.2. Definitions

Table 3: Definitions
Term	Definition
Chain of Trust	DNS keys, signatures, and Delegation Signer records that, when validated in a series, can provide proof of authenticity of the last element in the chain using the first element in the chain. Usually, the first element is a Trust Anchor.
Compromise	A violation (or suspected violation) of a security policy, in which an unauthorized disclosure of, or loss of control over, sensitive information may have occurred. With respect to private keys, a compromise is a loss, theft, disclosure, modification, unauthorized use, or other compromise of the security of such private key.
Compliance Audit	A periodic review that an entity undergoes to determine its conformance with standards that apply to it.
Delegation Signer (DS)	One of the RRs indicating that the delegated zone is digitally signed. It also assures that the parent zone recognizes the indicated key for the delegated zone. Refer to [RFC4035] for the formal definition.
Domain Key	The domain key holds the key-cloning vector (the domain identifier) that allows key cloning between HSMs and partitions. Cloning is a secure method of copying cryptographic objects between HSMs and partitions, required for backup and restore. Reconstruction of the domain key requires five out of seven Recovery Key Share Holders or Crypto Officers.
Hardware Security Module (HSM)	A type of secure cryptoprocessor aimed at managing cryptographic keys and cryptographic operations while providing physical protection of the private keying material through mechanisms to detect and protect against tampering.
Key Generation Ceremony	A procedure whereby a key pair is generated, its private key is transferred into a cryptographic module, its private key is backed up, and/or key sets are signed.
Key Management Facilities (KMF)	High security location where cryptographic materials are stored, and cryptographic operations are performed.
Key Signing Key (KSK)	A key that signs the key set.
Parent Zone	The zone that is one level higher in the DNS hierarchy.
Public Key Infrastructure	The architecture, organization, techniques, practices, and procedures that collectively support the implementation and operation of a public key cryptographic system.
Repository	DNSSEC-related information made accessible online.
Resource Record Signature (RRSIG)	Signature data in a zone. Refer to [RFC4035] for the formal definition.
RSA	A public key cryptographic system invented by Ron Rivest, Adi Shamir, and Leonard Adleman.
Root Zone KSK Operator Policy Management Authority (PMA)	The office within the RZ KSK Operator responsible for promulgating the DPS.
Root Zone KSK Operations Security (RKOS)	A security support and coordination role within the RZ KSK Operator, with the required security experience and skills to i.e. provide security-related advice to the PMA, follow up on incident reporting, provide assistance to the external auditors, conduct internal audits, initiate security-awareness activities, provide security training and maintain the Information Security Management System.
Service Organization Control (SOC) Assurance	An assurance service developed by AICPA. SOC is designed primarily to build trust and confidence among businesses depending on systems, addressing areas such as security, availability, confidentiality, and processing integrity.
Storage Master Key (SMK)	A key of an HSM required to encrypt application key backups. The SMK is the key used to encrypt the private key(s), and is backed up using a five out of seven threshold scheme with credentials distributed to trusted individuals (Recovery Key Share Holders).
Trust Anchor	An authoritative entity represented via a public key. A validating security-aware resolver uses this public key as a starting point for building the authentication chain to a signed DNS response. Refer to [RFC4033] for the formal definition of a Trust Anchor in the context of DNSSEC.
Trusted Role	A role within the DNSSEC operations that must be held by a Trusted Person.
Trusted Person	Personnel assigned to a Trusted Role who have successfully completed a comprehensive background investigation as defined in section 4.3.2, which indicates their ability to maintain the level of trust necessary for critical DNSSEC operations.
Trusted Status	Trusted Status is achieved by a person who has successfully completed the screening requirements for Trusted Roles set out in this DPS.
Trustworthy System	Computer system in which hardware, software, and operational procedures provide a reasonable (1) security against intrusion, misuse, unauthorized access, (2) degree of availability, and (3) adherence to accepted security practices.
Verisign	Means, with respect to each pertinent portion of this, Verisign, Inc. and/or any wholly owned Verisign subsidiary responsible for the specific operations at issue.
Zone	A boundary of responsibility for each domain.
Zone Signing Key (ZSK)	A key that signs the Root Zone.