Hello,
Is this change going to cause backwards compatibility problems with legacy
CMS implementations?
Since CMS respectively S/MIMEv3 claims for backward compability to PKCS#7v1.5
respectively S/MIMEv2 should backward compatibility problems with
PKCS#7v1.5 and S/MIMEv2 applications not be of concern, too?
Just for testing I have tried to send two signed mails to Netscape
Messenger (4.7), the one specifiying rsaEncryption as the signerInfo´s
signature algorithm, the second sha1WithRSAEncryption. Whereas the
first mail was succesfully verified, Netscape failed in verifying
the second mail by giving the following warning message:
Invalid Signature:
"Warning! In the time since the sender sent you this message and you
received it, the message appears to have been altered. Some or all of the
content of this message has been changed. You should contact the
message sender and/or your system administrator."
However, no problems for both messages when verifying with Outlook
Express or Outlook 2000.
Regards,
Dieter Bratko, IAIK
-----Ursprüngliche Nachricht-----
Von: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]Im Auftrag von Pawling,
John
Gesendet: Freitag, 31. August 2001 17:44
An: SMIME WG (E-mail)
Betreff: cmsalg-02 RSA OID Proposal
All,
RFC2630 CMS, section 12.2.2, specifies the use of the rsaEncryption object
identifier (OID) in the signedData signerInfo signatureAlgorithm field when
the RSA (PKCS #1 v1.5) algorithm is used as part of the signature generation
process. cmsalg-02, Section 3.2, specifies the use of the
md5WithRSAEncryption and sha1WithRSAEncryption OID (as appropriate) in the
signedData signerInfo signatureAlgorithm field (instead of the
id-rsaEncryption OID). The cmsalg-02 proposed use of these OIDs is
consistent with their use in the RFC2459 PKIX Certificate/CRL Profile. The
RFC2630 use of the id-rsaEncryption OID is inconsistent with RFC2459.
Is this change going to cause backwards compatibility problems with legacy
CMS implementations?
The current release of the S/MIME Freeware Library (SFL) (available from
<http://www.getronicsgov.com/hot/sfl_lib.htm>) can successfully verify a
signedData content type that includes a signerInfo signatureAlgorithm field
that includes the md5WithRSAEncryption, sha1WithRSAEncryption or
rsaEncryption OID (as appropriate). Therefore, the proposed cmsalg-02 use
of the md5WithRSAEncryption and sha1WithRSAEncryption OID (as appropriate)
would not cause backwards compatibility problems for those applications that
use the SFL along with a crypto library that supports the algorithms
indicated by the OIDs.
Feedback from others is welcome! This is an important issue.
===========================================
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================