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