## 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```](https://habr.com/ru/companies/neobit/articles/325490/)
   - Эти механизмы работают с конкретными сертификатами, а не с УЦ в целом. Например, OCSP-ответ включает информацию только о статусе сертификата, его серийном номере и времени проверки. [```7```](https://habr.com/ru/companies/neobit/articles/325490/)

2. **Роль аккредитации УЦ**:
   - Аккредитация УЦ — это юридический статус, который подтверждает его право выпускать сертификаты в соответствии с законодательством. В России, например, список аккредитованных УЦ публикуется в TSL (Trust Service Status List). [```3```](https://www.securitycode.ru/upload/iblock/d1c/yl19m8bhrtqtxz1fyutqwei06fm2dhjx/Jinn-Server%201.3%20-%20%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE%20%D0%B0%D0%B4%D0%BC%D0%B8%D0%BD%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%BE%D1%80%D0%B0.pdf)
   - TSL содержит не только список УЦ, но и их сертификаты, правила валидации, ссылки на CRL и параметры OCSP-серверов. Это позволяет проверить, что УЦ доверен и имеет право выпускать сертификаты. [```3```](https://www.securitycode.ru/upload/iblock/d1c/yl19m8bhrtqtxz1fyutqwei06fm2dhjx/Jinn-Server%201.3%20-%20%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE%20%D0%B0%D0%B4%D0%BC%D0%B8%D0%BD%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%BE%D1%80%D0%B0.pdf)

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

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

Формат **CADES-XL** (CAdES-X Long) включает дополнительные данные для проверки подписи, такие как:
- Полные данные сертификатов и списков отзыва (CRL), необходимые для проверки цепочки доверия. [```11```](https://demo-rx.directum24.ru/webclient/WebHelp/ru-RU/admin_nastroika_usovershenstvovannoi_ep.htm)[```13```](https://ru.wikipedia.org/wiki/CAdES)
- Штампы времени (TSP), которые фиксируют момент создания подписи и помогают доказать, что сертификат был действителен на тот момент. [```11```](https://demo-rx.directum24.ru/webclient/WebHelp/ru-RU/admin_nastroika_usovershenstvovannoi_ep.htm)[```5```](https://buh.ru/articles/kak-vybrat-format-elektronnoy-podpisi-pri-podpisanii-dokumentov.html)

Однако даже CADES-XL не содержит информации об аккредитации УЦ. Он обеспечивает:
- Проверку целостности цепочки сертификатов.
- Доказательство того, что сертификат не был отозван на момент подписания.
- Возможность офлайн-проверки подписи за счёт включения всех необходимых данных. [```11```](https://demo-rx.directum24.ru/webclient/WebHelp/ru-RU/admin_nastroika_usovershenstvovannoi_ep.htm)

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

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

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

## Источники

Хотя прямых ссылок на конкретные документы, где явно указано, что OCSP и CRL не подтверждают аккредитацию УЦ, в доступных источниках нет, это следует из:
- Определения стандартов OCSP и CRL, которые фокусируются на статусе сертификатов, а не на полномочиях УЦ.
- Практики реализации систем электронной подписи, где аккредитация УЦ проверяется отдельно через реестры вроде TSL.
- Документов, описывающих структуру и назначение TSL, например, в контексте работы с КриптоПро и другими системами. [```3```](https://www.securitycode.ru/upload/iblock/d1c/yl19m8bhrtqtxz1fyutqwei06fm2dhjx/Jinn-Server%201.3%20-%20%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE%20%D0%B0%D0%B4%D0%BC%D0%B8%D0%BD%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%BE%D1%80%D0%B0.pdf)

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

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

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

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

1. **Корневой сертификат Минцифры России** устанавливается в хранилище «Доверенные корневые центры сертификации». Это позволяет системе распознавать его как доверенный источник и строить цепочку доверия для сертификатов, выданных аккредитованными УЦ. [```1```](https://learn.microsoft.com/ru-ru/windows-hardware/drivers/install/trusted-root-certification-authorities-certificate-store)[```2```](https://taxcom.ru/support/ustanovka-kornevogo/)

2. **TSL.xml** содержит:
   - Список аккредитованных УЦ, включая «Контур».
   - Данные о корневых и промежуточных сертификатах.
   - Ссылки на актуальные CRL и параметры OCSP-серверов.
   - Правила валидации подписей. [```6```](https://www.cryptopro.ru/sites/default/files/products/svs/2/2828/cryptopro_svs_admin_guide.pdf)

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

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

**Промежуточный сертификат УЦ «Контур»** должен быть установлен в хранилище «Промежуточные центры сертификации». Это необходимо для:
- Построения полной цепочки доверия от сертификата подписанта до корневого УЦ.
- Проверки целостности и валидности всей цепочки сертификатов. [```2```](https://taxcom.ru/support/ustanovka-kornevogo/)[```3```](https://saby.ru/help/ep/workplace/esia/inst_corn)

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

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

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

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

3. **Проверка статуса сертификатов**:
   - OCSP или CRL используются для определения текущего статуса сертификатов (активен/отозван). [```7```](https://forum.rutoken.ru/topic/3665/)

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

| Элемент | Назначение |
|---------|------------|
| Корневой сертификат Минцифры России | Основа доверия для всей цепочки. [```1```](https://learn.microsoft.com/ru-ru/windows-hardware/drivers/install/trusted-root-certification-authorities-certificate-store) |
| Промежуточный сертификат УЦ «Контур» | Связывает сертификат подписанта с корневым сертификатом. [```2```](https://taxcom.ru/support/ustanovka-kornevogo/) |
| TSL.xml | Подтверждает аккредитацию УЦ и правила валидации. [```6```](https://www.cryptopro.ru/sites/default/files/products/svs/2/2828/cryptopro_svs_admin_guide.pdf) |
| OCSP/CRL | Проверяют статус сертификатов в цепочке. [```7```](https://forum.rutoken.ru/topic/3665/) |

## Вывод

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

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