Open Bug 154246 Opened 20 years ago Updated 15 years ago
Smartcard portability issues with CA chains
Note that this is a high-level tracking bug, meant to have dependencies to other NSS bugs. Assuming that the goal of smartcards is to be able to port your certificate from a computer to another with minimal setup, other than the one-time reader & driver installation, there is still a hole in NSS related to CA chains. Currently, our P12 import function in NSS does not import CA chains onto the hardware token, even though it is capable of storing them. This means that when you come to a new computer and put in your smartcard, you need to go fetch the root CA in your application first before you can use the cert in your card for anything. The solution for this is to have an alternate P12 import function provided by NSS that imports not only the user certs but also the entire chain of certs into the hardware token. There is already an enhancement request for this, 142889. The other problem is that the CAs also need to be trusted. There are several solutions to that problem. One is to always use certs that have a root CA that exists in the client application. The other would be to store the trust on the token. Unfortunately, there is no standard way in PKCS#11 to do this.
Same issue during cert enrollment. As far as improving the portability index of a smart card solution, there are two cases to consider: 1) Organizations whose PKI chains to a trusted root built in most browsers. When a user of such an org gets a cert from the CA (an intermediate) it would be sufficient to insert the ee cert and the intermediate. The root is not needed, and storing trust in the card is not needed to achieve the goal of portability. I think that this case covers most cases. 2) The root is not one commonly built in most browsers/OS. In this case, we would want to be able to store the entire chain, and the trust for the root. Note that many smart cards (including ActiveCard CAC cards) do not have enough space to store all that is needed in this case. On the application side, it would also be tricky to design UI that would guide the user via the various options.
The base support is there in NSS to handle these cases, the problem is how do we decided at issuance time how to configure the smart card. To expand on Stephane's comments. Environments: 1) All intermediates and roots are so ubiquitous that every potential client already has them. This is the environment we have been assuming, and isn't very far off our typical usage (Stephane & I can use either of our smart cards in the other's environment because the intermediates are already there). Minimum: User certs & keys on token, Intermediates/Roots not on token. 2) Roots are ubiquitous, but intermediates aren't. This would be something like the DOD deployment. This is also our environment if we try running in fresh profiles on machines, or we issue smart cards to users who didn't do their enrollment at their desk. Minimum: User cert & keys on token, Intermediates on token. NOTE: in environments where there is only roots with no intermediates environments 1 & 2 are the same. 3) Roots are not ubiquitous. This would be something like AOL sales people logging in from remote kiosk type machines. Minimum: User cert & keys on token, Intermediates on token, Root certs on token with associated trust objects. Environment 3 is the hardest because we have to 1) store more data, and 2) store objects that token software may (probably won't) recognize (trust objects). Environment 3 is also a ways off because you need the following to be ubiquitous: card readers, smart card enabled and configured software. It's probably to soon to expect usable deployments, but its the right time now to check that we have the right software in place to handle such deployments. The real question is, who or what decides how many certs to put on the token: Is it function of the token (some value configured at token install time)? Some tokens are too small to store all the certs. Is it a function of the cert request? Should we instead always try to store the intermediates? When should we try to store root and trust objects? What should we do if these fail? My current leaning is to always try to store the intermediates in the token as well as in the local database. This allows both environments 1 and 2 to work. Environment 3 sounds like a function of the cert request, so we would only try to store root certs with trust on the token if the user requested it. It should be part of the CMMF request, so the UI would be on the issuer's side. bob
From a deployability perspective, I think "best practices" would be to: - always inject the necessary intermediates onto a user's card (at issuance time, for example) since those intermediates are necessary to validate the chain and use those certs. - assume only that the top-level, public roots are available to the user. - inject the entire cert chain along with the end-entity cert, for closed environments, and in situations where user certs don't chain up to public root CAs. At least, that's what I'm planning for. All of this works as long as we don't need to store trust bits for the certs stored on the card. Not sure how to address that. BTW: A 32K smartcard should have enough space to store 4 or 5 certs. A 32K card is quickly becoming the low-end so we shouldn't constrain ourselves too much by today's technology. Moore's law being what it is, ya know.
P2, not an NSS vulnerability. Business impact.
Priority: -- → P2
QA Contact: bishakhabanerjee → jason.m.reid
Assignee: wtchang → nobody
QA Contact: jason.m.reid → libraries
You need to log in before you can comment on or make changes to this bug.