Closed Bug 1473806 Opened 7 years ago Closed 6 years ago

3.38 certutil -R cannot use EC orphan key

Categories

(NSS :: Tools, defect)

3.38
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: shihping.chan, Assigned: kjacobs)

References

Details

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID: 20180611123338 Steps to reproduce: # Works with RSA orphan key Fails at pubkey = SECKEY_ConvertToPublicKey(privkey); # works for RSA, what about EC? 1. create EC orphan key id is a9808349a2c7c3a6bcf603e7c08ec3f068fdfeb 2. certutil -R -k a9808349a2c7c3a6bcf603e7c08ec3f068fdfeb2 -a -s "CN=testing" Actual results: $ certutil -f password -d sql:. -R -k a9808349a2c7c3a6bcf603e7c08ec3f068fdfeb2 -a -s CN=testing certutil: Could not get keys from cert a9808349a2c7c3a6bcf603e7c08ec3f068fdfeb2: SEC_ERROR_BAD_DATA: security library: received bad data. a. Do we have enough in private key to derive the public key (i.e. store named curve) b. certutil does not accept -q nistp256 as a hint to get the public key from the private key certutil -q: specifies a PQG file for DSA keys (-k dsa) or a named curve for EC keys (-k ec) Expected results: -----BEGIN NEW CERTIFICATE REQUEST----- MIICVzCCAT8CAQAwEjEQMA4GA1UEAxMHdGVzdGluZzCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAK0wje4f8ym7/6NxMmxpNU3r03wh8FPLmpjVb+m6ipdv AeQb3u8p1SuqCHzURy9MZlaaJFYEq5eBvrdqwT2t+lQnNj7M3AgpjZJUufv6RagO nMuGUM3vEdYF/MyY9N77mbKuYp7ilVEFf1jTVyWndM87H14h2eOdxYelTxlheBTe
For EC orphan keys in SECKEY_ConvertToPublicKey we fail at getting CKA_EC_POINT attribute of the private key. GDB: 1233 pubk = (SECKEYPublicKey *)PORT_ArenaZAlloc(arena, (gdb) n 1235 if (pubk == NULL) { (gdb) pubk Undefined command: "pubk". Try "help". (gdb) n 1239 pubk->keyType = privk->keyType; (gdb) n 1242 pubk->arena = arena; (gdb) print pubk $1 = (SECKEYPublicKey *) 0x5555558494c0 (gdb) n 1244 switch (privk->keyType) { (gdb) n 1263 rv = PK11_ReadAttribute(privk->pkcs11Slot, privk->pkcs11ID, (gdb) n 1265 if (rv != SECSuccess) { (gdb) rv Undefined command: "rv". Try "help". (gdb) print rv $2 = SECSuccess (gdb) n 1268 rv = PK11_ReadAttribute(privk->pkcs11Slot, privk->pkcs11ID, (gdb) n 1270 if (rv != SECSuccess || pubk->u.ec.publicValue.len == 0) { (gdb) print rv $3 = SECFailure (gdb) Comments: 1. The CKA_EC_POINT is not required in PKCS#11 (however Luna HSM is an example that has this attribute; I guess the softokn doesn't?) 2. If the caller provides a hint to the curve -q nistp256 maybe use that to derive the public key Some message: Warning: could not extract public key from orphan key 0xNNNNNNNNNNNNNNNNNNNNNNNNN Deriving public key using curve CCCC
Oops I realise in my previous comment that the "raw" private key isn't actually available to compute the public key from the named curve. Only way is to have CKA_EC_POINT as an attribute of the CKO_PRIVATE_KEY... Is this bug better reframed as an RFE to softokn?
Assignee: nobody → kjacobs.bugzilla
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

try: -e all -t all -u all

gtests/pk11_gtest/pk11_import_unittest.cc

Pick up the gtest changes from patch https://phabricator.services.mozilla.com/D33262#change-GhQvkCURcwqg
Update the gtest to accept dsa and dh keys as well.

lib/cryptohi/seckey.c
When converting private keys to public keys, if we can't find a cert, look for a public key. If none found use the CKM_NSS_PUB_FROM_PRIV derive mechanism to create one.

lib/pk11wrap/pk11priv.h
lib/pk11wrap/pk11skey.c
Implement an internal function that can be used to derive a public key from a private key. Give appropriate warnings about what has to happen to make this public.

lib/softoken/lowkey.c
Add code to the low level derive public from private to actually calculate public componants that aren't stored in the private key.

lib/softoken/pkcs11i.h
lib/softoken/pkcs11.c
Add helper function to populate a PKCS #11 object from a NSSLOWKEYPublicKey.

lib/util/pkcs11n.h
lib/softoken/pkcs11c.c
Implement CKM_NSS_PUB_FROM_PRIV.

re comment 2 yes. There's a similiar issue for DSA and DH. The patch above handles it.

Attachment #9068945 - Attachment is obsolete: true

Landed on NSS_3_44_BRANCH https://hg.mozilla.org/projects/nss/rev/c876cbe32c46

Is this needed on default, too?

Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.44
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: