добавление цифровой подписи в PDF с видимой меткой времени и полем Reason с помощью ESIG / DSS

Question

Я пытаюсь понять и внедрить решение, основанное на спонсируемом Европейской комиссией проекте Служба цифровой подписи . В настоящее время я преуспел в использовании абстракции, предоставленной приложением DSS-DEMO, упомянутой в вышеупомянутой ссылке github, с помощью клиентского программного обеспечения Nowina NexU. Я хочу подписать цифровой документ в формате PDF со следующей конфигурацией:

• без контейнера
• ПАДЫ подпись
• окутан
• PAdES_BASELINE_LT уровень подписи
• алгоритм дайджеста SHA256

Я хочу, чтобы подпись имела видимую часть, то есть была бы видна на первой странице документа. Это несколько продемонстрировано здесь . Лично мне нужна фактическая отметка времени подписи и имя подписавшего из ее сертификата. В вышеприведенной демонстрации это делается путем предоставления «параметров» функции подписи.

Я также хочу заполнить поле «Причина» подписи - оно впоследствии отображается при просмотре свойств подписи с помощью программы, подобной Adobe Acrobat Reader.

Пока что у меня следующие проблемы, и я не могу найти ни примеров, ни другой информации о них.

1. Если я хочу отобразить метку времени подписи, которую я получу от службы Authority Timestamp, как я получу ее, поскольку связь с сервером меток времени осуществляется во время процесса подписания, т.е. после указания параметров, как я упоминал выше , Я полагаю, что мне нужно покопаться в коде DSS и сделать все шаги, которые я проделал для себя.
2. В настоящее время происходит странная вещь. Похоже, что подписи считаются действительными или, по крайней мере, НЕИЗВЕСТНЫМИ, когда я указываю жестко запрограммированную причину (например, «тест-тест»), или вообще не вижу причину. Когда я заполняю его из результатов чего-то другого, подпись недействительна. Поскольку подобные вещи обычно не происходят волшебством, я, должно быть, делаю что-то ужасно неправильно.

Код организован примерно так: существует REST-связь между двумя компьютерами - сервером и клиентом с установленным NexU. NexU осуществляет всю связь со смарт-картой или любым другим хранилищем сертификатов на клиентском компьютере - он обменивается значением дайджеста и подписанным значением дайджеста с сервером. Есть, среди прочего, две специфические фазы в коде сервера:

• getDataToSign - здесь дайджест рассчитывается по содержанию PDF
• signDocument - здесь происходит фактическое подписание - (вложение подписи в документ, я полагаю?).

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

Моя дата подписания - не логично ли, чтобы она была настолько близка к отметке времени сервера авторизации времени, насколько это возможно? Хорошо, я устанавливаю текущую метку времени моего собственного сервера в момент начала процесса подписи.

Я устанавливаю Reason, используя PAdESSignatureParameters.setReason. Любое полезное понимание приветствуется - спасибо.

Answer 1

1. Я решил странную проблему с полем «Причина» подписи.
2. Кажется, я не вижу, чтобы каким-либо образом Дата подписания отличалась от временной отметки, предоставленной властями времени.

Объяснение следует.

НасколькоВ первом случае это была моя вина.Для уточнения, насколько я понимаю, параметры подписи предоставляются методам DSS два раза с использованием метода SigningService.fillParameters ().

1. в SigningService.getDataToSign (...) и затем
2. в SigningService.signDocument (...)

Это важно сделатьв обоих методах, потому что в первый раз вычисляется хэш / дайджест документа, подлежащего подписанию.Поскольку я выбрал подпись, которая должна быть заключена в оболочку, то есть должна содержаться в документе, который будет подписан, нам нужно сначала применить подпись, а затем вычислить дайджест на основе этого «окончательного» документа.

Насколько я видел в коде DSS (приблизительно), представление загруженного PDF в памяти подписывается, и его дайджест вычисляется во время getDataToSign - но результат отбрасывается.

Во время самого метода signDocument (между тем дайджест отправляется обратно на клиент с установленным NexU и возвращается обратно на сервер с подписью), загруженный PDF снова подписывается, его дайджест вычисляется снова, но этовремя фактического подписанного дайджеста (мы получили от клиента) также применяется к документу - и результат этой операции в памяти отправляется обратно клиенту как подписанный документ PDF.

Что я делал неправильно, так это то, что в первый раз я терял переменную, которую собирался добавить в качестве Причины (она была потеряна где-то в атрибутах модели - я не передавал ее где-то посередине).запросы), в результате чего моя первая карта параметров, переданная в getDataToSign, отличается от второй карты параметров - поэтому вполне логично, что фактический хэш / дайджест документа отличался от дайджеста в сохраненной подписи (поскольку привремя, когда был рассчитан дайджест, который нужно подписать, я не передавал причину).Вот почему, когда я передавал жестко закодированное значение, поскольку оно было жестко закодировано, оно присутствовало при обоих вызовах fillParameters.Это была такая глупая ошибка, я знаю.Я должен был знать это, потому что не было абсолютно ничего о каких-либо трудностях с передачей Reason (или других полей, таких как Location) в Signature.

Кстати, подпись выполняется с помощью Apache PDFBox и постепенно.

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

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

Этобольше нравится - конечно, я открыт для других комментариев и ответов.Спасибо!