Subject: signedattributes in countersignature

From: [email-masked]
Date: Mon, 29 May 2006 11:57:46 +0300 (EEST)

Hi,
 My question is about cms structure which has a countersignature attribute
in its SignerInfos. When countersignature attribute which is again a
SignerInfo, has signedattribute(s), what will be data to be signed? RFC
3852(Cryptographic Message Syntax (CMS)) only says that:
   The countersignature attribute type specifies one or more signatures
   on the contents octets of the signature OCTET STRING in a SignerInfo
   value of the signed-data.  That is, the message digest is computed
   over the octets comprising the value of the OCTET STRING, neither the
   tag nor length octets are included.

But I could not find any information about countersignature which has
signedattribute? Is it necessary to sign der encoding of the
signedattributes as a usual SignerInfo in the signature structure as
defined in RFC 3852?
   The result of the message digest calculation process depends on
   whether the signedAttrs field is present.  When the field is absent,
   the result is just the message digest of the content as described
above.      When the field is present, however, the result is the
message
   digest of the complete DER encoding of the SignedAttrs value
   contained in the signedAttrs field.

  Moreover, is there any restriction in signed attributes which may be in
countersignature attribute?

 Işıl

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 May 2006 09:59:37 -0400

Did you see section 11.4 in RFC 3852?  It seems to answer most of 
your questions.

The countersignature cannot include the content-type attribute.

Russ

At 04:57 AM 5/29/2006, [email-masked] wrote:

>  Iþýl

---

From: [email-masked]
Date: Tue, 30 May 2006 21:58:24 +0300 (EEST)

Yes, I have seen the section. But there is no additional information
about other attribute restrictions and more importantly the input to the
signing process if there are signed attributes in the structure.

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 May 2006 16:48:48 -0400

It is a SignerInfo, so the normal processing order applies.  The 
attributes must be DER encoded before they are hashed.

Russ

---

From: [email-masked]
Date: Wed, 31 May 2006 09:21:14 +0300 (EEST)

But RFC says:

 You say, there is no difference in the input if CounterSignature has
signed attributes. According to the RFC; if exists, input to the Message
digest attribute is the signature value of the SignerInfo.
 I could not find anything in RFC or any other documents this explanation.

 Işıl
>> >>   Moreover, is there any restriction in signed attributes which may
>> be
>> >> in

---

From: Russ Housley <[email-masked]>
Date: Wed, 31 May 2006 10:54:08 -0400

The computation of the signature works like this in the "normal" case:

1.  Compute the message digest on the content:

       H1 = Hash(content)

2.  ASN.1 DER encode the signed attribute set, including H1 as the 
value for the message digest attribute, then compute the message 
digest on the signed attributes:

       H2 = Hash(DER(signed_attrs))

3.  Digitally sign H2 using the signer's private key:

       Sign(H2)

The computation of the countersignature is the same as the normal 
case, except that the content is different in step 1.

1.  Compute the message digest on the octets of the DER encoding of 
the signatureValue field:

       H1 = Hash(signature)

2.  ASN.1 DER encode the signed attribute set, including H1 as the 
value for the message digest attribute, then compute the message 
digest on the signed attributes:

       H2 = Hash(DER(signed_attrs))

3.  Digitally sign H2 using the signer's private key:

       Sign(H2)

I hope this helps,
   Russ

---

From: [email-masked]
Date: Wed, 31 May 2006 22:33:52 +0300 (EEST)

Thank you very much for all your help, this will help me.

>> >> >>    over the octets comprising the value of the OCTET STRING,
>> neither
>> >> the