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
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(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`