351258 - Storing trust anchors on smart cards/tokens

Status: RESOLVED WONTFIX

(NSS :: Libraries, enhancement, P3)

Description

[Eric Norman]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
Build Identifier: 

PKCS#11, as of version 2.10 (I think it is) provides for a mechanism such that certificates (really just the public key) can be marked as trusted on the smart card and that information communicated to the application through the PKCS#11 API.  It would be useful if trust anchors could be stored in smart cards and that the PKCS#11 interface in Firefox, Mozilla, etc. availed itself of this information thus enabling users to carry their trust anchors around wth them as well as their private keys, personal certificates, and so forth.

The PKCS#15 standard also supports a format standard of storage of trust anchors, but that's a matter for the OpenSC folks or card vendors.

Implementation note: most people think a trust anchor is the same thing as a "root certificate", and in many cases, there's no confusion.  However, it is possible for a trust anchor to be other than a self-signed certificate.

Just to be clear what I'm asking, I'm asking that if a trust anchor is discovered on a smart card or token, then the dialog about checking 3 boxes will   NEVER be shown to the user; NSS will assume that the 3 boxes have already been checked.

Reproducible: Always

Steps to Reproduce:
1.  Don't check 3 boxes (I don't think that helps much)
2.
3.

Actual Results:  
Certificate chain won't verify.

Expected Results:  
No warnings about failure to verity certificate chain.

See also ancient bug# 154255.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

I confirm that this is a request for enhancement.  :)
I concur that NSS should support and honor the PKCS#11 trust attribute from
PKCS#11 modules that support it. 

NSS gives the user the ability to override trust of any cert in any token. 
The trust information in NSS's own PKCS#11 DB slot can override the trust 
for any cert in any slot/token.  This provides a way for the user to set
trust on a cert in a PKCS#11 module that doesn't have any trust 
implementation.  It also allows the user to DISTRUST a cert that is marked
as trusted in a read-only token/slot.  

So, I don't think the 3 check boxes should (or will) disappear for tokens 
in PKCS#11 modules that support the PKCS#11 trust attribute.  But I think 
they should reflect the value of that trust attribute, when present, 
unless and until the user overrides it. 

Comment 2

[Eric Norman]

I have no problem with the notion that a user should be able to override trust information, and even concur that this is desirable.  The only disagreement I see here is in the area of human engineering; i.e. the user interface in this case.  Here's my thinking about that subject.

If a user goes to the trouble to store a trust anchor an their token, then I think it's impolite for the software to ask them to confirm that decision at least every time the token is inserted.  For example, by asking them to confirm that they intended that the three boxes be checked.  For one thing, usability studies have indicated that most users wouldn't come close to understanding what they are being informed about in such a dialog, even if the boxes are appropriately checked according to information on the smart card.   So why bother them with a dialog box that will be confusing?

In other words, I consider storing a trust anchor on a token to be equivalent to checking the three boxes the first time.  NSS doesn't ask for reconfirmation every time in that case.

As far as overriding the trust, I consider that an advanced operation and shuold be reachable through the normal certificate management mechanism that is available to day.

Reganding a different issue that bug# 154246 brings up.  There are also some who think that all the intermediate certificates that will be necessary for verification should be located and acquired during verification (the certificate discovery and path construction problem).  Hence the information that you really need to store on a token is your private key (to prevent access and usage) and your trust anchor (so that you don't have to trust what's in unknown equipment).  Yes, I realize that's not very complete and probably not even very workable.  But at least in theory, you don't need to also store intermediate certificates to preserve their trustworthiness.

Some also are thinking that the only trust anchor that you would have to store on your smart cart is that of your own organization.  That's one of the main ideas behind the bridge approach.  

Comment 3

[dftragenon88]

link website: http://157.245.53.11/

Comment 4

[agentogel188]

kunjungilah websiste kami hanya di http://178.128.214.30/

Comment 5

[buntut2d3d]

visit my website: http://46.105.174.178/

Comment 6

[boagencolok88]

http://www.gmj.ir/files/journals/1/articles/2775/submission/2775-1-20259-1-2-20221030.html