[Top] [All Lists]

patent freedom & compatibility

1997-11-06 08:29:12

Rodney Thayer <rodney(_at_)sabletech(_dot_)com> writes:
If you look at what has been happening in the IETF lately you'd see that
TLS, IPSec, and PKIX have all run into this issue.

Here's SSL3.02 draft (TLS) comments on this:

G. Patent Statement

   This version of the SSL protocol relies on the use of patented
   public key encryption technology for authentication and encryption.
   The Internet Standards Process as defined in RFC 1310 requires a
   written statement from the Patent holder that a license will be
   made available to applicants under reasonable terms and conditions
   prior to approving a specification as a Proposed, Draft or Internet
   Standard.  The Massachusetts Institute of Technology has granted
   RSA Data Security, Inc., exclusive sub-licensing rights to the
   following patent issued in the United States:

        Cryptographic Communications System and Method ("RSA"),
   No. 4,405,829

   The Board of Trustees of the Leland Stanford Junior University have
   granted Caro-Kann Corporation, a wholly owned subsidiary
   corporation, exclusive sub-licensing rights to the following
   patents issued in the United States, and all of their corresponding
   foreign patents:

         Cryptographic Apparatus and Method ("Diffie-Hellman"),
   No. 4,200,770

        Public Key Cryptographic Apparatus and Method ("Hellman-
   Merkle"), No. 4,218,582

   The Internet Society, Internet Architecture Board, Internet
   Engineering Steering Group and the Corporation for National
   Research Initiatives take no position on the validity or scope of
   the patents and patent applications, nor on the appropriateness of
   the terms of the assurance.  The Internet Society and other groups
   mentioned above have not made any determination as to any other
   intellectual property rights which may apply to the practice of
   this standard.  Any further consideration of these matters is the
   user's own responsibility.

Analyzing the document rather than studying the context is not
necessarily the way to look at things when dealing with the IETF
standards process.

Could you clarify that comment?

Personally I think a patent free MUST cipher set is great, and very

However I can also see that it would be nice to have backwards
compatibility, and to provide a way for automatic backwards
compatibility to be implemented within the documentation.

An analogy for what Ian is arguing for might be perhaps SSL2.0
fallback mode for SSL3.0 to retain backwards compatibility.

Could we not do this at the same time as having patented algorithms as
SHOULDs or even MAYs.  People don't have to implement SHOULD/MAY, but
they can if they want, and presumably some vendors would to please

Having more seamless backwards compatibility than pgp5.0 currently has
might paradoxically speed the move to pgp5.x / OpenPGP algorithms and
security improvements -- people may be holding back for various
perceived compatibility reasons.  (Personally my only hold up is MUA
software (unix person), I'm quite happy with being able to cope with
two key pairs and using appropriately.)

Note that I am not saying you can't be interoperable with pgp5.0,
clearly you can, as you can add both your old RSA keys if you have
some, or generate both RSA and DSA/EG keys and manually select key
types to use.  I understand pgp5.0 windows client will warn you if you
try to do things like sign with DSA key a document headed for someone
with an RSA key.  This kind of thing could be made seamless, so the
user wouldn't even notice.  So what is being suggested here is that
there is some value to working through the process when the draft
comes out to ensure that it would be possible to build such a system
with the message and key formats allowing software to auto-detect what
is the right thing to do.

One trick SSL3.0 does is to diddle with some random value/value which
is ignored which would not be noticeable to a 2.0 client, but which
could be used by a 3.0 client to detect that it was talking to a 3.0
capable client.  Building in more formalised upgrade paths in OpenPGP
1.0 version such as this, will ease the way for less hassles later.
It is probably possible to do things like this with 2.x, but I'm not
sure how pretty the result would be :-( (Hide EG/DSA key in pgp2.x
comment field, or other place?  Ugh.  Yuck.)

Now officially an EAR violation...
Have *you* exported RSA today? -->

print pack"C*",split/\D+/,`echo "16iII*o\U(_at_){$/=$z;[(pop,pop,unpack"H*",<>

<Prev in Thread] Current Thread [Next in Thread>