ietf-smime
[Top] [All Lists]

Re: Questions on digest and signature algorithm identifiers in CMS

2007-01-26 05:33:58

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!

OK, so let's see what we've got here. In the SignerInfo we have:

digestAlgorithm DigestAlgorithmIdentifier

and

signatureAlgorithm SignatureAlgorithmIdentifier

The intent is that digestAlgorithm act as a hint for implementors so that one-pass processing of the signature is possible. So in the event that there is a signedAttrs member (likely) that you digest it with the correct algorithm so that when you get to the signature, you will be ready to go with a completed digest so you verify the signature. This is purely for convenience.

This is the reason for the digestAlgorithms field in the SignedData structure also. The encapContentInfo needs to get digested with some algorithm(s), so you could use a hint as to which ones might be used.

Now, if the sending implementation or an intermediate agent (including an adversary) is a jerk, this digest algorithm hints might be inconsistent with the algorithm required for the signature validation, which I think is your concern.

There's no way around this potential inconsistency.

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.

I would also understand that you do not wish to commit to a definitive
answer on this question, so unless you (or someone else on the list)
says otherwise, I think I will just consider the message as "malformed"
if such a case arises.

Personally, I think that's reasonable. Not "liberal", but reasonable.

It might be a good idea to use one of the current draft (cms-mult-sign ?)
to answer the two following simple questions:

- Is it or is it not allowed at all to have different hash functions
in the digestAlgorithm and the signatureAlgorithm?

The description of the field is that it "identifies the message digest algorithm, and any associated parameters, used by the signer". If the value of this field doesn't meet this criteria, then I'd say "sending implementation broken" or "contents modified in a broken way in transit". So it's implicitly not allowed -- the spec says to indicate the algorithm that you used and that apparently didn't happen.

Being crabby about an inconsistency between the digest algorithm hints given previously and the signatureAlgorithm field of the SignerInfo is a thing to do, but I don't think it's productive. Your implementation may not afford you the luxury of digesting with every algorithm, in which case you need to hope for the best I guess.

- 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.

Blake
--
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com