ietf-smime
[Top] [All Lists]

Re: Protocol Action: Wrapping an HMAC key with a Triple-DES Key or an AES Key to Proposed Standard

2003-04-10 19:59:51

Russ Housley <housley(_at_)vigilsec(_dot_)com> writes:
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.

I take issue with your characterization of the incompatibility.  Certainly,
the two algorithms generate different outputs, [...]

From Webster's Revised Unabridged Dictionary:

  \In`com*pat"i*ble\, a. [Pref. in- not + compatible: cf. F. incompatible.]
  [It was formerly sometimes written incompetible.] 1. Not compatible; so
  differing as to be incapable of harmonious combination or coexistence;
  [...]

Seems incompatible to me :-).

Peter.