Форум КриптоПро
»
Общие вопросы
»
Общие вопросы
»
Возможная проблема в RFC6960 (OCSP protocol)
Статус: Сотрудник
Группы: Администраторы, Участники
Зарегистрирован: 24.11.2009(UTC)
Сообщений: 965
Откуда: Crypto-Pro
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 174 раз в 152 постах
|
Ответ достаточно ожидаемый. Они рассматривают документ с позиции двух тезисов. Цитата:1.
The descriptions ARE the same and you have not yet seen it. What is to be hashed is the public key. This public key is a string of bits (a "bit string"). It does NOT say to hash the Value portion of the ASN.1 Tag/Length/Value BIT STRING; it says to hash the public key. The byte of "unused bits" is very clearly NOT part of the public key, so this byte is not part of the input to the hash (and it never has been, so there is no change from 2650 to 6960). Т.е. хешировать только public key, в их понимании еще до того как вы упаковываете его в asn1. И в этот момент у вас еще нет unused bits и тогда как бы вопросов нет. Цитата:2.
It is that Appendix B.1 is NORMATIVE (i.e., official; THE standard specification; the only part of the entire document that MUST be implemented for compliance). So it is NOT that there are 2 or 3 descriptions of the ASN.1 and people won't know what to implement. There is ONE description of the ASN.1 for implementers to follow; everything else can be completely and safely ignored.
Т.е. все что не в приложении второстепенно по сути. Надеюсь, что если похожие вопросы еще у кого то будут возникать, то эта ветка найдется в поиске. |
|
 4 пользователей поблагодарили Анатолий Беляев за этот пост.
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 22.01.2008(UTC) Сообщений: 671   Откуда: Йошкар-Ола Сказал «Спасибо»: 3 раз
Поблагодарили: 93 раз в 67 постах
|
О, какой-то осмысленный ответ, спасибо. Цитата:Т.е. хешировать только public key, в их понимании еще до того как вы упаковываете его в asn1. И в этот момент у вас еще нет unused bits и тогда как бы вопросов нет. KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key -- (i.e., the SHA-1 hash of the value of the -- BIT STRING subjectPublicKey [excluding -- the tag, length, and number of unused -- bits] in the responder's certificate) Рассматривать responder's public key как нечто абстрактное невозможно в контексте данного RFC. Это не какая-то последовательность бит, в комментариях чётко сказано, что "BIT STRING subjectPublicKey". Работаю тут с BIT STRING и только с этим типом данных. Цитата:Т.е. все что не в приложении второстепенно по сути Да мне всё-равно что именно первично и вторично. Просто в данном RFC есть два разных определения для KeyHash. Если первично определение из Appendix B.1 то пусть упомянут, что протокол OCSP был изменён по сравнению с RFC2960. |
С уважением,
Юрий Строжевский |
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 12.10.2009(UTC)
Сообщений: 42
Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 6 раз в 6 постах
|
Насчет хеширования только части BIT STRING - схема не новая. RFC 5280 (Собственно X.509), и более ранние редакции (3280, 2459) 4.2.1.2. Subject Key Identifier (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). Отредактировано пользователем 29 мая 2020 г. 13:50:00(UTC)
| Причина: Не указана
|
|
|
|
|
|
Форум КриптоПро
»
Общие вопросы
»
Общие вопросы
»
Возможная проблема в RFC6960 (OCSP protocol)
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
