I would like to see the specifications published as RFCs, then get some
implementation experience. I believe that the most valuable spec changes
will result from implementaion experiences. So, I would expec to wait a
few months before we query the working group for issues and proposed solutions.
At 04:05 PM 6/1/99 -0600, Bob Jueneman wrote:
Russ, and others,
I regret the timing of my remarks, which was unfortunate. Although
I had been following along the S/MIME discussions, it was not
an area I was responsible for until very recently. I hope to be able to
make more of a contribution in the future. Unfortunately, the fact that
my comments came just after, rather than before the Last Call, was
viewed with distaste by some, and perhaps understandably so.
My concern for the apparently duplication of algorithm specifications
was to prevent exactly the kind of unfortunate disagreement in
specifications as occurred with the may/should for RSA signature,
but I overlooked the fact that CMS is intended to have a broader scope
than just the S/MIME specification, and that the S/MIME spec was
picking and choosing a profile of algorithms from a larger set.
Although I feel as strongly as most of the members of the IETF
regarding the need for strong cryptography, I do disagree with
the policy of mandating strong algorithms as a MUST, as I would
prefer to deal with such issues on the political, rather than as
an issue for the standards community to deal with. I will address that
issue with the IESG, as you requested, rather than burden the list.
However, since S/MIME provides a way for one user to inform
other correspondents of their preferred algorithms, the only practical
implication (other than the not so trivial issue of specsmanship and
conformance) is the question of what is to be done as a default,
in the absence of prior knowledge. But according to 18.104.22.168 (Rule 3,
Unknown Capabilities, Unknown Version of S/MIME), the rule is
that the sending agent SHOULD use triple-DES -- not MUST.
I can live with that -- that gives the implementor leeway to
have the user specify a default option, request notification, etc.
On a different subject, can I ask you what the plan is for
entertaining further comments and/or proposed revisions to
either the S/MIME or CMS specification, prior to their
consideration as Draft Standard? Will suggestion for revisions
be in order at some point in time, or is that decision expected
to be a straight up/down vote?
Robert R. Jueneman
Network Security Development
122 East 1700 South
Provo, UT 84606
Russ Housley <housley(_at_)spyrus(_dot_)com> 05/24/99 08:45AM >>>
In CMS Section 12.3.2, RSA Key Management is a "should" implement
algorithm. As a result of an editorial error, in CMS Section 12.2,
Signature is a "may" implement algorithm. I thought that they had the
"should" status. This would be consistent with the MSG document.
We went through great pains to include support many, many algorithms
CMS. The "must" implement algorithms to provide a set of
strong algorithms. The "should" implement algorithms provide backward
compatibility with S/MIMEv2. Any other algorithm is considered a
implement algorithm. RSA with OAEP falls into this "may" implement
The IETF consistently includes strong algorithms in standards. If you
to discuss this policy, please discuss it in a broader context (not
S/MIME) with the IETF Security Area Directors (Jeff Schiller and
Leech). I have CCed them on this e-mail message, so you have their
addresses. I do not consider this an approprate topic for the S/MIME
I wish you had raised this inconsistency during CMS and MSG Last Call.
IESG has approved these documents. I hope you will raise this topic
when the documents are considered for Draft Standard status.
S/MIME WG Chair &
CMS Document Editor