ietf-smime
[Top] [All Lists]

CAdES implementation. The algorithm to hash attributes.

2006-12-22 04:32:39
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: spv(_at_)CryptoPro(_dot_)ru <mailto:spv(_at_)CryptoPro(_dot_)ru> 

 

<Prev in Thread] Current Thread [Next in Thread>
  • CAdES implementation. The algorithm to hash attributes., Смирнов Павел Владимирович <=