It seemed that we are speaking about different things. In certificate i pasted, integers used for exponent1, exponent2 and coefficient encoded with different lengths. In chapter 8.3 of ISO 8825 there is clear statement of how integer values should be encoded. All need is to take those numbers from "bad" certificate i pasted and encode it by using different 8825 implementations to see leading zeros appear. When openssl encode those number leading zeros are missing. This is what i claim as a bug.
On Tue, Apr 3, 2012 at 11:58 AM, Erwann Abalea via RT <[email protected]> wrote: > Le 03/04/2012 09:38, Tamir Khason via RT a écrit : >> Please see decrypted private key >> http://pastebin.com/DzYLnHZT >> > > Thanks. > You didn't provide information on where you think the error is, > precisely. I'll base my answer on your previous posts. > > You started to say that "the coefficients should be of the same length". > By "coefficient", you mean the CRT parameters (exponent1, exponent2, > coefficient). You didn't provide an authority source to back up this > assertion. In fact, it's false, and has been explained why. There's no > optimization trick, no particular decision, some parameters can be > smaller than others, that happens, and it's not wrong. > > You then talked about end-of-content octets. There's no such octet in > the provided example. And there's no end-of-content octet possible in > the DER representation of an object. End-of-content octets are found > with indefinite length objects, when you don't know in advance the size > of the object you're encoding, but can tell when it ends; think of it as > "streaming", for example. This is allowed with BER only, not DER. > > It was explained to you how an integer is serialized in DER, in order to > be sure that it's the smallest representation of the integer, without > any confusion between negative and positive numbers. In your provided > example, all the CRT parameters have their DER serialization starting > with a leading 00 octet, because the next non 00 octet has its highest > bit equal to 1, and if this leading 00 octet wouldn't be here the > serialized number would have been considered a negative number, which is > not wanted. The fact that exponent1 and coefficient are of the same size > as prime1 and prime2 is a coincidence (see first paragraph of this > answer). And the fact that exponent2 has a smaller size is also a > coincidence. > > Is there anything still not clear? Do you still think OpenSSL has a bug? > If yes, maybe you could consider switching to the openssl-users mailing > list, which should obviously has been done long ago. Just subscribe to > this list, and reply on this other list. It is clear to anybody here > that what you spotted is not a bug in OpenSSL but an incomprehension on > your side. > > Cordialement. > > -- > Erwann ABALEA > ----- > Ce ne sont que des propositions. Je ne veux pas les faire passer en > force. Je pense que si mes idées doivent être reprises, elles ne > doivent pas passer au vote, pour plusieurs raison : > -+- BC in : http://neuneu.ctw.cc - Neuneu sans vote et sans forcer -+- > > -- Tamir http://khason.net/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
