Subject: cmsalg-02 RSA OID Proposal

From: "Pawling, John" <[email-masked]>
Date: Fri, 31 Aug 2001 11:44:17 -0400

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, [email-masked]
Getronics Government Solutions, LLC
===========================================

---

From: Eric Rescorla <[email-masked]>
Date: 31 Aug 2001 09:18:13 -0700

> Is this change going to cause backwards compatibility problems with legacy
I strongly suspect it will. More to the point, what's the virtue of
this change? 

-Ekr