Add PKCS#8 ECPrivateKey export/import functions.

Add PKCS#8 ECPrivateKey export/import functions.

Also const-correct a few functions and add some missing error tracers.
Deprecate the old ones. Also const-correct a few functions and add some missing
error tracers. Future work migrate existing serializations to the new format.

BUG=603319
Committed: https://crrev.com/212cdf69ab10af4d04cb12919b5c6504e54f73cc
Cr-Commit-Position: refs/heads/master@{#398318}

[davidben, 2016-05-02 23:18:53]

davidben@chromium.org changed reviewers:
+ rsleevi@chromium.org

[davidben, 2016-05-02 23:18:54]

Let's get these in there so new code doesn't use the "encrypted" nonsense.

https://codereview.chromium.org/1935053003/diff/20001/crypto/ec_private_key_u...
File crypto/ec_private_key_unittest.cc (right):

https://codereview.chromium.org/1935053003/diff/20001/crypto/ec_private_key_u...
crypto/ec_private_key_unittest.cc:43: TEST(ECPrivateKeyUnitTest, InitRandomTest)
{
(I more-or-less rewrote this test. The old version was rather hairy.)

[Ryan Sleevi, 2016-05-02 23:26:56]

https://codereview.chromium.org/1935053003/diff/20001/crypto/ec_private_key.cc
File crypto/ec_private_key.cc (right):

https://codereview.chromium.org/1935053003/diff/20001/crypto/ec_private_key.c...
crypto/ec_private_key.cc:107: NID_X9_62_prime256v1) {
Why? We don't enforce this elsewhere, AFAICT. It's implicit in
ExportPublicKeyRaw, but my point here is that this isn't documented in the
header as part of the API contract, nor consistently enforced. I have no
objections to enforcing this consistently, and to clearly documenting that
contract - but this feels asymmetric and underspecified in the present form.

[davidben, 2016-06-01 17:19:39]

https://codereview.chromium.org/1935053003/diff/20001/crypto/ec_private_key.cc
File crypto/ec_private_key.cc (right):

https://codereview.chromium.org/1935053003/diff/20001/crypto/ec_private_key.c...
crypto/ec_private_key.cc:107: NID_X9_62_prime256v1) {
On 2016/05/02 23:26:56, Ryan Sleevi (OOO til 6-6) wrote:
> Why? We don't enforce this elsewhere, AFAICT. It's implicit in
> ExportPublicKeyRaw, but my point here is that this isn't documented in the
> header as part of the API contract, nor consistently enforced. I have no
> objections to enforcing this consistently, and to clearly documenting that
> contract - but this feels asymmetric and underspecified in the present form.

I think it's a little poor to have parsing be able to create keys that we would
never parse. But, fair enough, if we're to limit it to P-256, it should be done
uniformly and with tests. Took that bit out. We can sort it out separately.

[davidben, 2016-06-01 17:19:58]

https://codereview.chromium.org/1935053003/diff/20001/crypto/ec_private_key.cc
File crypto/ec_private_key.cc (right):

https://codereview.chromium.org/1935053003/diff/20001/crypto/ec_private_key.c...
crypto/ec_private_key.cc:107: NID_X9_62_prime256v1) {
On 2016/06/01 17:19:39, davidben (OOO until 5-31) wrote:
> On 2016/05/02 23:26:56, Ryan Sleevi (OOO til 6-6) wrote:
> > Why? We don't enforce this elsewhere, AFAICT. It's implicit in
> > ExportPublicKeyRaw, but my point here is that this isn't documented in the
> > header as part of the API contract, nor consistently enforced. I have no
> > objections to enforcing this consistently, and to clearly documenting that
> > contract - but this feels asymmetric and underspecified in the present form.
> 
> I think it's a little poor to have parsing be able to create keys that we
would
> never parse. But, fair enough, if we're to limit it to P-256, it should be
done
> uniformly and with tests. Took that bit out. We can sort it out separately.

s/would never parse/would never create/

[Ryan Sleevi, 2016-06-07 12:05:10]

Lots of red bots - some dependencies to fix up?

[davidben, 2016-06-07 15:46:45]

On 2016/06/07 12:05:10, Ryan Sleevi wrote:
> Lots of red bots - some dependencies to fix up?

Seems I missed the ExportValueForTesting caller. Fixed.

[Ryan Sleevi, 2016-06-07 16:25:54]

The CQ bit was checked by rsleevi@chromium.org

[Ryan Sleevi, 2016-06-07 16:25:54]

lgtm

[commit-bot: I haz the power, 2016-06-07 16:32:12]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1935053003/80001

[commit-bot: I haz the power, 2016-06-07 17:11:24]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-06-07 17:14:05]

Description was changed from

==========
Add PKCS#8 ECPrivateKey export/import functions.

Also const-correct a few functions and add some missing error tracers.
Deprecate the old ones. Also const-correct a few functions and add some missing
error tracers. Future work migrate existing serializations to the new format.

BUG=603319
==========

to

==========
Add PKCS#8 ECPrivateKey export/import functions.

Also const-correct a few functions and add some missing error tracers.
Deprecate the old ones. Also const-correct a few functions and add some missing
error tracers. Future work migrate existing serializations to the new format.

BUG=603319

Committed: https://crrev.com/212cdf69ab10af4d04cb12919b5c6504e54f73cc
Cr-Commit-Position: refs/heads/master@{#398318}
==========

[commit-bot: I haz the power, 2016-06-07 17:14:06]

Patchset 5 (id:??) landed as
https://crrev.com/212cdf69ab10af4d04cb12919b5c6504e54f73cc
Cr-Commit-Position: refs/heads/master@{#398318}