Document Title: Guide for Integration and Use of Electronic Digital Signatures for Domain Data Verification in the .KZ and .ҚАЗ Zones Status: Draft Version: 1.0 Publication Date: 01.06.2026 Owner: Kazakhstan Network Information Center (KazNIC) This document provides a description of additional technical details and extensions of the EPP protocol implemented by the KazNIC registry, as outlined in the following document: "Regulations on the Use of Electronic Digital Signatures for Verification of Domain Data in the .KZ and .ҚАЗ Zones." 1. Verification of Registrant Registration Data Verification of registration data is initiated by the domain registrant and confirms that the registrant's information is accurate. Upon successful verification, the corresponding status is displayed in the Whois system. For the verification process, the use of electronic digital signatures is introduced. Only registration certificates issued by the National Certification Authority of the Republic of Kazakhstan (NCA RK) are permitted. 2. EPP Protocol Extension: "kz-law-ext" (Version 2.0) A specialized EPP protocol extension - kz-law-ext version 2.0 - is used to transmit electronic digital signature (EDS) data. This extension augments the standard Domain object with the block, which is a scalable collection (list) of elements. Data Structure: - root element of a single signature, containing a cryptographic package and associated business metadata. Attribute actionType (required): Defines the business context and intended purpose of the signature (allowed value: REGISTRANT-IDENTITY-CONFIRMATION). Uniqueness and Overwriting Logic: The actionType attribute serves as a unique composite business key within a domain. When a new signature with an existing actionType="REGISTRANT-IDENTITY-CONFIRMATION" is received, the KazNIC system automatically overwrites outdated operational data with the new data. Historical data is preserved in the audit archive. — contains the binary value of the detached digital signature (CMS/CAdES BLOB) encoded in Base64. Attribute docSpecAlg (required): Defines the technical specification version and strict template of the text document presented to the user for signing (e.g., DOC-SPEC-REGISTRANT-IDENTITY-CONFIRMATION-V1). Attribute signerRole (required): Describes the legal role and authority of the individual generating the signature (allowed values: CURRENT_REGISTRANT, NEW_REGISTRANT, REGISTRAR). Processing the Command: To optimize network traffic and ensure registry performance, in response to the standard command, the KazNIC server returns a symmetric structure, where the heavy element is replaced with a lightweight tag. This contains a cryptographic receipt in the form of a SHA-256 hash string (exactly 64 hex characters) of the original signature, retaining all identification attributes (actionType, docSpecAlg, signerRole). Documentation: Technical specifications of the extension are provided in the file [kz-law-ext-2.0.txt]. 3. Technical Requirements for Digital Signatures Data Formation: The document to be signed is prepared according to the algorithm DOC-SPEC-REGISTRANT-IDENTITY-CONFIRMATION-V1. Description available in [Algorithm Specification DOC-SPEC-REGISTRANT-IDENTITY-CONFIRMATION-V1.txt]. Signature Type: CMS Detached Standard: CAdES-T. A trusted timestamp (TSP) from NCA RK confirming the signing time is mandatory. Encoding: The final binary digital signature object must be converted to Base64 format for inclusion in . 4. Digital Signature Verification Process Verification: The registry performs automatic validation of the digital signature, certificate validity, and matching of the IIN/BIN identifier. Statuses Used: pendingRegistrantIdentityVerification, registrantIdentityVerificationFailed, registrantIdentityVerified. The status pendingRegistrantIdentityVerification is set at the start of verification and removed upon completion. Successful verification results in the status registrantIdentityVerified. Failed verification results in the status registrantIdentityVerificationFailed with the reason for non-compliance specified. 5. Testing and Debugging All functional changes, validation rules, and protocol extensions are deployed on the test EPP server (OT&E). Availability: Registrars can begin adapting and testing their software on the test server. Recommendation: Before moving to the production EPP server, a full test cycle should be performed: from creating a Contact object with the residenceDetails extension to successful domain registration in the .kz zone, including licensing control and digital signature verification. Test Environment: To verify signatures on the OT&E server, test certificates from the NCA RK SDK are used. Trusted timestamps (TSP) must be generated using the NCA RK test environment.