254524 - Support the CKA_TRUSTED standard PKCS#11 trust bit

Status: NEW

(NSS :: Libraries, enhancement, P2)

Description

[Julien Pierre]

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 .

Comment 1

[Julien Pierre]

Too late for 3.11 .

Comment 2

[Julien Pierre]

This is in Bob's area, so I'm reassigning this bug to him.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Unsetting target milestone in unresolved bugs whose targets have passed.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 5

[Robert Relyea]

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

[Wan-Teh Chang]

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.

Comment 7

[Robert Relyea]

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

[Eric Devolder]

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.