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

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline heavyside  
#1 Оставлено : 11 ноября 2020 г. 16:27:22(UTC)
heavyside

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

Группы: Участники
Зарегистрирован: 26.11.2015(UTC)
Сообщений: 14
Российская Федерация
Откуда: Москва

Сказал(а) «Спасибо»: 11 раз
Здравствуйте,

прислали тут приказ: http://publication.pravo...?index=0&rangeSize=1

Правильно ли я понимаю, что он по сути закрепляет часть rfc 5652 в отечественном законодательстве + уточняет некоторые значения атрибутов?
И по сути никаких действий с софтом не требуется, если подписываешь Crypto Pro и не составляешь сам сообщения в формате CMS?

Почитал стандарт, посмотрел существующие подписанные сообщения, вроде так всё и есть.
Offline two_oceans  
#2 Оставлено : 12 ноября 2020 г. 6:08:52(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Интересненько. По диагонали проглядел, смутило 2 момента: информация об исходном сообщении и иерархическая последовательность сертификатов. Надо вчитываться внимательнее чтобы понять не отменили ли между делом отсоединенную подпись и сокращенную цепочку сертификатов. Надеюсь, что мне просто показалось.

Кроме того, категорически не нравится такое регламентированное задание поиска сертификата через IssuerSerial, так как: 1) номера сертификатов гост, выпущенных аккредитованными УЦ, с некоторых пор содержат рандомную часть; 2) издатель может иметь несколько сертификатов с одинаковым именем; 3) авторы rfc с какого-то дуба предлагают отображать номер в десятичном формате вместо шестнадцатиричного (что очень неудобно по отношению к сертификатам гост, у которых за счет рандомной части длина номера стала 20+ байт).

С учетом всего этого, чисто технически во многих случаях удобнее пропустить поиск по издателю, и сразу искать по отпечатку, по идентификатору ключа издателя или просто по серийному номеру (рандомной части должно хватить чтобы номера у разных УЦ не повторялись). Но ведь нет, скопипастили из rfc как раз неэффективный поиск по строке (имени издателя) - ведь если в ЭП больше ничего не указано о сертификате, то придется искать по издателю.
Offline heavyside  
#3 Оставлено : 12 ноября 2020 г. 10:08:53(UTC)
heavyside

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

Группы: Участники
Зарегистрирован: 26.11.2015(UTC)
Сообщений: 14
Российская Федерация
Откуда: Москва

Сказал(а) «Спасибо»: 11 раз
Автор: two_oceans Перейти к цитате
Интересненько. По диагонали проглядел, смутило 2 момента: информация об исходном сообщении и иерархическая последовательность сертификатов. Надо вчитываться внимательнее чтобы понять не отменили ли между делом отсоединенную подпись и сокращенную цепочку сертификатов.


Отсоединенную не отменили - п.5.3: "Если поле eContent отсутствует, электронный документ хранится в отдельном файле."
С сертификатами на мой взгляд интереснее ситуация: о необходимости включать всю цепочку там явно, с моей точки зрения, не сказано. Один сертификат это тоже последовательность. А вот если цепочка сертификатов, то порядок их должен быть от корня к подписанту, п.2:
"иерархически обусловленная последовательность сертификатов, каждый последующий сертификат которой подписан ЭП, основанной на предшествующем сертификате"

Ещё меня напрягает п.6. Сравнил с текущей реализацией.
п.6.1: Тип содержимого(Content-type). Должен быть добавлен в атрибут id-contentType с объектным идентификатором вида: 1.2.840.113549.1.3
п.6.2: id-messageDigest с объектным идентификатором вида: 1.2.840.113549.1.4
п.6.3: id-aa-signingCertificateV2 с объектным идентификатором вида: 1.2.840.113549.1.9

у нас соответственно:
contentType 1.2.840.113549.1.9.3
messageDigest 1.2.840.113549.1.9.4
signingCertificateV2 1.2.840.113549.1.9.16.2.47 (тут как раз соответствует)

Такое ощущение, что просто ошиблись в приказе.
Автор: two_oceans Перейти к цитате
Кроме того, категорически не нравится такое регламентированное задание поиска сертификата через IssuerSerial

тут нет у меня комментариев. Не очень пока понимаю о чем речь.

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