>This was something of an eye-opener. It's so simple. We should have
>been doing this all along. There was never any reason to send
>passwords in the clear (well, uuencoded), given HTTP's two-round-trip
>authentication mechanism.
>
>Why is this nifty proposal tucked away in a corner? Why didn't I hear
>about it before now? I thought I was pretty tuned in to this sort of
>thing...
This proposal utilizes RSA MD5 encryption. If you have this
capability, why not go all the way to SSL (or SHTTP)? It would
make much more sense.
>For the longest time, I was under the impression that the web user
>base would have two choices:
>
> 1. Use a free browser, and access only public information, or
> send your password essentially in the clear to subscribe to
> for-pay info.
>
> 2. Use a commercial browser that supports the security
> options (SHTTP, SSL, kerberos...) supported by the services
> you use.
>
>The reason I believed this was that real security is to expensive to
>develop to give away (and it almost always requires a license of some
>kind...).
I don't see how this proposal fixes this problem. It requires MD5 which
will require a license from RSA. How does this not fall into your class
2 space? As long as I am in that space, I would much prefer a protocol
which has been widely adopted by the financial community (e.g. SSL).
-Jon