This API takes a PK11Slot parameter. This is the slot to import the certificate and the associated private key to. However, the PKCS#12 file can contain a collection of certificates including CA certificates. Up until now, this API has imported all non-user certificates (these without private keys) to the softoken / certificate database. It can be argued that sometimes that's what the user wants, but not always. If I fix this function to import all the certificates to the slot that's passed in, it will change some applications behavior, including pk12util and PSM. I'm not sure of the way to go here. Should there be a new API with an additional argument to clarify where non-user certs are to be stored (eg. a second slot argument) ?
To be more concrete here : deep down into the PKCS#12 import code, we come to a choice between a PK11_ImportCertForKeyToSlot for user certs (that we have the private key for) or CERT_ImportCert. The later function always imports the certificate to the softoken, so all CAs end up in the softoken slot, rather than the slot passed in. Ian suggested using PK11_ImportCert. This would import the CA certificates to the same slot as the user certificates. This may or may not be the right thing to do. I have attached a patch that does this.
Created attachment 82724 [details] [diff] [review] Patch to import CA certs using PK11_ImportCert This patch switches from CERT_ImportCert to PK11_ImportCert to import CA certs. It also has a nickname generation patch for 142868.
Comment on attachment 82724 [details] [diff] [review] Patch to import CA certs using PK11_ImportCert this patch has problems with trust for CA certs
As discussed in bug 142866, PK11_ImportCerts does not set trust bits. Therefore this patch has a problem for CA certs - the trust bits are missing on the token after import. We need to clarify the upper-level P12 import API definition to decide which slot each type of cert is getting imported to. Logically I think they should all end up in the slot that's passed in. Unfortunately that's not what we have done in the past. So we probably need to maintain the legacy behavior for this function, and define new functions to get full control of the target slot for each cert.
Changing title to reflect the actual PKCS#12 decoding function in the library. The function I had listed was in the pk12util.c tool source.
Summary: slot semantics for P12U_ImportPKCS12Object → slot semantics for SEC_PKCS12DecoderStart
Assigned the bug to Julien. Target NSS 3.6.
Assignee: wtc → jpierre
Target Milestone: --- → 3.6
Moved to target milestone 3.8 because the original NSS 3.7 release has been renamed 3.8.
Target Milestone: 3.7 → 3.8
Bob, I believe your patch for 142867 also resolves this issue, by providing different options for the location of the CA certs.
yes, I believe it implements exactly what the problem description is for this bug. We can close this as a dup of the other.
*** This bug has been marked as a duplicate of 142867 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.