[Top] [All Lists]

Re: Issues with S/MIME Message Specification

1999-06-01 17:12:08

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 (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
Security Architect
Network Security Development
Novell, Inc.
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

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