Subject: Comments on MSG spec

From: Al Arsenault <[email-masked]>
Date: Fri, 20 Nov 1998 11:21:50 -0500

Folks,

        I've had a chance to look at a few of the documents again recently.
 The
latest version of the MSG spec on the web server is
draft-ietf-smime-msg-5.txt.  I have a few minor comments on that document;
apologies if any or all of these are OBE.

        1.  Section 2.5.3, the first paragraph is pretty rough reading. 
Recommend that the last two sentences be changed to something like:
This attribute tells the receiver which of the sender's certificates should be
used for encrypting the session key when the receiver later wants to send an
encrypted message to the sender.  This attribute simplifies interoperability
among clients that use separate keys for signing and encryption.

        2.  Section 2.5.3, last paragraph:  Second sentence (the one in
parentheses):  change "to" to "too".  Third sentence, change "senders" to
"sender's".

        3.  Section 2.6, first sentence:  Is the reference to [DES] dangling? 
It would seem that one reference to tripleDES would be sufficient.

        4. Section 2.6, second sentence:  This is rough wording.  What do you
mena by "RC2 ... or a compatible algorithm"?  Which algorithms are "compatible"
with RC2?

        5.  Section 2.6.3 is essentially repeated in the Security
Considerations
section.  It's better there, anyway; I recommend deleting 2.6.3.

        6.  Section 3.1, last paragraph before 3.1.1:  this paragraph is out of
place.  It belongs in Section 4, if it's not already covered there.

                                        Al Arsenault

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 20 Nov 1998 14:06:44 -0800

>among clients that use separate keys for signing and encryption.

That sounds good to me.

>It would seem that one reference to tripleDES would be sufficient.

I think we can take out the [DES] reference.

>mena by "RC2 ... or a compatible algorithm"?  Which algorithms are
"compatible"

Don't ask. It's a bad historical artifact. We should definitely remove the
"or a compatible algorithm".

>section.  It's better there, anyway; I recommend deleting 2.6.3.

I disagree, because without it 2.6 is incomplete. I think the duplication
is OK.

>place.  It belongs in Section 4, if it's not already covered there.

I disagree. Section 4 has nothing about this topic. True, we don't have a
separate section on "what to do when you receive an S/MIME message", but I
think discussing it for each type of message is just fine.

--Paul Hoffman, Director
--Internet Mail Consortium