Small addendum: OID value 4294967295 (2^32-1) encodes correctly,
The values 4294967296 (2^32)until 4294967299 (2^32+3)encode into 0 until 3. The value 4294967300 (2^32 + 4) encodes correctly again! (Probably here the program turns too late into the arbitrary-number mode?) Regards Daniel Marschall Am 20.06.2011 13:24, schrieb The default queue via RT: > Greetings, > > This message has been automatically generated in response to the > creation of a trouble ticket regarding: > "BUG: OID values near 32-Bit border are encoded wrong", > a summary of which appears below. > > There is no need to reply to this message right now. Your ticket has been > assigned an ID of [openssl.org #2542]. > > Please include the string: > > [openssl.org #2542] > > in the subject line of all future correspondence about this issue. To do so, > you may reply to this message. > > Thank you, > [email protected] > > ------------------------------------------------------------------------- > Hello, > > I have a bug report for OpenSSL 0.9.8o 01 Jun 2010 (latest stable for > Debian Squeeze) > > OpenSSL has problems encoding OIDs which are at the border of 32 bit range. > > I tested encoding several OIDs in the "new_oids" section to generate > attributes. > > - OpenSSL encodes the OID 2.999.4294967295 (4294967295 = 2^32-1) correctly. > - OpenSSL encodes the OID 2.999.4294967296 (4294967296 = 2^32) into "06 > 03 88 37 00" which is 2.999.0 ! > - OpenSSL encodes the OID 2.999.4294967297 (4294967297 = 2^32+1) into > "06 03 88 37 01" which is 2.999.1 ! > > This seems to be a bug and not a range limitation, since OpenSSL can > successfully create certificates with 64-, 128-, 256-, 512- and even > 1024-Bit OIDs!! (Which is amazing compared to the Windows CryptoAPI > Shell Extensions which are limited to 64 bits) > > Please note that only the CREATION of such a certificate/attribute is > buggy. When I edit the faulty certificate with a hex editor and then > listing it with "-text -noout" the value "06 07 88 37 90 80 80 80 00" > decodes successfully to 2.999.4294967296 as well as "06 07 88 37 90 80 > 80 80 01" decodes successfully to 2.999.4294967297. > > Best regards > Daniel Marschall > > ---- > > Appendix: How to reproduce: > > > File myconf.cnf: > > [ new_oids ] > testBase32_minus1=2.999.4294967295 > testBase32=2.999.4294967296 > testBase32_plus1=2.999.4294967297 > > File myscript.sh: > > #!/bin/sh > > openssl genrsa -out private.key 512 > > openssl req -new -batch -sha1 -key private.key -out request.pem -config > myconf.cnf -subj "/testBase32_minus1=Test 4294967295/testBase32=Test > 4294967296/testBase32_plus1=Test 4294967297" > > openssl req -in request.pem -noout -text > > >
|
Small addendum: OID value 4294967295 (2^32-1) encodes correctly, The values 4294967296 (2^32) until 4294967299 (2^32+3) encode into 0 until 3. The value 4294967300 (2^32 + 4) encodes correctly again! (Probably here the program turns too late into the arbitrary-number mode?) Regards Daniel Marschall Am 20.06.2011 13:24, schrieb The default queue via RT:
|
smime.p7s
Description: S/MIME cryptographic signature
