Open
Bug 1245777
Opened 8 years ago
Updated 2 years ago
Expose EC_NewKeyFromSeed() to PKCS#11
Categories
(NSS :: Libraries, defect, P3)
NSS
Libraries
Tracking
(firefox47 affected)
NEW
Tracking | Status | |
---|---|---|
firefox47 | --- | affected |
People
(Reporter: ttaubert, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
6.65 KB,
patch
|
rrelyea
:
review-
|
Details | Diff | Splinter Review |
To properly support WebCrypto PKCS#8 imports we need a method to compute the point on the curve for a given secret value. It would also be nice to use that same method for PKCS#8/JWK imports to check whether (x,y) = G*d for a given curve.
Reporter | ||
Comment 1•8 years ago
|
||
Attachment #8715714 -
Flags: review?(rrelyea)
Comment 2•8 years ago
|
||
Comment on attachment 8715714 [details] [diff] [review] 0001-Bug-1245777-Expose-EC_NewKeyFromSeed-to-PKCS-11.patch Review of attachment 8715714 [details] [diff] [review]: ----------------------------------------------------------------- So we can't just add new functions to PKCS #11. Also, you are using a pretty low level value when I think the high level primitive is you have an ECC private key and you want the public key falue. In that case I think we can define a CKM_NSS_PUBLIC_FROM_PRIVATE as a derive mechanism. We'd call C_Derive() with the handle from the private key. It will return a handle to the public key. For ECC it would use EC_NewKeyFromSeed() to get the private key, DH, DSA would use DSA_NewKeyFromSeed(), and RSA would use build_rsa_from_primes() [you'd have to export a function from freebl to softokn to handle this. Ideally your protocol will generate an ECC private key, though you could build it using C_CreateObject() and setting all the right attributes. It's better if you don't need to do that. Usually if you are doing that it means your protocol code is carrying to many secrets in the code itself and not leaving them in the token. bob ::: lib/softoken/fipstokn.c @@ +1566,5 @@ > + > + return NSC_CurvePointFromSecret(pParams, ulParamsLen, > + pSecret, ulSecretLen, > + pData, ulDataLen); > +} We can't just add functions through the PKCS #11 interface without working through the PKCS #11 oasis group. PKCS #11 is a standard, and new functions are a no-no. We could create a private mechanism, and use once of the existing functions on the mechanism.
Attachment #8715714 -
Flags: review?(rrelyea) → review-
Reporter | ||
Updated•7 years ago
|
Assignee: ttaubert → nobody
Status: ASSIGNED → NEW
Reporter | ||
Updated•7 years ago
|
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•