X509_REQ weird behavior
Hi all, Recently I needed to perform the following task: given a certificate request (PKCS10 structure), make another one, with just a different public key. So, I've written the following piece of code to do this: // Declarations EVP_PKEY pkey; FILE* infile, *outfile; // Opening the input and output files ... // Creating the public key ... // Read the PKCS10 X509_REQ* req = PEM_read_X509_REQ(infile, NULL, NULL, NULL); // Set certificate request public key if(!X509_REQ_set_pubkey(req, pkey)) return -1; // Sign upon the request if(!X509_REQ_sign(req, pkey, EVP_sha1())) return -1; // Write the new certificate into the output file if(!PEM_write_X509_REQ(outfile, req)) return -1; Everything worked as expected (no errors were reported). However, looking at the output file after the execution, I discovered the request I got was the same as the input one! I took me several hours (and drove me crazy!) to find the catch. I needed to clear the cached values in the req_info structure, as follows: req-req_info-asn1 = NULL; req-req_info-length = 0; Well, now it works. But I think the behavior described above is buggy. Can someone, please, fix it in the future releases of OpenSSL? Thanks, Michael Pogrebisky, Software developer at Mercury Interactive Inc., Israel. --- Work phone: +972-(0)3-5399258 Home phone: +972-(0)3-9610824 Mobile phone: +972-(0)54-497123 Work fax: +972-(0)3-5331617 E-mail: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[STATUS] OpenSSL (Sun 23-Dec-2001)
OpenSSL STATUS Last modified at __ $Date: 2001/12/21 03:23:15 $ DEVELOPMENT STATE o OpenSSL 0.9.7: Under development... o OpenSSL 0.9.6c: Released on December 21st, 2001 o OpenSSL 0.9.6b: Released on July 9th, 2001 o OpenSSL 0.9.6a: Released on April 5th, 2001 o OpenSSL 0.9.6: Released on September 24th, 2000 o OpenSSL 0.9.5a: Released on April 1st, 2000 o OpenSSL 0.9.5: Released on February 28th, 2000 o OpenSSL 0.9.4: Released on August09th, 1999 o OpenSSL 0.9.3a: Released on May 29th, 1999 o OpenSSL 0.9.3: Released on May 25th, 1999 o OpenSSL 0.9.2b: Released on March 22th, 1999 o OpenSSL 0.9.1c: Released on December 23th, 1998 RELEASE SHOWSTOPPERS o BIGNUM library failures on 64-bit platforms (0.9.7-dev): - BN_mod_mul verificiation (bc) fails for solaris64-sparcv9-cc AVAILABLE PATCHES o IN PROGRESS o Steve is currently working on (in no particular order): ASN1 code redesign, butchery, replacement. OCSP EVP cipher enhancement. Enhanced certificate chain verification. Private key, certificate and CRL API and implementation. Developing and bugfixing PKCS#7 (S/MIME code). Various X509 issues: character sets, certificate request extensions. o Geoff and Richard are currently working on: ENGINE (the new code that gives hardware support among others). o Richard is currently working on: UI (User Interface) UTIL (a new set of library functions to support some higher level functionality that is currently missing). Shared library support for VMS. Kerberos 5 authentication Constification OCSP NEEDS PATCH o All 'openssl' subprograms taking '-des' and '-des3' options should include AES support (0.9.7-dev) o 'openssl speed' should include AES support (0.9.7-dev) o apps/ca.c: Sign the certificate? - n creates empty certificate file o OpenSSL_0_9_6-stable: #include openssl/e_os.h in exported header files is illegal since e_os.h is suitable only for library-internal use. o Whenever strncpy is used, make sure the resulting string is NULL-terminated or an error is reported o OpenSSL STATUS is never up-to-date. OPEN ISSUES o The Makefile hierarchy and build mechanism is still not a round thing: 1. The config vs. Configure scripts It's the same nasty situation as for Apache with APACI vs. src/Configure. It confuses. Suggestion: Merge Configure and config into a single configure script with a Autoconf style interface ;-) and remove Configure and config. Or even let us use GNU Autoconf itself. Then we can avoid a lot of those platform checks which are currently in Configure. o Support for Shared Libraries has to be added at least for the major Unix platforms. The details we can rip from the stuff Ralf has done for the Apache src/Configure script. Ben wants the solution to be really simple. Status: Ralf will look how we can easily incorporate the compiler PIC and linker DSO flags from Apache into the OpenSSL Configure script. Ulf: +1 for using GNU autoconf and libtool (but not automake, which apparently is not flexible enough to generate libcrypto) o The perl/ stuff needs a major overhaul. Currently it's totally obsolete. Either we clean it up and enhance it to be up-to-date with the C code or we also could replace it with the really nice Net::SSLeay package we can find under http://www.neuronio.pt/SSLeay.pm.html. Ralf uses this package for a longer time and it works fine and is a nice Perl module. Best would be to convince the author to work for the OpenSSL project and create a Net::OpenSSL or Crypt::OpenSSL package out of it and maintains it for us. Status: Ralf thinks we should both contact the author of Net::SSLeay and look how much effort it is to bring Eric's perl/ stuff up to date. Paul +1 WISHES o SRP in TLS. [wished by: Dj [EMAIL PROTECTED], Tom Wu [EMAIL PROTECTED], Tom Holroyd [EMAIL PROTECTED]] See http://search.ietf.org/internet-drafts/draft-ietf-tls-srp-00.txt as well as http://www-cs-students.stanford.edu/~tjw/srp/. Tom Holroyd tells us there is a SRP patch for OpenSSH at http://members.tripod.com/professor_tom/archives/, that could be useful. __ OpenSSL Project
[PATCH] aes integration (2nd try)
Okay, here's my first stab at some improvements to AES integration. . apps/openssl speed now supports aes options, works just like des. . improved efficiency of EVP calling AES . substantial AES API cleanup Coming soon: . 128-bit CFB and OFB modes . Support in more apps/openssl programs . MMX ASM code I'll leave renaming rijndael.h and crypto/rijndael/ to someone with more CVS skill :) cvs diff -Nu is at: http://defiant.dfw.nostrum.com/~sprunk/aes.diff.bz2 S -- Stephen Sprunk So long as they don't get violent, I want to CCIE #3723 let everyone say what they wish, for I myself have K5SSSalways said exactly what pleased me. --Albert Einstein __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
