Applicant Information

Does or will this RSP have a publicly verifiable, third-party certification (e.g. ISO 27001) held directly by the organization and relevant to the registry services under application?

Yes

Does or will this RSP have processes and controls to manage physical access to infrastructure and systems, including building access controls, security cameras and/or other sensors, physical environmental monitoring and safety equipment, and alarm systems related to the physical infrastructure?

Yes

Does or will this RSP have processes and controls to manage non-physical access to infrastructure, including network access from both internal systems and external Internet systems, intrusion detection systems, security information and event management systems, network firewalls, network segmentation and isolation, user identification and authentication, and authorization schemes?

Yes

Does or will this RSP have processes and controls pertaining to the selection of vendors and equipment suppliers, management and maintenance of assets while in use, procurement of assets, and safe disposal of assets?

Yes

Does or will this RSP routinely renew and keep safe all cryptographic material necessary for the operation of the RSP?

Yes

Does or will this RSP secure (e.g. encryption, tamper detection, etc…) at-rest data relevant to the operation of the RSP, including but not limited to DNSSEC if applicable?

Yes

Does or will this RSP secure (e.g. encryption, tamper detection, etc…) in-transit data relevant to the operation of the RSP, including but not limited to DNSSEC if applicable?

Yes

If applicable, does or will this RSP have security controls for data in virtualized environments, including controls relevant to both on-premises or private virtualization environments as well as public clouds, network isolation, memory isolation, process isolation, and hypervisor access controls?

Yes

Does or will this RSP have a senior executive primarily in charge of and responsible for security?

Yes

Does or will this RSP conduct background checks, both initial and on-going, of personnel and vendors relevant to the registry services under application?

Yes

Does or will this RSP comply with BCP 38?

Yes

Does or will this RSP implement routing security of some nature, such as automated route filters, RPKI route origin validation, or other operational practices defined by the Internet Society and Global Cyber Alliance’s Mutually Agreed Norms for Routing Security (MANRS)?

Yes

Does or will this RSP have documented, regular, and active practices for the maintenance of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the maintenance, upgrading, and patching of software relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the lifecycle of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the secure development of software?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the maintenance of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the maintenance, upgrading, and patching of software relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the lifecycle of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the development of software?

Yes

Does or will this RSP use Infrastructure-as-Code (IaC) to manage all systems relevant to operation of the registry services under application?

Yes

Does or will this RSP use automated orchestration to manage all systems relevant to the operation of the registry services under application?

Yes

Does or will this RSP have at least two Tier III (as defined here: https://uptimeinstitute.com/tiers) or equivalent data centers having no inter-dependencies?

Yes

Does or will this RSP use hardware security modules (HSMs) certified to at least FIPS 140-3 Level 3?

Yes

Does or will this RSP implement RFC 4033 (“DNS Security Introduction and Requirements”)?

Yes

Does or will this RSP implement RFC 4034 (“Resource Records for the DNS Security Extensions”)?

Yes

Does or will this RSP implement RFC 4035 (“Protocol Modifications for the DNS Security Extensions”)?

Yes

Does or will this RSP implement RFC 4509 (“Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)”)?

Yes

Does or will this RSP implement RFC 6840 (“Clarifications and Implementation Notes for DNS Security (DNSSEC)”)?

Yes

Does or will this RSP implement RFC 6781 (“DNSSEC Operational Practices, Version 2”)?

Yes

Does or will this RSP implement RFC 7583 (“DNSSEC Key Rollover Timing Considerations”)?

Yes

Does or will this RSP implement RFC 9276 (“Guidance for NSEC3 Parameter Settings”)?

Yes

Does or will this RSP implement any of RFC 6605 (“Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC”), RFC 5702 (“Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC“), and/or RFC 8080 (“Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC”)?

Yes

Describe the processes and procedures to be used to practice and ensure a successful KSK rollover for both emergency and non-emergency situations, including coordination with the MAIN RSP and IANA.

Online KSK Rollovers For Online Key Signing Keys (KSKs), Identity Digital follows the “double DS” rollover method, as described in RFC 5011. The procedure is as follows: - A new KSK is generated. - The new KSK is added to the apex DNSKEY RRSet and signed using the current KSK. - A hold-down period of 2x the DNSKEY T TL is performed. - The new DS record is added to the parent zone (via IANA RZM request). - A hold-down period of 2x the DS TTL is performed. - The DNSKEY RRSet is signed using the new KSK. - A hold-down period of 2x the DNSKEY TTL is performed. - The old DS record is removed from the parent zone via IANA RZM request. - The old DNSKEY record is removed from the apex DNSKEY RRSet. Offline KSK Rollovers In the case where the Registry Operator or another MAIN-RSP controls the KSK, the KSK rollover methodology becomes their responsibility. Identity Digital, as DNSSEC-RSP, will generate the necessary Key Signing Request / Signed Key Response operations to facilitate the KSK rollover: - KSK owner informs Identity Digital of desired KSK rollover. - KSK owner generates a new KSK. - Identity Digital generates a KSR that will span the timeframe of the KSK rollover and validates the KSR. - Identity Digital encrypts the KSR and sends it to the KSK owner. - KSK owner generates the SKR based on the KSR. - KSK owner encrypts the SKR and sends it to Identity Digital. - Identity Digital validates the SKR and loads it into the DNSSEC Signing Subsystem External DNSSEC-RSP KSK Rollovers. Identity Digital performs DNSSEC operations after the MAIN-RSP has prepared an unsigned zone. For a DNSSEC-RSP outside of the organization, the unsigned zone will be transferred out to the DNSSEC-RSP, as shown in the Transfer Data Source in ID_DNSSEC.4.14_Data-Flow_1of1. It is the responsibility of the DNSSEC-RSP to then correctly perform the KSK rollover according to their preferred methodology and validate the zone. The signed zone (along with any changes to the DNSKEY RRSet as part of a KSK rollover) are then transferred from the DNSSEC-RSP and sent to all DNS-RSPs for publication and resolution. Emergency KSK Rollovers There are two distinct emergency scenarios that could involve a KSK rollover: The compromise of a key, or the compromise of one or more Hardware Security Modules (HSMs). The highest priority is always to keep the zone resolving and avoid validators who consider the zone Invalid. To this effect, the most prudent procedure involves removing the current DNSSEC signature, and then quickly performing a KSK installation. This would be executed as follows: - Identity Digital informs the IANA, as the parent zone operator of an emergency KSK rollover, and requests that the DS record for the compromised key be removed immediately. - A new KSK is generated. - The new KSK replaces the old KSK in the apex DNSKEY RRSet and is signed using the current KSK, with a TTL of 120. - A hold-down period of 2x the DNSKEY TTL is performed. - The new DS record is added to the parent zone (via IANA RZM request). - A hold-down period of 2x the DS TTL is performed. - The DNSKEY RRSet is signed using the new KSK. - A hold-down period of 2x the DNSKEY TTL is performed. Using this method, new queries for the DS record will immediately show the change in the zone, which decreases the possibility of the zone not resolving if caches do not purge data quickly enough. For the first scenario, Identity Digital will follow the procedure above. In the second scenario, where the potential for all keys on the HSM have been compromised, the above procedure would be repeated across all affected zones.

Does or will this RSP compartmentalize (e.g. virtualization) the DNSSEC service in such a manner that each compartment (e.g. containers, virtual machines, physical machines) is dedicated to DNSSEC (excluding system services such as monitoring, remote access NTP)?

Yes

Does or will this RSP regularly exercise DNSSEC service continuity actions?

Yes

Does or will this RSP be capable of transferring all applicable operations to another RSP as defined by the Material Subcontracting Arrangement Technical Questions?

Yes

Does or will this RSP participate in coordinated Emergency Back-end Registry Operator (EBERO) transitions, including but not limited to maintaining the DNSSEC chain of trust, of hosted gTLDs when the business relationship of this RSP and the Registry Operator is not in good standing?

Yes

Does or will this RSP monitor for faults inside its own network?

Yes

Does or will this RSP monitor for faults from a point outside any of its own networks?

Yes

Does or will this RSP have documented processes for aggregation and triage of faults?

Yes

Does or will this RSP have documented processes to mitigate faults once detected?

Yes

Does or will this RSP have processes to minimize faults during maintenance of systems, including both automated processes and manual change control processes?

Yes

Does or will this RSP have personnel capable of reacting to and mitigating faults 24 hours per day of every day of every year of service?

Yes

Provide documentation regarding any RSP functions currently being served for any gTLD, the domain names of the gTLDs, and all service disruptions for each gTLD in the past six months, where a service disruption is defined by Specification 10 of the ICANN Registry Agreement (2024).

Per the clarifying information ICANN has provided regarding this question via the FAQs posted on the RSP Pre-Evaluation site, Identity Digital confirms that in the six months preceding the submission of this application, we have not experienced any service disruptions that went beyond the Emergency Threshold defined in Section 6 of Specification 10 of the ICANN Registry Agreement for any supported TLDs.