Re: Issues with S/MIME Message Specification

["Bob Jueneman" <[e-mail]>]

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 2.7.1.3 (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?

Regards,

Bob



Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[e-mail]
1-801-861-7387

>>> Russ Housley <[e-mail]> 05/24/99 08:45AM >>>
Bob:

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, RSA
Signature is a "may" implement algorithm.  I thought that they had the same
"should" status.  This would be consistent with the MSG document.

We went through great pains to include support many, many algorithms in
CMS.  The  "must" implement algorithms to provide a set of interoperable
strong algorithms.  The "should" implement algorithms provide backward
compatibility with S/MIMEv2.  Any other algorithm is considered a "may"
implement algorithm. RSA with OAEP falls into this "may" implement category.

The IETF consistently includes strong algorithms in standards.  If you wish
to discuss this policy, please discuss it in a broader context (not just
S/MIME) with the IETF Security Area Directors (Jeff Schiller and Marcus
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 mail
list.

I wish you had raised this inconsistency during CMS and MSG Last Call.  The
IESG has approved these documents.  I hope you will raise this topic again
when the documents are considered for Draft Standard status.

Russ
  S/MIME WG Chair  &
  CMS Document Editor