Скажите, пожалуйста, есть ли возможность обойти это?
Если вы хотите, чтобы ваши подписи были совместимы , то нет никакого способа обойти это.
Я прочитал эту статьюи понял, что каждая предыдущая цифровая подпись (даже отсоединенная) включена в SignedContent следующей подписи
Этот ответ по-прежнему представляет текущую ситуацию. Во всяком случае, это было подтверждено более новыми спецификациями, например, спецификации PAdES, упомянутые в этом ответе, были просто «техническими спецификациями» (ETSI TS 102 778), и в настоящее время существуют фактические нормы (ETSI EN 319 142), которые также требуют подписи в формате PDF дляподписать все в своей ревизии, кроме собственного контейнера подписи. Кроме того, был опубликован ISO 32000-2, в котором все еще есть это требование для его совместимых сигнатур и, кроме того, в него включена сокращенная копия спецификации PAdES.
Здесь вы подчеркиваете, что даже «отсоединены». «Отдельно» в данном контексте относится только к структуре контейнера CMS, который встроен в PDF;в частности, не означает, что подпись более отделена от PDF или чего-либо подобного.
Если вы нене должны быть совместимыми , хотя, есть некоторые варианты, здесь два из них, которые все еще достаточно близки к взаимодействующим сигнатурам:
Вы можете игнорировать требование, чтоПодпись pdf должна подписывать все в своей редакции, кроме собственного контейнера подписи.
Например, вы можете подготовить несколько полей подписи и словарей в одной новой редакции документа и установить диапазон байтов подписи каждой подписи, чтобы исключить заполнители все этих подписей.
вы можете игнорировать требование, чтобы в контейнере подписи CMS был только один SignerInfo, и поместить SignerInfos от разных подписывающих сторон в одну подпись. контейнер в поле единой подписи.
Общие средства проверки подписи PDF будут,
в случае подписей, созданных, как описано в первом варианте, не положительнопроверить, по крайней мере, большинство из них,
либо потому, что их код запрограммирован только для двух диапазонов байтов со знаком (то есть для одного пробела), и поэтому используются только первые два диапазона, что приводит кневерный хеш документа;
или потому что они явно требуют, чтобы подпись охватывала всю ее ревизию минус один заполнитель для контейнера подписи проверяемого поля подписи;число валидаторов такого рода, безусловно, возросло после публикации магистерской диссертации «Безопасность PDF-подписей» Карстена Мейера цу Селхаузена в Рурском университете в Бохуме, см. этот вопрос .
в случае подписей, созданных, как описано в последнем варианте, , по-видимому, положительно проверяет, по крайней мере, многие из них, пока вы не посмотрите на результат проверки вдетализируйте и поймите, что они проверили только один из SignerInfos и проигнорировали остальные.
Например, в случае двух SignerInfos Adobe Reader проверяет второй (я предполагаю, что он всегда проверяет last один) и eSig DSS проверяет первый, и ни один из них в настоящее время не указывает в результате проверки, что может присутствовать другой SignerInfo.
Крупная шведская охранная компания,например, реализует второй вариант в своем программном обеспечении;в своем домашнем пивоваренном формате PDF / CAdES-A он вставляет контейнеры CAdES-A в качестве контейнера CMS в PDF-файлы и допускает в них несколько SignerInfos. Следовательно, очевидно, что его собственное программное обеспечение будет распознавать и проверять все SignerInfos. Тем не менее, это решение для домашнего приготовления и не совместимо.