Peter:
>>>This document defines a mechanism for "wrapping" (aka encrypting) an
HMAC key
>>>with either Triple-DES or the Advanced Encryption Standard (AES).
Standards
>>>already exist for wrapping Triple-DES keys in Triple-DES and AES keys
in AES.
>>>However no standard exists for wrapping HMAC keys, which is what this
document
>>>addresses.
>>
>>Actually a standard does exist for wrapping HMAC keys with any kind of key,
>>formerly RFC 3211, now a part of RFC 3369. This was pointed out over a
year
>>ago during the draft process, but ignored by the RFC authors. So now
we have
>>two incompatible ways to wrap HMAC keys, one in RFC 3369, the other in this
>>new RFC.
>
>Ignored is not a correct characterization. I recall a discussion on the
>S/MIME list.
My apologies, I wasn't very clear in the above (see below).
>As I recall, without searching the mail list archive, no one else voiced a
>concern about publishing a second wrapping technique. Several people voiced
>approval for alignment with the NIST AES Key Wrap algorithm. And, as is
often
>the case in these matters, many people voiced no opinion one way or the
other.
I have no objection to the publication of another key wrap algorithm, what I
was commenting on was the abstract that was quoted in the announcement and
that I quoted in my message, which states:
Standards already exist for wrapping Triple-DES keys in Triple-DES and AES
keys in AES. However no standard exists for wrapping HMAC keys, which is
what this document addresses.
What it should say, to be accurate, is:
This document defines an additional HMAC key wrap mechanism alongside the
one in RFC 3369.
I wasn't really commenting on the contents of the RFC itself, merely trying to
correct the statement in the quoted abstract, which seemed to be ignoring the
existing RFC 3369 (formerly RFC 3211) key wrap. Sorry if I was unclear on
that.
You are correct. This could have been more clear. It should have stated
that an additional mechanism was being defined.
Russ