On 03/21/2009 09:32 PM, Ian G:
On 21/3/09 16:54, Eddy Nigg wrote:
Huu? No outcry about rudeness in mailing lists here?
Eddy, I agree that rudeness was carrying us away from the problem and
on to the personalities. Indeed, it's up to all of us to be be minded
of this. For reasons that are too wordy to be worth the bytes, I
didn't do it, so thanks!
Well, I just thought that I'd remind you about how outraged you were
when I said the same thing....besides that such comments were seen
allover many times and I think it's just a funny expression. Perhaps you
should offer to both of us some of your stuff so we'll have some fun
together ;-)
Now, to the problem. It seems that we have a consensus that client
certificates (in a client authentication role at least) are unusable
with the current system.
I think that the word unusable is far too strong. See, there are
improvements possible and most likely should be made at various levels,
but unusable? I can claim tens of thousands of active accounts using
nothing else than client certificate authentication. In the OpenID space
I know about Verisign and some other providers offering them too - with
StartSSL being a provider based solemnly on client cert authentication.
And, the way forward is more UI support [1], as suggested by Johnathan.
Yes, I think Johnath has a few ideas to make the UI better...
Now - long pause, deep breath - everything below which you mention
sounds to me as if you are trying to invent client certificate
authentication once again from scratch...well, it already exists and
mostly works fairly well...most of it below works more or less the way
you would like it to be...not sure what I'm missing or if you are
missing something here...
...or perhaps indeed learn to configure your servers properly and get
some advice on application programming, middle-ware, protocol layers and
sessions...
a. For every request for a client-cert, there would be a request from
low-level code to intermediate-level code for a key/certificate.
b. In the intermediate layer, that request would be matched against a
list of pre-established tuples like {domain name, certificate, action,
status}.
c. If the typle isn't found (which means the domain name wasn't
indexed) then the intermediate level code would pass the request up to
the higher-layer code to ask the user (pop-up?) :
* which certificate to use (if more than one available)
* whether to accept this choice:
+ once
+ for minutes (say 30 minutes, but configurable)
+ for now (in memory, not saved to disk) [2]
+ forever (save tuple to disk).
* whether to display the client identity in use
d. The intermediate layer returns the key/cert to be used via either
tuple matching or via user interface. Then, once the tuple is
set/saved, we have a good chance of transparent session restart.
How does that sound?
iang
[1] Yes, we noted that servers may be misconfigured. But, waiting for
the servers to be properly configured looks implausible, we might be
waiting for a long time, and even then we won't have solved the full
problem. It seems fairly clear that clients will *always* have to
deal with it, regardless.
[2] For my money, I want the "for now" option because I want to be
re-asked in a few days of what's going on ... and be forced to rethink
whether I want a long term relationship here or not. I don't want the
browser to store any relationship in any permanent store until I tell
it. That's just me...
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog: https://blog.startcom.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
