What IETF cares about is that the algorithm is a published standard
(either de facto or de jure), and that the technology is available
under reasonable and nondiscriminatory terms.
Keith, I'm afraid I must disagree with you on this. Again I cite the
IETF rules published in RFC2026, specifically section 10.2:
10.2 Confidentiality Obligations
No contribution that is subject to any requirement of confidentiality
or any restriction on its dissemination may be considered in any part
of the Internet Standards Process, and there must be no assumption of
any confidentiality obligation with respect to any such contribution.
yes, but section 10.3.2 also says:
10.3.2. Standards Track Documents
(A) Where any patents, patent applications, or other proprietary
rights are known, or claimed, with respect to any specification on
the standards track, and brought to the attention of the IESG, the
IESG shall not advance the specification without including in the
document a note indicating the existence of such rights, or
claimed rights. Where implementations are required before
advancement of a specification, only implementations that have, by
statement of the implementors, taken adequate steps to comply with
any such rights, or claimed rights, shall be considered for the
purpose of showing the adequacy of the specification.
(B) The IESG disclaims any responsibility for identifying the
existence of or for evaluating the applicability of any claimed
copyrights, patents, patent applications, or other rights in the
fulfilling of the its obligations under (A), and will take no
^^^^^^^^^^^^^^^^
position on the validity or scope of any such rights.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(C) Where the IESG knows of rights, or claimed rights under (A), the
IETF Executive Director shall attempt to obtain from the claimant
of such rights, a written assurance that upon approval by the IESG
of the relevant Internet standards track specification(s), any
party will be able to obtain the right to implement, use and
distribute the technology or works when implementing, using or
distributing technology based upon the specific specification(s)
under openly specified, reasonable, non-discriminatory terms.
The Working Group proposing the use of the technology with respect
to which the proprietary rights are claimed may assist the IETF
Executive Director in this effort. The results of this procedure
shall not affect advancement of a specification along the
standards track, except that the IESG may defer approval where a
delay may facilitate the obtaining of such assurances. The
results will, however, be recorded by the IETF Executive Director,
and made available. The IESG may also direct that a summary of
the results be included in any RFC published containing the
specification.
So:
a. 10.3.2(B) says that even if RSA claims they have a trade secret, IETF
will take no position on whether that claim is valid.
b. 10.3.2(A) says that if RSA informs the IESG that IETF's referencing
somebody else's RC2 spec is a violation of their intellectual
property rights, the IESG will duly note RSA's claim in any RFCs
that reference that RC2 spec.
c. 10.3.2(C) says that if RSA does claim rights, IETF will try to
get them to agree to license the technology under fair terms,
but whether such a license is granted DOES NOT prevent the
advancement of the document along the standards track.
Note however that as a practical matter, if working group members
believe -- for whatever reason -- that a technology is too encumbered,
that algorithm might not gain consensus support for the group.
A claim of a trade secret is at its core a claim of confidentiality, and
RC2 is claimed to be a trade secret. As such, 10.2 applies and we cannot
use RC2 in an Internet standard unless its status changes.
Nope. The IETF stays out of the business of deciding whether the
claim has merit.
Again, individuals in the community can have their own opinions, and
if enough of those opinions are against using RC2, it will be
difficult for RC2 to get the consensus it needs to be part of an
Internet standards-track protocol. But those individuals don't have
to agree on the reason for supporting or not supporting RC2.
Section 10.2, as it applies to RC2, basically means that IETF can't
reference RC2 in a standards-track protocol *if that reference* is
subject to confidentiality restrictions. So if an IETF WG wants to
use RC2, it has to find a specification for that algorithm which is
not subject to such restrictions.
If RSA publishes the algorithm, fine; if the algorithm is published by
somebody else, fine. But it does have to be published. If this WG
can't find a RC2 specification to reference, it needs to use some
other symmetric encryption algorithm. (And IMHO it shouldn't waste any
more time waiting for RSA to make up its mind...RSA has had plenty of time
to publish RC2 if it wants to do that.)
Again I have to disagree. Publication is not the issue here, the
issue is RSA's claim to a confidentiality requirement that covers
RC2. As long as such a claim exists we cannot use RC2, period.
I think we do disagree here. But I for one won't object to use of RC2
as long as the S/MIME specification can reference a published
specification which is available to anyone.
IETF rules are very clear: we don't take any position as to the validity
of anybody else's intellectual property claims.
Exactly, and this is the entire point. Since the IETF isn't in the
business of assessing the validity of IP claims it has no choice
but to treat the RSA claims as potentially valid.
"I don't think that means what you think it means"... though I don't
think I can state things more clearly than section 10.3.2 of RFC 2026.
Specifically, the ongoing efforts of RSA to keep the details of RC2
(and to a lesser extent RC4) secret have had a chilling effort on
analysis of these algorithms in the cryptographic community. Simply
put, I know of the existance of no cryptographic results for RC2
(and precious few for RC4). Now, when it comes to cryptographic
algorithms, it is almost axiomatic that trust only comes after
careful scrutiny. And while Ron Rivest is a highly competent
cryptographer with excellent credentials, he nevertheless could have
made some mistake in the design of RC2. And if I put on my
mathematician hat for a moment, I'm also uncomfortable with some of
the design elements in RC2; the S-box seems a bit small given that
it is initialized more or less at random.
Yes, these are indeed problems. But it's up to the community to
decide whether an algorithm is suitable for a particular purpose.
Keith