Подписание с OCSP с помощью iText - PullRequest
0 голосов
/ 30 апреля 2018

Я могу без проблем подписать PDF-документ. Моя логика приложения такова; 1- создать пустое поле для подписи в pdf 2- отправьте хэш-код поля в веб-сервис подписи 3- получить объект подписи 4- встроил этот объект в поле.

Вот мой код Подпись недействительна для файла PDF с iText
Спасибо @mlk, помогли мне в этом.

Но я понимаю, что у меня проблема с отзывом.

Как видно на рисунке, моя подпись не содержит OCSP. а в разделе доверия опция «Сертифицировать документы» не выполнена (красный крестик)

Ответ веб-службы уже содержит crl и ocsp

<sc:RevocationInformation>
 <sc:CRLs>
  <sc:CRL> .... CRL .... </sc:CRL>
 </sc:CRLs>
 <sc:OCSPs>
  <sc:OCSP> ..... ocsp content..... </sc:OCSP>
 </sc:OCSPs>
</sc:RevocationInformation>

Но я использую только объект подписи.

Мой вопрос заключается в том, как я могу встроить CRL и OCSP в pdf.

Как я вижу некоторые примеры, метод SignDetached был использован вместо метода SignDeferred. Если мне нужно использовать метод SignDetached, я должен создать поле в файле PDF. Потому что мне понадобится хэш-код этого поля. Как работает процесс.

Редактировать: Когда я открываю свой тестовый PDF-файл и PDF-файл, подписанный swisscom, я вижу эти окна.

Для швейцарцев

А это мой тест pdf

Как можно видеть, есть разница в валидации. Поэтому я щелкаю поле подписи и подтверждаю, чтобы я получил это окно.

Это то же самое, что и оригинальный подписанный файл swisscom. но мне нужно сделать дополнительную проверку. Чего не хватает в моей подписи, что мне нужно проверить?

Редактировать 2:

Подписано Swisscom http://documents.swisscom.com/product/1000255-Digital_Signing_Service/Documents/Reference_Guide/Reference_Guide-All-in-Signing-Service-en.pdf

и мой подписанный тестовый файл

https://app.box.com/s/ju7xgkxucw0rwif7k3052rx5n8f9omwq

1 Ответ

0 голосов
/ 02 мая 2018

На самом деле у вашего вопроса есть два отдельных аспекта, с одной стороны, вы хотите знать, почему два документа (созданный вами и предоставленный Swisscom) ведут себя по-разному в вашем Adobe Reader, а с другой стороны, вы спрашиваете как встроить CRL и OCSP в pdf .

Различия между подписанными документами

Вопрос версий Adobe Reader

Прежде всего, различное поведение Adobe Reader, которое вы наблюдали для двух документов, имеет место только в старых версиях Adobe Reader, оба файла в Adobe Reader DC проверены немедленно с зелеными галочками.

5.PDF_1_.pdf

Reference_Guide-All-in-Signing-Service-en.pdf

Таким образом, Reader не только больше не ведет себя по-другому, но и подписи из коробки считаются действительными! Привязка доверия получена из утвержденного списка доверия Adobe.

Кроме того, вы можете видеть, что обе подписи считаются «LTV-совместимыми». Таким образом, включена вся информация, необходимая для проверки Adobe Reader, в частности информация об отзыве (CRL и ответы OCSP).

Другая подпись Фильтр значения

Основное различие между двумя сигнатурами заключается в Фильтре подписи PDF,

  • 5.PDF_1_.pdf имеет подпись Фильтр Значение ETSI.RFC3161 и
  • Reference_Guide-All-in-Signing-Service-ru.pdf имеет подпись Фильтр значение Adobe.PPKLite .

Значение Filter ETSI.RFC3161 в подписанном вами файле не имеет смысла: это значение является зарезервированным SubFilter значением для документа отметки времени ! Значение Filter Adobe.PPKLite в файле, подписанном SwissCom, действительно является именем фильтра, это имя обработчика подписи Adobe.

В соответствии со спецификациями PDF ISO 32000-1 и ISO 32000-2:

Имя предпочтительного обработчика подписи для использования при проверке этой подписи. Если запись Prop_Build отсутствует, она также должна быть именем обработчика подписи, который использовался для создания подписи. Если присутствует Prop_Build , его можно использовать для определения имени обработчика, который создал подпись (который обычно совпадает с Filter , но не обязателен). Соответствующий читатель может заменить другой обработчик при проверке подписи, если он поддерживает указанный формат SubFilter . Примеры обработчиков подписи: Adobe.PPKLite , Entrust.PPKEF , CICI.SignIt и VeriSign.PPKVS .

Значение значения Filter со временем уменьшилось. Более ранние версии Adobe Reader (а также версии других средств проверки подписи) обрабатывали подписи только с определенными значениями Filter автоматически, а в настоящее время значение Filter по существу игнорируется.

Таким образом, версия Adobe Reader, с которой вы наблюдали, что отличающееся поведение, должна быть более старой версией, которая все еще обрабатывает только подписи с известными фильтрами немедленно и такими с неизвестными фильтрами только по требованию.

Вы ссылаетесь на этот вопрос для вашего исходного кода, который, в частности, содержит

IExternalSignatureContainer external = new ExternalBlankSignatureContainer(PdfName.ADOBE_PPKLITE, PdfName.ADBE_PKCS7_DETACHED);
PdfSignature external2 = new PdfSignature(PdfName.ADOBE_PPKLITE, PdfName.ADBE_PKCS7_DETACHED);//ADBE_PKCS7_SHA1);
//as pdf name I tried also PdfName.ETSI_RFC3161

Судя по всему, вы создали свою подпись, используя код из попытки, для которой вы пытались также PdfName.ETSI_RFC3161 ...

Встраивание CRL и OCSP в pdf

Этот вопрос в вашем контексте фактически стал спорным, поскольку ваша подпись распознается как LTV включена , то есть, в частности, включает в себя всю информацию об аннулировании (CRL, ответы OCSP), необходимую для средства проверки подписи Adobe Читатель. Таким образом, я расскажу об этом только в общих чертах.

По сути, есть два места для размещения информации об аннулировании в PDF:

1114 * * специальный, определенный Adobe атрибут в контейнере для подписи или специальный, определенный ETSI словарь в последующем инкрементном обновлении.

Атрибут Информация отзыва по adbe

Данный атрибут уже указан в спецификации PDF ISO 32000-1:

Объект PKCS # 7 должен содержать следующее:

[...]

  • Информация об аннулировании как подписанный атрибут (PDF 1.6): Этот атрибут может включать в себя всю информацию об аннулировании, необходимую для выполнения проверок аннулирования сертификата подписавшего и его сертификатов эмитента. Поскольку информация об аннулировании является подписанным атрибутом, ее необходимо получить до вычисления цифровой подписи.

[...]

Атрибут Информация отзыва по adbe:

adbe-revocationInfoArchival OBJECT IDENTIFIER ::=
                              { adbe(1.2.840.113583) acrobat(1) security(1) 8 }

Значение атрибута информации об отзыве может включать любой из следующих типов данных:

  • Списки отзыва сертификатов (CRL), описанные в RFC 3280 (см. Библиографию): CRL обычно большие и поэтому не должны быть встроены в объект PKCS # 7.

  • Ответы по протоколу состояния онлайн-сертификата (OCSP), описанные в RFC 2560, X.509. Протокол статуса сертификата в сети Интернет с открытым ключом - OCSP (см. Библиографию): как правило, они небольшие и имеют постоянный размер и должны быть тип данных, включенный в объект PKCS # 7.

  • Пользовательская информация об аннулировании: формат не предписан этой спецификацией, за исключением того, что он должен быть закодирован как строка октета. Приложение должно иметь возможность определять тип данных, содержащихся в STRING OCTET, просматривая связанный ИДЕНТИФИКАТОР ОБЪЕКТА.

Значение атрибута Информация отзыва об adbe имеет тип ASN.1 RevocationInfoArchival:

   RevocationInfoArchival ::= SEQUENCE {
     crl [0] EXPLICIT SEQUENCE of CRLs, OPTIONAL
     ocsp [1] EXPLICIT SEQUENCE of OCSP Responses, OPTIONAL
     otherRevInfo [2] EXPLICIT SEQUENCE of OtherRevInfo, OPTIONAL
   }
   OtherRevInfo ::= SEQUENCE {
     Type OBJECT IDENTIFIER
     Value OCTET STRING
   }

Этот способ встраивания был известен еще до появления первой спецификации ISO PDF ISO 32000-1 и, следовательно, должен использоваться для большинства валидаторов. Недостатком является то, что этот атрибут подписан, поэтому информация должна быть получена раньше. Это не всегда возможно.

Кстати, именно так эта информация встраивается в ваш документ, SwissCom встраивает этот атрибут в контейнер для подписи.

Словарь ETSI Document Security Store (DSS)

Этот словарь и его обработка определяются ETSI, например, в ETSI EN 319 142-1 и был скопирован в обновление спецификации PDF ISO 32000-2:

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

Словарь DSS , если таковой имеется, должен содержать информацию, относящуюся к проверке, только для документа и отметок времени подписи, представленные в формате PKCS # 7 и CMS (и его производных) или для подписей XAdES подписей форм динамический XFA [i.7].

ПРИМЕЧАНИЕ: См. ETSI EN 319 142-2 [i.11] для определения сигнатур XAdES форм, подписывающих динамический XFA.

Записи в словаре DSS

Тип Имя (Необязательно) Для хранилища безопасности документов должно быть DSS словарь.

VRI Словарь (Необязательно) Этот словарь содержит подпись VRI словари в документ. Ключ каждой записи в этом словаре дайджест подписи SHA1 в кодировке base-16 (заглавные буквы) для который применяется, и значение словаря VRI подписи который содержит информацию, связанную с проверкой для этого подпись. (См. Дополнительные требования a, b, c.).

Certs Array (Необязательно) Массив косвенных ссылок на потоки, каждый содержащий один сертификат X.509 с кодировкой DER ( определено в IETF RFC 5280 [4]). Этот массив содержит сертификаты которые могут быть использованы при проверке любых подписей в документ.

OCSP Массив (Необязательно) Массив косвенных ссылок на потоки, каждый содержащий DER-кодированный статус онлайн-сертификата Ответ протокола (OCSP) (который должен быть таким, как определено в IETF RFC 6960 [5]). Этот массив содержит OCSP, которые можно использовать в проверка любых подписей в документе.

CRL Массив (Необязательно) Массив косвенных ссылок на потоки, каждый содержащий DER-кодированный список отзыва сертификатов (CRL) (это должно быть определено в IETF RFC 5280 [4]). Этот массив содержит CRL, которые могут быть использованы при проверке любого подписи в документе.

Поскольку этот способ встраивания не был известен в первой спецификации ISO PDF ISO 32000-1, ряд валидаторов могут не знать, как обращаться с этой информацией. Преимущество состоит в том, что этот словарь не нужно подписывать, поэтому информацию можно получить после подписания. Это может быть необходимо в некоторых случаях использования.

...