ietf-smime
[Top] [All Lists]

Re: Questions on digest and signature algorithm identifiers in CMS

2007-01-19 07:18:34

On Fri, Jan 19, 2007 at 12:57:12PM +0100, Denis Pinkas wrote:

Julien,

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.

Denis,

thanks for your answer. And my apologies for not having seen your previous
mail. I'm subcribed to the list, but I apparently have missed that one.

Nevertheless, while I agree with you there is a minor clarification needed,
I'm afraid that your text still leaves some things unclear.

You say that if the signatureAlgorithm is sha-1WithRSAEncryption
then the digestAlgorithm must be id-sha1.

I have no specific issue with this rule, but
1) I could not find it anywhere in the current text
2) It contradicts (in spirit) the text from RFC4056, which does
not mandate the use of the same hash function.

--------------------------------------------------------------------
RFC4056:
digestAlgorithms SHOULD contain the one-way hash function used to
compute the message digest on the eContent value.

The same one-way hash function SHOULD be used for computing the
message digest on both the eContent and the signedAttributes
value if signedAttributes exist.

The same one-way hash function MUST be used for computing the message
digest on the signedAttributes and as the hashAlgorithm in the RSA-
PSS-params structure.
--------------------------------------------------------------------

The main problem I see in the current CMS is the fact that two
different techniques can be used for signing/verification (probably
due to legacy interoperability reason, I'm not trying to blame anyone
here :)).

When there are no signedAttrs, the signatureAlgorithm should be
understood as a fake OID, and interpreted differently from the other
RFCs. More precisely, it represents "the part of the signature that you
perform after the hashing". (In theory, that a big problem,
because not all signature algorithms can be expressed as a hash +
some other operations, but in practice, that essentially the case,
so let's live with it).

When there are signed attributes, however, both interpretations become
possible:

- the first one being "we hash the content with digestAlgorithm and then
we hash the signed attributes with the same digestAlgorithm and then
we perform the same half-signing as above".

- The second being: "we hash the content with digestAlgorithm and then
we sign the signedAttrs with the signatureAlgorithm (to be understood
as a _real_ signatureAlgorithm, e.g. including its own hash if it uses
one)."

Apparently, the wording of RFC4056 seem to imply that the second
interpretation should be used. The problem is that RFC4056 is totally
silent about the way to verify when signedAttrs are absent.

RFC3852 is not very verbal regarding the various interpretations,
but I would tend to think it suggests the first one.


Is there a consensus on the list on the correct interpretations ?
Or even better, a quote that clarifies it ?

Regards,

--
Julien Stern