135327 - PK11_UnwrapPrivKey requires public key value

Status: NEW

(NSS :: Libraries, enhancement, P2)

Description

[Jamie Nicolson]

PK11_UnwrapPrivKey takes an argument that is the public key value. I believe
this is used to set the CKA_ID and also for some internal database stuff.

JCA does not provide any interface for public key information when unwrapping
private keys. Therefore we cannot implement key unwrapping to the JCA interface
as long as NSS requires public key information.

NSS should be able to unwrap private keys without any public key information. My
understanding is NSS uses public key information purely for internal
implementation details, not for any theoretical reason.

Comment 1

[Robert Relyea]

This seems doable for session keys. It's more problematic for token keys.

The issue for token keys are twofold:
1) The NSS private key database stores public keys with the private key. This is
particularly true of DSA and DH keys (public components of RSA keys are already
a part of the RSA private key).

2) Token keys need a way for us to find them again, particularly from a cert. If
we unwrap Private keys without a CKA_ID, the private keys can 'disappear' to the
rest of NSS.

The first is probably the biggest issue, until we change the key database we
will still need the public key component. Presumably JCA will have it's own way
of dealing with #2, so it's probably not as much an issue. Is there a way in JCA
to specify this value after the fact so that you can write a JCA app that will
end up creating keys and certs which can be usable to the rest of NSS as well?

bob

Comment 2

[Wan-Teh Chang]

Changed the QA contact to Bishakha.

Comment 3

[Robert Relyea]

target 3.5 for now

Comment 4

[Wan-Teh Chang]

Move to 3.6.  Should this be a P1 or P2?

Comment 5

[Jamie Nicolson]

I vote for P1, because we can't unwrap private keys in JCA until this gets
fixed, and unwrapping private keys is a common operation. There's no way to
specify this after the fact via JCA.

Comment 6

[Robert Relyea]

Sigh,

This will really have to wait until we can redesign our database to hold
separate public and private keys.

bob

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Bob,  

Isn't it possible to derive the public value from the private value in all cases?
If so, is there any reason to hold this up for Stan?

Marking P2 per our current prioritization rules.

Comment 8

[Robert Relyea]

No, Only RSA keys can do derive public keys from private keys (and only if you
include enough of the components. RSA private keys typically have all the
components).

DSA and DH keys can't derive the public values from the private values.

bob

Comment 9

[Julien Pierre]

Bob, will this be getting addressed with the new DB in 3.12 ?

Comment 10

[Robert Relyea]

When using the Shared DB support, yes. The value is still accepted, but not required.