Я так понимаю PKCS#7, CMS, CAdES'ы и прочее, что бы вместе с цифровой подписью передавать и открытый ключ (или сертификат) для проверки.

В XML, например в СМЭВ, подпись 64 байта в одном тэге, сертификат в другом, ну и служебная информация (алгоритмы хеша, подписи, канонизаций).

AFAIK

В Крипто-ПРО JCP достаточно простые примеры. Что там в бинарном виде и как считается, IMHO совсем лишняя и не нужная информация )))

приумножая знания, приумножаешь скорбь (C)

Я так понимаю, вопрос был в каком виде в

XML-Signature Syntax and Processing
W3C Recommendation 12 February 2002

http://www.w3.org/2000/09/xmldsig
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/Overview.html

хранится цифровой ключ в ноде SignatureValue. Отвечаю - чистые 64 байта полученные от криптопровайдера, теже (при определенном шаманстве!), что возвращает WinAPI ф-ция CryptSignHash переведенные в текст по Base64.

Всякие "продвинутые" хрени получаемые через CryptSignMessage и ему подобное - не при делах.

kmaw...а зачем ему это? один фиг легитимно это только через API криптопровайдера. он же легитимно хочет.

Не знаю, что он хочет. Я 2 недели убил, что бы через КриптоПро CSP и Windows API подписать XML'ку. КриптоПро JCP у заказчика не куплено, две недели танцевал с бубном вокруг КриптоПро. Сегодня первый день, как Java на проверку подписи true сказало.

Тоже размышлял, та ли подпись в Java или какая-то другая... не, та же самая.... если в бубен хорошо постучать )))

kmaw...ну вообщето КриптоПро платный.
Понятное дело.

У заказчика официально установлен только CSP, поэтому и пришлось извращаться (C, JNI, "ручками" подписывать XML). На JCP проблем с подписью/валидацией XML быть вообще не должно AFAIK,

Что конкретно нужно ТС, вопрос остается открытым.

Подозреваю, что пользование бесплатными средствами поддерживающими ГОСТ (даже если они и есть) полностью не осмысленно. Т.к. никакой гарантии более-менее корректной работы и соответствия стандарту/закону. Я уж не говорю про сертификацию.

Что говорить, когда даже у CSP и JCP байтовая последовательность подписи немного, но отличаются (нужно подшаманивать). И это у одного производителя и по ГОСТу ! ))). На форуме были темы, когда _официальный_ центр сертификации в Москве выдавал ключи и сертификаты не по стандарту. А при Subj, вопрос кто будет крайним, IMHO достаточно важен. Буду даже какие-то проблемы с ЭЦП/сертификатами/ключами, всегда можно развести руками и сказать - КриптоПро виноват и отойти в сторонку )))

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

К тому же и цены на софт вполне умеренные IMHO

какими нормативными документами РФ
Методические рекомендации СМЭВ версия 2.4.4 ( http://smev.gosuslugi.ru/portal/) ссылаются на закон от 6 апреля 2011 г. "63-ФЗ «Об электронной подписи"

На сайте КриптоПро тоже есть подборка ссылок:
http://www.cryptopro.ru/support/docs/law

то на какие открытые стандарты (RFC, PKCS etc) опираться? Стоит задача организовать проверку достоверности подписи документов, подписанных в сторонних системах
IMHO В зависимости от того, от каких систем приходят данные и в каком стандарте.

Если пишется ТЗ на систему, то лично я бы "стырел" соответствующие куски из СМЭВ.

1) СМЭВ-подобный XMLDsig для данных в XML (бинарная подпись получаемая из КриптоПро JCP или аналогов)
2) PKCS#7 (detached) + СМЭВ-подобное именование файлов для бинарных файлов и вложений (я это пока не делал, т.ч. совместимость PKCS#7 между КриптоПро CSP и JCP еще не проверял)

СМЭВ активно насаждается, плюс думаю, большинство официальных сертификационных центров также под СМЭВ заточены. Т.ч. СМЭВо-подобие явно упростит жизнь в дальнейшем.

Тут только нужно не забыть о подводных камнях:

например СМЭВ тайм-стамп ставит на уровне шины, в подпись самой СМЭВ. Т.ч. при подписи физического лица и при подписи информационной системы подключенной к СМЭВ тайп-стамп не ставится. Если у Вас своя система, то отстутвие тайм-стамп автоматом весь юридический аспект подписи поставит под сомнение.

Возможно какие-то и другие подводные камни. Тайм-стемп первое, что пришло в голову.