Название документа: Руководство по интеграции и использованию ЭЦП для верификации данных доменных имен в зонах .KZ, .ҚАЗ
Статус: draft (черновик)
Версия: 1.0
Дата публикации: 01.06.2026г
Владелец: Казахстанский центр сетевой информации (KazNIC)


Настоящий документ содержит описание дополнительных технических деталей и описание расширений протокола EPP, внедряемых регистратурой KazNIC,
описанных в следующем документе "Регламент использования ЭЦП для верификации данных доменных имен в зонах .KZ, .ҚАЗ"

1. Верификация регистрационных данных регистранта
 
  Верификация регистрационных данных проводится по инициативе регистранта доменного имени и подтверждает, что данные регистранта являются 
  достоверными. По факту успешного прохождения верификации в системе Whois отображается соответствующий статус. 
	
  Для процесса верификации вводится использование электронной цифровой подписи. К использованию допускаются только регистрационные свидетельства 
  (сертификаты), выданные Национальным удостоверяющим центром Республики Казахстан (НУЦ РК).

2. Расширение EPP протокола: "kz-law-ext" (версия 2.0)

  Для передачи данных электронной цифровой подписи (ЭЦП) используется специализированное расширение протокола EPP — kz-law-ext версии 2.0. 
  Данное расширение дополняет стандартный объект Domain блоком <kz-law-ext:digitalSignatures>, который представляет собой масштабируемую 
  коллекцию (список) элементов <kz-law-ext:digitalSignature>.
  
  Состав данных: 

    <kz-law-ext:digitalSignature> — корневой элемент одиночной подписи, содержащий криптографический пакет и сопутствующие бизнес-метаданные.	

    Атрибут actionType (обязательный): Определяет бизнес-контекст и целевое назначение подписи (допустимые значения: REGISTRANT-IDENTITY-CONFIRMATION).

    Логика уникальности и вытеснения: Атрибут actionType выступает в роли уникального составного бизнес-ключа в рамках домена. При поступлении новой
    подписи с уже существующим в базе данных значением actionType="REGISTRANT-IDENTITY-CONFIRMATION", система KazNIC производит автоматическую
    перезапись (вытеснение) устаревших операционных данных актуальными. При этом исторические данные сохраняются в архиве аудита.

    <kz-law-ext:signatureValue> - содержит бинарное значение открепленной цифровой подписи (CMS/CAdES BLOB) в кодировке Base64. 

    Атрибут docSpecAlg (обязательный): Определяет версию технической спецификации и жесткий шаблон формирования текстового документа, который подавался на
    подпись пользователю (например, DOC-SPEC-REGISTRANT-IDENTITY-CONFIRMATION-V1).

    Атрибут signerRole (обязательный): Описывает юридическую роль и полномочия лица, сформировавшего подпись (допустимые значения: CURRENT_REGISTRANT,
    NEW_REGISTRANT, REGISTRAR).
  
  Обработка команды <info>:

    Для оптимизации сетевого трафика и обеспечения производительности реестра, в ответ на стандартную команду <info> сервер KazNIC возвращает симметричную
    структуру <kz-law-ext:digitalSignatures>, где вместо тяжелого элемента <signatureValue> отдается легковесный тег <kz-law-ext:signatureHash>. 
    Внутри него передается криптографическая квитанция в виде строки SHA-256 хеша (длиной строго 64 символа Hex) от оригинальной подписи, с сохранением всех 
    атрибутов идентификации (actionType, docSpecAlg, signerRole).

  Документация: Техническая спецификация расширения приведена в файле [kz-law-ext-2.0.txt].

3. Технические требования к цифровой подписи
  
  Формирование данных: Для подготовки подписываемого документа используется алгоритм DOC-SPEC-REGISTRANT-IDENTITY-CONFIRMATION-V1. Описание алгоритма 
  содержится в файле [Спецификация алгоритма DOC-SPEC-REGISTRANT-IDENTITY-CONFIRMATION-V1.txt].
  
  Тип подписи: CMS Detached (открепленная)  
  
  Стандарт: CAdES-T. Обязательно наличие метки доверенного времени (TSP timestamp) от НУЦ РК, подтверждающей момент подписания.
  
  Кодировка: Финальный бинарный объект цифровой подписи должен быть сконвертирован в формат Base64 для передачи в поле <kz-law-ext:signatureValue>.
  

4. Описание процесса верификации цифровой подписи

  Верификация: Регистратура осуществляет автоматическую проверку корректности цифровой подписи, валидности сертификата и соответствия идентификатора ИИН/БИН.
  
  В процессе верификации используются дополнительные статусы: pendingRegistrantIdentityVerification, registrantIdentityVerificationFailed, registrantIdentityVerified.

  Статус pendingRegistrantIdentityVerification устанавливается Регистратурой в момент начала проверки и снимается по её завершении.

  В случае удачной верификации устанавливается статус registrantIdentityVerified.

  В случае неудачной верификации устанавливается статус registrantIdentityVerificationFailed с указанием причины несоответствия.


5. Тестирование и отладка

Все функциональные изменения, правила валидации и расширения протокола развернуты на тестовом EPP-сервере (OT&E).

  Доступность: Регистраторы могут приступать к доработке и тестированию собственного программного обеспечения на тестовом сервере.

  Рекомендация: До перехода на основной EPP сервер рекомендуется выполнить полный цикл тестов: от создания объекта Contact с расширением residenceDetails 
  до успешной регистрации домена в зоне .kz с прохождением лицензионного контроля и верификации ЭЦП.

  Тестовая среда: Для корректной верификации подписей на сервере OT&E используются тестовые сертификаты из SDK НУЦ РК. Для формирования меток 
  доверенного времени (TSP) необходимо использовать тестовое окружение НУЦ РК.