Subject: CAdES implementation. The algorithm to hash attributes.

From: Смирнов Павел Владимирович <[email-masked]>
Date: Fri, 22 Dec 2006 14:01:14 +0300

Greetings!

We work on implementing the electronic signature formats defined in ETSI TS 101 733 v1.6.3. We encountered a problem and need some help. S/MIME working group has adopted the previous version of this standard in RFC 3126 and we hope people on this list can answer the question. If this is the wrong place, please give an advice where to address the problem.

The question arises when we must hash data to create a CAdES-C time-stamp (section 6.3.5). The standard says the following:

The value of messageImprint field within TimeStampToken shall be a hash of the concatenated values (without the type or length encoding for that value) of the following data objects:

∙ OCTETSTRING of the SignatureValue field within SignerInfo;

∙ signature-time-stamp; or a time mark operated by a Time-Marking Authority;

∙ complete-certificate-references attribute;

∙ complete-revocation-references attribute.

The note "without the type or length encoding for that value" instructs us to omit the OCTETSTRING tag and length of the SignatureValue. It is rather clear (but unclear why, I will mention this later). Next, what do we have to do with three attributes left? Do we have to omit SEQUENCE tag and length of the Attribute object? Or do we have to omit attrType of this Attribute? Or do we have to hash the complete ASN.1 DER representation of these attributes as it was done for SignatureValue in CMS over signedAttrs value?

The standard should describe such points unambiguously. What did I miss?

The same problem applies to the hash calculation for the archive time-stamp attribute:

The value of messageImprint field within TimeStampToken shall be a hash of the concatenation of:

∙ The encapContentInfo element of the SignedData sequence;

∙ When present, the Certificates and crls elements of the SignedData sequence;

∙ Together with all data elements in the SignerInfo sequence including all signed and unsigned attributes.

Here we cannot see the magic "without the type or length encoding for that value" note. This leaves us wondering why there is such difference.

RFC on CMS has a very good explanation on how to calculate message digest for the signature. That explanation leaves no ambiguity and clears the point why we should omit tag and length encoding of eContent. So may be hash calculation should be clarified in the current edition of CAdES standard.

Pavel V. Smirnov
CryptoPro
Tel: +7 495 933-1168
WWW: http://www.CryptoPro.ru <http://www.cryptopro.ru/> 
e-mail: [email-masked] <mailto:[email-masked]>