Re: Questions on digest and signature algorithm identifiers in CMS

On Thu, Jan 25, 2007 at 02:04:10PM -0500, Russ Housley wrote:
> I cannot imagine a situation where they are not the same.
>
> The SigenedData carries a set of digest algorithm identifiers, this 
> allows there to be more than one SignerInfo that contain different 
> digest algorithms.  The SignerInfor carries a single digest algorithm 
> identifier.  It MUST be one of the ones listed in the 
> SignedData.  That digest algorithm is used to hash the content to an 
> to hash the attributes.  The second one being the digest value that 
> is actually signed.
Russ,

first, I just wanted to say I appreciate that you are taking the time
to reply to my emails and possibly weird questions.

My intent is not to do CMS bashing, to claim there is a mistake,
or to ask for a new version of some documents. I am also not
trying to pinpoint an issue in CMS due to a theoretical situation.

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!

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.

However, I still generally believe that the current versions of the
RFCs do not provide enough guidance for _verification_ of a CMS
signature, most notably in the bordercase situations.

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?

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

Regards,

--
Julien

> Russ
>
> At 12:44 PM 1/25/2007, Julien Stern wrote:
>
> > On Thu, Jan 25, 2007 at 12:04:10PM -0500, Russ Housley wrote:
> > > I think it is clear that they SHOULD be the same.  That is, without a
> > > really good reason, use the same one-way hash function in both
> > > places.  I do not know of any case in the real world where they are
> > > different.
> > Russ,
> >
> > OK. I agree they SHOULD be the same. I'm simply asking whether or not
> > they MUST be the same. And if not, what an implementation is
> > supposed to do when it receives a CMS object where there are NOT the
> > same ?
> >
> > - Consider the signature invalid ?
> > - Ignore the hash function in the digestAlgorithm ?
> > - Ignore the hash function in the signatureAlgorithm ?
> > - If signedAtts are present, use the digestAlgorithm for them,
> >  then use the signatureAlgorithm for the signedAtts ? Otherwise fail ?
> >
> > --
> > Julien
> >
> > > Russ
> > >
> > >
> > > At 04:03 AM 1/25/2007, Julien Stern wrote:
> > >
> > > > On Wed, Jan 24, 2007 at 07:40:40PM -0500, Russ Housley wrote:
> > > > > Neither of them seem right to me.  Please review section 3 of RFC 
> > 3370.
> > > > Russ,
> > > >
> > > > section 3 of RFC3370 is silent on this (and so it 3852 actually).
> > > > RFC3370 says that
> > > >
> > > >  "CMS implementations MAY support RSA (PKCS#1 v1.5) signature value
> > > >  algorithm identifiers that specify both the RSA (PKCS #1 v1.5)
> > > >  signature algorithm and the message digest algorithm."
> > > >
> > > > But it does not say what to include in the digestAlgorithm in that case.
> > > > And it seems that RFC3852 and RRFC4056 have different views on this:
> > > >
> > > > RFC3852 says (page 13):
> > > >
> > > >  "digestAlgorithm identifies the message digest algorithm, and any
> > > >  associated parameters, used by the signer.  The message digest is
> > > >  computed on either the content being signed or the content
> > > >  together with the signed attributes using the process
> > > >  described in section 5.4."
> > > >
> > > >  ==> This seems to imply that __THE SAME__ digest must be used for
> > > >      content and signed attributes
> > > >
> > > > But RFC4056 says (page 3):
> > > >
> > > >  "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."
> > > >
> > > >  ==> This seems to imply that __DIFFERENT__ digests may be used for
> > > >      content and signed attributes
> > > >
> > > > I was simply wondering which RFC was correct.
> > > >
> > > > Regards,
> > > >
> > > > --
> > > > Julien
> > > >
> > > > > Russ
> > > > >
> > > > > At 12:53 PM 1/19/2007, Julien Stern wrote:
> > > > >
> > > > > > On Fri, Jan 19, 2007 at 12:08:29PM -0500, Russ Housley wrote:
> > > > > > > Julien:
> > > > > > >
> > > > > > > Does the examples document (RFC 4134) help answer your questions?
> > > > > > Russ,
> > > > > >
> > > > > > unfortunately, they do not. As far as I have seen, they use either
> > > > > > 'sha1' as the digestAlgorithm and 'dsaWithSha1' as the signature
> > > > > > algorithm or 'sha1' as the digestAlgorithm and 'rsaEncryption' as
> > > > > > the signature algorithm.
> > > > > >
> > > > > > So either there is the "magic" OID rsaEncryption, which is not a
> > > > > > real signature OID, or the hash function defined in 'dsaWithSha1'
> > > > > > matches 'sha1'.
> > > > > >
> > > > > > To present my question is a possibly more constructive way,
> > > > > > please find below two snippets of what could be clarifications
> > > > > > to CMS signatures from my humble point of view.
> > > > > >
> > > > > > The list could then tell me which snippet is the "correct" one,
> > > > > > and decide whether it could be regarded as a worthwhile addition
> > > > > > to one of the WG document or not.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > --
> > > > > > Julien
> > > > > >
> > > > > > Possible clarification 1:
> > > > > > -------------------------
> > > > > >
> > > > > > The signatureAlgorithm field in SignerInfo should be interpreted
> > > > > > in a special way inside CMS. It may either contain a fully-fledged
> > > > > > signature algorithm, or the special OID rsaEncryption.
> > > > > >
> > > > > > When it contains a fully-fledged algorithm, the digestAlgorithm
> > > > > > MUST be coherent with the digest used in the signatureAlgorithm
> > > > > > (e.g. if the signature algorithm is RSA with SHA-1, the 
> > digestAlgorithm
> > > > > > MUST be SHA-1, otherwise the verification fails).
> > > > > >
> > > > > > When it contains the special OID rsaEncryption, the full signature
> > > > > > algorithm is defined by looking the digestAlgorithm and will
> > > > > > be an RSA PKCS1.5 signature with the hash function specified
> > > > > > in digestAlgorithm.
> > > > > >
> > > > > >
> > > > > > Possible clarification 2:
> > > > > > -------------------------
> > > > > >
> > > > > > The signatureAlgorithm field in SignerInfo should be interpreted
> > > > > > in a special way inside CMS. It may either contain a fully-fledged
> > > > > > signature algorithm, or the special OID rsaEncryption and should be
> > > > > > interpreted differently depending on whether signedAttrs are present
> > > > > > or not.
> > > > > >
> > > > > > When signedAttrs are present and a fully-fledged signatureAlgorithm
> > > > > > is present, the digestAlgorithm is only used to hash the content,
> > > > > > and the fully-fledged algorithm is used to sign the signedAttrs.
> > > > > > Therefore, it is possible to have MD5 as the digestAlgorithm
> > > > > > and RSA with SHA-1 as the signature algorithm.
> > > > > >
> > > > > > When the signedAttrs are present and the special OID rsaEncryption
> > > > > > is present, the digestAlgorithm is used to hash the content,
> > > > > > and an RSA PKCS1.5 signature with the hash function specified in
> > > > > > digestAlgorithm is used to sign the signedAttrs.
> > > > > >
> > > > > > When signedAttrs are not present and a fully-fledged 
> > signatureAlgorithm
> > > > > > is present, the digestAlgorithm MUST be coherent with the digest used
> > > > > > in the signatureAlgorithm (e.g. if the signature algorithm is RSA 
> > with
> > > > > > SHA-1, the digestAlgorithm MUST be SHA-1, otherwise the verification
> > > > > > fails).
> > > > > >
> > > > > > Finally, when signedAttrs are not present and the special OID
> > > > rsaEncryption
> > > > > > is present, the full signature algorithm on the content is defined by
> > > > > > looking the digestAlgorithm and will be an RSA PKCS1.5 signature with
> > > > the
> > > > > > hash function specified in digestAlgorithm.
> > > > > >
> > > > > >
> > > > > >
> > > > > > > Russ
> > > > > > >
> > > > > > >
> > > > > > > > Folks,
> > > > > > > >
> > > > > > > > I have a few questions regarding the interpretation of the 
> > algorithm
> > > > > > > > identifiers used in CMS in the SignerInfo structure.
> > > > > > > >
> > > > > > > > SignerInfo ::= SEQUENCE {
> > > > > > > >        version CMSVersion,
> > > > > > > >        sid SignerIdentifier,
> > > > > > > >        digestAlgorithm DigestAlgorithmIdentifier,
> > > > > > > >        signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
> > > > > > > >        signatureAlgorithm SignatureAlgorithmIdentifier,
> > > > > > > >        signature SignatureValue,
> > > > > > > >        unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
> > > > > > > >
> > > > > > > >
> > > > > > > > This structure includes both a digestAlgorithm and a
> > > > signatureAlgorithm,
> > > > > > > > and there are two cases: either signedAttrs are present or not.
> > > > > > > >
> > > > > > > > Let us first look at case 1, signedAttrs are present.
> > > > > > > > In that case, we hash the content with the "digestAlgorithm",
> > > > > > > > and then compute the signature on the DER of signedAttrs with
> > > > > > > > "signatureAlgorithm".
> > > > > > > >
> > > > > > > > My first question is: is it authorized to have a _different_
> > > > > > > > hash function is the digestAlgorithm and the signatureAlgorithm ?
> > > > > > > > For instance, can I hash the content with MD5 and sign the
> > > > signedAttrs
> > > > > > > > with "RSA-SHA1" ? How about PSS ? About about the general case ?
> > > > > > > >
> > > > > > > > Now, in case 2, we have both a hash function defined in
> > > > > > "digestAlgorithm"
> > > > > > > > and a hash function (implicitely defined) in "signatureAlgorithm"
> > > > > > > > (except for the special "rsaEncryption" identifier).
> > > > > > > >
> > > > > > > > In that case, is it authorized to have a _different_ hash function
> > > > > > > > in digestAlgorithm and signatureAlgorithm ? And if so, how to
> > > > interpret
> > > > > > > > it ? Assuming I have MD5 for the digest and RSA-SHA1
> > > > > > > > for the signature, should I interpret it as a RSA-MD5 signature ?
> > > > > > > > As a RSA-SHA1 signature ? Or should I consider the CMS as invalid 
> > ?
> > > > > > > > Is there a general rule ?
> > > > > > > >
> > > > > > > > Thank you very much for your clarifications.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > --
> > > > > > > > Julien Stern