Michael,
The TLS Chair and the IETF Security Area Directors spent about 6 months
wrestling with this issue and delayed the publication of TLS in the
meantime. Hence I think you take the text in TLS as correct that this
is not covered by any RSA patents.
Carl-Uno
> -----Original Message-----
> From: Michael Sweet [mailto:mike at easysw.com]
> Sent: Friday, April 23, 1999 11:32 AM
> To: Keith Moore
> Cc: Carl-Uno Manros; Paul Moore; IETF-IPP
> Subject: Re: IPP> Re: PRO - Issue 32: Use of Basic & Digest
> Authentication
>>> 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>