Используем Firefox 3.6 Win7, добавляет именно второй байт 0. Т.е. строка
var dataToSign="abc";

В подписи превращается в a0b0c0. Т.е. никакого UTF-8.

Пологаю что, при передаче строкового параметра через COM объекты, все переводится к UCS-2. Так что ждем от вас метода convertUnicode (или как вы его назовете) отбрасывающего второй байт. В будущем к нему можно добавить нужные параметры конвертации, если будут необходимы.

Посмотрели как ведут себя браузеры с бинарными данными: по-разному и плохо. Данные с сервера качали с помощью XmlHttpRequest.

IE в зависимости от Content-type писал данные в xmlHttpRequest::responseText или xmlHttpRequest::responseBody.
При записи в xmlHttpRequest::responseText независимо от charset (us-ascii, utf-8и т.п.) данные перекодировались в UCS-2.
xmlHttpRequest::responseBody имел тип Array of Byte, для которого нет простого способа почитать из javaScript.

Firefox, Chrome, Opera любые бинарные данные писали в xmlHttpRequest::responseText; пытались угадать кодировку данных; с нулевыми байтами внутри данных
обходились хорошо, не обрезая строку по первому нулю. Все беды начинались при передаче данных плагину. Если внутри строки встречался 0, то плагин получал обрезанную строку, но
длина строки передавалась оригинальная. Плагин ожидает получить данные в UTF-8 кодировке, поэтому что получается после перекодирования из UTF-8 в UCS-2 произвольных бинарных данных
и что будет в итоге подписано - неизвестно.

Для борьбы с этими проблемами будет сделано:

Бинарные данные должны быть закодированы в base64,
У объекта CadesSignedData появится новое свойство ContentEncoding, говорящий плагину о кодировке контента (base64, utf-8, ucs-2).
Перед созданием подписи:
- base64 будет декодирован в бинарные данные
- utf-8 -> ucs-2
- ucs-4 -> ucs-2
При проверке прикрепленной подписи перед получение контента также нужно указать кодировку, в которой будут получены подписанные данные.

удивительно но с файлами проблема решена
с использованием base64 для передачи с сервера
ручным побитовым перекодированием (в chrome есть встроенная функция).

теперь следующий вопрос
могу ли с помощью плагина создать xmldsig подпись?

собственно мне надо сделать три параметра для подписи узла xml
<DigestValue> - это хэш. можно ли его выловить из свойств объекта?
<SignatureValue> - это сама подпись. видиом она такой и останется.
<X509Certificate> - это публичный ключ от сертификата

идея в том что бы пользователь поставил СВОЮ подпись на узел xml файла и ничего кроме браузера не использовал.
естественно мы уже используем sharpei на сервере - но там ставится только серверная подпись.

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

подскажите пожалуйста какое техническое решение использовать при решении такой задачи
используя браузер поставить клиентскую подпись в формате xml dsig

Добрый день.

Скажите, пожалуйста, планируется ли добавить в плагин функционал по созданию клиентской подписи в формате xmldsig?