- From: <michael.mccormick@wellsfargo.com>
- Date: Thu, 5 Jul 2007 22:37:04 -0500
- To: <stephen.farrell@cs.tcd.ie>
- Cc: <public-wsc-wg@w3.org>
I think what you're proposing sounds consistent with the recommendations presented in http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals/CertErr -----Original Message----- From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org] On Behalf Of stephen.farrell@cs.tcd.ie Sent: Thursday, June 28, 2007 1:42 PM To: public-wsc-wg@w3.org Subject: ACTION-240 :TLS errors... The action called for me to do a review of TLS errors. I went through the RFC and found the attached. Basically, I think that the only thing the normal user should need to see is "secure connection error" (or whatever). Anything more should be a click-through to get more detail and that detail should I think be intended for sys admins and not for users. There is probably no benefit in differentiating any of the errors otherwise, since the PKI and authorization stuff is afaik generally not useful. The former because no-one knows what a cert is, the latter because I don't think anyone does authorization at that layer - its done by the web server. I don't see any point in tell normal users about crypto or other errors. So, I'd argue to add some text that only one TLS error ever be shown, though I'm not sure how that'd be best done. Regards, Stephen. PS: There's one potential additional thing - the gmt_unix_time value in the ClientHello message could in principal cause an error if a server required the time to be fresh/recent. But I don't think that's done, is it? If not, then we could also add a proposal that servers don't, in fact, cause an error for that reason. Maybe something to raise with the TLS WG in the IETF as a potential future correction.
Received on Friday, 6 July 2007 03:37:27 UTC