[openssl-dev] [openssl.org #1497] Issue: PKCS#12 export with empty password produces incorrect encoding of MacData in PFX object
This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl.org #1497] Issue: PKCS#12 export with empty password produces incorrect encoding of MacData in PFX object
Stephen Henson via RT wrote: [EMAIL PROTECTED] - Fri Mar 02 09:58:13 2007]: openssl pkcs12 -export -in _.pem -nodes -out _.p12 generates PFX DER data with MacData in which empty password is used incorrectly, violating following quote from Chapter B, section B.2, item 3 of PKCS#12 standard [1]: "Note that if the password is the empty string, then so is P." However, I verified that openssl uses 2-byte BMPString "00 00" in hex notation when preparing a string to be hashed. Correct implementation is to use zero-length BMPString for an empty password. I believe that openssl can read correct formatting of PKCS#12, i.e. it understands both formats, so the problem is limited to export. Another name of this problem is ' NULL v.s. "" '. [1] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf As I recall this was a compatibility issue. A zero-length password is interpreted as a valid password by some implementations resulting in a double NULL but as empty by others. OpenSSL chose the option for maximum interoperability. On parsing a file it does try both versions and uses whichever produces the correct MAC. Thank you for the reply. Would it be time to re-consider the issue again and perhaps consider using correct format, given that many applications that expected incorrect format, Internet Explorer for example, have been since fixed? Thank you. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1497] Issue: PKCS#12 export with empty password produces incorrect encoding of MacData in PFX object
> [EMAIL PROTECTED] - Fri Mar 02 09:58:13 2007]: > > openssl pkcs12 -export -in _.pem -nodes -out _.p12 > > generates PFX DER data with MacData in which empty password is used > incorrectly, violating following quote from Chapter B, section B.2, item > 3 of PKCS#12 standard [1]: > > "Note that if the password is the empty string, then so is P." > > However, I verified that openssl uses 2-byte BMPString "00 00" in hex > notation when preparing a string to be hashed. Correct implementation is > to use zero-length BMPString for an empty password. > > I believe that openssl can read correct formatting of PKCS#12, i.e. it > understands both formats, so the problem is limited to export. Another > name of this problem is ' NULL v.s. "" '. > > [1] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf > As I recall this was a compatibility issue. A zero-length password is interpreted as a valid password by some implementations resulting in a double NULL but as empty by others. OpenSSL chose the option for maximum interoperability. On parsing a file it does try both versions and uses whichever produces the correct MAC. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1497] Issue: PKCS#12 export with empty password produces incorrect encoding of MacData in PFX object
openssl pkcs12 -export -in _.pem -nodes -out _.p12 generates PFX DER data with MacData in which empty password is used incorrectly, violating following quote from Chapter B, section B.2, item 3 of PKCS#12 standard [1]: "Note that if the password is the empty string, then so is P." However, I verified that openssl uses 2-byte BMPString "00 00" in hex notation when preparing a string to be hashed. Correct implementation is to use zero-length BMPString for an empty password. I believe that openssl can read correct formatting of PKCS#12, i.e. it understands both formats, so the problem is limited to export. Another name of this problem is ' NULL v.s. "" '. [1] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf Thank you. The tail of make report is attached. I didn't attach the whole thing, since I think the issue is s design issue. ... OpenSSL self-test report: OpenSSL version: 0.9.8d Last change: Introduce limits to prevent malicious keys being able t... Options: -mcpu=pentium no-camellia no-gmp no-krb5 no-mdc2 no-rc5 no-shared no-zlib no-zlib-dynamic OS (uname): Linux tcm 2.6.18-mh1aj #8 PREEMPT Sun Sep 24 00:26:08 PDT 2006 i686 i686 i386 GNU/Linux OS (config): i686-whatever-linux2 Target (default): linux-elf Target: linux-elf Compiler: Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux Thread model: posix gcc version 4.1.0 20060304 (Red Hat 4.1.0-3) Test passed. Test report in file testlog I also filed http://rt.openssl.org/Ticket/Display.html?ShowHeaders=1&id=1496 first by mistake. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]