Subject: SMIMECapabilites for AES, etc.

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 29 Nov 2000 09:58:15 -0700

>> Although it isn't strictly interactive in the sense that SSL is,
>> the SMIMECapabilities attribute allows the originator of a message
>> to indicate his preference as to encryption algorithms, including
>> 40-bit RC4 vs. 56-bit DES > vs. 128-bit whatever vs. 196-bit
>> triple-DES (and soon, presumably, 256-bit AES).
>
>Yes, but on the open Internet most certificates are sent as part of the
>message (presently in PKCS#7 format), not retrieved from global directories
>as the X.500 folks initially hoped. In that context, the recipient would
>have to send an initial signed message to the sender to indicate the user
>agent's capabilities: and in most cases (like one I mentioned of the mailing
>list) that's just not viable.
>
>Enzo
>
>
You are correct, of course.  I was thinking  about the encryption case, primarily, where it is much more likely that the recipients would have exchanged at least a signed message, precisely in order to exchange certificates.

That does bring up a good point regarding AES, however.  In the past, it was usually possible to make a good guess as to whether to use a 40-bit key (RC2 or RC4) or a full strength key (DES, triple-DES, or perhaps 128-bit RC2 or RC4) based on what you knew about the recipient, in particular whether he or she was in the US or Canada, or somewhere else that was more likely to be subject to export controls.  And nearly all of the e-mail packages implemented RC2 and RC4, and the "domestic-strength" packages implemented both DES and triple-DES. So the SMIMECapabilities attribute wasn't really all that necessary.

As we begin the transition to AES, however, that won't be the case.  There will be a substantial number of packages that support triple-DES but haven't been upgraded to AES, and I would expect that situation to last for a couple of years or more.  So anyone who simply fires off a message encrypted in AES without checking first is taking the risk that his message can't be read.

In order to facilitate an orderly transition, I would suggest that we specify a date certain, after which the default algorithm would be 256-bit AES, rather than triple-DES.  That certainly wouldn't be difficult to implement.  Assuming that AES is formally endorsed some time in the next couple of months (I don't know the exact time line they are on), what would people think about April 1, 2004? That would provide a generous 18 months for a vendor to release their next version, and another 18+ months for users to adopt it.  Since most e-mail packages are based on underlying crypto packages that can be downloaded via the web, I think that would be more than enough time.

Of course if someone chooses to do so, they can explicitly request (or force) the use of AES prior to that date, but at least the default would be taken care of nicely.

Bob