[Top] [All Lists]

Re: Questions on digest and signature algorithm identifiers in CMS

2007-01-19 05:23:18


On January 9, I addressed this topic on the list, but no one has responded yet.
Hereafter are some extracts of what I said, where the clarifications you are 
looking for 
are addressed in the third pararagraph.

"The current explanations from CMS (in fact from PKCS#7) are far insufficient 
to provide sufficient guidance for a correct verification. This needed to be 
and has been fixed in the first text proposal".

"First replacement:

   A recipient verifies a signature in the following way : 
   It must first identify the signer's public key to be used for the 
   verification.  The signer's public key is referenced in the sid 
   value either by an issuer distinguished name along with an 
   issuer-specific serial number or by a subject key identifier that 
   identifies the certificate containing the public key.  If the 
   essCertID signed attribute is present, then the public key 
   contained in the referenced certificate shall be used.  The 
   signer's certificate may be included in the SignedData certificates 
   It must verify that the signatureAlgorithm indicated in the 
   SignerInfo value is compatible with the digestAlgorithm indicated 
   in the SignerInfo value and the algorithm contained in the 
   subjectPublicKeyInfo from the signer?s certificate, e.g. if the 
   signatureAlgorithm is sha-1WithRSAEncryption then the 
   digestAlgorithm must be id-sha1 and the algorithm contained in the 
   subjectPublicKeyInfo must be rsaEncryption. In addition, it must 
   verify that the strength and key size of these algorithms are 
   conformant with its local security policy, otherwise it shall 
   discard the signature.
   It must then use the specific digestAlgorithm indicated in the 
   SignerInfo value to compute a digest and the signatureAlgorithm 
   indicated in the SignerInfo value with to verify the signature 
   value, as defined in Section 5.3. 
   A given signer may apply more than one signature.  This may be 
   useful in particular when some recipients are unable to process 
   some algorithms during an algorithm migration phase".



I have a few questions regarding the interpretation of the algorithm
identifiers used in CMS in the SignerInfo structure.

SignerInfo ::= SEQUENCE {
      version CMSVersion,
      sid SignerIdentifier,
      digestAlgorithm DigestAlgorithmIdentifier,
      signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
      signatureAlgorithm SignatureAlgorithmIdentifier,
      signature SignatureValue,
      unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

This structure includes both a digestAlgorithm and a signatureAlgorithm,
and there are two cases: either signedAttrs are present or not.

Let us first look at case 1, signedAttrs are present.
In that case, we hash the content with the "digestAlgorithm",
and then compute the signature on the DER of signedAttrs with

My first question is: is it authorized to have a _different_
hash function is the digestAlgorithm and the signatureAlgorithm ?
For instance, can I hash the content with MD5 and sign the signedAttrs
with "RSA-SHA1" ? How about PSS ? About about the general case ?

Now, in case 2, we have both a hash function defined in "digestAlgorithm"
and a hash function (implicitely defined) in "signatureAlgorithm"
(except for the special "rsaEncryption" identifier).

In that case, is it authorized to have a _different_ hash function
in digestAlgorithm and signatureAlgorithm ? And if so, how to interpret
it ? Assuming I have MD5 for the digest and RSA-SHA1
for the signature, should I interpret it as a RSA-MD5 signature ?
As a RSA-SHA1 signature ? Or should I consider the CMS as invalid ?
Is there a general rule ?

Thank you very much for your clarifications.


Julien Stern

Denis Pinkas