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

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline Юрий  
#1 Оставлено : 19 мая 2020 г. 10:23:29(UTC)
Юрий

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

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 667
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 2 раз
Поблагодарили: 93 раз в 67 постах
Итак, есть RFC6960, описывающая различные аспекты реализации протокола OCSP. В частности там же описываются структуры, участвующие в реализации протокола OCSP.
Одной из таких структур является KeyHash. Проблема состоит в том, что в RFC6960 присутствует два различных, на мой взгляд, описания KeyHash.

Некоторые "вводные":
1) Значением "responder's public key" является ASN.1 BIT STRING кодированное по правилам DER;
2) Тип ASN.1 BIT STRING состоит из стандартной структуры TLV - tag, length, value. Однако в блоке value для BIT STRING первый байт определяет "unused bits" - количество бит (0-7), которые в value являются "padding bits" и не используются;

Итак, первое определение для KeyHash встречается в 4.2.1 "ASN.Specification of the OCSP Response":

KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key (excluding the tag and length fields)

Второе определение встречается в Appendix B.1 "OCSP in ASN.1 - 1998 Syntax":

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)

Вопрос к сообществу: считаете ли вы, что SHA-1 хэш, полученный используя эти два определения будет одинаковым или нет? Буду благодарен за развёрнутые ответы с обоснованием.
С уважением,
Юрий Строжевский
thanks 9 пользователей поблагодарили Юрий за этот пост.
Андрей * оставлено 19.05.2020(UTC), Санчир Момолдаев оставлено 20.05.2020(UTC), Максим Коллегин оставлено 20.05.2020(UTC), pd оставлено 20.05.2020(UTC), Сонина Лолита оставлено 20.05.2020(UTC), Агафьин Сергей оставлено 20.05.2020(UTC), Nikolay Batischev оставлено 20.05.2020(UTC), Наталья Мовчан оставлено 20.05.2020(UTC), Андрей Емельянов оставлено 20.05.2020(UTC)
Offline Юрий  
#2 Оставлено : 20 мая 2020 г. 13:49:47(UTC)
Юрий

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

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 667
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 2 раз
Поблагодарили: 93 раз в 67 постах
Совсем всё на этом форуме тухло? Ни у кого здесь понимания ASN.1 не осталось что-ли?
С уважением,
Юрий Строжевский
Offline Максим Коллегин  
#3 Оставлено : 20 мая 2020 г. 17:10:24(UTC)
Максим Коллегин

Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 12.12.2007(UTC)
Сообщений: 6,005
Мужчина
Откуда: КРИПТО-ПРО

Сказал «Спасибо»: 17 раз
Поблагодарили: 588 раз в 529 постах
Главный знаток ASN1 на этом форуме - Юрий Строжевский.
Если честно, я не представляю, как можно посчитать хэш на битовую строку, кроме как на строку байт, при этом вполне естественно включить и «padding».

Но если заглянуть в https://tools.ietf.org/h.../rfc3280#section-4.2.1.2 - то там тоже отбрасывают number of unused bits. Так что скорее всего всегда подразумевается хэширование без number of unused bits.

Отредактировано пользователем 20 мая 2020 г. 17:42:37(UTC)  | Причина: Не указана

Знания в базе знаний, поддержка в техподдержке
Offline Юрий  
#4 Оставлено : 21 мая 2020 г. 12:29:00(UTC)
Юрий

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

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 667
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 2 раз
Поблагодарили: 93 раз в 67 постах
Ну раз никого больше высказаться нет, то расскажу я вам сказочку о том, как авторы PKI-related RFC ASN.1 понимают.
Ниже будет моя переписка с авторами RFC6960.
С уважением,
Юрий Строжевский
Offline Юрий  
#5 Оставлено : 21 мая 2020 г. 12:29:36(UTC)
Юрий

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

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 667
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 2 раз
Поблагодарили: 93 раз в 67 постах
Hello, the RFC6960 authors! 
I need to clarify one possible mistake in RFC6960. The problem is in KeyHash description. In the initial RFC2560 we have:   KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
   (excluding the tag and length fields) But in your RFC6960 we have TWO different descriptions of the KeyHash: one from RFC2560 and another one: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) The difference is in using of "unused bits". It is just one byte, but we all know that having SHA-1 for array having just one byte missing would lead to a wrong result. So, please clarify how to you KeyHash and if it is a mistake in RFC (as I do believe) then please fix it in another RFC. The RFC having a mistakes in data desciptions should be in a "standard track". 
Best regards,Yury Strozhevsky
С уважением,
Юрий Строжевский
Offline Юрий  
#6 Оставлено : 21 мая 2020 г. 12:30:18(UTC)
Юрий

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

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 667
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 2 раз
Поблагодарили: 93 раз в 67 постах
Hi Yury, 
I fail to see the problem. RFC 6960 is a corrected more precise description compared with RDC 2560, but essentially says the same thing.If you still think this is wrong, then please file an errata so we can process it properly. 
Stefan Santesson
С уважением,
Юрий Строжевский
Offline Юрий  
#7 Оставлено : 21 мая 2020 г. 12:30:57(UTC)
Юрий

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

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 667
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 2 раз
Поблагодарили: 93 раз в 67 постах
Hello Yury,



Thank you very much for clarifying this. I did not remember that “unused bits” was in part of the “Value” portion of BIT STRING – this is my fault: I should have looked this up before responding. Furthermore, it was not clear to me (and probably also not clear to Stefan) that these two descriptions were both in RFC6960 – I thought you were saying that one was in RFC2560 and the other was in RFC6960. (When I read through your first e-mail again carefully, I realize that this is NOT what you said, but I initially thought it was what you said.)



Yes, you are definitely correct that if one description is in Section 4.2.1 and the other is in Appendix B.1, then this is a mistake. However, the first paragraph of Appendix B contains the following sentence: “Although a 2008 ASN.1 module is provided [i.e., in Appendix B.2], the module in Appendix B.1 remains the normative module as per the policy of the PKIX working group.” This is common practice in IETF RFCs: ASN.1 may be sprinkled anywhere throughout the text of the document, but the full module given in the Appendix is the normative ASN.1. Thus, the description given in Appendix B.1 is the correct description, regardless of any other description given anywhere else in the document.

So, I agree that this is an error and the two descriptions should, in an ideal world, be aligned. However, the content of Appendix B.1 is the definitive ASN.1; this is what implementers should code.

Carlisle.
С уважением,
Юрий Строжевский
Offline Юрий  
#8 Оставлено : 21 мая 2020 г. 12:31:41(UTC)
Юрий

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

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 667
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 2 раз
Поблагодарили: 93 раз в 67 постах
Hi Yury,



I would like to clarify also.



First. Thank you very much for bringing this to our attention. I made the same error as Carlisle to read this as if the difference was between 2560 and 6960.



The rest I have understood the whole time.



Now, let me explain why I don’t believe this is a serious problem and why I think this is more editorial:



Both texts says the following: “SHA-1 hash of responder's public key”

This to me is very clear that what we are supposed to hash, is the bits of the key and none of the ASN.1 stuff.

The text then just attempts to explain what this means in practice.



The latter text in the ASN.1 module Appendix B (which is what implementers are expected to implement) is correct in detail.

The first informational text is insufficient and potentially misleading. If you interpret it the way you describe, the result would be mismatching. I get that.



I still don’t think it is very likely that this will cause any problems. The standard has been around for many years and this has not surfaced as a matter of interop problems.



I still encourage you to write an errata. Following the link in my last e-mail. I personally think the errata should suggest alignment of the descriptions.



Thanks again for bringing this to our attention.



Stefan Santesson
С уважением,
Юрий Строжевский
Offline Юрий  
#9 Оставлено : 21 мая 2020 г. 12:32:50(UTC)
Юрий

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

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 667
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 2 раз
Поблагодарили: 93 раз в 67 постах
"These descriptions are not the same and we both know it." Wrong. 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). You are not supposed to hash the encoding of the public key – different encodings could conceivably include all sorts of extra things, like padding bits and parity check bits and descriptions of unused bits, etc., but that is NOT what it says. You are supposed to hash the bits that represent the public key itself (nothing more; nothing less). As Stefan mentioned, these documents have been around for quite a while and there have not been any interoperability issues around this. When 6960 came out, not one single person said "You changed the protocol and broke my implementation of 2650!". So it seems that everyone has understood the description except you. This does not indicate an error in the spec; instead, it indicates an error in your interpretation of the spec.



"ok, even if they are not same Appendix B.1 is preferable" Again, wrong. It is not that Appendix B.1 is "preferable". 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.
С уважением,
Юрий Строжевский
Offline Юрий  
#10 Оставлено : 21 мая 2020 г. 12:36:23(UTC)
Юрий

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

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 667
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 2 раз
Поблагодарили: 93 раз в 67 постах
Ну и так далее в том же духе: эти описания идентичны (в одном хэш без одного байта - конечно "идентичны"), типа "мы имели в виду вот это, хоть это как-то по другому описано в RFC", "вот за много лет никто не заметил" и так далее.
Как я вижу никому здесь это не интересно (или нет какой-то квалификации для понимания, хотя всё достаточно примитивно). Я просто оставлю это здесь для формирования понимания у других на будущее - даже авторы RFC делают ошибки. Если вы заметили такую - пишите авторам.
С уважением,
Юрий Строжевский
thanks 1 пользователь поблагодарил Юрий за этот пост.
Андрей * оставлено 21.05.2020(UTC)
Offline Анатолий Беляев  
#11 Оставлено : 22 мая 2020 г. 13:38:20(UTC)
Анатолий Беляев

Статус: Сотрудник

Группы: Администраторы, Участники
Зарегистрирован: 24.11.2009(UTC)
Сообщений: 952
Откуда: Crypto-Pro

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 165 раз в 146 постах
Ответ достаточно ожидаемый. Они рассматривают документ с позиции двух тезисов.
Цитата:
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.

Т.е. все что не в приложении второстепенно по сути.

Надеюсь, что если похожие вопросы еще у кого то будут возникать, то эта ветка найдется в поиске.

Техническую поддержку оказываем тут.
Наша база знаний.
Наша страничка в Instagram.
thanks 4 пользователей поблагодарили Анатолий Беляев за этот пост.
Андрей * оставлено 22.05.2020(UTC), Максим Коллегин оставлено 22.05.2020(UTC), Анатолий Колкочев оставлено 24.05.2020(UTC), Санчир Момолдаев оставлено 25.05.2020(UTC)
Offline Юрий  
#12 Оставлено : 25 мая 2020 г. 16:13:25(UTC)
Юрий

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

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 667
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 2 раз
Поблагодарили: 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.
С уважением,
Юрий Строжевский
Offline KDA  
#13 Оставлено : 29 мая 2020 г. 13:48:04(UTC)
KDA

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

Группы: Участники
Зарегистрирован: 12.10.2009(UTC)
Сообщений: 38

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 4 раз в 4 постах
Насчет хеширования только части 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)  | Причина: Не указана

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