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