154255 - storage of trust on hardware tokens

Status: NEW

(NSS :: Libraries, defect, P2)

Description

[Julien Pierre]

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.

Comment 1

[Wan-Teh Chang]

Assigned the bug to Bob.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 3

[Robert Relyea]

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

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

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.