Статус: Активный участник
Группы: Участники
Зарегистрирован: 21.11.2010(UTC) Сообщений: 1,130
Сказал(а) «Спасибо»: 7 раз Поблагодарили: 155 раз в 140 постах
|
Автор: Uruzaner  В общем, RFC, который описывает MIME-контент в части pkcs7 жёстко привязан к Windows-ending в текстовых строках. Если читать RFC на электронную почту, то использование канонического (CRLF) признака конца строки не должно вызывать удивления. Насколько я понимаю, после кодирования в base64, подпись накладывается на текст. Насколько я помню, при подписании текста из него исключают хвостовые пробелы и символы конца строки. Следовательно, можно предположить, что если бы вы подписали base64-текст, как одну длинную строку, то его разбивка на строки не повлияла бы на возможность проверки ЭП. Для подписания именно бинарного файла, насколько я понимаю, надо "играться" с Content-(Transfer-En)Coding. P.S. Насколько я понимаю, необязательно убирать разбивку на строки, чтобы подписать base64-текст, как одну длинную строку.
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 19.01.2023(UTC) Сообщений: 15  Сказал(а) «Спасибо»: 1 раз
|
Автор: basid  Автор: Uruzaner  В общем, RFC, который описывает MIME-контент в части pkcs7 жёстко привязан к Windows-ending в текстовых строках. Если читать RFC на электронную почту, то использование канонического (CRLF) признака конца строки не должно вызывать удивления. Насколько я понимаю, после кодирования в base64, подпись накладывается на текст. Насколько я помню, при подписании текста из него исключают хвостовые пробелы и символы конца строки. Следовательно, можно предположить, что если бы вы подписали base64-текст, как одну длинную строку, то его разбивка на строки не повлияла бы на возможность проверки ЭП. Для подписания именно бинарного файла, насколько я понимаю, надо "играться" с Content-(Transfer-En)Coding. P.S. Насколько я понимаю, необязательно убирать разбивку на строки, чтобы подписать base64-текст, как одну длинную строку. Сама подпись накладывается на текст внутри boundary (исключая сами теги) Как пример ниже (видим 4 заголовка, а ниже рандомную строку в псевдо-base64, в этом месте хранится вложение к письму): Код:Content-Type: text/xml; charset="windows-1251"; name="maket.xml"
Content-Disposition: attachment; filename="maket.xml"
Content-Transfer-Encoding: base64
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0id2luZG93cy0xMjUxIiBzdGFuZGFsb25lPSJu==
По поводу исключения символов конца строка при подписании - возможно так оно и есть, но видимо LR в этот список не входит и подписывается вместе с ним, а потом при разборе письма он меняется на CRLF (или наоборот, отсекается при валидации, в общем где-то он однозначно теряется), и подпись уже не взлетает. Всё это делалось для ухода от использования cryptosendmail и для реализации его функционала как под Win, так и под Deb. Теперь всё работает как задумано) Отредактировано пользователем 30 сентября 2023 г. 16:41:12(UTC)
| Причина: Не указана
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close