1. Section 2.1: Remove the RECOMMENDED from the first sentence in this
paragraph. You are only defining how to use CBC and thus should make
not statements about using some other mode. (Unless you belive that
there are strong reasons for not using ANY other mode, and in that case
it should be MUST.)
2. Section 2.1: The last sentence can be replaced with the text. "The
plain text is padded according to section 6.3 of RFC 3369." The current
language is slightly confusing on when the padding needs to be done
relative to when the encryption is actually done. The current language
seems to eliminate the possiblity of starting the encryption and just
padding when the last block is processed.
3. As per another message, need the section on SMIMECapabilities.
4. Please provide an ASN.1 module with all new items. (Follow
procedures outlined on the IMC hosted page to get a module number.)
5. Abstract: I would like to see the alst sentence of the abstract
rewritten. This is going to be an additional algorithm and as such
would not be included in the CMS specifications. The text seems to
imply that the goal is to move this text into the replacements for RFC
3369 & RFC3370. I can assure you this will not happen. This algorithm
would be required to advance on it's own and could be referenced by
application documents in conjuction with a reference to RFC 3369.
6. Please insert a new section between 1 and 2 which gives some history
about the development of Camellia.
7. Section 2.2: I strongly suggest that you change the parameters for
the key wrap algorithm OIDs to be ABSENT rather than NULL.
8. Section 3: Have you looked at any of the security the key wrap
algorithm for any holes?
9. Security Considerations: Please add the standard consideration
about protecting the Camellia key value.
Jim