RE: ACTION-240 :TLS errors...

2nd that, but even more generic "connection error"

Site is not working correctly, it is broken.

If anything goes wrong with security services, we are not in a position
to determine risk to user. 

User and customer service can figure out next steps. Browser provides
click through interface to connection details including security info.

Bill D.




-----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 2: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 Thursday, 28 June 2007 18:57:51 UTC