Open Bug 154255 Opened 19 years ago Updated 10 years ago

storage of trust on hardware tokens


(NSS :: Libraries, defect, P2)



(Not tracked)


(Reporter: julien.pierre, Assigned: rrelyea)


(Blocks 1 open bug)


There is no standard for storing trust in PKCS#11 . This poses a problem when
manipulating certificates stored on hardware tokens. Specifically, it gets in
the way of being able to easily port a smartcard from one computer to another
without additional setup. We should propose a method of storing trust to the
PKCS#11 committee.

In the meantime, I can think of the following workaround. It's hackish, but I
think it would work :

If a hardware token contains a leaf user certificate with a full chain, and we
don't have a trust object for the root CA, we could implicitly trust the root CA
for all usages in the context of the verification of the leaf user certificate
(but the root CA would not be trusted in any other context). This change would
only affect the cert verification function and wouldn't make the root CA trusted
for anything else.
Blocks: 154246
Assigned the bug to Bob.
Assignee: wtc → relyea
I think the usual assumption is that any certs on a hardware token 
are trusted, especially if the user has authentication to the token.
That was the operating assumption on Fortezza cards, as I recall.

The vast majority of PKCS#11 tokens exist solely to hold a user's own
cert (chain) and private key, all of which are implicitly trusted by 
the user.

NSS's penchant for making everything be a PKCS#11 token, and storing 
third part certs in a PKCS#11 token means that one of NSS's DB tokens 
is (er, can be) the exception to the rule, in that the DB token can have 
untrusted certs.  But again, I think the DB token is the exception to 
the rule for PKCS#11 tokens.

I think we ought to impllictly trust certs from PKCS#11 tokens other than
NSS's own software tokens.
Actually we don't implicitly trust certs in hardware tokens unless they are so

There are two ways to mark a cert for trust in a hardware token: The old way
(cert CKA_ID with only '0''s in the ID). This is how fortezza worked. Certs
marked this way are trusted for everything (I believe).

The current way (Trust objects in tokens).

Just an opinion: Since trust objects in PKCS 11 devices don't seem to be 
a priority for token vendors, we ought to find another way to accomodate
real world tokens.
Priority: -- → P2
QA Contact: bishakhabanerjee → jason.m.reid
QA Contact: jason.m.reid → libraries
You need to log in before you can comment on or make changes to this bug.