ietf-smime
[Top] [All Lists]

Re: CAdES implementation. The algorithm to hash attributes

2007-06-14 13:53:43



-----Original Message-----
From: Pope, Nick 
Sent: 14 June 2007 21:33
To: 'spv(_at_)CryptoPro(_dot_)ru'; ''ietf-smime(_at_)imc(_dot_)org'
Subject: Re: CAdES implementation. The algorithm to hash attributes


Pavel,

Sincere apologies for missing your email from a number of months ago.  Your
input is welcomed although the response was very late.

This identifies what I believe to be three issues:

1) What encoding is used?  I suggest the answer should be the 
equivalent to the note as for archive time-stamp.

"NOTE: Unless DER is used throughout, it is recommended that the binary 
encoding of the ASN.1 structures being time-stamped are preserved to 
ensure that the recalculation of the data hash is consistent."

2) Exactly what part of the Attribute encoding is hashed?  I suggest 
that the current text implies that each attribute is hashed with the 
attrType and attrValues (including type and length) but without the 
type and length of the SEQUENCE.

This could be clarified by a note:
"NOTE: Each attribute is included in the hash with the attrType and 
attrValues (including type and length) but without the type and length 
of the outer SEQUENCE."

3) Why are Type and Length not include?  I think this a matter of style 
and provided it is explicit this is not an issue.

I suggest the same clarification be added to 6.3.6.

I believe the revised text on archive timestamp already addresses these 
issues.

I hope that these comments are still of help.

Regards

Nick Pope
Thales eSecurity.



To: <ietf-smime(_at_)xxxxxxx> 
Subject: CAdES implementation. The algorithm to hash attributes. 
From: =?koi8-r?b?883J0s7P1yDwwdfFzCD3zMHEyc3J0s/Xyd4=?= <spv(_at_)xxxxxxxxxxxx> 
Date: Fri, 22 Dec 2006 14:01:14 +0300 
Sender: owner-ietf-smime(_at_)xxxxxxxxxxxx 

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

 
 

----------------------------------------------------------------------------
----

Prev by Date: I-D ACTION:draft-ietf-smime-ibearch-02.txt 
Previous by thread: I-D ACTION:draft-ietf-smime-ibearch-02.txt 
Index(es): 
Date 
Thread
Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email 
postmaster(_at_)thales-esecurity(_dot_)com(_dot_)
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited". 

<Prev in Thread] Current Thread [Next in Thread>
  • Re: CAdES implementation. The algorithm to hash attributes, Pope, Nick <=