What do you think such a warning would accomplish? There are no ways to mitigate malware (bad client or otherwise), and using passwords make it even easier.
End users are not going to read the specification and service providers have absolutely no alternatives. As for the example, the issue you described with accepting every CA is completely irrelavent because changing the root certificates will be done in secrecy by the installed malware. I have not seen any argument showing how such a warming makes any difference in deploying OAuth (or not). Can you propose text and show how it mau affect implementation? EHL On Sep 6, 2011, at 17:50, "Melinda Shore" <melinda.sh...@gmail.com> wrote: > On 09/06/2011 04:23 PM, Peter Saint-Andre wrote: >> I just looked at the most recent specifications for TLS (RFC 5246) and >> secure shell (RFC 4253), which I think we'd all agree are two quite >> successful security technologies. Neither of those specs says anything >> about not protecting humans users from malicious clients that perform >> keylogging to capture security-critical data the user might enter. > > I think there's an argument to be made that the user interface > is sufficiently different that those might not be a great model. > But it's also the case that there have been security problems > with both that may or may not have been avoided in part by > putting in warnings not to trust every crappy, random CA > certificate that wafts by, or not to respond "Sure - thanks!" > to every ssh host key you're offered. > > Melinda > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
