Comments on this draft:
1. Title: I suggest that "Password-based Encryption for CMS" is a better
title. [Comment made in working group last call]
2. Section 1: Paragraph 2: The format of the messages are described using
1988 not 1994 ASN. Please update this reference.
3. Section 1.2.1: Paragraph 1: The phrase "user-supplied password or
previously agreed-upon key" is somewhat misleading. KEK is the generally
used agreed-upon key method for key managment. Please delete the phrase "or
previously agreed-upon key". (Ditto for all subsequent references.)
4. Section 1.2.1: In the event that two password recipient info's are
present, how do I determine which is the one I am to use?
5. Section 1.2.1: Paragraph keyEncryptionAlgorithm: This field identifies a
key-encryption not a content-encryption algorithm. Please update.
6. Section 1.2.1: Paragraph keyDerivationAlgorithm: Please justfy why this
is optional. The same behavior could be obtained from the KEK with an empty
keyIdentifier field. I don't think this generally useful because as with
question 4 above how do you determine the correct one in the event that
multiple of these exist in the structure. [Comment made in working group
last call.]
7. Section 2.1: Paragraph 2: You cannot place a MUST on CMS
implementations. Please change to "Conforming implementations".
8. Section 2.2 & 2.3: You have Key Encryption algorithms and Symmetric Key
Encryption algorithms. I don't understand the difference between these two
groups as they both appear to be using symmetric keys, take a KEK and
encrypt a CEK. The only difference appears to be that the first are simple
encrytion algorithms and the second are complex ones.
9. Section 2.2: What is KSG? This is not expanded anyplace.
10. Section 2.2: Why is Triple-DES/CBC a MUST algorithm. This appears to
be reasonable for content encryption but is not a good idea for key
encryption.
11. Section 2.3.1: Item 4: Suggest you change the start of the text to
"Append random padding to make the CEK data block a multiple of the KEK
block length. Enough padding must be added to ensure that the resulting
data block is atleast two KEK blocks long. (The..."
12. Section 2.3.3: unwrap Item 2: This does not appear to agree with the
algorithm in section 2.3.2. Should it not be "Set the IV to the decrypted
content, decrypt the first 8 bytes."?
13. Section 2.2: I am having a problem with what you are using for the
KeyEncryptionAlgorithm. I think that you need to use something other than
the standard content-encryption algorithm OIDs in this location due to the
fact that you are adding additional processing in the form of the wrapping
algorithm. I think that this issue alone is a killer for this document as
it is presently set out.
14. Section 2.2: It is still my belief that the key wrap algorithm
presented as part of RFC2460 should be the MUST key wrap algorithm (i.e.
id-alg-CMS3DESwrap). The CMS version will be implemented in software for
CMS compatilibity and in all likely hood will also be done in hardware as
well if KEK encryption ever becomes real common place. (For use with S/MIME
symmetric key mailing lists if nothing else.) While I don't object to your
offering a second key wrap algorithm I don't see a strong benifit for it
over the already existing version in CMS. [Comment made in working group
last call.]
15. Appendix A: Imports statement is syntaxically incorrect. (Probably also
wrong for Appendix B.)
16. Appendix A: Missing definitions for the imported items -- they can't be
imported from an ASN.1 1994 module. They need to be copied here not
imported.
17. Appendix B: Do not re-use the same module numbers for both the 1994 and
1988 versions of the ASN modules.
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of The IESG
Sent: Tuesday, April 03, 2001 11:46 AM
To: IETF-Announce:
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Last Call: Password-based Encryption for S/MIME to Proposed
Standard
The IESG has received a request from the S/MIME Mail Security Working
Group to consider Password-based Encryption for S/MIME
<draft-ietf-smime-password-03.txt> as a Proposed Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg(_at_)ietf(_dot_)org or ietf(_at_)ietf(_dot_)org mailing lists by April
17, 2001.
Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-password-03.txt