Subject: draft-ietf-smime-idea

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 23 Feb 2000 09:58:46 -0800

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

---

From: Russ Housley <[email-masked]>
Date: Wed, 23 Feb 2000 14:20:11 -0500

All:

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.

Russ

At 09:58 AM 02/23/2000 -0800, Paul Hoffman / IMC wrote:
>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

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 23 Feb 2000 13:16:05 -0800

>3.  I would like this document to become a Standards Track document.

Not to disagree with the WG chair, but it is unclear why this should be on 
standards track. It is protocol information for the community about a 
non-mandatory algorithm that, as far as we can tell, is barely used. 
Because of that, isn't it much better qualified for Informational RFC?

--Paul Hoffman, Director

---

From: Russ Housley <[email-masked]>
Date: Thu, 24 Feb 2000 15:14:39 -0500

Paul:

Take a look at the cipher suite definitions associated with TLS.  Only one 
cipher suite is mandatory to implement, but all of the cipher suite 
documents are on standards track.

The SKIPJACK and KEA document is an exception.  The algorithm to wrap one 
SKIPJACK key with another SKIPJACK key is not specified in a publicly 
available document. For this reason, it is not appropriate for the document 
to be on standards track.  All of the information to implement is not 
provided....

Russ

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 24 Feb 2000 13:45:51 -0800

>documents are on standards track.

If Johnny jumped off a bridge, would you do it? :-) Other WGs are putting 
things like this on standards track; I don't think that is necessarily a 
good idea. This can probably be deferred until you talk with the ADs about 
what they think.

--Paul Hoffman, Director