Diffie-Hellman
Patent is now expired. A derivative, ElGamal, also is unencumbered.
DSA
Has some uncertainty, due to claims that it touches the "Schnorr" patent,
however there is little support for this concern and it is generally being
treated as unencumbered.
IDEA
Patented, but this is no longer a serious factor, since PGP has moved away
from using IDEA.
MD5
Unencumbered.
RC2
No longer a trade secret by RSADSI. However they continue to retain
trademark on the name. See RFC2268 for the algorithm.
RSA
Patented only in the United States. The patent expires on September 20,
2000 and is held by Public Key Partners (PKP), of which RSADSI is a partner.
SHA-1
Unencumbered.
Hence, the deployment of S/MIME v2.0 remains significantly encumbered by the
RSA patent. S/MIME v3.0 defaults to use of Diffie-Hellman and, so, will not
be burdened. The S/MIME working group is currently looking at potential
patent issues with the variant of Diffie-Hellman they are using, but the
final version of S/MIME v3.0 should be unburdened (one way or another).
/John Wenn (with help from Xavier Riley).
> -----Original Message-----
> From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com]
> Sent: Friday, April 23, 1999 1:10 PM
> To: Michael Sweet; Keith Moore
> Cc: Carl-Uno Manros; Paul Moore; IETF-IPP
> Subject: RE: IPP> Re: PRO - Issue 32: Use of Basic & Digest
> Authentication
>
>
> 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@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@easysw.com
> > Printing Software for UNIX
> http://www.easysw.com
> >
>