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