doc/IT/CADES/AI/cryptopro-csp1.md

## cryptopro CSP
## 1 Базовый Вопрос 
Есть СЭД, где подписание проводится электронной подписью.  
Параметры: 
- Тип подписи: усиленная квалифицированная электронная подпись (УКЭП).
- Выдается аккредитованным центром УЦ Контур (удостоверяющий центр). 
- Формат подписи: CADES-XL. В качестве OCSP сервера используется внешний сервис «УЦ Контур OCSP». 
- TSP – внешний сервис компании Тензор.
- Ключи хранятся в РуТокен.  
- Внутри компании при подписании используются продукты КриптоПРО. 
Нарисуй подробную схему (mermaid) взаимодействия всех компонент рассмотренного решения с указанием протокола, передаваемых данных и состава программных моделей на серверной и клиентской части.

Разбиваю систему на несколько читаемых схем с детализацией.

## Схема 1: Общая архитектура системы

```mermaid
graph TB
    subgraph "Клиентская часть"
        A[Веб-браузер] --> B[СЭД Клиент]
        B --> C[КриптоПРО Browser Plugin]
        C --> D[КриптоПРО CSP]
        D --> E[Драйвер Рутокен]
        E --> F[Рутокен]
    end

    subgraph "Серверная часть"
        G[Сервер СЭД] --> H[КриптоПРО SDK]
        G --> I[База документов]
        G --> J[База сертификатов]
    end

    subgraph "Внешние сервисы"
        K[УЦ Контур OCSP]
        L[Тензор TSP]
        M[УЦ Контур]
    end

    C --> K
    C --> L
    H --> K
    H --> L
    M -.-> F
```

**Компоненты клиентской части:**
- **Веб-браузер** - интерфейс пользователя
- **СЭД Клиент** - JavaScript приложение
- **КриптоПРО Browser Plugin** - плагин для работы с ЭП в браузере
- **КриптоПРО CSP** - криптопровайдер
- **Драйвер Рутокен** - драйвер для работы с токеном
- **Рутокен** - аппаратный носитель ключей

**Компоненты серверной части:**
- **Сервер СЭД** - backend система (Java/.NET)
- **КриптоПРО SDK** - библиотеки для работы с ЭП
- **Базы данных** - хранение документов и сертификатов

## Схема 2: Процесс подписания документа

```mermaid
sequenceDiagram
    participant П as Пользователь
    participant К as Клиент СЭД
    participant Пл as КриптоПРО Plugin
    participant CSP as КриптоПРО CSP
    participant РТ as Рутокен
    participant ОС as УЦ Контур OCSP
    participant ТС as Тензор TSP
    participant С as Сервер СЭД

    Note over П,С: Этап 1: Подготовка документа
    П->>К: Запрос на подписание документа
    К->>К: Формирование хэша документа (SHA-256)
    К->>Пл: Передача хэша для подписания
    
    Note over Пл,РТ: Этап 2: Создание подписи
    Пл->>CSP: Запрос на подписание хэша
    CSP->>РТ: Команда подписи (PKCS#11)
    РТ->>РТ: Подписание закрытым ключом
    РТ-->>CSP: Подписанный хэш
    CSP-->>Пл: Базовая подпись
    
    Note over Пл,ОС: Этап 3: Получение OCSP-статуса
    Пл->>ОС: OCSP-запрос (сертификат)
    ОС-->>Пл: OCSP-ответ (статус: valid/revoked)
    
    Note over Пл,ТС: Этап 4: Получение временной метки
    Пл->>ТС: TSP-запрос (хэш подписи)
    ТС-->>Пл: TSP-ответ (RFC 3161)
    
    Note over Пл,С: Этап 5: Формирование CAdES-XL
    Пл->>Пл: Сборка CAdES-XL контейнера
    Пл-->>К: Готовая подпись
    К->>С: Отправка подписанного документа
    С-->>К: Подтверждение приема
```

## Схема 3: Формат данных CAdES-XL

```mermaid
graph LR
    A[CAdES-XL Контейнер] --> B[Исходная подпись]
    A --> C[OCSP-ответ]
    A --> D[TSP-метка]
    A --> E[Цепочка сертификатов]
    
    B --> B1[Подписанный хэш документа]
    B --> B2[Сертификат подписанта]
    
    C --> C1[Статус сертификата]
    C --> C2[Время проверки]
    C --> C3[Подпись OCSP-сервера]
    
    D --> D1[Временная метка]
    D --> D2[Подпись TSA]
    
    E --> E1[Сертификат подписанта]
    E --> E2[Промежуточные сертификаты]
    E --> E3[Корневой сертификат]
```

**Состав CAdES-XL:**
- **Подписанные данные** - хэш документа + подпись
- **OCSP-ответ** - подтверждение действительности сертификата
- **TSP-метка** - доказательство времени подписания
- **Полная цепочка сертификатов** - от подписанта до корневого УЦ

## Схема 4: Верификация подписи на сервере

```mermaid
sequenceDiagram
    participant С as Сервер СЭД
    participant SDK as КриптоПРО SDK
    participant ОС as УЦ Контур OCSP
    participant ТС as Тензор TSP
    participant БД as База данных

    С->>SDK: Верификация CAdES-XL подписи
    
    Note over SDK,SDK: Проверка целостности
    SDK->>SDK: Проверка хэша документа
    SDK->>SDK: Проверка электронной подписи
    
    Note over SDK,ОС: Проверка сертификата
    SDK->>ОС: Запрос актуального статуса
    ОС-->>SDK: Текущий статус сертификата
    
    Note over SDK,ТС: Проверка временной метки
    SDK->>ТС: Верификация TSP-метки
    ТС-->>SDK: Подтверждение валидности
    
    Note over SDK,БД: Сохранение результатов
    SDK-->>С: Результат верификации
    С->>БД: Сохранение подписанного документа
    С->>БД: Запись журнала подписания
```

## Технические детали

**Протоколы и форматы:**
- **OCSP:** HTTP/HTTPS, ASN.1 кодирование
- **TSP:** HTTP/HTTPS, RFC 3161
- **Подпись:** CAdES-XL, PKCS#7/CMS
- **Сертификаты:** X.509 v3
- **Хэширование:** SHA-256/512

**Криптографические параметры:**
- **Алгоритмы:** RSA-2048/4096, ECDSA
- **Носитель:** Рутокен ГОСТ 2.0
- **Формат ключей:** PKCS#8, PKCS#12

**Данные передаваемые между компонентами:**
- Хэш документа (32/64 байта)
- Электронная подпись (256/512 байт)
- OCSP-ответ (1-4 КБ)
- TSP-метка (2-8 КБ)
- CAdES-XL контейнер (10-50 КБ)

## 2 Уточнение 1
Места хранения промежуточных и корневых сертификатов на клиентском компьютере.  
Не понятно, зачем нужен  КриптоПРО SDK в серверной части, если подписание производится в клиентской части.   
Будем считать, что на клиенте стоит "Толстый клиент СЭД" и не требуется браузер, КриптоПРО Browser Plugin.  

Учту замечания и предоставлю уточненные схемы.

## Схема 1: Хранилища сертификатов на клиентском компьютере

```mermaid
graph TB
    subgraph "Клиентский компьютер"
        A[Толстый клиент СЭД] --> B[КриптоПРО CSP]
        A --> C[Системное хранилище]
        
        B --> D[Хранилище КриптоПРО]
        B --> E[Реестр Windows]
        
        C --> F[Доверенные корневые УЦ]
        C --> G[Промежуточные УЦ]
        C --> H[Личные сертификаты]
        
        I[Рутокен] --> J[Закрытый ключ]
        I --> K[Личный сертификат]
        I --> L[Цепочка сертификатов]
        
        B --> I
    end
    
    subgraph "Внешние источники"
        M[УЦ Контур] --> N[Корневые сертификаты]
        M --> O[Промежуточные сертификаты]
        P[Сервер СЭД] --> Q[Доверенные сертификаты]
    end
    
    N --> F
    O --> G
    Q --> F
```

**Детализация хранилищ:**

### 1. Системное хранилище Windows:
- **Доверенные корневые УЦ** (`Cert:\LocalMachine\Root`)
  - Корневые сертификаты УЦ Контур
  - Другие аккредитованные УЦ
- **Промежуточные УЦ** (`Cert:\LocalMachine\CA`)
  - Промежуточные сертификаты УЦ Контур
  - Сертификаты цепочки доверия
- **Личные сертификаты** (`Cert:\CurrentUser\My`)
  - Сертификаты пользователя (копии с Рутокен)

### 2. Хранилище КриптоПРО:
- Файловое хранилище (`%ALLUSERSPROFILE%\Application Data\Crypto Pro`)
- Контейнеры закрытых ключей
- Кэш сертификатов
- Настройки криптопровайдера

### 3. Рутокен:
- Закрытый ключ (не экспортируемый)
- Личный сертификат пользователя
- Возможно: цепочка сертификатов

## Схема 2: Работа с сертификатами при подписании

```mermaid
sequenceDiagram
    participant ТК as Толстый клиент СЭД
    participant CSP as КриптоПРО CSP
    participant РТ as Рутокен
    participant ХР as Хранилища сертификатов
    participant ОС as УЦ Контур OCSP

    Note over ТК,ХР: Этап 1: Построение цепочки доверия
    ТК->>CSP: Запрос сертификата с Рутокен
    CSP->>РТ: Чтение сертификата
    РТ-->>CSP: Личный сертификат
    CSP-->>ТК: Сертификат пользователя
    
    ТК->>ХР: Построение цепочки доверия
    ХР-->>ТК: Корневые/промежуточные сертификаты
    
    Note over ТК,ОС: Этап 2: Проверка цепочки
    ТК->>CSP: Проверка цепочки сертификатов
    CSP->>ХР: Поиск корневого сертификата
    ХР-->>CSP: Корневой сертификат УЦ Контур
    CSP-->>ТК: Результат проверки цепочки
    
    ТК->>ОС: Проверка статуса сертификата
    ОС-->>ТК: OCSP-ответ (действителен/отозван)
    
    Note over ТК,ТК: Этап 3: Формирование данных для подписи
    ТК->>ТК: Включение цепочки в CAdES-XL
```

## Схема 3: Роль КриптоПРО SDK на сервере

```mermaid
graph TB
    subgraph "Серверная часть"
        A[Сервер СЭД] --> B[КриптоПРО SDK]
        
        B --> C[Верификация подписи]
        B --> D[Проверка цепочек сертификатов]
        B --> E[Валидация временных меток]
        B --> F[Проверка статусов OCSP]
        
        C --> C1[Целостность документа]
        C --> C2[Корректность подписи]
        
        D --> D1[Построение цепочки доверия]
        D --> D2[Проверка корневых сертификатов]
        D --> D3[Проверка сроков действия]
        
        G[Хранилище сертификатов сервера] --> G1[Доверенные корневые УЦ]
        G --> G2[Списки отозванных сертификатов]
        G --> G3[Кэш OCSP-ответов]
        
        B --> G
        B --> H[УЦ Контур OCSP]
        B --> I[Тензор TSP]
    end
    
    subgraph "Клиентская часть"
        J[Толстый клиент] --> K[Подписанный документ]
        K --> A
    end
```

**Задачи КриптоПРО SDK на сервере:**

### 1. Верификация подписи:
- Проверка соответствия подписи документу
- Проверка алгоритмов подписи
- Валидация формата CAdES-XL

### 2. Проверка цепочек сертификатов:
```python
# Пример логики проверки
def verify_certificate_chain(server_cert, intermediate_certs, root_certs):
    # Проверка срока действия всех сертификатов
    check_validity_period(server_cert, intermediate_certs, root_certs)
    
    # Построение и проверка цепочки доверия
    chain = build_trust_chain(server_cert, intermediate_certs, root_certs)
    
    # Проверка политик сертификации
    verify_certificate_policies(chain)
    
    return chain_is_valid
```

### 3. Работа с OCSP и CRL:
- Кэширование OCSP-ответов
- Проверка по спискам отзыва (CRL)
- Валидация подписей OCSP-ответов

### 4. Проверка временных меток:
- Верификация TSP-подписи
- Проверка согласованности времени
- Валидация политик временных меток

## Схема 4: Детальный процесс верификации на сервере

```mermaid
sequenceDiagram
    participant К as Толстый клиент
    participant С as Сервер СЭД
    participant SDK as КриптоПРО SDK
    participant ХР as Хранилище сертификатов
    participant ОС as УЦ Контур OCSP
    participant ТС as Тензор TSP

    К->>С: Передача CAdES-XL подписи
    С->>SDK: Запрос верификации подписи
    
    Note over SDK,SDK: Проверка целостности
    SDK->>SDK: Проверка хэша документа
    SDK->>SDK: Проверка электронной подписи
    
    Note over SDK,ХР: Проверка цепочки сертификатов
    SDK->>ХР: Поиск корневого сертификата УЦ Контур
    ХР-->>SDK: Корневой сертификат
    SDK->>SDK: Построение и проверка цепочки
    
    Note over SDK,ОС: Проверка статуса сертификата
    SDK->>ОС: OCSP-запрос (сертификат подписанта)
    ОС-->>SDK: OCSP-ответ (статус)
    
    Note over SDK,ТС: Проверка временной метки
    SDK->>ТС: Верификация TSP-подписи
    ТС-->>SDK: Подтверждение валидности
    
    SDK->>SDK: Проверка политик подписания
    SDK->>SDК: Валидация CAdES-XL структуры
    
    SDK-->>С: Результат верификации
    С->>С: Запись в журнал аудита
    С-->>К: Подтверждение приема документа
```

**Преимущества использования КриптоПРО SDK на сервере:**

1. **Единая логика проверки** - одинаковые алгоритмы на клиенте и сервере
2. **Централизованное управление доверенными сертификатами**
3. **Кэширование OCSP-ответов** - снижение нагрузки на УЦ
4. **Детальный аудит** - полная информация о процессе верификации
5. **Соответствие требованиям** - выполнение нормативных требований к ЭП

Это объясняет необходимость КриптоПРО SDK на сервере даже при клиентском подписании.

## 3 Нет, все криптооперации только на клиенте через  КриптоПРО CSP. Корневые и промежуточные сертификаты УЦ хранятся в реестре Windows.

Мы сосредоточимся только на клиентской части, где все криптооперации выполняются с помощью КриптоПРО CSP.
Компоненты: толстый клиент СЭД, КриптоПРО CSP, Рутокен, системное хранилище сертификатов Windows (корневые и промежуточные сертификаты УЦ Контур), а также взаимодействие с внешними сервисами (OCSP УЦ Контур и TSP Тензор).

Процесс подписания документа:
- Подготовка документа и вычисление хэша.
- Подписание хэша с помощью закрытого ключа с Рутокен (через КриптоПРО CSP).
- Получение OCSP-статуса сертификата.
- Получение временной метки от TSP.
- Формирование подписи в формате CAdES-XL, включая цепочку сертификатов, OCSP-ответ и временную метку.
- Поскольку серверная часть не участвует, мы не будем ее включать в схему.

Уточним, что корневые и промежуточные сертификаты УЦ Контур уже установлены в хранилище Windows (в доверенные корневые и промежуточные УЦ соответственно).

## Схема работы криптографических операций на клиентской части

```mermaid
graph TB
    subgraph "Клиентский компьютер"
        A[Толстый клиент СЭД] --> B[КриптоПРО CSP]
        B --> C[Драйвер Рутокен]
        C --> D[Рутокен с ключами]
        
        B --> E[Системное хранилище Windows]
        E --> F[Доверенные корневые УЦ]
        E --> G[Промежуточные УЦ]
        
        A --> H[Внешние сервисы]
    end
    
    subgraph "Внешние сервисы"
        I[УЦ Контур OCSP]
        J[Тензор TSP]
    end
    
    A --> I
    A --> J
```

## Детальная схема процесса подписания

```mermaid
sequenceDiagram
    participant ТК as Толстый клиент СЭД
    participant CSP as КриптоПРО CSP
    participant РТ as Рутокен
    participant ХР as Хранилище Windows
    participant ОС as УЦ Контур OCSP
    participant ТС as Тензор TSP

    Note over ТК,ТК: Этап 1: Подготовка документа
    ТК->>ТК: Формирование документа для подписания
    ТК->>ТК: Вычисление хэша (SHA-256/512)
    
    Note over ТК,ХР: Этап 2: Получение сертификата
    ТК->>CSP: Запрос сертификатов с Рутокен
    CSP->>РТ: Получение сертификата пользователя
    РТ-->>CSP: Сертификат подписанта
    CSP-->>ТК: Сертификат и цепочка
    
    ТК->>ХР: Запрос корневых сертификатов УЦ Контур
    ХР-->>ТК: Корневые и промежуточные сертификаты
    
    Note over ТК,ОС: Этап 3: Проверка статуса сертификата
    ТК->>ОС: OCSP-запрос с сертификатом
    ОС-->>ТК: OCSP-ответ (статус действителен)
    
    Note over ТК,РТ: Этап 4: Подписание документа
    ТК->>CSP: Запрос на подписание хэша
    CSP->>РТ: Команда подписи (использует закрытый ключ)
    РТ-->>CSP: Подписанный хэш
    CSP-->>ТК: Базовая электронная подпись
    
    Note over ТК,ТС: Этап 5: Получение временной метки
    ТК->>ТС: TSP-запрос (хэш подписи)
    ТС-->>ТК: TSP-ответ с временной меткой
    
    Note over ТК,ТК: Этап 6: Формирование CAdES-XL
    ТК->>ТК: Сборка CAdES-XL контейнера:
    ТК->>ТК: - Исходная подпись
    ТК->>ТК: - Сертификат подписанта
    ТК->>ТК: - Цепочка сертификатов
    ТК->>ТК: - OCSP-ответ
    ТК->>ТК: - TSP-метка
    
    ТК-->>ТК: Готовый подписанный документ в формате CAdES-XL
```

## Схема хранилищ сертификатов Windows

```mermaid
graph LR
    subgraph "Системное хранилище Windows"
        A[Доверенные корневые УЦ] --> A1[Корневой УЦ Контур]
        A --> A2[Другие аккредитованные УЦ]
        
        B[Промежуточные УЦ] --> B1[Промежуточные сертификаты УЦ Контур]
        B --> B2[Сертификаты цепочки доверия]
        
        C[Личные сертификаты] --> C1[Копии сертификатов с Рутокен]
    end
    
    subgraph "Рутокен"
        D[Закрытый ключ] --> D1[Не экспортируемый]
        E[Открытый ключ] --> E1[Сертификат пользователя]
    end
    
    E1 --> C1
    A1 --> B1
```

## Технические детали реализации

### 1. Работа с хранилищами сертификатов:

```cpp
// Пример использования CryptoAPI для работы с хранилищами
HCERTSTORE hRootStore = CertOpenSystemStore(0, "ROOT");
HCERTSTORE hCAStore = CertOpenSystemStore(0, "CA");
HCERTSTORE hMyStore = CertOpenSystemStore(0, "MY");

// Поиск сертификата УЦ Контур
PCCERT_CONTEXT pCertContext = CertFindCertificateInStore(
    hRootStore,
    X509_ASN_ENCODING,
    0,
    CERT_FIND_SUBJECT_STR,
    L"УЦ Контур",
    NULL
);
```

### 2. Процесс подписания через КриптоПРО CSP:

```cpp
// Инициализация криптопровайдера
HCRYPTPROV hProv;
CryptAcquireContext(&hProv, NULL, "Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider", PROV_GOST_2012_256, 0);

// Получение хэша документа
HCRYPTHASH hHash;
CryptCreateHash(hProv, CALG_GR3411, 0, 0, &hHash);
CryptHashData(hHash, pbData, dwDataLen, 0);

// Подписание хэша
DWORD dwSigLen;
CryptSignHash(hHash, AT_SIGNATURE, NULL, 0, NULL, &dwSigLen);
BYTE *pbSignature = new BYTE[dwSigLen];
CryptSignHash(hHash, AT_SIGNATURE, NULL, 0, pbSignature, &dwSigLen);
```

### 3. Формат CAdES-XL контейнера:

```
CAdES-XL Подпись:
├── SignedData
│   ├── Version
│   ├── DigestAlgorithms
│   ├── EncapsulatedContentInfo (документ)
│   ├── Certificates (цепочка сертификатов)
│   └── SignerInfos
│       ├── Version
│       ├── SID (идентификатор подписанта)
│       ├── DigestAlgorithm
│       ├── SignedAttributes
│       ├── SignatureAlgorithm
│       └── SignatureValue
├── OCSPResponse (ответ от УЦ Контур)
└── TimeStampToken (метка от Тензор TSP)
```

### 4. Взаимодействие с внешними сервисами:

**OCSP-запрос:**
- Протокол: HTTP/HTTPS
- Формат: ASN.1
- Данные: серийный номер сертификата
- Ответ: статус (good, revoked, unknown)

**TSP-запрос:**
- Протокол: HTTP/HTTPS
- Формат: RFC 3161
- Данные: хэш от подписи
- Ответ: временная метка с подписью TSA

## Преимущества клиентского подписания:

1. **Безопасность** - закрытые ключи никогда не покидают Рутокен
2. **Производительность** - нет сетевых задержек при криптооперациях
3. **Автономность** - работа без подключения к серверу СЭД
4. **Соответствие требованиям** - УКЭП соответствует 63-ФЗ

Все криптографические операции выполняются локально на клиентском компьютере с использованием установленных корневых и промежуточных сертификатов из хранилища Windows.

## 4 Как на другом аналогичном компьютере проверить подпись? Сертификат подписанты мы вкладываем в подпись и устанавливать его не нужно.

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

При этом сертификат подписанта мы можем извлечь из подписи (если он вложен). Однако, для проверки цепочки нам нужны корневые и промежуточные сертификаты, которые могут быть не вложены в подпись (или вложены, но мы должны доверять им только если они подписаны доверенными УЦ).

Что понадобится на другом компьютере:
- Установленные корневые сертификаты УЦ, которым мы доверяем (например, УЦ Контур).
- Установленные промежуточные сертификаты, если они не вложены в подпись или если мы не хотим полагаться на вложенные.
- Программное обеспечение для проверки подписи (например, КриптоПРО CSP и утилиты или библиотеки для проверки).
- Доступ к OCSP-серверу или CRL для проверки статуса сертификатов (если мы проверяем онлайн).
- Возможно, потребуется настроить доверие к TSA (сервису временных меток) для проверки временных меток.

Сертификат подписанта можно вложить в подпись, и тогда он будет доступен при проверке. Однако, чтобы проверить цепочку, нам нужно иметь корневые и промежуточные сертификаты в хранилище доверенных корневых и промежуточных УЦ.

Важно: мы должны проверить, что сертификат подписанта был выдан доверенным УЦ, и что цепочка построена правильно.

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

Если на другом компьютере не установлены корневые и промежуточные сертификаты, то даже при вложенной цепочке мы не сможем проверить подпись, потому что мы не доверяем корневому сертификату, если он не установлен в хранилище доверенных.

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

Кроме того, для проверки подписи в формате CAdES-XL нам понадобится ПО, которое поддерживает этот формат (КриптоПРО CSP, например).

Итак, для проверки на другом компьютере нужно:
- Установить корневые и промежуточные сертификаты УЦ Контур (если они еще не установлены).
- Установить КриптоПРО CSP (или другое ПО, которое умеет проверять CAdES-XL) и настроить хранилища сертификатов.
- Убедиться, что есть доступ к OCSP-серверу УЦ Контур и TSP-серверу Тензор (если проверяем онлайн).
- Передать подписанный документ (вместе с подписью) на другой компьютер.
- Выполнить проверку подписи.

Если мы не проверяем онлайн (без OCSP и TSP), то мы можем проверить только целостность и цепочку сертификатов, но не актуальность статуса сертификата.

Пример кода для проверки подписи с использованием КриптоПРО CSP (C++), но это может быть сделано и с помощью утилит командной строки (cryptcp или cups).

Однако, если мы хотим проверить подпись без установки КриптоПРО CSP, то это может быть проблематично, так как требуется поддержка формата и алгоритмов.

Вывод: на другом компьютере нужно установить:
- Корневые и промежуточные сертификаты УЦ.
- ПО для проверки подписи (КриптоПРО CSP или другое).
- Обеспечить доступ к OCSP и TSP (для полной проверки).

Сертификат подписанта вложен в подпись, поэтому устанавливать его отдельно не нужно, но корневые и промежуточные сертификаты должны быть установлены в хранилище.

## Проверка подписи на другом компьютере

```mermaid
graph TB
    subgraph "Компьютер для проверки"
        A[Программа проверки] --> B[КриптоПРО CSP]
        A --> C[Системное хранилище Windows]
        
        C --> D[Доверенные корневые УЦ]
        C --> E[Промежуточные УЦ]
        
        F[Внешние сервисы] --> G[УЦ Контур OCSP]
        F --> H[Тензор TSP]
        
        A --> G
        A --> H
    end
    
    I[Подписанный документ] --> A
```

## Что нужно для проверки на другом компьютере:

### 1. Обязательные компоненты:
```mermaid
graph LR
    A[Компьютер для проверки] --> B[КриптоПРО CSP]
    A --> C[Доверенные корневые сертификаты]
    A --> D[Доверенные промежуточные сертификаты]
    A --> E[Программа проверки]
    
    F[Подпись CAdES-XL] --> G[Сертификат подписанта]
    F --> H[Цепочка сертификатов]
    F --> I[OCSP-ответ]
    F --> J[TSP-метка]
    
    E --> F
```

## Детальный процесс проверки подписи

```mermaid
sequenceDiagram
    participant ПП as Программа проверки
    participant CSP as КриптоПРО CSP
    participant ХР as Хранилище Windows
    participant ОС as УЦ Контур OCSP
    participant ТС as Тензор TSP

    Note over ПП,ПП: Этап 1: Извлечение данных из CAdES-XL
    ПП->>ПП: Парсинг CAdES-XL контейнера
    ПП->>ПП: Извлечение сертификата подписанта
    ПП->>ПП: Извлечение цепочки сертификатов
    ПП->>ПП: Извлечение OCSP-ответа
    ПП->>ПП: Извлечение TSP-метки
    ПП->>ПП: Извлечение исходного документа
    
    Note over ПП,ХР: Этап 2: Проверка цепочки доверия
    ПП->>ХР: Поиск корневого сертификата УЦ Контур
    ХР-->>ПП: Корневой сертификат
    ПП->>CSP: Проверка цепочки сертификатов
    CSP-->>ПП: Результат проверки цепочки
    
    Note over ПП,ОС: Этап 3: Проверка статуса сертификата
    ПП->>ОС: Запрос актуального статуса сертификата
    ОС-->>ПП: Текущий OCSP-ответ
    ПП->>ПП: Сравнение с вложенным OCSP-ответом
    
    Note over ПП,ТС: Этап 4: Проверка временной метки
    ПП->>ТС: Верификация TSP-метки
    ТС-->>ПП: Подтверждение валидности
    
    Note over ПП,ПП: Этап 5: Проверка подписи
    ПП->>CSP: Проверка электронной подписи
    CSP-->>ПП: Результат проверки подписи
    
    ПП->>ПП: Формирование итогового отчета
```

## Технические детали проверки

### 1. Компоненты, необходимые для проверки:

**Обязательно:**
- КриптоПРО CSP (для проверки алгоритмов и форматов)
- Доверенные корневые сертификаты УЦ Контур в хранилище Windows
- Доверенные промежуточные сертификаты УЦ Контур
- Программа для проверки подписей (может быть встроена в СЭД)

**Опционально (для полной проверки):**
- Доступ к УЦ Контур OCSP (для проверки актуального статуса)
- Доступ к Тензор TSP (для верификации временных меток)

### 2. Что содержится в CAdES-XL и не требует отдельной установки:

```cpp
// Данные, которые извлекаются из подписи:
struct CAdES_XL_Data {
    vector<byte> original_document;      // Исходный документ
    X509Certificate signer_cert;         // Сертификат подписанта
    vector<X509Certificate> cert_chain;  // Цепочка сертификатов
    OCSPResponse ocsp_response;          // Ответ OCSP на момент подписания
    TimeStampToken tsp_token;            // Временная метка
    vector<byte> signature;              // Электронная подпись
};
```

### 3. Критически важные моменты:

**Сертификат подписанта:**
- ✅ **Вложен в подпись** - не требует отдельной установки
- ✅ **Цепочка сертификатов** - обычно тоже вложена
- ❌ **Корневые сертификаты** - должны быть установлены в доверенное хранилище

**Проверка цепочки доверия:**
```python
def verify_certificate_chain(signer_cert, intermediate_certs, trusted_roots):
    # Проверяем, что сертификат подписанта выдан промежуточным УЦ
    if not verify_issuer(signer_cert, intermediate_certs[0]):
        return False
    
    # Проверяем, что промежуточный УЦ выдан корневым УЦ
    if not verify_issuer(intermediate_certs[0], trusted_roots["УЦ Контур"]):
        return False
    
    # Проверяем, что корневой УЦ доверенный
    if not is_trusted_root(trusted_roots["УЦ Контур"]):
        return False
    
    return True
```

### 4. Сценарии проверки:

```mermaid
graph TB
    A[Начало проверки] --> B{Есть доступ к интернету?}
    
    B -->|Да| C[Онлайн проверка]
    B -->|Нет| D[Офлайн проверка]
    
    C --> C1[Проверка по OCSP]
    C --> C2[Верификация TSP]
    C --> C3[Проверка подписи]
    C --> E[Полная проверка]
    
    D --> D1[Проверка вложенного OCSP]
    D --> D2[Проверка TSP-метки]
    D --> D3[Проверка подписи]
    D --> F[Ограниченная проверка]
    
    E --> G[Результат: Полностью действительна]
    F --> H[Результат: Действительна на момент подписания]
```

### 5. Код проверки подписи:

```cpp
// Пример использования КриптоПРО для проверки
HRESULT VerifySignature(const std::string& signed_data) {
    // Инициализация криптопровайдера
    HCRYPTPROV hProv;
    CryptAcquireContext(&hProv, NULL, "Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider", 
                       PROV_GOST_2012_256, 0);
    
    // Создание объекта для проверки подписи
    HCRYPTMSG hMsg = CryptMsgOpenToDecode(ENCODING, 0, 0, hProv, NULL, NULL);
    
    // Декодирование CAdES-XL
    CryptMsgUpdate(hMsg, (BYTE*)signed_data.c_str(), signed_data.length(), TRUE);
    
    // Проверка подписи
    BOOL result = CryptMsgControl(hMsg, 0, CMSG_CTRL_VERIFY_SIGNATURE, &verify_params);
    
    if (result) {
        // Дополнительные проверки цепочки сертификатов
        return VerifyCertificateChain(hMsg);
    }
    
    return E_FAIL;
}
```

## Вывод:

**Что НЕ нужно устанавливать:**
- Сертификат подписанта (вложен в подпись)
- Промежуточные сертификаты (обычно вложены в подпись)
- Закрытые ключи (только для подписания)

**Что НУЖНО установить:**
- КриптоПРО CSP
- Доверенные корневые сертификаты УЦ Контур
- Программу для проверки подписей

**Что желательно иметь:**
- Доступ к интернету для проверки актуального статуса сертификатов
- Доступ к TSP-сервису для верификации временных меток

Таким образом, для проверки подписи на другом компьютере достаточно установить криптопровайдер и доверенные корневые сертификаты, все остальные необходимые данные содержатся в самой CAdES-XL подписи.

## 5 Верно ли составил обобщённый алгоритм подписания документа:
1. Толстый клиент СЭД: Получение документа для подписания УКЭП
2. Толстый клиент СЭД: Передача файла документа в КриптоПро CSP
3. КриптоПро CSP: Формирование CADES-BES
- 3a) Запрос и проверка сертификатов корневого и промежуточных УЦ
- 3b) Команда подписи (использует закрытый ключ из РуТокен) и прием подписанного хэш
- 3с) Получение сертификата подписанта для вложения в подпись
4. КриптоПро CSP: Получение OCSP-ответа и TSP-ответа и формирование CADES-XL контейнера (на основе CADES-BES)
5. КриптоПро CSP: Передача сформированного файла-подписи CADES-XL в Толстый клиент СЭД
6. Формирование Описания электронного документа (XML) и передача трех файлов (документ, подпись CADES-XLб описание) в хранилище подписанных документов

В представленном алгоритме есть неточности. В частности, пункты 3a, 3b, 3c, 4 и 5 относятся к разным участникам процесса.
Давайте разберем, кто что делает.

В корректном алгоритме:
- Толстый клиент СЭД управляет процессом.
- КриптоПРО CSP выполняет криптографические операции, но не занимается самостоятельным сбором OCSP и TSP (это делает клиентская программа с помощью CSP или других средств).
- Формирование CAdES-BES и CAdES-XL осуществляется толстым клиентом с использованием функций CSP.

Исправленный алгоритм:
- Толстый клиент СЭД: Получение документа для подписания УКЭП.
- Толстый клиент СЭД: Вычисление хэша документа (возможно, с помощью КриптоПРО CSP) или передача документа в CSP для вычисления хэша и подписания.
- Толстый клиент СЭД: Запрос к КриптоПРО CSP на подписание хэша документа (с формированием CAdES-BES).
При этом:
- 3a. КриптоПРО CSP запрашивает сертификат с Рутокен (и цепочку сертификатов, если возможно) и вкладывает их в подпись.
- 3b. КриптоПРО CSP использует закрытый ключ с Рутокен для подписания хэша (пользователь вводит PIN-код для доступа к ключу).

Толстый клиент СЭД: Получение от КриптоПРО CSP подписи в формате CAdES-BES.

Толстый клиент СЭД: Усиление подписи до CAdES-XL:
- 5a. Запрос OCSP-статуса для сертификата подписанта у УЦ Контур (OCSP-сервер).
- 5b. Запрос временной метки у TSP-сервиса Тензор.
- 5c. Формирование CAdES-XL контейнера путем добавления OCSP-ответа и TSP-метки к CAdES-BES.

Толстый клиент СЭД: Формирование описания электронного документа (XML) и передача трех файлов (документ, подпись CAdES-XL, описание) в хранилище подписанных документов.

Таким образом, КриптоПРО CSP не занимается самостоятельно получением OCSP и TSP, это делает толстый клиент (или плагин) с помощью соответствующих сервисов.

Если в вашем алгоритме подразумевается, что КриптоПРО CSP сам выполняет шаги 4 и 5, то это возможно только если используется дополнительный компонент (например, КриптоПРО TSP Client, OCSP Client) и они настроены в CSP. Но обычно эти операции выполняются клиентской программой.

Уточним, что в стандартном сценарии:
- КриптоПРО CSP предоставляет функции для подписания и проверки подписи, работы с сертификатами и ключами.
- Для работы с OCSP и TSP клиентская программа использует отдельные библиотеки или компоненты (которые могут быть от КриптоПРО или других производителей).

В целом алгоритм верный, но есть несколько важных уточнений и корректировок:

## Исправленный алгоритм подписания документа:

```mermaid
sequenceDiagram
    participant ТК as Толстый клиент СЭД
    participant CSP as КриптоПРО CSP
    participant РТ as Рутокен
    participant ОС as УЦ Контур OCSP
    participant ТС as Тензор TSP
    participant ХР as Хранилище

    Note over ТК,ТК: 1. Подготовка документа
    ТК->>ТК: Получение документа для подписания УКЭП
    
    Note over ТК,CSP: 2. Формирование хэша
    ТК->>CSP: Передача документа/хэша для подписания
    
    Note over CSP,CSP: 3. Формирование CAdES-BES
    CSP->>РТ: Запрос сертификата подписанта
    РТ-->>CSP: Сертификат подписанта
    CSP->>ХР: Проверка цепочки доверия (корневые/промежуточные УЦ)
    CSP->>РТ: Команда подписи (использует закрытый ключ)
    РТ-->>CSP: Подписанный хэш
    CSP-->>ТК: CAdES-BES подпись
    
    Note over ТК,ТК: 4. Усиление до CAdES-XL
    ТК->>ОС: Запрос OCSP-статуса сертификата
    ОС-->>ТК: OCSP-ответ
    ТК->>ТС: Запрос временной метки для подписи
    ТС-->>ТК: TSP-ответ
    
    Note over ТК,ТК: 5. Формирование финальной подписи
    ТК->>ТК: Сборка CAdES-XL (CAdES-BES + OCSP + TSP)
    
    Note over ТК,ХР: 6. Сохранение результатов
    ТК->>ТК: Формирование описания ЭД (XML)
    ТК->>ХР: Передача в хранилище: документ, подпись CAdES-XL, описание
```

## Уточнения к вашему алгоритму:

### Пункт 2: "Передача файла документа в КриптоПро CSP"
**Уточнение:** Обычно передается не файл, а его хэш. КриптоПРО CSP работает с хэшем документа:
```cpp
// Вместо передачи всего файла
HCRYPTHASH hHash;
CryptCreateHash(hProv, CALG_GR3411, 0, 0, &hHash);
CryptHashData(hHash, pbDocumentData, dwDocumentSize, 0);
// Передается hHash для подписания
```

### Пункт 3: "КриптоПро CSP: Формирование CADES-BES"
**Уточнение:** Формирование CAdES-BES включает:
- Подписанный хэш документа
- Сертификат подписанта
- Цепочку сертификатов (опционально)
- Временные метки (опционально)

### Пункт 3a: "Запрос и проверка сертификатов"
**Уточнение:** Проверка цепочки обычно выполняется автоматически КриптоПРО CSP при наличии доверенных корневых сертификатов в хранилище Windows.

### Пункт 4: "КриптоПро CSP: Получение OCSP-ответа и TSP-ответа"
**Корректировка:** Эти операции обычно выполняет толстый клиент СЭД, а не КриптоПРО CSP напрямую:

```cpp
// Толстый клиент СЭД делает OCSP-запрос
OCSPResponse ocsp_response = send_ocsp_request(signer_certificate);

// Толстый клиент СЭД делает TSP-запрос  
TimeStampToken tsp_token = send_tsp_request(signature_hash);
```

### Пункт 5: "Передача сформированного файла-подписи"
**Уточнение:** КриптоПРО CSP возвращает базовую подпись (CAdES-BES), а толстый клиент СЭД формирует окончательный CAdES-XL контейнер.

## Исправленная нумерация алгоритма:

1. **Толстый клиент СЭД:** Получение документа для подписания УКЭП
2. **Толстый клиент СЭД:** Вычисление хэша документа (через КриптоПРО CSP)
3. **КриптоПРО CSP:** Формирование CAdES-BES подписи:
   - 3a. Получение сертификата подписанта с Рутокен
   - 3b. Проверка цепочки доверия через системное хранилище
   - 3c. Подписание хэша закрытым ключом с Рутокен
4. **Толстый клиент СЭД:** Усиление подписи до CAdES-XL:
   - 4a. Получение OCSP-ответа от УЦ Контур
   - 4b. Получение TSP-метки от Тензор
   - 4c. Формирование CAdES-XL контейнера
5. **Толстый клиент СЭД:** Формирование описания ЭД (XML)
6. **Толстый клиент СЭД:** Передача пакета документов в хранилище

## Критическое замечание:

**Самое важное уточнение:** КриптоПРО CSP в основном отвечает за криптографические операции, а толстый клиент СЭД - за orchestration процесса (управление потоком данных, взаимодействие с внешними сервисами, формирование сложных контейнеров).

Ваш алгоритм в целом правильный, но требует перераспределения ответственности между компонентами.