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