[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questions on digest and signature algorithm identifiers in CMS
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
> >> >>
> >>
>