Какое ПО использовать для ЭЦП

[rutit]

Подскажите пожалуйста касательно выбора ПО для подписания документов в Лоцмане юридически значимой ЭЦП.
В описании сказано, что "поддержка функционала ЭЦП осуществляется системой «КРИПТОН® Подпись» версия 1.0 (разработчик ООО «Фирма АНКАД»)". Но эта система официально выше Windows XP не поддерживается и непонятно , что с функционированием на х64 платформах.
Какой еще криптопровайдер будет работать с связке с Лоцманом ?

[Danila]

А вы хотите организовать прикрепленную подпись?

Наше мнение по организации этого механизма вышла такая. Вот выдержка из нашего решения по организации выдачи документов на сторону:

Для передачи сторонним организациям достаточно иметь общего поставщика квалифи-цированной ЭЦП. Для этого необходимо в договорах указывать потребность в передаче КД с ЭЦП доверенного лица. Такой механизм возможен в соответствии с п.4.14 ГОСТ 2.051-2013: при организации обмена КД допускается заменять набор ЭЦП, установленный в PDM-системе, одной ЭЦП лица, ответственного за передачу КД. Согласно п.3.1.10 ГОСТ 2.001-2013 возможно создание удостоверяющего листа (согласующего бумажного документа) со списком документов, их реквизитами и подписью ответственного лица, выпустившего данный документ. Согласно п.4.5 ГОСТ 2.102-2013 для передачи дубликата, копии документа достаточно передавать его в электронном виде с ЭЦП лица, изготовившего копию или дубликат. Согласно п.4.15 ГОСТ 2.051-2013 допускается заменять применение ЭЦП выпуском УЛ – сопроводительного бумажного документа согласно ГОСТ 2.001-2013 с собственно-ручными подписями в нем тех, кто выпустил УЛ.

Соответственно для внутреннего документооборота достаточно использовать неквалифицированную подпись со своим центром сертификации. А для внешнего документооборота - использовать любого "провайдера" ЭЦП, с которым работает заказчик.

Стоимость КАЖДОЙ квалифицированной ЭЦП от лицензированного провайдера будет стоить существенных денег, поэтому мы используем свое решение для внутреннего документооборота и только одну квалифицированную подпись будем делать для передачи на сторону. Еще не было потребности с ЭЦП на сторону у нас. Но частичный опыт с этим уже есть. В частности аналогично работают системы бухгалтерские и таможенные.

У нас также существует договор о признании внутренней ЭЦП между несколькими организациями работающими в одной PDM-системе, в частности ВП. Внутренняя ЭЦП организована через сертификаты системы Windows. В Лоцмане эти подписи являются неприсоединенными и хранятся отдельно от самого файла/объекта.

[rutit]

А где  вы в Лоцмане смотрите хеш-сумму конкретного документа? (что-то так и не смог найти)

[rutit]

Поясню свой вопрос.
Если у вас подлинники находятся в электронном виде, то они должны быть подписаны юридически значимой электронной подписью (ЭП).
Если вы согласно ГОСТ 2.001-2013 и ГОСТ 2.051-2013  вместо ЭП используете Удостоверяющий Лист (УЛ), то вам надо в него вписать хеш-сумму каждого электронного документа в базе Лоцмана (ваш архив КД) и естественно в нем же (Лоцмане) вы должны и видеть хеш.

Вот этой возможности я пока не нашел в нем, жду ответ от сапорта.

В Лоцмане эти подписи являются неприсоединенными и хранятся отдельно от самого файла/объекта.

Боюсь, что одно это может уже не соответствовать требованиям ФЗ от 06.04.2011 N 63-ФЗ. Даже простая электронная подпись должна содержаться в электронном документе. И должна быть как минимум реализована проверка  обнаружения факта внесения изменений  в  электронный  документ  после  момента  его подписания (это уже для неквалифицированной усиленной подписи).

_______________________________________________
«Хороший проектировщик всегда помнит,
что за его спиной стоит прокурор» ©

[Danila]

Вам ЭЦП нужна для внутреннего документооборота или для отправки документов на сторону?

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

Рекомендую внимательно изучить документ Федеральный закон об Электронной подписи от 06.04.2011 №63-ФЗ.

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

Статья 6. Условия признания электронных документов, подписанных электронной подписью, равнозначными документам на бумажном носителе, подписанным собственноручной подписью

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

Руководствуясь этим законом, внутренними правилами (стандартами предприятия) и договорами с другими пользователями системы (например, ВП) - мы используем простую подпись, выданную Нашим центром сертификации. Эта подпись на стороне, конечно, иметь юридическую силу не будет. Но внутри наших нескольких организаций, работающих в единой системе - проблем нет.

Для решения проблемы отправки документов на сторону я указал возможные пути ранее, еще раз их разложу по пунктам.
1. Квалифицированная ЭЦП аккредитованного поставщика (например КРИПТО-ПРО) ответственного за выдачу лица на документах, отсылаемых на сторону.
2. УЛ с живыми подписями ВСЕХ согласующих лиц комплекта документов.
3. Живая подпись на самом УЛ человека выпускающего УЛ.

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

Я вас уверяю, что описанный мной механизм работает - и примеры аналогичные нашей системе тоже знаем.

[Danila]

А где  вы в Лоцмане смотрите хеш-сумму конкретного документа? (что-то так и не смог найти)

В базе данных для каждого файла есть соответствующее ему значение CRC.

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

[rutit]

Как раз внимательное прочтение ФЗ и вызвало вопрос о квалифицированной ЭП.

Статья 5. Виды электронных подписей 

- однозначно определяет виды используемых подписей.

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

До сих пор нет ни одного удостоверяющего центра, который бы занимался изготовлением электронной подписи в соответствии с ее видами, установленными данным Законом.

В нашем случае электронный подлинник КД должен быть подписан усиленной подписью (причем как квалифицированная так и неквалифицированная усиленная ЭП выпускаются только аккредитованными УЦ, но в данный момент выпускаются только квалифицированные ЭП).

Статья 6. Условия признания электронных документов, подписанных электронной подписью, равнозначными документам на бумажном носителе, подписанным собственноручной подписью 
...
2. Информация в электронной форме, подписанная простой электронной подписью или неквалифицированной электронной подписью, признается электронным документом, равнозначным документу на бумажном носителе, подписанному собственноручной подписью, в случаях, установленных федеральными законами, принимаемыми в соответствии с ними нормативными правовыми актами или соглашением между участниками электронного взаимодействия. Нормативные правовые акты и соглашения между участниками электронного взаимодействия, устанавливающие случаи признания электронных документов, подписанных неквалифицированной электронной подписью, равнозначными документам на бумажных носителях, подписанным собственноручной подписью, должны предусматривать порядок проверки электронной подписи. Нормативные правовые акты и соглашения между участниками электронного взаимодействия, устанавливающие случаи признания электронных документов, подписанных простой электронной подписью, равнозначными документам на бумажных носителях, подписанным собственноручной подписью, должны соответствовать требованиям статьи 9 настоящего Федерального закона.

- причем это касается не только документов отправляемых наружу, но и внутри   организации.

Для подписания КД  требуется усиленная подпись ( т.к. требуется защитить документ от возможных изменений ),квалифицированная или неквалифицированная - это отделный вопрос, но т.к. неквалифицированных ЭП пока в УЦ не генерируют, то остается вариант только квалифицированной.

[Danila]

А с вас просят усиленную подпись для внутреннего документооборота?

Это организация не из вашего документооборота? Тогда купите одно место для работника и дайте ему эту ЭЦП. Она будет присоединенная, квалифицированная. И купите ее у аккредитованного центра - найти можно.  Там скорее продается ПО + ключ (токен).  На другой стороне достаточно только ПО от этого аккредитованного центра.

Реально мы используем Неквалифицированную ЭЦП для нашего документооборота. И все необходимые ФЗ правила при этом выполняются. Потребностей в усиленной никакой стороной пока не продиктованы. Все будет зависеть от вашего договора по внутреннему документообороту.

В системе Лоцман используется открепленная ЭЦП, то есть на самом файле никаких изменений нет, данные об ЭЦП хранятся в отдельных полях БД. Но наше использование сертификатов Windows, которая поддерживается Лоцманом - это неквалифицированная ЭЦП,  которая удовлетворяет всем потребностям ФЗ. Изменение файла с такой ЭЦП делает подпись некорректной.

Мы сами сформировали корневой сертификат Windows. И далее генерируем сертификаты Windows от корневого сертификата для каждого пользователя.
Для создания таких сертификатов можно использовать простейшую стандартную утилиту makecert. Cуществуют и другие программные решения, которые можно найти в интернете. Все они создают стандартные сертификаты Windows.
Все сертификаты можно увидеть в винде тут: Пуск\Выполнить\certmgr.msc

Кстати, один из минусов системы Лоцман и их системой ЭЦП - это последовательная подпись. То есть каждая следующая ЭЦП подписывает все предыдущие. И изъять стандартными механизмами ранее подписанную ЭЦП невозможно.

[rutit]

Но наше использование сертификатов Windows, которая поддерживается Лоцманом - это неквалифицированная ЭЦП,  которая удовлетворяет всем потребностям ФЗ.

К сожалению это не так. Сертификат Windows согласно ФЗ вообще для таких вещей не годится . Смотрим напр. определения в самом ФЗ:

2) сертификат  ключа  проверки  электронной  подписи  -  электронный  документ  или  документ  на
бумажном носителе, выданные  удостоверяющим  центром  либо  доверенным  лицом  удостоверяющего
центра   и   подтверждающие   принадлежность   ключа    проверки    электронной    подписи    владельцу
сертификата ключа проверки электронной подписи;

7)   удостоверяющий   центр    -    юридическое    лицо    или    индивидуальный    предприниматель,
осуществляющие функции по созданию и выдаче сертификатов ключей проверки электронных подписей,
а также иные функции, предусмотренные настоящим Федеральным законом;

Центр Сертификации Windows не является юридическим лицом или индивидуальным предпринимателем, осуществляющем функции по созданию и выдаче сертификатов ключей проверки электронных подписей, впрочем как и ваша организация тоже (см.ваш ОКВЕД, это отдельный вид деятельности). То что Аскон предлагает Центр Сертификации Windows - так это неправомочно согласно ФЗ.
Сэкономить на ЭЦП не получится .

[Danila]

Центр Сертификации Windows - только инструмент, хранящий сертификаты, а положение об ЭЦП на нашем предприятии (Юридическом лице) определяет мой отдел и меня лично как ответственного за создание, хранение, управление и удаление сертификатов согласно этому документу.

Да, мы используем неквалифицированную ЭЦП. Но у нас есть все инструменты, документальные разрешения, правила работы и другие регламенты, определяющую нашу работу с ЭЦП в корпоративной системе Лоцман, при этом сторонние организации, работающие в этой же системе признают наше право на управление всеми регламентами ЭЦП.

[rutit]

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

[Danila]

1) электронная подпись - информация в электронной форме, которая присоединена к другой информации в электронной форме (подписываемой информации) или иным образом связана с такой информацией и которая используется для определения лица, подписывающего информацию;

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

2) сертификат ключа проверки электронной подписи - электронный документ или документ на бумажном носителе, выданные удостоверяющим центром либо доверенным лицом удостоверяющего центра и подтверждающие принадлежность ключа проверки электронной подписи владельцу сертификата ключа проверки электронной подписи;

У нас в организации наше подразделение и есть удостоверяющий центр. Что закреплено соответствующим документом (положение об ЭЦП и Удостоверяющем центре на предприятии).

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

]3. Неквалифицированной электронной подписью является электронная подпись, которая:

1) получена в результате криптографического преобразования информации с использованием ключа электронной подписи;

2) позволяет определить лицо, подписавшее электронный документ;

3) позволяет обнаружить факт внесения изменений в электронный документ после момента его подписания;

4) создается с использованием средств электронной подписи.

У нас НЕКВАЛИФИЦИРОВАННАЯ ЭЦП.

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

У нас есть и все средства управления ЭЦП и корневой сертификат - сертификат ключа проверки.

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

Всем требованиям удовлетворяем, договора есть, положение об ЭЦП и удостоверяющем центре на предприятии есть. Документооборот с нашей ЭЦП в нашей системе - юридически правомерен.

Статья 12. Средства электронной подписи
1. Для создания и проверки электронной подписи, создания ключа электронной подписи и ключа проверки электронной подписи должны использоваться средства электронной подписи, которые:
1) позволяют установить факт изменения подписанного электронного документа после момента его подписания;
2) обеспечивают практическую невозможность вычисления ключа электронной подписи из электронной подписи или из ключа ее проверки.
2. При создании электронной подписи средства электронной подписи должны:
1) показывать лицу, подписывающему электронный документ, содержание информации, которую он подписывает;
2) создавать электронную подпись только после подтверждения лицом, подписывающим электронный документ, операции по созданию электронной подписи;
3) однозначно показывать, что электронная подпись создана.
3. При проверке электронной подписи средства электронной подписи должны:
1) показывать содержание электронного документа, подписанного электронной подписью;
2) показывать информацию о внесении изменений в подписанный электронной подписью электронный документ;
3) указывать на лицо, с использованием ключа электронной подписи которого подписаны электронные документы.

Все механизмы реализованы.

Статья 13. Удостоверяющий центр

Все механизмы этой статьи реализованы.

Статья 14. Сертификат ключа проверки электронной подписи

Реализован корневой сертификат проверки, соответствующий этой статье.

У нас НЕ Аккредитованный удостоверяющий центр. И нам это не надо. Для внутреннего документооборота достаточно ОРГАНИЗОВАТЬ свой.
И соответственно НЕКВАЛИФИЦИРОВАННАЯ ЭЦП.

Все эти механизмы позволяют реализовать сертификаты Windows.

[Chaa]

В базе данных для каждого файла есть соответствующее ему значение CRC.

CRC криптографически не стойкое (т.е. для любого файла легко можно сделать любое значение CRC), и в ЭЦП не применяется.

Для объектов хэш рассчитывается намного сложнее, учитывая связи, атрибуты и т.д.  там не все так очевидно.

В API есть функция GetObject, которая посчитает хзш объекта для вас.

[Danila]

CRC криптографически не стойкое (т.е. для любого файла легко можно сделать любое значение CRC), и в ЭЦП не применяется.
В API есть функция GetObject, которая посчитает хзш объекта для вас.

Согласен, сказал криво, не верно сформулировал то, что хотел.

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

Но подпись объекта как я сказал - у "Лоцманистов" ну оооочень кривая)))) Из-за недоопциональности и недологики) Но именно только подпись объекта. С подписью файла - проблем нет, за исключением того, что каждая следующая подпись подписывает все предыдущие.

[Chaa]

С подписью файла - проблем нет, за исключением того, что каждая следующая подпись подписывает все предыдущие.

У меня вот и с подписью файлов как-то не задалось.
Подпись файла можно сохранить отдельно. А есть ли способ проверить ЭЦП файла без Лоцмана, средствами Windows или еще как-то?

[Danila]

У меня вот и с подписью файлов как-то не задалось.
Подпись файла можно сохранить отдельно. А есть ли способ проверить ЭЦП файла без Лоцмана, средствами Windows или еще как-то?

Без Лоцмана - никак, эта подпись отсоединенная и хранится не в таблице файлов, а в таблице подписей. Определить ЭЦП файла вне своей системы невозможно.

Это, конечно, если вы не используете другого поставщика подписей, который присоединяет ЭЦП к файлу.
И файл с такой подписью уже может закладываться в Лоцман или другую систему, и можно средствами этого поставщика для этого файла всегда определить наличие подписей.

Но это будет не так то просто организовать. Надо не забывать, что тогда необходимы права на изменение файла, чтобы к нему присоединять ЭЦП. Что логикой системы не всегда допустимо. Или же организовывать свое решение или предложенное Асконом.

Такое используется чаще при отправке на сторону. И как раз вот тогда и нужна Квалифицированная ЭЦП.

[Danila]

Кстати, про порядок использования ЭЦП на предприятии и между организациями вещает ГОСТ 2.051.
Там можно найти много полезной информации.

[rutit]

Там же как раз написано, что ЭП формируетя по ГОСТ 34.10-2012 , а функция хеширования вычисляется по ГОСТ 34.11-2012. 
Этот механизм реализуется ТОЛЬКО сертифицированными программами-криптопровайдерами ( производители этих программ в этом году все дружно переходят на новый ГОСТ ), подпись только встроенными средствами Windows CriptoAPI не соответствует ни текущему ни предыдущему ГОСТам и не сертифицировано ФСБ и не может применяться для подписи электронных документов.
И мы снова вернулись к покупке ПО и усиленных ключей (хоть квалифицированных, хоть неквалифицированных).

[Danila]

Там же как раз написано, что ЭП формируетя по ГОСТ 34.10-2012 , а функция хеширования вычисляется по ГОСТ 34.11-2012. 
Этот механизм реализуется ТОЛЬКО сертифицированными программами-криптопровайдерами ( производители этих программ в этом году все дружно переходят на новый ГОСТ ), подпись только встроенными средствами Windows CriptoAPI не соответствует ни текущему ни предыдущему ГОСТам и не сертифицировано ФСБ и не может применяться для подписи электронных документов.
И мы снова вернулись к покупке ПО и усиленных ключей (хоть квалифицированных, хоть неквалифицированных).

В чем-то, возможно, вы и правы. Я не буду спорить далее. Я просто приведу те, доводы, согласно которым наше Военное представительство и АР МАК никаких претензий по электронному документообороту нам не выдало.

Мы основывались на следующие пункты при принятии решения.

2.051 4.3 ЭП - неотъемлемая часть реквизитной части ДЭ, предназначенная для удостоверения и подтверждения его подлинности и целостности.
При использовании документа за пределами корпоративной информационной системы (системы документооборота организации) следует использовать квалифицированную ЭП. В документообороте внутри организации допускается применять простую или неквалифицированную ЭП [5].

4.13 Использование конкретных алгоритмов выработки ЭП устанавливает организация в зависимости от наличия конкретного информационного, программного и организационного обеспечения.

ФЗ №063
Статья 4. Принципы использования электронной подписи
Принципами использования электронной подписи являются:
1) право участников электронного взаимодействия использовать электронную подпись любого вида по своему усмотрению, если требование об использовании конкретного вида электронной подписи в соответствии с целями ее использования не предусмотрено федеральными законами или принимаемыми в соответствии с ними нормативными правовыми актами либо соглашением между участниками электронного взаимодействия;
2) возможность использования участниками электронного взаимодействия по своему усмотрению любой информационной технологии и (или) технических средств, позволяющих выполнить требования настоящего Федерального закона применительно к использованию конкретных видов электронных подписей;

ГОСТ Р 34.11-2012
1 Область применения
...
Стандарт рекомендуется использовать при создании, эксплуатации и модернизации систем обработки информации различного назначения.

Проверяющие органы были удовлетворены предоставленными техническими и организационными решениями, с учетом того, что CryptoApi реализует через стандартного провайдера похожие алгоритмы с асимметричными и симметричными ключами, то есть позволяет шифровать и расшифровывать данные, а также работать с электронными сертификатами. ГОСТ Р 34.11-2012 по алгоритму формирования хэша несет как бы рекомендательный характер. А ГОСТ Р 34.10-2012 - не описывает сам алгоритм, а только общую логику. Которой в целом CryptoAPI соответствует (По крайней мере мы в этом убедили всех, кого надо). Наверно, проверяющие не стали "буквоедами" в этой части и допустили использование нам этого механизма.

На момент когда мы начинали это все  в 2009 году - иных решений  практически не существовало. Хотя и до сих пор все проверяющие органы спокойно относятся к нашей системе ЭЦП.

Чисто теоретически вы натолкнули снова на мысль к тому, чтобы вернуться к решению этой задачи и поискать официальные библиотеки с АПИ-функционалом, поддерживающим именно этот ГОСТ Р 34.11-2012 по реализации алгоритма создания хэша для ЭЦП. Фактически просто в используемых механизмах необходимо вместо стандартного провайдера Microsoft Base Cryptographic Provider поставить такого, который удовлетворяет всем требованиям: PROV_GOST_2001_DH.  Такие вещи, конечно, реализованы за денежки у сертифицированных производителей. Но возможно, достаточно будет одного токена на организацию такого решения, если все действия с подписью и т.д. производить на сервере.

[СергейТ]

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

Это точно? где об можно узнать поподробней?

Судя по тому, что встроенные в Лоцман механизмы подписи работают только с файлами xps, то больше похоже на первый вариант.
Если бы подпись была отделяемой, то не должно быть ограничений на подписание файлов pdf и jpg.