Open Bug 154246 Opened 18 years ago Updated 13 years ago

Smartcard portability issues with CA chains

Categories

(NSS :: Libraries, defect, P2)

defect

Tracking

(Not tracked)

People

(Reporter: julien.pierre, Unassigned)

References

(Depends on 2 open bugs)

Details

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.
Depends on: 142889
Depends on: 154251, 154255
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.