At 11:21 AM 11/20/98 -0500, Al Arsenault wrote:
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.
That sounds good to me.
3. Section 2.6, first sentence: Is the reference to [DES] dangling?
It would seem that one reference to tripleDES would be sufficient.
I think we can take out the [DES] reference.
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?
Don't ask. It's a bad historical artifact. We should definitely remove the
"or a compatible algorithm".
5. Section 2.6.3 is essentially repeated in the Security
Considerations
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.
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.
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