Hack to allow ec_private_key_openssl loading keys generated with NSS.

Hack to allow ec_private_key_openssl loading keys generated with NSS.

BUG=none

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=258739

[mattm, 2014-03-19 21:49:44]

Oh, one annoying thing is that if you have --vmodule specified, you still get
bunch of error spam.

[Ryan Sleevi, 2014-03-21 20:32:18]

lgtm

[mattm, 2014-03-21 21:05:43]

The CQ bit was checked by mattm@chromium.org

[commit-bot: I haz the power, 2014-03-21 21:06:24]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mattm@chromium.org/205333002/1

[commit-bot: I haz the power, 2014-03-22 02:42:50]

Change committed as 258739

[wtc, 2014-03-22 03:13:45]

https://codereview.chromium.org/205333002/diff/1/crypto/ec_private_key_openss...
File crypto/ec_private_key_openssl.cc (right):

https://codereview.chromium.org/205333002/diff/1/crypto/ec_private_key_openss...
crypto/ec_private_key_openssl.cc:137: // causes OpenSSL to use an empty password
instead of "\0\0".

Does NSS have a bug?

[mattm, 2014-03-22 04:01:33]

https://codereview.chromium.org/205333002/diff/1/crypto/ec_private_key_openss...
File crypto/ec_private_key_openssl.cc (right):

https://codereview.chromium.org/205333002/diff/1/crypto/ec_private_key_openss...
crypto/ec_private_key_openssl.cc:137: // causes OpenSSL to use an empty password
instead of "\0\0".
On 2014/03/22 03:13:45, wtc wrote:
> 
> Does NSS have a bug?

I don't know I'd call it a bug in NSS, other than perhaps of lacking
documentation.
NSS takes a SECItem for the password and uses it directly, so it's up to the app
to use an appropriately formatted password. (In ec_private_key_nss.cc, we pass
in a 0-length pwitem.)

OpenSSL interprets the password input as ASCII and converts it to 2-byte unicode
string with included null termination (Unless you #define PBE_UNICODE when
building OpenSSL, in which case it's like NSS and you can pass in whatever you
want without it being changed.)

PKCS 12 section B.1 says the password should be a 2-byte big-endian unicode
string with included 2 bytes of null termination, but then B.2.3 says that if
the password is the empty string, P should also be empty. I guess taken
literally, "\0\0" is not an empty string, but I dunno if that's what was
intended.