Peter:
>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).
Isn't this kind of asking for trouble? In addition since SignerInfo already
specifies the hash algorithm being used as DigestAlgorithmIdentifiers, why is
there a need to specify it again in the SignatureAlgorithmIdentifier?
Yes, this does lead to some redundancy. However, it is completely
justifiable. The massage digest algorithm identifier comes before the
data, and the signature algorithm identifier comes after the data. This
ordering facilitates pipeline processing by the recipient.
>Is this change going to cause backwards compatibility problems with
legacy CMS
>implementations?
cryptlib has a many-to-one mapping of OIDs, so this shouldn't be a problem, as
long as there's an RSA in there somewhere it'll identify it as RSA.
Cool.
Russ