Closed Bug 142889 Opened 18 years ago Closed 17 years ago

slot semantics for SEC_PKCS12DecoderStart

Categories

(NSS :: Libraries, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 142867

People

(Reporter: julien.pierre, Assigned: julien.pierre)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

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) ?
Blocks: 142867
No longer blocks: 142867
Priority: -- → P2
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.
This patch switches from CERT_ImportCert to PK11_ImportCert to import CA certs.
It also has a nickname generation patch for 142868.
Attachment #82724 - Flags: needs-work+
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
Blocks: 154246
Blocks: 154251
Assigned the bug to Julien.  Target NSS 3.6.
Assignee: wtc → jpierre
Target Milestone: --- → 3.6
Target Milestone: 3.6 → 3.7
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
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.