ietf-smime
[Top] [All Lists]

Re: Questions on digest and signature algorithm identifiers in CMS

2007-01-25 11:11:46

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