Open Bug 154255 Opened 20 years ago Updated 11 years ago
storage of trust on hardware tokens
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.
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 'marked'. 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). bob
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
You need to log in before you can comment on or make changes to this bug.