[Top] [All Lists]

Re: patent freedom & compatibility

1997-11-06 09:40:12
My point is that TLS was ordered to use DSS/DH and 3DES rather than RSA and
RC4 as the MUST.

Using encumbered algorithms as non-MUST algorithms is fine.

Analyzing 2026 to death rather than finding out what the IETF really does
is why I started this comment.

At 03:20 PM 11/6/97 GMT, you wrote:

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>