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
field.
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.
Denis
======================================================
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!
[snip]
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.
Blake,
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".
Regards,
--
Julien
Regards,
Denis Pinkas