[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions on digest and signature algorithm identifiers in CMS

To: ietf-smime@xxxxxxx
Subject: Re: Questions on digest and signature algorithm identifiers in CMS
From: "Julien Stern" <julien.stern@xxxxxxxxxxxxx>
Date: Fri, 26 Jan 2007 12:00:31 +0100
In-reply-to: <7.0.0.16.2.20070125135823.04aea938@xxxxxxxxxxxx>
List-archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-id: <ietf-smime.imc.org>
List-unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>
Mail-followup-to: Julien Stern <julien.stern@xxxxxxxxxxxxx>, ietf-smime@xxxxxxx
References: <20070119100021.GN4036@xxxxxxxxxxxx> <7.0.0.16.2.20070119120707.040c3e10@xxxxxxxxxxxx> <20070119175315.GU4036@xxxxxxxxxxxx> <7.0.0.16.2.20070124193646.04af4940@xxxxxxxxxxxx> <20070125090319.GQ4036@xxxxxxxxxxxx> <7.0.0.16.2.20070125120250.04a6f9c8@xxxxxxxxxxxx> <20070125174418.GW4036@xxxxxxxxxxxx> <7.0.0.16.2.20070125135823.04aea938@xxxxxxxxxxxx>
Sender: owner-ietf-smime@xxxxxxxxxxxx
User-agent: Mutt/1.5.13 (2006-08-11)

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

Follow-Ups:
- Re: Questions on digest and signature algorithm identifiers in CMS
  - From: Blake Ramsdell

References:
- Questions on digest and signature algorithm identifiers in CMS
  - From: Julien Stern
- Re: Questions on digest and signature algorithm identifiers in CMS
  - From: Russ Housley
- Re: Questions on digest and signature algorithm identifiers in CMS
  - From: Julien Stern
- Re: Questions on digest and signature algorithm identifiers in CMS
  - From: Russ Housley
- Re: Questions on digest and signature algorithm identifiers in CMS
  - From: Julien Stern
- Re: Questions on digest and signature algorithm identifiers in CMS
  - From: Russ Housley
- Re: Questions on digest and signature algorithm identifiers in CMS
  - From: Julien Stern
- Re: Questions on digest and signature algorithm identifiers in CMS
  - From: Russ Housley

Prev by Date: WG LAST CALL: draft-ietf-smime-bfibecms-01.txt
Next by Date: Re: Questions on digest and signature algorithm identifiers in CMS
Previous by thread: Re: Questions on digest and signature algorithm identifiers in CMS
Next by thread: Re: Questions on digest and signature algorithm identifiers in CMS
Index(es):
- Date
- Thread