Keith Moore wrote:
>> > If you're in the US, you have to pay homage (literally) to RSA to
> > develop any implementation of TLS.
Hey, I found section 9 in the RFC... Maybe this isn't true after
all... (why is this stuff always buried?)
> is this really true? the default mandatory TLS ciphersuite is
> TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, which (AFAIK) doesn't use
> any RSA-controlled technology.
I really don't know; most public-key stuff seems to be controlled in
some way by RSA, and I don't know enough about the Diffie-Hellman
stuff to know if it falls under the RSA patents, or if it is even
secure enough to be considered as a replacement for RSA should it
*not* fall under the patents. (Nor do I know if it is covered by
patents in other countries or falls under export/import restrictions.)
I think before any decision is made on issue 32 we need to determine
if requiring TLS in clients is feasible; i.e. are there existing TLS
products or tools for all/most platforms, what legal concerns are
there, etc. If it turns out that a free, compliant IPP implementation
cannot be produced with TLS without export restrictions, then I think
we have no choice but to drop the TLS requirement and stick with
Digest, or have the optional TLS support in the client requirements.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com