Форум КриптоПро
»
Средства криптографической защиты информации
»
КриптоПро .NET
»
Оптимальный вариант получения списка сертификатов субъектов, принадлежащих одному корню
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,340   Сказал «Спасибо»: 550 раз
Поблагодарили: 2212 раз в 1727 постах
|
Автор: KDA  Прошу прощения, что встреваю, но истина дороже :)
RFC 5280 не имеет требований, что идентификатор ключа должен быть 20 байтов или что это должен быть SHA-1
Оговорка про 20 октетов есть у серйиного номера, но это несколько другое.
На практике видел сертификаты, у которых это поле было большей размерности. И это удовлетворяло формулировкам упомянутого RFC. certutil выводит по Хеш ИД ключа ( rfc-sha1) и Хеш ИД ключа (sha1)  Snimok ehkrana ot 2020-08-28 14-09-42.png (56kb) загружен 4 раз(а). 4.2.1.1. Authority Key Identifier ссылается на Two common methods for generating key identifiers from the public key are described in Section 4.2.1.2.где написано: Цитата: (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
value of the BIT STRING subjectPublicKey (excluding the tag,
length, and number of unused bits).
(2) The keyIdentifier is composed of a four-bit type field with
the value 0100 followed by the least significant 60 bits of
the SHA-1 hash of the value of the BIT STRING
subjectPublicKey (excluding the tag, length, and number of
unused bits).
|
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 12.10.2009(UTC)
Сообщений: 42
Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 6 раз в 6 постах
|
Забыли существенное
ДО
For CA certificates, subject key identifiers SHOULD be derived from
the public key or a method that generates unique values. Two common
methods for generating key identifiers from the public key are:
Т.е. в лучшем случае - рекомендации. Иначе было бы MUST
И после (самое главное):
Other methods of generating unique numbers are also acceptable.
Т.е. там вполне мог бы быть, например, ГОСТ-хеш, у которого размер побольше
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,340 Сказал «Спасибо»: 550 раз
Поблагодарили: 2212 раз в 1727 постах
|
Автор: KDA Забыли существенное
ДО
For CA certificates, subject key identifiers SHOULD be derived from
the public key or a method that generates unique values. Two common
methods for generating key identifiers from the public key are:
Т.е. в лучшем случае - рекомендации. Иначе было бы MUST
И после (самое главное):
Other methods of generating unique numbers are also acceptable.
Т.е. там вполне мог бы быть, например, ГОСТ-хеш, у которого размер побольше Технически кто-то должен это для начала реализовать и поддерживать. А сейчас sha1 |
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,340 Сказал «Спасибо»: 550 раз
Поблагодарили: 2212 раз в 1727 постах
|
|
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,340 Сказал «Спасибо»: 550 раз
Поблагодарили: 2212 раз в 1727 постах
|
Автор: KDA Забыли существенное
ДО
For CA certificates, subject key identifiers SHOULD be derived from
the public key or a method that generates unique values. Two common
methods for generating key identifiers from the public key are:
Т.е. в лучшем случае - рекомендации. Иначе было бы MUST
Для сертификатов CA идентификаторы ключа субъекта ДОЛЖНЫ быть получены из открытого ключа или метод, генерирующий уникальные значения. |
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 395 раз в 366 постах
|
Оно конечно может быть изменено, но смысл менять? Для поиска важно чтобы: - способ вычисления давал достаточно длинное значение (160 бит примерно 10 в 48 степени, столько сертификатов нескоро навыпускают) - не выдавал одно значение на разные данные (это общее у всех хэшей, пока вариантов данных намного меньше чем значений - результаты практически уникальны) - был быстрым (sha1 отточили до предела за годы). Поэтому смысл менять будет только если найдется алгоритм дающий 160 бит быстрее чем sha1. Гост-2012 дает больше бит, но и считается дольше. Какая разница спорить про SHOULD/MUST там "Должен" только про уникальность идентификатора и не более того. К слову, в xades-bes вместо отпечатка считается хэш от всего сертификата, расчет возможен по гост-2012 (алгоритм можно выбрать). Так что старые хэши уже только там где их реально нет смысла обновлять (в поисковых идентификаторах). Отредактировано пользователем 28 августа 2020 г. 13:58:27(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 12.10.2009(UTC)
Сообщений: 42
Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 6 раз в 6 постах
|
Автор: Андрей *
Для сертификатов CA идентификаторы ключа субъекта ДОЛЖНЫ быть получены из
открытого ключа или метод, генерирующий уникальные значения.
Ну и вообще забавно, сначала Цитата:RFC будут менять для начала... софт переписывать все... Т.е. RFC уже не переписываем, а переводим. Но к переводу рекомендую обратиться так же к RFC 2119Там объясняют разницу между словами капсом. Так же не надо никакой софт переписывать, если изначально не кодировать в него ограничение в 20 байт. Так же, из 5280 Про authority key identifier (Выделил жирным) Цитата:Two common methods for generating key
identifiers from the public key are described in Section 4.2.1.2.
Where a key identifier has not been previously established, this
specification RECOMMENDS use of one of these methods for generating
keyIdentifiers or use of a similar method that uses a different hash
algorithm. Автор: two_oceans Оно конечно может быть изменено, но смысл менять? Позволю повториться Автор: KDA
На практике видел сертификаты, у которых это поле было большей размерности.
Видел в продакшене. Хеш по какому-то из ГОСТов. Правда, это не КриптоПро, что не отменяет факта, что "просто взять 20 байт" - это, мягко говоря, некорректно. Автор: two_oceans
К слову, в xades-bes вместо отпечатка считается хэш от всего сертификата, расчет возможен по гост-2012 (алгоритм можно выбрать). Так что старые хэши уже только там где их реально нет смысла обновлять (в поисковых идентификаторах).
Та же ситуация, кстати. Выбрать можно, если подписанные атрибуты генерировать самостоятельно. А если проверять - придется разбираться с тем, что дали. Как и с длиной идентификатора ключа, которую мог сгенерировать неизвестный софт. Отредактировано пользователем 28 августа 2020 г. 19:27:09(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,340 Сказал «Спасибо»: 550 раз
Поблагодарили: 2212 раз в 1727 постах
|
Автор: KDA Автор: Андрей *
Для сертификатов CA идентификаторы ключа субъекта ДОЛЖНЫ быть получены из
открытого ключа или метод, генерирующий уникальные значения.
Ну и вообще забавно, сначала Цитата:RFC будут менять для начала... софт переписывать все... Т.е. RFC уже не переписываем, а переводим. Но к переводу рекомендую обратиться так же к RFC 2119Там объясняют разницу между словами капсом. Так же не надо никакой софт переписывать, если изначально не кодировать в него ограничение в 20 байт. Так же, из 5280 Про authority key identifier (Выделил жирным) Цитата:Two common methods for generating key
identifiers from the public key are described in Section 4.2.1.2.
Where a key identifier has not been previously established, this
specification RECOMMENDS use of one of these methods for generating
keyIdentifiers or use of a similar method that uses a different hash
algorithm. Автор: two_oceans Оно конечно может быть изменено, но смысл менять? Позволю повториться Автор: KDA
На практике видел сертификаты, у которых это поле было большей размерности.
Видел в продакшене. Хеш по какому-то из ГОСТов. Правда, это не КриптоПро, что не отменяет факта, что "просто взять 20 байт" - это, мягко говоря, некорректно. Автор: two_oceans
К слову, в xades-bes вместо отпечатка считается хэш от всего сертификата, расчет возможен по гост-2012 (алгоритм можно выбрать). Так что старые хэши уже только там где их реально нет смысла обновлять (в поисковых идентификаторах).
Та же ситуация, кстати. Выбрать можно, если подписанные атрибуты генерировать самостоятельно. А если проверять - придется разбираться с тем, что дали. Как и с длиной идентификатора ключа, которую мог сгенерировать неизвестный софт. Речь была вообще не о прикладной софте. Как ОС будет искать, думая, что там sha1, а по факту sha512? А в целом, я предложил вариант, чтобы не декодировать asn1, не подключать тот же BC... Нужно правильное решение? Да, начинаем читать все rfc, с 90х, чтобы иметь понятия, что означает SHOULD и почему нет до сих пор MUST |
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,340 Сказал «Спасибо»: 550 раз
Поблагодарили: 2212 раз в 1727 постах
|
Хотя нет, о чем я, sha1, sha512, гост, без разницы же, это просто идентификатор, для поиска |
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,340 Сказал «Спасибо»: 550 раз
Поблагодарили: 2212 раз в 1727 постах
|
Тогда взять RAW расширения, прочитать размер идентификатора и считать его. Всё.
|
|
|
|
|
|
|
Форум КриптоПро
»
Средства криптографической защиты информации
»
КриптоПро .NET
»
Оптимальный вариант получения списка сертификатов субъектов, принадлежащих одному корню
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
