doc/IT/CADES/tsl_1.md

### TSL.xml
Trust-service Status List
## 1
Файл **TSL.xml** (Trust-service Status List) содержит список аккредитованных удостоверяющих центров (УЦ), их сертификатов и связанных данных, необходимых для проверки квалифицированных электронных подписей. Без этого файла невозможно корректно верифицировать подпись, так как он служит основой для определения доверия к сертификатам.

## Состав TSL.xml

В TSL.xml включены:
- **Данные об аккредитованных УЦ**: наименования, идентификаторы, контактные сведения.
- **Сертификаты УЦ**: открытые ключи и метаданные, позволяющие проверить их подлинность.
- **Списки отозванных сертификатов (CRL)**: информация о сертификатах, которые больше не действительны.
- **Правила и параметры проверки**: алгоритмы, сроки действия сертификатов, требования к форматам подписей.

Формат TSL.xml основан на стандартах ETSI TS 102 231 V3.1.2 и соответствует схеме, доступной по ссылке (например, http://e-trust.gosuslugi.ru/docs/TSLExt.1.0.xsd). [```11```](https://www.securitycode.ru/upload/iblock/214/nngr7qzd3nfara57t8me31ug0gr963w7/Jinn-server%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%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8F.pdf)

## Почему TSL.xml необходим для проверки подписи

1. **Определение доверенных УЦ**: TSL.xml содержит список УЦ, аккредитованных уполномоченным федеральным органом (УФО). Без этого списка невозможно установить, выдан ли сертификат подписи доверенным центром.
2. **Проверка цепочки доверия**: для верификации подписи требуется проверить всю цепочку сертификатов — от конечного сертификата до корневого. TSL.xml включает корневые и промежуточные сертификаты, необходимые для построения этой цепочки.
3. **Контроль актуальности сертификатов**: в TSL.xml содержатся списки отозванных сертификатов (CRL), что позволяет убедиться, что сертификат не был аннулирован.
4. **Соответствие стандартам**: TSL.xml обеспечивает соблюдение требований законодательства и стандартов в области электронной подписи, включая проверку алгоритмов и форматов.

Без TSL.xml система не сможет:
- Определить, является ли УЦ, выдавший сертификат, аккредитованным.
- Проверить целостность и подлинность цепочки сертификатов.
- Убедиться, что сертификат не отозван.

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

При проверке квалифицированной электронной подписи система выполняет следующие шаги:
1. **Загрузка TSL.xml**: файл загружается с портала УФО или из локального хранилища.
2. **Проверка сертификата УЦ**: система сверяет сертификат, выдавший подпись, с данными из TSL.xml.
3. **Проверка цепочки доверия**: верифицируются все сертификаты в цепочке, вплоть до корневого, который должен быть включён в TSL.
4. **Контроль CRL**: система проверяет, не включён ли сертификат в список отозванных.
5. **Проверка подписи**: после подтверждения доверия к сертификату выполняется верификация самой подписи (алгоритмы хэширования, цифровая подпись и т.д.).

## Утилиты для работы с TSL.xml

Для автоматизации работы с TSL.xml используются специальные утилиты, например:
- **DSS.TslTool** от КриптоПро: позволяет загружать TSL, устанавливать сертификаты УЦ и CRL, а также управлять списком доверенных издателей. [```1```](https://cryptopro.ru/forum2/default.aspx?g=posts&t=21233)[```8```](https://dss.cryptopro.ru/docs/adminguide_nix/cprotools/tsltool.html)
- Инструменты в ПАК «Jinn-Server»: поддерживают загрузку TSL, проверку его авторства и целостности, формирование списка доверенных УЦ. [```11```](https://www.securitycode.ru/upload/iblock/214/nngr7qzd3nfara57t8me31ug0gr963w7/Jinn-server%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%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8F.pdf)

## Вывод

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

## 2 Почему указал "Корневые сертификаты аккредитованных коммерческих УЦ." как корневые - ведь они не само подписные,

Корневые сертификаты аккредитованных коммерческих удостоверяющих центров (УЦ) называются так, потому что они являются верхними звеньями в цепочке доверия для сертификатов, выдаваемых этими УЦ. Хотя они не являются самоподписанными (их подписывает головной удостоверяющий центр — Минцифры России), они выполняют функцию корневых в контексте доверия к сертификатам конкретного УЦ.

## Почему они называются корневыми

Корневой сертификат в цепочке доверия — это сертификат, который не требует подписи вышестоящим центром, так как является исходным звеном доверия. В случае коммерческих УЦ их сертификаты подписываются головным удостоверяющим центром (ГУЦ) — Минцифры России. Однако для сертификатов, выдаваемых коммерческим УЦ, его сертификат становится «корневым» в том смысле, что он является верхним звеном в цепочке доверия для сертификатов, которые этот УЦ выдаёт конечным пользователям. То есть, когда проверяется подпись, выданная коммерческим УЦ, система сначала проверяет его сертификат, а затем поднимается по цепочке до сертификата Минцифры России.

## Кто подписывает сертификаты аккредитованных УЦ

Сертификаты аккредитованных коммерческих УЦ подписывает **головной удостоверяющий центр (ГУЦ) — Минцифры России**. После аккредитации УЦ получает от Минцифры России квалифицированный сертификат, который позволяет ему выдавать сертификаты конечным пользователям. Этот сертификат Минцифры России является корневым для всех сертификатов, выдаваемых данным УЦ.

## Цепочка доверия

Цепочка доверия при проверке электронной подписи выглядит следующим образом:
1. **Корневой сертификат Минцифры России** — верхний уровень доверия, выданный самим Минцифры России.
2. **Сертификат аккредитованного УЦ** — промежуточный уровень, подписанный корневым сертификатом Минцифры России.
3. **Сертификат конечного пользователя** — выданный аккредитованным УЦ, подписанный его сертификатом.

Для корректной проверки подписи необходимо, чтобы все звенья цепочки были действительны и доверялись системой.

## Почему это важно

Если бы коммерческие УЦ подписывали свои сертификаты самостоятельно (были самоподписанными), это создало бы риск подделки и отсутствия централизованного контроля. Система аккредитации и подписания сертификатов головным центром обеспечивает:
- Единую точку доверия — Минцифры России.
- Возможность отзыва аккредитации УЦ и аннулирования всех выданных им сертификатов.
- Проверку целостности и подлинности сертификатов через цепочку доверия.

Таким образом, хотя сертификаты аккредитованных УЦ не являются самоподписанными, они выполняют роль корневых для сертификатов, которые эти УЦ выдают конечным пользователям, поэтому их и называют корневыми в контексте доверия к конкретному УЦ.

## 3
Минцифры России выступает единой точкой доверия в системе электронной подписи в России, потому что именно этот орган регулирует всю сферу и выполняет функции головного удостоверяющего центра (ГУЦ). Это закреплено на законодательном уровне — постановлением Правительства РФ от 28.11.2011 № 976 (с изменениями). Другие организации, такие как ФНС, Казначейство и Банк России, хотя и могут выдавать сертификаты, не являются головными удостоверяющими центрами в рамках этой системы. Их роль ограничена специфическими категориями пользователей или отраслями. [```2```](https://dzen.ru/a/ZWRtiPl6NVo1SPHp)

## Почему именно Минцифры России — головная организация

1. **Законодательное регулирование**. Минцифры России уполномочено Правительством РФ выполнять функции головного удостоверяющего центра. Это означает, что только этот орган имеет право выдавать сертификаты другим удостоверяющим центрам (УЦ), которые затем могут выпускать сертификаты конечным пользователям. [```11```](https://ca.kontur.ru/articles/21929-kak_ustanovit_kornevoj_sertifikat_uc)[```12```](https://markirovka.truemark.ru/elektronnaya-podpis-chestnyj-znak/)

2. **Контроль и аккредитация**. Минцифры осуществляет аккредитацию коммерческих УЦ, проверяя их соответствие строгим требованиям (капитал, лицензии, страхование, квалификация сотрудников и т. д.). После аккредитации УЦ получает от Минцифры сертификат, который позволяет ему выдавать сертификаты пользователям. [```6```](https://ca.kontur.ru/articles/52319-akkreditovannye_udostoveryayushhie_centry_voprosy)[```7```](https://nalog-nalog.ru/spravochnaya_informaciya/v_kakom_udostoveryayuwem_centre_mozhno_poluchit_ecp-nn/)

3. **Единое звено в цепочке доверия**. Корневой сертификат Минцифры России является верхним звеном в цепочке доверия для всех аккредитованных УЦ. Это обеспечивает единый стандарт проверки подписей и централизованный контроль над системой. Без этого звена доверие к сертификатам было бы фрагментированным, а проверка подписей — сложной и ненадёжной. [```11```](https://ca.kontur.ru/articles/21929-kak_ustanovit_kornevoj_sertifikat_uc)[```12```](https://markirovka.truemark.ru/elektronnaya-podpis-chestnyj-znak/)

4. **Отзыв аккредитации и аннулирование сертификатов**. Минцифры имеет полномочия отзывать аккредитацию УЦ, что приводит к аннулированию всех выданных ими сертификатов. Это невозможно при децентрализованной системе, где несколько организаций выдают сертификаты друг другу. [```6```](https://ca.kontur.ru/articles/52319-akkreditovannye_udostoveryayushhie_centry_voprosy)

## Роль других организаций

- **ФНС, Казначейство, Банк России** выдают сертификаты только для определённых категорий пользователей (руководители ИП и юрлиц, госслужащие, представители финансового сектора) и действуют в рамках своих полномочий, установленных отдельными приказами. Они не могут аккредитовать другие УЦ или выступать в роли головных центров. [```2```](https://dzen.ru/a/ZWRtiPl6NVo1SPHp)[```7```](https://nalog-nalog.ru/spravochnaya_informaciya/v_kakom_udostoveryayuwem_centre_mozhno_poluchit_ecp-nn/)

- **Коммерческие УЦ** могут выдавать сертификаты только после получения аккредитации от Минцифры. Их сертификаты подписываются корневым сертификатом Минцифры, а не самоподписываются. [```11```](https://ca.kontur.ru/articles/21929-kak_ustanovit_kornevoj_sertifikat_uc)[```12```](https://markirovka.truemark.ru/elektronnaya-podpis-chestnyj-znak/)

## Почему не может быть нескольких головных центров

Если бы несколько организаций могли выдавать сертификаты друг другу, это создало бы ряд проблем:
- **Фрагментация системы**. Отсутствие единого стандарта и центра контроля усложнило бы проверку подписей и повысило бы риски ошибок.
- **Сложность управления цепочками доверия**. При взаимодействии сертификатов от разных головных центров потребовались бы дополнительные механизмы кросс-сертификации, что увеличило бы техническую сложность и риски.
- **Снижение безопасности**. Децентрализация повысила бы вероятность компрометации системы, так как контроль над каждым головным центром стал бы менее строгим.

Таким образом, Минцифры России как единый головной центр обеспечивает целостность, безопасность и юридическую значимость системы электронной подписи в России. Это соответствует принципам централизованного регулирования, закреплённым в законодательстве.

## 4 "Они не могут аккредитовать другие УЦ или выступать в роли головных центров." разве они не дают сертификаты для УЦ банков, а УЦ банков уже выдают подписи клиентам и сотрудникам?

УЦ Банка России и другие государственные удостоверяющие центры (например, ФНС, Казначейство) не выдают сертификаты другим удостоверяющим центрам (УЦ) и не выполняют функции головных центров в системе аккредитации. Их роль ограничена выдачей электронных подписей конкретным категориям пользователей в рамках своих полномочий, установленных законодательством. Аккредитацию коммерческих УЦ и выдачу им корневых сертификатов осуществляет Минцифры России как головной удостоверяющий центр (ГУЦ). [```6```](https://www.consultant.ru/document/cons_doc_LAW_112701/606f47cb390e18423146cdb18f7ee51f8ea06194/)[```7```](https://web.archive.org/web/20190405103708/http://base.garant.ru/12184522/7a58987b486424ad79b62aa427dab1df/)

## Почему государственные УЦ не аккредитуют другие УЦ

1. **Законодательное регулирование**. Аккредитация УЦ в России регулируется Федеральным законом № 63-ФЗ «Об электронной подписи» и постановлением Правительства РФ от 28.11.2011 № 976. Согласно этим документам, полномочия по аккредитации и выдаче корневых сертификатов принадлежат Минцифры России. Государственные УЦ (ФНС, Казначейство, Банк России) не наделены такими полномочиями. [```4```](https://dzen.ru/a/ZWRtiPl6NVo1SPHp)

2. **Специализация государственных УЦ**. Эти центры выдают электронные подписи только определённым категориям пользователей:
   - УЦ ФНС — руководителям юридических лиц, ИП и нотариусам. [```11```](https://its.1c.ru/db/eldocs/content/110/hdoc)[```2```](https://www.diadoc.ru/articles/81907-elektronnaya_podpis_ot_uc_gosorganov)
   - УЦ Казначейства — должностным лицам госорганов, сотрудникам бюджетных учреждений и организациям, получающим казначейское сопровождение. [```1```](https://kiji.ru/news/common-news/poluchenie-podpisi-v-fns-federalnom-kaznachejstve-i-uc-banka-rossii/)[```2```](https://www.diadoc.ru/articles/81907-elektronnaya_podpis_ot_uc_gosorganov)
   - УЦ Банка России — руководителям кредитных организаций, операторов платёжных систем, некредитных финансовых организаций и другим лицам, связанным с финансовым сектором. [```1```](https://kiji.ru/news/common-news/poluchenie-podpisi-v-fns-federalnom-kaznachejstve-i-uc-banka-rossii/)[```2```](https://www.diadoc.ru/articles/81907-elektronnaya_podpis_ot_uc_gosorganov)

3. **Отсутствие инфраструктуры для аккредитации**. Аккредитация требует проверки соответствия УЦ строгим требованиям (капитал, лицензии, страхование, квалификация сотрудников и т. д.), а также выдачи квалифицированного сертификата. Государственные УЦ не обладают необходимыми механизмами и полномочиями для выполнения этих функций. [```6```](https://www.consultant.ru/document/cons_doc_LAW_112701/606f47cb390e18423146cdb18f7ee51f8ea06194/)[```7```](https://web.archive.org/web/20190405103708/http://base.garant.ru/12184522/7a58987b486424ad79b62aa427dab1df/)

## Роль Минцифры России как головного центра

Минцифры России выполняет функции ГУЦ, что включает:
- Аккредитацию коммерческих УЦ на основании их заявлений и проверки соответствия требованиям закона. [```6```](https://www.consultant.ru/document/cons_doc_LAW_112701/606f47cb390e18423146cdb18f7ee51f8ea06194/)
- Выдачу аккредитованным УЦ квалифицированных сертификатов, которые становятся корневыми для цепочек доверия этих центров. [```6```](https://www.consultant.ru/document/cons_doc_LAW_112701/606f47cb390e18423146cdb18f7ee51f8ea06194/)[```7```](https://web.archive.org/web/20190405103708/http://base.garant.ru/12184522/7a58987b486424ad79b62aa427dab1df/)
- Контроль за соблюдением аккредитованными УЦ установленных требований и возможность отзыва аккредитации при нарушениях. [```6```](https://www.consultant.ru/document/cons_doc_LAW_112701/606f47cb390e18423146cdb18f7ee51f8ea06194/)

## Сравнение ролей государственных УЦ и Минцифры

| **Организация**       | **Функции**                                                                 |
|------------------------|---------------------------------------------------------------------------|
| Минцифры России        | Аккредитация коммерческих УЦ, выдача корневых сертификатов, контроль системы |
| УЦ ФНС, Казначейства, Банка России | Выдача электронных подписей конкретным категориям пользователей в рамках своих полномочий |

Таким образом, государственные УЦ не могут выступать в роли головных центров или аккредитовать другие УЦ. Их задача — обеспечивать электронные подписи для определённых групп пользователей, тогда как Минцифры России координирует всю систему аккредитации и доверия.

- https://ca.kontur.ru/articles/52319-akkreditovannye_udostoveryayushhie_centry_voprosy
- https://www.diadoc.ru/articles/81907-elektronnaya_podpis_ot_uc_gosorganov

## 5 файл TSLExt.1.0.xsd
- [Пытаюсь проверить подпись (элемент /АккредитованныеУдостоверяющиеЦентры/Signature/) всех данных в файле TSLExt.1.0.xml ](https://cryptopro.ru/forum2/default.aspx?g=posts&t=8842) 
- [ПАК квалифицированной электронной подписи "Jinn-Server"](https://www.securitycode.ru/upload/iblock/214/nngr7qzd3nfara57t8me31ug0gr963w7/Jinn-server%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%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8F.pdf)

## 6 Напиши алгоритм как программа проверки подписи использует файл https://e-trust.gosuslugi.ru/assets/docs/ca/TSLExt.1.0.xsd
Файл `TSLExt.1.0.xsd` — это **схема XML** (не список статусов!), описывающая структуру и правила валидации документа TSL (Trust Service Status List). Программа **не использует его напрямую** для проверки подписи, а применяет **для валидации самого TSL‑файла** перед работой с данными из него.

Ниже — алгоритм, как программа задействует `TSLExt.1.0.xsd` в цепочке проверки электронной подписи.

### Алгоритм использования TSLExt.1.0.xsd

1. **Загрузка TSL‑файла**  
   Программа получает актуальный TSL‑документ (обычно в формате XML) с официального ресурса, например:  
   `https://e-trust.gosuslugi.ru/TrustServiceStatusList`  
   *(точный URL может меняться; важно, чтобы источник был доверенным)*.

2. **Загрузка схемы XSD**  
   Программа загружает файл схемы `TSLExt.1.0.xsd` по известному URL:  
   `https://e-trust.gosuslugi.ru/assets/docs/ca/TSLExt.1.0.xsd`  
   *(схема может быть предварительно встроена в ПО или скачиваться при обновлении TSL)*.

3. **Валидация структуры TSL против XSD**  
   Программа передаёт TSL‑XML и схему XSD в XML‑валидатор (например, используя библиотеки типа `xmlschema` в Python, `javax.xml.validation` в Java и т. п.).  
   **Что проверяется:**  
   - Соответствие имён элементов и атрибутов схеме.  
   - Правильность типов данных (даты, строки, идентификаторы).  
   - Наличие обязательных элементов (например, `<TSL>`, `<TSLType>`, `<SequenceNumber>`).  
   - Вложенность и порядок элементов согласно XSD.  
   - Корректность пространств имён (namespaces).  

4. **Обработка результатов валидации**  
   - **Если TSL валиден:** программа продолжает работу с данными из TSL (список УЦ, статусы, CRL и т. п.).  
   - **Если TSL невалиден:** программа отклоняет файл, регистрирует ошибку и, возможно, повторяет загрузку. Дальнейшая проверка подписи не выполняется.

5. **Использование данных из валидного TSL**  
   После успешной валидации программа:  
   - Извлекает список аккредитованных УЦ и их сертификаты.  
   - Проверяет, входит ли УЦ, выдавший сертификат подписи, в актуальный список доверенных.  
   - Получает ссылки на списки отозванных сертификатов (CRL) для нужных УЦ.  
   - Сверяет сроки действия сертификатов УЦ и других параметров из TSL.

6. **Проверка электронной подписи**  
   На основе данных из валидного TSL программа:  
   - Строит цепочку доверия от сертификата подписи до корневого сертификата УЦ.  
   - Проверяет статус сертификата УЦ (активен/отозван/истек).  
   - Валидирует подпись документа с учётом правил, указанных в TSL (алгоритмы, политики).  
   - Выдает итоговый вердикт: «подпись действительна» / «подпись недействительна» / «недостаточно данных».

### Зачем нужна валидация по XSD
- **Безопасность:** исключает обработку искажённых или поддельных TSL‑файлов.  
- **Соответствие стандартам:** гарантирует, что TSL соответствует формату ETSI EN 319 162-1 и требованиям УФО.  
- **Стабильность:** предотвращает сбои программы из‑за некорректной структуры XML.

### Важные замечания
- `TSLExt.1.0.xsd` **не содержит** списков УЦ, сертификатов или CRL — это только описание формата.  
- Программа должна проверять **подлинность** TSL (например, по электронной подписи самого TSL), а не только его структуру.  
- Схема XSD может обновляться; программа должна учитывать версии и поддерживать актуальные форматы.

## 6 Напиши алгоритм как программа проверки подписи использует файл tsl.xml по адресу https://e-trust.gosuslugi.ru/app/scc/portal/api/v1/portal/ca/getxml 
https://e-trust.gosuslugi.ru/check/sign#/portal/sig-check

## Алгоритм использования TSL.xml при проверке электронной подписи

Ниже приведён пошаговый алгоритм, как программа проверки электронной подписи работает с TSL.xml, загружаемым по указанному URL.

### Шаг 1. Загрузка TSL.xml

Программа выполняет HTTP‑запрос:
```
GET https://e-trust.gosuslugi.ru/app/scc/portal/api/v1/portal/ca/getxml
```
**Требования:**
* запрос должен выполняться по защищённому протоколу HTTPS;
* необходимо обработать возможные ошибки (отсутствие соединения, тайм‑аут, HTTP‑ошибки);
* рекомендуется кэшировать полученный файл с учётом его срока действия (указан в TSL).

### Шаг 2. Проверка подлинности и целостности TSL.xml

Перед использованием данных программа:
1. Проверяет **электронную подпись TSL** (если она присутствует):
   * извлекает подпись из XML;
   * находит сертификат подписанта в доверенных корневых сертификатах (обычно — Минцифры России);
   * верифицирует подпись этим сертификатом.
2. Проверяет **сроки действия TSL**:
   * сравнивает текущую дату с полями `<NextUpdate>` и `<ThisUpdate>` в XML;
   * отклоняет TSL, если он устарел.

### Шаг 3. Валидация структуры XML по схеме

Программа проверяет соответствие TSL.xml схеме `TSLExt.1.0.xsd` (загружается по известному URL):
* использует XML‑валидатор для проверки соответствия схемы;
* отклоняет файл при любых ошибках валидации.

### Шаг 4. Извлечение ключевых данных из TSL.xml

Программа анализирует XML и извлекает:
* **Список аккредитованных УЦ** (удостоверяющих центров):
   * их наименования;
   * идентификаторы (OID);
   * статусы аккредитации.
* **Сертификаты УЦ**:
   * открытые ключи;
   * сроки действия;
   * политики применения.
* **Ссылки на CRL** (списки отозванных сертификатов):
   * URL для загрузки CRL;
   * периоды обновления.
* **Правила проверки подписей**:
   * поддерживаемые алгоритмы;
   * требования к форматам.

### Шаг 5. Поиск УЦ, выдавшего сертификат подписи

Программа:
1. Из сертификата проверяемой подписи извлекает:
   * идентификатор УЦ (например, поле `Issuer`);
   * серийный номер сертификата УЦ.
2. Ищет этот УЦ в списке из TSL.xml:
   * сверяет OID и другие идентификаторы;
   * проверяет статус аккредитации (должен быть «действующий»).

### Шаг 6. Проверка статуса сертификата УЦ

Если УЦ найден в TSL:
1. Программа:
   * загружает актуальный CRL по ссылке из TSL;
   * проверяет, не включён ли сертификат УЦ в список отозванных;
   * убеждается, что срок действия сертификата УЦ не истёк.
2. Если сертификат УЦ недействителен — проверка подписи прерывается с ошибкой.

### Шаг 7. Построение цепочки доверия

Программа формирует цепочку сертификатов:
1. Сертификат подписи → сертификат УЦ → корневой сертификат (из TSL).
2. Для каждого звена:
   * проверяется подпись нижестоящего сертификата вышестоящим;
   * сверяются сроки действия;
   * проверяются политики применения.

### Шаг 8. Проверка самой электронной подписи

На основе данных из TSL программа:
* выбирает алгоритм подписи (указан в TSL);
* вычисляет хэш документа;
* сверяет подпись с открытым ключом из сертификата;
* учитывает дополнительные правила из TSL (например, требования к меткам времени).

### Шаг 9. Формирование итогового вердикта

Программа возвращает результат:
* **«Подпись действительна»** — если все проверки пройдены;
* **«Подпись недействительна»** — если хотя бы одна проверка не пройдена;
* **«Недостаточно данных»** — если TSL недоступен или некорректен.

### Шаг 10. Логирование и отчётность

Программа записывает в журнал:
* время проверки;
* идентификатор проверяемой подписи;
* статус TSL (актуальность, подпись);
* результаты всех проверок;
* итоговый вердикт.

## Важные замечания

1. **Безопасность**:
   * TSL.xml должен загружаться только по HTTPS;
   * подпись TSL должна быть проверена перед использованием;
   * сертификаты УЦ из TSL должны сверяться с доверенными корневыми.

2. **Кэширование**:
   * TSL можно кэшировать на период, указанный в `<NextUpdate>`;
   * при истечении срока кэша — загрузить новый TSL.

3. **Обработка ошибок**:
   * при недоступности TSL — использовать кэшированную версию (если актуальна);
   * при невозможности загрузить TSL — вернуть ошибку «Недостаточно данных».

4. **Соответствие стандартам**:
   * алгоритм должен соответствовать требованиям ФЗ‑63 «Об электронной подписи»;
   * формат TSL должен соответствовать ETSI EN 319 162‑1.
     
## 7 Покажи, что все корневые сертификаты - самоподписные

**Да, вы абсолютно правы.** Все корневые сертификаты Удостоверяющих Центров (УЦ) являются **самоподписными** (self-signed). Это фундаментальный принцип архитектуры PKI (Public Key Infrastructure).

## 🔐 **Почему корневые сертификаты самоподписные?**

### **1. Причина: "Курица и яйцо"**
- Чтобы проверить подпись сертификата, нужен сертификат вышестоящего УЦ
- У корневого УЦ **нет вышестоящего** центра
- Поэтому он **подписывает сам себя**, создавая точку доверия

### **2. Технические характеристики:**
```
Root Certificate {
    Version: 3
    Serial Number: Уникальный
    Signature Algorithm: ГОСТ Р 34.10-2012
    Issuer: CN=Минцифры России, O=...
    Validity: Длительный срок (15-20 лет)
    Subject: CN=Минцифры России, O=... (совпадает с Issuer)
    Subject Public Key Info: Публичный ключ
    Basic Constraints: CA=TRUE, pathlen=не ограничен
    Key Usage: keyCertSign, cRLSign
    Subject Key Identifier: [хеш]
    Authority Key Identifier: [тот же хеш] ← САМОподпись!
    Signature: Подписано собственным приватным ключом
}
```

## 🌳 **Пример из анализируемой подписи:**

### **Корневой сертификат Минцифры России:**
- **Issuer:** `CN=Минцифры России, O=Министерство цифрового развития..., C=RU`
- **Subject:** `CN=Минцифры России, O=Министерство цифрового развития..., C=RU`
- **Поля совпадают** - это самоподписанный сертификат
- **Подпись** создана приватным ключом Минцифры

## 🔄 **Иерархия доверия:**

```
┌─────────────────────────────┐
│   Самоподписной Корневой УЦ  │ ← Доверенный якорь
│   (Минцифры России)         │    (предустановлен в ОС)
└──────────────┬──────────────┘
               ↓ (подписывает)
┌─────────────────────────────┐
│   Промежуточный УЦ          │ ← Аккредитованный УЦ
│   (АО "СКБ Контур")         │    (проверяется через OCSP/CRL)
└──────────────┬──────────────┘
               ↓ (подписывает)
┌─────────────────────────────┐
│   Сертификат конечного      │ ← Сертификат пользователя
│   пользователя              │    (проверяется через OCSP/CRL)
│   (Иванова Л.А.)          │
└─────────────────────────────┘
```

## 🎯 **Ключевые отличия самоподписных сертификатов:**

| Параметр | Самоподписной (Корневой) | Промежуточный/Конечный |
|----------|--------------------------|------------------------|
| **Issuer** | = Subject | ≠ Subject |
| **Проверка подписи** | Не проверяется | Проверяется цепочкой |
| **Доверие** | Предустановлено | Наследуется от корня |
| **Статус** | Не проверяется OCSP/CRL | Проверяется обязательно |
| **Срок** | 15-20+ лет | 1-3 года |

## ⚠️ **Важные нюансы:**

### **1. "Доверенность" корневого сертификата:**
- **Технически:** любой может создать самоподписной сертификат
- **Юридически:** доверенным считается только сертификат, включенный в:
  - Реестр Минцифры РФ (для России)
  - Trust Store операционной системы
  - Список доверенных УЦ браузера

### **2. Отличие от "self-signed certificate" в вебе:**
В контексте веб-серверов:
- **Self-signed** = недоверенный, вызывает ошибки браузера
- **Root CA** = доверенный, предустановлен в ОС

В контексте ЭП в РФ:
- **Самоподписной УЦ** = доверенный корень (Минцифры)

### **3. Проверка корневого сертификата:**
Хотя подпись не проверяется, есть другие проверки:
```
1. Хеш сертификата должен совпадать с предустановленным
2. Срок действия должен быть действителен
3. OID и политики должны соответствовать требованиям
4. Ключевое использование: keyCertSign = TRUE
```

## 📋 **Как это работает на практике:**

### **В вашей подписи:**
1. **Корень:** Минцифры России (самоподписной, доверенный)
2. **Промежуточный:** АО "СКБ Контур" (подписан корнем)
3. **Конечный:** Иванова Л.А. (подписан промежуточным)

### **Проверка цепочки:**
```python
# Псевдокод проверки
def verify_chain(cert, chain):
    root = get_trusted_root()  # Предустановленный корень
    
    # Проверяем снизу вверх
    for cert in reversed(chain):
        if cert.is_self_signed():  # Дошли до корня
            if cert == root:       # Совпадает с доверенным?
                return True
            else:
                return False       # Неизвестный корень!
        
        # Проверяем подпись сертификата
        issuer_cert = find_issuer(cert, chain)
        if not verify_signature(cert, issuer_cert):
            return False
    
    return True
```

## 🎓 **Ответ на ваш вопрос:**

**Да, верно.** Все корневые сертификаты являются самоподписными. Но критически важно понимать:

1. **Не каждый самоподписной сертификат** является доверенным корнем
2. **Доверие возникает** только при включении в реестры/хранилища
3. **В PKI России** доверенным корнем является сертификат Минцифры
4. **Статус корня** не проверяется через OCSP/CRL, но проверяется его соответствие предустановленному

Это создает иерархическую систему доверия, где **корень — это якорь**, от которого распространяется доверие ко всем нижестоящим сертификатам через механизмы подписания и проверки.