Patented algorithms such as the RSA public-key algorithm, CAST or IDEA
are a different issue, correct? I understand that all of these
particular algorithms have provisions for non-commercial use. If they
didn't, would there be a problem with putting them in the spec?
I'm afraid your understanding of the rules is somewhat out of date. This is
indeed the way it used to be, but it isn't any longer.
The current rules seem quite clear to me -- pure intellectual property issues
are something the IETF doesn't factor into their protocol design decisions. If
they are known they have to be documented, and an attempt has to be made to
obtain reasonable licensing terms (whatever that means), but that's it. As
such, there is no problem requiring a patented algorithm in a protocol, even if
the patent isn't easily licensable or has no provisions for non-commercial use.
The only way to keep such an algorithm out of the standard is to use the
interoperability requirements to say it cannot advance to draft because of a
lack of interoperable implementations, but all this means is that two different
parties have to be able to get a license, not that anyone has to be able to.
(And in this era of routine patent portfolio swaps among the big boys this
requirement is totally meaningless in practice.)
So there is no problem using RSA, Diffie-Hellman, LZW, or designing protocols
that negotiate compression along with encryption (this idea is patented,
believe it or not), or for that matter the 40-bit variant of DES that IBM
apparently has patented. (I'm still looking for a reference to this last, BTW,
but cannot find one that includes a useful description of the technique, let
alone a description of what the patent actually covers.)
The issue with RC2 isn't that it is covered by a trade secret and that trade
secrets never expire (this is one of Keith's pet peeves, but there's nothing in
the rules that forbids it that I know of), it is that trade secrets imply
confidentiality restrictions and such restrictions are forbidden regardless of
their origin. If a variant of trade secret existed that didn't require
confidentiality it would be perfectly acceptable under current IETF rules, even
if its IP claim never expired. (Of course such a variant cannot possibly exist
as the very foundation of trade secrecy lies in its confidentiality.)
Keith's point here is that he believes the IETF's rule of having to keep IP
issues out of the decision process means that RC2's trade secret status cannot
be used as a basis of rejecting the protocol. My counter is that the trade
secret status is irrelevant, it is the confidentiality restrictions implied by
this status that are unacceptable, and I find no language anywhere that allows
for an exception to the rules against confidentiality restrictions because the
confidentiality restriction arises as a result of a trade secret.
BTW, I happen to disagree with the way the IETF chooses to treat patents now
and I argued against it at some length when the rule change was made, but the
consensus went the other way. This means, BTW, that should this WG decide to
replace RC2 with, say, the patented 40-bit IBM DES variant you would have to
license this new patent to implement S/MIME, and it would be just too bad if
IBM didn't have reasonable licensing terms available for it. See why I don't
like the present policy all that much?