[Top] [All Lists]

Re: Questions on digest and signature algorithm identifiers in CMS

2007-01-26 09:12:46

This thread has illustrated the fact that CMS is not crystal clear. 
There is a need to fix this. Herafter is a strawman proposal :

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. 

The following examples are provided:

      - if the signatureAlgorithm is sha-1WithRSAEncryption, then the 
        digestAlgorithm must  be id-sha1 and the algorithm contained in 
        the subjectPublicKeyInfo must be rsaEncryption.

      - if the signatureAlgorithm is id-RSASSA-PSS, then the 
        hashAlgorithm included in the RSASSA-PSS-params must be the 
        same as the one indicated in the digestAlgorithm field from 
        SignerInfo. The algorithm contained in the subjectPublicKeyInfo 
        must either be id-RSASSA-PSS with the same parameters as those 
        indicated in the signature algorithm or be rsaEncryption. 
   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. 

   In addition, it MUST verify that the strength and key size of 
   these algorithms are conformant with the security policy, otherwise 
   it shall discard the signature.

   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.


On Fri, Jan 26, 2007 at 04:02:28AM -0800, Blake Ramsdell wrote:
Julien Stern wrote:
I am just faced with a simple practical problem, namely: what is an
implementation supposed to do when it receives a CMS message where
the hash function in the digestAlgorithm and the signedAlgorithm
are not the same?  I mean, there must be quite a large number of CMS
implementations that were faced with the same problem!


Now, a "tough guy" implementation might take the precaution that every 
other implementation is crazy, and digest with every algorithm that they 
understand. In my case, I always digest with MD5 and SHA-1. So I 
personally don't listen to the digestAlgorithms field in SignedData or 
the digestAlgorithm field in SignerInfo. When I get to the signature 
verification, I say "OK, so which digest do I need" and use the right 
one (or freak out if it's not one of those). So I never have the 
heartache of betrayal from these fields, at the acceptable (in my case) 
cost of performance.


Thank you for your input.
I like your interpretation (considering the digest as a pure hint) too.

- What should be the behavior of a verification algorithm which is
faced with such a situation?

Not sure if it's specified anywhere, but that's up to the implementation 
I would say.

OK. I guess I have my answer :) So, I'll go for either "reject"
or "use only digests as a hint".




Denis Pinkas