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]

Reply via email to