I have a few objections to this draft that I would like to see cleared up
before any further discussion happens on the draft.
The draft does not have the mandatory notice about whether or not it
complies with RFC 2026. Without this notice, the authors could claim that
they do not release copyright on the draft to the IETF, and therefore we
may not be able to use the discussions of the draft in the future.
The draft seems more like a marketing effort than a technical
specification. All the talk about integration with S/MIME, the history of
IDEA, and so on is pretty useless. A simple document saying "here's the
OID, here are the parameters, here's our patent statement" would suffice.
(I find it particularly galling that the sentence "S/MIME is constructed as
an open system." is used near the beginning of the draft as a way to make
nice before proposing an algorithm that is heavily protected by patents.)
The draft restates some of the MUSTs and SHOULDs from the -msg draft, which
is completely inappropriate. All such restatements should be removed,
leaving just the changes that this draft would make to the
hopefully-soon-to-be-standard.
There is no Security Considerations section; I think one would be
appropriate, given that this is proposing an algorithm that is not widely
known.
The statement "Commercial licenses can be obtained by contacting
idea(_at_)ascom(_dot_)ch" is interesting, if true. I was told a few years ago that a
company that applied for an IDEA license for PGP was flatly rejected
without any talk of the cost (I have no verification of this). Perhaps the
authors of this draft should reword the sentence, or spell out what they
mean in terms similar to those used in RFC 2026 and RFC 2028.
--Paul Hoffman, Director
--Internet Mail Consortium