Блог

вот! Я использую pdfbox 1.8.11 для создания подписи pdf, я мог бы создать подпись с поддержкой LTV со встроенным словарем DSS. Теперь проблема заключается в проверке сертификата при наличии нескольких подписей.

Согласно спецификации PDF 2.0 LTV и PAdES LTV, разрешено добавлять VRI для каждой подписи, чтобы можно было проверять связанные данные отзыва для каждой конкретной подписи.

Есть идеи, как добавить словарь VRI для подписи? Поскольку ключом для VRI является хэш в кодировке a base-16, это означает, что сначала мне нужно иметь подпись. Насколько я знаю (надеюсь, я ошибался), подпись создается, когда PDF с информацией, связанной с подписью, сохраняется в выходной поток. ( PDDocument.saveIncremental(ins, outs) )

============================================================

более подробно:

Я столкнулся с этой проблемой, когда я хочу проверить подпись по данным DSS в соответствии со спецификацией PAdES LTV и PDF 2.0 LTV. В первую очередь следует обратить внимание на спецификацию формата PDF 2.0 LTV.

Если я правильно понимаю:

1. DSS содержит данные отзыва для всех подписей, которые у нас есть в подписанном PDF.

Ситуация, с которой я столкнулся: Предположим: есть два пользователя, пользователь A и Пользователь B, их сертификаты выданы одними и теми же CA: s. (Я думаю, это довольно распространенное явление. )

1. Пользователь A подписал документ с помощью DSS (сертификаты / crls / ocp встроены).
2. Несколько дней спустя пользователь B подписывает документ, подписанный пользователем A, с помощью DSS (сертификаты / crls / ocps). Примечание!: crls идентифицируются по идентификатору эмитента.

Этап проверки подписи:

Когда я хочу перестроить цепочку сертификатов, сверьте сертификат sign с crl и ocsp, особенно когда я хочу проверить, что срок действия crl не истек на момент подписания документа, мне нужно убедиться, что я использую правильную версию crl.

Для меня это означает, что я должен проверить, правильно ли сопоставлены сертификаты / crls / ocsp с подписью. В противном случае проверка больше не является надежной, равно как и бессмысленной.

Следовательно, даже несмотря на то, что последняя спецификация PAdES 103 не рекомендует использовать VRI. Серьезно, я думаю, что это неправильно….

Тогда другая проблема:

Как я прокомментировал ниже, я использую pdfbox для подписи pdf.

1. Если я заранее соберу данные DSS, создайте подпись впоследствии. (Дело в том, что DSS также является частью подписанного контента.)

   • Хорошая вещь: acrobat Reader распознает мою подпись, включен LTV.
   • Плохо то, что в такой ситуации я не могу добавить туда VRI. Ключом для VRI является хэшированное значение подписи.

2. Если я сначала подпишу документ, а затем получу подпись и DSS с помощью VRI, acrobat reader больше не распознает DSS. Моя подпись больше не поддерживает LTV в acrobat Reader. Это проблема, в которой я запутался. Является ли acrobat Reader неправильным при проверке LTV или??

Я считаю это неправильным? Если я что-то понял неправильно, пожалуйста, укажите на это. Заранее спасибо!

Прежде всего, последнему просмотренному мной черновику PDF 2.0 около двух лет. Таким образом, мой ответ лучше основывать на стандартах ETSI, а не на этом черновике. 😉

Если я правильно понимаю:

1. DSS содержит данные отзыва для всех подписей, которые у нас есть в подписанном PDF.

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

Когда я хочу перестроить цепочку сертификатов, сверьте сертификат sign с crl и ocsp, особенно когда я хочу проверить, что срок действия crl не истек на момент подписания документа, мне нужно убедиться, что я использую правильную версию crl.

Для меня это означает, что я должен проверить, правильно ли сопоставлены сертификаты / crls / ocsp с подписью. В противном случае проверка больше не является надежной, равно как и бессмысленной.

Какова именно ваша цель? Пытаетесь ли вы повторно ввести в действие определенный предыдущий акт проверки? Или вы просто хотите проверить подпись?

В первом случае вам действительно нужно некоторое сопоставление «для проверки этой подписи использовалась следующая информация о связи проверки», предоставленная, например, структурами VRI.

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

Таким образом,

Поэтому, несмотря на то, что последняя спецификация PAdES 103 не рекомендует использовать VRI. Серьезно, я думаю, что это неправильно….

Спецификация PAdES на LTV просто хочет гарантировать, что подписи могут быть проверены, а не то, что они могут быть проверены точно так же, как раньше. Имея в виду эту задачу, это правильно.

Если я заранее собираю данные DSS, создайте подпись впоследствии. (Дело в том, что DSS также является частью подписанного содержимого.)

Хорошая вещь: acrobat Reader распознает мою подпись, включен LTV.

Плохо то, что в такой ситуации я не могу добавить туда VRI. Ключом для VRI является хэшированное значение подписи.

Вы не только не можете, вам фактически не разрешено! Как указано в ETSI EN 319 142-1 V1.1.1:

Любые словари VRI должны располагаться в разделах инкрементного обновления документа. Если словарь подписи, к которому применяется словарь VRI, сам находится в разделе инкрементного обновления (см. Пункт 7.5.6 ISO 32000-1 [1]), обновление VRI должно быть выполнено позже, чем обновление подписи.

Если я сначала подпишу документ, а затем получу подпись и DSS с помощью VRI, acrobat reader больше не распознает DSS. Моя подпись больше не поддерживает LTV в acrobat Reader. Это проблема, в которой я запутался. Является ли acrobat Reader неправильным при проверке LTV или??

Вот где пример файла, показывающий это поведение, мог бы помочь