On Tue, 23 Jul 1996, Jeff Weinstein wrote:
Raph Levien wrote:
Of course, your hypothetical user who wants to use a 512-bit key and 128-bit RC2 is still completely screwed by all currently shipping S/MIME products, as well as the S/MIME spec.
I can't find anything in the S/MIME spec that makes the combination of 512-bit RSA key and 128-bit RC2 (or 3DES) illegal. The spec says that you must support RSA key sizes from 512 to 1024. Am I missing something?
By "screwed," I mean that, because of the default settings, a user who wants to receive mail encrypted with ciphers stronger than 40-bit will still receive a majority of messages encrypted at 40 bits. Since S/MIME has not been widely deployed yet, this claim is speculation. However, there is a lot of reason to believe it. The problem is not that the combination is illegal, it's that nobody will actually configure their clients to use it.
There is another method that does not require verisign or other CAs to add key size extensions to their certs. We can define a new authenticated attribute that gets included in Signed-Data and Signed-And-Enveloped-Data messages that indicates the user's key size and algorithm preference. This has the advantage that the preference is selected and signed by the user. This method was discussed at the S/MIME meeting in January at the RSA Crypto conference. I'm a bit surprised that it never got into the Implementation Guide. I'll make sure that we bring it up on the smime list again.
I don't like the fact that your proposal leaves clients with absolutely no information about symmetric cipher choice until the first round of signed messages has been exchanged. In this initial round, the protocol is still dependent on the global default.
How did you get the certificate of the recipient? I assume that you got it from a degenerate PKCS#7 Signed-Data message as recommended by the s/mime spec. That degenerate message could contain the attribute I describe. If you got the certificate by some other means, we would fall back to your heuristic.
Perhaps I'm missing something here. In the model I'm assuming, if I wanted to send you mail, the first thing I'd do is get your certificate. Today, I'd do that by going to the VeriSign Web site, but in the near future I would expect this lookup to be automatic. Either way, it would be up to VeriSign to ship the algorithm preference information along with the X.509 cert (whether by degenerate PKCS#7 or some other means). This means that VeriSign needs to agree to ship the information in response to queries, and also that users keep the VeriSign database up to date with respect to algorithm preferences. This is the infrastructure requirement I referred to, one that isn't present in my proposal. After the first exchange of e-mail, the problem goes away. However, I consider the protection of the inital round to be important.
P.S. Can we agree not to describe 128-bit RC2 as "strong crypto" until it's been subject to more serious scrutiny? It's probably a great cypher, but most cautious crypto-people would far rather place their trust in Triple-DES.
Certainly. We will definitely offer 3DES as well as RC2 in our product.
Good. The point I'm making has more to do with representing 128-bit RC2 as being of comparable trustworthiness as 3DES, though, not simply of offering the option. Since RC2 is slower than 3DES, it's not at all clear to me why anyone would choose it. Just to be clear, I'm not arguing with you because I think Netscape will ship a bad product. However, I do see a real danger that, in the field, S/MIME will have severe security problems, mostly because people don't understand how to use it correctly. Carefully explaining the exact strengths and limitations of S/MIME is our best hope of it being deployed as a strong crypto protocol. Since most of the force behind S/MIME now is from marketing, rather than security, people, I don't see much of that going on (as a case in point, from a technical perspective, the recent interoperability testing has been fairly sloppy). It is my hope that Netscape will do better. Raph