[Top] [All Lists]

Re: The RC2 debate

1997-04-23 10:57:54
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


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.


<Prev in Thread] Current Thread [Next in Thread>