Paul raises some very important points. Let me share my view as the S/MIME
Working Group Chair.
1. We must have an IPR statement for this document to progress to an RFC.
2. I do not mind some justification text. Something like: "Organization
who make already use of IDEA for other applications also want to use IDEA
in S/MIME." But, in my opinion, the marketing hype needs to be
significantly reduced. The CAST-128 document does not try to convince
anyone that CAST-128 is appropriate or inappropriate for any particular
group of users. The IDEA document should have a similar tone.
3. I would like this document to become a Standards Track document. The
document should state the one and only way that IDEA is used with
CMS. Clearly, IDEA will not be mandatory to implement, but if IDEA is
implemented, then it MUST be done in the manner specified in this
document. I cannot recommend that this document become a Standards Track
RFC until items 1 and 2 are repaired.
At 09:58 AM 02/23/2000 -0800, Paul Hoffman / IMC wrote:
There are a few things in this document that should raise concern.
Appendix C states clearly that this is a patented algorithm for which
licensing is available. However, it appears that no one has let the IETF
Secretariat know that. Nothing about IDEA is listed on
<http://www.ietf.org/ipr.html>. This draft should not be considered until
there is a formal statement to the IETF.
Parts of the document sounds like a marketing brochure. "Today, IDEA is
widely applied in electronic business applications." "Especially for those
organization who make already use of IDEA on a wide scale it is of high
interest that IDEA is also available in S/MIME." "Experts in cryptography
consider IDEA to be a highly secure symmetric cipher [IDEA]." And so on.
These seem particularly inappropriate for an RFC. To be frank, I've never
heard of anyone wanting to use IDEA for anything other than old PGP. The
folks who wrote PGP had their reasons for choosing IDEA when they did, but
they dropped IDEA as a required algorithm for OpenPGP and that doesn't
appear to have negatively affected them. The IETF shouldn't codify this
kind of marketing hype, even in an Informational RFC. To move forwards
with this, it would be nice if the authors went through the draft and took
out the marketing fluff.
--Paul Hoffman, Director
--Internet Mail Consortium