Atom Лента - Форум КриптоПро - Тема:Возможная проблема в RFC6960 (OCSP protocol) - 10Форум КриптоПро - Atom Лентаurn:https:--www-cryptopro-ru:AtomLenta:ForumKriptoPro:Tema:VozmozhnajaproblemavRFC6960(OCSPprotocol)-10:1Copyright 2024 Форум КриптоПро2024-03-29T17:48:31Zhttps://www.cryptopro.ru/forum2/Images/YAFLogo.pngForum Adminhttps://www.cryptopro.ruforum@cryptopro.ruKDAhttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=1894&name=KDAKDAhttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=1894&name=KDAЮрийhttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=123&name=ЮрийАнатолий Беляевhttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=2008&name=Анатолий БеляевЮрийhttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=123&name=ЮрийЮрийhttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=123&name=ЮрийЮрийhttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=123&name=ЮрийЮрийhttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=123&name=ЮрийЮрийhttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=123&name=ЮрийЮрийhttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=123&name=ЮрийЮрийhttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=123&name=ЮрийYetAnotherForum.NETurn:https:--www-cryptopro-ru:ftPosts:st1:meid115734:1Возможная проблема в RFC6960 (OCSP protocol)<table class="content postContainer_Alt" width="100%"><tr><td>Насчет хеширования только части BIT STRING - схема не новая.<br />RFC 5280 (Собственно X.509), и более ранние редакции (3280, 2459)<br />4.2.1.2. Subject Key Identifier<br /><br />(1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the<br />value of the BIT STRING subjectPublicKey (excluding the tag,<br />length, and number of unused bits).</td></tr></table>2020-05-29T13:50:00+03:002020-05-29T13:50:00+03:00KDA<table class="content postContainer_Alt" width="100%"><tr><td>Насчет хеширования только части BIT STRING - схема не новая.<br />RFC 5280 (Собственно X.509), и более ранние редакции (3280, 2459)<br />4.2.1.2. Subject Key Identifier<br /><br />(1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the<br />value of the BIT STRING subjectPublicKey (excluding the tag,<br />length, and number of unused bits).</td></tr></table>urn:https:--www-cryptopro-ru:ftPosts:st1:meid115535:1Возможная проблема в RFC6960 (OCSP protocol)<table class="content postContainer" width="100%"><tr><td>О, какой-то осмысленный ответ, спасибо.<br /><br /><div class="quote"><span class="quotetitle">Цитата:</span><blockquote>Т.е. хешировать только public key, в их понимании еще до того как вы упаковываете его в asn1. И в этот момент у вас еще нет unused bits и тогда как бы вопросов нет.</div></div><br /><br />KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key<br /> -- (i.e., the SHA-1 hash of the value of the<br /> -- BIT STRING subjectPublicKey [excluding<br /> -- the tag, length, and number of unused<br /> -- bits] in the responder's certificate)<br /><br />Рассматривать responder's public key как нечто абстрактное невозможно в контексте данного RFC. Это не какая-то последовательность бит, в комментариях чётко сказано, что "BIT STRING subjectPublicKey". Работаю тут с BIT STRING и только с этим типом данных.<br /><br /><div class="quote"><span class="quotetitle">Цитата:</span><blockquote>Т.е. все что не в приложении второстепенно по сути</div></div><br /><br />Да мне всё-равно что именно первично и вторично. Просто в данном RFC есть два разных определения для KeyHash. Если первично определение из Appendix B.1 то пусть упомянут, что протокол OCSP был изменён по сравнению с RFC2960. </td></tr></table>2020-05-25T16:13:25+03:002020-05-25T16:13:25+03:00Юрий<table class="content postContainer" width="100%"><tr><td>О, какой-то осмысленный ответ, спасибо.<br /><br /><div class="quote"><span class="quotetitle">Цитата:</span><blockquote>Т.е. хешировать только public key, в их понимании еще до того как вы упаковываете его в asn1. И в этот момент у вас еще нет unused bits и тогда как бы вопросов нет.</div></div><br /><br />KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key<br /> -- (i.e., the SHA-1 hash of the value of the<br /> -- BIT STRING subjectPublicKey [excluding<br /> -- the tag, length, and number of unused<br /> -- bits] in the responder's certificate)<br /><br />Рассматривать responder's public key как нечто абстрактное невозможно в контексте данного RFC. Это не какая-то последовательность бит, в комментариях чётко сказано, что "BIT STRING subjectPublicKey". Работаю тут с BIT STRING и только с этим типом данных.<br /><br /><div class="quote"><span class="quotetitle">Цитата:</span><blockquote>Т.е. все что не в приложении второстепенно по сути</div></div><br /><br />Да мне всё-равно что именно первично и вторично. Просто в данном RFC есть два разных определения для KeyHash. Если первично определение из Appendix B.1 то пусть упомянут, что протокол OCSP был изменён по сравнению с RFC2960. </td></tr></table>urn:https:--www-cryptopro-ru:ftPosts:st1:meid115495:1Возможная проблема в RFC6960 (OCSP protocol)<table class="content postContainer_Alt" width="100%"><tr><td>Ответ достаточно ожидаемый. Они рассматривают документ с позиции двух тезисов. <br /><div class="quote"><span class="quotetitle">Цитата:</span><blockquote>1.<br />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). </div></div><br />Т.е. хешировать только public key, в их понимании еще до того как вы упаковываете его в asn1. И в этот момент у вас еще нет unused bits и тогда как бы вопросов нет.<br /><div class="quote"><span class="quotetitle">Цитата:</span><blockquote>2.<br />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.<br /></div></div><br />Т.е. все что не в приложении второстепенно по сути.<br /><br />Надеюсь, что если похожие вопросы еще у кого то будут возникать, то эта ветка найдется в поиске. <br /><br /></td></tr></table>2020-05-22T13:38:20+03:002020-05-22T13:38:20+03:00Анатолий Беляев<table class="content postContainer_Alt" width="100%"><tr><td>Ответ достаточно ожидаемый. Они рассматривают документ с позиции двух тезисов. <br /><div class="quote"><span class="quotetitle">Цитата:</span><blockquote>1.<br />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). </div></div><br />Т.е. хешировать только public key, в их понимании еще до того как вы упаковываете его в asn1. И в этот момент у вас еще нет unused bits и тогда как бы вопросов нет.<br /><div class="quote"><span class="quotetitle">Цитата:</span><blockquote>2.<br />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.<br /></div></div><br />Т.е. все что не в приложении второстепенно по сути.<br /><br />Надеюсь, что если похожие вопросы еще у кого то будут возникать, то эта ветка найдется в поиске. <br /><br /></td></tr></table>urn:https:--www-cryptopro-ru:ftPosts:st1:meid115447:1Возможная проблема в RFC6960 (OCSP protocol)<table class="content postContainer" width="100%"><tr><td>Ну и так далее в том же духе: эти описания идентичны (в одном хэш без одного байта - конечно "идентичны"), типа "мы имели в виду вот это, хоть это как-то по другому описано в RFC", "вот за много лет никто не заметил" и так далее.<br />Как я вижу никому здесь это не интересно (или нет какой-то квалификации для понимания, хотя всё достаточно примитивно). Я просто оставлю это здесь для формирования понимания у других на будущее - даже авторы RFC делают ошибки. Если вы заметили такую - пишите авторам.</td></tr></table>2020-05-21T12:36:23+03:002020-05-21T12:36:23+03:00Юрий<table class="content postContainer" width="100%"><tr><td>Ну и так далее в том же духе: эти описания идентичны (в одном хэш без одного байта - конечно "идентичны"), типа "мы имели в виду вот это, хоть это как-то по другому описано в RFC", "вот за много лет никто не заметил" и так далее.<br />Как я вижу никому здесь это не интересно (или нет какой-то квалификации для понимания, хотя всё достаточно примитивно). Я просто оставлю это здесь для формирования понимания у других на будущее - даже авторы RFC делают ошибки. Если вы заметили такую - пишите авторам.</td></tr></table>urn:https:--www-cryptopro-ru:ftPosts:st1:meid115445:1Возможная проблема в RFC6960 (OCSP protocol)<table class="content postContainer_Alt" width="100%"><tr><td>"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.<br /><br /> <br /><br />"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.</td></tr></table>2020-05-21T12:32:50+03:002020-05-21T12:32:50+03:00Юрий<table class="content postContainer_Alt" width="100%"><tr><td>"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.<br /><br /> <br /><br />"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.</td></tr></table>urn:https:--www-cryptopro-ru:ftPosts:st1:meid115444:1Возможная проблема в RFC6960 (OCSP protocol)<table class="content postContainer" width="100%"><tr><td>Hi Yury,<br /><br /> <br /><br />I would like to clarify also.<br /><br /> <br /><br />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.<br /><br /> <br /><br />The rest I have understood the whole time.<br /><br /> <br /><br />Now, let me explain why I don’t believe this is a serious problem and why I think this is more editorial:<br /><br /> <br /><br />Both texts says the following: “SHA-1 hash of responder's public key”<br /><br />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.<br /><br />The text then just attempts to explain what this means in practice.<br /><br /> <br /><br />The latter text in the ASN.1 module Appendix B (which is what implementers are expected to implement) is correct in detail.<br /><br />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.<br /><br /> <br /><br />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.<br /><br /> <br /><br />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.<br /><br /> <br /><br />Thanks again for bringing this to our attention.<br /><br /> <br /><br />Stefan Santesson</td></tr></table>2020-05-21T12:31:41+03:002020-05-21T12:31:41+03:00Юрий<table class="content postContainer" width="100%"><tr><td>Hi Yury,<br /><br /> <br /><br />I would like to clarify also.<br /><br /> <br /><br />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.<br /><br /> <br /><br />The rest I have understood the whole time.<br /><br /> <br /><br />Now, let me explain why I don’t believe this is a serious problem and why I think this is more editorial:<br /><br /> <br /><br />Both texts says the following: “SHA-1 hash of responder's public key”<br /><br />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.<br /><br />The text then just attempts to explain what this means in practice.<br /><br /> <br /><br />The latter text in the ASN.1 module Appendix B (which is what implementers are expected to implement) is correct in detail.<br /><br />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.<br /><br /> <br /><br />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.<br /><br /> <br /><br />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.<br /><br /> <br /><br />Thanks again for bringing this to our attention.<br /><br /> <br /><br />Stefan Santesson</td></tr></table>urn:https:--www-cryptopro-ru:ftPosts:st1:meid115443:1Возможная проблема в RFC6960 (OCSP protocol)<table class="content postContainer_Alt" width="100%"><tr><td>Hello Yury,<br /><br /> <br /><br />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.)<br /><br /> <br /><br />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.<br /> <br />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.<br /> <br />Carlisle.</td></tr></table>2020-05-21T12:30:57+03:002020-05-21T12:30:57+03:00Юрий<table class="content postContainer_Alt" width="100%"><tr><td>Hello Yury,<br /><br /> <br /><br />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.)<br /><br /> <br /><br />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.<br /> <br />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.<br /> <br />Carlisle.</td></tr></table>urn:https:--www-cryptopro-ru:ftPosts:st1:meid115442:1Возможная проблема в RFC6960 (OCSP protocol)<table class="content postContainer" width="100%"><tr><td>Hi Yury, <br />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. <br />Stefan Santesson</td></tr></table>2020-05-21T12:30:18+03:002020-05-21T12:30:18+03:00Юрий<table class="content postContainer" width="100%"><tr><td>Hi Yury, <br />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. <br />Stefan Santesson</td></tr></table>urn:https:--www-cryptopro-ru:ftPosts:st1:meid115441:1Возможная проблема в RFC6960 (OCSP protocol)<table class="content postContainer_Alt" width="100%"><tr><td>Hello, the RFC6960 authors! <br />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<br />   (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<br />                         -- (i.e., the SHA-1 hash of the value of the<br />                         -- BIT STRING subjectPublicKey [excluding<br />                         -- the tag, length, and number of unused<br />                         -- 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". <br />Best regards,Yury Strozhevsky</td></tr></table>2020-05-21T12:29:36+03:002020-05-21T12:29:36+03:00Юрий<table class="content postContainer_Alt" width="100%"><tr><td>Hello, the RFC6960 authors! <br />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<br />   (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<br />                         -- (i.e., the SHA-1 hash of the value of the<br />                         -- BIT STRING subjectPublicKey [excluding<br />                         -- the tag, length, and number of unused<br />                         -- 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". <br />Best regards,Yury Strozhevsky</td></tr></table>urn:https:--www-cryptopro-ru:ftPosts:st1:meid115440:1Возможная проблема в RFC6960 (OCSP protocol)<table class="content postContainer" width="100%"><tr><td>Ну раз никого больше высказаться нет, то расскажу я вам сказочку о том, как авторы PKI-related RFC ASN.1 понимают. <br />Ниже будет моя переписка с авторами RFC6960.</td></tr></table>2020-05-21T12:29:00+03:002020-05-21T12:29:00+03:00Юрий<table class="content postContainer" width="100%"><tr><td>Ну раз никого больше высказаться нет, то расскажу я вам сказочку о том, как авторы PKI-related RFC ASN.1 понимают. <br />Ниже будет моя переписка с авторами RFC6960.</td></tr></table>