It is a SignerInfo, so the normal processing order applies. The
attributes must be DER encoded before they are hashed.
Russ
At 02:58 PM 5/30/2006, ihasircioglu(_at_)uekae(_dot_)tubitak(_dot_)gov(_dot_)tr
wrote:
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.
>
> 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,
ihasircioglu(_at_)uekae(_dot_)tubitak(_dot_)gov(_dot_)tr wrote:
>
>> 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
>
>