AES and OAEP tying
"Blake Ramsdell" <blake@brutesquadlabs.com> Mon, 13 May 2002 09:43 UTC
Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01513 for <smime-archive@odin.ietf.org>; Mon, 13 May 2002 05:43:10 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g4D9VGJ24382 for ietf-smime-bks; Mon, 13 May 2002 02:31:16 -0700 (PDT)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4D9VGL24378 for <ietf-smime@imc.org>; Mon, 13 May 2002 02:31:16 -0700 (PDT)
Received: from DEXTER ([192.168.0.7]) by brutesquadlabs.com with SMTP ; Mon, 13 May 2002 02:31:15 -0700
Message-ID: <031a01c1fa60$6fd810c0$0700a8c0@brutesquadlabs.com>
From: Blake Ramsdell <blake@brutesquadlabs.com>
To: ietf-smime@imc.org
Subject: AES and OAEP tying
Date: Mon, 13 May 2002 02:27:44 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit
From what I can tell, the AES symmetric algorithm and the OAEP key wrapping mechanism are being discussed in the same draft. This is unprecedented as far as I can tell -- traditionally we have specified each algorithm in its own draft, and it does not seem useful to combine these two algorithms for technical reasons. From what I can tell, this happened between -01 (3/26/01) and -02 (7/19/01) of draft-ietf-smime-aes-alg. I have reviewed the minutes from the relevant WG minutes, and did not see any significant discussion about this pairing -- it just happened at one point. I guess this is a rhetorical way of saying "It seems that the intent is to drag OAEP into the mainstream, and by precluding the use of RSA-PKCS with AES, we effectively block the future use of RSA-PKCS if anyone chooses to use AES". Am I missing something? I know that it's disclaimed in the overview that these are separate concepts, but I'm not sure of any editorial or technical value of their combination in a single draft. I personally recommend that OAEP be (re-) separated completely from the AES draft. This seems to make things clearer in the event that an even newer, shinier and better symmetric key wrapping mechanism should come along. Well, speak of the devil... ;) But seriously -- I can't see any good editorial or technical reason to tie these mechanisms together. Also, I recommend that the prohibition of RSA-PKCS be removed for AES. That also does not seem to follow the spirit of algorithm profiles for CMS. We have already covered the concerns of RSA-PKCS extensively. I may have missed an earlier discussion of this very issue, but I can't find it in the archives. Clarifications welcome, but I don't think this is the right way to proceed with these two separate mechanisms, and the current document is confusing to me. Sorry I didn't bring this up earlier, but I seem to be paying a little bit of attention now. (closes bunker door, hiding inside) Blake -- Blake Ramsdell Brute Squad Labs http://www.brutesquadlabs.com
- AES and OAEP tying Blake Ramsdell
- Re: AES and OAEP tying Housley, Russ
- Re: AES and OAEP tying Blake Ramsdell