PK11_UnwrapPrivKey requires public key value

NEW
Assigned to

Status

P2
enhancement
17 years ago
11 years ago

People

(Reporter: jamie-bugzilla, Assigned: rrelyea)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
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.
(Assignee)

Comment 1

17 years ago
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

17 years ago
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
(Assignee)

Comment 3

17 years ago
target 3.5 for now
Target Milestone: --- → 3.5

Comment 4

17 years ago
Move to 3.6.  Should this be a P1 or P2?
Target Milestone: 3.5 → 3.6
(Reporter)

Comment 5

17 years ago
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.
(Assignee)

Comment 6

17 years ago
Sigh,

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

bob
Target Milestone: 3.6 → 4.0
(Reporter)

Updated

17 years ago
Blocks: 135328
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.
Severity: normal → enhancement
Priority: -- → P2
Target Milestone: 4.0 → ---
(Assignee)

Comment 8

16 years ago
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
QA Contact: bishakhabanerjee → jason.m.reid
QA Contact: jason.m.reid → libraries

Comment 9

11 years ago
Bob, will this be getting addressed with the new DB in 3.12 ?
(Assignee)

Comment 10

11 years ago
When using the Shared DB support, yes. The value is still accepted, but not required.
You need to log in before you can comment on or make changes to this bug.