1. Section 2.1. What is the timing you expect to see relative to PKCS5v2
being advanced to an RFC of some type?
2. Section 2.1. The S/MIME working group is using 88 ASN syntax. The
syntax in this section is not. Please correct.
3. Section 2.1 Why is there ASN here that does not actually provide any
useful information. What are the parameters. What is the OID associated
with this set of parameters.
4. Section 2.3.1 We have a key wrap algorithm specified in RFC 2630. You
are using a different key wrap algorithm. I would prefer to see a single
one for simplity of implementation. What is your justification for added
complexity?
5. Section 2.3.2. You state that the length of the key can be determined
from the CEK parameters. This is not always true. A counter example would
be to use 256-bits of key material for a RC2/128-bit process. In this case
you would only pull 128-bits of key material and be unable to decrypt the
content.
6. Sectoin 2.3.1. Questions about your algorithm: 1) what is the IV that
should be used initially on the first pass encryption (not explicity stated
but implied later). 2) Where is the IV saved? 3) What does step 1 of
section 2.3.2 do? I don't see a corresponding step in section 2.3.1. This
thing might work, but I should don't believe it from just reading the
document.
7. Section 2.3.4 -- Can this issue also be addressed by the addition of a
random salt to the KEK creation process? This means one is not using the
same KEK for every CEK encrption from a single password.
8. Section 2.4.1 -- You cannot change the CEK for RC2 in this document. I
don't want two different versions for this depending on wheither I have a
Password KEK mixed in the set of recipients. This just will not fly.