[Top] [All Lists]

Re: AES and PKCS #1 v1.5 Issue

2002-07-17 01:17:00

----- 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

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 

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

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
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.


<Prev in Thread] Current Thread [Next in Thread>