Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

2 Страницы<12
Опции
К последнему сообщению К первому непрочитанному
Offline basid  
#11 Оставлено : 30 сентября 2023 г. 14:00:55(UTC)
basid

Статус: Активный участник

Группы: Участники
Зарегистрирован: 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-текст, как одну длинную строку.
Offline Uruzaner  
#12 Оставлено : 30 сентября 2023 г. 16:38:48(UTC)
Uruzaner

Статус: Участник

Группы: Участники
Зарегистрирован: 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)  | Причина: Не указана

RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Guest
2 Страницы<12
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.