Есть ли причина использовать CAdES поверх XAdES для расширенных электронных подписей? - PullRequest
4 голосов
/ 19 июня 2011

Мне не удалось найти причину того, почему кто-то предпочел бы внедрить программное решение с электронной подписью, ориентированное на CAdES, вместо ориентированного на XAdES.

В интернете гораздо больше открытых библиотек, примеров реализации и примеров XAdES, но, тем не менее, я не верю, что именно поэтому люди решают использовать XAdES вместо CAdES.

Это потому, что XAdES ориентирован на XML, а разработчики программного обеспечения, как правило, любят все, что связано с XML? Есть ли сценарий, в котором CAdES является просто лучшим вариантом для использования поверх XAdES?

Для справки:

  • CAdES - это CMS / PKCS # 7 в расширенной форме (поддерживает отметку времени)
  • XAdES - это XML-DSig в расширенной форме (поддерживает отметку времени)

Ответы [ 2 ]

5 голосов
/ 05 июля 2011

Одним из преимуществ CAdES является то, что он обычно вызывает меньше проблем с совместимостью, поскольку стандарт XML-DSig допускает множество вариантов, включая XSLT, XPointer Framework, канонизацию XML и многое другое.CAdES будет менее требовательным, если иметь дело только со строго кодированными DER-сигнатурами (картина меняется, когда вам нужно работать с кодировками BER).

CAdES превосходит XAdES в сценариях, где создание «прикрепленных» сигнатур на больших порциях данныхнеобходимо (вы хотите, чтобы результатом был один фрагмент данных, который содержит как исходные данные, так и подпись).Эквивалентом присоединенной подписи CAdES (исходные входные данные хранятся в элементе EncapContentInfo структуры CMS) является Enveloping Signature .Если вам необходимо создать такую ​​подпись, существует высокая вероятность того, что вы столкнетесь с проблемами при работе с большими входными данными, если ваша реализация XAdES основана на DOM (те, о которых я знаю) - ваша машина в конечном итоге выйдет из строяпамяти.

Производительность была бы еще одним аргументом в пользу CAdES.Вычисление дайджеста сообщения CAdES обычно выполняется непосредственно на необработанных байтах входных данных, подписи XML, которые вычисляются в документах XML, включают в себя много накладных расходов, таких как оценка выражений XPath, преобразования XSLT, кодирование / декодирование Base64 и канонизация,и, возможно, несколько элементов Transform.

Если вы создаете систему архивирования для долгосрочной проверки подписей, в которой хранится много подписей, CAdES является предпочтительным форматом из-за его компактности по сравнению с текстовым форматом XAdES.

3 голосов
/ 09 сентября 2018

CADES поверх XAdES:

  • Меньше опций для реализации
  • (Способ) Легче проверять
  • Работает с любыми данными, включая XML
  • Легче для ASiC
  • Windows API более надежен для его построения
  • Нет необходимости в сложной канонизации
  • Может использоваться с S / MIME
  • Позволяетнесколько подписей
  • Используется в PAdES
  • Быстрее

XAdES через CAdES:

  • Подписанные XML-файлы все еще могут быть прочитаныприложения, не поддерживающие шифрование
  • Несколько элементов могут быть подписаны за один проход
  • Вам не нужен компилятор ASN.1

Единственная причина, по которой я бы использовал XAdES, этопервое, личное мнение.Но затем незнакомое приложение может изменить файл, сделав подпись недействительной.Кроме того, использование типов * AdES означает, что вы хотите быть совместимым с правилами ЕС, и это обычно означает документы PDF, подписанные с помощью PAdES.Когда вы просто хотите подписать электронное письмо, CAdES не очень полезен, так как он не проверяется большинством клиентов S / MIME.AdES - это европейские законы, так что не так много американских приложений знают об этом.

Кроме того, эти формы не просто старые с временными метками, есть много дополнений.См. https://www.w3.org/TR/XAdES/ и https://www.secureblackbox.com/kb/articles/8-CAdES.rst.

Я также реализовал их в C ++ для Windows, отметьте здесь и здесь и здесь для моего полного набора инструментов.

...