Related work: http://tools.ietf.org/wg/pkix/draft-ietf-pkix-certimage/
will IMHO be difficult to roll out because it mixes local GUI requirements with relying party ditto. anders ----- Original Message ----- From: "Kai Engert" <kaie-dontspa...@kuix.de.example.test> Newsgroups: mozilla.dev.tech.crypto To: <dev-tech-crypto@lists.mozilla.org> Sent: Sunday, March 28, 2010 15:16 Subject: Re: Improving SSL client auth and bad certificate reporting innon-browser applications On 28.03.2010 06:19, Nelson B Bolyard wrote: > The sequence of events in the dialog is likely, IMO, to give the users the > impression that client authentication is a user-initiated act, rather than > a server initiated act. It seems to say to the user, "if you want to > authenticate to this server with your cert, you select your cert and click > here". yes: ... you click here (the icon), you select your cert, then the browser or the user will reload ... > I gather that the intent is that the browser will (re)initiate an > https request to the server(s) in response to that click. yes, after the user selects a different authentication (use a cert, use a different cert, don't use a cert) in the dialog. > But there is no > assurance that the server will request client auth when the subsequent > requests are sent. > > I think this is likely to lead to a lot of inquiries/complaints from users, > asking "why can't I authenticate to this site whenever I want to?". Thanks for making us aware of this scenario (server requests auth on first connect, but doesn't on subsequent connects). I think we can address your scenario with the following application behaviour: If we're connecting to a site and the site requests client auth, we will look up our stored configuration. If we can't find any stored configuration for the site, then, do the same as we do today, and show a prompt (the same prompt as used for the configuration, which is similar to today's client auth prompt). It will be a one-time automatic prompt (for this site). The action chosen by the user (use or cert or do not use a cert) can be remembered as the future default (for this site). In the future, if the user connects to the site, we don't need to bother the user with a prompt. We'll either use a cert or not use a cert, and indicate it showing the respective icon (allowing the user to click and change her mind). Would this work? In addition, a site that requests a client cert only once, and on failure will never ask again, probably isn't very smart. I'd expect any reasonable site must deal with the possibility that a user doesn't send a cert on first attempt. A site must make it possible to retry in some way. If the user notes the request to authentication, then configures to use a cert, then uses the site's mechanisms to retry, I think we have achieved our goal. Does this make sense? > Also, what are those icons supposed to represent? The first icon is supposed to show a closed barrier, like the ones used at streets on border crossings, or at railway crossings. It means site requested a cert, but we're not sending a cert to the site. The second icon is supposed to show an open barrier combined with a passport. It means a site requested a cert, and we're sending a cert. > It looks to me like a > book and a light beam, where the book eventually interrupts the light beam, > much as objects on a conveyor belt at a supermarket checkout break the > light beam which stops the belt. Perhaps that's not what it's showing me, > but if it is, that doesn't suggest to me anything having to do with > authentication. But this is a minor point. I'm sure that suitable icons > can be found. I'm not a graphics artist. I don't propose to use these icons as is. But people asked for a mockup, and here you are. :-) Kai -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
