At 12:05 PM -0800 2/7/12, Joe St Sauver wrote:
...
This is actually a fascinating question, and one where the answer you
get for "Why don't people deploy client certs?" varies from person to
person. I attempt to capture a little of that in a talk I did a week
or so ago at Internet2/ESNet Joint Techs in Baton Rouge:
"Client Cert Deployment Models and Hardware Tokens/Smart Cards"
http://pages.uoregon.edu/joe/client-cert-models/jt-louisiana.pdf
It wasn't possible to do an exhaustive analysis of that question in
a 20 minute slot, but you can at least get an idea of what we're seeing...
I think there are multiple reasons why client certs have not taken off,
based on 20+ years of experience in the area. We provided a client
cert system for a financial firm in the early 90's. It was easy to
use, bootstrapped from the password-based system that the firm used.
But, because there were no good tools to allow users to move certs
and private keys among client machines, it was eventually turned off.
...
FWIW, even the Feds issue multiple certs, if only because some need to
be non-repudiable (e.g., for signing) while others need to be escrowed
for potential recovery (or authorized monitoring) of encrypted content
(at least in a Federal environment).
The 3-cert CAC is not what I was suggesting. (And the reasons there are
separate certs for sigs vs. key transport is because users need to
perform key recovery for themselves for old e-mail, rather than for
monitoring.) What I was advocating is certs with different IDs, each
appropriate for a well-defined set of contexts, issued by CAs that
are authoritative for identity in specific contexts.
That said, given my druthers, I'd prefer a single client cert to use for
MOST purposes, just as I prefer to use a single PGP/GPG key -- it's
easier, and reduces correspondent confusion.
It is easier, but is undermines privacy and raises the question of
what CA is appropriate for ALL contexts.
...
I'd also assert that the cost of the cert is trivial relative to the
cost of the secure storage device that might hold the cert (e.g., a
USB format hard token, or a smart card and reader).
The cost of managing a cert has a lot to do with the nature of the
relationship between the issuer and subject, and the liability that
the CA incurs as a result of issuing the cert. For example, I have
relationships with credit card issuers. They make money when I use my
cards. If they issued certs to me, that could be used in lieu of
plastic, because they believed the security could be better, I
probably would not pay for the cert.
...
I concur that multiple certs equal user confusion unless you can really
make it pretty darn clear (e.g., jsmith+sign...@example.com or
jsmith+encrypt...@example.com, for example).
not the sort of IDs I had in mind. I have an identity with Visa, with
Amex, with UA, US, Hertz, Avis, etc. Each is authorized to identify
me in certain contexts, and my ID is context specific. I also have a
relationship entities who provide e-mail services, and they are the
best entities to act as CAs when my e-mail address is the subject
name. It's not about signing vs. encryption, but more about what
entity is authoritative for identifying me.
...
An interesting approach, BTW, is the one that CILogon takes, leveraging
federated authentication to mint certs for secure access to cyber
infrastructure -- see http://www.cilogon.org/ for more information about
this approach, if interested.
federated authentication systems using certs generally seem to be
motivated because folks can make cross-certification work properly.
other federated auth systems seem to be based on having one org trust
another to assert and identity for a user know to the second, but not
the first. that's a recipe for secruity problems.
Steve
_______________________________________________
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey
