Francois:
I have the following comments on this updated Internet Draft:
a. Section 2.3.1 indicates that Generation of the an AES key used in doing
AES-KeyWrap is done using the method in [DH] with the following
modifications: The Hash function H will be [SHA-256] rather than SHA-1. As
you know, RFC2631 defines one Key Derivation Function (KDF), which is
derived from one of the two KDFs defined under ANSI X9.42. However, NIST
recently suggested a new standardized KDF for both ANSI X9.42 and X9.63 in
its Key Establishment Schemes document presented at its second Key
Management Workshop on November 1-2. Since you are already questioning if
you should change the OID for this KDF because you are mandating SHA-256 not
SHA-1, shouldn't S/MIME, NIST and ANSI take this opportunity to standardize
on one common algorithm for this KDF?
Jim and I had an e-mail exchange with Paul Timmel on this subject. We plan
to stick with SHA-1.
b. Section 2.3.2 is about the AES CEK wrap process, shouldn't it be more
general than just wrapping an AES key in another AES key similarly to the
recently approved <draft-ietf-smime-key-wrap-01.txt>? If yes, the last
sentence of this section indicates that if different lengths are supported,
the KEK MUST be of equal or greater length then the CEK. I would disagree
with this mandatory requirement if other types of keys could be wrapped an
AES key. Take for example Triple DES with three keys (i.e. 192 bits), which
has only an effective strength of 112 bits, could securely be wrapped with a
KEK of 128 bits instead of 192 bits. This last comment also applies to
Section 6, which indicates that when wrapping a content-encryption key with
a key-encryption key, the key-encryption key should always be at least the
same length as the content-encryption key.
I do not think that this is a general mechanism. The one in
draft-ietf-smime-key-wrap-01 certainly is not. The analysis of the
algorithms in draft-ietf-smime-key-wrap-01 was not done for the general
cases. NIST has said that this algorithm is appropriate for wrapping one
AES key with another, and that is how we plan to use it.
I do not see any reason to mix algorithms.
Feel free to distribute these comments and your response on the mailing list
since I am not currently a member of the S/MIME list, but only monitor its
status on the web site.
Russ