Open
Bug 254524
Opened 20 years ago
Updated 2 years ago
Support the CKA_TRUSTED standard PKCS#11 trust bit
Categories
(NSS :: Libraries, enhancement, P2)
Tracking
(Not tracked)
NEW
People
(Reporter: julien.pierre, Assigned: rrelyea)
Details
The current PKCS#11 specification (v2.20) defines the following attribute. This attribute was added in version 2.11 . The following are direct quotes from the spec : "CKA_TRUSTED - CK_BBOOL - The certificate can be trusted for the application that it was created." Later : "The CKA_TRUSTED attribute cannot be set to CK_TRUE by an application. It must be set by a token initialization application or by the token's SO. Trusted certificates cannot be modified." Even later : "The CKA_CERTIFICATE_CATEGORY and CKA_TRUSTED attributes will together be used t map to the categorization of the certificates. A certificate in the certificates CDF will be marked with category "token user". A certificate in the trustedCertificates CDF or in the usefulCertificates CDF will be marked with category "authority" or "other entity" depending on the CommonCertificateAttribute.authority attribute and the CKA_TRUSTED attribute indicates if it belongs to the trustedCertificates or usefulCertificates CDF ." CKA_TRUSTED is also defined as a public key attribute : "CKA_TRUSTED - CK_BBOOL - The key can be trusted for the application that it was created. The wrapping key can be used to wrap keys with CKA_WRAP_WITH_TRUSTED set to CK_TRUE ." Also as a secret key attribute : "CKA_WRAP_WITH_TRUSTED - CK_BBOOL - CK_TRUE if the key can only be wrapped with a key that has CKA_TRUSTED set to CK_TRUE . Default is CK_FALSE . CKA_TRUSTED - CK_BBOOL - The wrapping key can be used to wrap keys with CKA_WRAP_WITH_TRUSTED set to CK_TRUE ." I think it might be useful to support the certificate attribute for CKA_TRUSTED. The reason is that the JDK PKCS#11 provider makes use of this attribute to expose certificates from tokens through its keystore interface. It appears that certs that don't have either this flag or a private key are currently invisible to the JDK applications, for example any certs in the root cert module, or CA certs in softoken. I consider this to be mostly a flaw in the JDK implementation, and I have given the JDK team a definition of our proprietary trust flags, so that they could query them and make better choices, but they haven't agreed to do this yet as they are non-standard. Outside of the JDK issue, however,we need to decide whether we want to implement CKA_TRUSTED. If so, I'm not sure how we should implement it . The spec is quite a bit too vague for my taste on the actual use of this bit. We would probably map certain states of our trust bits to CK_TRUE for this flag. I don't know what the mapping algorithm should be. Also, the spec says trusted certificates can't be modified, and that just doesn't seem to fit with our current model where no certs have that property as far as I know. Comments on this are welcome .
Reporter | ||
Updated•20 years ago
|
Severity: normal → enhancement
Priority: -- → P2
Reporter | ||
Updated•20 years ago
|
Target Milestone: --- → 3.10
Reporter | ||
Updated•19 years ago
|
Target Milestone: 3.10 → 3.11
Updated•19 years ago
|
QA Contact: bishakhabanerjee → jason.m.reid
Reporter | ||
Comment 2•18 years ago
|
||
This is in Bob's area, so I'm reassigning this bug to him.
Assignee: julien.pierre.bugs → rrelyea
Updated•18 years ago
|
QA Contact: jason.m.reid → libraries
Comment 3•15 years ago
|
||
Unsetting target milestone in unresolved bugs whose targets have passed.
Target Milestone: 3.12 → ---
Comment 4•14 years ago
|
||
Here is a recent request that reiterates the desire for support of this feature. On 4/14/2010 5:22 AM, wei deng wrote: > I am an engineer working in mozilla China, I'm going to provide a > solution for Chinese banks which support IE only in China now. The > problem I met is that: > > There are many vendors who supply smart-cards for banks, they have > implemented the pkcs#11 modules (maybe implemented most parts of > pkcs#11). There are two kinds of certificates in the smart-card, one for > personals, and one for bank which should be added to the clients' > trusted certificates list. We can add their pkcs#11 security module into > the secmod.db which is done by an installer made by banks. So, when > starting Fx, it loads all the security modules in the secmod.db and load > certificates into certificates list through PKCS#11 APIs aotumatically. > Then we can see the security modules in the Fx security devices list and > the personal certificat in the certificates list. I am not familiar with > the PKCS#11 APIs, maybe they did not implenment some, so Fx could not > load the certificat for bank into the trusted certificates list. We can > get the certificate for bank now, how to load it into Fx as root > certificate by other programme, not automatically? I believe the problem preventing the bank's cert from being trusted is lack of support for the CKA_TRUSTED attribute being supplied by the bank's PKCS#11 module.
Assignee | ||
Comment 5•14 years ago
|
||
One problem with CKA_TRUSTED is there is not definition for what it is trusted for. "CKA_TRUSTED | CK_BBOOL | The certificate can be trusted for the application that it was created" In general there are a couple of other attributes that it would be useful to parse as well unfortunately it's not on my priority queue. I welcome patch submissions;). bob
Comment 6•14 years ago
|
||
Bob: can we interpret CKA_TRUSTED to mean the certificate is trusted for all purposes? We'll need to deal with the same issue in the PEM module because the CA PEM files don't tell us what they are trusted for, either.
Assignee | ||
Comment 7•14 years ago
|
||
I would be reluctant to add "all" purposes. SSL server and Email should cover the most important situations. I think I would drop object signing. My point was the spec sort of leaves it open. We have to decide how we interpret it. In the PEM situation, it's a little more clear that they mean 'all' purposes, though, again, I think we hold back on object signing. bob
Comment 8•13 years ago
|
||
I might be wrong, but perhaps there is a way to restrict trust to appropriate domain. This could be deduced from certificate type and/or key usage, provided these extensions are present on the certificate, and consistent.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•