----- Original Message -----
From: "Jim Schaad" <jimsch(_at_)nwlink(_dot_)com>
To: <ietf-smime(_at_)imc(_dot_)org>
Sent: Tuesday, July 16, 2002 10:40 PM
Subject: AES and PKCS #1 v1.5 Issue
At the face-to-face meeting, I indicated that it is still my belief that
we should prohibit the use of RSA PKCS#1 v1.5 to transport AES keys due
to the somewhat weaker security provided by this method. While I agree
that there is no known attack against RSA PKCS#1 v1.5 in the case of
S/MIME (as a store-and-forward mail system), I do believe that one can
construct an attack against an arbitrary CMS-based protocol. Since this
is a discussion of how to use AES with CMS and not just with S/MIME, I
believe that the more general case should rule what happens in this
document.
My position continues to be along the lines of specification purity -- it is my
opinion that the AES algorithm profile for CMS is not the forum for flogging
PKCS #1 v1.5 unless there are specific issues that are unique to the specific
combined use of AES and PKCS #1 v1.5.
This is especially in light of the fact that:
1. RFC 3218 discusses the issue of the MMA and CMS at length (as I believe
Peter has already pointed out)
2. CMSALG already discusses this in at least two places -- roughly a page of
text.
3. There is a TBD in MSG-bis that says we should discuss it some more there.
Having done implementations of the RSA-OAEP padding already, I do NOT
believe that there is a serious development hurdle to getting RSA-OAEP
distributed.
Not everyone controls the key unwrapping and unpadding, as in the case of
hardware tokens or software libraries that don't separate the block decryption
from the block unpadding. Some of us are more "applied" cryptogruffers than
others ;).
1. Leave the ban on RSA PKCS#1 v1.5 as is currently present in the
document.
2. Remove the ban, but allow the author to present a diatribe on why
it's a bad idea.
3. Remove the ban entirely and force an update to SMimeCapabilities to
allow for products to advise that the combination is not acceptable.
In the event that we decide to continue with any ban on the use of PKCS #1 v1.5
in any CMS context, it is my recommendation that we either a) modify the
existing CMS / CMSALG / MSG specification in that way, or b) create a separate
document that explains the issue further.
If we have failed to explain just how bad PKCS #1 v1.5 is, then I believe this
is a failing of MSG and CMSALG and should be addressed there, not in the AES
algorithm profile.
Blake