Re: patent freedom & compatibility

[Rodney Thayer <rodney@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx> 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
>desirable.
>
>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
>users.
>
>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.)
>
>Adam
>-- 
>Now officially an EAR violation...
>Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/
>
>print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
>)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
>
>