These two are leftovers from the previous mail which did not get
incorperated into the new draft (except as Needed changes in appendix F).
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 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.
2.6.1.4 Rule 4: Unknown Capabilities
If:
- the sending agent has no knowledge of the encryption capabilities of the
recipient,
then the sending agent MUST use tripleDES."
2. Insert a new section 2.6.4 with the following text.
"Section 2.6.4 Selecting a receipients Encryption Certificate
The use of the must algorithms in this specification lead to the problem of
given a user's signing certificate from a signed message, how is the
encryption certificate determined. Since the signing and key exchange
algorithms will no longer use the same certificates.
Section 2.5 deifnes a method by which a sending agent can optionally
announce what its perfered key-exchange certificate is. The following
method for processing and remembering the encryption certificate attribute
in incoming signed messages SHOULD be used.
If an Encryption Key preference attribute is found in a message, this is the
certificate that should be associated as the encryption certificate for the
user.
If no Encrytion Key perference attribute is found in a message, the set of
certificates should be searched for a certificate with the same DN as the
signing certificate which can be used for encryption. If no certificate is
found, then encryption cannot be done with the signer of the message. If
multiple certificates are found, the MUA can make an arbitrary choice
between them.
- If the receiving agent has not yet done an association for the sender's
encryption certificate, then, after verifiying the signature on the incoming
message and checking the timestamp, the receiving agent SHOULD create a new
associaiton containing the signing time and the encryption certificate.
- If such an association already exists, the receiving agent SHOULD verify
that the signing time in the incoming message is greater than the signing
time stored in the association and that the signature is valid. If so, the
receiving agent SHOULD update both the signing time and the encryption
certificate association. Values of the signing time that lie far in the
future (that is, a greater discrepancy than any reasonable clock skew), or
an encryption preference in a message whos signature cannot be verified,
MUST NOT be accepted."
-----------------------------------------------------------------------
Now for the new comments on this draft:
3. Section 3.7 -- the first sentence of paragraph 3 and the last of
paragraph 2 are identical. Please delete one of these.
4. Section 4.1 -- Should make this text match the requirements above. In
section 2.2 we said SHOULD to 512 to 1024 bit signature verification. In
this section we are talking about old clients. Lets be consistant.
jim