At 11:44 AM 3/26/98 -0800, Jim Schaad (Exchange) wrote:
1. Section 2.6.2.3 and 2.6.2.4. The wording no longer works for these two
sections now that 3DES is a must and RC2/40 is an optional.
I disagree. The wording works fine. It was heavily debated about a year
ago. The first rule that comes after "you know what the user wants" MUST
prefer tripleDES. Prefering RC2/40 over tripleDES is wrong and will keep
S/MIME v3 from becoming a standard in the IETF.
I have switched
the order of the rules as tripleDES is now a MUST algorithm and is therefore
by definition supported, but we know that not everyone does support it. I
suggest that these sections be re-written as follows:
"2.6.1.3 Rule 3: Low Encryption interopt mode
If:
- the sending agent has no knowledge of the encryption capabilities of the
recipient,
- and the sending agent is has reason to believe that the recipient does
not support high level encryption,
then the sending agent SHOULD use RC2/40.
Over my dead body. Whoops, maybe I stated that too forcefully. :-)
The phrase "has reason to believe" has no place in a specification like
this. That's based on such vague out-of-band guesses that it will lead to
rampant confusion on developer's part. Worse yet, it will cause some
sending agents to default to weak encryption. We have to say how they might
know this, and we already did that in 2.6.1.1 and 2.6.1.2. If you think
there is some other way for the sender to know something about the
recipient, please let me know, since we should add a step between the first
two and the second two.
The logic for the current 2.6.1.3 and 2.6.1.4 is that if you have no idea
what the recipient wants, the only thing you can base your decision on is
your aversion to risk of failed decryption. Because the latter choice is
based on a non-protocol decision, 2.6.1.3 and 2.6.1.4 must be SHOULDs, not
MUSTs.
2. Insert a new section 2.6.4 with the following text.
"Section 2.6.4 Selecting a receipients Encryption Certificate
This looks pretty good. I might want to wordsmith it a bit, but I think
this is a valuable addition.
--Paul Hoffman, Director
--Internet Mail Consortium