Closed Bug 128172 Opened 23 years ago Closed 22 years ago

function to convert a session key to a token key

Categories

(NSS :: Libraries, enhancement, P1)

enhancement

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jamie-bugzilla, Assigned: jamie-bugzilla)

References

Details

Attachments

(1 file, 1 obsolete file)

In the JCA model, whenever you generate a keypair, the keys are temporary
objects. Not until you store them do they become permanent. I already have the
ability to create temporary (session) keys. Now I need a way to convert a
session key to a token key. This would do a C_CopyObject on the key while
modifying the CKA_TOKEN attribute to be TRUE.
Target Milestone: --- → 3.4
These are the functions I had in mind. I haven't tested them yet. But do they
look OK, generally? Since they are new functions, not modifying existing code,
adding them would be very low risk, right?
Yes, adding new functions that do not modify existing code
would be low risk.  You just need to verify that they work.

Bob, if you think it's ok to add these two functions and
you have reviewed the patch, I can take care of the mechanical
part.
Actually, I can do the work as long as you guys approve of the changes.
Assignee: relyea → nicolson
I don't have any problem. I do have some comments on the code:

1) we probably should preserve wincx from the source key/private key.
2) I don't think we have ever tested copy object, at least for copying to token
objects. I think it should work (as long as it is calling handle object at the
bottom).

bob
Priority: -- → P1
We can add a symmetric key, but it doesn't show up because of 130699, so it's
not useful. I'm adding 130699 as a blocker of this bug.
Depends on: 130699
No longer depends on: 130699
Depends on: 130699
Moved to 3.4.1.
Target Milestone: 3.4 → 3.4.1
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
Set target milestone to NSS 3.5.
Target Milestone: 3.4.1 → 3.5
Target 3.6.
Target Milestone: 3.5 → 3.6
Bob, could you work with Jamie to decide whether
his patch can be checked in in the 3.6 timeframe?
Yes, he should check in his patch in the 3.6 time frame. It would also be good
to test the patch to make sure it actually works, but I wouldn't hold 3.6 up in
the failure case.

bob
Attached patch updated patchSplinter Review
Improved patch. Includes the header file and nss.def changes.
Also, we need to get a RW session before we can create a new token object.
Attachment #71794 - Attachment is obsolete: true
Attachment #100344 - Flags: review+
Comment on attachment 100344 [details] [diff] [review]
updated patch

Looks good
Checked in on trunk.

/cvsroot/mozilla/security/nss/lib/nss/nss.def,v  <--  nss.def
new revision: 1.84; previous revision: 1.83

/cvsroot/mozilla/security/nss/lib/pk11wrap/pk11func.h,v  <--  pk11func.h
new revision: 1.34; previous revision: 1.33

/cvsroot/mozilla/security/nss/lib/pk11wrap/pk11skey.c,v  <--  pk11skey.c
new revision: 1.56; previous revision: 1.55
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: