Vin McLellan <[EMAIL PROTECTED]> writes:
> When SSL/TLS was brought to the IETF, there was some sort of special
> arrangement -- a concession to the huge SSL installed base (among consumers
> and commercial developers) which was accustomed to using RSA-based SSL with
> RC4 -- which acknowledged the proprietary RSAS ciphers as an acceptable
> alternatives, but not the required options, within the new TLS standard.
Yes, but the issue here was never RC4. Rather, it was RSA.
> Since D-H popped free of patent restrictions, having served its
> time, the standards-makers have tried -- as noted above -- to celebrate its
> non-proprietary status by making it the "Mandated" key-exchange scheme in
> their efforts to standardize the most successful RSApkc-based commercial
> protocols: SSL/TLS and S/MIME.
>
> Despite the demand for RC4's relative efficiency, however, I think
> the IETF's TLS WG was uncomfortable with the idea of pairing a free
> key-agreement/signature mechanism with a proprietary (copyright, if not
> trade secret) RC4 cipher. I think they fudged it by referencing the
> non-Rivest ARC-4 source, but still labelling the new TLS ciphersuites as
> including "RC4."
I don't believe this was the case. The original SSLv3 drafts
did not have DH/DSS/RC4 support. TLSv1 continued this.
The evidence that this was simply a glitch is that
DH_anon _was_ defined with RC4.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
PureTLS - free SSLv3/TLS software for Java
http://www.rtfm.com/puretls/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]