142866 - PK11_ImportCert fails to import CA cert trust bits

Status: RESOLVED INVALID

(NSS :: Libraries, defect, P2)

Description

[Julien Pierre]

CERT_ImportCerts takes a CERTCertDBHandle only. There is no way to specify a 
PK11Slot or NSSToken . As a result, CA certificates are always imported to the 
softoken / certificate database. We need a new API to do this.

Comment 1

[Julien Pierre]

Bob, Wan-Teh, please comment and set target milestone as appropriate. This might 
be a 4.0 item.

Comment 2

[Julien Pierre]

Ian suggested using PK11_ImportCert. However, that function needs a key handle, 
which is not available for CA certs. I tried to pass 0 which is 
CK_INVALID_HANDLE. The CA certs were imported seemingly successfully, but had 
not only no nicknames but also no trust bits. I did set includeTrust = PR_TRUE 
on PK11_ImportCert. This does not seem to matter.

Comment 3

[Ian McGreer]

Julien-

What you are doing is correct.  You should pass CK_INVALID_HANDLE if you do not
have a key.  The cert *should* have a nickname if you passed one, so I don't
know why that failed.  You're right about the trust -- that is certainly a bug.

Comment 4

[Julien Pierre]

I didn't pass a nickname (I still need to move the old nickname generation code 
to the PKCS#12 library for that to work) so I didn't expect one to show up. But 
I did expect at least the CA trust bits to work. I was not trying to import into 
a hardware token, just into softoken using the PK11_ImportCert API.

Comment 5

[Julien Pierre]

Since the API exists, the description is inaccurate. I'm reusing this bug for 
the behavior problem.

Comment 6

[Ian McGreer]

Attachment: grab cert->trust when includeTrust is true

This is a bit hacky, but I don't know how else to do it without changing the
API.  Basically, you set cert->trust with the desired trust *before* calling
PK11_ImportCert, and use includeTrust == PR_TRUE.  The end result should be an
import with the desired trust.

Normally, we'd prefer not to have cert->trust messed with outside of API calls,
or it won't represent the real world.  But I think it is okay in this case.

Comment 7

[Julien Pierre]

Thanks for the quick patch, Ian. It did not resolve the problem though. I will 
give you my patches to the PKCS#12 code that calls PK11_ImportCert and a test 
case to reproduce it very shortly.

Comment 8

[Robert Relyea]

Yes, I don't see mozilla using this functionality in 3.5. Setting to 4.0

Comment 9

[Julien Pierre]

Bob. It turned out the functionality existed in the form of PK11_ImportCert, but 
it doesn't work properly. I'm looking at using it to fix the PKCS#12 import code 
so we may need to fix it for 3.5 .

Comment 10

[Julien Pierre]

Ian : to test the problem, you should use the patch at 
http://bugzilla.mozilla.org/attachment.cgi?id=82724&action=view and apply it to 
the tip. 

Also get the P12 files from 
http://bugzilla.mozilla.org/attachment.cgi?id=79783&action=view .

Then run a script like this :

#!/bin/tcsh
certutil -d . -N
pk12util -d . -i /u/jpierre/p12/TESTQCLIENT_RAO.p12 -W 1234abC!
certutil -d . -L

The output will be :

In order to finish creating your database, you
must enter a password which will be used to
encrypt this key and any future keys.

The password must be at least 8 characters long,
and must contain at least one non-alphabetic character.

Enter new password: 
Re-enter password: 
TESTFROMRAO                                                  u,u,u
Belgacom E-Trust Primary CA for qualified certificates - Belgacom ,,   
Belgacom E-Trust Root CA for qualified certificates - Belgacom ,,   

As you can see, the CA bit / trust flags are missing in the certutil display.
If you use NSS 3.3 DSOs, the flags are fine.

Comment 11

[Ian McGreer]

Julien-

Your patch removes the call to CERT_ImportCerts, which was responsible for
setting cert->trust.  As is, cert->trust is NULL when PK11_ImportCert is called,
so that explains why it ends up NULL on the token.

Comment 12

[Ian McGreer]

Just to clarify, I stand by a proposal made in some other bug, that you should
go ahead and call CERT_ImportCerts, and then if the target token is *not* the
internal token, follow up with a call to PK11_ImportCert.  This is because
*most* tokens do not support trust (sure, some may, as Bob pointed out), and
even if they do there's really no harm in duplicating the CA chain in cert7.db.

Comment 13

[Julien Pierre]

Ian,

I'm not sure these are really the trust bits that are the problem or some other 
bits here. certutil shows the two CA (intermediate and root) have no bits at all 
after the import with my patch. I think this means they are not recognized as CA 
 certs, not just as trusted CA certs.

I also wonder why the PK11_ImportCertForKeyToSlot sets the bits for the user 
cert, but PK11_ImportCert does not set them for the CA cert.

Comment 14

[Robert Relyea]

It doesn't set any buts.

The IsUser bits are virtual bits which are set implicitly by the fact the
private key for the cert exists. There is not representation in the trust object
for this (though for compatibility, Softoken does set the user bits in the
physical database).

The missing bits on the CA's should not have any affect on their usage. the
CA_Peer bits are advisory only.

bob

Comment 15

[Robert Relyea]

That should have been "doesn't set any bits" (the u and i key are too close
together;).

Comment 16

[Ian McGreer]

I agree with Bob.  The "c,c," trust set by 3.3 is for the UI.  PSM detects valid
ca trust, and displays such certs in the Authorities tab.  This is an
application decision, not an NSS decision.

However, the PKCS#12 library did used to make that decision, by calling
CERT_ImportCerts.  libpkcs12 said, "This is user cert import, so I'll take it
for granted that any CA certs should be trusted as valid CA certs."  I think the
reason for doing this was purely for the client UI, so that users could visually
acknowledge that the chain was imported from their .p12 file.

I do not believe PK11_ImportCert should be making that decision.  It is okay for
it to take whatever trust is set on the cert, but I don't think it should be
setting default trust bits for all certs.  If you want CA certs to have valid ca
trust on import, you need to make that decision before calling PK11_ImportCert.

Comment 17

[Julien Pierre]

I'm closing this as invalid since it isn't the role of this function to set 
trust. The rest of the discussion can continue in bug 142889, about "slot 
semantics" for the p12 import function .