Subject: RE: Pkinit issue: algorithm IDs for DH

From: Medvinsky Alexander-MGI1174 <[email-masked]>
Date: Mon, 13 Sep 2004 17:02:03 -0700

I don't have any preference regarding keeping RC2-based key encryption in PKINIT and PacketCable doesn't use it.  I recall that someone asked for RC2 a few years ago.  Regarding AES-based encryption, there is an AES wrap algorithm defined in RFC 3565 (Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax):

   aes  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) country(16) 
	  				    us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 1 }

   id-aes128-wrap  OBJECT IDENTIFIER  ::=  { aes 5 }
   id-aes192-wrap  OBJECT IDENTIFIER  ::=  { aes 25 }
   id-aes256-wrap  OBJECT IDENTIFIER  ::=  { aes 45 }

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Monday, September 13, 2004 1:56 PM
To: [email-masked]
Subject: Pkinit issue: algorithm IDs for DH

Hi.  I'm working on specific text to add static-static DH to pkinit. I ran across the following issue:

Section 3.1 of pkinit 20 says:

PKINIT uses the following algorithm identifiers [2] for encrypting the reply key with the temporary key:

    des-ede3-cbc      (three-key 3DES, CBC mode)
        rc2-cbc                     (RC2, CBC mode)

This seems problematic for two reasons.  First, shouldn't we have an OID for AES?  Second, is RC2 at all appropriate to use in a new proposed standard?

As a side note, if I were doing this from scratch, I would have used Kerberos EncryptedData rather than CMS for that part of the protocol. I don't think making that change at this point in time is desirable.

--Sam