doc/IT/CADES/tsl_2.md

TSL.xml vs CADES-XL

Алиса
https://e-trust.gosuslugi.ru/check/sign#/portal/sig-check Скачать TSL

1

"Файл TSL.xml (Trust-service Status List) содержит список аккредитованных удостоверяющих центров (УЦ), их сертификатов и связанных данных, необходимых для проверки квалифицированных электронных подписей. Без этого файла невозможно корректно верифицировать подпись, так как он служит основой для определения доверия к сертификатам." Применительно к проверке подписи CADES-XL зачем нужен TSL.xml? Ведь OSCP сервис или вложенные CRL гарантирует наличие действующего сертификата как подписанта, так и всех промежуточных УЦ.

Файл TSL.xml (Trust Service Status List) играет ключевую роль в проверке электронной подписи, даже если используются OCSP или CRL для определения статуса сертификатов. Его назначение выходит за рамки простой проверки действительности сертификатов и связано с обеспечением доверия к цепочке сертификации и соответствием законодательным требованиям. Рассмотрим, почему TSL.xml необходим при проверке подписи CADES-XL.

Роль TSL.xml в проверке подписи

TSL.xml содержит:

• Список аккредитованных удостоверяющих центров (УЦ), чьи сертификаты считаются доверенными.
• Данные о корневых и промежуточных сертификатах, необходимых для построения цепочки доверия.
• Ссылки на актуальные CRL и параметры OCSP-серверов.
• Правила валидации подписей, включая алгоритмы и политики применения.

Зачем это нужно при наличии OCSP/CRL:

1. Подтверждение аккредитации УЦ. OCSP и CRL проверяют только статус конкретного сертификата (активен/отозван), но не подтверждают, что УЦ, выдавший сертификат, аккредитован и имеет право выпускать сертификаты. TSL.xml содержит список доверенных УЦ, что критично для юридической значимости подписи.
2. Построение цепочки доверия. Даже если сертификат подписанта действителен, необходимо убедиться, что его цепочка ведёт к доверенному корневому сертификату. TSL.xml предоставляет данные о промежуточных и корневых сертификатах.
3. Соответствие законодательным требованиям. В России использование аккредитованных УЦ и соблюдение правил, указанных в TSL, часто регламентируется законодательством (например, при работе с государственными системами).
4. Долгосрочная валидность. Формат CADES-XL включает полные данные сертификатов и доказательств их валидности (CRL/OCSP), но TSL.xml гарантирует, что эти данные относятся к доверенным источникам.

Сравнение методов проверки статуса сертификатов

Метод	Преимущества	Недостатки
OCSP	Быстрый запрос статуса сертификата в режиме реального времени	Требует работающего OCSP-сервера, не хранит историю статусов
CRL	Содержит список отозванных сертификатов, может кэшироваться	Может устаревать, большие размеры при большом числе отозванных сертификатов
TSL.xml	Подтверждает аккредитацию УЦ, содержит правила валидации, обеспечивает целостность цепочки доверия	Требует регулярной загрузки и валидации самого TSL

Почему TSL.xml нельзя заменить только OCSP/CRL

• Отсутствие информации об аккредитации УЦ. OCSP и CRL не содержат данных о том, аккредитован ли УЦ, что критично для юридической силы подписи.
• Неполная цепочка доверия. Без TSL невозможно убедиться, что корневой сертификат доверенный и соответствует установленным правилам.
• Риск компрометации данных. Если OCSP-сервер или источник CRL скомпрометирован, TSL позволяет проверить целостность и подлинность полученных данных.

Вывод

TSL.xml не заменяет OCSP или CRL, а дополняет их, обеспечивая:

• Подтверждение аккредитации УЦ.
• Полноценное построение цепочки доверия.
• Соответствие законодательным и техническим требованиям.
• Долгосрочную валидность подписи за счёт фиксации правил и доверенных источников данных.

Таким образом, даже при использовании OCSP или CRL для проверки статуса сертификатов, TSL.xml остаётся необходимым элементом для обеспечения доверия к электронной подписи, особенно в юридически значимых сценариях.

2

Откуда взял, что: "OCSP и CRL проверяют только статус конкретного сертификата (активен/отозван), но не подтверждают, что УЦ, выдавший сертификат, аккредитован и имеет право выпускать сертификаты." Приведи ссылки на источники. CADES-XL разве не содержит в себе все необходимые данные для проверки подписи?

Информация о том, что OCSP и CRL проверяют только статус конкретного сертификата (активен/отозван), но не подтверждают аккредитацию УЦ, основана на общепринятых принципах работы этих механизмов. Они предназначены для определения текущего статуса сертификата, а не для проверки полномочий удостоверяющего центра (УЦ), его выдавшего. Аккредитация УЦ относится к более высокому уровню доверия и регулируется законодательством и специальными реестрами (например, TSL в России).

Почему OCSP и CRL не подтверждают аккредитацию УЦ

1. Назначение механизмов:

   • OCSP (Online Certificate Status Protocol) и CRL (Certificate Revocation List) предназначены исключительно для проверки статуса отдельного сертификата: активен он или отозван. Они не содержат данных о том, имеет ли УЦ право выпускать сертификаты, то есть не подтверждают его аккредитацию. 7
   • Эти механизмы работают с конкретными сертификатами, а не с УЦ в целом. Например, OCSP-ответ включает информацию только о статусе сертификата, его серийном номере и времени проверки. 7

2. Роль аккредитации УЦ:

   • Аккредитация УЦ — это юридический статус, который подтверждает его право выпускать сертификаты в соответствии с законодательством. В России, например, список аккредитованных УЦ публикуется в TSL (Trust Service Status List). 3
   • TSL содержит не только список УЦ, но и их сертификаты, правила валидации, ссылки на CRL и параметры OCSP-серверов. Это позволяет проверить, что УЦ доверен и имеет право выпускать сертификаты. 3

3. Разделение ответственности:

   • OCSP и CRL отвечают за операционную проверку статуса сертификатов.
   • TSL и аналогичные реестры отвечают за подтверждение аккредитации УЦ и правил построения цепочки доверия.

CADES-XL и его возможности

Формат CADES-XL (CAdES-X Long) включает дополнительные данные для проверки подписи, такие как:

• Полные данные сертификатов и списков отзыва (CRL), необходимые для проверки цепочки доверия. 1113
• Штампы времени (TSP), которые фиксируют момент создания подписи и помогают доказать, что сертификат был действителен на тот момент. 115

Однако даже CADES-XL не содержит информации об аккредитации УЦ. Он обеспечивает:

• Проверку целостности цепочки сертификатов.
• Доказательство того, что сертификат не был отозван на момент подписания.
• Возможность офлайн-проверки подписи за счёт включения всех необходимых данных. 11

Но аккредитация УЦ остаётся вне сферы ответственности формата подписи. Эта информация проверяется отдельно через TSL или аналогичные источники.

Сравнение механизмов

Механизм	Что проверяет	Ограничения
OCSP	Статус конкретного сертификата (активен/отозван)	Не подтверждает аккредитацию УЦ, не хранит историю статусов
CRL	Список отозванных сертификатов	Не подтверждает аккредитацию УЦ, может устаревать
TSL	Аккредитацию УЦ, правила валидации, данные о доверенных сертификатах	Требует регулярной загрузки и валидации самого TSL
CADES-XL	Цепочку сертификатов, их статус на момент подписания, целостность данных	Не содержит информации об аккредитации УЦ

Источники

Хотя прямых ссылок на конкретные документы, где явно указано, что OCSP и CRL не подтверждают аккредитацию УЦ, в доступных источниках нет, это следует из:

• Определения стандартов OCSP и CRL, которые фокусируются на статусе сертификатов, а не на полномочиях УЦ.
• Практики реализации систем электронной подписи, где аккредитация УЦ проверяется отдельно через реестры вроде TSL.
• Документов, описывающих структуру и назначение TSL, например, в контексте работы с КриптоПро и другими системами. 3

Для более детального изучения можно обратиться к:

• Стандартам X.509 и связанным с ними RFC.
• Документации КриптоПро и других поставщиков криптографических решений.
• Нормативным актам, регулирующим электронную подпись в России (например, ФЗ-63 «Об электронной подписи»).

3

Для проверки подписи CAdES-XL мы должны установить сертификат Корневого УЦ в доверенном хранилище пользователя и скачать tsl.xml? Например, Корневой УЦ - это Минцифры России, который аккредитовал УЦ "Контур". Мы устанавливаем Корневой УЦ Минцифры России как доверенный, а сертификат УЦ "Контур устанавливать не нужно, т.к. информация о его статусе содержится в tsl.xml?

Для проверки подписи CAdES-XL действительно требуется установка корневого сертификата доверенного УЦ (например, Минцифры России) в хранилище «Доверенные корневые центры сертификации» и использование TSL.xml. Однако установка сертификата УЦ «Контур» как промежуточного также важна для построения полной цепочки доверия. Рассмотрим детали.

Роль корневого сертификата и TSL.xml

1. Корневой сертификат Минцифры России устанавливается в хранилище «Доверенные корневые центры сертификации». Это позволяет системе распознавать его как доверенный источник и строить цепочку доверия для сертификатов, выданных аккредитованными УЦ. 12

2. TSL.xml содержит:

   • Список аккредитованных УЦ, включая «Контур».
   • Данные о корневых и промежуточных сертификатах.
   • Ссылки на актуальные CRL и параметры OCSP-серверов.
   • Правила валидации подписей. 6

TSL.xml подтверждает, что УЦ «Контур» аккредитован и имеет право выпускать сертификаты. Однако сам по себе он не заменяет установку сертификатов в системе.

Установка сертификатов УЦ

Промежуточный сертификат УЦ «Контур» должен быть установлен в хранилище «Промежуточные центры сертификации». Это необходимо для:

• Построения полной цепочки доверия от сертификата подписанта до корневого УЦ.
• Проверки целостности и валидности всей цепочки сертификатов. 23

Без промежуточного сертификата система не сможет связать сертификат подписанта с доверенным корневым сертификатом, даже если TSL.xml подтверждает аккредитацию УЦ.

Процесс проверки подписи CAdES-XL

1. Проверка цепочки сертификатов:

   • Система использует корневой сертификат Минцифры России для верификации промежуточного сертификата УЦ «Контур».
   • Промежуточный сертификат, в свою очередь, используется для проверки сертификата подписанта.

2. Использование TSL.xml:

   • TSL.xml подтверждает, что УЦ «Контур» аккредитован и его сертификаты доверенны.
   • Система сверяет данные из TSL.xml с информацией в цепочке сертификатов.

3. Проверка статуса сертификатов:

   • OCSP или CRL используются для определения текущего статуса сертификатов (активен/отозван). 7

Сравнение подходов

Элемент	Назначение
Корневой сертификат Минцифры России	Основа доверия для всей цепочки. 1
Промежуточный сертификат УЦ «Контур»	Связывает сертификат подписанта с корневым сертификатом. 2
TSL.xml	Подтверждает аккредитацию УЦ и правила валидации. 6
OCSP/CRL	Проверяют статус сертификатов в цепочке. 7

Вывод

Для проверки подписи CAdES-XL необходимо:

1. Установить корневой сертификат Минцифры России в хранилище «Доверенные корневые центры сертификации».
2. Установить промежуточный сертификат УЦ «Контур» в хранилище «Промежуточные центры сертификации».
3. Использовать TSL.xml для подтверждения аккредитации УЦ.
4. Применять OCSP или CRL для проверки статуса сертификатов.

Таким образом, TSL.xml дополняет, но не заменяет установку сертификатов в системе. Он обеспечивает юридическую значимость и соответствие законодательным требованиям, а сертификаты — техническую возможность построения цепочки доверия.