Меня там слегка перекоробило от того что топикстартер подписывает хэш - зачет конечно по знанию RAW подписи, вот только есть разница сколько раз хэш вычислять в cades, правда? Если подписываются атрибуты, то это значит что хэш документа не сам идет на вход CryptSignHash, а включается в какой-то вторичный блок вместе с остальными атрибутами и вот уже хэш этого блока идет на CryptSignHash. Догадайтесь что еще там будет в этом блоке... а не данные ли это о поиске сертификата подписавшего? Или где топикстартер нашел в cades-bes доказательства - их там нет! Доказательства и метки доверенного времени появляются как минимум в cades X long type и всех более сложных форматах. Об этом изящно намекнул Андрей, но кажется иронию не распознали.

Про пропиетарный формат это Вы конечно глобально замахнулись, но этого собственно не нужно. Поясню свою мысль, на основе которой я отвечал топикстартеру. Что имел ввиду он - пусть сам отвечает, я расскажу свое видение. Смысл в том, что внутри своей ИС подпись можно хранить разобранной, а вот когда понадобиться ее передать контрагенту или проверить, то выполняется сборка частей и из ИС выдается полная подпись. Контрагенту просто нет нужды ставить какие-то несертифицированные программки - он имеет дело с собранной подписью общепринятого формата.Да - да. Только вот CAdES-BES разбирать несколько неперспективно (максимум сертификат не включать), формат должен быть посложнее.

По поводу возможности разборки - в подписи cades есть подписанные атрибуты и неподписанные атрибуты. Как правило, подписанные подписаны тем, кто подписывает документ. Их разбирать нельзя - подпись математически нарушится. Также мало смысла отделять метку доверенного времени на подпись - ну она каждый раз новая, никуда больше не пристроить. Неподписанные же атрибуты можете блоками добавлять или удалять, Вашу подпись это математически не нарушит.

НЕподписанные атрибуты, как правило, это что уже имеет подпись из других источников - списки отзыва сертификатов подписаны ключом УЦ, метки доверенного времени - ключом сервера TSP, ответы OCSP - ключом ответчика. Представьте, Вы "штампуете" одной ключевой парой подписи формата cades X long type. 100 документов за сутки, с доказательствами, которые по сути одни и те же, отличие только в моменте времени (ну хэш от этого меняется, но это несущественно).

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

Итак, у нас появился у всех 100 подписей за день одинаковый блок доказательств (плюс метка доверенного времени на доказательства). Тогда почему бы его не хранить отдельно и сэкономить место на 99 таких блоков. Формально конечно этого же можно добиться просто заархивировав файлы подписи (если они не шифруются после подписания). Без манипуляций архивированный размер будет чуть больше, так как время отличается.

Идеи дальше, допустим мы не уверены в сервере TSP и получаем метку от двух серверов. Тогда мы можем доказательства сервера 1 подтвердить меткой сервера 2, и наоборот. Тогда если один из серверов (пусть 2) скомпрометирует ключ и его сертификат будет отозван, мы сможем доказать что метка была сделана до отзыва по метке от сервера 1. Чтобы не остаться с одним сервером, мы вводим сервер 3 вместо сервера 2 и продолжаем взаимные подтверждения. Понятно, что такая "косичка" из доказательств займет очень много времени если ее продолжать несколько лет и ее уже проще хранить отдельно. Ну просто представьте обновлять в каждой подписи сделанной за 10 лет... хотя бы раз в год и 3 месяца на которые выдают сертификаты... думаю есть занятия поинтереснее. Не проще ли обновлять каждый день но только 2-3 доказательства.
(пошел на обед... продолжение возможно следует)

Отредактировано пользователем 27 декабря 2021 г. 8:29:19(UTC)  | Причина: Не указана

two_oceans,
интересует Ваше мнение:

1) подписываем документ XLong1 (при этом до подписания и после с небольшими интервалами проверяем CRL\OCSP, сохраняем).
2) через 10ч после подписания выходит CRL, по которому сертификат уже был отозван до подписания, на момент в п.1)
3) при этом в этот же момент по OCSP статус сертификата - не отозван и успешно проверяется некоторое время
(воздушный зазор, перенос CRL к службе OCSP, например, 10-15 минут)

понятно, что проблема "с действиями в УЦ" (плановая публикация CRL, большой период действия (12ч)).

такой вопрос:
что сильнее OCSP из XLong1 или CRL (юридически\технически)?


p.s.
Случай реальный, все совпадения не случайны.

служба не видит сертификат в CRL (копия, принесенная админом с УЦ) = не в отозванных = выдает статус "действует", подписывает ответ...
Именно это и наблюдается в момент смены CRL каждые 12ч (в примере) - появляется информация, что было отозвано ххх сертификатов за прошедшие 12ч, но некоторое время по OCSP эти сертификаты ещё действующие.

Моё видение - УЦ должен как можно оперативнее выпускать CRL и предоставлять более актуальные статусы по OCSP (это же у некоторых - за доп.плату, включение URL OCSP в сертификат). Какой смысл от OCSP с задержкой в 12ч...

Некоторые УЦ выкладывают обновления CRL раз в час (хотя период действия сутки, например), уже лучше...

У меня требование функционального заказчика в части хранения подписей и документов на 5 лет. Срок истечения сертификата не особо важен (в смысле, что юридически будет сложно создать претензию после того как сертификат истек по периоду действия), т.к. подписываемый документ является важным пару суток с момента подписания, а далее он уже становится устаревшим. По количеству у нас сейчас 2,5 года прошло и мы имеем 46млн документов. По объему это не так много, около 450GB, но напрягает то, что в среднем одна подпись весит 8кб, а данные 2кб, т.е. 4/5 объема - это подписи. Всё это лежит в блобах в постгресе. Весь вопрос зародился из того, что время бэкапа подтгреса стало достаточно большим и эти данные один из самых "жирных" кусков в БД.

Вот пообщавшись с вами подумываю теперь в сторону того, чтобы все подписи старее года выгружать просто на хранение куда-то в виде дерева папок и файлов. Там их можно было бы уже и структурировать по отпечатку ключа, а потом сжимать. Такой подход не сломается если на усовершенствованную будем переходить. Либо думать на переход от полных бэкапов постгрена на инкрементные.

Отредактировано пользователем 27 декабря 2021 г. 13:54:31(UTC)  | Причина: Не указана

Про отличие bes с xLongType в части использования я знаю. В части того как оно там лежит в структуре подписи - нет. Рассуждать про то, что у меня сейчас bes, а должен быть xLongType в этой ветке не хотелось, т.к. есть много специфики самой системы и документов. Если кратко, то проблемы с доказательством нет, а до xLongType еще руки не дошли, но в планах это есть.