Суммируя:
Могу ли я создать подписываемый дайджест, не зная заранее чей-то сертификат?
В случае подфильтра ETSI.CAdES.detached или adbe.pkcs7.detached вы можете создать дайджест документа , не зная заранее чей-либо сертификат. .
Однако обычно вам необходимо знать сертификат подписавшего перед началом создания контейнера подписи CMS для встраивания в PDF.
В деталях:
(Остерегайтесь, следующее несколько упрощено.)
Я могу (возможно) создать дайджест, зарезервировать место для записи / Contents и позже присоединить этот объект PKCS # 7.
Если вы сначала зарезервируете пространство, а затем создадите дайджест, это действительно так.
Путаница начинается, когда я читаю следующее:
Информация об отзыве - это подписанный атрибут, что означает, что программное обеспечение для подписи должно фиксировать информацию об отзыве перед подписанием. Аналогичное требование применяется к цепочке сертификатов. Программное обеспечение для подписи должно захватить и проверить цепочку сертификата перед подписанием.
Итак, я не совсем понимаю: по-видимому, запись / Contents (содержащая сертификат и подписанный дайджест) не переваривается, но цепочка сертификатов является подписанным атрибутом (и, следовательно, ее нужно переваривать?).
Я был бы признателен, если бы кто-нибудь дополнительно уточнил, что именно переваривается, и, возможно, лучше объяснил бы мне подписанные атрибуты.
Главный факт, о котором следует знать, заключается в том, что в случае контейнеров подписи PKCS # 7 / CMS подписание обычно включает не просто вычисление одного хэша, но как минимум двух !
Первый хэш, хэш документа, действительно рассчитывается для всего файла, включая словарь подписи, но исключая само значение подписи (запись Содержание) (вы можете захотеть прочтите этот ответ для получения дополнительной информации).
Но это не хеш, который сразу используется при применении алгоритма подписи.
Во время генерации контейнера подписи PKCS # 7 / CMS (если только в его самой примитивной форме) вы создаете структуру, называемую подписанными атрибутами.
Вы заполняете эту структуру несколькими атрибутами (парами имя-значение), среди которых уже вычисленный хэш документа, а также другие, например информация об отзыве в стиле Adobe, о которой вы читали.
Когда вы закончите создание этой структуры, вы хешируете эту структуру и генерируете для нее подпись.
Затем вы можете собрать контейнер подписи PKCS # 7 / CMS, используя эти подписанные атрибуты, подпись и некоторую дополнительную информацию, не подписанную этой подписью, например сертификаты, отметки времени подписи, ...
Дополнительные сведения о контейнере подписи см. В этом ответе.
Наконец, вы вставляете этот контейнер подписи в зарезервированное место в PDF.
Главный вопрос, на который я хочу ответить: могу ли я создать подписываемый дайджест, не зная заранее чей-то сертификат? (Я работаю с отдельной подписью pkcs7)
В случае подфильтра ETSI.CAdES.detached или adbe.pkcs7.detached вы можете создать дайджест документа , не зная заранее чей-либо сертификат. .
Однако в зависимости от профиля подписи CMS вам обычно необходимо знать сертификат подписывающего лица до начала создания контейнера подписи, поскольку многие профили требуют наличия подписанного атрибута, ссылающегося на сертификат подписавшего.
Разъяснения:
ОП задал несколько дополнительных вопросов в комментарии:
1. Один из подписанных атрибутов - это хэш документа (без / contents), так что, если я правильно понимаю, это беззнаковый хеш?
Поскольку подписанные атрибуты в конечном итоге хешируются и подписываются, этот хэш документа в нем не сразу, прямо подписывается но он косвенно подписывается как часть этого структура атрибутов. Так что я бы не назвал это беззнаковым ...
- В конце концов, когда пользователь действительно генерирует подпись, он подписывает хеш объекта PKCS # 7?
Нет, хэш структуры подписанных атрибутов, который является только частью объекта PKCS # 7, а не всем. Есть несколько частей объекта PKCS # 7 / CMS без знака.
- Есть ли у записи / Contents объект PKCS # 7, который действительно доступен для чтения? (Чтобы извлечь сертификаты и т. Д. Для проверки)
Запись Contents действительно содержит полноценный объект контейнера подписи PKCS # 7 / CMS в виде двоичной строки. Таким образом, да, вы можете прочитать его (прочитав значение этой двоичной строки) и (если у вас есть код, который знает, как анализировать такой контейнер подписи) извлечь из него информацию.
Однако будьте осторожны, контейнер подписи может не содержать всех данных, необходимых для проверки: например, если вы проверяете с использованием модели проверки цепочки (а не оболочки), вам может потребоваться извлечь время подписи из соответствующей записи словаря подписи PDF.
- При проверке подписи мы просто извлекаем встроенный объект PKCS # 7, пересчитываем дайджест, пересчитываем дайджест объекта PKCS # 7 и сверяем его с подписью, используя сертификат, который мы получаем от объекта PKCS # 7?
Очевидно, вам также необходимо вычислить дайджест диапазонов байтов подписанного PDF-файла и сравнить это значение с подписанным атрибутом, содержащим исходный дайджест документа (вы могли иметь в виду это, пересчитывая дайджест.)
Как упоминалось в ответе на вопрос 3, вам может потребоваться получить дополнительную информацию из PDF-файла для использования при проверке PKCS # 7.
Кроме того, вы говорите сертификат, который мы получаем от объекта PKCS # 7 - имейте в виду, что контейнер подписи PKCS # 7 / CMS может содержать несколько сертификатов. Вы должны найти правильный. Для этого должны использоваться CMS SignerInfo SignerIdentifier и подписанные атрибуты ESS.
Кроме того, вам также необходимо проверить действительность и доверие подписывающего сертификата.
- Есть ли хорошая документация о том, какие есть аутентифицированные атрибуты?
Вы можете начать читать
person
mkl
schedule
25.03.2015
