RE: I-D ACTION:draft-ietf-smime-aes-alg-03.txt

["Housley, Russ" <[e-mail]>]

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