Не все сертификаты и списки отозванных сертификатов находятся в подписи CAdES-A v3.
Проверка подписи CAdES-A v3 сторонними средствами выполняется с ошибкой.
Подпись "КриптоПро CAdES-A v3.p7s" ( CAdES-Av3.zip (13kb) загружен 1 раз(а). прилагается) сформирована с помощью утилиты КриптоПро cryptcp.x64.exe, версии 5.0.12278.0
Версия КриптоПро: 5.0.13300 КС1

Точнее, цепочка сертификатов для сертификата TCP службы "Тестовый оператор TSP" отсутствует в подписи. Подпись содержит метки времени signature-time-stamp (1.2.840.113549.1.9.16.2.14) и CAdES-C-time-stamp (1.2.840.113549.1.9.16.2.25), подписанные сертификатом "Тестовый оператор TSP", сертификат издателя которого (вся цепочка вместе со списками отозванных сертификатов) отсутствует в архивной подписи. Эти неподписываемые атрибуты присутствуют в хеш-таблице ats-hash-index-v3 (0.4.0.19122.1.5) архивной метки времени.

Примечание: - отсутствующая цепочка сертификатов находится внутри неподписываемых атрибутов certificate-values и revocation-values меток времени signature-time-stamp и CAdES-C-time-stamp. Но насколько это правильно и стандартизировано искать сертификаты и CRL-и в неподписываемых атрибутах неподписываемого атрибута? Т.е., другими словами, должны ли сторонние инструменты искать там сертификаты и CRL-и?
Возможно, это не правильно и, как минимум, избыточно, поскольку данная информация дублируется в каждой метке времени.

Также, есть рекомендация, чтобы все необходимые данные для построения и проверки цепочки сертификатов находились внутри архивной подписи, в полях SignedData.certificates и SignedData.crls. Вот из спецификации ETSI TS 101 733 V2.2.1 (2013-04), "CMS Advanced Electronic Signatures (CAdES)":
Пункт 6.4.3, "archive-time-stamp-v3 Attribute":
If none of ATSv2, an earlier form of archive time-stamp or a long-term-validation attribute are already present, then the new validation material shall be included within the root SignedData.certificates, or SignedData.crls as applicable.
С чем может быть связано, что вы не следуете данной рекомендации?

Добрый день!
К сожалению, я пропустила ваше сообщение.
Давайте разберёмся - прежде всего в стандарте нет такого понятия "подпись CAdES-A v3". Есть описание формата CAdES-A with archive-time-stamp (ATSv3) attribute в версии стандарта 2013 года.
https://www.etsi.org/del...60/ts_101733v020201p.pdf

В этой же версии стандарта есть и рекомендации по размещению доказательств. См. например раздел 6.3.4 revocation-values Attribute Definition :
"This attribute may include the values of revocation data including CRLs and OCSPs for any TSUs that have provided
the time-stamp tokens, if these certificates are not already included in the TSTs as part of the TSUs signatures. In this
case, the unsigned attribute shall be added to the signedData of the relevant time-stamp token. "

Версия v3 относится к неподписанным атрибутам, ats-hash-index-v3 и archive-time-stamp-v3. Оба этих атрибута не накладывают никаких ограничений на месторасположение доказательств для цепочки штампа времени.

А вот форматов подписи CAdES-A в актуальной версии стандарта представлено 2: это CAdES-B-LTA (baseline profile) и CAdES-E-A (extended):
https://www.etsi.org/del.../en_31912201v010301p.pdf Building blocks and CAdES baseline signatures
https://www.etsi.org/del.../en_31912202v010101p.pdf Extended CAdES signatures

Среди этих форматов нет лучшего или худшего, применение каждого из них зависит от требований конкретной системы. При этом "поверх" подписи CAdES-X Long Type 1 может быть сделана только подпись CAdES-E-A. Для подписи CAdES-B-LTA пришлось бы удалять неподписанные атрибуты, что неприемлемо. А подпись формата CAdES-X Long Type 1 - это самый распространённый на настоящий момент формат подписи долговременного хранения. Именно поэтому нами был реализован формат CAdES-E-A как самый востребованный.

Требования по хранению доказательств и сертификатов _только_ в коллекциях SignedData.Certificates и SignedData.CRLs относятся к формату подписи CAdES-B-LTA, который запрещает включать в подпись неподписанные атрибуты revocation-values и certificate-values.

Приведённая вами рекомендация относится только ко вновь добавляемым в подпись сертификатам и доказательствам для цепочки сертификата ключа подписи. Но для сертификата ключа подписи к моменту получения архивного штампа все доказательства уже собраны в формате CAdES-X Long Type 1 и никакие новые доказательства не добавляются.

Елена, спасибо большое за ответ! У меня есть пару комментариев только.


Не только цепочки сертификата ключа подписи, но и сертификатов TSP и OCSP служб. Вот из спецификации (пункт 6.4.3, archive-time-stamp-v3 Attribute):
Before incorporating a new archive-time-stamp-v3 attribute, the SignedData shall be extended to include any validation data, not already present, which is required for validating the signature being archive time-stamped. Validation data may include certificates, CRLs, OCSP responses, as required to validate any signed object within the signature including the existing signature, time-stamps, OCSP response and certificates.


Обычно, получаемые штампы имеют формат CAdES-BES, а не CAdES-X Long Type 1, поэтому доказательства отсутствуют. В том числе и при получении архивного штампа.
Это надо ещё и поискать такой TSP сервис, чтобы он предоставлял штамп метки времени со всеми доказательствами.