Holger:
PKCS#7 only supported the RSA algorithm, and it used field names that
represent this situation. signatureAlgorithm is the new name, indicating
support for any digital signature algorithm. The digestEncryptionAlgorithm
is the old name, indicating the RSA operation that is performed to generate
a digital signature with that algorithm.
<snip>
Now my questions:
(2) How should I handle a CMS (2630/3369) signature where the value of
the digestAlgorithm does not match the 'included' digestAlgorithm in
the signatureAlgorithm field. (e.g. having a RIPEMD160 digestAlgo
OID at the digestInfo field and a Sha1WithDSA OID in the signature-
algorithm field).
I think that the digestAlgorithm must be consistent with the one used in
the signature.
(3) When a component claims that it can produce valid RFC 2630
signatures, is the usage of the 'old' RSA OID 1.2.840.113549.1.1.1
the only exception from the rule? Is the usage of the 'other'
RSA signature OIDs (sha1WithRSAEncryption) really forbidden in 2630?
Be flexible in receive processing, but strict on send processing. That
said, if you need interoperability with some PKCS#7 implementations, you
may need to send it the only way that they know how to accept it.
Russ