On 12/01/2008 06:57 AM, Frank Hecker:
Eddy Nigg wrote:
Getting a certificate happens at some CAs already during the
registration process (cough, cough).
This is an interesting point, which I think supports at least some of
Ian's arguments. What you've done is to provide a real incentive for
users to get client certificates, certificates that can then be
repurposed for S/MIME email or other uses.
Well, actually we were exploring ways to facilitate user accounts
without compromising on security. Our "old" CA infrastructure had
nothing like an account exactly for this reasons. Basically we couldn't
rely on anything which required user input like user names and passwords
(because of the risk of getting phished, with us being a potential
target), hence we opted for client certificate authentication eventually.
But in this case users are willing to go through the minor hassle of
getting a client cert because they're motivated to get those super-duper
free SSL certificates, and they need the client cert to access the
administrative interface. It's a clever way of getting around the problem.
We could have opted for using only the authentication bits for this
purpose certificate, but clearly recognized the added benefit for not
requiring the user to jump through the same process again just to get a
client cert, second obviously also to promote S/MIME further.
> especially if none of your friends and other
> correspondents have one. (It's the network effect in reverse.)
>
So they get one :-) And it usually goes like "Hey, what's that, I want
one too..."
Considering the amount of public client certs stored in my TB, it
seems that many of the somewhat more technical orientated audience are
A) able to use it, B) actually using it. And not all of them are geeks
either.
With all due respect, this is merely anecdotal evidence.
Yes, certainly, I'm not a typical example, it was still interesting to
realize that I've got hundreds of other peoples public certificate in my
store. And from all brands and CAs in addition to that.
IMO the only
two metrics of interest for S/MIME email are a) the fraction of email
users who have personal certs usable for S/MIME; and b) the fraction of
all email messages that are send using S/MIME.
However don't be mistaken, there are many subscribers which come
solemnly for the client certificates. I don't know the reasons nor did
we ever make a study, but the number is much higher than some here would
prefer us to believe.
To be clear, I don't think that S/MIME email is irreparable.
I must ask if it's broken at all? It could be made even more convenient,
but it's certainly not broken to the extend that it needs reparation...
I think it
could benefit from an improved UI in products like Thunderbird and more
attention to making the initial "bootstrapping" process more automatic
and invisible. (For example, when a user gets a certificate, have
Thunderbird automatically offer to send a signed message with the cert
to all people to whom you've sent mail, or all people in your
addressbook, or whatever.)
I think I wouldn't want that, but it's maybe an idea of some benefit to
some users. Not sure...
And as noted above, I think a fundamental
problem is providing more incentives for users to get client certs,
particularly outside the context of S/MIME proper. (For example, have
some interesting web service that uses client certs for authentication.)
I think that client auth would really help solve some huge problems out
there. Incidentally, many OpenID providers have opted exactly for this
type of authentication most likely because of the higher risks involved
with having only one authoritative provider for all site authentications
when using OpenID. I certainly believe that financial institutions
should use it (more) as well.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: [EMAIL PROTECTED]
Blog: https://blog.startcom.org
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
